Category: EU AI Act & GPAI

Annex XI Documentation

Also known as: Annex XI Technical Documentation, EU AI Act Annex XI

Simply put

Annex XI Documentation refers to a set of records that certain AI providers are expected to prepare under an annex of the EU AI Act, describing the AI model and how it is intended to be used. Based on the evidence available, this documentation typically includes items such as a general description of the AI model, its intended tasks, acceptable use policies, and its release date. Note that 'Annex XI' also appears in a separate EU regulation for medical devices, where it means something entirely different, so the term should always be read in context.

Formal definition

In the context of the EU Artificial Intelligence Act, Annex XI specifies technical documentation referenced in the Act's relevant article (as indicated by the source), enumerating the information a provider is expected to maintain. Per the evidence, this includes a general description of the AI model, its intended tasks, acceptable use policies, and release date, among other items not fully enumerated in the evidence provided. Practitioners should distinguish this from the identically labeled 'Annex XI' under the EU Medical Device Regulation (MDR), which addresses conformity assessment based on product conformity verification (batch testing or production quality assurance) and is unrelated to AI model documentation. The evidence does not establish the exact article cross-reference, the complete list of required elements, or applicable effective dates, so those details are out of scope here and should be verified against the current consolidated text of the Act.

Why it matters

For providers of certain AI models subject to the EU AI Act, Annex XI Documentation represents part of the paper trail that regulators and downstream parties may rely on to understand what a model is, what it is intended to do, and how it should and should not be used. In many governance frameworks, documentation of this kind serves as the connective tissue between an organization's internal accountability structures and its external obligations, giving oversight functions a reference point for what the provider claims about the model. Maintaining such records is a governance measure that supports transparency and accountability; it does not by itself eliminate the underlying risks associated with a model's development or deployment.

A recurring source of confusion is that the label 'Annex XI' also appears in a separate EU instrument, the Medical Device Regulation, where it refers to conformity assessment based on product conformity verification (for example, batch testing or a production quality assurance system) and has nothing to do with AI model documentation. Professionals working across both domains can easily misattribute requirements from one regime to the other, which can lead to preparing the wrong records or misreading a compliance obligation. Reading the term strictly in the context of the regulation being cited is essential.

The evidence available establishes only a partial picture of the AI Act's Annex XI contents and does not confirm the exact article cross-reference, the complete list of required elements, or applicable effective dates. Because the EU AI Act's documentation obligations are subject to phased application and interpretation, practitioners should treat the items described here as illustrative rather than exhaustive and verify specifics against the current consolidated text.

Who it's relevant to

AI model providers subject to the EU AI Act

Providers who fall within the scope of the relevant Annex XI obligations are the parties expected to prepare and maintain this documentation. They need to understand which elements—such as a general description of the model, its intended tasks, acceptable use policies, and release date—apply to them, and should confirm the complete set of requirements against the current text of the Act rather than relying on illustrative lists.

AI governance and compliance officers

Those responsible for organizational accountability for AI systems use documentation of this kind as a reference point linking internal oversight to external regulatory obligations. They should treat such records as a risk-management measure that supports transparency, not as something that eliminates model-related risk, and should track the phased and evolving nature of the Act's requirements.

Legal and regulatory specialists working across EU regimes

Professionals advising on EU regulation should be alert to the fact that 'Annex XI' carries an entirely different meaning under the Medical Device Regulation, where it concerns conformity assessment based on product conformity verification. Reading the term in its correct regulatory context is essential to avoid misattributing obligations from one regime to the other.

Auditors and third-line assurance functions

Auditors reviewing an organization's AI Act readiness may examine Annex XI Documentation as evidence of a provider's descriptions and claims about a model. They should recognize that the available sources do not confirm the exact article cross-reference, the full list of required elements, or effective dates, and should verify scope against the consolidated text before drawing conclusions.

Inside Annex XI Documentation

Technical documentation reference

In the EU AI Act framework, Annex XI is commonly associated with documentation obligations tied to general-purpose AI (GPAI) models. As typically framed, it sets out the categories of technical information a provider is expected to compile and maintain. Note that the precise contents, annex numbering, and applicability should be verified against the current consolidated text, as these have been subject to change through the legislative process.

Model description and development information

Documentation of this type generally covers a description of the model, its intended tasks and integration options, and information about the development process, including design choices. The exact required fields depend on the operative version of the instrument and should not be assumed to be exhaustive here.

Training and testing information

Such documentation typically addresses the data and processes used for training, testing, and validation, including, in many formulations, information on data provenance and curation at a level of detail scoped to the obligation. This is documentation about the model lifecycle rather than an operational risk-control process in itself.

Computational and resource information

GPAI-focused documentation obligations are often described as including information on computational resources used in training and, where relevant, energy consumption. Whether and how specific metrics are required should be confirmed against the current text.

Purpose and audience distinction

Documentation of this kind is generally intended to support transparency toward regulators and, in some cases, toward downstream providers who integrate the model. It serves a governance and accountability function—supporting oversight and traceability—and is distinct from the substantive model risk management processes (identification, measurement, monitoring, and control of model risk) that an organization may run separately.

