"Lista varje AI-underleverantör och var data går" - underprocessorfrågan
Detta är frågan där två föreskrifter möts i en kalkylbladscell. Köparens integritetsteam behöver listan för sin GDPR-granskning - som behandlar personuppgifter, där under vilken överföringsbasis. Köparens AI granskare behöver samma lista för att kartlägga vilka modeller som sitter i din produkt innan Article 50 av EU AI Act börjar gälla på 2 augusti 2026. Ett bord svarar båda - vilket också innebär en felaktig rad fångas två gånger.
Varför en tabell nu tjänar två recensioner
Standard AI due-diligence instrument - AI-CAIQ (Cloud Security Alliance, oktober 2025) och SIG 2026 AI-domänen - be om samma kärnartefakter: en inventering av AI-system, provenance av modellerna, AI-underleverantörerna bakom dem och dataflödena mot dessa modeller. Underleverantörslistan är där alla fyra konvergerar. Det matar också köparens DPA-granskning direkt: en AI-funktion som tyst kallar en USA-bearbetad modell API är, från integritetsteamets stol, en internationell överföring av deras data - och GDPR Chapter V ger dem en kort meny med lagliga rutter: ett adekvatitetsbeslut (Article 45), lämpliga skyddsåtgärder som Standard Contractual Clauses (Article 46; Implementing Decision (EU) 2021/914), eller narrow ZQXZQX
Bygga den verkliga listan
En rad per underprocessor som rör AI-funktioner, med dessa kolumner - fästen är dina för att verifiera, aldrig att gissa:
| Subprocessor (juridisk enhet) | Rollen | Data som når den | Bearbetningsregion | Överföringsmekanism |
|---|---|---|---|---|
| [Modelleverantörens upphandlande enhet] | LLM API för [feature] | [Prompts/kundinnehåll från modul X] | [Region per den signerade DPA] | [DPF-certifiering eller SCC i DPA - verifiera innan du namnger] |
| [Cloud/hosting provider] | Hosting, Förvaring | [All kunddata] | t.ex. EU-regionen] | [- Om bearbetning stannar i EES, ingen tredjelandsöverföring för att motivera] |
| [Vector DB / transkription / OCR-leverantör] | [Supporting AI service] | [Vad som faktiskt flödar] | [Region] | [Verifiera i den säljarens DPA] |
Tre vanor gör listan överlever granskning. Använd upphandlande juridiska enheter, inte produktnamn - en granskare kan korsa kontrollen mot din offentliga underprocessor sida, så håll de två synkroniserade. Beskriv dataflöden av vad som faktiskt lämnar din gräns, inte genom funktionsmarknadsföring. Och om en modell körs självvärd i din egen infrastruktur, säg så: en modell som aldrig får kunddata externt är den enklaste raden på sidan.
Överföringsmekanismens kolumn: verifiera den, gissa den aldrig.
Det typiska fallet: en EU- eller tjänsteleverantör som kallar en modell API bearbetad i USA. Två mekanismer täcker vanligtvis det, och som man tillämpar är en per-leverantör faktum, inte en genre konvention:
- EU-US Data Privacy Framework (DPF). Europeiska kommissionens beslut om tillräcklighet av 10 juli 2023 (C(2023) 4745) omfattar överföringar till amerikanska organisationer Hålla en aktiv DPF-certifieringOm din specifika leverantörs upphandlande enhet är certifierad är kontrollerbar på den officiella listan på dataprivacyframework.gov - kontrollera den; svara inte på minnet. För överföringar från Storbritannien har UK-US Data Bridge (den brittiska förlängningen till DPF) varit i kraft sedan 12 oktober 2023.
- Standardavtalsklausuler (SCC). Om leverantören inte är DPF-certifierad, är mekanismen normalt SCC (Implementing Decision (EU) 2021/914) införlivas i DPA du undertecknade med dem. Det gör den signerade DPA - inte leverantörens marknadsföringssidor - källan till denna cell.
Ordning som stänger frågan en gång verifierad: Överföringar till [leverantör] (USA) omfattas av [leverantörens EU-USA Data Privacy Framework certifiering / Standard Contractual Clauses (beslut (EU) 2021/914) som införlivats i leverantörens databehandlingsavtal], granskas från och med [datum]. Om du inte kan verifiera antingen idag, skriv "överföringsmekanism under verifiering mot den signerade DPA" - en väntande cell är trovärdig; en felaktig mekanism som heter självsäker är ett skriftligt fel om köparens data.
AI Act-frågan som gömmer sig i listan
Samma tabell berättar köparen vars modeller dina produktskepp - vilket väcker frågan som AI-sektionen ställer nästa: vem är den Leverantör av det resulterande systemet? Om du erbjuder en tredjepartsmodell under ditt eget varumärke, är du leverantören för Article 50(1), med de transparensuppgifter som följer av 2 augusti 2026 - Digital Omnibus inte skjuta upp Article 50. Den fullständiga logiken finns i Vem är leverantören av ditt AI-system? och vår Article 50 frågeformulär guideDen fria Article 50 checker kartlägger dina specifika funktioner i sju frågor.
Mini-FAQ
Är vår AI-modellleverantör en underleverantör?
Om kundinnehåll som innehåller personuppgifter når leverantörens API, kommer köpare att förvänta sig det på listan - så kartlägga vad som faktiskt flyter till varje modell innan de svarar. Om din arkitektur håller personuppgifter borta från modellen API, säg det exakt och vara redo att bevisa det. Äkta klassificering kant fall hör till råd.
Tänk om vi inte kan verifiera överföringsmekanismen just nu?
Gissa inte. Kontrollera leverantörens nuvarande DPF-status på den officiella listan och mekanismen i DPA du faktiskt signerade, tills dess markera cellen som väntande verifiering. I väntan är trovärdig; fel är en felaktighet.
Behöver EU AI Act en underleverantörslista?
Listan är en GDPR och upphandling artefakt. AI Act sitter bakom det: listan avslöjar vars modell du skickar och skickar en tredjepartsmodell under ditt eget varumärke gör dig leverantör under Article 50(1), som är tillämplig från 2 augusti 2026.
Relaterad: Frågan reser vanligtvis med "Är våra data vana vid att träna dina modeller?" samma DPA, nästa rad ner. Om frågeformuläret bara landade, börja med Första-24-timmars spelbokoch bläddra resten av Svara på bibliotek för frågorna kring denna.