Data minimisation requires personal data to be adequate, relevant and limited to what is necessary for the purpose. For an AI agent, that means each capability sees only the fields its task needs, for the case in hand, for as long as the task lasts. Proving it means showing the access design, not asserting good intentions.
What does data minimisation require?
Data minimisation is one of the principles in GDPR Article 5. In substance, personal data must be adequate, relevant and limited to what is necessary in relation to the purposes for which it is processed.
All three words matter. Adequate means enough to do the job properly; minimisation is not a reason to make an agent decide on too little information. Relevant means connected to the purpose. Limited to what is necessary means no more than that.
GDPR also requires data protection by design and by default: measures built in so that, by default, only personal data necessary for each specific purpose is processed, including as to the amount collected, the extent of processing, the period of storage and accessibility. For agents, that is the stronger duty, because it is about design, not just practice.
Who does it apply to?
Every controller, for every processing purpose. A firm deploying agents is responsible for what those agents can see and do with personal data, even when the agent and its model come from vendors. Platforms acting as processors should make minimisation possible; the controller must use it.
Why is minimisation harder for agents?
Agents perform better with more context. Give an agent the whole customer file and it answers more questions correctly. That creates steady pressure to grant broad access, and broad access is the opposite of minimisation.
Four agent behaviours stretch the principle:
- Whole-record retrieval. An agent asked for a customer's address retrieves the full profile, including income, health notes and complaint history.
- Context accumulation. Over a long task, the agent's working context collects every tool result. Data needed for one step remains present in all later steps and in every prompt sent to the model provider.
- Cross-case carry-over. An agent handling several cases keeps data from earlier ones in memory or context.
- Speculative reading. Given search access, an agent may look through records it does not need to answer a question, because it can.
Each of these processes data that is not necessary for the purpose. And each widens what can go wrong: the more an agent can see, the more it can disclose by mistake or under manipulation. Minimisation is the first defence against data breaches caused by AI agents, not just a principle on paper.
How do you limit what each agent can see, and prove it?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Limited to what is necessary | Field-level access per capability: the agent receives named fields, not whole records | Field map per capability, approved by the data owner |
| Relevant to the purpose | Retrieval scoped to the case the agent is working on | Retrieval rules; records showing case ID on each read |
| By default | New capabilities start with no data access; access is added with justification | Change records with justification |
| Limit extent of processing | Context pruned between steps; only results needed later are kept | Agent configuration; context size records |
| Limit storage | Short retention for working context and caches; separate schedule for memory | Retention schedule; deletion records |
| Limit accessibility | Special category fields masked unless the capability needs them | Masking rules; exception approvals |
| Limit disclosure to processors | Identifiers replaced with tokens before prompts go to the model provider | Tokenisation records |
| Demonstrate | Periodic access review comparing what each agent can see with what it used | Access review reports |
The last row produces the most useful evidence. If an agent can see forty fields but has used only six in three months, the other thirty-four are not necessary. Removing them is minimisation; documenting the review is accountability.
Special category data deserves its own review; see GDPR special category data and AI agents. And memory needs particular care, because it is easy to keep more than intended; our answer to whether GDPR applies to what an AI agent remembers explains why.
How does minimisation interact with automated decisions?
Minimisation and adequacy can pull against each other in decisions about people. An agent that assesses affordability on too few fields may decide unfairly; one that reads everything may breach minimisation. The answer is to define, per decision type, which data is necessary and adequate, and to justify both. That definition also helps with automated decision-making under GDPR, where people are entitled to meaningful information about the logic involved.
What will a supervisor or auditor ask?
- What personal data can this agent see? Why does it need each item?
- How is access limited to the case it is working on?
- What data goes to the model provider in a typical prompt?
- When did you last review access against use, and what did you remove?
- How do you keep special category data away from agents that do not need it?
How does this compare outside the EU?
The US has no general minimisation principle at federal level, but financial privacy rules under GLBA restrict sharing and require safeguards, and state laws such as California's CCPA as amended by the CPRA include purpose and proportionality limits. Firms running agents in both markets usually find the GDPR design satisfies both; see whether GLBA applies to AI agents handling customer data.
What does minimisation not cover?
It does not set specific field lists; you decide what is necessary and justify it. It does not override other obligations to keep data, such as financial record-keeping. It does not make the data accurate or the processing fair. And it does not decide what actions an agent may take with the data it sees. For the full map, see AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Does minimisation stop us giving agents full customer files?
Usually, yes. Unless every field is necessary for every task the agent performs, full-file access processes more than needed. Scope access to fields and cases.
Is pseudonymisation enough for minimisation?
It helps, especially for data sent to model providers, but pseudonymised data is still personal data. Minimisation asks first whether the data is needed at all.
How often should agent access be reviewed?
On every change to an agent's capabilities or sources, and on a set cycle otherwise. Comparing what an agent can see with what it actually used is the quickest way to find excess.