Category: EU AI Act & GPAI

Annex XII Documentation

Also known as: Annex XII, Annex XII Transparency Information

Simply put

Annex XII Documentation refers to a set of transparency information described in an annex to the EU AI Act, the European Union's regulation on artificial intelligence. Based on the available evidence, this annex specifies information such as a general description of the AI model, its intended tasks, and how it can be integrated into other systems. It is one of several distinct documentation annexes in the EU AI Act, and it applies within the EU regulatory context rather than universally.

Formal definition

In the EU AI Act, Annex XII sets out transparency information referred to in the relevant provisions of the Act. According to the evidence, it enumerates required content including a general description of the AI model, its intended tasks, and how the model can be integrated into other systems. It should be distinguished from other documentation annexes cited in the evidence—notably Annex XI (technical documentation for AI models) and Annex IV (technical documentation for high-risk AI system providers)—which serve different documentation functions under the Act. The precise triggering conditions, the specific Article that Annex XII is referred to under, and the full list of required elements are not fully specified in the evidence provided and should be verified against the official EU AI Act text. As a documentation obligation, this annex forms part of a binding EU legal instrument; its detailed scope, applicable actors, and effective timing are out of scope for this entry given the available evidence.

Why it matters

Annex XII Documentation matters because it is part of the EU AI Act's structured approach to transparency, situating certain disclosure obligations within a binding EU legal instrument rather than in voluntary guidance. For organizations that develop or integrate AI models intended for the EU market, understanding which annex governs which type of documentation is a foundational compliance task. Confusing Annex XII with the technical documentation annexes—Annex XI for AI models or Annex IV for high-risk AI system providers—can lead to preparing the wrong artifacts or misallocating compliance effort.

The practical significance lies in the distinct function Annex XII appears to serve within the Act's documentation architecture. Based on the available evidence, it concerns transparency information such as a general description of the model, its intended tasks, and how the model can be integrated into other systems. This kind of information typically supports downstream actors who need to understand a model well enough to deploy or build on it, which is a different objective from the internal technical documentation that regulators or auditors may examine. Treating these as one undifferentiated documentation set risks both under-disclosure to integrators and over-disclosure of material that belongs in a different annex.

Because the EU AI Act is a jurisdiction-specific instrument, Annex XII obligations should not be assumed to apply outside the EU regulatory context or to be interchangeable with documentation expectations under other frameworks. The precise triggering conditions, the Article under which Annex XII is referred to, the full list of required elements, and the effective timing are not fully established by the evidence available here and should be verified against the official EU AI Act text before relying on them for compliance decisions.

Who it's relevant to

AI model providers and developers targeting the EU market

Organizations that develop AI models intended for use or integration within the EU may need to prepare transparency information of the kind described in Annex XII. Correctly distinguishing this transparency documentation from the technical documentation covered by other annexes helps ensure the right artifacts are produced for the right purpose. Because the exact scope and applicable actors are not fully established by the evidence here, providers should confirm their specific obligations against the official EU AI Act text.

Compliance officers and AI governance teams

Those responsible for mapping regulatory obligations to internal controls need to understand how Annex XII fits within the EU AI Act's broader documentation structure, and how it differs from Annex XI and Annex IV. This supports accurate allocation of compliance effort and avoids conflating transparency disclosures with internal technical documentation. Governance measures reduce and manage compliance risk but do not eliminate it, and the precise requirements should be verified against the authoritative text.

System integrators and downstream deployers

Actors who build on or deploy AI models supplied by others rely on transparency information—such as a general description of the model, its intended tasks, and how it can be integrated into other systems—to understand and appropriately use those models. Annex XII's transparency focus is relevant to this audience, though the specific obligations that fall on integrators versus providers under the Act are out of scope for this entry given the available evidence.

Legal and regulatory specialists advising on EU AI Act compliance

Legal professionals interpreting documentation obligations must scope Annex XII correctly to the EU jurisdiction and to the relevant provisions of the Act, and should not treat it as interchangeable with documentation requirements under other frameworks or other annexes. Given that the precise triggering Article, effective timing, and full list of required elements are not fully specified in the evidence provided, verification against the official EU AI Act text is essential before advising clients.

Inside Annex XII Documentation

Provider-to-deployer information

In the EU AI Act, the annex commonly associated with documentation obligations sets out information that a provider of a general-purpose AI model is expected to make available downstream. Note: the precise annex numbering and content should be verified against the current consolidated text, as references such as 'Annex XII' can shift between draft and final versions.

Model characteristics and capabilities

Descriptive information about the model's intended purpose, its capabilities and limitations, and the types of tasks it is designed to perform, enabling downstream actors to understand what they are integrating.

Technical and training-related details

Information that may include aspects of the model's architecture, training and testing processes, and data characteristics, to the extent this is specified in the applicable text. The exact scope should be confirmed against the operative legal instrument.

