Voice agents
Voice agent data residency: negen EU-valkuilen uit de praktijk
Negen data residency-valkuilen die we tegenkwamen bij een voice agent voor een Duits-Nederlandse verzekeraar, gerangschikt op hoe sterk de leverancier ze verbergt.

Frankfurt, een dinsdag in maart. We zitten in een vergaderzaaltje boven de schadeafdeling van de verzekeraar. De DPO schuift een geprint Datadog-dashboard over de tafel. Drie regels zijn geel gemarkeerd: span attributes met fragmenten van klantgesprekken, allemaal getimed op 02:14 CET, allemaal gerouteerd naar een us-east-1 endpoint.
"BaFin staat hier over zes weken," zegt ze. "Leg uit."
De voice agent die we negen weken aan het bouwen waren handelde inkomende first-notice-of-loss gesprekken af in het Duits en Nederlands. Elke leverancier in onze stack adverteerde met "EU data residency" op zijn compliance-pagina. Elke leverancier leverde die kop ook. Elke leverancier lekte ook iets waar we niet aan hadden gedacht om naar te vragen.
Dit is de veldgids die we na die meeting schreven. Negen valkuilen, gerangschikt naar hoezeer de compliance-pagina van de leverancier ze bagatelliseert. De volgorde telt: hoe hoger op de lijst, hoe groter de kans dat je het lek alleen vindt door packet captures te lezen.
Residency is een graph, geen vinkje
Een gesprek is niet één dataflow. Het is een graph: SIP-signalering, RTP-media, transcripts, embeddings, prompts, completions, tool-call payloads, logs, traces, retraining queues, backup-snapshots. Elke edge in die graph heeft zijn eigen regio, zijn eigen sub-processor, zijn eigen log sink.
De compliance-pagina van de leverancier vouwt de graph samen tot één vrolijke node in Frankfurt. Het werk is om die graph weer open te vouwen en voor elke stap, van de SIP INVITE tot de geprinte schademelding, te vragen waar de byte in rust staat, waar hij doorheen reist, en wie de doos waar hij op staat kan dagvaarden.
De Duitse Bundesdatenschutzgesetz en de Nederlandse AVG zijn het qua inhoud grotendeels eens. Waar ze uiteenlopen, is in toon: de BDSG is preciezer over telco-metadata onder §3 TKG, de Nederlandse AP heeft luider gesproken over vector embeddings. Een Duits-Nederlandse deployment moet beide lezingen tevredenstellen.
Valkuil 1: observability die gespreksinhoud naar us-east-1 stuurt
Dit is de slechtst verstopte. Elk framework in onze stack had een Datadog-, Sentry- of OpenTelemetry-integratie die iemand in 2023 had aangezet en daarna vergeten. Default-instellingen sturen error payloads, span attributes, breadcrumbs en request bodies naar de regio waar de observability-tenant leeft. Onze LLM-gateway was door een vorige opdrachtnemer gekoppeld aan een Amerikaanse Datadog-tenant. De compliance-pagina van de gatewayleverancier zei "we hosten inference in de EU," wat klopte, en zweeg over het feit dat de gateway ook elke prompt en completion naar een Amerikaanse trace store stuurde als debug-attribuut.
De fix bestaat uit twee delen. Eerst: dwing de observability-tenant naar de EU-site. Datadog heeft een EU1-regio op app.datadoghq.eu, Sentry heeft de.sentry.io, New Relic heeft api.eu.newrelic.com. Daarna: scrub request en response bodies voordat ze de tracer bereiken. Een korte middleware doet het:
const SCRUB_KEYS = ['transcript', 'prompt', 'completion', 'utterance', 'audio_url', 'tool_args']
function scrubSpan(span) {
if (!span.meta) return span
for (const k of SCRUB_KEYS) {
if (span.meta[k]) span.meta[k] = '[redacted]'
}
if (span.meta.http?.body) span.meta.http.body = '[redacted]'
return span
}
tracer.use('http', { hooks: { request: (span) => scrubSpan(span) } })
Compliance-pagina's zeggen "we hosten je data in de EU." Ze zeggen niet "je error tracker stuurt het stemtranscript van een beller naar Virginia elke keer dat een tool call faalt."
Valkuil 2: het RTP-mediapad dat je SIP-provider niet laat zien
Telefonie-aanbieders routeren signalering (SIP) en media (RTP) over verschillende paden. Het signaleringspad draagt de gespreksopzet en het beller-ID. Het mediapad draagt de audio zelf. Een leverancier met EU SIP-PoP's kan je RTP-stream nog steeds via een Amerikaanse transit ankeren wanneer het gesprek vanaf een roaming-nummer komt, wanneer de EU-medianode vol zit, of wanneer de carrier van de beller een slechte route naar huis kiest.
Vraag de telefonieleverancier per gesprek om de media-ankerregio, niet als globale instelling. Twilio toont dit via het MediaRegion-veld op een call; Vonage en Telnyx hebben vergelijkbare knoppen. Vergrendel de regio op de1 of ie1. Laat hem niet autoselecteren. Log daarna het werkelijke anker dat het gesprek gebruikte, want de gevraagde regio en de toegekende regio zijn niet altijd hetzelfde.
Valkuil 3: cascaderende sub-processor-ketens
Je contract met leverancier A noemt zijn sub-processors. Sub-processor B van leverancier A heeft zijn eigen sub-processors. Op de derde laag heb je een CDN waar je nooit mee akkoord ging, die TLS termineert voor een analytics-beacon waar je ook nooit mee akkoord ging, op een us-east-1 doos, omdat leverancier B Segment gebruikt voor product analytics en Segment op AWS US draait.
We maakten letterlijk een tabel met drie kolommen: leverancier, sub-processor, sub-sub-processor. We eisten dat leverancier A onze regionale beperking schriftelijk door de keten heen doorzette, met een auditclausule. Twee leveranciers zeiden ja. Eén leverancier zei "we hebben geen controle over de regio van B." Die leverancier vervingen we voordat inkoop ook maar iets had ondertekend.
De EDPB-aanbevelingen over aanvullende maatregelen noemen deze cascade expliciet en leggen uit waarom één enkele Standard Contractual Clauses-kopie bij de voorste leverancier het probleem niet dekt. De meeste compliance-pagina's van leveranciers noemen die aanbevelingen helemaal niet.
Valkuil 4: backup- en disaster-recoveryregio's
Een leverancier hostt productie in Frankfurt en is daar eerlijk over. De backupregio valt standaard terug op de EU-regio die geografisch het dichtst bij de primaire ligt, wat meestal prima is, behalve wanneer "dichtstbijzijnd" stilletjes Londen betekent (post-Brexit een derde land onder een adequacy decision die de Commissie kan intrekken), of us-east-1, omdat de DR-runbook van de leverancier nooit is bijgewerkt nadat de EU-regio openging.
Vraag schriftelijk om de DR-regio. Vraag om de failover-testlog van het afgelopen kwartaal. Als de runbook "om de dienst even draaiende te houden" faillt over naar een Amerikaanse regio, sterft je residency-claim op het moment dat een echte storing toeslaat. Eén leverancier bood aan een contractclausule toe te voegen die Amerikaanse failover verbood; die accepteerden we. Twee weigerden; één vervingen we, bij de ander legden we een gedocumenteerd risico vast na een Transfer Impact Assessment.
Valkuil 5: telemetrie van model-fine-tuning
Elke LLM-leverancier met een fine-tuning-product stuurt training events standaard naar een Amerikaans gehoste ML ops-platform. De trainingsdata zelf blijft in de EU-bucket. De telemetrie eromheen (welke voorbeelden faalden in de validatie, welke prompts produceerden refusals, gradient norms, evaluatieoutput) vaak niet. Die telemetrie bevat genoeg tekstfragmenten om een betekenisvolle slice van de trainingsset te reconstrueren.
Als je fine-tunet, vraag dan welke MLOps-stack de leverancier voor de run zelf gebruikt. Weights and Biases heeft nu een dedicated EU-cloud; Comet heeft regio-gebonden instances; MLflow self-host je waar je de server neerzet. De default-tenant bij elk managed aanbod is VS. De leverancier vermeldt dat niet uit zichzelf.
Valkuil 6: STT-regiofallback onder belasting
Speech-to-text-leveranciers adverteren met een EU-endpoint. Onder belasting (en met "belasting" bedoelen we een dinsdagochtend in het schadeseizoen na een storm) vallen er meerdere transparant terug op een Amerikaanse regio. De leverancier logt de fallback intern als een betrouwbaarheidsincident. Jij ziet het niet in je dashboard. De X-Region response header vertelt waar het request werkelijk draaide. De compliance-pagina niet.
We bouwden een smoke test die elke minuut één synthetische call afvuurt op het STT-endpoint en de X-Region-header naar een aparte Loki-instance logt. De eerste keer dat we 'm draaiden, kwam 8% van de requests in een venster van vier uur terug als us-west-2. De incident response van de leverancier, nadat we escaleerden: "we hebben die fallback niet gedocumenteerd omdat we hem als betrouwbaarheidsfeature beschouwden." De fallback werd binnen een dag via een flag op ons account uitgeschakeld. Die flag stond al twee jaar standaard uit.
Log altijd de werkelijke responseregio per request, niet de geconfigureerde. Compliance-pagina's beschrijven steady-state routing. Je residency-zaak staat of valt bij de failure modes die niemand documenteert.
Valkuil 7: artefacten van TTS-stemclones
Als je een stem kloont voor de agent (dat deden wij, met schriftelijke toestemming en een aparte verwerkersovereenkomst met de stemacteur), is het stemmodel zelf persoonsgegevens van de spreker. De leverancier slaat dat modelartefact op in welke GPU-pool ook vrij was toen je trainde. Wij hadden zes weken een clone, getraind op een drie uur durende studiosessie van een Duitse Sprecher, op een us-east-1 inference cluster staan voordat we het doorhadden.
Vraag de TTS-leverancier waar het modelbestand in rust staat opgeslagen, en apart waar inference draait. Dat zijn vaak verschillende dozen in verschillende regio's. ElevenLabs, Cartesia en Resemble bieden allemaal EU-regio-opties, maar de toggle zit verstopt in account settings en de default is VS. De toestemmingspapieren die je met de stemacteur tekende beloofden vrijwel zeker EU-opslag; de default van de leverancier brak die vrijwel zeker.
Valkuil 8: vector embeddings en het brontekstgat
Je kennisbank van polisdocumenten staat in een EU-bucket. Je embeddt 'm via een EU LLM-endpoint. De resulterende vectoren sla je op in een managed vector database. Die vector database is toevallig een managed Pinecone- of Weaviate-cluster die tot voor kort geen EU-regio aanbood.
Embeddings zijn niet anoniem. Met de brondocumenten en het embeddingmodel kun je ze omkeren en betekenisvolle fragmenten herstellen. De Nederlandse Autoriteit Persoonsgegevens heeft dit punt schriftelijk gemaakt in de context van medische RAG-systemen, en dezelfde logica geldt voor schadenotities bij verzekeringen. Pinecone biedt nu een Frankfurt-regio. Qdrant Cloud heeft Frankfurt al langer dan een jaar. Voor een verzekeringscasus blijft pgvector in een EU-gehoste Postgres het veiligste antwoord, omdat de attack surface kleiner is en je DBA 'm al begrijpt. Daar zijn we naartoe verhuisd.
Valkuil 9: inference logs en abuse-review queues
De compliance-pagina van de leverancier zegt "we draaien inference in de EU." Lees de volgende alinea. Inference logs (de volledige prompt, de completion, de system prompt, de tool calls, de timing) lopen vaak via een Amerikaanse "trust and safety"-pijplijn voordat ze worden opgeslagen of weggegooid. Abuse-review queues worden vrijwel altijd bemand door een leverancier in de VS of de Filipijnen, en de reviewers zien volledige prompts.
Vraag: waar staan inference logs in rust? Hoe lang worden ze bewaard? Wie reviewt gemarkeerde completions? Als het antwoord een trust and safety-team noemt, vraag dan waar dat team zit en welke velden ze zien. Voor onze verzekeraar onderhandelden we een no-logs-tier met de LLM-leverancier en draaiden we onze eigen redaction pipeline aan de grens, zodat PII werd gemaskeerd voordat de tekst een API overschreed.
De vorm van het residency-mapdocument
Wat de DPO uiteindelijk tekende was geen memo. Het was een kaart van 14 pagina's. Pagina 1 was een Mermaid-diagram van elke edge in de datagraph. Pagina's 2 tot en met 11 waren één pagina per edge: bronregio, bestemmingsregio, sub-processor, bewaartermijn, contractclausule, waargenomen bewijs. Pagina 12 waren de openstaande risico's. Pagina 13 was de Transfer Impact Assessment voor de ene Amerikaanse edge die we niet konden elimineren. Pagina 14 was het testplan: hoe we elke claim hierboven elk kwartaal verifiëren.
De kaart kostte een week om te maken en per kwartaal een dag om te onderhouden. Zonder de kaart was het gesprek met BaFin een gok geweest. Met de kaart was het een checklist.
De audit die je vandaag kunt draaien
Pak de komende tien minuten. Open de runtime config van je voice agent en grep op deze strings: datadog, sentry, endpoint, region, api.openai.com, eu1, us-east, us-west, amazonaws.com. Vraag je bij elke hit af: waar staat de byte aan de andere kant, en bindt het contract die leverancier aan de regio die hij op de slidedeck adverteerde?
Die grep is niet de audit. Het zijn de eerste tien minuten ervan. De volledige kaart kost een week, soms twee.
Toen we de voice agent bouwden voor die Duits-Nederlandse verzekeraar, was het lastigste deel niet de prompting of het latency budget. Het was een residency-kaart maken die de DPO zonder gekruiste vingers kon ondertekenen. Dat werk doen we nu op dag drie van elke voice-opdracht, voordat er code naar een telefoonnummer gaat.
Kern
Residency is een graph, geen vinkje. Elke compliance-pagina vouwt die graph samen tot één vrolijke node in Frankfurt; jouw taak is om hem weer open te vouwen.
FAQ
Verplicht de AVG mijn voice agent om alle data in de EU te houden?
Nee. De AVG staat doorgifte toe onder adequacy decisions of Standard Contractual Clauses met aanvullende maatregelen. Je moet wel weten waar elke byte staat en elke doorgifte schriftelijk kunnen rechtvaardigen.
Welk residency-lek wordt het vaakst gemist in een voice-agent-stack?
Observability. Datadog-, Sentry- en OpenTelemetry-exporters sturen request- en response-bodies naar de regio waar de tenant leeft, en bij de meeste teams is de default-tenant de VS.
Kan ik überhaupt een Amerikaanse LLM-aanbieder gebruiken voor een EU voice agent?
Ja, mits je een EU-inferenceregio contracteert, PII scrubt voor de API-grens, retention uitschakelt en de Transfer Impact Assessment vastlegt. De meeste leveranciers bieden dit op enterprise-tiers.
Zijn vector embeddings persoonsgegevens onder de AVG?
De Nederlandse AP en meerdere EU-toezichthouders hebben schriftelijk gesteld dat embeddings kunnen worden omgekeerd om brontekst te herstellen. Embeddings die voortkomen uit persoonsgegevens vallen daarmee onder hetzelfde regime.
Hoe lang duurt een volledige residency-audit voor een voice-agent-stack?
Ongeveer een week gericht werk voor de kaart, daarna ruwweg een dag per kwartaal om te verifiëren dat de claims nog kloppen. De meeste tijd zit in het lezen van sub-processor-lijsten en het draaien van per-call regiotests.