EU AI data residency: wat je AI-functie echt buiten Europa stuurt

Je AI-functie werkt. Dan stuurt het securityteam van je grootste klant een vragenlijst, en één regel daarin blokkeert de deal: noem elke locatie waar onze data verwerkt wordt. Het eerlijke antwoord is dat niemand in je team ze allemaal kent.

Dat is geen onkunde. Het is de normale uitkomst van de manier waarop AI-functies in de praktijk gebouwd worden. Iemand kiest een modelleverancier en checkt de compliance-pagina. Iemand anders voegt een vector database toe, omdat retrieval nodig was. Iemand zet tracing aan, omdat een prompt debuggen zonder tracing bijzonder vervelend is. Iemand koppelt een evaluatietool om regressies eruit te houden. Elk van die keuzes was op zichzelf verstandig, en elk van die keuzes opende een nieuwe route waarlangs klantdata Europa verlaat.

Dit artikel is voor founders, CTO's en product- of operationsleiders bij SaaS- en enterprisebedrijven die EU-klanten bedienen en op dit moment een AI-functie uitrollen of er een door een inkooptraject proberen te krijgen. Zoek je een algemene juridische samenvatting van de AVG, dan is dit niet het juiste artikel. Wil je weten welke onderdelen van je architectuur het antwoord echt bepalen, en wat je moet oplossen voordat die vragenlijst binnenkomt, lees dan verder.

Je krijgt een heldere definitie van wat EU AI data residency wel en niet dekt, de 3 vragen die telkens tot één vraag worden samengeperst, de 9 plekken waar klantdata een AI-functie verlaat, een uitgewerkt voorbeeld, 3 architectuurpatronen met hun echte afwegingen, en de vragen die je in de offertefase moet beantwoorden zodat dit vooraf ontworpen wordt in plaats van achteraf gerepareerd.

‍

Belangrijkste punten

• EU AI data residency is geen eigenschap van één onderdeel van je stack. Het is het gecombineerde gedrag van elke dienst die je AI-functie aanraakt, en het model is meestal de enige die iemand controleert.

• Opslag, verwerkingslocatie en jurisdictie zijn 3 losse vragen. Een EU-regio beantwoordt de eerste, soms de tweede, en nooit de derde.

• Data in Europa opslaan en inference in Europa draaien zijn bij de meeste leveranciers aparte instellingen. De standaard voor de een is niet de standaard voor de ander.

• De dure lekken zitten zelden in de modelaanroep. Ze zitten in observability-traces, evaluatieruns, foutmeldingen met payload, en de kleine helper-API's die niemand heeft vastgelegd.

• De deadline voor hoog risico onder de EU AI Act is verschoven naar december 2027, maar de transparantieverplichtingen van augustus 2026 zijn blijven staan, en securityreviews van klanten hebben sowieso nooit op de wet gewacht.

• EU sovereign cloud-opties werden in 2026 echt bruikbaar, waarmee het oude excuus verviel dat frontier-modellen simpelweg niet in Europa beschikbaar waren.

• Residency achteraf inbouwen kost doorgaans meer dan het vooraf goed doen, omdat je dan meestal je retrievallaag en je hele observability-opzet tegelijk moet omgooien.

• De bepalende vraag in de offertefase is niet welk model je gebruikt. Het is welke categorieën klantdata überhaupt bij een derde partij mogen komen.

‍

Wat EU AI data residency echt betekent

EU AI data residency is de garantie dat de klantdata die door je AI-functie stroomt binnen de Europese Unie opgeslagen en verwerkt blijft, bij elke dienst in het verzoekpad en niet alleen bij de modelleverancier. Die laatste bijzin is de kern van dit artikel, want dat is precies het deel dat wegvalt.

De meeste teams behandelen dit als één ja of nee. In werkelijkheid zijn het 3 vragen, met verschillende antwoorden.

‍

‍

