# AI Development & Deployment Standard

**Purpose.** The engineering-facing requirements for building, testing, deploying, and operating AI systems — the technical controls that make the framework's principles real inside a delivery pipeline.

**When to use it.** Applies to every system you build or materially fine-tune. Apply the gates proportionately: full rigour for high-risk, light touch for minimal.

**How to use it.** Implement the gates as pipeline checks rather than documents wherever you can. A requirement that a human must remember to check will be skipped under deadline pressure; one that fails a build will not.

---

### 1. Scope

Applies to AI systems built, fine-tuned, or materially configured by
**[Organisation]**. Third-party systems used as-is fall under
Third-Party AI Risk Policy.

### 2. Lifecycle gates

| Gate | Requirement | Evidence | Blocking? |
|---|---|---|---|
| **G1 Intake** | Prohibited-practice screen; risk tier assigned; registered. | AI System Inventory entry | Yes — all tiers |
| **G2 Data** | Sources registered, lawful, classified; quality assessed. | Data Asset Register; quality report | Yes — all tiers |
| **G3 Design** | Risk assessment started; oversight approach defined. | AI Risk Assessment | High-risk |
| **G4 Build** | Evaluation plan; bias testing; version control of data and model. | Test results | High-risk |
| **G5 Pre-deploy** | Documentation complete; oversight operable; owner sign-off. | Model Card / Model Risk Documentation; sign-off | Yes — all tiers |
| **G6 Operate** | Monitoring live; logging retained; incident route defined. | Monitoring config | High-risk |
| **G7 Change** | Material change re-triggers G3–G5. | Change record | High-risk |
| **G8 Retire** | Decommissioned; records retained; inventory updated. | Retirement record | Yes — all tiers |

### 3. Data requirements

- Training, validation, and test data **must** be documented as to source,
  licence, and lawful basis.
- Splits **must** be documented and leakage-checked.
- Representativeness **must** be assessed against the affected population.
- Data versions **must** be recorded so results can be reproduced.

### 4. Evaluation

| Requirement | Minimal | High-risk |
|---|---|---|
| Accuracy metrics declared | Recommended | **Required** |
| Performance across subgroups | Recommended | **Required** |
| Robustness / adversarial testing | Optional | **Required** |
| Reproducible evaluation | Recommended | **Required** |
| Independent review of results | Optional | **Required** |

Declare metrics **before** running the evaluation. Choosing the metric after
seeing the results is how systems get approved on the one number that
happened to look acceptable.

### 5. Logging

High-risk systems **must** automatically log, at minimum: timestamp, system
and model version, input reference, output, confidence where available, and
any human override. Retain per {{default:log-retention}} — long enough to
reconstruct a decision if it is challenged.

> **Application logs are usually not enough**
> Standard telemetry records that a request happened. Art. 12 traceability
> needs what the model was asked and what it answered. These are rarely the
> same log.

### 6. Human oversight implementation

- The interface **must** show the reviewer what they need in order to judge
  the output, including uncertainty.
- Override **must** be possible without engineering involvement.
- Overrides **must** be logged and reviewed for pattern — a system that is
  overridden constantly is not working.
- Reviewer workload **must** allow genuine consideration. Record the assumed
  review time per decision.

### 7. Security

Address AI-specific threats alongside conventional application security:
prompt injection, training-data poisoning, model extraction, membership
inference, and unintended disclosure through outputs. See
Control Library & Assurance Map.

### 8. Deployment & rollback

Staged rollout for high-risk systems, with a **tested** rollback path and a
defined kill switch. Record who can invoke it — see Decision Rights & Escalation.

### 9. Review

| Version | Date | Owner | Approved by |
|---|---|---|---|
| 0.1 | [date] | [role] | [committee] |

---

## Adaptation notes

- **Small teams:** Gates G1, G2, G5, and G8 are the minimum viable set: know what you have, know your data is lawful, check before launch, clean up after.
- **MLOps-mature organisations:** Map each gate to an existing pipeline stage and enforce it in CI. The goal is that evidence is produced as a by-product rather than assembled before an audit.
- **Regulated financial services:** Add independent model validation before G5 and align documentation with your model risk management standard.
- **Mostly buying, not building:** This standard will be largely out of scope. Invest instead in Third-Party AI Risk Policy and contractual evidence rights.

---

*From the [Open Data & AI Governance Kit](https://lsdeva.github.io/governance-kit/). Licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) — free to use, adapt, and share with attribution.*

***Not legal advice.** Adapt to your jurisdiction, sector, and risk appetite, and have qualified counsel review anything material.*