Governance starts with knowing which AI systems you run, what data shaped them and how to restore a version you trust. This section covers inventories, data governance, lineage, recoverable assets and the documentation that makes models auditable.
You cannot govern AI you do not know about. An AI inventory is a register of every AI system, who owns it, how risky it is and how far it can act on its own, much like an asset register for company laptops but with risk ratings attached. It also lists what each system depends on, such as data, models, tools and people.
diagram
One inventory record ties an AI system to an owner, a risk rating and its dependencies. These are the fields ADG MC-1, NIST GOVERN 1.6 and ISO/IEC 42001 A.4 point to.
Key points
ADG (Adopt, Defend, Govern) Minimum Control 1 (MC-1) requires an inventory of every AI system with an accountable owner, a risk classification and an autonomy tier.
NIST AI Risk Management Framework (AI RMF) GOVERN 1.6 calls for mechanisms to inventory AI systems, resourced according to organizational risk priorities.
ISO/IEC 42001 Annex A control A.4 documents AI resources: resource documentation (A.4.2), data (A.4.3), tooling (A.4.4), system and computing (A.4.5) and human resources (A.4.6).
The UK-US Guidelines for Secure AI System Development treat models, data, user feedback, prompts, software, documentation, logs and assessments as assets to track and protect.
NIST Special Publication (SP) 800-218A notes that AI models and their components may need to be added to the organization's asset inventories when a release is archived.
Under EU AI Act Article 49, providers register most Annex III high-risk systems in the EU database of Article 71 before placing them on the market, which an internal inventory feeds.
ADG's AI System Profile artifact records each system's architecture, risk classification, autonomy tier, harm classes and deployment pattern.
Exam tip
When asked for the first step of an AI governance program, pick building the AI inventory with named owners. ADG's Foundation phase starts with MC-1, MC-2 and MC-3.
Training data is the recipe a model learns from, so bad or biased ingredients produce a bad model. Data governance sets the rules for where data comes from, how it is checked, cleaned and labeled, and who may use it. For high-risk systems in the EU these rules are law, not just good practice.
diagram
Article 10 and ISO/IEC 42001 A.7 expect every step from acquisition to approval to be documented, so the data set's fitness for its purpose can be shown to an assessor.
Key points
EU AI Act Article 10 governs training, validation and testing data for high-risk systems; after the Digital Omnibus it applies from 2 December 2027 for Annex III systems.
Article 10(2) practices cover design choices, data origin, preparation and assumptions, and must examine and mitigate biases that could harm health, safety or fundamental rights.
Article 10(3) requires the data sets to be relevant, sufficiently representative and, to the best extent possible, free of errors and complete for the intended purpose.
Regulation (EU) 2026/1744, the Digital Omnibus on AI, deleted Article 10(5) and moved the strictly necessary permission to use special category data for bias detection to a new Article 4a.
ISO/IEC 42001 Annex A.7 covers data for AI systems: data for development (A.7.2), acquisition (A.7.3), quality (A.7.4), provenance (A.7.5) and preparation (A.7.6).
ADG (Adopt, Defend, Govern) warns that storage-layer access control is no longer enough, because retrieval and tool connections collapse every source into one text stream.
Data minimisation under General Data Protection Regulation (GDPR) Article 5(1)(c) means personal data must be adequate, relevant and limited to what the purpose needs.
Exam tip
For data questions, look for representativeness, documented origin and bias examination together. An answer that only says to encrypt the training data addresses security, not data governance.
Provenance is the birth certificate of a piece of data: where it came from and who vouched for it. Lineage is its travel diary: every system it passed through and every change made to it. Together they let you trace a strange model output back to the exact data behind it, the way a chain of custody works for evidence.
diagram
A hash recorded at the source and checked at each hop proves the data that trained a model is the data that was approved, and lets any output be traced back to it.
Key points
Provenance records where data originated and who handled it; lineage traces how it moved and changed through the pipeline, so an output can be traced back to its sources.
The multi-agency AI Data Security guidance (May 2025) recommends sourcing from authoritative data, tracking provenance and logging the path data follows through an AI system.
It also recommends checksums or cryptographic hashes for integrity, digital signatures on trusted dataset revisions, and an append-only, cryptographically signed store where feasible.
Split-view poisoning abuses expired domains in curated URL lists; curators should publish hashes of raw data and consumers should discard downloads that fail the hash check.
ADG (Adopt, Defend, Govern) Minimum Control 6 (MC-6), the Context Policy, defines provenance, retention, access restrictions and trust ordering for every context input.
NIST SP 800-218A task PS.3.2 asks developers to track the provenance of a model and its components, for example in a software bill of materials (SBOM).
ADG's data layer includes output attribution, tracing which source documents fed a specific AI output. Supplier and dataset lineage across the supply chain is covered in 3.2.
Exam tip
Provenance answers where data came from, lineage answers what happened to it. For integrity questions, the best answer pairs hashes or signatures with provenance records, not access control alone.
Pin an approved dataset with a hash · bash
# record the hash when the dataset is approved
sha256sum claims-train-2026-10.parquet > claims-train-2026-10.parquet.sha256
# verify before every training run and stop if it changed
sha256sum -c claims-train-2026-10.parquet.sha256 || exit 1
If a model is tampered with or a bad update ships, you need to put back a version you trust, like restoring a laptop from last week's backup. That only works if every model, data set and prompt version was archived, hashed and linked to its approval. Traceability is what turns a backup into a trustworthy recovery point; the wider continuity plan sits in 5.1.
diagram
Recovery depends on traceability: a version is only safe to restore if its hash still matches the approved release record.
Key points
The UK-US Guidelines for Secure AI System Development expect processes to track, authenticate, version control and secure AI assets, and to restore a known good state after compromise.
Deploying AI Systems Securely (2024) recommends hashed, encrypted copies of each model release in a tamper-proof location, with keys in a vault or hardware security module (HSM).
The same guidance recommends automated rollback so a faulty or compromised update can quickly revert to the last known good model.
NIST SP 800-218A task PS.3.1 archives each release with integrity verification and provenance data, plus documentation of the training process and why the model was chosen.
SP 800-218A also suggests securely storing training, testing, fine-tuning and alignment data for future use and reference, so a model can be investigated or rebuilt.
ADG (Adopt, Defend, Govern) treats vector stores and embedding infrastructure as governed data assets that need access control, encryption, backup and recovery.
Link each model version to its data hash, prompt version and approval record, so known good is a documented fact rather than a guess.
Exam tip
The strongest recovery answer restores an integrity-checked, previously approved version. Restoring the latest backup without checking its hash risks reloading a poisoned or tampered model.
A model card is like the nutrition label on a food package: a short, standard summary of what the model is for, how well it works and where it falls short. A datasheet does the same for a data set. For high-risk systems in the EU, the law adds a much fuller technical file that regulators can inspect.
Model card
Intended and out-of-scope uses
Evaluation procedure
Performance by group
Model version
Both
Short standardized documents
Support transparency and accountability
Datasheet for a dataset
Motivation for the data
Composition
Collection process
Recommended uses
A model card describes the trained model and a datasheet describes the data behind it. Both are short, standard documents that support transparency and accountability.
Key points
Model cards are short documents that accompany a trained model, stating intended use, evaluation procedures and performance across relevant demographic and intersectional groups.
Datasheets for datasets document a data set's motivation, composition, collection process and recommended uses, the data-side partner to a model card.
EU AI Act Article 11 requires technical documentation for a high-risk system before it is placed on the market, kept up to date and containing at least the Annex IV elements.
Annex IV covers intended purpose and version history, design choices, architecture, data provenance and datasheets, and the human oversight measures needed.
Providers keep the technical documentation for 10 years after the system is placed on the market or put into service (EU AI Act Article 18).
The Digital Omnibus on AI extended simplified technical documentation from small and medium-sized enterprises (SMEs) to small mid-cap companies.
ISO/IEC 42001 Annex A control A.6.2.7 covers AI system technical documentation, and A.6.2.8 covers recording of event logs.
Exam tip
Match the artifact to the audience: a model card informs users and deployers, a datasheet describes data, and Annex IV technical documentation proves conformity to authorities.
Minimal model card (example) · json
{
"model": "contoso-churn-predictor",
"version": "2.3.0",
"intendedUse": "Rank retention offers. Not for credit or employment decisions.",
"trainingData": "Datasheet DS-118, sha256 pinned",
"metrics": {"auc": 0.87, "aucLowestGroup": 0.82},
"limitations": "Not validated for customers under 18",
"owner": "ml-platform@example.com",
"approvedBy": "Model Risk Committee, 2026-10-02"
}
A model registry is the official catalogue of model versions, like a library that records every edition of a book, who checked it and which edition is on the shelf. Governance adds rules: an independent reviewer must sign off before a version is promoted, and every change is logged. That way you always know exactly which model is answering customers today.
diagram
The registry is the hand-off point: the developer registers, an independent validator tests, governance approves, and the previous version stays available for rollback.
Key points
SR 26-2, the US banking model risk guidance that replaced SR 11-7 in April 2026, expects a model inventory detailed enough to understand model risk individually and in aggregate.
EU AI Act Annex IV asks for the system's version and its relation to previous versions, so a registry should keep the full version history, not just the current model.
ISO/IEC 42001 Annex A covers verification and validation (A.6.2.4), deployment (A.6.2.5) and operation and monitoring (A.6.2.6), the gates a registry records.
ADG (Adopt, Defend, Govern) Minimum Control 3 (MC-3) separates deployment ownership, security validation and approval authority, so a model's builder cannot also approve its release.
The NIST AI Risk Management Framework (AI RMF) calls it best practice to separate those who build and use models from those who verify and validate them.
ADG's Model and Prompt Change Log records every change to models, prompts and configurations with approval records, the evidence for Minimum Control 5 (MC-5).
AI RMF MANAGE 3.2 requires pre-trained models used in development to be monitored as part of regular monitoring and maintenance, so third-party base models belong in the registry.
Exam tip
A registry is governance only if promotion to production needs an independent approval recorded against the exact version. A shared folder of model files is the distractor.