Integration and compliance support

Documentation intended to help downstream deployers understand the model sufficiently to meet their own obligations, functioning as a transparency and information-transfer mechanism rather than as a full model risk validation record.

Common questions

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

Does 'Annex XII Documentation' refer to a settled, universally recognized documentation standard?

No. Annex references within the EU AI Act's structure have been subject to renumbering and revision through the legislative process, so a specific annex label should not be treated as a fixed, universally recognized citation. The safer approach is to confirm the current consolidated text and annex numbering directly from the official published version applicable to your obligation, rather than relying on an annex number alone. This entry describes the concept of transparency and information-provision documentation as commonly discussed under the EU AI Act; it does not assert that a particular annex number is authoritative across all versions or contexts.

Is documentation of this kind the same as the technical documentation a provider maintains for its own model risk management?

Not necessarily, and conflating the two is a common error. Documentation aimed at transparency or information provision to downstream parties typically serves a governance and disclosure function under a regulatory instrument, whereas internal model risk documentation supports the identification, measurement, monitoring, and control of model risk. The two may overlap in content, but they answer to different purposes and audiences. Treating a compliance-facing document as a substitute for internal validation and monitoring records, or vice versa, can leave gaps in both governance and model risk coverage.

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

Responsibility is usually distributed rather than assigned to a single owner. In many governance structures, the first line (those building or deploying the system) generates the underlying technical and operational content, while second-line functions may review it for compliance and risk consistency. Because documentation obligations under the EU AI Act can differ depending on whether an organization acts as a provider or a deployer, the specific owner depends on that role. Organizations should confirm which role applies to them before assigning accountability, as the obligations attaching to each are not identical.

How should this documentation be kept current as a model changes over time?

Documentation is generally treated as a living record rather than a one-time deliverable. As commonly practiced, changes to the model, its data, its intended purpose, or its operating context can trigger a need to update the corresponding documentation. Linking documentation updates to existing change-management and version-control processes helps keep the record aligned with the system in production. Note that keeping documentation current supports compliance and oversight but does not by itself eliminate model risk; it makes that risk more visible and manageable.

What is the practical difference between documenting model validation and documenting model verification in this context?

The distinction matters and should be preserved in the documentation. Verification typically addresses whether the system was built correctly against its specifications, while validation typically addresses whether the system is appropriate and performs as intended for its purpose. Documentation that records only one of these leaves the other unevidenced. When compiling transparency or information-provision material, it is worth confirming that both the 'built right' and 'right thing built' dimensions are captured where the applicable obligation calls for them, without treating the two as interchangeable.

How can an organization tell whether its documentation is sufficient for the applicable obligation?

Sufficiency generally depends on the specific obligation and the organization's role, so a fixed checklist is unlikely to be authoritative across all cases. A practical approach is to map documentation content back to the requirements in the current official text applicable to you, and to have a second-line or independent review assess completeness against those requirements. Because regulatory treatment in this area continues to evolve and annex numbering has changed over the legislative process, confirm you are working from the current consolidated version before concluding that documentation is adequate.

Common misconceptions

This documentation constitutes model validation or verification in the model risk management sense (as framed by guidance such as SR 11-7).

Disclosure and transparency documentation under a regulatory instrument is distinct from independent model validation. Validation typically involves independent testing of conceptual soundness and outcomes, while this documentation is primarily an information-transfer obligation. The two may complement each other but are not interchangeable.

The specific annex number and its exact contents are fixed and universally cited.

Annex numbering and content in the EU AI Act can differ between drafts, the final adopted text, and later amendments. Practitioners should confirm the current reference rather than rely on a remembered clause number, and should not treat a particular number as authoritative without checking the operative text.

Producing this documentation demonstrates that the AI system is compliant or that its risks have been eliminated.

Documentation is a measure that supports transparency and helps other parties meet their obligations; it does not by itself establish overall compliance or remove risk. It is one control among many within a broader governance and risk-management framework.

Best practices

Confirm the current annex reference and its exact required contents against the consolidated, operative version of the EU AI Act before relying on any specific clause number in policies or contracts.

Treat this documentation as a downstream information-transfer obligation and map it explicitly to what deployers need to fulfill their own responsibilities, rather than assuming it satisfies internal model validation requirements.

Maintain the documentation as a living artifact, updating it when the model's capabilities, limitations, or intended purpose change, and versioning each release.

Coordinate between legal, compliance, and technical teams so that descriptive claims about capabilities and limitations are accurate and defensible.

Clearly delineate in your control inventory where this regulatory documentation ends and where separate model risk management activities (such as independent validation and ongoing monitoring) begin, to avoid conflating governance disclosure with risk measurement.

Note explicitly in internal records that the scope of this documentation is limited to transparency and information provision, so that stakeholders do not overstate its assurance value.