Governance across the AI life cycle

The governance chaingovernance chainThe traceable line by which a single pillar is held for a single system: principle, then the harm that would breach it, then the risk that harm carries, then the control that reduces the risk (preventive, detective, or corrective), then the residual risk judged against appetite, proven with evidence. The chain is what makes responsible AI accountable rather than aspirational, and what lets an organization move a principle from a policy statement to a working control it can point to. See principle, harm, risk, control, residual risk, evidence.Open full entry → in the foundation article runs in one direction: a principleprincipleOne of the seven responsible-AI values a governed system should live up to (fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, human oversight). A principle is abstract: it states an outcome, not a lever you can pull. It becomes governable by naming the harm that would breach it, assessing the risk that harm carries, and placing controls against that risk. When GovCompass holds a principle this way it calls it a pillar. See pillar, harm, risk.Open full entry →, the harmharmThe concrete damage an AI system can do that a responsible-AI principle exists to prevent: in the EU AI Act's terms, harm to a person's health, safety, or fundamental rights. Harm is the bridge between an abstract principle and a governable risk; governance becomes operational the moment an organization names the specific harms it wants to prevent. For fairness, a harm is a group receiving systematically worse outcomes because of a characteristic that should not have counted. See principle, risk.Open full entry → that would breach it, the riskriskIn the EU AI Act's terms, the combination of the probability that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → that harm carries, the controlcontrolThe concrete, testable measure that reduces a specific risk, and through that risk protects the principle behind it. Also called a risk management measure, risk response, or risk treatment. Always traceable to the risk it addresses: under EU AI Act Art. 9 every control must map back to a specific risk, and controls recorded separately from their risks is a recognized compliance failure. It works in one of three types: preventive, detective, or corrective. See risk, control types, evidence.Open full entry → that reduces the risk, the evidenceevidenceThe concrete proof that a control is designed, implemented, and working: a test report, an audit trail, an impact assessment, a monitoring log. Each link in the governance chain produces an artifact, and together they are what an organization hands to its own board, a regulator, a customer, or an affected person to show, not say, that a system is governed. Its absence is itself the failure: a risk register without test results, or a mitigation claimed without validation, is a governance gap, not a paperwork one. The closing link of the governance chain. See control, governance.Open full entry → that the control works. That is the vertical axis of the model, how a single principle is held.

This article is about the other axis, the horizontal one: time. An AI systemAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs — predictions, content, recommendations or decisions — that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry → is not governed in a single moment. It is governed across a life that runs from the first intake decision to the day it is switched off, and each stage of that life has its own work to do. The two axes meet at every point: in each stage of the life cyclelife cycleThe span of a single AI system from first intake to retirement, across which it must be governed. The horizontal axis of governance: where the governance chain holds one principle, the life cycle runs one system through time. Commonly drawn as six stages, plan and design, data and develop, verify and validate, deploy, operate and monitor, and retire, each with controls native to it and an anchor artifact. A loop rather than a line, because a system in production feeds new risk back into fresh assessment. See artifact, control, governance chain.Open full entry → you run the chain, asking which risks are live now and which controls belong here. Where they meet, the controls produce the artifacts that an auditor will later ask to see.

A loop, not a line

It is tempting to draw the life cycle as a straight line from idea to retirement. The working view is a loop. A system in production throws up new data, new failure modes, and new regulation, and that feeds back into a fresh round of assessment, sometimes a redesign, sometimes a retraining. The frameworks agree on this shape even where they name the stages differently: the NIST AI Risk Management Framework runs from concept and design through data, development, and testing to deployment, monitoring, and retirement, and treats governancegovernanceThe system through which an organization steers itself: corporate governance, risk management, compliance, lines of accountability, risk appetite, and the operating model. It exists across everything the organization does, before and beyond AI. AI governance is this same system extended for AI. See AI governance, governance design, execution level.Open full entry → as something that spans all of it rather than sitting at the front.

Six stages give enough resolution to be useful without becoming a checklist. Each has controls that are native to it, the work that belongs in that stage and nowhere else, and each produces an anchor artifactartifactThe concrete record that proves a control was carried out: a test report, an impact assessment, a monitoring log, a release sign-off. An artifact is the tangible form evidence takes, the thing an auditor reaches for to confirm that a control was not just designed but actually operated. Each stage of the AI life cycle produces its own anchor artifact. Distinct from evidence as a whole: evidence is the proof, an artifact is one piece of it. See evidence, life cycle.Open full entry →, the one document or record an auditor reaches for first.

The six stages

1. Plan and design. The system is scoped before it is built: intake, risk-tiering, an impact assessmentimpact assessmentA structured evaluation, carried out in the plan-and-design stage, of the harms an AI system could cause and the risk those harms carry, before the system is built. The first place the governance chain is run, and the cheapest point in the life cycle to reduce risk. The anchor artifact of the planning stage; under the EU AI Act, a fundamental-rights impact assessment is required for certain high-risk deployers. See harm, risk, life cycle.Open full entry →, an ethics review, and a go or no-go gate. This is where the cheapest risk reduction in the whole life cycle sits, because a risk caught here costs a conversation, while the same risk caught in production costs a recall. The anchor artifact is the impact and risk assessment, with the ethics-review minutes and the go/no-go decision logdecision logThe recorded outcomes and reasoning of governance decisions (committee approvals, risk acceptances) — building precedent, consistency and auditability.Open full entry → beside it.