De eerste vraag is opslag in enge zin: waar de bytes staan wanneer ze bewaard worden. Chatgeschiedenis, geüploade bestanden, de embeddings in je vectorindex, de logs. Dit is de vraag die elke compliance-pagina helder beantwoordt, omdat dit het makkelijkst te garanderen en het makkelijkst te vermarkten is.

De tweede vraag is de verwerkingslocatie: waar de inference daadwerkelijk plaatsvindt op het moment dat een prompt beantwoord wordt. Dit is bij de meeste leveranciers een aparte instelling, en dat is het waard om expliciet te benoemen omdat het mensen verrast. OpenAI documenteert data residency en inference residency bijvoorbeeld als losse mogelijkheden met eigen voorwaarden. Je data in Europa opslaan betekent op zichzelf niet dat je prompts ook in Europa verwerkt worden. Als de vragenlijst naar verwerking vraagt en jij antwoordt met een feit over opslag, heb je de vraag niet beantwoord.

De derde vraag is jurisdictie, en die wordt bijna nooit op papier behandeld. Jurisdictie gaat niet over geografie, maar over zeggenschap. Een datacenter in Frankfurt dat wordt gerund door een bedrijf waarvan de moedermaatschappij onder de openbaarmakingswetgeving van een ander land valt, staat juridisch anders dan een datacenter dat wordt gerund door een in de EU gevestigde entiteit met personeel dat in de EU woont. Precies daarom heeft AWS zijn European Sovereign Cloud opgezet als aparte Duitse vennootschappen in plaats van als zomaar een extra regio, met algemene beschikbaarheid vanaf januari 2026 en een eerste regio in Brandenburg, uitsluitend bemand door EU-inwoners. Je mag prima besluiten dat jurisdictie voor jouw product een aanvaardbaar risico is. Wat je niet kunt doen, is doen alsof een EU-regio die vraag heeft opgelost.

‍

Waarom een EU-regio in 2026 geen voldoende antwoord meer is

Er zijn 2 dingen veranderd, en ze trekken de andere kant op.

De wettelijke klok werd ruimer. De Digital Omnibus on AI verschoof de nalevingsdeadline voor zelfstandige AI-systemen met hoog risico van augustus 2026 naar december 2027, en voor hoog risico AI die in producten is ingebouwd naar augustus 2028. Als je plan was om naar een deadline in 2026 te sprinten, heb je tijd teruggekregen. De transparantieverplichtingen die vanaf augustus 2026 gelden zijn niet verschoven, en de verboden praktijken gelden al sinds februari 2025.

De commerciële klok werd juist strakker. Enterprise-inkopers, ziekenhuizen, banken en publieke aanbestedingen hebben nooit op de wet gewacht. Zij vragen het nu, in de securityvragenlijst, vóór ondertekening. Onze klanten in de zorg en fintech lopen consequent tegen residency-vragen aan in verkoopgesprekken, ruim voordat een toezichthouder ernaar kijkt. Een uitgestelde juridische deadline stelt een vastgelopen deal niet uit.

Ondertussen is het technische excuus vervallen. Een paar jaar lang was er een reëel argument dat alles in Europa houden betekende dat je merkbaar zwakkere modellen accepteerde. In 2026 is dat argument een stuk dunner. Frontier-modellen zijn beschikbaar via de EU-regio's van de grote cloudplatforms, en er bestaan aparte soevereine opties. De afweging is verschoven van capaciteit naar kosten, inspanning en hoe snel nieuwe modelversies bij je aankomen. Dat is een heel ander gesprek, en een stuk ongemakkelijker, want het betekent dat het antwoord nu een keuze is en geen beperking.

‍

De 9 plekken waar je AI-functie data buiten Europa stuurt

Dit is het deel waar teams op vastlopen. Als wij een bestaande AI-functie doorlichten, is de modelleverancier bijna altijd correct ingesteld, want dat is het voor de hand liggende punt om te controleren. De lekken zitten overal elders.

‍

‍

Werk ze in deze volgorde af, want de latere zijn juist de plekken die gemist worden.

