Sub-Processor Disclosure Obligations for AI Vendors Under GDPR

When an AI vendor forwards your prompt to a model provider, that provider is a sub-processor, and Article 28(2) gives you a say in whether it is engaged. The obligation is old and clear. What is new is a vendor architecture in which the sub-processor that handles a given request is chosen at runtime, which is a fact pattern Article 28 was not drafted with in mind.

What Article 28(2) requires

Article 28(2) of the GDPR says that the processor shall not engage another processor without prior specific or general written authorisation of the controller, and that in the case of general written authorisation the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes. Article 28(4) then requires the same data protection obligations to be imposed on the sub-processor by contract, and keeps the first processor fully liable to the controller for the sub-processor’s performance. The text is at EUR-Lex, Regulation (EU) 2016/679.

Three things follow that are commonly missed. The authorisation must be prior — engagement first and notification afterwards does not comply. The authorisation must be written, which for general authorisation means it is in the DPA, not implied by silence. And Article 28 sets no notice period at all: the length of time between notification and engagement is entirely a matter of contract, which is why the number in the clause is the whole of your practical protection.

General authorisation and its conditions

Essentially every AI vendor operates on general written authorisation, because specific prior authorisation for each addition does not scale. That is permitted, but it comes with a condition that is frequently treated as optional: the controller must be informed of intended changes. Publishing a list on a web page and expecting customers to poll it is not obviously informing anybody.

The European Data Protection Board addressed the chain directly in Opinion 22/2024 on certain obligations following from the reliance on processors and sub-processors, adopted in October 2024 at the request of the Danish supervisory authority and available from the EDPB’s document register. Its central points for this question are that the controller should have readily available the information identifying all processors and sub-processors in the chain, that the controller’s obligation to use only processors providing sufficient guarantees under Article 28(1) extends down the chain rather than stopping at the first hop, and that the controller cannot discharge that obligation simply by relying on the processor’s own assurance without any verification of its own.

The practical reading is that a defensible arrangement has three elements: a named list, an active notification mechanism such as email or a subscribable feed rather than a page, and a notice period long enough for the controller to assess a new entry before it starts processing. Where the SCCs are in place, Clause 9 Option 2 requires exactly this and puts a specified minimum period in the contract — see which SCC modules apply to an AI processor.

The routing problem

Here is where AI vendors are structurally different from the hosting vendors Article 28 was written about. A vendor that offers access to several models is engaging several sub-processors, and which one handles a given request may depend on the model the customer selected, on a fallback triggered by an upstream outage, or on a routing policy the vendor tunes without telling anyone. The set of sub-processors that actually processed your data last month is therefore a factual question with a possibly surprising answer.

The GDPR does not distinguish between a sub-processor engaged for every request and one engaged only when the primary is unavailable. Both are engaged. A fallback provider that handled one per cent of your traffic during an incident is a sub-processor that processed your personal data, and if it was not on the list you authorised, that is an Article 28(2) problem regardless of the volume. It may also be a transfer to a different third country than the one your assessment covers.

Two questions to put to any vendor with multi-model routing, both of which have short answers that are rarely volunteered. Is the list of model providers exhaustive, or is it the providers currently in use? And is fallback to a provider outside my selected set possible during an incident, and if so am I notified after the fact? A vendor that cannot answer the second question has not thought about Article 28(2) at all.

The objection right nobody exercises

Article 28(2) gives the controller the opportunity to object. It does not say what happens next, and that silence is where the right usually dies. A well-drafted DPA states the consequence: if the controller objects, the processor may either not engage the sub-processor for that controller’s data, or the controller may terminate the affected services without penalty and with a pro-rata refund. A DPA that establishes an objection right with no consequence has established nothing, because the vendor’s answer to an objection is “noted”.

There is a real commercial asymmetry here and it is worth naming. For a small customer of a large provider, an objection that leads only to a termination right is not a remedy — it is an invitation to migrate. The honest mitigation is architectural rather than contractual: keeping a second provider viable so that objecting is a routing change. That is the same conclusion the retention and training clauses reach from a different direction in DPA clauses specific to AI sub-processing.

Verifying the chain

The controller’s own obligation under Article 28(1) is to use only processors providing sufficient guarantees to implement appropriate technical and organisational measures. Reading a list is not verifying it. A proportionate verification for an AI chain covers: whether each named sub-processor has a public DPA and transfer paperwork of its own; whether the training-exclusion and retention terms you negotiated with your vendor have in fact been passed down under Article 28(4); which country each sub-processor processes in; and whether any of them publishes a transparency report on government access requests.

Record the result and the date in your Article 30 entry — the recipients and transfers fields depend on it, as records of processing activities for an AI system sets out. The due-diligence questions themselves are collected in Article 28 due diligence for an AI sub-processor and the GDPR checklist for an AI sub-processor. The point of writing it down is not the document. It is that when a sub-processor is added in eight months, someone can tell whether anything material has changed, which is impossible if the original assessment was never recorded.