What data governance documentation the EU AI Act requires

At a glance

• The most detailed data governance documentation duties fall on providers of high-risk AI systems, under Article 10, Article 11 and Annex IV of the AI Act.
• Organisations using a high-risk system built by someone else have responsibilities for the input data they control and for retaining automatically generated logs under their control.
• Technical documentation must stay up to date. Recording sources, responsibilities and relevant changes should be an ongoing practice, not a file written once at launch.

Which AI systems the data rules apply to

The detailed data governance rules in Article 10 concern high-risk AI systems. Classification depends on Article 6 and the relevant annexes, including certain product-related systems under Annex I and use cases under Annex III. Examples include certain recruitment systems, systems evaluating the creditworthiness of natural persons, and systems determining access to specified essential services. The precise intended purpose, conditions and exceptions matter.

A chatbot summarising internal policies or a model forecasting stock levels is not automatically high-risk simply because it uses AI. Equally, a tool's label alone cannot establish that it falls outside the high-risk rules. The first job is to assess each use case against the Act's classification criteria.

The Act also separates two roles. A provider develops an AI system, or has it developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its own authority, outside personal, non-professional activity. A company may be a deployer for vendor tools and a provider for some systems developed for internal use. Certain changes to a system or its intended purpose can also affect that role.

What Article 10 asks you to show about training data

Article 10 of the AI Act covers data and data governance for high-risk systems. For high-risk systems using techniques involving the training of AI models with data, it requires training, validation and testing data sets to be subject to governance and management practices appropriate to the system's intended purpose. Those practices cover, among other things:

1. The relevant design choices.
2. How the data was collected, where it came from and, for personal data, the original purpose of collection.
3. The preparation steps, such as annotation, labelling, cleaning, updating, enrichment and aggregation.
4. The assumptions made, particularly about what the data is intended to measure and represent.
5. An assessment of the availability, quantity and suitability of the data needed.
6. An examination of possible biases, including biases that could affect health and safety, fundamental rights or lead to prohibited discrimination, and appropriate measures to detect, prevent and mitigate them.
7. The relevant data gaps or shortcomings found, and how they can be addressed.

Article 10 also requires the data sets to be relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose. They must have appropriate statistical properties, including, where applicable, for the people or groups concerned. For high-risk systems that do not use techniques involving model training, Article 10(6) applies the requirements in paragraphs 2 to 5 to testing data sets only.

Notice what this list is. It is not just a description of the model. It describes the data: its origin, its handling and its known weak spots. That overlaps with the work a data governance team already does, documented for a particular system and its intended purpose.

What the technical documentation must contain about data

Article 11 requires providers of high-risk systems to draw up technical documentation before the system is placed on the market or put into service, and to keep it up to date. Annex IV sets out its required contents.

For data, Annex IV point 2(d) calls for a description of the training methodologies and techniques, and the training data sets used, where applicable. It includes general information about those data sets, their provenance, scope and main characteristics; how data was obtained and selected; labelling procedures, such as supervised learning; and data cleaning methodologies, such as outlier detection. Article 12 separately requires high-risk systems to technically allow automatic recording of events over their lifetime.

A common misconception is that AI Act documentation is a compliance file written once at launch by whoever built the model. Article 11 requires technical documentation to stay current. Changes to data sources or preparation steps should therefore be assessed for their effect on that documentation. Keeping ownership information current also helps teams maintain the record, even though an ownership register alone does not satisfy the Act.

For example, a credit scoring model was trained on a customer table maintained by Finance. Six months later, the table's owner leaves and a colleague adds a new filter. If nobody records that change, the team may no longer be able to reconcile the documented training snapshot with the current table or explain the data used in a later retraining run. Preserve the historical record and document relevant changes rather than overwriting the past.

What deployers have to document

If you use a high-risk system built by a vendor, the provider is generally responsible for Article 10 and Annex IV. Your deployer duties are different, but they still touch data. Check your role rather than assuming that buying a system always leaves you solely a deployer.

Under Article 26(4), to the extent that deployers control input data, they must ensure that it is relevant and sufficiently representative in view of the high-risk system's intended purpose. Deployers also have duties concerning automatically generated logs under their control. Confirm the applicable retention requirements with your legal adviser, including any relevant personal data protection rules.

In practice, this means knowing which of your data sets feed which AI system, who is responsible for them and what changed. That is a lineage and ownership question involving the data team, not only procurement. Input-data and logging duties are only part of the wider deployer obligations in Article 26.

What general-purpose AI model providers document

Providers of general-purpose AI models, the models on which many tools are built, have separate obligations under Article 53. These include drawing up and keeping technical documentation current, providing specified information to downstream AI system providers, and making publicly available a sufficiently detailed summary of the content used to train the model, using the template provided by the AI Office. Article 53 also includes a policy obligation concerning EU copyright law.

These duties are distinct from the high-risk system requirements. Article 53 contains qualified exemptions for certain free and open-source models, while providers of general-purpose AI models with systemic risk have additional obligations under Article 55.

Many companies use general-purpose models rather than provide them. For those companies, practical questions include what the vendor publishes and whether their own data enters a workflow through prompts, fine-tuning or retrieval. Those activities are not interchangeable: supplying retrieval context, for example, does not by itself mean that the data becomes part of the underlying model's training set. The company's role and obligations need to be assessed for the actual arrangement.

Who documents what under the AI Act

A practical framework: Inventory, Source, Own, Record, Review

The following workflow is a practical way to organise supporting records. It is not a substitute for the Act's full requirements or a prescribed legal documentation format.

• Inventory: list your AI use cases, assess which are high-risk and identify whether you are a provider or deployer for each. Record the reasoning behind that assessment.
• Source: for each high-risk use case, list the data sets it uses and where each one comes from. Distinguish training, validation, testing and operational input data where relevant.
• Own: name one accountable person per data set who can answer questions about its content and coordinate or approve changes within your governance process.
• Record: keep a dated trail of what changed in each data set and who changed it. Retain the versions or references needed to distinguish historical data from current data.
• Review: check the record against reality on a fixed rhythm and whenever a source, owner or preparation step changes. Update the relevant technical documentation when needed.

Keep the record current

The AI Act's data requirements build on familiar governance questions: where did the data come from, what was done to it, what limitations are known and who can explain it? Teams already recording sources and owners have a useful foundation, but still need to assess system-specific requirements, evidence and wider obligations.

Start with the inventory, connect each system to its relevant data records and keep those records current. The legal summaries here describe selected provisions of Regulation (EU) 2024/1689, not a complete compliance assessment or legal advice. System classification, role allocation and the application of particular obligations require case-specific legal assessment.