De voor de hand liggende 3

De modelaanroep draagt de prompt, de systeeminstructies en alle klantcontext die je hebt meegestuurd. Embeddings sturen je documenten ergens heen om in vectoren te worden omgezet, wat neerkomt op het volledig uitlezen van de brontekst, ook al ziet de uitvoer eruit als getallen. De vector store bewaart vervolgens een tweede kopie van alles wat je geïndexeerd hebt, en dat is een echte kopie, geen verwijzing.

Teams krijgen de eerste meestal goed en behandelen de andere 2 als leidingwerk. Dat is het niet. Een vectordatabase op een in de VS gehost abonnement bevat de documenten van je klant net zo goed als je eigen productiedatabase.

De 3 die niemand vastlegt

Observability- en tracingtools leggen volledige prompts en volledige antwoorden vast, want dat is nu juist wat ze bruikbaar maakt. Gaan die traces naar een dienst buiten Europa, dan heb je een complete, doorzoekbare, vrijwel onbeperkt bewaarde spiegel van elk klantgesprek gebouwd, in een systeem waar je securityreview waarschijnlijk nooit naar heeft gekeken.

Evaluatietooling is nog lastiger, omdat er mensen bij betrokken zijn. Iemand bouwt een evaluatieset uit echte transcripten, omdat synthetische voorbeelden de interessante fouten nooit vangen. Die echte transcripten staan daarna in het evaluatieplatform, worden bij elke testronde opnieuw afgespeeld en soms aan annotatoren getoond. Niemand heeft hiervoor een dataflowdiagram gemaakt. Het is ontstaan tijdens een debugsessie.

Foutregistratie en applicatiemonitoring leggen stilletjes request-payloads vast in stacktraces. Je monitoring is ingericht voordat de AI-functie bestond, door iemand die aan latency dacht en niet aan het feit dat een toekomstige functie patiëntnotities of klantfinanciën in de request body zou zetten.

De laatste 3

Prompt caching houdt context warm aan de kant van de leverancier om kosten en latency te besparen. Dat is een bewaarbeslissing die een performancefunctie voor je neemt, en de locatie ervan volgt de leverancier, niet jouw bedoeling.

Feedback- en fine-tuningpijplijnen nemen de gesprekken die je gebruikers hebben gemarkeerd, per definitie de rommelige echte gevallen, en sturen ze ergens heen om het model te verbeteren. Controleer of dat ergens binnen je residency-grens ligt en of de data na de trainingsronde bewaard blijft.

Helper-API's vormen de lange staart en zijn de meest voorkomende verrassing: transcriptie voor een spraakfunctie, OCR voor geüploade documenten, een verrijkingsdienst, de e-maildienst die de uitvoer van de agent bezorgt. Elk daarvan is door een andere persoon in een andere sprint toegevoegd. Samen verplaatsen ze vaak meer gevoelige data over de grens dan het model zelf.

Wil je het volledige draaiboek om een AI-build zo op te zetten dat deze punten benoemd worden voordat ze gebouwd worden, dan loopt de SaaS AI Blueprint door de bijbehorende architectuurkeuzes heen.

‍

Een uitgewerkt voorbeeld: de assistent die zijn eigen securityreview niet haalde

Neem een Nederlands healthtechbedrijf met ongeveer 80 medewerkers, dat planning- en patiëntcommunicatiesoftware verkoopt aan klinieken. Ze voegen een AI-assistent toe die vervolgberichten aan patiënten opstelt op basis van consultnotities. Het werkt goed en klinieken zijn er blij mee.

De build zag er verantwoord uit. De modelleverancier stond ingesteld op een EU-regio en er lag een getekende verwerkersovereenkomst. Daar kon het team op verzoek naar wijzen. Toen deed een ziekenhuisgroep een grondige review, en viel het beeld in ongeveer een week uit elkaar.

