What actually goes in AI technical documentation, and where model cards fit

Standfirst: A model card is an industry habit with no legal definition. Annex IV of the EU AI Act is a legal specification with a numbered list, and Article 11 makes that list the mandatory floor for the technical documentation of a high-risk AI system. If you walk into the exam knowing the difference, and knowing what each Annex IV section actually asks for, you will read documentation questions the way the regulation reads them.

Two things that sound alike and are not

A model card is a documentation practice. Teams publish a short, structured summary of a model: what it does, how it was trained, how it performs. The format varies by organization. No statute defines it, no regulator has adopted it as a compliance artifact, and nothing in the EU AI Act mentions it.

Technical documentation under the EU AI Act is different in kind. Article 11(1) requires that the technical documentation of a high-risk AI system be drawn up before the system is placed on the market or put into service, and be kept up to date. The article states its purpose plainly:

The technical documentation shall be drawn up in such a way as to demonstrate that the high-risk AI system complies with the requirements set out in this Section and to provide national competent authorities and notified bodies with the necessary information in a clear and comprehensive form to assess the compliance of the AI system with those requirements. It shall contain, at a minimum, the elements set out in Annex IV.

Read that sentence twice. The audience is not the public and not the deployer. It is national competent authorities and notified bodies, the people who assess compliance. The content is not whatever the provider finds useful to share. It is, at a minimum, everything in Annex IV.

One relief valve exists. SMEs, including start-ups, may provide the Annex IV elements in a simplified manner, using a simplified form the Commission must establish. Notified bodies must accept that form for conformity assessment. If an SME opts for the simplified route, it must use that form. Article 11(3) also lets the Commission amend Annex IV by delegated act to keep pace with technical progress, so the list can change.

What Annex IV actually lists

Annex IV has nine numbered sections. Each applies "as applicable to the relevant AI system," but the list is the minimum, not a menu.

Section	What it requires
1	A general description: intended purpose, provider name, version and its relation to previous versions, interaction with external hardware or software, software and firmware versions, the forms in which the system is placed on the market (packages, downloads, APIs), the hardware it runs on, product photographs where it is a product component, the deployer-facing user interface, and instructions for use for the deployer
2	The elements of the system and its development process (detailed below)
3	Monitoring, functioning and control: capabilities and limitations, degrees of accuracy for specific persons or groups and overall expected accuracy, foreseeable unintended outcomes and sources of risk to health, safety, fundamental rights and discrimination, human oversight measures under Article 14, and input data specifications as appropriate
4	Why the chosen performance metrics are appropriate for this specific system
5	A detailed description of the risk management system under Article 9
6	Relevant changes the provider made to the system through its lifecycle
7	Harmonized standards applied; where none, a detailed description of the solutions used to meet Chapter III, Section 2 requirements, plus other standards and specifications applied
8	A copy of the EU declaration of conformity referred to in Article 47
9	The post-market performance evaluation system, including the post-market monitoring plan under Article 72(3)

Section 2 is where most of the engineering detail lives, and it is where exam questions on documentation depth tend to point. You should be able to name its components:

• Development methods and steps, including use of pre-trained systems or third-party tools and how the provider integrated or modified them.
• Design specifications: the general logic of the system and its algorithms, key design choices with rationale and assumptions, classification choices, what the system is designed to optimize for, expected output and output quality, and any trade-offs made to comply with Chapter III, Section 2.
• System architecture and the computational resources used to develop, train, test and validate the system.
• Data requirements, where relevant, in terms of datasheets describing training methodologies and data sets: provenance, scope, main characteristics, how data was obtained and selected, labelling procedures and data cleaning methodologies.
• Assessment of human oversight measures under Article 14, including technical measures to help deployers interpret outputs, per Article 13(3), point (d).
• Pre-determined changes to the system and its performance, where applicable, with the technical solutions ensuring continuous compliance.
• Validation and testing procedures, including the data used, metrics for accuracy, robustness and compliance, potentially discriminatory impacts, and test logs and reports dated and signed by responsible persons.
• Cybersecurity measures put in place.

Notice what this demands that no model card format supplies as a matter of course: signed and dated test reports, trade-off decisions with rationale, a copy of a declaration of conformity, and a post-market monitoring plan.

Article 13 serves a different reader

Article 13 covers transparency and the provision of information to deployers. Its instrument is the instructions for use, which must accompany a high-risk AI system in an appropriate digital format or otherwise, containing "concise, complete, correct and clear" information that is accessible and comprehensible to deployers. The design obligation in Article 13(1) sits alongside it: the system must be transparent enough for deployers to interpret its output and use it appropriately.

Article 13(3) sets the minimum content of the instructions for use:

• Identity and contact details of the provider and, where applicable, its authorised representative.
• Characteristics, capabilities and limitations of performance, including intended purpose; the tested and expected level of accuracy, robustness and cybersecurity under Article 15, with circumstances that may affect them; known or foreseeable circumstances of use or reasonably foreseeable misuse that may lead to risks to health, safety or fundamental rights under Article 9(2); technical capabilities relevant to explaining output; performance regarding specific persons or groups, when appropriate; and specifications for input data or information on training, validation and testing data sets, when appropriate.
• Pre-determined changes to the system and its performance, if any.
• Human oversight measures under Article 14, including technical measures that facilitate interpretation of output.

The distinction to hold onto is audience and function. Annex IV documentation exists so authorities and notified bodies can assess compliance. Article 13 instructions exist so deployers can operate the system properly. The same fact, such as expected accuracy, appears in both, written for different readers at different levels of detail.

	Annex IV technical documentation	Article 13 instructions for use
Reader	National competent authorities, notified bodies	Deployers
Purpose	Demonstrate and allow assessment of compliance	Enable correct interpretation and use of output
Character	Comprehensive, at minimum the Annex IV elements	Concise, complete, correct and clear
Timing	Drawn up before market placement, kept up to date	Accompanies the system

Where the model card fits

A well-built model card overlaps with both instruments. Intended purpose, performance metrics, limitations and training data description appear in model cards and in Annex IV sections 1 through 4. That overlap is real and useful. A provider that already writes model cards has a head start on several Annex IV elements.

Overlap is not substitution. A model card does not, by itself, satisfy Article 11, for two reasons you should be able to state. First, Annex IV is a minimum, and its list runs well past what model cards typically contain: the risk management system under Article 9, harmonized standards applied, the declaration of conformity under Article 47, the post-market monitoring plan under Article 72(3), signed test reports and lifecycle change records. Second, the legal function differs. Annex IV documentation must demonstrate compliance to an authority in a clear and comprehensive form. A model card carries no such obligation and answers to no defined standard. Treat the model card as a familiar starting point that maps onto parts of the legal requirement, never as the requirement itself.

The exam will test whether you can tell these instruments apart by audience, legal basis and content. Expect to need Article 11 for the obligation, Annex IV for the elements, and Article 13 for the deployer-facing information, and to know which of those three a given fact belongs to. If a question offers a model card as a compliance answer, you now know why it fails: it has no legal definition, and the law asks for more.

Common questions

Is a model card the same as EU AI Act technical documentation?

No. A model card is a practice convention with no legal definition. Annex IV of the EU AI Act is a legal specification with a required list of elements. They overlap, and a model card is not a substitute.

What is the difference between technical documentation and instructions for use?

They serve different audiences. Technical documentation under Article 11 and Annex IV is for authorities assessing conformity. Instructions for use under Article 13 are for the deployer, so they can operate the system within its limits.