An agent that can read a customer record, call a tool and write the result back into a system changes the compliance job. The question is no longer whether a model can produce useful text. It is whether the organisation can account for each personal-data use, control the agent’s permissions and explain its decisions when something goes wrong.
That is a manageable adoption problem. GDPR does not prohibit organisations from using agents. It requires the same disciplines that apply to other processing: a lawful, fair and transparent purpose; data minimisation; appropriate security; and evidence that the organisation has put those duties into practice. The ICO’s current AI and biometrics strategy explicitly identifies agentic AI as raising questions about accountability and redress.
Start with the job the agent will do
“Agentic AI” is not a GDPR role or a special legal category. In practice, it describes a system that can pursue a task through connected tools. A support agent might retrieve an account history, draft a reply, create a ticket and offer a refund within a set limit. An HR agent might search a personnel system and prepare a manager briefing. The same model can present different data-protection risks in each deployment because the data, permissions and consequences differ.
The adoption record should therefore begin with a defined use case: affected people, data categories, systems the agent can reach, actions it can take, human approvals and stop conditions. This gives the privacy lead and technical owner something concrete to assess. It also prevents a vague approval for “AI” being stretched to cover a new connector or a new automated action.
Allocate responsibility across the tool chain
A deployer may use an orchestration platform, a model provider, a CRM, a search service and a monitoring tool in one workflow. Calling every supplier a processor without examining the activity is risky. Under the EDPB’s controller and processor guidelines, the assessment is functional: who determines the purposes and means of the particular processing? A contract label helps record the relationship; it does not decide it by itself.
For example, a retailer may decide that an agent can handle delivery queries and select the CRM fields it may read. That points to the retailer acting as controller for that deployment. A service provider processing those records solely on documented instructions may be a processor for that activity. If a provider uses information for a separate purpose, such as product improvement or its own analytics, the organisation needs to examine that separate processing and the provider’s stated role.
Keep a chain-of-processing record for every live agent: the parties, systems, data flows, instructions, subprocessors, international transfers and decision owner. Update it when a tool, provider term or memory setting changes. This is ordinary accountability work, applied to a workflow that can change rapidly.
Make memory and retention intentional
Agents often create more than one record of an interaction. A prompt, session transcript, short summary, retrieval index, tool-call log, ticket note and vendor support log can each contain personal data. Teams should not assume a technical format is anonymous because it is hard to read. The ICO’s AI security and data-minimisation guidance says organisations should address data minimisation throughout the AI lifecycle.
For each store, name the owner, purpose, retention period, access group, deletion route and search method. A useful control is to separate short-lived task context from reusable memory. The latter needs a clear business purpose and a review point. If the team cannot explain why an agent retains a summary after the task ends, do not retain it.
Explain the processing and establish a lawful basis
A customer-facing service agent can make the use of personal data harder to explain because the agent may draw on several systems and act through tools. GDPR Article 5 requires processing to be lawful, fair and transparent, while Articles 13 and 14 set information duties for data subjects. The relevant GDPR principles and the ICO’s AI transparency guidance are a better starting point than generic supplier assurances.
Before launch, document the purpose for each processing step and the lawful basis that applies. Then make the notice match the system people will actually encounter: what the agent does, the personal data it uses, meaningful human contact where appropriate, and how a person can exercise their rights. For higher-risk processing, assess whether a DPIA is required. The ICO describes a DPIA as an important way to demonstrate accountability for an AI system processing personal data.
Treat prompt injection as an access-control test
Prompt injection is often discussed as a model-safety problem. For an agent with tools, it also tests whether the organisation has restricted access properly. A malicious instruction in a document or webpage could try to make an agent disclose information, search outside its task or take an unauthorised action. The exposure depends on the permissions that the organisation has granted, not on the wording of the prompt alone.
Article 32 requires controllers and processors to implement appropriate technical and organisational measures, taking account of risk. Apply that duty to the agent’s real powers: use least-privilege service accounts, separate testing from live data, restrict outbound destinations, require approval for consequential actions, log tool calls and test whether revoked access actually stops the agent. The ICO’s AI guidance covers security, data minimisation and governance as connected data-protection duties.
Put governance around changes, not paperwork
An approval at pilot stage will not cover every later connector, model setting or action. Give one senior owner authority to approve the use case, one technical owner responsibility for controls, and the privacy function a defined review route. The ICO’s accountability guidance says organisations are responsible for complying with data-protection law and demonstrating that compliance in AI systems that process personal data.
Set events that trigger reassessment: a new data source, new tool permission, changed retention, a move into a high-impact decision, a new provider purpose, or a material incident. For EU-facing deployments, assess the AI Act separately from GDPR. It includes an AI-literacy duty for providers and deployers in Article 4, while its high-risk obligations depend on the use case and other conditions in the Regulation. The AI Act text is the primary reference for that separate analysis.
Use DSAR visibility as one operating test
A subject access request does not define every agentic-AI risk, but it exposes weak records quickly. Article 15 gives individuals a right of access to personal data and related information. Run a synthetic request against one agent: can the response team identify relevant transcripts, summaries, tool inputs, outputs and downstream records without relying on an engineer’s memory? The site’s existing AI DSAR guide explains the rights-handling angle in more depth.
The point is not to disclose every system log automatically. The response team still needs to assess scope, third-party data and any lawful restriction. The test is whether the organisation knows where to look and who decides. ICO guidance on the right of access sets out the wider framework.
Agent adoption readiness checklist
- Write down the task, affected people, data categories and permitted actions.
- Map every system the agent reads from or writes to, including logs, queues and vendor support access.
- Allocate controller, processor or other roles activity by activity and record the evidence.
- Set purpose, lawful basis, retention and a deletion route for each memory layer.
- Limit credentials and require a person to approve actions with significant consequences.
- Complete or refresh the DPIA where the processing is likely to create high risk.
- Test a rights request, access revocation and a prompt-injection scenario before wider rollout.
- Reassess after each material change, and train the people who configure, supervise and use the agent.
Adopt agents with evidence, control and review
Start with one bounded workflow. Give it narrow permissions and a named owner. Keep a record that a colleague outside the build team can use to understand the data path and the decisions made. That creates room to improve the service without asking people to trust an opaque chain of tools. Teams that need a shared baseline can build it into their GDPR training and operating procedures.
