Regionale AI-endpoints houden niet alle data in de EU: stel de route per verwerkingsstap vast

Nee. OpenAI, Google Cloud, Anthropic en Microsoft documenteren dat een regionaal of EU-endpoint vooral opslag en modelverwerking bindt, terwijl routing, authenticatie, analytics, documentextractie en operationele metadata buiten die regio kunnen lopen. Stel daarom per verwerkingsstap afzonderlijk vast waar data terechtkomt; een regionale endpointnaam is geen bewijs van volledige datalokalisatie.

De directe aanleiding is actuele documentatie van OpenAI over data residency en inference residency voor ChatGPT. Daarin maakt OpenAI expliciet onderscheid tussen inference residency — de GPU-uitvoering van klantcontent in een gekozen regio — en overige verwerking. Authenticatie, verzoekroutering, analytics en CPU-taken zoals documentextractie en coördinatie kunnen volgens OpenAI buiten die gekozen regio plaatsvinden. Een regionale inferentie zegt dus niets over waar de rest van de keten draait, en daarmee is het AI-dataverblijf per verwerkingsstap verschillend.

Wat stellen OpenAI, Google Cloud, Anthropic en Microsoft precies over regionale en globale endpoints?

Alle vier de leveranciers beschrijven in hun eigen documentatie dat de geografische uitkomst afhangt van het gekozen endpoint en van afzonderlijke verwerkingsstromen, niet van de productnaam. De rode draad is dat de geografische uitkomst per leverancier, endpoint en verwerkingsstroom moet worden gecontroleerd. Regionale endpoints kunnen opslag en modelverwerking begrenzen, maar de precieze reikwijdte van ondersteunende en operationele stromen verschilt per dienst.

• OpenAI plaatst GPU-inferentie van in-scope content in de gekozen regio, maar sluit CPU-verwerking, routing, authenticatie en analytics buiten die regio niet uit.
• Google Cloud stelt in zijn documentatie over data residency voor het Gemini Enterprise Agent Platform dat verzoeken naar een global endpoint in iedere Google Cloud-locatie kunnen worden verwerkt en dus geen datalokalisatiegarantie bieden. Jurisdictionele multi-region- en locational endpoints beperken ML-verwerking wel tot de gekozen jurisdictie of regio.
• Anthropic beschrijft regional compliance als een keuze tussen globale endpoints, die verzoeken dynamisch naar beschikbare capaciteit routeren, en regionale endpoints, waarvan Anthropic stelt dat opslag en modelverwerking binnen de gekozen regio blijven, met beschikbaarheid in onder meer Europa, de Verenigde Staten en Azië-Pacific.
• Microsoft vermeldt in zijn EU Data Boundary change log dat OpenAI-operated models binnen Microsoft Generative AI Services als subprocessor gepseudonimiseerde gebruikers-id's in de Verenigde Staten kunnen verwerken en opslaan voor troubleshooting, debugging en security — binnen een dienst die onder de EU Data Boundary valt.

Als technische illustratie van hetzelfde principe beschrijft OpenRouter US in-region routing, waarbij verzoeken binnen de Verenigde Staten worden gerouteerd naar Amerikaanse provider-endpoints; de bron verwijst daarnaast naar een eerder aangeboden EU-routingoptie. Dat laat zien dat routing geografisch kan worden afgedwongen, maar ook dat provider-routing en inferentie afzonderlijke controlepunten blijven.

Welke verwerkingsstappen moet ik afzonderlijk geografisch nagaan?

Onze analyse van de genoemde documentatie leidt tot een praktisch controlekader van minstens vijf punten die u afzonderlijk kunt nagaan; de bronnen stellen niet gezamenlijk vast dat dit een uitputtende of universele minimumset is. Zo wordt het AI-dataverblijf per verwerkingsstap zichtbaar.