De vectorindex met de consultnotities stond op een beheerd abonnement waarvan de standaardregio in de Verenigde Staten lag, 6 maanden eerder gekozen tijdens het prototypen en daarna nooit meer bekeken. De tracingtool legde elke prompt vast, dus elke notitie, en bewaarde die 30 dagen op infrastructuur buiten de EU. De evaluatieset waarmee het team de kwaliteit controleerde bevatte ongeveer 400 echte geanonimiseerde consulten, alleen was het anonimiseren gedaan door een script dat datums en klinieknamen liet staan. De transcriptiedienst voor de spraaknotitiefunctie, op één middag toegevoegd door één engineer, was nooit beoordeeld.

Vier lekken, geen daarvan het model, geen daarvan kwaadwillend, allemaal het gevolg van gewone beslissingen in de volgorde waarin engineeringwerk nu eenmaal gebeurt. Het herstel kostte ongeveer 7 weken: de vector store verplaatsen, overstappen op zelf gehoste tracing met redactie van prompts, de evaluatieset opnieuw opbouwen en de transcriptieleverancier vervangen. Hetzelfde werk in de ontwerpfase had een paar dagen architectuuroverleg gekost.

Die verhouding, dagen aan het begin tegenover weken achteraf, is het patroon dat we telkens zien. Het is geen technologieprobleem. Het is een volgordeprobleem.

‍

3 manieren om een AI-functie in Europa te houden

Zodra je accepteert dat residency een architectuurbeslissing is, zijn er 3 realistische vormen. De strengste is voor de meeste producten niet de juiste.

‍

‍

Beheerde EU-regio

Draai frontier-modellen via de EU-regio's van een groot cloudplatform, zet elke ondersteunende dienst vast op diezelfde regio, teken het papierwerk en zet zero retention aan waar dat wordt aangeboden. Dit is voor de meeste B2B SaaS-producten het juiste antwoord. Het is binnen dagen live, houdt je op actuele modellen en voldoet aan het overgrote deel van de securityvragenlijsten. Het neemt de juridische blootstelling buiten de EU niet weg, dus als de zorg van je koper specifiek over buitenlandse openbaarmakingswetgeving gaat, dicht dit dat gat niet.

EU sovereign cloud

Gebruik een aanbieder die is opgezet als een door de EU gecontroleerde entiteit met EU-personeel. Dit is de optie die de jurisdictievraag echt beantwoordt, en die werd in de loop van 2026 praktisch bruikbaar. De kosten zijn reëel: minder diensten, nieuwe modelversies die later binnenkomen en een kleinere groep engineers met ervaring. Kies dit als je verkoopt aan overheid, defensie, zorgsystemen of gereguleerde financiële partijen, waar de jurisdictievraag expliciet gesteld en expliciet beoordeeld wordt.

Zelf gehoste open modellen

Draai open modellen op infrastructuur die je zelf beheert binnen de EU. Er gaat niets naar buiten, punt. De eerlijke prijs is dat je nu zelf GPU-capaciteitsplanning, modelupgrades, evaluatie, beschikbaarheid en de beveiliging van de serving-stack bezit, en dat je een capaciteitsverschil met frontier-modellen accepteert op zware redeneertaken. Dit is veel minder vaak het juiste antwoord dan het internet suggereert. Het past als de data echt je perimeter niet mag verlaten, of als je volume hoog en voorspelbaar genoeg is dat de rekensom los van compliance al klopt.

Een praktische kanttekening: deze sluiten elkaar niet uit. Een gebruikelijk en verstandig patroon is routeren op dataklasse, waarbij gewone verzoeken naar een beheerde EU-regio gaan en het kleine deel dat de gevoeligste velden raakt naar een zelf gehost model. Dat kost meer om te bouwen dan één pad, en veel minder dan alles door de strengste route persen.

‍

Wat in het contract hoort, niet alleen in de architectuur

Architectuur zonder papierwerk overleeft geen review, en papierwerk zonder architectuur is een bewering die je niet kunt onderbouwen. Je hebt beide nodig. De punten die het vaakst terugkomen:

