Among EU enterprises with 10 or more employees that had ever considered using AI, 53.61% name a lack of clarity about legal consequences as a reason they do not use it — a larger share than those citing data-protection concerns. That uncertainty is answerable. GDPR still applies when an agent does the work, and the obligations attach to specific agent actions: reading a mailbox, storing a summary, sending a message, calling an external service. This guide maps those actions to the articles they trigger. It is not legal advice.
GDPR did not change when agents arrived. What changed is where the obligations land: on actions no person watched, taken by software that picks its own steps.
Eurostat's 2025 figures put lack of relevant expertise at the top of the reasons EU enterprises give for not using AI, at 70.31%. Legal uncertainty follows at 53.61% — ahead of data-protection and privacy concerns at 52.72%. Legal doubt outranks privacy fear, and the two are usually treated as one problem. The wider picture of AI adoption across European enterprises shows the same size gap behind both numbers.
This guide answers the legal-clarity half for one specific case: a European business running an AI agent that touches customer or client data. It maps what the agent does — read, store, send, transfer, retain — to the GDPR obligations each action engages. For the underlying distinction between a model, an agent, and a workflow, start with what an AI agent is. For the separate EU AI Act questions, the EU AI Act deployer guide is the owner.
This guide is not legal advice, not a compliance assessment, and not certification.
Which GDPR principles an agent engages first
The GDPR's obligations sit in Article 5, and an agent engages four of them harder than a static tool does.
Purpose limitation (Article 5(1)(b)) requires data to be "collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes." An agent that rewrites its own plan mid-run can drift past the purpose it was given.
Data minimisation (Article 5(1)(c)) requires data to be "adequate, relevant and limited to what is necessary." An agent granted access to a whole mailbox, rather than one label, fails this at the connection step — before it processes anything.
Storage limitation (Article 5(1)(e)) requires data to be kept "for no longer than is necessary." Agents produce derived artifacts — summaries, labels, embeddings — that outlive the task that created them.
Accountability (Article 5(2)) requires the controller to "be responsible for, and be able to demonstrate compliance with" the rest. Demonstrating compliance means producing evidence of what the agent did.
| Principle | GDPR article | What an agent changes |
|---|---|---|
| Purpose limitation | 5(1)(b) | The agent can extend its own plan past the stated purpose |
| Data minimisation | 5(1)(c) | Tools grant access at the account level; the agent works at the record level |
| Storage limitation | 5(1)(e) | Derived artifacts persist after the source task ends |
| Accountability | 5(2) | Evidence must cover automated actions no person observed |
Article 25(2) turns this into a default setting rather than an aspiration. It requires that "by default, only personal data which are necessary for each specific purpose of the processing are processed," and it names four dimensions: "the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility."
Those four dimensions are the same four levers you set when configuring an agent's permissions.
Configuring an agent is a controller decision
The business running the agent is normally the controller, and the act of configuring the agent is what makes it so.
The EDPB's Guidelines 07/2020 on the concepts of controller and processor, adopted in final form on 7 July 2021, establish that these are functional concepts. Paragraph 12 states that controller status "must in principle be determined by its actual activities in a specific situation, rather than upon the formal designation of an actor." Paragraph 28 closes the contractual escape route: "It is not possible either to become a controller or to escape controller obligations simply by shaping the contract in a certain way where the factual circumstances say something else."
Paragraph 40 is where this becomes concrete for agent deployers. The EDPB defines essential means — the decisions reserved to the controller — as those "closely linked to the purpose and the scope of the processing, such as the type of personal data which are processed ('which data shall be processed?'), the duration of the processing ('for how long shall they be processed?'), the categories of recipients ('who shall have access to them?') and the categories of data subjects ('whose personal data are being processed?')."
Read that list against an agent configuration screen. Which data sources the agent connects to. How long its memory and logs persist. Which tools and services receive the output. Whose records fall inside its scope. The EDPB's four essential-means questions are the four decisions made when scoping an agent.
GDPR still applies when an agent does the work. The controls have to move to runtime.
A regulator has now said something close to this directly. Spain's Agencia Española de Protección de Datos published Agentic Artificial Intelligence from the Perspective of Data Protection (V1.1, February 2026), a 71-page guidance document addressing agents specifically. It states that the controller "is the one who, alone or jointly with others, determines the purposes and means of the processing, regardless of the form in which such means, whether they are agentic AI systems or others."
The AEPD goes further on the design point: "The level of autonomy of the agent in the processing is a design decision of the controller." And on minimisation: "Data minimisation must be considered from the design of the processing and transferred to the design or configuration of the agents."
Configuration is where the obligation lands. That is a supervisory authority's position, not an inference. The specific mapping onto the EDPB's four essential-means questions remains YardWork's reading — the 2021 guidelines predate agentic systems and do not mention them — but the underlying principle now has agent-specific regulator support.
The vendor's role is not fixed either. Writing in the IAPP in October 2025, Keivan Navaie, Professor of Intelligent Networks at Lancaster University School of Computing and Communications, puts it directly: "In an agentic stack, roles can differ per use. A plugin may act as your processor on one call and determine purposes and means on the next." Article 28(10) supplies the consequence: "If a processor infringes this Regulation by determining the purposes and means of processing, the processor shall be considered to be a controller in respect of that processing."
A signed data processing agreement records an intended arrangement. It does not determine what the agent did at 03:00 on a Tuesday.
Why the document-based compliance model breaks
Traditional compliance describes processing once, in advance, in a document. That model assumes the processing does not change between reviews. An agent breaks that assumption in three specific ways.
The plan changes mid-run. An agent given a goal selects its own steps. A data protection impact assessment written against the expected steps does not cover the ones the agent chose instead.
Tools get called that no assessment listed. An agent that can reach a translation or summarisation service will use it when the task seems to require it. Each call is potentially a disclosure to a recipient, and possibly a transfer under Chapter 5.
Derived data outlives its source. Summaries, classifications, and embeddings persist in memory stores after the originating task closes. The AEPD is blunt about where this data ends up: the agent's memory stores personal data, and "the logs will store information about both the users of the agentic AI and the people subject to the processing, it could even store data on people who should not be data subject." The logs are a processing record in their own right.
Navaie's article illustrates the compound failure with a scheduling agent. Asked to arrange a follow-up meeting, the agent reads a discharge note mentioning diabetes and applies an "endocrinology" label. It sends the message to external summarisation and translation services and stores vector embeddings of the result.
One scheduling task has now produced special-category processing under Article 9, disclosures to services whose roles were never assessed, a probable cross-border transfer, and persistent derived artifacts that defeat storage limitation. This is an illustrative scenario from the article, not a reported enforcement case.
Article 9(1) prohibits processing of data "revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership," along with genetic data, biometric identification data, "data concerning health," and data concerning sex life or sexual orientation, unless one of the ten Article 9(2) exceptions applies. The agent in that example was never given health data as such. It derived a health inference from a document it was allowed to read.
Whether an inference of that kind constitutes Article 9 data is fact-specific and contested. What is not contested is that ordinary client contact data does not become special-category data merely because an agent processes it.
Mapping agent actions to obligations
Each thing an agent does engages a different set of articles. This is the map, and it is the part worth keeping.
| Agent action | Primary articles engaged | Control that answers it |
|---|---|---|
| Reads a mailbox, file store, or CRM | 5(1)(b) purpose, 5(1)(c) minimisation, 25(2) by default | Scope access to a label, folder, or record set — not the account |
| Stores a summary, label, or embedding | 5(1)(e) storage limitation, 25(2) storage period | Retention rule per memory tier, with deletion that runs on schedule |
| Sends an external message | 5(1)(a) transparency, 22 where the decision is significant | Human approval before external sends |
| Transfers data to a third-party service | Chapter 5, 28 processor terms, 30(1) recipient records | Named recipient list, transfer basis, and a record of each call |
| Retains logs and traces | 5(2) accountability, 30(1) records, 32 security | Action log with a defined retention period and restricted access |
| Infers a new attribute about a person | 9 where the inference is special-category | Block or route inference beyond the stated purpose |
Two entries deserve expansion, because generic guides get both wrong.
Article 22 is narrower than it is usually described. It gives a data subject "the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her." The AEPD is explicit that agents do not automatically engage it: "The incorporation of agentic AI systems in a processing may involve automation, but it will not always involve automated decisions within the meaning of Article 22 of the GDPR." Drafting an email, filing a document, or summarising a thread does not meet that bar. Rejecting an application might. Where Article 22 does apply, Article 22(3) requires safeguards including the right to obtain human intervention, to express a point of view, and to contest the decision — which is what an approval gate provides.
Where the human sits is a design choice, and the AEPD sets out four levels of agent autonomy:
| Autonomy level | Who acts | Practical effect |
|---|---|---|
| The agent proposes, the human operates | Human | The agent never touches the external system |
| The agent and the human collaborate | Both | Shared execution, shared judgement |
| The agent operates, the human is consulted or approved | Agent, gated | The approval gate that Article 22(3) safeguards resemble |
| The agent operates, the human observes | Agent | Oversight is after the fact, not before |
Choosing a level is not a technical preference. It decides whether a person can intervene before an action lands.
Article 30(5) rarely rescues a small business running an agent. The exemption applies to organisations with fewer than 250 employees, but it fails if any one of three conditions is met: the processing is likely to result in a risk to rights and freedoms, the processing is not occasional, or it includes special categories of data. The middle condition is the one that bites. An agent that checks a mailbox every fifteen minutes is difficult to describe as occasional processing.
The agent's goal is a first-class object. When it proposes to expand what it touches — a new tool, a new data category, a new recipient — the platform must surface that change and route it to a human or block it. A static approval given at launch cannot carry an autonomous system through the decisions it makes afterwards.
Where the exemption fails, Article 30(1) applies in full: purposes of processing, categories of data subjects and of personal data, categories of recipients, third-country transfers, erasure time limits, and a general description of technical and organisational security measures.
Four controls that make this operable
Navaie proposes four build-once controls for agentic systems. They are an expert proposal rather than a legal requirement, and they map cleanly onto the obligations above.
| Control | What it does | Obligation it serves |
|---|---|---|
| Purpose locks and goal-change gates | Treats the agent's goal as "a first-class, inspectable object" and blocks or escalates when scope expands | 5(1)(b), 25(2) |
| End-to-end execution records | Keeps "a durable, searchable record" of plan, tool calls, data categories, destinations, and state updates | 5(2), 30(1) |
| Tiered memory governance | Separates "short-lived working memory" from "long-lived profiles or vector embeddings" and enforces timelines for each | 5(1)(e), 25(2) |
| Live controller and processor mapping | Maintains "a registry that resolves roles at runtime, ties each resolution to contractual hooks, and records cross-border pathways" | 28, Chapter 5, 30(1) |
In YardWork implementations, the equivalent controls are set during scoping rather than added afterwards. The documented practice is scoped tool access per workflow, per-client isolation and permission boundaries, an audit log of actions, approval flows for high-impact actions, and human review before external sends, posts, writes, or commits. Those controls are scoped per engagement. They are a description of implementation practice, not a compliance guarantee, an audit, or certification.
The broader control design — permissions, change control, failure review, scope limits — belongs to the AI agent governance owner. For the mechanics of the approval step itself, what approval workflows do in an AI agent system covers the gate, the timeout, and the fallback.
Questions to put to a provider before launch
The useful provider questions are the ones whose answers become evidence. Vague reassurance is not evidence.
On roles. For each connected tool and model service, are you acting as our processor, and on what instruction? Which calls, if any, do you make for your own purposes? A provider that cannot separate these is describing Article 28(10) risk.
On recipients and transfers. Name every third party that receives personal data during a run, including model, summarisation, translation, and enrichment services. In which country is each processed? What is the transfer basis?
On retention. How long is each memory tier kept — working context, conversation history, embeddings, logs? Does deletion remove derived artifacts, or only the source record?
On evidence. Can you produce, for a specific date, what the agent did, which data categories it touched, which tools it called, and what it sent? Article 30(1) and Article 5(2) both need this to exist.
On revocation. What are the steps to cut an agent's access to one tool, and how long do they take? What happens to data already held?
On security. Article 32(1) requires "appropriate technical and organisational measures to ensure a level of security appropriate to the risk," and names encryption and pseudonymisation, ongoing confidentiality and resilience, restoration after an incident, and "a process for regularly testing, assessing and evaluating the effectiveness" of those measures. Ask which of these apply to the agent's stored credentials and retained context specifically, not to the platform in general.
Keeping the map current
Every legal statement in this guide carries a date, and dates are the part that goes stale.
The GDPR text is stable. Regulator guidance is not, and the agent-specific layer is moving fast. The EDPB Guidelines 07/2020 were adopted on 7 July 2021 and predate agentic systems entirely; they say nothing about agents. The AEPD's agentic AI guidance is at V1.1, dated February 2026 — a version number that signals revision, not settlement.
National supervisory authorities diverge, and they move at different speeds. Spain has published agent-specific guidance; most member states have not. Each authority publishes its own mandatory-DPIA list and its own interpretations. The AEPD's positions are authoritative in Spain and persuasive elsewhere, not binding across the EU. A conclusion that holds in one member state may not hold in another, and this guide does not resolve those differences.
The UK is a separate regime. The ICO's Guidance on AI and data protection was updated on 15 March 2023, and the page now carries a notice that "due to changes made by the Data (Use and Access) Act, this guidance is under review and may be subject to change." UK GDPR is not EU GDPR, and the gap between them is widening.
A practical review cadence: re-check the supervisory authority's guidance and any DPIA list every six months, and re-check whenever the agent gains a new tool, a new data category, or a new recipient. The last of those is the one that matters most, because it happens without a calendar reminder.
Where a specific classification, lawful basis, or transfer question has real consequences, it requires a qualified data protection professional. This guide organises the questions. It does not answer them for a specific business.
Frequently asked questions
Is my business the controller if an AI agent acts autonomously? Normally yes. The EDPB's Guidelines 07/2020 state that controller status follows an actor's actual activities rather than the formal designation in a contract. A business that decides why the agent runs and what data it may reach is determining the purposes and means of that processing. Autonomy in execution does not move that decision to the vendor.
Do we need a DPIA before launching an AI agent? It depends on the processing, not on the word "agent". Article 35(1) requires a DPIA before processing that is likely to result in a high risk to rights and freedoms, and specifically mentions new technologies. Article 35(3) names systematic extensive automated evaluation, large-scale special-category processing, and systematic large-scale monitoring of public areas. Individual EU supervisory authorities also publish their own mandatory-DPIA lists, which should be checked directly.
Does the GDPR small-business exemption cover records of processing? Rarely, once an agent is running. Article 30(5) exempts organisations with fewer than 250 employees, but the exemption fails if any one of three conditions applies: the processing is likely to result in a risk to rights and freedoms, the processing is not occasional, or it includes special categories of data. An agent that runs on a schedule is difficult to describe as occasional processing.
Can we run an AI agent with customer data outside the EU? Transfers outside the EU are permitted under Chapter 5 of the GDPR, but they must be documented and grounded in a valid transfer mechanism. The practical difficulty with agents is knowing that a transfer happened. An agent calling a summarisation or translation service may move personal data across a border without that call appearing in any transfer record.
Is this guide legal advice? No. This guide maps agent actions to the GDPR articles they commonly engage, and separates official text from guidance and interpretation. It cannot classify a specific business, resolve a specific processing operation, or replace advice from a qualified data protection professional.
Notes
- GDPR text, Articles 5, 9, 22, 25, 28, 30, and 35, accessed August 11, 2026. Used for all quoted official text and article references.
- EDPB, Guidelines 07/2020 on the concepts of controller and processor in the GDPR, final version adopted 7 July 2021, accessed August 11, 2026. Paragraphs 12, 28, 29, 39, and 40 are used for the functional role test and the essential-means definition.
- AEPD (Agencia Española de Protección de Datos), Agentic Artificial Intelligence from the Perspective of Data Protection, V1.1, February 2026, retrieved August 11, 2026. Used for the controller-determination and design-decision statements, the four autonomy levels, the Article 22 scope point, and the memory-and-logs passage. AEPD guidance is authoritative in Spain and persuasive, not binding, elsewhere in the EU.
- Keivan Navaie, "Engineering GDPR compliance in the age of agentic AI," IAPP, 8 October 2025, accessed August 11, 2026. Used for the four build-once controls, the per-call role quote, and the scheduling-agent scenario. The scenario is illustrative and is not a reported enforcement case.
- Eurostat, dataset
isoc_eb_ai, "Artificial intelligence by size class of enterprise", retrieved via the Eurostat dissemination API on August 11, 2026; dataset last updated 15 June 2026. Figures are forgeo=EU27_2020,time=2025,size_emp=GE10,nace_r2=C10-S951_X_K, unitPC_ENT_AI_EC— the percentage of enterprises that had ever considered using any of the measured AI technologies. Indicators:E_AI_BLE70.31%,E_AI_BLEG53.61%,E_AI_BCDP52.72%. The dataset measures a range of AI technologies and must not be read as an AI-agent adoption or compliance rate. - ICO, Guidance on AI and data protection, updated 15 March 2023, accessed August 11, 2026. Cited only for the UK divergence boundary and the guidance's under-review status. UK GDPR is not authority for an EU obligation.
- The action-to-obligation map, the essential-means reading, the provider question set, and the review cadence in this guide are YardWork work-product. They are educational and must not be presented as legal advice, a compliance assessment, or certification.