Governing AI models with model cards, approvals and audit trails means documenting each model's intended use, training data, performance limitations and known risks, then routing every model through a formal review before it reaches production and logging every decision made about it afterward. A model card is a structured document, following the format popularized by Google's original model cards paper, that records training data sources, evaluation metrics across relevant subgroups, intended and out-of-scope use cases, and known failure modes, giving reviewers and auditors a single reference instead of scattered tribal knowledge. Approval workflows should require sign-off from a technical reviewer, who checks evaluation results and testing coverage, and a risk or compliance reviewer, who checks the model card for use cases triggering elevated obligations, particularly high-risk categories under frameworks like the EU AI Act. Audit trails need to capture who approved a version, what evaluation results justified it, and every later change to the model, prompt or configuration, stored so it cannot be quietly edited after the fact. Governance tooling built into MLflow's model registry, or a dedicated platform, can enforce these gates automatically rather than relying on a checklist someone might skip. Nanobase AI implements model card templates and approval gates so every deployed model has a documented, auditable history.
A model card section by section, with example content
A model card is only useful with specific, checkable content, not generic boilerplate. The table below shows what each section should contain, for a hypothetical claims-triage model.
| Section | What it documents | Example content |
|---|---|---|
| Intended use | The specific use case and user | Route auto claims to the correct adjuster queue by estimated severity |
| Out-of-scope use | Uses the card explicitly disclaims | Not validated for coverage denial or fraud determination |
| Training data summary | Sources, date range, size, exclusions | 142,000 claims from 2021-2025, excluding claims under litigation |
| Evaluation by subgroup | Metrics broken out, not aggregated | Precision and recall reported separately by claim type and region |
| Known limitations | Where the model is expected to fail | Degrades on claim types introduced after the training cutoff |
| Owner and review date | Accountable person and last review | Claims analytics lead; last reviewed: recorded quarter |
A model card without subgroup-level evaluation and a named owner is a description, not a governance document, since no one can be held accountable to it.
An end-to-end governance workflow with named gate owners
- Submission: the developer packages the card, evaluation report and data references; owned by the engineering lead.
- Technical review: an independent reviewer checks methodology, test coverage and reproducibility; owned by a review board.
- Risk and compliance review: checks intended use against regulated categories, such as EU AI Act high-risk classifications, and confirms data sourcing meets privacy obligations; owned by a compliance officer.
- Approval: a formal sign-off is recorded against the card version, with any conditions attached; owned by a governance committee.
- Deployment: the model is deployed tagged with a version identifier linking to its card; owned by MLOps.
- Periodic re-review: a reassessment, typically every six to twelve months or on material drift, re-runs the checks; owned jointly by the reviewer and owner.
Naming an owner for each gate, not just a process step, is what prevents a review from becoming a form nobody is accountable for completing.
What triggers a review outside the normal schedule
- Detected drift in input data or model performance beyond an established threshold.
- A new regulation or compliance deadline that newly applies to the model's use case.
- A customer complaint or internal incident tied to a specific decision.
- An upstream data source change, or a provider update that changes a hosted model's behavior.
Common governance failure modes
The most common failure is a card written once at approval and never updated as the model evolves, so the document no longer describes what is running. A close second is a review lacking genuine independence, where the team that built the model signs off on its own review. A third is a broken link between the approved card and the version deployed, letting a change reach production unreviewed.
Governance tooling only prevents these failures if the registry enforces the link between an approved card and a deployable model, rather than trusting it to be maintained manually.
Governance for a small team without a full compliance function
A small team does not need a dedicated GRC platform to run this credibly. A shared card template, a review group of two or three people, and a registry tag connecting each deployed model to its card gets most of the benefit. What matters is that no model reaches production without a reviewer who did not build it signing off, and that record stays tamper-evident.
Frequently asked questions
Who should write the initial model card?
The engineer or data scientist who built the model should draft the card, since they know the training data and results directly. It should then be reviewed and corrected by an independent reviewer before it is treated as accurate, since self-reported documents tend to understate limitations.
How detailed does a model card need to be for a low-risk internal tool?
A lower-risk tool still benefits from the core sections, intended use, training data summary and known limitations, but can use a lighter review with fewer sign-offs. Review depth should scale with the impact of a wrong decision, not apply uniformly regardless of stakes.
What happens if a model fails its risk or compliance review?
It is either sent back for changes, such as retraining on more representative data or narrowing its intended use, or blocked from deployment if the use case falls into an unsupported category. The rejection and reasoning should be recorded in the same audit trail as an approval.
Does every model update require a full re-review?
Not necessarily. A minor update, such as a scheduled retrain with no change to intended use, typically needs lighter re-verification against existing thresholds. A material change, such as a new data source or a significant shift in results, should trigger the full review path.
How Nanobase AI helps
Nanobase AI implements model card templates and approval workflows with named reviewers at each gate, tied to registry tags linking every deployed model to its approved documentation. For clients under EU AI Act, GDPR or KVKK obligations, we build the compliance review around the regulatory categories that apply, and connect the audit trail to the data lineage that shows what fed the model.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.