GDPR and AI Agents: A Practical Compliance Guide

What counts as personal data when an AI agent is involved?

Personal data is any information relating to an identified or identifiable person. That definition is deliberately broad, and AI agents stress-test it because they pull context from many places at once. An agent that drafts a reply to a Zendesk ticket sees the customer's name, their email, their order history, and possibly free-text complaints that contain health or financial details. An agent that updates a Salesforce opportunity touches contact records, notes, and the identity of the rep who owns the deal.

Two categories deserve extra care. Special category data (Article 9) covers health, biometrics, ethnicity, religion, sexual orientation, and political views, and it carries a higher bar for processing. The trap is that this data often arrives unannounced inside free text, like a support message that mentions a medical condition. Your agent does not know it crossed a line unless you have controls that catch it.

The practical takeaway is to map, before you deploy, exactly which fields and tools the agent can reach and what personal data flows through each one. If you cannot describe the personal data your agent processes, you cannot claim a lawful basis for it, and you certainly cannot answer a data subject who asks what you did with theirs.

Choosing a lawful basis for AI agent processing

Every act of processing needs a lawful basis under Article 6, and for AI agents the two that come up most are legitimate interests and contract. Consent exists too, but it is a poor fit for back-office automation because it must be freely given, specific, and revocable, which is hard to engineer for an agent acting across many records.

Legitimate interests (Article 6(1)(f)) is the workhorse for internal operational agents, such as one that summarises support tickets for an agent or keeps a CRM clean. To rely on it you must run and document a Legitimate Interests Assessment: identify the interest, show the processing is necessary to achieve it, and balance it against the rights and reasonable expectations of the people whose data is involved. The European authorities are clear that the interest must be real and present, not hypothetical, and that you must consider whether a less intrusive method would do the job. That last test maps neatly onto good agent design: scope the tools tightly and you strengthen your balancing test at the same time.

• Contract (Article 6(1)(b)) fits when the agent's processing is genuinely necessary to deliver a service the data subject signed up for, such as an agent that processes a customer's own order status request.
• Legitimate interests fits internal operational automation, but only if you complete and keep the three-part assessment and can show people would not be surprised by the processing.
• Consent fits narrow, user-facing cases where the person actively opts in, and it must be as easy to withdraw as it was to give, which is operationally heavy for agents.
• Legal obligation or vital interests rarely apply to commercial AI agents, so do not reach for them to paper over a weak basis.
• Special category data needs a second condition under Article 9 on top of your Article 6 basis, so flag any workflow that may touch health, biometric, or other sensitive data.

Data minimization and purpose limitation in practice

Data minimization (Article 5(1)(c)) says personal data must be adequate, relevant, and limited to what is necessary. AI agents push against this principle because the easy design is to hand the model everything and let it figure out what matters. That is the design a regulator will question. The compliant pattern is least-privilege: give the agent access only to the fields and tools a specific task needs, and nothing more.

Purpose limitation (Article 5(1)(b)) is the sibling principle. Data collected for one purpose cannot be quietly reused for another that the person would not expect. If you gathered support emails to resolve tickets, pointing an agent at that same data to score sales leads is a new purpose that needs its own lawful basis and, often, a fresh notice to the people involved. This is exactly where AI projects drift, because the data is already sitting there and reusing it feels free.

A worked example makes it concrete. A support rep asks an AI agent to summarise a customer's open tickets before a call. A minimized agent reads only that customer's ticket subjects, statuses, and the rep's own notes, returns a three-line summary, and writes nothing back. A sloppy agent queries the whole ticket table, ingests every customer's complaints into one context window, and posts the summary to a public channel where the whole company can read another customer's private grievance. Same feature, two very different compliance outcomes, and the difference is entirely in how the tools were scoped.

Article 22 and automated decision-making: where the agent must stop

Article 22 is the clause that most directly shapes how much authority you give an AI agent. It gives people the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significant effects, such as denying credit, terminating an account, or rejecting a job application. There are three narrow exceptions: the decision is necessary for a contract, it is authorised by law, or it rests on the person's explicit consent. Even when an exception applies, the person keeps the right to obtain human intervention, to express their view, and to contest the outcome.

The key phrase is solely automated. A human who rubber-stamps the agent's output does not cure the problem; supervisory authorities have made clear that the human involvement must be meaningful, by someone with the authority and information to actually change the decision. This is the strongest argument for human-in-the-loop approvals on consequential actions: they keep a real person in the decision and create the record that proves it.

In practice this means you should classify your agent's actions by impact. Reading data and drafting text are low-stakes. Updating a non-sensitive CRM note is medium. Closing a customer's account, issuing a refund above a threshold, or anything that legally or significantly affects a person is high-stakes, and those actions should route to a human for approval rather than execute on their own. Note that the EU AI Act adds a separate layer on top of this for systems it classifies as high-risk, so for decisions about individuals you may face cumulative obligations under both regimes.

Honoring data subject rights: access, erasure, and the rest

GDPR gives people enforceable rights over their data, and your AI agent has to be compatible with them rather than an obstacle. The two that come up most often are the right of access (Article 15), where a person asks what data you hold and how it is used, and the right to erasure (Article 17), the so-called right to be forgotten. If an agent has copied personal data into notes, summaries, or a separate store, that copy is in scope for both requests, which is one more reason to minimize what the agent writes and where.