• Een getekende verwerkersovereenkomst met elke verwerker in de keten, niet alleen met de modelleverancier.

• De subverwerkerslijst van de leverancier, plus het recht op melding bij wijzigingen, want je residency-positie kan verschuiven doordat iemand anders van toeleverancier wisselt.

• Zero data retention aangezet en schriftelijk bevestigd overal waar het beschikbaar is.

• Een schriftelijke verklaring over waar inference draait, niet alleen waar data wordt opgeslagen, want dat zijn verschillende toezeggingen.

• Bewaartermijnen voor logs en traces, meestal precies het gat tussen wat je beleid zegt en wat je tooling daadwerkelijk doet.

• Je eigen dataflowoverzicht, actueel gehouden, met elke dienst die de AI-functie aanraakt en wat die dienst ontvangt. Dit ene document beantwoordt de meeste securityvragenlijsten in een middag in plaats van in 2 weken.

Dat laatste punt levert het meeste op en wordt door de meeste teams overgeslagen, omdat het aanvoelt als documentatie in plaats van engineering. Het is precies het stuk dat je enterprise-koper wil zien.

‍

Hoe je residency vooraf inricht

Bij Codelevate behandelen we dit als een discovery-vraag en niet als een deploymentvraag, want tegen de tijd dat je deployt zijn de dure beslissingen al genomen. Bij AI-platformbuilds lopen we 6 vragen door voordat er een architectuur wordt gekozen.

• Welke categorieën klantdata komen überhaupt bij de AI-functie, en welke daarvan mag je infrastructuur verlaten?

• Wie is de strengste koper waaraan je de komende 2 jaar wilt verkopen, en wat vraagt hun securityreview vandaag?

• Valt een deel hiervan onder een hoog risico categorie in de EU AI Act, wat naast residency ook documentatieverplichtingen verandert?

• Welke ondersteunende diensten heeft de functie nodig, en wat is de residency-positie van elk daarvan, stuk voor stuk benoemd?

• Wat wordt er gelogd, waar gaan die logs heen en hoe lang blijven ze staan?

• Wie is eigenaar van deze beslissing na livegang, wanneer iemand in maand 8 een nieuwe tool toevoegt?

Die 6 vragen beantwoorden kost meestal een paar werksessies en verandert de build. Het is ook het verschil tussen een AI-functie die door de inkoop komt en een die erin blijft steken. Wil je een tweede blik op hoe je huidige functie het zou doen, dan doet ons AI-ontwikkelteam deze review als onderdeel van de scoping. Voor de regelgevende kant legt onze uitleg over de EU AI Act de verplichtingen in gewone taal uit, en de AI agent security checklist behandelt de maatregelen die naast residency horen.

‍

De korte versie

EU AI data residency is geen eigenschap van je modelleverancier. Het is de zwakste schakel over alle diensten die je AI-functie aanraakt, en het model is meestal de sterkste schakel omdat dat als enige is gecontroleerd. Scheid de 3 vragen, opslag, verwerking en jurisdictie, beantwoord ze allemaal bewust, en leg het antwoord vast in een dataflowoverzicht dat je aan een koper kunt geven.

Doe je dat in de ontwerpfase, dan kost het een paar dagen. Doe je het nadat een ziekenhuisgroep of een bank er al naar heeft gevraagd, dan kost het weken herstelwerk aan je retrieval- en observabilitylagen, terwijl de deal wacht.

‍

‍

Zit je nog eerder in het traject en wil je het volledige draaiboek, inclusief hoe je een AI-project zo opzet dat residency, security en compliance in de ontwerpfase geregeld zijn, download dan de SaaS AI Blueprint. En heb je al een functie in productie en wil je een eerlijk beeld van waar de data werkelijk heen gaat, plan dan een gratis gesprek met ons team. We brengen het liever nu samen in kaart dan nadat de vragenlijst binnen is.

‍