Govern
Model Transparency Cards
How was this system built and tested?
Documents a system's purpose, data, performance, and limits in a form non-engineers can actually use.
- Evidence: research-based (Mitchell et al. 2019, Gebru et al. 2018)
- Tested: concept only, mock data
Overview
Why it matters
Every AI system is a set of choices. Most people never see them.
What a system was trained to do, on which data, how it was tested, where it works and where it fails: these choices are made by developers and rarely reach the people using it or affected by it.
A transparency card is the reference document that runtime patterns like Model Scope & Limits link to. It's not documentation for engineers. It's disclosure for everyone else.
What does it look like?
User wanting to understand the system
User wanting to understand the system
- User sees AI badge on a decision interface.
- Clicks "About this system."
- Compact summary card appears: what the system does, who built it, what it's designed for.
- User clicks "Full transparency documentation" for the complete card.
Regulator conducting a compliance review
Regulator conducting a compliance review
- Regulator requests documentation for an AI system used in benefit decisions.
- Organization provides the transparency card: structured document covering training data, evaluation, fairness metrics, governance.
- Regulator reviews performance metrics across demographic groups.
- Regulator identifies a disparity in performance for one group: raises with organization.
Operator evaluating a new deployment context
Operator evaluating a new deployment context
- Product team considers deploying a fraud detection model in a new market.
- Team reviews the model transparency card.
- Sees: training data was collected primarily from the existing market. Fairness section notes lower accuracy for new-to-credit users.
- Decision: commission local validation study before deployment. New findings will update the card.
When does it fit?
Use it when
- An AI system affects people's rights, access or significant interests
- Regulation requires technical documentation
- Users, affected people or regulators need a reference
Skip it when
- The card would be so thin it misleads
- Some details are security-sensitive: say what's withheld and why, but still publish the card
Design
How do I apply it?
-
Write for the people affected.
If it needs ML expertise to read, it's technical documentation with the wrong label.
-
Be specific about limits.
"Not validated for self-employed applicants" beats "may have limitations".
-
Break performance down.
One overall accuracy figure hides differences between groups.
-
Keep it current.
A card for version 1 on a system now at version 3 is misleading.
-
Link it from the interface.
People shouldn't have to search for it.
How can I show it?
Version indicator
Version number and last update on the card.
A visible version number and "last updated" date on the card. Users and auditors need to know whether the card reflects the current version of the system.
Plain-language summary section
Key answers in plain words, before any detail.
A non-technical summary at the top of the card, placed before any technical detail, that answers the key questions a non-expert might have.
Summary card (compact view)
The essential facts on one screen.
A brief, scannable overview of the system: designed for users who need the key facts quickly: - System name and version - What it does (one sentence) - What it is designed for (intended use) - What it is not designed for - Who is responsible - Last updated
Linked in-context disclosure
Links from the interface wherever limits appear.
The transparency card is not just a standalone document: it is linked from the runtime interface wherever scope, limitations, or governance information is surfaced. "For more about this system's limitations → [Model Transparency Card]."
Full transparency card (expanded view)
The complete card: purpose, data, performance, limits.
A structured document covering: - System overview: what it does and how - Intended use: specific use cases and contexts it was designed for - Out-of-scope use: uses that are not appropriate and why - Training data: what kind of data, from what time period, from what sources - Evaluation: how performance was measured, on what populations - Performance: key metrics, including disaggregated metrics by demographic group where relevant - Known limitations: specific failure modes, edge cases, underperforming contexts - Fairness: known disparities in performance across groups and what was done about them - Governance: who is responsible, how to contact them, how to report issues - Version history: when changes were made and what changed
What does it cost?
Completeness vs. readability
A complete card runs to pages. Summary at the top, detail on request.
Transparency vs. business secrets
Disclose as much as possible, and say explicitly what isn't disclosed and why.
Accuracy vs. liability
Published figures create accountability. That's the point of transparency.
Connections
Which patterns work with it?
Model Scope & Limits
What can this system reliably do?
Scope & Limits surfaces the key scope information at runtime. Model Transparency Cards provide the complete documentation. The runtime pattern links to the card.
Data Provenance & Lineage
Where does this data come from?
The training data section of the transparency card is the complete version of what provenance surfacing shows in the runtime interface.
Ethical & Fairness Signals
Is this system fair across groups?
Fairness metrics belong in the transparency card. Runtime fairness signals point to the card for full documentation.
AI Presence Disclosure
Am I interacting with an AI?
Disclosure says AI is involved. The transparency card says what that AI is. Both are needed.
Sources (4)
Sources (4)
Mitchell et al. (2019) — Model Cards for Model Reporting
the foundational paper proposing model cards as a standard format for AI system documentation. The direct origin of this pattern
Gebru et al. (2018) — Datasheets for Datasets
proposes the same documentation-first approach for training datasets. Together with model cards, establishes the documentation layer of AI transparency
European Union (2024) — EU AI Act. Annex IV
specifies the technical documentation requirements for high-risk AI systems, which largely correspond to the content of model transparency cards. The regulatory specification this pattern implements
Raji et al. (2020) — Closing the AI Accountability Gap
argues that documentation is necessary but not sufficient for accountability: it must be paired with genuine audit mechanisms. Model cards are a starting point, not an endpoint
You have to show what your AI system does, for whom, and where it fails.
In procurement or to a regulator. That's where this pattern starts. Let's look at your documentation together.
Work with me