AI Governance Engineer
GitHub
On this page

Pattern: Model Card as Control Evidence

Model and data cards regenerated from the pipeline as structured evidence, so transparency documents describe the system as it runs today.

Layer 02 · Inventory & Transparency In the chapter 05 catalogue

One working control on the engineering side of AI governance.

Summary: Treat the model card and data card not as launch documentation written once, but as structured evidence regenerated from the pipeline, so that transparency documents describe the system as it is now and feed the assurance layer.

Model Card as Evidence A workflow diagram generated by Archify. 01 / Layer 02 Inventory & Transparency 02 / Evidence EX / Rejected Generate from outputs Validate at the gate Cite as evidence Training & eval outputs · scores, datasets · Layer 02 Inventory & Transparency › Generate from outputs Training & eval outputs scores, datasets Model card · generated, structured · Layer 02 Inventory & Transparency › Generate from outputs Model card generated, structured Schema check · valid / invalid · Layer 02 Inventory & Transparency › Validate at the gate Schema check valid / invalid Attached to release · versioned · Layer 02 Inventory & Transparency › Validate at the gate Attached to release versioned Evidence record · read by assurance · Evidence › Cite as evidence Evidence record read by assurance Rejected · not attached · Rejected › Validate at the gate Rejected not attached validate invalid valid generate cite Legend Agent logic Policy Context / trace
Model Card as EvidenceThe model card is generated from real training and eval outputs, checked against a schema at one gate, and attached to the release as control evidence. A hand-written card is documentation; a generated, validated one is a control. Generated from the Body of Knowledge.Open interactive diagram (opens in a new tab)

Objectives

Convert transparency documentation from a static PDF into a versioned artefact that is both human-readable and machine-consumable, and that counts as control evidence.

Target users

AI governance engineer, ML engineer, DPO.

Impacted stakeholders

Model owners, users, auditors, data subjects.

Relevant principles

Instrument the build to produce its own proof; make the governed path the easiest path.

Context

A system subject to transparency obligations, where cards are traditionally written at launch and never touched again.

Problem

A model card written once decays into fiction as the model, prompts and datasets change. A card that is not regenerated cannot be trusted as evidence and misleads the very auditor it was meant to satisfy.

Solution

Template the card and populate it from the pipeline: intended use, evaluation results (from the Eval Gate), datasets (from the AIBOM), known limitations and owner. Regenerate on each significant change and version it with the model. Store the card as structured data so it can be both read by a person and consumed by the assurance layer.

Consequences

Transparency stays true and doubles as evidence. The cost is templating and pipeline wiring, and agreeing what “significant change” triggers a regeneration.

AIBOM; Eval Gate in CI; Machine-Readable Evidence (OSCAL); FRIA-as-Code.

Maps to: EU AI Act Art. 11, Art. 13 (transparency) · ISO/IEC 42001, ISO/IEC 42005 · NIST AI RMF (Map, Measure) · Layer 02 Inventory & Transparency.

Function labels follow the NIST AI RMF1. Mappings are illustrative, not a claim of conformity.

Sources

  1. [1] AI Risk Management Framework (AI RMF 1.0; Govern, Map, Measure, Manage). NIST. 2023-01-26. https://www.nist.gov/itl/ai-risk-management-framework (verified: primary)
Edit this page on GitHub
Cite this pattern

García Aibar, J. (2026). Pattern: Model Card as Control Evidence. In AI Governance Engineering: The Thesis & Body of Knowledge (v0.5.0), chapter 05, Patterns. https://doi.org/10.5281/zenodo.22956197. https://aigovernanceengineer.com/patterns/model-card-as-control-evidence. CC BY 4.0

BibTeX