The right to object (Article 21) matters specifically when you rely on legitimate interests: a person can object to that processing, and you must stop unless you can show compelling grounds that override their rights. There is also the right to rectification, so if an agent wrote something inaccurate into a record, you need to be able to find and fix it. Each of these is far easier to satisfy when you can answer a simple question: what did the agent read, what did it write, and where did the output go.

That is the operational case for audit logging. When a data subject access request lands, a team without records spends days reconstructing what happened. A team with a clear log of agent actions can search for the person's identifiers, list every record the agent touched, and respond inside the one-month statutory window. Treat the audit trail as a compliance asset, not a debugging afterthought.

DPAs, sub-processors, and the vendors behind your agent

When you use a third-party platform to run your AI agent, that vendor is processing personal data on your behalf, which makes them a data processor and triggers Article 28. You need a Data Processing Agreement in place that sets out the scope, duration, and purpose of the processing, requires the processor to act only on your instructions, imposes confidentiality and security obligations, and commits them to help you respond to data subject requests and breaches.

Sub-processors are the part teams overlook. Your agent platform may rely on other services underneath it, and each of those is a sub-processor that must be disclosed and bound by equivalent terms. You have the right to be informed of changes and to object. If any of those parties processes data outside the EEA, you also need a valid transfer mechanism such as Standard Contractual Clauses plus a transfer risk assessment. Ask every vendor for their sub-processor list and their data residency options before you sign, not after.

Accountability: how approvals and audit logs carry the weight

Accountability (Article 5(2)) is the principle that pulls the others together: you must not only comply, you must be able to demonstrate it. For an AI agent, demonstration comes down to two things you can actually produce on demand. The first is a record of your decisions, like your lawful basis, your Legitimate Interests Assessment, and your Data Protection Impact Assessment for higher-risk processing. The second is a record of what the agent did in production.

Human-in-the-loop approvals and audit logs are not just risk controls, they are accountability evidence. An approval step proves a real person stood between the agent and a consequential action, which is exactly what Article 22 asks for. An audit log proves what data was touched and by which decision, which is what a regulator or a data subject will want to see. Together they turn 'trust us, the agent is careful' into 'here is the record'.

A DPIA is worth singling out. GDPR requires one when processing is likely to result in a high risk to people's rights, and large-scale automated processing of personal data, including profiling, is a textbook trigger. The DPIA is also the natural place to write down your minimization choices, your approval gates, and your retention rules, so it doubles as both a compliance document and a design spec for the agent.

Common GDPR mistakes when deploying AI agents

Most GDPR problems with AI agents are not exotic. They come from a handful of predictable shortcuts, and each one is avoidable with a design choice made early.

• Giving the agent broad read access because it is convenient, which violates data minimization and weakens any legitimate interests argument you might make later.
• Reusing data collected for one purpose to power a different agent, which breaches purpose limitation unless you establish a fresh basis and tell the people involved.
• Letting the agent take consequential actions with no human gate, which risks running afoul of Article 22 and leaves no meaningful human in the decision.
• Treating a human who clicks approve without context as compliance, when the rubber-stamp is exactly what supervisory authorities say does not count.
• Logging nothing or logging too much, where the first leaves you unable to answer access requests and the second creates a fresh pile of personal data to protect.
• Skipping the DPIA and the vendor DPA because the project felt small, then discovering the processing was high-risk and the paperwork should have come first.

A decision framework for how much autonomy to grant

The single most useful GDPR decision for an AI agent is how much it may do on its own. Tie that decision to the impact of the action on real people, not to how impressive the demo looks.

Use full automation only for processing with no legal or significant effect on individuals, where the data is minimized and the output stays inside an appropriate audience. Use human-in-the-loop approval for any action that could significantly affect a person, anything touching special category data, and anything that is hard to reverse. When in doubt, gate it, because an approval step costs seconds and an Article 22 complaint costs months.

The chart below shows, directionally, how scoping and approval choices shift your exposure. The numbers are illustrative and meant to make the pattern visible, not to serve as a benchmark for any specific deployment.

Your practical GDPR checklist for AI agents

Pulling the guide together, here is a working checklist you can take into a deployment review with your DPO and counsel. It does not replace legal advice, and it is not exhaustive, but it covers the questions that catch most teams. A platform built for governed action, where approvals, role-based access, and audit logs are first-class rather than bolted on, makes most of these far easier to satisfy in practice. Onpilot was designed around exactly that: least-privilege access, human-in-the-loop approvals, and an audit trail for every action an agent takes.

• Map the personal data: list every field and tool the agent can reach, and flag anything that could be special category data.
• Fix a lawful basis per workflow and document it, including a Legitimate Interests Assessment where you rely on legitimate interests.
• Apply least privilege so the agent reads and writes only what each task needs, satisfying data minimization by design.
• Confirm purpose limitation: no agent reuses data collected for a different purpose without a fresh basis and notice.
• Classify actions by impact and route consequential ones to a human approver, keeping you on the right side of Article 22.
• Stand up audit logging and a deletion path so you can answer access, rectification, objection, and erasure requests inside the deadline.
• Get a signed DPA and the sub-processor list from your platform vendor, and confirm data residency and transfer mechanisms.
• Run a DPIA for higher-risk processing and keep it current as the agent's scope changes.