Approving an AI Sub-Processor Under GDPR Article 28

#ai #machinelearning #tutorial #llm

“Sufficient guarantees” is three words in Article 28(1) doing an enormous amount of work. It is a verification duty: you have to have checked, and you have to be able to show what you checked. This is how to run it against an AI sub-processor, where the chain is longer and less visible than the one the provision was drafted for.

What the standard actually says

Article 28(1) GDPR: a controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of the Regulation and ensure the protection of the rights of the data subject. Recital 81 fills in what to look at — expert knowledge, reliability and resources. Article 28(5) says adherence to an approved code of conduct or an approved certification mechanism may be used as an element by which to demonstrate sufficient guarantees; note “an element”, not a substitute for the assessment. Regulation (EU) 2016/679 on EUR-Lex.

Two more paragraphs carry the sub-processor mechanics. Article 28(2): the processor shall not engage another processor without prior specific or general written authorisation of the controller; with a general authorisation, the processor shall inform the controller of intended changes concerning the addition or replacement of other processors, giving the controller the opportunity to object. Article 28(4): where a processor engages another processor for specific activities on behalf of the controller, the same data protection obligations as set out in the controller contract shall be imposed on that other processor by contract, in particular providing sufficient guarantees; and where the other processor fails to fulfil its obligations, the initial processor remains fully liable to the controller for the performance of that other processor’s obligations.

Not legal advice. Note also that the assessment is continuous rather than a one-off gate — the EDPB’s guidelines on the concepts of controller and processor make the point that the controller must verify guarantees before engagement and at intervals thereafter. Current EDPB guidance is published at edpb.europa.eu.

The chain in an AI deployment

The reason a general vendor process misses things here is that the chain has layers that do not exist in ordinary SaaS. A realistic set for a hosted model feature:

The application vendor you contracted with — your processor.
The model provider, if the application vendor calls somebody else’s model. Often disclosed.
The inference host, which is frequently a hyperscaler and frequently a different entity from the model provider — a model available through a cloud marketplace is served by the cloud, not by the model’s author.
The safety or moderation layer, which may be a separate classifier service and which by definition sees content.
Human review, whether staff or an outsourced annotation and review supplier. Very often undisclosed and often the most sensitive link in the chain.
Observability and evaluation tooling — tracing platforms and eval vendors that store prompts and outputs verbatim, which is exactly the data everyone else in the chain is careful about.
Vector storage and retrieval, often a separate managed service holding embeddings derived from your documents.

Two of those — human review and observability — are the ones that routinely fail to appear on a published sub-processor list, because internally they are described as operations rather than as processing. Ask about them by function, not by whether they are on the list. The disclosure page covers what a vendor is obliged to publish.

The approval process

Confirm your role. If you are the controller, this process is yours. If you are yourself a processor for a customer, you are the “initial processor” in Article 28(4) and you remain fully liable for the sub-processor — which raises the evidence bar rather than lowering it.
Obtain the list with function, entity and country, and specifically ask whether each recipient processes content or only metadata. “Metadata only” is a meaningful narrowing and a claim worth testing.
Scale the diligence to the risk of the link. A sub-processor that sees raw prompts containing special category data under Article 9 warrants a different depth from a CDN. Write the tier criteria down once; applying them consistently is most of what makes the file defensible.
Collect evidence, not assertions. Certification scope statements with dates — the scope statement, because an ISO 27001 certificate covering one business unit tells you nothing about the one serving you. A SOC 2 Type II with the exceptions section read rather than the cover page. ISO 42001 where an AI management system is claimed; see what ISO 42001 certification actually covers.
Verify the flow-down exists. Ask the processor to confirm in writing that it has imposed the same data protection obligations on the sub-processor by contract, referencing Article 28(4). If it will not confirm that, you have an Article 28(4) problem regardless of how good the sub-processor is.
Do the transfer analysis per recipient. Each non-EEA recipient needs its own mechanism — usually the SCCs, with the module chosen by the roles of the two parties, and Module Three for processor-to-processor. Chained transfers need chained mechanisms, and a transfer impact assessment that names the actual recipient country and its access laws rather than a template.
Record the decision with its reasons and its date, including what you could not verify. An honest gap with a mitigation is defensible; a silent gap is not.
Set the re-check cadence and subscribe to the change feed. Most vendors publish sub-processor changes by RSS or email subscription and almost nobody subscribes. If the notice period is thirty days and nobody reads the notice, the objection right in Article 28(2) has expired before anyone in your organisation knows a new party is in the chain.

Making the objection right mean something

The general authorisation model is standard and it is fine, but the objection right it comes with is usually worthless as drafted, for a simple reason: objecting has no consequence. The vendor adds the sub-processor, you object, and the contract says the parties will discuss in good faith. Nothing follows.

What makes it real is a termination consequence tied to the objection: if you object on reasonable data protection grounds and the vendor proceeds, you may terminate the affected service without penalty and with a pro-rata refund and transition assistance. Vendors resist this and often accept a narrowed version — objection on documented data protection grounds only, within the notice period, with termination limited to the affected service rather than the whole agreement. That narrowed version is worth having. The unnarrowed version with no remedy is not.

The second thing to fix is the notice period against your own decision cycle. Thirty days is common; a thirty-day period that requires a DPO assessment, a transfer impact assessment for a new country and an internal approval is not thirty days of decision time. Either negotiate sixty for changes affecting content processors, or pre-agree an internal fast path.

What the file has to contain

Accountability under Article 5(2) means being able to demonstrate compliance, and the demonstration here is a file per sub-processor holding: the identity, entity and country; the function and whether it touches content; the evidence collected with dates and scope statements; the transfer mechanism and the TIA; the flow-down confirmation; the risk tier you assigned and why; the decision, the decision-maker and the date; and the review date. Your Article 30 record separately needs the categories of recipients and the third country transfers — that entry is fed by this file rather than replacing it.

A closing note on scope creep, because it is the most common way this process is defeated after it is built: the file is approved against a described processing, and then the feature changes. A retrieval feature that starts summarising documents and later starts sending them to an evaluation platform has added a sub-processor without any vendor changing anything. Tie the re-check to your own change management as well as to the vendor’s notices. The checklist form of all this is in the sub-processor checklist; the contractual limb is in the right-to-audit clause page.

Worth stating plainly: putting a gateway in front of several model providers adds a link to this chain rather than removing one — the gateway is a processor or sub-processor in its own right and belongs on your list. What it buys in exchange is that the chain becomes enumerable, because one place records which provider served each request. With Multigrid you can also bring your own provider keys, which keeps the contract with the model provider in your name rather than adding an intermediary to it — a different, and for some organisations simpler, shape of the same chain.