“List every AI subprocessor and where data goes” — the subprocessor question
This is the question where two regulations meet in one spreadsheet cell. The buyer's privacy team needs the list for its GDPR review — who processes personal data, where, under which transfer basis. The buyer's AI reviewer needs the same list to map which models sit inside your product before Article 50 of the EU AI Act starts to apply on 2 August 2026. One table answers both — which also means an inaccurate row gets caught twice.
Why one table now serves two reviews
Standard AI due-diligence instruments — the AI-CAIQ (Cloud Security Alliance, October 2025) and the SIG 2026 AI domain — ask for the same core artifacts: an inventory of AI systems, the provenance of the models, the AI subprocessors behind them, and the data flows toward those models. The subprocessor list is where all four converge. It also feeds the buyer's DPA review directly: an AI feature quietly calling a US-processed model API is, from the privacy team's chair, an international transfer of their data — and GDPR Chapter V gives them a short menu of lawful routes: an adequacy decision (Article 45), appropriate safeguards such as Standard Contractual Clauses (Article 46; Implementing Decision (EU) 2021/914), or the narrow Article 49 derogations as a residual option.
Building the real list
One row per subprocessor that touches AI features, with these columns — brackets are yours to verify, never to guess:
| Subprocessor (legal entity) | Role | Data that reaches it | Processing region | Transfer mechanism |
|---|---|---|---|---|
| [Model provider's contracting entity] | LLM API for [feature] | [Prompts / customer content from module X] | [Region per the signed DPA] | [DPF certification or SCCs in the DPA — verify before naming] |
| [Cloud/hosting provider] | Hosting, storage | [All customer data] | [e.g. EU region] | [— if processing stays in the EEA, no third-country transfer to justify] |
| [Vector DB / transcription / OCR vendor] | [Supporting AI service] | [What actually flows] | [Region] | [Verify in that vendor's DPA] |
Three habits make the list survive review. Use contracting legal entities, not product names — a reviewer can cross-check against your public subprocessor page, so keep the two synchronized. Describe data flows by what actually leaves your boundary, not by feature marketing. And if a model runs self-hosted in your own infrastructure, say so: a model that never receives customer data externally is the easiest row on the page.
The transfer-mechanism column: verify it, never guess it
The typical case: an EU or EU-serving vendor calling a model API processed in the United States. Two mechanisms typically cover it, and which one applies is a per-provider fact, not a genre convention:
- EU-U.S. Data Privacy Framework (DPF). The European Commission's adequacy decision of 10 July 2023 (C(2023) 4745) covers transfers to US organizations holding an active DPF certification. Whether your specific provider's contracting entity is certified is checkable on the official list at dataprivacyframework.gov — check it; do not answer from memory. For transfers from the UK, the UK-US Data Bridge (the UK extension to the DPF) has been in force since 12 October 2023.
- Standard Contractual Clauses (SCCs). If the provider is not DPF-certified, the mechanism is normally the SCCs (Implementing Decision (EU) 2021/914) incorporated into the DPA you signed with them. That makes the signed DPA — not the provider's marketing pages — the source for this cell.
Wording that closes the question once verified: "Transfers to [provider] (US) are covered by [the provider's EU-U.S. Data Privacy Framework certification / the Standard Contractual Clauses (Decision (EU) 2021/914) incorporated in the provider's Data Processing Agreement], reviewed as of [date]." If you cannot verify either today, write "transfer mechanism under verification against the signed DPA" — a pending cell is credible; a wrong mechanism named confidently is a written misstatement about the buyer's data.
The AI Act question hiding inside the list
The same table tells the buyer whose models your product ships — which raises the question the AI section asks next: who is the provider of the resulting system? If you offer a third-party model under your own brand, you are the provider for the purposes of Article 50(1), with the transparency duties that entails from 2 August 2026 — the Digital Omnibus did not postpone Article 50. The full logic is in "Who is the provider of your AI system?" and our Article 50 questionnaire guide; the free Article 50 checker maps your specific features in six questions.
Mini-FAQ
Is our AI model provider a subprocessor?
If customer content containing personal data reaches the provider's API, buyers will expect it on the list — so map what actually flows to each model before answering. If your architecture keeps personal data away from the model API, say that precisely and be ready to evidence it. Genuine classification edge cases belong with counsel.
What if we cannot verify the transfer mechanism right now?
Do not guess. Check the provider's current DPF status on the official list and the mechanism in the DPA you actually signed; until then, mark the cell as pending verification. Pending is credible; wrong is a misstatement.
Does the EU AI Act require a subprocessor list?
The list is a GDPR and procurement artifact. The AI Act sits behind it: the list reveals whose model you ship, and shipping a third-party model under your own brand makes you the provider under Article 50(1), applicable from 2 August 2026.
Related: the question usually travels with "Is our data used to train your models?" — same DPA, next row down. If the questionnaire just landed, start with the first-24-hours playbook, and browse the rest of the answer library for the questions around this one.