Why Your Model Card Is the First Thing an Auditor Will Ask For.

What Is a Model Card

A model card is a structured document that describes an AI system - its intended use, training data characteristics, known limitations, performance benchmarks, and evaluation results.

The concept was introduced by Google researchers in 2018. It has since become the standard format for AI system documentation and is now referenced directly in regulatory frameworks.

What ISO 42001 Requires

ISO 42001:2024 Clause 6.4 requires organisations to determine and document information about AI system design and intended use. This includes:

• •The intended purpose and context of use
• •Known limitations and failure modes
• •Training data sources and characteristics
• •Performance metrics and evaluation methodology
• •Who the system is designed to serve and who it may affect

This is not a suggestion. It is a documented information requirement that auditors will verify.

Why Auditors Ask for It First

When an AI system is under review - whether by a regulatory auditor, an enterprise procurement team, or an investor conducting due diligence - the model card is the first document requested.

It tells the reviewer three things immediately:

First, whether the organisation understands what their AI system actually does. Teams that cannot produce a model card often discover that the system is doing things they did not intend.

Second, whether the organisation has thought about who the system affects and how. This maps directly to EU AI Act risk classification.

Third, whether the organisation has a documentation culture around AI. A missing model card is a signal that other documentation is likely also missing.

What Most Teams Have Instead

Most teams have model documentation scattered across Notion pages, Confluence wikis, Slack threads, and the memory of the engineer who built it.

This is not the same as a model card. In a regulatory context, undocumented knowledge does not exist.

The Minimum Viable Model Card

Based on ISO 42001 requirements and regulatory guidance, a minimum viable model card should contain:

• •Model name and version
• •Intended use cases
• •Out-of-scope use cases
• •Training data description
• •Evaluation methodology and results
• •Known limitations and failure modes
• •Affected populations
• •Last review date

One page is sufficient if it covers these elements. The goal is not comprehensiveness - it is defensibility.