Waar één InterMIND-vergadering daadwerkelijk draait

Elk serieus enterprise-inkoopgesprek komt uiteindelijk bij dezelfde vraag: "Waar gaan deze gegevens naartoe?" De DPO wil een sub-verwerkerslijst. De CIO wil weten welke leveranciers in de VS gevestigd zijn. De juridische afdeling wil een diagram met pijlen.

We geven u liever het volledige beeld dan het stukje voor stukje per e-mail te sturen. Hier is dus het gegevenspad van één vergadering — elke externe service die het raakt, waar elk wordt uitgevoerd, en welke gegevens erdoorheen stromen. Geverifieerd tegen de daadwerkelijke implementatieconfiguratie op 2026-05-28.

Elk pad dat vergaderinhoud raakt, is EU tijdens uitvoering — inclusief de AI-stappen, die draaien op de AI-gateway die uw organisatie selecteert, in een EU-regio van onze eigen tenant. De leveranciers achter die gateway zijn Amerikaanse bedrijven die EU-regio's exploiteren; we vermelden dat hieronder openlijk, en we geven aan welk model volledig buiten de vergadering blijft.

Dit bericht brengt in kaart waar uw vergadering draait. Het bijbehorende bericht, Waaruit één InterMIND-vergadering is opgebouwd, brengt in kaart waaruit het is opgebouwd — welke lagen onze eigen code zijn, welke open-source zijn, en waar we pragmatisch zijn over propriëtaire SaaS.

Wat "waar het draait" daadwerkelijk betekent

Twee dingen worden in soevereiniteitsgesprekken door elkaar gehaald en het zijn niet dezelfde dingen:

1. Runtime / gegevenspad. Waar de bytes van uw vergadering fysiek worden verwerkt tijdens het verzoek. Dit is waar verordeningen voor dataresidentschap en de meeste DPA's daadwerkelijk over gaan.
2. Juridische vestigingsplaats van de leverancier. Waar de SaaS-leverancier juridisch is gevestigd. Dit is waar CLOUD-Act-discussies over gaan — het theoretische bereik van een Amerikaanse dwangmaatregel tegen de moederentiteit van de leverancier, ongeacht waar de workload draait.

Bijna elke "is dit EU?"-vraag is in werkelijkheid een van deze twee, onnauwkeurig gesteld. We beantwoorden ze hieronder voor elke leverancier afzonderlijk.

Het gegevenspad van één vergadering

Volg één oproep van deelname tot follow-up e-mail:

1. Browser opent de vergaderpagina. SSR draait op Vercel, vastgemaakt aan fra1 (Frankfurt). Alle aanvraag-/antwoordgegevens — sessiecookies, API-payloads, server-weergegeven HTML — worden in de EU verwerkt tijdens uitvoering.
2. WebSocket maakt verbinding met onze vergaderserver in Parijs (cdg). Vergaderorchestratie, aanwezigheid, signalering — allemaal EU.
3. Spraakherkenning draait op onze mediaserver. De audio komt via WebRTC aan bij onze eigen engine — de Mind API op OVH, Frankrijk — en wordt daar woord voor woord herkend, op dezelfde server die de oproep afhandelt; er is geen spraakservice van derden betrokken. Spraaknotities in chat zijn de enige uitzondering: hun spraak-naar-tekst draait op Azure AI Speech, de spraakservice van de standaard AI-gateway (leverancierstabel hieronder). De pijplijn zelf staat in Binnen de vier vertaalpijplijnen.
4. Spraak- en chatvertaling bereiken onze eigen engine op OVH Frankrijk. Dit is mind-sdk + de Mind API — onze code, onze hosts, in Frankrijk. Er is geen model van derden betrokken. Sub-seconde budget, één vertaling per aanwezige doeltaal in de ruimte, EU-resident bij elke hop.
5. Een document dat in de chat wordt gedeeld (PDF, DOCX, DOC, PPTX, XLSX) gaat server-side van de Parijse ws-server naar DeepL in Keulen. Duits bedrijf, Duitse verwerking. Spraak en chat raken DeepL niet.
6. Toepassingsgegevens — gebruikers, teams, berichten, vergadermetadata — leven in Neon Postgres op AWS Frankfurt (eu-central-1). Snapshots in dezelfde regio.
7. Opnames, bijlagen, exports worden opgeslagen op Tigris, S3-compatibele opslag op Fly. Edge-gerepliceerd; de bucket is configureerbaar naar multi-regio EU voor tenants die het strakker vastgezet willen hebben.
8. Fouten en prestatiesporen gaan naar de EU-instantie van Sentry (de.sentry.io). De Amerikaanse organisatie is in mei uitgefaseerd.
9. Productanalyses gaan naar PostHog EU (eu.i.posthog.com).
10. Transactionele e-mail (magic links, uitnodigingen, betalingsbevestigingen) gaat via Resend vanuit eu-west-1 (Ierland).

Alles hierboven is EU tijdens uitvoering. De vertaalengine — het deel waar de meeste van uw gegevens daadwerkelijk doorheen stromen — is ook onze eigen code, niet die van een derde partij. De client-SDK waarop het draait is open-source (BSD-3-Clause) en vandaag de dag auditabel; zelf-hosten van de engine zelf staat op de roadmap voor een klant die dit nodig heeft.

De leverancierskaart