1. Ontsleuteling: waar wordt het versleutelde verzoek ontsleuteld tot leesbare content?
2. Voorbewerking: waar vinden prompt- en documentverwerking plaats, zoals CPU-gebaseerde documentextractie?
3. Inferentie: waar draait de GPU-uitvoering van het model?
4. Logs en metadata: waar worden logs, analytics en operationele identifiers verwerkt en bewaard?
5. Subprocessors en fallback: welke onderaannemers krijgen toegang en waar gaat verkeer heen als de primaire regio geen capaciteit heeft?

Naar onze inschatting zegt een EU- of regionale endpointnaam niet zonder meer welke van deze vijf punten wordt gebonden. De precieze reikwijdte moet per leverancier, product en endpointdocumentatie worden vastgesteld.

Wat betekent dit voor bestuurders, juristen en CISO's die gevoelige data verwerken?

Onze analyse: omdat OpenAI documenteert dat CPU-taken en routing buiten de inferentieregio kunnen lopen, levert een EU-endpoint naar onze inschatting voor organisaties met bijzondere of vertrouwelijke gegevens feitelijk geen volledige datalokalisatie op zonder aanvullende verificatie; Onze analyse is daarom dat de verwerkingsverantwoordelijke de datastroom per stap moet vastleggen voordat een AI-dienst in productie gaat, niet erna. Omdat Google Cloud een global endpoint uitdrukkelijk zonder lokalisatiegarantie levert, loopt een organisatie die onbewust op het globale endpoint staat naar onze analyse een onzichtbaar doorgifterisico; daarom hoort de endpointkeuze naar onze inschatting als expliciete, gedocumenteerde configuratie in het inkoop- en architectuurbesluit, met de regionale variant als uitgangspunt bij gevoelige verwerking. Omdat Microsoft vermeldt dat gepseudonimiseerde gebruikers-id's binnen een EU Data Boundary toch in de VS kunnen worden verwerkt, volstaat een geruststellende productnaam naar onze inschatting niet als onderbouwing in een verwerkersregister of DPIA; daarom moet de jurist naar onze inschatting de subprocessorlijst en de operationele stromen opvragen en als doorgiftegrond beoordelen. Omdat Anthropic global routing als aparte modus naast regionale endpoints aanbiedt, is het volgens onze analyse een eigen controlepunt om vast te leggen welk routing- en fallbackgedrag voor het gekozen endpoint geldt; daarom legt de CISO naar onze inschatting in het contract vast wat er bij capaciteitstekort gebeurt en of uitwijk naar een andere regio is toegestaan. Dit raakt volgens onze analyse aan privacy by design als levenscyclusplicht onder AVG-artikel 25 en aan bredere AVG-vraagstukken rond AI-privacy en AVG in de beroepspraktijk.

Welke vragen leg ik mijn AI-leverancier voor om de route te verifiëren?

Vraag per endpoint en per regio om een routingmatrix in plaats van een algemene residencyverklaring. De documentatie van de leveranciers laat zien dat alleen een stap-voor-stap-uitsplitsing betekenis heeft; dezelfde logica geldt wanneer u zelf datastromen bij AI-chatdiensten controleren wilt of de AVG-eisen aan generatieve AI-workflows toetst.

• Welk endpoint gebruiken wij feitelijk — global, jurisdictioneel multi-region of locational — en hoe is dat afgedwongen?
• Waar wordt ons verzoek ontsleuteld en waar draait de CPU-voorbewerking, inclusief documentextractie?
• Waar worden logs, analytics en operationele metadata verwerkt en hoelang bewaard?
• Welke subprocessors krijgen toegang en in welke landen, en geldt dat ook voor gepseudonimiseerde identifiers?
• Wat is het fallbackgedrag bij capaciteitstekort, en kunnen wij uitwijken naar een andere regio contractueel uitsluiten?

Zonder antwoord op deze punten rust een residency-aanname naar onze inschatting op een naam, niet op bewijs. Dat is het concrete verschil dat de recente documentatie van deze vier leveranciers zichtbaar maakt.

Bronnen: Het artikel steunt op officiële documentatie van OpenAI, Google Cloud, Anthropic en Microsoft en op productdocumentatie van OpenRouter over regionale en globale routing.