Enter for every AI system. Go as deep as your system letter, and implement in your mode.
Why it exists
Make every AI system pass through defined gates on its way into production — and make leaving production as deliberate as arriving. AI that appears in production by accident, because a pilot quietly became permanent or a feature toggle was never revisited, is AI that no one approved, no one owns, and no one will retire. Impose a lifecycle: every system is requested, evaluated, approved, deployed, monitored, and — the step almost everyone forgets — retired, in that order, with a decision at each transition. Six phases, then: request, evaluation, approval, deployment, monitoring, retirement.
What to actually do
Open every initiative with a charter that states what is out of scope. Before work begins, write a short charter: what the initiative is for, what it will and — explicitly — will not do, who its stakeholders are, how success will be measured, and who signs off. The out-of-scope line is the one teams always skip and the one that later saves them: it is the only durable defence against the quiet expansion by which a document-summarising pilot becomes, six months later, a system making decisions about people, without anyone ever having approved the change.
Give experimentation a sanctioned place, or it will find an unsanctioned one. Provide a governed environment in which teams can try AI safely: separated from production, using non-sensitive or synthetic data, with no production credentials, and with defined criteria for what graduates out of it. This is as much a control against unregistered AI as it is an evaluation tool — people experiment either where you can see them or where you cannot, and the sandbox is how you choose the former.
Gate the approval in proportion to the risk. Before any system goes live, it is approved — but calibrate the weight of that approval to the stakes. A low-risk internal tool needs a light, fast decision by its owner. A high-risk system — one affecting people’s rights, money, health, or safety — requires sign-off from each of risk, security, privacy, compliance, and the business, with the remaining risk after mitigations documented and accepted by name. Proportionality is what keeps the gate respected: a gate that is equally heavy for everything will be evaded for everything.
Plan the retirement on the day you approve the launch. Decommissioning an AI system is not switching it off. Require, for every retirement: the secure disposition of the data it held; the archival or destruction of the model itself; the purge of the derived stores built from its data; the revocation of every access credential and every connection an agent held — because an agent whose keys are never revoked remains a live door into your systems long after everyone has forgotten it exists — and the transfer of whatever knowledge the system embodied. Write the retirement plan at approval time, while someone still knows what the system touches.
Controls
Baseline2 controls
Control 31
Define the request-to-retirement lifecycle and route every AI system through it.
BaselinePreventiveall rolesper system
What it is
No system reaches production outside the six phases.
How to implement it · Minimum structure
Six phases: request, evaluation, approval, deployment, monitoring, retirement
For each phase: entry condition, who decides, minimum record kept
Request form: purpose, AI Owner, data used, users, expected benefit
Rule: nothing reaches production without a recorded approval; pilots carry an end date
Retirement as a planned phase, not an afterthought
Each system's current phase shown in the register
How to start
Write a one-page description of the six phases and the decision at each, and place every existing system in its current phase in the register.
Evidence
The lifecycle description and register entries showing each system's phase and decisions.
Mode: light / standard / full
light
The owner-manager approves each transition and records it in the inventory spreadsheet.
standard
AI Owners move systems through the phases with a shared form, and the AI lead checks no system skips approval.
full
The lifecycle runs in a workflow tool with mandatory gates linked to the register.
Control 32
Approve every system before deployment, at a weight proportionate to its risk.
BaselinePreventiveall rolesper system
What it is
Light for low stakes, multi-party for high stakes — but always an explicit decision by an accountable person.
How to implement it · Minimum rules
Approval levels tied to the risk class, written down in advance
Low risk (internal, no personal data, no decisions about people): the AI Owner approves with a short record
Medium risk: AI Owner plus Technology Owner, with a security and privacy check
High risk (rights, money, health or safety): multi-party sign-off and named acceptance of residual risk
Every approval records approver, date, risk class and conditions
No deployment without a recorded approval
How to start
Define two or three approval levels tied to the risk class and use them for the next system requested.
Evidence
The approval records, each showing approver, date and risk class.
Mode: light / standard / full
light
The owner-manager approves every system, with a one-line record for low risk and a written note of the risks accepted for anything higher.
standard
Approval rights are assigned per level and the AI lead keeps the approval log.
full
Approval levels are enforced in the workflow tool, with high-risk approvals routed to the committee.
Enhanced4 controls
Control 33
Open each initiative with a charter that includes an explicit out-of-scope boundary and a named sign-off.
EnhancedPreventiveall rolesper system
What it is
Scope changes re-open the charter; they do not bypass it.
How to implement it · Minimum structure
Purpose and the business objective it serves
In scope: what the initiative will do
Out of scope: what it explicitly will not do (e.g. will not make or recommend decisions about individuals)
Stakeholders
Success measures and how they will be checked
Named sign-off
Rule: any change of scope re-opens the charter and needs a new sign-off
How to start
Adopt a one-page charter template and require a signed charter before work starts on the next initiative.
Evidence
Signed charters with their out-of-scope lines and any re-opened versions.
Mode: light / standard / full
light
The owner-manager signs a one-page charter written by whoever proposes the initiative.
standard
The AI Owner writes and signs the charter, and the AI lead checks it before evaluation begins.
full
Charters are held in the portfolio system, with scope changes routed back through formal re-approval.
Control 34
Operate a sanctioned experimentation environment.
EnhancedPreventiveall rolesper system
What it is
Isolated from production, without sensitive data or production credentials, with defined graduation criteria.
How to implement it · Minimum rules
Separated from production systems and networks
Only non-sensitive or synthetic data
No production credentials or connectors to internal systems
Each experiment registered: owner, purpose, end date
Graduation criteria: charter, risk class and approval through the lifecycle before any production use
Experiments past their end date closed and their data deleted
How to start
Set up one isolated workspace with synthetic or public data and publish the rules for using it.
Evidence
The sandbox rules, the experiment register and graduation records.
Mode: light / standard / full
light
Use a separate trial account with the provider, holding no company data, and keep the experiment list in a spreadsheet.
standard
IT provides an isolated environment and the AI lead tracks experiments and graduations.
full
A managed experimentation platform enforces isolation and data rules technically, with graduation through the approval workflow.
Control 35
Require multi-party sign-off for high-risk systems.
EnhancedPreventiveall rolesper system
What it is
Risk, security, privacy, compliance, and the business each sign, and the residual risk is recorded and owned.
How to implement it · Minimum content
Signatories: risk, security, privacy, compliance and the business (AI Owner)
Each signatory's findings and conditions
Residual risk after mitigations, described in plain terms
Named person who accepts the residual risk, with authority under the risk appetite
Version of the system approved and date
Any refusal blocks go-live until resolved or escalated
How to start
Create a sign-off sheet with the five signature lines and a residual-risk section, and attach it to the next high-risk approval.
Evidence
Completed sign-off sheets with named residual-risk acceptance.
Mode: light / standard / full
light
Commission external advice for the specialist views, and the owner-manager signs the acceptance of residual risk.
standard
Existing managers sign for each function, coordinated by the AI lead.
full
Each function signs through the approval workflow, and the committee authorises go-live on the completed record.
Control 36
Evaluate and document impact before deployment.
EnhancedPreventiveall rolesper system
What it is
The evaluation covers the people affected, not only the technology.
How to implement it · Minimum structure
System description, purpose and context of use
People affected: who, how many, and any vulnerable groups
Possible harms: errors, unfair treatment, privacy intrusion, loss of opportunity, safety
Mitigations and the human oversight in place
Remaining impact and the conclusion: proceed, proceed with conditions, or stop
Review on any change of purpose, data or affected population
How to start
Complete a short impact template for the next system before approval, with the AI Owner and someone who knows the people affected.
Evidence
The completed impact evaluations attached to the approval records.
Mode: light / standard / full
light
The owner-manager and the AI Owner fill a two-page template together.
standard
The AI Owner leads the evaluation with privacy and the relevant business area, and the AI lead reviews it.
full
A structured evaluation by a specialist team, with consultation of affected groups for high-risk systems and committee review.
Advanced1 controls
Control 37
Execute planned decommissioning for every retirement.
AdvancedPreventiveall rolesper system
What it is
Data disposition, model archival or destruction, purge of derived stores, credential and connection revocation, and knowledge transfer — evidenced, not assumed.
How to implement it · Steps
Data: return, archive or delete what the system held, according to its retention rules
Model: archive or destroy it, and record which
Derived stores: purge indexes, caches, summaries and logs built from its data
Access: revoke every credential, key, token and connector the system or its agents held, and verify none still works
Knowledge: document what the system did, its decisions and dependencies, and hand over to whoever takes on the work
Close: mark the asset retired in the register, with the AI Owner's sign-off and evidence for each step
How to start
Turn these steps into a checklist and require evidence for every line before the next retired asset is closed.
Evidence
Decommissioning records, including proof of credential and connector revocation.
Mode: light / standard / full
light
A named person works through the checklist using the provider's account-closure and deletion settings; the owner-manager signs it.
standard
The Technology Owner executes the checklist and the AI Owner signs off the evidence.
full
Decommissioning runs as a managed change with automated revocation checks and independent verification before closure.
Evidence
Charters with their out-of-scope lines; sandbox usage and graduation records; approval and sign-off records with named residual-risk acceptance; impact evaluations; decommissioning records including revocation evidence.