Governance and Model Cards

Governance is the documentation and process that lets someone who did not build a model decide whether to approve it, audit it, or turn it off. Model cards carry that information, and a registry that enforces the card at approval time is what makes governance real rather than aspirational. Without enforcement, a card is a paragraph nobody reads after launch.

The idea

A model card records the facts a reviewer needs:

• Intended use and, more importantly, out-of-scope uses. Most harm comes from the second category.
• Training data: source, collection method, time window, and known gaps in coverage.
• Evaluation: overall metrics plus results by meaningful slice, with the slices named.
• Limitations and known failure modes, stated plainly.
• Fairness considerations for decisions that affect people, with the chosen definition of fairness stated explicitly, because definitions conflict and cannot all hold at once.
• Ownership: the accountable person and team, not just the team alias.
• Lineage: code commit, data version, and hyperparameters for the exact artifact.

Governance machinery sits around the card: a model registry with approval states, review gates tied to a risk tier, and an audit trail of who changed what and when. Tier by impact on people — a spam filter and a credit decision should not pass through the same process. Decisions about credit, employment, health, or access to services warrant the full review; internal ranking experiments rarely do. Sector rules and frameworks such as the EU AI Act add documentation and traceability expectations, so the card should be built to be produced on request rather than assembled after the fact.

Cards go stale. Version them with the model and generate them from the training pipeline so the numbers in the card come from the run that produced the artifact, not from a document someone edited by hand.

Worked example

A pipeline emits the card as part of every training run, pulling each field from a source that already exists:

The registry refuses promotion when required fields are missing, so "we will document it next sprint" cannot ship a model. The reviewer reads a card that matches the artifact, and the audit trail shows the approval.

Check yourself

1. Who is a model card written for, and what decision does it support?
2. Why should a card be generated by the pipeline instead of written by hand at launch?
3. How should risk tiering change the amount of governance process a model receives?

Key takeaways

• A card is governance only when a registry enforces it at approval time.
• Document intended use and out-of-scope use; most harms come from the second.
• Match process to risk tier, and regenerate documentation for every version.