2. Data and develop. The model is built. The controls native to this stage govern the data and the building: data acquisition-and-use policies covering rights, quality, and lineage; bias testing; documentation produced as you build rather than reconstructed afterward; and secure development practice. The anchor artifact is a datasheetdatasheetA document recording the provenance of a dataset: its sources, the rights under which it is used, its composition, and its known limitations. The anchor artifact of the data-and-develop stage, it makes the data behind a model traceable and is a precondition for assessing risks such as bias. See artifact, life cycle.Open full entry → for each dataset, recording its sources, rights, and limitations, with the lineage records and development documentation.

3. Verify and validate. The model is tested against the bar set in stage one. The native controls are defined acceptance thresholds, independent review, and a release gaterelease gateA decision point in the verify-and-validate stage where a system is checked against defined acceptance thresholds and signed off before it can go live, by someone with the authority to refuse. A preventive control: a release gate that no one can refuse is not a gate. Its anchor artifact is the release sign-off, recording who approved deployment and on what basis. See control, control types, life cycle.Open full entry → signed by someone with the authority to say no. The signature matters: a release gate that no one can refuse is not a gate. The anchor artifact is the test and validation report, with the release sign-off.

4. Deploy. The system goes live. The native controls are a deployment checklist, user training, fallback and rollback plans, and notices to the people the system affects. The anchor artifact is the model cardmodel cardA structured document describing an AI model: its purpose, training data, performance across conditions, limitations, and intended use. A core deployment-stage artifact, it lets the people operating and overseeing a system understand what it does and where it should not be trusted. Part of the technical documentation an auditor expects for a high-risk system. See artifact, life cycle.Open full entry → or system documentation, with the instructions for use, the training recordstraining recordsEvidence of who completed which training content version, when, with results — the artefact that makes training function as a compliance control.Open full entry →, and the rollout plan.

5. Operate and monitor. The system runs, and this is the stage that matters most and is served worst. The native controls are continuous monitoringcontinuous monitoringOngoing observation of a deployed system's performance, drift, fairness and usage against thresholds with named owners — the control that matches AI's speed and scale.Open full entry → with alert thresholds and named owners, periodic reassessment, incident management, and change managementchange managementControlled handling of updates to models, data and configurations — every material change re-passes validation before redeployment.Open full entry →. The anchor artifact is the body of monitoring reports and logs, with incident records that show the corrective action taken, and the change log.

6. Retire. The system is switched off, which is itself a governed act. The native controls are a turn-off plan, communication to stakeholders, disposition of the data and the model, and record retention. The anchor artifact is the decommissioningdecommissioningDeliberate retirement of an AI system: turn-off plan, stakeholder communication, data and model disposition, record retention.Open full entry → record, with the disposition evidence and the retained archive.

Stage	Controls native to it	Anchor artifact
1. Plan and design	Intake, risk-tiering, impact assessment, ethics review, go/no-go gate	Impact and risk assessment (with ethics-review minutes, go/no-go log)
2. Data and develop	Data acquisition-and-use policy, bias testing, build-time documentation, secure development	Datasheets (with lineage records, development documentation)
3. Verify and validate	Acceptance thresholds, independent review, signed release gate	Test and validation report (with release sign-off)
4. Deploy	Deployment checklist, user training, fallback and rollback, notices to affected people	Model card or system documentation (with instructions for use, training records, rollout plan)
5. Operate and monitor	Continuous monitoring with thresholds and owners, periodic reassessment, incident and change management	Monitoring reports and logs (with incident records, change log)
6. Retire	Turn-off plan, stakeholder communication, data and model disposition, record retention	Decommissioning record (with disposition evidence, retained archive)

Where life-cycle governance actually fails

The first four stages get the attention, because they are where the system is built and where launch pressure concentrates. The stage that fails is the fifth. Two independent research efforts, one government-funded and one from industry, have separately found that production monitoring and the validation of a system's behavior once it is live are the most underserved controls in the entire field: the tooling and the practice have not caught up with what the frameworks already require. The hard problem is not building a system that works on launch day. It is proving it still works six months later.

This is the life-cycle expression of the failure the foundation article names: a governance designgovernance designThe tier at which governance structures, policies, frameworks, and standards are established; sets the rules the execution level must follow.Open full entry → that is strong on paper and hollow in practice. An organization runs the intake gate, tests the model, signs the release, and then lets the monitoring lapse, and the system drifts unwatched. Every control in stages one to four can be in place and the system can still fail, because governance is not a gate you pass once but a loop you keep running. The operate stage is where the loop is most often left open.

How this connects to the chain

The two axes are one model seen from two directions, and the connection between them is evidence.

Run the chain inside any stage and it produces that stage's anchor artifact. In plan and design, working out the harms a system could cause and tiering its risk is the chain's first links, and the impact assessment is the evidence they were done. In verify and validate, testing a control against a defined threshold is the chain's control-and-evidence step, and the validation report is the proof. In operate and monitor, watching for a risk that prevention did not eliminate is a detective control, and the monitoring log is its evidence.

So the life cycle answers a question the chain on its own does not: when. The chain says every control must be tied to a risk and proven with evidence. The life cycle says here is when in a system's life each control is applied and each piece of evidence is produced. Read together, they give the whole picture: what holds a principle in place, and across what span of time the work is done and the proof accumulates.

Continue reading

• What is AI governance
• How the GovCompass model maps to the major frameworks