AI/ML Model Cards: What the EU AI Act Requires for GPAI Documentation in 2026

Why model cards matter now

The EU AI Act's General Purpose AI (GPAI) obligations under Article 53 became directly applicable in August 2025. If you develop or deploy an AI system — whether a chatbot, a classification model, a content generation tool, or an API — you are now operating in a regulated environment. And regulators, enterprise customers, and auditors are increasingly asking: "Where's your model card?"

A model card is a structured document that describes your AI system's capabilities, limitations, intended use cases, training data, evaluation results, and safety measures. It is simultaneously a transparency tool for users, technical documentation for regulators, and an internal accountability mechanism for your team.

This guide explains what the EU AI Act requires, what a good model card contains, and how to create one.

The EU AI Act GPAI framework: a quick summary

The EU AI Act (Regulation (EU) 2024/1689) introduces specific obligations for General Purpose AI (GPAI) models — AI models trained on large amounts of data that can perform a wide range of tasks, typically released via APIs or integrated into products.

Key definitions:

GPAI model (Art. 3(63)): An AI model trained with a large amount of data using self-supervision at scale, displaying significant generality and capable of competently performing a wide range of distinct tasks.
Provider (Art. 3(3)): A natural or legal person that develops a GPAI model and places it on the market under their own name or trademark.
Deployer (Art. 3(4)): A natural or legal person using an AI system in a professional context.

The GPAI obligations in Art. 53 apply to providers of GPAI models and require:

Draw up and keep up-to-date technical documentation (Annex XI / Annex XII)
Provide information and documentation to downstream providers integrating the GPAI model
Put in place a copyright compliance policy (Art. 53(1)(c))
Publish a summary of the training data used for copyright purposes (Art. 53(1)(d))

If you are a downstream deployer using a third-party GPAI model (OpenAI, Anthropic, Mistral, etc.) rather than developing your own, many of these obligations fall on the GPAI provider. However, you still have obligations when deploying the system (Art. 50 transparency for chatbots and synthetic media, and the full set of obligations if your use case is high-risk).

What is a model card?

The term "model card" was coined by researchers at Google in 2018 as a framework for transparent, responsible AI documentation. The concept has since been adopted across the industry and has now been effectively codified into law by the EU AI Act's Annex XI/XII technical documentation requirements.

A model card covers:

Model identity: Name, version, provider, release date
Intended use cases: What the model is designed to do
Out-of-scope uses: What the model must not be used for
Architecture and capabilities: What the model can do technically
Training data: What data was used, when, from where
Evaluation results: Benchmarks, performance metrics, known limitations
Bias and fairness: What biases were identified and how they were addressed
Safety measures: What controls are in place
Human oversight: What level of human review is in place

EU AI Act Art. 53: What the technical documentation must contain

Annex XI of the EU AI Act specifies the technical documentation that GPAI model providers must prepare. At a minimum, it must include:

Documentation Area	Required Content	Relevance
General description	Intended tasks, types of content generated, release date, version history	All GPAI models
Training process	Training methodologies, key design choices, compute used, energy consumption	All GPAI models (compute info for systemic risk assessment)
Training data	Training data sources, data volumes, data cutoff dates, copyright compliance approach	All GPAI models — also required in public summary (Art. 53(1)(d))
Model architecture	Number of parameters, model size, key architecture decisions	All GPAI models
Capabilities and limitations	Performance benchmarks, known limitations, foreseeable risks, misuse potential	All GPAI models
Safety testing	Evaluation results, adversarial testing, red-teaming, safety measures	All GPAI models; expanded for systemic risk models
Copyright policy	Policy for complying with EU copyright law, approach to rights reservation	All GPAI models (Art. 53(1)(c))
Information for downstream providers	Documentation and information to be provided to deployers integrating the model	All GPAI models

Annex XII specifies what must be included in the public summary of training data that all GPAI providers must publish under Art. 53(1)(d).

Systemic risk models (Art. 51): additional requirements

GPAI models that were trained using more than 10²⁵ FLOPs (floating-point operations) are presumed to present systemic risks and face additional obligations under Art. 51-55:

Conduct model evaluations, including adversarial testing
Assess and mitigate possible systemic risks at EU level
Track, document, and report to the EU AI Office any serious incidents and corrective measures
Ensure an adequate level of cybersecurity protection for the model, its training infrastructure, and inference services
Report compute used for training to the EU AI Office

This currently applies to the largest foundation models: GPT-4-class models, Claude 3-class models, Gemini 1.5-class models, and equivalents. Most SaaS founders building on top of these models rather than training from scratch are not the GPAI model provider — OpenAI, Anthropic, and Google are. But if you are fine-tuning at scale or building your own foundation model, you need to check.

Open-source GPAI models: reduced obligations

