Your firm is almost always the controller and the AI agent platform a processor. You decide why customer data is used and which jobs the agent does; the platform runs the agent on your documented instructions. If the platform uses your data for its own purposes, such as improving its products, it becomes a controller for that use.
What does GDPR require of controllers and processors?
GDPR splits responsibility by who decides. The controller determines the purposes and the essential means of processing: why personal data is used, whose data, and what happens to it. The processor handles personal data on the controller's behalf and on its instructions, and may not use it for anything else.
The controller carries the main duties. It must have a lawful basis under Article 6, meet the Article 5 principles, keep records of processing under Article 30, and run a data protection impact assessment under Article 35 where processing is likely to be high risk. A processor has its own direct duties too: security, records of the processing it carries out for controllers, using only authorised sub-processors, and helping the controller meet its obligations.
The relationship must be governed by a binding written contract. That contract is not a formality. It is the document a supervisor reads first when something goes wrong between the two parties.
Who does this apply to?
Any organisation that deploys an AI agent on personal data within GDPR's reach, and any vendor whose platform runs that agent. It applies equally under UK GDPR and the Data Protection Act 2018, where the same split of roles is used.
The label in the vendor's terms does not decide the role. Facts do. If a platform calls itself a processor but decides to retain prompts for its own analytics, it is acting as a controller for that analytics, whatever the paperwork says.
What changes when the system is an agent that acts?
A chat tool that answers questions touches personal data lightly. An agent that reads a customer file, drafts a letter, updates a record and files a case touches it at every step. Three features of agents make the role analysis sharper.
The agent's brief is the instruction. Under GDPR a processor acts on documented instructions. For an agent platform, those instructions are the agent's role, its sources, the systems it may connect to and the actions it may take. If you cannot export that brief, you cannot show what you instructed.
The chain of sub-processors is longer. A platform usually calls a model provider, a hosting provider and sometimes search or document services. Each is a sub-processor if it handles your customers' personal data. You need to know who they are and where they process.
Platforms may want to learn from your data. If a vendor uses your conversations or case files to tune its models or build benchmarks, it is pursuing its own purpose. That makes it a controller for that processing, and you need a lawful basis to disclose the data to it, which is often hard to find.
A platform that never updates model weights for a customer, and changes only the agent's brief, sources and bounds, keeps the processor role clean. That is a design choice worth asking about directly.
How do you meet the requirement?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Processing only on documented instructions | Agent brief, sources and permitted actions held as versioned configuration you approve | Exported brief history with approver and date of each change |
| No use for the vendor's own purposes | Contract clause barring training or product improvement on your data; technical setting confirmed | Signed clause; configuration evidence; vendor attestation |
| Confidentiality of staff | Vendor staff access to customer data limited and logged | Access logs; confidentiality terms |
| Security of processing | Encryption, access control, segregation of customer data, tested regularly | Security report; penetration test summaries |
| Sub-processors authorised in advance | Published list with notice of changes and a right to object | Current list; change notices received |
| Help with data subject rights | Ability to find, export and delete a person's data across agent memory, logs and records | Request log showing completion |
| Help with breaches and DPIAs | Breach notice terms; vendor input to your DPIA | Contract terms; DPIA annex |
| Deletion or return at the end | Defined exit process covering memory, logs and backups | Deletion certificate |
| Audits and information | Right to audit, satisfied by reports plus targeted questions | Audit reports; question responses |
A SOC 2 report for an AI agent platform helps with the security rows, but it does not answer the instruction and purpose rows. Those need to be in the contract and visible in the product.
What will a supervisor or auditor ask?
- Which agents process personal data, and for each, who is controller and who is processor?
- Where is the contract, and does it cover every point GDPR requires?
- How do you know the vendor does not use your data to train or improve its models?
- Who are the sub-processors, and in which countries do they process?
- Can you show the exact instructions the agent was running under on a given date?
- If a customer asks for erasure, can you remove their data from the agent's memory and the vendor's systems?
The fourth and fifth questions are where agent deployments most often fall short. Firms sign a standard processing agreement and never check whether the brief that governs the agent is exportable and versioned.
What does the controller-processor split not cover?
It does not decide whether the processing is lawful. That remains your job as controller, including whether the agent's assessments amount to profiling under GDPR. It does not transfer accountability: appointing a processor does not move your duties to it. It does not address the quality of the agent's decisions, which is a governance question that frameworks such as the NIST AI RMF address; our piece on why regulated firms use the voluntary NIST AI RMF for agents explains how. And it does not settle international transfer rules, which need their own assessment.
For how this fits with the other rules that reach agents, 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.
Where Pryme fits
Pryme Intelligence does not update model weights for any customer. Qualification changes the agent's brief, sources, bounds and certification, which keeps your data out of the vendor's purposes. Each agent's brief is versioned, and every verdict the agent receives is filed in an append-only record, so you can show the instructions in force and what the agent did under them on any given day.
Questions people ask
Can an AI agent platform and its customer be joint controllers?
Yes, if both decide the purposes and means together, for example where a vendor and a firm jointly design a service and both use the data for their own ends. Joint controllers need an arrangement setting out who does what. Most agent deployments are not joint control.
Is the model provider behind the platform a processor too?
If it handles your customers' personal data in prompts or outputs, it is a sub-processor of the platform. The platform should list it, flow down the same terms, and tell you where it processes data.
Does using pseudonymised data avoid the controller-processor question?
No. Pseudonymised data is still personal data if it can be linked back to a person with other information. It reduces risk and is good practice, but the contract and role analysis still apply.