De twee zwaarste gegevensstromen qua volume — spraak-/chatvertaling via onze eigen engine op OVH en documentvertaling via DeepL — komen toevallig ook overeen met de twee leveranciers waarvan de moederentiteit in de EU is gevestigd. Dat dekt het grootste deel van de vergaderinhoud. De volledige sub-verwerkerslijst met details over de vestigingsplaats van het moederbedrijf wordt als standaardpraktijk in de DPA opgenomen; de tabel hierboven is de weergave tijdens uitvoering, waar de meeste dataresidentschap-bepalingen over gaan.

De AI-stappen, helder benoemd

Na afloop van de oproep voeren we een paar taalmodelstappen uit op wat er is gezegd: de AI-samenvatting (onderwerpen, besluiten, actie-items, openstaande vragen), de post-meeting samenvatting, en de AI-notitie-editor (een notitie vertalen, of deze corrigeren / uitbreiden / vereenvoudigen). Tijdens de vergadering schrijft hetzelfde soort stap een samenvatting van elk document dat in de chat wordt gedeeld en beantwoordt het Ask AI en Mia. Dit zijn de enige plekken waar een algemeen model afgeleide vergaderinhoud raakt, en ze gaan allemaal naar één plek:

• De AI-gateway die uw organisatie selecteert. Eén resolver in de code kiest deze voor elke aanroeplocatie; er is geen tweede pad. De standaard is Azure OpenAI in de EU Data Zone; via de instellingen kan een organisatie overstappen naar Vertex AI op het EU multi-regio endpoint of Amazon Bedrock in Frankfurt, of elke AI-functie richten op zijn eigen OpenAI-compatibele endpoint — vLLM in zijn eigen datacenter, een implementatie in zijn eigen tenant. Elke gehoste gateway draait in onze eigen tenant, geconfigureerd voor nul gegevensretentie en geen training op klantinhoud; de fallback blijft op dezelfde gateway — een tweede EU-regio, of een tweede model van dezelfde leverancier — nooit een andere leverancier. De documentatie voor AI-functies vermeldt de gateways en regio's.
• De samenvatting en de vertaalactie van de editor gaan via het vertaaltraject, niet via het taalmodel — hetzelfde pad dat live chat vertaalt.
• AI kan voor de hele organisatie worden uitgeschakeld: transcriptie en vertaling blijven werken; de samenvatting, documentoverzichten, de schrijfassistent en Ask AI stoppen.

Realtime spraak, realtime chat, notities en documentvertaling gaan nooit door een van deze heen — ze waren vanaf het begin EU-resident.

Waar de leveranciers zitten: Microsoft, Google en Amazon zijn Amerikaanse bedrijven die EU-regio's exploiteren. Dat wordt openlijk vermeld op de vertrouwenspagina, niet verborgen — het is de vraag over de vestigingsplaats van het moederbedrijf van bovenaf dit bericht, beantwoord voor deze hop op dezelfde manier als voor de infrastructuur. Eén model zit volledig buiten de vergadering: onze openbare benchmark voor vertaalkwaliteit gebruikt een LLM-judge (Gemini, met Claude als fallback, via de AI Gateway van Vercel) om machinevertalingen van FLORES-200 referentiezinnen te scoren. Dat is een vaste, openbare dataset — niet de vergadering van wie dan ook.

Wat dit betekent voor uw DPA

Voor de meeste EU-kopers — Duitse Mittelstand, gereguleerde industrieën die standaard GDPR DPA's draaien — beantwoordt het bovenstaande beeld de vraag over dataresidentschap direct: elke hop tijdens uitvoering die uw vergadering neemt, is in de EU. De vestigingsplaats van de leverancier wordt volgens normale praktijk bekendgemaakt in de sub-verwerkerslijst; daar is niets verrassends aan. De kaart van dataresidentschap is één onderdeel; voor de rest van de gegevensbeschermingsverplichtingen — wissen, bewaren, overdraagbaarheid, toestemming — hebben we de codebase door een volledige audit gehaald en elk item afgezet tegen de code.

Voor Franse souveraineté numérique en SecNumCloud-gradige inkoop is de vestigingsplaats van het moederbedrijf van de leverancier zelf deel van het criterium, niet alleen de locatie tijdens uitvoering. Dat is een ander gesprek — een alternatieve implementatietopologie die elke component onder leveranciers met Europese jurisdictie houdt. We draaien dat niet standaard; we zetten het op voor een tenant die het nodig heeft en waar het contract de opzet rechtvaardigt.

Voor Amerikaanse en de meeste APAC-kopers is meestal het tegenovergestelde waar — zij willen een lage latentie vanuit hun eigen regio, wat een ander probleem is. Vandaag draaien we single-region in fra1. Als uw verkeer een Amerikaanse edge rechtvaardigt, plannen we dat met u.

Waar deze post ons toe verplicht

Dit is het beeld op 2026-05-28. We werken het bij wanneer de stack verandert — leveranciersswap, migratie van regio, een nieuwe externe service. De huidige configuratie is verifieerbaar in onze openbare vercel.json, de mind-sdk + Mind API-engine draaiend op OVH Frankrijk, en het dashboard van elke leverancier zelf.

Als iets hier verkeerd lijkt, of uw DPO een antwoord nodig heeft dat deze kaart niet geeft, schrijf het ons. We corrigeren liever een ontbrekend detail dan dat u het ontdekt tijdens een contractbeoordeling.

Bronnen: runtime-regio's en modelrouting geverifieerd tegen de geïmplementeerde configuratie (vercel.json, fly.toml) en de verzonden code; Vercel AI Gateway (het pad voor provider-pinning van de samenvatting), FLORES-200; gecontroleerd augustus 2026.