Art. 53(2) provides reduced obligations for GPAI models released under a free and open-source licence (permitting access, use, modification, and distribution of the model weights). Open-source GPAI providers must still comply with the copyright policy requirement (Art. 53(1)(c)) and publish the training data summary (Art. 53(1)(d)) — but are exempted from the broader technical documentation requirements, unless the model presents systemic risks.

This is why Mistral, Meta (LLaMA), and Falcon have slightly different obligations than OpenAI or Anthropic.

What goes in a good model card: section by section

1. Model overview and identity

Start with the basics: who made it, when, what version, what it does. Be clear about the intended purpose in plain language. A model card that requires specialist knowledge to understand has failed its purpose.

2. Risk classification and EU AI Act status

State explicitly: is this a GPAI model, a high-risk system, a limited-risk system, or a minimal-risk system? For most SaaS AI features, this will be limited risk (Art. 50 transparency obligations) or minimal risk. If your product uses AI for hiring decisions, credit scoring, or similar high-stakes use cases, you are in the high-risk tier with significantly more obligations.

3. Intended and prohibited use cases

Be specific and honest. Intended use cases guide deployers in appropriate deployment. Prohibited uses provide legal protection if the model is misused — you documented it was not intended for that purpose. Include:

Use cases the model has been tested and validated for
Use cases that are explicitly not supported
High-risk use cases that require additional safeguards if attempted

4. Training data

This is the most legally sensitive section in 2026. Three overlapping frameworks apply:

EU AI Act Art. 10: Training data must be subject to appropriate data governance practices — data sourcing, pre-processing, filtering, known limitations and biases in the data
EU AI Act Art. 53(1)(d): A summary of training data must be published
Copyright law: Art. 53(1)(c) requires a copyright compliance policy. Text and Data Mining (TDM) exceptions under EU Directive 2019/790 apply, but rights reservation (opt-out) must be respected
GDPR: If training data includes personal data, Art. 6 lawful basis, Art. 5 data minimisation, and Art. 25 privacy by design apply

Include: data sources, data volume estimates, time range, filtering and curation applied, known gaps or biases in the training corpus, copyright compliance approach.

5. Performance and evaluation

Document what benchmarks were run and what the results were — honestly. A model card that only shows impressive benchmark results and hides failure modes is worse than useless; it creates legal liability when the model is deployed in situations it was never evaluated for.

6. Bias and fairness

What demographic groups, languages, or topics was the model tested on? Were disparate performance rates found? What mitigation was applied? If no bias testing was conducted, say so — and document the plan to address it. Undisclosed known biases in AI systems that cause harm expose providers to liability.

7. Safety measures and human oversight

Describe the content filters, output moderation, rate limiting, abuse monitoring, and human review processes in place. Under EU AI Act Art. 14, high-risk AI systems must be designed to allow human oversight — the model card is where this is documented.

8. Environmental impact

EU AI Act Recital 90 calls for awareness of environmental impacts of AI. Training compute and inference energy use are increasingly disclosed in industry model cards (e.g. GPT-4 technical report, Gemini technical report).

Who needs to see your model card?

Enterprise customers: Increasingly require model cards as part of security and compliance questionnaires, particularly in regulated industries
Downstream integrators: If you offer a GPAI API, Art. 53 requires you to provide technical documentation to those integrating your model
Regulators: The EU AI Office may request documentation; national market surveillance authorities will conduct audits
Auditors: SOC 2, ISO 27001, and GDPR audits increasingly include AI governance questions
Your own team: A model card forces internal clarity about what the model does, what its limits are, and what safeguards are in place

Model card vs. EU AI Act Art. 50 transparency notice: what's the difference?

They are complementary, not interchangeable:

Document	Audience	Purpose	Required by
Model Card	Deployers, regulators, technical users	Technical documentation of model capabilities, limitations, and safety	EU AI Act Art. 53 (GPAI) / Annex IV (high-risk)
Art. 50 Transparency Notice	End users (general public)	Inform users they are interacting with AI (chatbots) or consuming AI-generated content	EU AI Act Art. 50
GDPR Privacy Notice	Data subjects	Inform about personal data processing	GDPR Art. 13/14
DPIA	Internal / DPAs	Assess risks of high-risk personal data processing	GDPR Art. 35

For a complete AI governance documentation stack, you need all of these for the relevant use case.

Generate your model card now

ComplyKit's AI/ML Model Card Generator walks you through the EU AI Act Art. 53 documentation requirements and generates a publication-ready model card covering all the sections above. Free, no account required.

If you're also working on EU AI Act Art. 50 user transparency, the EU AI Act Transparency Declaration Generator covers that requirement separately.

Related tools and guides

⚠️ This guide is for informational purposes only and does not constitute legal advice. EU AI Act interpretation is evolving. Consult a qualified AI governance professional and legal counsel for specific advice on your AI system.