You are almost always the controller, because you decide why the personal data is processed. Your supplier's role varies. The Information Commissioner's Office says a contract does not settle it, and that deployers of closed-access models are more likely joint controllers than controllers using a processor. Running the model on hardware you own removes the outside AI processor.
What is the difference between a controller and a processor?
The controller decides why personal data is processed and, in broad terms, how. The processor handles that data only on the controller's documented instructions and does nothing with it for its own ends. The UK GDPR definitions turn on one word: determines.
Where two organisations jointly determine purposes and means they are joint controllers under Article 26, and must agree a transparent arrangement covering who does what, including who answers individuals. A processor that steps outside instructions and starts determining purposes and means of its own becomes a controller for that processing under Article 28(10), with the liability that follows.
None of this is a label you pick. It is a finding of fact about who is in charge.
Which role do you hold when you use an AI supplier?
You are the controller, in almost every case. You decided to run the data through a model, what question the model would answer, and how long to keep the output.
That holds whether you are a lender screening applications, an insurer triaging claims, a local authority handling licence renewals or a firm reviewing disclosure. The supplier built a general capability. You pointed it at named people for a purpose you chose. The purpose is yours, so the controllership is yours, along with the duties that bite hardest on automated decisions.
Buyers go wrong by assuming the rest follows: that if they are the controller, the supplier must be their processor. It does not. The supplier's role is a separate question, and the answer is often not processor.
When does an AI supplier become a controller in its own right?
As soon as it processes your data for a purpose of its own that you did not set. That is the whole test.
The usual candidates are retention of inputs and outputs for product improvement, retraining or fine tuning on customer traffic, human review of samples for quality, abuse monitoring wider than you asked for, and usage analytics. Each is a purpose the supplier decided. For that processing it is a controller, not your processor, whatever the order form says. Article 28(10) is explicit: a processor which determines purposes and means is considered a controller for that processing.
This matters commercially, not only legally. If your supplier is a controller for part of the flow, you cannot discharge your accountability by pointing at its contract, and there is a second controller in the chain with its own lawful basis and its own duties to individuals.
Why does the ICO point towards joint controllership for closed-access models?
Because in a closed-access deployment the buyer cannot see or change the things that decide how the processing works. The Information Commissioner's Office, in its response to the consultation series on generative AI, says roles must reflect "the actual levels of control and influence over the purposes and means" of each separate processing activity, and that a contract does not necessarily determine whether an organisation is a controller, a joint controller or a processor.
The consequence is uncomfortable. The developer has already fixed the training data, the architecture, the safety behaviour, the logging and the retention. Those upstream decisions shape every inference you later run. You supply the purpose and have little influence over the means. The ICO's position is that this looks more like joint controllership between developer and deployer than a clean controller to processor split, and that a developer cannot sensibly claim to be a mere processor for processing it has largely predetermined.
Joint controllership is not a technicality. It means an Article 26 arrangement, the essence of which must be available to individuals, and individuals may exercise their rights against either party. Many AI procurements have no such arrangement, because both sides assumed a processor relationship the facts do not support.
The analysis is fact specific: two deployments of the same category of model can land differently depending on configuration, retention and what the supplier does with traffic.
What must the contract say if the supplier is your processor?
Article 28(3) sets a floor, and the ICO lists what the contract must contain: processing only on your documented instructions, a duty of confidence on anyone handling the data, security measures meeting Article 32, no sub-processor without your written authorisation, help with individuals' rights, assistance with your own security, breach and impact assessment duties, deletion or return of the data at the end of the contract, and submission to audits and inspections.
Article 28(1) puts a duty on you before any of that applies. You may use only a processor that provides sufficient guarantees it can meet those requirements. Sufficient guarantees is not a signature. It is something you have to show you assessed, and the UK and EU GDPR position is no softer for AI.
A data processing agreement is a promise about future behaviour. It is not evidence of past behaviour. When a regulator asks what happened to one specific record in March, a contract cannot answer, which is why a zero data retention promise does less work than buyers expect.
Who answers a subject access request or an erasure request?
You do. As controller you own the response, the one month deadline in Article 12(3), and the extension of up to two months for complex requests.
To answer properly you need to know which personal data entered the model, on whose behalf, at what time, what came back, who relied on it, and whether any copy still sits with the supplier or a sub-processor. Most AI deployments cannot produce that. Prompts land in a log nobody structured, outputs get pasted into a case note, and the retention position lives in a PDF from last year. That gap is what an AI audit trail exists to close.
If the supplier is a joint controller, the individual can approach either of you, and you still have to know your own side. If it is a processor, its Article 28(3) duty is to help you respond, not to respond for you.
What changes when the model runs on hardware you own?
The processing stays inside your own controllership, and there is no outside AI processor in the flow, because no personal data leaves your estate to reach a model.
That removes a class of question rather than answering it. No third party controllership analysis for inference. No international transfer assessment for prompts. No retention promise to take on trust. No sub-processor list to keep current. What remains is the work only you can do: lawful basis, necessity, a DPIA where one is required, security, and honest records.
This is what we built at Mickai®. The Sovereign Intelligence Operating System runs on hardware the customer owns, offline capable, with no data egress. Its Open Audit Record seals every consequential action under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024, and an auditor verifies an exported record offline with a public key, using tools that are not ours. That is tamper-evident, not tamper-proof. We cannot stop somebody altering a record. We can make certain that altering it breaks verification, and that the break is visible to a third party who does not have to take our word for it. Consequential actions wait for a named person to approve them, so the record shows a human making the call rather than a system.
Running on your own hardware does not make you compliant, and removes none of the obligations you already had. It changes who is in the room, not what the law asks of you. Cloud stays genuinely valuable for work that is not regulated. My argument is not with the companies building the compute or the cloud layer. It is with the assumption that a regulated organisation must rent its intelligence, ship data offsite and take a vendor's word for what happened to it. A closed beta is open, with one regulated company onboarding as a design partner.
What should you check before you sign?
Ask the supplier, in writing, what role it claims for each processing activity and why. Then test that answer against what it actually decides.
Five questions do most of the work. What happens to inputs and outputs: retained, logged, sampled by humans, used for evaluation, used for training? Which sub-processors, in which countries, and how are changes notified? Are the full Article 28(3) terms present, or a summary that gestures at them? If a regulator asks in two years how one decision was reached, can you evidence it without asking the supplier? And if the honest answer is that the supplier holds more influence over the means than you do, who is drafting the Article 26 arrangement that position requires?
This is an explainer, not legal advice, and role allocation turns on facts. Take the facts of your own deployment to your data protection officer or counsel.
Frequently asked questions
Is our AI supplier automatically a data processor?
No. Processor status depends on whether the supplier only acts on your documented instructions. If it retains your inputs, trains on them, or reviews samples for its own purposes, it is determining purposes and means, which makes it a controller for that processing under Article 28(10). Check what it actually does, not what the order form calls it.
(remove this entire FAQ entry, leaving exactly five questions: "Is our AI supplier automatically a data processor?", "Does the contract decide whether a supplier is a controller or a processor?", "What contract terms does UK GDPR require for a processor?", "Who answers a subject access request when AI is involved?", "Does on-premises AI remove the processor relationship?". If the developer/development-stage point must be kept, append it to FAQ 1 instead: "The ICO also treats developers as controllers for the development stage of their models.")
Yes, if it decides to use them for its own purposes: retraining, evaluation, quality sampling or safety work beyond what you asked for. It then has its own lawful basis to establish and its own duties to the people in those prompts. The ICO also treats developers as controllers for the development stage of their models.
Does the contract decide whether a supplier is a controller or a processor?
No. The ICO is explicit that a contract does not necessarily determine whether an organisation is a controller, a joint controller or a processor. Roles must reflect actual control and influence over the purposes and means of each processing activity. A contract describing a supplier as your processor does not make it one if it behaves otherwise.
What contract terms does UK GDPR require for a processor?
Article 28(3) requires processing only on your documented instructions, a duty of confidence, security measures meeting Article 32, no sub-processor without your written authorisation, help with individuals' rights, assistance with your security, breach and impact assessment duties, deletion or return of data at the end of the contract, and submission to audits and inspections. Article 28(1) also requires you to use only processors offering sufficient guarantees.
Who answers a subject access request when AI is involved?
You do, as controller, within one month under Article 12(3), extendable by two further months for complex requests. A processor must help you but cannot answer for you. If the supplier is a joint controller, the individual may approach either party. You still need records showing what data entered the model and what came back.
Does on-premises AI remove the processor relationship?
It removes the outside AI processor, because no personal data leaves your estate to reach a model. You still have a software supplier, and support arrangements may involve processing, so scope those separately. What it does not remove is your own accountability: lawful basis, necessity, a DPIA where required, security and records all remain yours as controller.
Related briefings
Data protection and UK GDPR
- UK GDPR and AI: Does Your Data Have to Stay in the UK?
- UK Data Storage vs AI Processing: What Is the Difference
- Right to Erasure in an AI Knowledge Base: How to Comply
- Employee Pasted Client Data Into AI: Is It a Breach?
- AI Call Transcription and UK GDPR: What Firms Must Do
Governance, audit and oversight
- Tamper-Evident vs Immutable Log: The Real Difference
- Human on the Loop vs In the Loop: AI Oversight Explained
Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.
Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.
Written by Micky Irons, founder and chief executive of Mickai LTD.
Top comments (0)