EU AI Act Article 10 data governance for AI agents

Article 10 of the EU AI Act requires providers of high-risk AI systems to train, validate and test them on data that is relevant, sufficiently representative, examined for bias and, as far as possible, free of errors and complete. For an AI agent, the harder question is the data it reads at runtime, which the deployer largely controls.

What does Article 10 require, in plain words?

Article 10 is a data quality and data governance duty. It applies to high-risk AI systems and is aimed at the datasets used to build them: training, validation and testing data. Where a system is not trained by the provider in the classic sense, the testing data rules still apply.

The data governance practices it expects cover, in substance:

• the design choices behind the data and why they were made;
• where the data came from and, for personal data, the original purpose of collection;
• preparation steps such as labelling, cleaning, enrichment and aggregation;
• the assumptions the data is meant to represent;
• whether there is enough of it, of the right kind;
• an examination for biases likely to affect health, safety or fundamental rights, or to lead to discrimination, with measures to detect, prevent and reduce them;
• the gaps or shortcomings in the data and how they are addressed.

Datasets must reflect the setting the system will be used in: the geography, the behaviour and the context. The Act also allows providers to process special category personal data where strictly necessary to detect and correct bias, under tight safeguards.

Who does Article 10 apply to?

The duty sits with the provider of a high-risk system, the party that develops it and places it on the market or puts it into service under its own name. A bank that buys a credit assessment agent is usually a deployer. A bank that builds one, or substantially modifies a bought one, takes on provider duties, including Article 10.

Deployers are not off the hook. Article 26 requires a deployer that controls the input data to make sure it is relevant and sufficiently representative for the system's intended purpose. For agents, that clause does a lot of work, because most of what an agent knows at the moment of action comes from inputs the deployer chose.

What changes when the system is an agent that reads sources at runtime?

A conventional model is trained once and then scores inputs. An agent built on a general-purpose model is rarely trained by the business at all. Its behaviour depends on three things: the model, the brief, and the sources it retrieves while working, such as a policy library, a customer record, a ledger or an inbox.

That shifts the data governance problem. The training data of the underlying model is the model provider's concern. The quality of an agent's answer about a customer's arrears depends on whether it read the current ledger or a stale export, and whether it treated an emailed claim as fact. Those are runtime source questions, and Article 10's logic applies to them even where its text is aimed at datasets.

Three agent-specific risks follow:

1. Source drift. A policy document is replaced but the agent's index still serves the old one. The data was accurate when governed and is wrong now.
2. Untrusted inputs treated as data. An emailed invoice or a web page carries instructions or false figures. This is the injection problem described in our note on how the OWASP Top 10 for LLM applications applies to agents.
3. Unrepresentative test sets. An agent certified on tidy English-language cases meets handwritten scans and mixed-language messages in production.

Our view is that a deployer should govern each runtime source as a dataset in its own right: named, owned, versioned and classified by how much it can be trusted.

How do you meet Article 10 for an agent?

The last row is where agent design matters most. If a fact's origin travels with it, the agent and the control layer can treat a ledger balance differently from a figure in a forwarded email. Without that, data governance stops at the edge of the index.

Article 10 also links to your risk process. The risks found in the data review feed the risk management system under Article 9 of the EU AI Act, and the logs that show which source was read on each run are the same records Article 12 expects an agent to keep.

What will a supervisor or auditor ask?

• Which sources does this agent read, who owns each, and how often is each refreshed?
• How did you check that the test cases represent the people the agent serves?
• Show us the bias tests and what you changed as a result.
• If a source changes, how do you know the agent's behaviour has not changed with it?
• Can you show, for a given decision, exactly which version of which source the agent used?
• Who in your team understands these checks well enough to challenge them?

The last question connects to staff competence, which Article 4 on AI literacy makes a duty in its own right.

What does Article 10 not cover?

It does not regulate the general-purpose model's training data in your hands; that falls under the separate general-purpose model rules. It does not apply as a provider duty to agents that are not high-risk, although the same discipline is sound practice for any agent that touches customers or money. It does not replace GDPR: a dataset can meet Article 10 and still breach purpose limitation or data minimisation. And it does not tell you what an agent may do with the data, which is a question of bounds and oversight, not quality. We map the wider set of duties in our guide to AI agent regulation, mapped to controls.

This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.

Where Pryme fits

In Pryme, every fact reaching an agent arrives through the Pryme Context Protocol stamped with its origin: sealed, signed, declared or external. That makes a deployer's source register enforceable rather than descriptive. An agent can quote an external figure, but an external claim cannot authorise a payment, and the record of each run shows which source and class decided.