Standard Contractual Clauses for an AI Processor: Which Modules Apply

The 2021 standard contractual clauses are one document with four alternative modules, and signing the wrong one is not a formality — the modules impose different obligations and only one of them matches any given role configuration. For an AI stack the choice is usually obvious and occasionally is not, because the company sending the prompts is frequently itself a processor.

The four modules

Commission Implementing Decision (EU) 2021/914 of 4 June 2021 adopted the current set of clauses for transfers of personal data to third countries under Article 46(2)(c) of the GDPR. The text, with all four modules and the annexes, is at EUR-Lex, Decision (EU) 2021/914. The modules are:

• Module One — controller to controller. The exporter and importer each determine their own purposes.
• Module Two — controller to processor. The exporter is a controller, the importer processes on its instructions. This module is drafted to satisfy Article 28(3) as well, so it can serve as the data processing agreement rather than sitting alongside a separate one.
• Module Three — processor to processor. The exporter is itself a processor acting for someone else, and is passing data to a sub-processor abroad. The instructions flow through from the original controller, which changes the drafting throughout.
• Module Four — processor to controller. An EU processor returning data to a controller established outside the EU. The rarest of the four.

The clauses are a package: you select one module, delete the others, and you may not amend the standard text. You may add commercial terms and further safeguards provided they do not contradict the clauses or prejudice data subject rights, which is the space in which AI-specific drafting lives.

Which one fits an AI vendor

Start from the roles rather than from the product category. If you are a company using a model API to serve your own users, you are the controller, the vendor is your processor, and the answer is Module Two. This is the common case and it is why most vendor DPAs attach Module Two already completed.

The case that catches people is the SaaS business that embeds a model. If you process your customers’ end-user data on their instructions, you are a processor, and passing that data to a model provider abroad is a processor-to-processor transfer: Module Three, not Module Two. Executing Module Two there misdescribes your role in a signed instrument, and the substantive difference is not cosmetic — under Module Three the importer’s obligations run to instructions originating from a controller that is not a party to the contract, and the notification and objection mechanics for onward sub-processing are drafted accordingly.

A third configuration appears when the vendor has become a controller in its own right, for instance because it reuses prompts for its own training. Transfers for that processing are controller to controller, Module One — and if a vendor asks you to sign Module Two for a relationship in which it also trains on your data, the paperwork and the reality have parted company. That characterisation question is worked through in joint controllership between an AI vendor and its customer.

The docking clause, Clause 7, is optional and is worth including in AI arrangements specifically: it lets an entity accede to the clauses later without a fresh signature round, which is what you want when a group company or a new sub-processing entity enters the chain.

The annexes are the AI-specific part

The standard text cannot be edited, so everything that makes the instrument fit your processing is in the three annexes, and a completed set of SCCs with generic annexes is the most common defect in this area.

• Annex I.A — parties. Names, addresses, contact points, roles, and the activities relevant to the data transferred. “Provision of software services” is not a description of the activity; “processing of end-user prompts and generated responses for the purpose of answering support queries” is.
• Annex I.B — description of the transfer. Categories of data subjects and personal data, any special category data and the restrictions applied to it, the frequency of the transfer, the nature and purpose of the processing, the retention period, and — this is the field to look at — the subject matter, nature and duration of processing by any sub-processor. For an AI vendor that routes to upstream model providers, that last field is where the upstream processing gets described, or does not.
• Annex I.C — competent supervisory authority. Determined by Clause 13, which depends on where the exporter is established or, for an exporter outside the EU with a representative, where that representative sits.
• Annex II — technical and organisational measures. The annex must describe measures specific to the processing, not a generic security summary. For AI processing this is where zero-retention or bounded log windows, the exclusion of prompt bodies from telemetry, per-tenant key separation, region pinning and the prohibition on training use should appear — because a measure recorded in Annex II is part of the instrument rather than a settings page.
• Annex III — list of sub-processors. Required where Clause 9 Option 1, specific prior authorisation, is chosen.

Clause 9 and Clause 14 do the work

Two clauses carry most of the practical weight for AI transfers. Clause 9 governs the use of sub-processors and offers two options: Option 1, specific prior authorisation of each sub-processor with the agreed list in Annex III; or Option 2, general written authorisation with the importer obliged to inform the exporter of intended additions or replacements at least a specified period in advance, giving the exporter time to object. The blank in Option 2 is a negotiated number, and it is the single most consequential blank in the document for anyone whose vendor adds model providers. The obligation underneath it is examined in sub-processor disclosure obligations for AI vendors.

Clause 14 is the Schrems II clause. The parties warrant that they have no reason to believe the laws and practices in the third country applicable to the importer prevent it from fulfilling its obligations, having taken due account of the specific circumstances of the transfer, the laws and practices of the destination country, and any relevant contractual, technical or organisational safeguards. Clause 14(d) requires the parties to document that assessment and make it available to the competent supervisory authority on request. Clause 14 is therefore not a representation you can simply sign — it is a promise that an assessment exists, which is the subject of transfer impact assessments for a US-hosted AI provider.

Clause 15 sets out what the importer must do when it receives a legally binding request from a public authority for the transferred data — notify the exporter where permitted, challenge the request where there are reasonable grounds, and provide the minimum permissible amount. Clause 16 requires the importer to inform the exporter if it becomes unable to comply, and gives the exporter a right to suspend or terminate.

Where the SCCs do not reach

Three gaps matter here. First, the 2021 clauses were drafted for transfers to importers not themselves subject to the GDPR; the Commission’s published position is that they are not the right instrument where the importer’s processing is already directly subject to the Regulation under Article 3(2). The Commission has indicated it intends to adopt an additional set of clauses for that situation, and at the time of writing none has been adopted — a real and persisting gap for non-EU AI vendors that market into the Union.

Second, the SCCs are an EU instrument. Transfers out of the United Kingdom need either the ICO’s International Data Transfer Agreement or the UK Addendum to the EU clauses; transfers out of Switzerland need the Swiss adaptations recognised by the Federal Data Protection and Information Commissioner. A single AI vendor serving a UK, EU and Swiss footprint needs all three, and vendors frequently supply only the first.

Third, SCCs are unnecessary for transfers covered by an adequacy decision. Where a US vendor is certified under the EU-US Data Privacy Framework for the relevant data, the transfer travels on Article 45 rather than Article 46 and no Clause 14 assessment is required for it — which is a meaningful simplification with meaningful edges, set out in the EU-US Data Privacy Framework and AI vendors.