@misc{aige2026bok,
  author  = {Jorge García Aibar},
  title   = {{AI Governance Engineering: The Thesis \& Body of Knowledge}},
  chapter = {05. Patterns: Model Card as Control Evidence},
  year    = {2026},
  version = {0.5.0},
  doi     = {10.5281/zenodo.22956197},
  url     = {https://aigovernanceengineer.com/patterns/model-card-as-control-evidence},
  note    = {Version 0.5.0}
}
Share on LinkedIn
Around Model Card as Control EvidenceThe patterns Model Card as Control Evidence is listed with, and the obligations, open controls and incident cases that name it.Names this patternRelated patternColour: stack layer of the related pattern01 Govern-as-Code02 Inventory03 Evals05 AssuranceModel Card as Control EvidenceRelated patterns (4)AIBOM · Related patternAIBOMEval Gate in CI · Related patternEval Gate in CIFRIA-as-Code · Related patternFRIA-as-CodeMachine-Readable Evidence (OSCAL) · Related patternMachine-Readable EvidenceObligations (5)EU AI Act Art. 11: technical documentation (Annex IV) · Names this patternEU AI Act Art. 11EU AI Act Art. 13: transparency and information to deployers · Names this patternEU AI Act Art. 13ISO/IEC 42005:2025: guidance for AI system impact assessment · Names this patternISO/IEC 42005:2025NIST AI RMF MAP · Names this patternNIST AI RMF MAPNIST AI RMF MEASURE · Names this patternNIST AI RMF MEASUREControls (1)AIGE-CTL-DATA-002 Dataset Card for Every Admitted Version · Names this patternDataset Card for Every Admitted…Cases (3)A health-risk score that predicted cost, not need · Names this patternHealth-risk scoreA recruiting model that learned the past (reported) · Names this patternRecruiting model (reported)SyRI: a fraud risk model no court could verify · Names this patternSyRI judgmentSource: the pattern catalogue, theobligation register, the opencontrols and the cases
Around Model Card as Control EvidenceThe patterns Model Card as Control Evidence is listed with, and the obligations, open controls and incident cases that name it.Names this patternRelated patternColour: stack layer of the related pattern01 Govern-as-Code02 Inventory03 Evals05 AssuranceRelated patterns (4)AIBOM · Related patternAIBOMEval Gate in CI · Related patternEval Gate in CIFRIA-as-Code · Related patternFRIA-as-CodeMachine-Readable Evidence (OSCAL) · Related patternMachine-Readable…Controls (1)AIGE-CTL-DATA-002 Dataset Card for Every Admitted Version · Names this patternDataset Card for Every…Cases (3)A health-risk score that predicted cost, not need · Names this patternHealth-risk scoreA recruiting model that learned the past (reported) · Names this patternRecruiting model (reported)SyRI: a fraud risk model no court could verify · Names this patternSyRI judgmentObligations (5)EU AI Act Art. 11: technical documentation (Annex IV) · Names this patternEU AI Act Art. 11EU AI Act Art. 13: transparency and information to deployers · Names this patternEU AI Act Art. 13ISO/IEC 42005:2025: guidance for AI system impact assessment · Names this patternISO/IEC 42005:2025NIST AI RMF MAP · Names this patternNIST AI RMF MAPNIST AI RMF MEASURE · Names this patternNIST AI RMF MEASUREModel Card asControl EvidenceSource: the pattern catalogue, the obligation register, the open controls and thecases
Around Model Card as Control Evidence The patterns listed with this one, in their layer colour, and the obligations, open controls and incident cases that name it. Follow a node to see why the pattern is worth building, and what to build with it.
Data table
What Model Card as Control Evidence connects to
FamilyItemRelation
Related patternsAIBOMRelated pattern
Related patternsEval Gate in CIRelated pattern
Related patternsFRIA-as-CodeRelated pattern
Related patternsMachine-Readable Evidence (OSCAL)Related pattern
ObligationsEU AI Act Art. 11: technical documentation (Annex IV)Names this pattern
ObligationsEU AI Act Art. 13: transparency and information to deployersNames this pattern
ObligationsISO/IEC 42005:2025: guidance for AI system impact assessmentNames this pattern
ObligationsNIST AI RMF MAPNames this pattern
ObligationsNIST AI RMF MEASURENames this pattern
ControlsAIGE-CTL-DATA-002 Dataset Card for Every Admitted VersionNames this pattern
CasesA health-risk score that predicted cost, not needNames this pattern
CasesA recruiting model that learned the past (reported)Names this pattern
CasesSyRI: a fraud risk model no court could verifyNames this pattern

Obligations this pattern evidences

Register rows that list this pattern among the patterns that build their evidence. Mappings are illustrative, not a claim of conformity.

When these obligations applyThe obligations Model Card as Control Evidence evidences, on the dates they first apply and on their later steps, against the register's review date.First appliesDeferredLater stepAheadAs of 2026-09-242still to come2027-12-022028-08-022030-08-02EU AI Act Art. 11 · applies from 2027-12-02 · DeferredArt. 11EU AI Act Art. 13 · applies from 2027-12-02 · DeferredArt. 13Art. 11Art. 13Art. 11Art. 133 without a date (Voluntary)Source: the obligation register(/obligations)As of 2026-09-24
When these obligations applyThe obligations Model Card as Control Evidence evidences, on the dates they first apply and on their later steps, against the register's review date.First appliesDeferredLater stepAheadDateits place on the time axis2still to come2026202720282029203020312027-12-022028-08-022030-08-02EU AI Act Art. 11 · applies from 2027-12-02 · DeferredArt. 11EU AI Act Art. 13 · applies from 2027-12-02 · DeferredArt. 13Art. 11Art. 13Art. 11Art. 13As of 2026-09-243 without a date (Voluntary)Source: the obligation register (/obligations)As of 2026-09-24
When these obligations apply Each obligation this pattern evidences, on the date it first applies, drawn by its status in the register, and on each later dated step (a square, filled once reached); the dashed line is the date the rows were last reviewed. What comes before the line is already due, so the pattern's evidence is needed now; what comes after it sets the deadline to build it by.
Data table
When the obligations Model Card as Control Evidence evidences apply
DateObligationStepStatus
2027-12-02EU AI Act Art. 11: technical documentation (Annex IV)Applies fromDeferred
2027-12-02EU AI Act Art. 13: transparency and information to deployersApplies fromDeferred
2028-08-02EU AI Act Art. 11: technical documentation (Annex IV)Later step: Applies to Annex I embedded (product safety-component) systemsDeferred
2028-08-02EU AI Act Art. 13: transparency and information to deployersLater step: Applies to Annex I embedded (product safety-component) systemsDeferred
2030-08-02EU AI Act Art. 11: technical documentation (Annex IV)Later step: Deadline for legacy high-risk systems intended for use by public authorities (Art. 111(2))Deferred
2030-08-02EU AI Act Art. 13: transparency and information to deployersLater step: Deadline for legacy high-risk systems intended for use by public authorities (Art. 111(2))Deferred
No dateISO/IEC 42005:2025: guidance for AI system impact assessmentVoluntary
No dateNIST AI RMF MAPVoluntary
No dateNIST AI RMF MEASUREVoluntary

Cases where it applies

Incident post-mortems that name this pattern as a control that would have caught the failure.

Draft controls in the open control profiles that build on this pattern. A control states the requirement and the evidence it must leave behind.