When an AI system rejects your loan application, flags your medical scan as abnormal, or screens your CV before a human ever sees it, the obvious question is: what is this thing basing its decision on?
In most organisations, nobody has a clear answer. The engineers have moved to the next project. The documentation, if it exists, is scattered across a data scientist’s notebook and three Slack threads from 2022.
That’s an expensive problem. It exposes organisations to regulatory penalties, reputational damage from biased outputs, and audit liability when they can’t demonstrate that they understood the systems they deployed.
The AI model card is built to fix that.
It’s a structured document that travels with an AI model and answers the questions that executives, compliance officers, product managers, and regulators need answered: what does this model do, how was it built, where does it perform well, and where does it fail?
The goal is AI transparency: making the decision-making logic of complex artificial intelligence systems legible to the people responsible for deploying and governing them.
What a model card actually is
An AI model card is a standardised disclosure document attached to a machine learning model. It summarises the base model’s purpose, training data, performance across different groups, and known limitations in accessible language.
Think of it as a technical passport for an AI system.
A pharmaceutical product comes with a documented list of ingredients, clinical trial results, contraindications, and approved use cases.
A well-built model card provides equivalent transparency for a machine learning model, including when not to use it and which populations it wasn’t tested on.
That second part, the disclosure of limitations and out-of-scope applications, is what separates responsible AI documentation from marketing copy.
The term covers several related document types:
- An ML model card focuses on a single trained model.
- A system card documents an entire AI system made up of multiple chained ML models.
- A data card documents the dataset used for training.
Mature AI programmes maintain all three, because each answers a different question in the audit chain.
Where the model card concept came from
The standardised AI model card traces back to pioneering 2018 research by Margaret Mitchell, Timnit Gebru, and their colleagues.
Mitchell et al. identified that AI development had a structural documentation problem: engineers understood their models deeply, but that understanding disappeared when models shipped to production or moved to new teams.
Their proposed framework, the foundation for what practitioners now call the model card guidebook, required AI developers to document a model’s intended use case, training data, performance across demographic groups, and known limitations.
It was designed to scale from internal peer review to public disclosure, making responsible AI a structural requirement rather than a personal virtue.
What goes inside a model card
A comprehensive AI model card covers six standard areas. These components appear in any serious model documentation.
| Section | What it covers |
|---|---|
| Model details | Name, model version, model architecture, license, release date |
| Intended use | Primary intended use case, target users, out-of-scope applications |
| Training data | Dataset sources, data card references, demographic composition |
| Model performance and metrics | Quantitative analyses across benchmarks and subgroups |
| Bias and fairness | Tests performed, identified limitations, mitigation steps |
| Risk management | Safety constraints, failure modes, security considerations |
Model details contains the key information that identifies the model unambiguously: the model version, the underlying model architecture (such as a transformer or a convolutional neural network), the licensing terms, and who developed it. If a vendor can’t provide this section satisfactorily, flag that detail as an early warning signal.
Intended use is where most AI deployment problems start. It specifies the exact context and population the model was validated for. A machine learning model trained on chest X-rays from adult patients in UK teaching hospitals isn’t validated for paediatric patients in rural clinics. A clear intended use case makes that boundary explicit before deployment, not after an incident.
Training data documents data sources, collection methods, and known biases in the dataset. Organisations that need stronger audit trails often pair the AI model card with a separate data card that documents data provenance independently of model reporting.
Model performance and metrics is where AI documentation most often misleads people. A single aggregate accuracy number tells you almost nothing useful. Responsible model reporting shows quantitative analyses broken down by subgroup. A credit-scoring model might perform well on average but significantly underperform for specific demographic groups. You want that disparity declared up front.
Bias and fairness documents what tests the team ran, what they found, and what steps they took to mitigate the problem. It should also disclose what they didn’t test. For non-technical leaders, this section answers one question: did this team take fairness seriously, and can they prove it?
Risk management documents failure modes and what the model does when it encounters inputs it wasn’t trained on. It should clearly state what the model should not be used for. These aren’t just ethical guidelines, but legal guardrails that protect your organisation if a downstream user misapplies the tool.
Compliance: the EU AI Act and the NIST AI RMF
Regulatory requirements around AI model documentation are no longer theoretical. The EU AI Act mandates technical documentation for high-risk AI systems across any organisation deploying artificial intelligence that affects people within the EU.
The NIST AI RMF (Risk Management Framework), published by the US National Institute of Standards and Technology, requires organisations to document intended use, known risks, and performance characteristics as part of a formal AI governance programme.
The required fields in both frameworks map almost directly onto a comprehensive model card. Organisations that build model cards satisfying both from the start find their regulatory audit burden significantly lower.
When a notified body or external auditor arrives, your AI documentation becomes the primary evidence repository.
A well-constructed ML model card reduces audit time by giving auditors a structured view of the system’s risk profile rather than requiring them to reconstruct it from scattered internal sources—a scenario that can produce compliance failures and expensive legal exposure.
How to build a model card
Model card creation doesn’t require a data scientist, but you need a clear process and the right tools.
Choose your format
Markdown is the most common format for human-readable technical documentation. JSON and YAML work better for machine-readable AI documentation that integrates into automated deployment pipelines. Most teams start with a Markdown template stored in the same version control repository as the model.
Use an established model card toolkit
The Hugging Face Hub has built model card support directly into its platform, with a standardised README.md format, metadata headers, and evaluation widgets. Google’s Model Card Toolkit provides a programmatic approach that generates cards from structured data. Both are reliable starting points for AI developers building their first cards.
Version your cards alongside your models
A model card that doesn’t match the current model version is worse than no card. Every time you update the base model or retrain on new data, update the card. Platforms like Amazon SageMaker can automate this by linking the card to the model registry and refreshing it as new evaluations run.
Write for the right audience
A model card that only an ML engineer can parse has failed its purpose. Include plain-language summaries of the intended use, the key limitations, and the relevant fairness considerations. Relevant information buried in technical notation isn’t accessible—and that can have repercussions.
The goal of an AI model card is to give every stakeholder, from the procurement lead to the compliance director, the full picture they need to make an informed decision.
Where all this is heading
As AI systems grow more complex, individual ML models are being chained together into larger agentic systems where each component handles a different task. A single-model ML model card can’t document the emergent behaviour of that kind of architecture.
The system card is the next evolution of AI model cards, and it’s where regulatory frameworks like the EU AI Act’s provisions for general-purpose AI models are already pointing.
Organisations that build strong model documentation habits now will adapt to that expansion far better than those starting from scratch when the auditors arrive.
Mo is the founder of Column, a technical research and content agency. Connect with him on LinkedIn.