Common questions

Answers to the questions practitioners most commonly ask about Annex XI Documentation.

Does preparing Annex XI documentation apply to all AI systems an organization deploys?

No. As commonly understood in the context of the EU AI Act, the technical documentation obligations associated with Annex XI are scoped to particular categories of systems and providers rather than to every AI system in general use. Treating the documentation set as a universal requirement for all AI deployments is a frequent error. You should confirm which categories of systems the obligation actually attaches to under the applicable provisions before assuming it applies, and note that the EU AI Act is EU law and does not by itself govern systems outside its jurisdictional and material scope.

Is Annex XI documentation the same thing as internal model validation reports under model risk management frameworks?

No, and conflating the two is a common mistake. Documentation contemplated by the EU AI Act serves a regulatory conformity and transparency function under that legal instrument, whereas model validation documentation under model risk management practice (historically framed by guidance such as SR 11-7 in U.S. banking supervision) is an internal risk control artifact focused on assessing whether a model is sound and fit for its intended use. The two can overlap in content and evidence, but they arise from different frameworks, serve different purposes, and are not interchangeable substitutes for one another.

Who within an organization is typically responsible for producing and maintaining this documentation?

Responsibility commonly spans multiple functions rather than sitting with a single team. In many organizations, technical teams supply the underlying descriptions and evidence, while compliance, legal, and governance functions coordinate completeness and alignment with the applicable obligations. Where organizations use a lines-of-defense model, the owning or developing function (first line) typically generates the content, while oversight functions (second line) review it for adequacy. The specific allocation depends on internal governance structures and should be defined explicitly to avoid gaps.

How should documentation be kept current after a system is placed into use?

Documentation is generally treated as a living artifact rather than a one-time deliverable. In practice, organizations tie updates to change management and monitoring processes, so that material changes to the system, its data, or its intended use trigger a review and, where needed, revision of the relevant sections. Establishing version control, defined update triggers, and clear ownership helps maintain currency. Keeping documentation current supports but does not by itself eliminate the underlying risks associated with the system.

How does this documentation relate to voluntary standards such as ISO/IEC 42001 or the NIST AI RMF?

The relationship is one of potential support rather than equivalence. Voluntary standards and frameworks (ISO/IEC 42001, issued as a management-system standard, and the NIST AI Risk Management Framework, issued as voluntary guidance) may help an organization structure processes and evidence that can feed into required documentation. However, conforming to a voluntary framework does not automatically satisfy a legal documentation obligation, and satisfying a legal obligation does not automatically demonstrate conformance to a voluntary standard. They should be mapped deliberately rather than assumed to be interchangeable.

What is a practical way to organize documentation so it can be reviewed or produced on request?

A common approach is to maintain a structured, indexed set of materials that maps each required element to its supporting evidence and identifies the responsible owner and last review date. This makes it easier to demonstrate completeness, respond to internal audit or external review, and identify gaps. Traceability between the documented claims and the underlying technical evidence is generally valued. The specific structure that will be adequate depends on the applicable obligations and the nature of the system, so organizations should confirm scope rather than rely on a generic template.

Common misconceptions

Annex XI documentation is the same as model risk management or satisfies model risk obligations.

Documentation obligations are an AI governance and transparency mechanism—they record information to support oversight and traceability. They are not equivalent to model risk management, which is the ongoing identification, measurement, monitoring, and control of risks arising from model use (as historically framed by guidance such as SR 11-7 in a different, U.S. banking context). Producing the documentation does not by itself validate a model or manage its risks.

The exact contents and clause numbering of Annex XI can be stated definitively and are stable.

The EU AI Act and its annexes have moved through a legislative process, and annex numbering, scope, and detailed contents have been subject to revision. Practitioners should treat any summary as indicative and verify specific fields, thresholds, and applicability against the current consolidated official text rather than relying on a fixed recollection.

Preparing this documentation demonstrates that the model is compliant, safe, or low-risk.

Documentation supports transparency and accountability and can reduce compliance and oversight risk, but it does not eliminate risk or independently establish that a model performs adequately. Compliance depends on meeting the substantive requirements applicable to the model, of which documentation is one part, and does not substitute for validation, testing, or monitoring.

Best practices

Verify the current, consolidated official text of the EU AI Act to confirm the exact annex numbering, scope, applicable obligations, and effective dates before relying on any internal summary of Annex XI contents.

Maintain documentation as a living artifact that is version-controlled and updated as the model, its training data, or its intended uses change, rather than treating it as a one-time deliverable.

Keep documentation obligations organizationally distinct from, but linked to, model risk management processes so that transparency records and substantive risk controls each remain identifiable and auditable.

Scope the level of detail to the intended audience—regulators versus downstream integrators—and confirm which recipients the applicable obligation actually addresses.

Cross-reference documentation with underlying evidence (training and testing records, data provenance information, computational resource data) so that recorded claims are traceable to source material.

Engage legal or regulatory specialists to confirm applicability to your model type, particularly for general-purpose AI, before treating the documentation as complete or compliance-establishing.