This article is provided for general information and does not constitute legal or regulatory advice. It reflects publicly available sources as at 18 September 2026. Regulatory timelines and standards are changing; confirm obligations with your own compliance function and the relevant authority.
Most organizations now have an AI governance policy. Far fewer can answer a simple question about any given model in production: who approved it, on what evidence, and what would happen if it started behaving differently tomorrow.
That gap is not a failure of intent. It is a failure of form. A policy describes what should be true. A system produces evidence of what is true. Those are different artifacts, and only one of them survives contact with a deployment schedule.
This article is about the second kind. Not what your governance framework should say - there is no shortage of good material on that - but where each requirement has to live in the stack before it counts as implemented.
One question sorts governance requirements into implemented and aspirational:
What artifact does this produce, and who would notice if it stopped being produced?
Apply it to a typical policy line - "models must be reviewed for bias before deployment". Implemented, that means: an evaluation runs in the pipeline, writes a result somewhere durable, and the deployment fails if the result is missing. Unimplemented, it means someone did an analysis once, in a notebook, and the notebook is on a laptop.
Both versions satisfy the policy as written. Only one can be evidenced twelve months later when the person who did the analysis has changed teams.
The same test applied across a governance framework tends to produce an uncomfortable inventory. That discomfort is the useful output. Most organizations find that their governance is real at the level of decisions and absent at the level of artifacts.
Governance fails when it is assigned to a committee rather than to a layer of the stack. These five are where the artifacts actually get produced.
What has to be true: you can say what data a model was trained, fine-tuned or grounded on, where it came from, and what constraints came with it.
Artifact: dataset lineage recorded at build time - source, date, basis of use, and any personal data it contains. Where that personal data sits is its own design problem - we cover it separately. Not a spreadsheet maintained by hand; a record produced by the pipeline that assembles the data.
How it fails: the lineage exists for the initial training run and not for the four refreshes since. Lineage that is not automated does not survive contact with iteration.
What has to be true: every model in production is identifiable, and you can tie it to the evaluation that justified deploying it.
Artifact: a model registry entry - version, training data reference, evaluation results, approver, deployment date. This is the single highest-value artifact in the list, because almost every governance question resolves to "which version, and what did you know about it".
How it fails: a vendor model is updated underneath you. If your registry records "GPT-class provider endpoint" rather than a pinned version and a date, you cannot answer what changed when behavior shifts.
What has to be true: the path from a model existing to a model serving traffic is gated, and the gate produces a record.
Artifact: a release record naming the version, the reviewer, the evaluation evidence, and the rollback plan. The gate should be automated enough that skipping it requires a deliberate override - and the override should itself be logged.
How it fails: the gate applies to the model and not to the prompt, the retrieval index, or the tool configuration. In a modern AI system these change far more often than the model does, and they change behavior just as much.
What has to be true: you can see what the system is doing in production, and you can stop it.
Artifacts: monitoring on output quality and drift, logging of what the system accessed and did, correlation identifiers that let a single decision path be reconstructed across services, and a revocation mechanism that works in seconds.
How it fails: