Waar één InterMIND-vergadering daadwerkelijk draait

Elk serieus enterprise-aankoopgesprek komt uiteindelijk uit bij dezelfde vraag: "Waar gaan deze gegevens naartoe?" De DPO wil een lijst van sub-verwerkers. 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 plaatje dan het stukje bij beetje per e-mail te sturen. Hier is dus het datapad van één vergadering — elke externe service die het raakt, waar elk wordt uitgevoerd, en welke data erdoorheen stroomt. Geverifieerd tegen de daadwerkelijke implementatieconfiguratie op 2026-05-28.

Elk pad dat vergaderinhoud raakt, is EU tijdens runtime — inclusief de AI-stappen na de vergadering, die we vroeger als de enige kloof bestempelden en inmiddels naar EU-processors hebben verplaatst. We geven eerlijk aan waar het ene overgebleven VS-model zich bevindt, en waarom het nooit in aanraking komt met uw vergadering.

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

Wat "waar het draait" daadwerkelijk betekent

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

1. Runtime / datapad. Waar de bytes van uw vergadering fysiek worden verwerkt tijdens het verzoek. Dit is waar dataresidency-regelgeving en de meeste DPA's eigenlijk over gaan.
2. Statutaire 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 moedermaatschappij van de leverancier, ongeacht waar de workload draait.

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

Het datapad van één vergadering

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

1. Browser opent de vergaderpagina. SSR draait op Vercel, vastgezet op fra1 (Frankfurt). Alle aanvraag-/responsdata — sessiecookies, API-payloads, door de server gerenderde HTML — wordt tijdens runtime in de EU verwerkt.
2. WebSocket maakt verbinding met onze vergaderserver in Parijs (cdg). Vergaderorchestratie, aanwezigheid, signalering — allemaal EU.
3. Spraakherkenning draait in de browser van de spreker. Lokaal. Verlaat nooit het apparaat totdat de resulterende transcriptie voor vertaling wordt verzonden. (We hebben uitgelegd waarom in Binnen de vier vertaalpijplijnen.)
4. Spraak- en chatvertaling bereiken onze eigen engine op OVH France. Dit is mind-sdk + de Mind API — onze code, onze hosts, in Frankrijk. Er zit geen model van een derde partij in de keten. Sub-seconde budget, per-taal WebSocket-pool, EU-resident bij elke hop.
5. Een document dat in de chat wordt gedeeld (PDF, DOCX, PPTX, XLSX) gaat via de server vanaf de Parijse ws-server naar DeepL in Keulen. Duits bedrijf, Duitse verwerking. Spraak en chat raken DeepL niet.
6. Toepassingsdata — gebruikers, teams, berichten, vergader-metadata — staat 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-region EU voor tenants die het strakker vastgezet willen hebben.
8. Fouten en prestatiesporen gaan naar Sentry's EU-instantie (de.sentry.io). De Amerikaanse org is in mei buiten gebruik gesteld.
9. Productanalytics 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 runtime. De vertaalengine — het deel waar de meeste van uw data daadwerkelijk doorheen stroomt — 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; het zelf hosten van de engine zelf staat op de roadmap voor een klant die het nodig heeft.

De leverancierskaart

De twee zwaarste gegevensstromen qua volume — spraak-/chatvertaling via onze eigen engine op OVH en documentvertaling via DeepL — gebeuren toevallig ook de twee leveranciers wiens moedermaatschappij in de EU staat. Dat dekt het grootste deel van de vergaderinhoud. De volledige lijst van sub-verwerkers met details over de statutaire vestigingsplaats wordt als standaardpraktijk in de DPA opgenomen; de tabel hierboven is de runtime-weergave, waar de meeste dataresidency-clausules over gaan.

De AI-stappen na de vergadering, duidelijk benoemd

Nadat de oproep is beëindigd, voeren we een paar taalmodel-stappen uit op wat er is gezegd: de AI-digest (onderwerpen, beslissingen, actie-items, open vragen), de post-meeting samenvatting, en de AI-notitie-editor (vertaal een notitie, of repareer / breid uit / vereenvoudig het). Dit zijn de enige plekken waar een algemeen model vergaderafgeleide inhoud raakt — en ze draaien nu allemaal op EU-processors:

• De digest draait op EU-gehoste Mistral (mistral-large-3, mistral-medium-3.5 fallback), bereikt via Vercel's AI Gateway vastgezet op de Mistral-provider met zero-data-retention — het verzoek faalt in plaats van terug te vallen op een non-ZDR of VS-host.
• De summary en de vertaalactie van de editor gaan via onze eigen EU-engine op OVH — dezelfde engine die live spraak en chat vertaalt — zodat de samenvatting het dataplane waarin de vergadering al plaatsvond nooit verlaat.
• De generatieve acties van de editor (repareren, uitbreiden, verminderen, vereenvoudigen, samenvatten) kunnen niet op een vertaalengine draaien, dus gebruiken ze hetzelfde EU Mistral + zero-data-retention pad als de digest.

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

De enige plek waar een in de VS gevestigd model nog in de keten zit, raakt geen vergaderdata: onze openbare vertaalkwaliteit-benchmark gebruikt een frontier-model als een geautomatiseerde rechter, die machinevertalingen van FLORES-200 referentiezinnen beoordeelt. Dat is een vaste, openbare dataset — niet iemands vergadering.

We gaan nog verder met de EU-Mistral-stappen: een geplande door de eigenaar gecontroleerde opt-out om de digest volledig uit te schakelen, en een zelf-gehost open-weights model (Kimi-klasse) op OVH om de externe Mistral te vervangen voor samenvattingstaken die geen frontier-reasoner nodig hebben. Beide staan op de roadmap, zijn nog niet verzonden; we werken dit bericht bij wanneer ze live gaan.

Wat dit betekent voor uw DPA

Voor de meeste EU-kopers — de Duitse Mittelstand, gereguleerde industrieën die werken met standaard GDPR-DPA's — beantwoordt het bovenstaande plaatje de vraag over dataresidency direct: elke runtime-hop die uw vergadering maakt, vindt plaats in de EU. De vestigingsplaats van de leverancier wordt volgens normale praktijk in de sub-verwerkerlijst bekendgemaakt; daar is niets verrassends aan. De residency-kaart is één onderdeel; voor de rest van de gegevensbeschermingsverplichtingen — wissen, bewaartermijnen, 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 statutaire vestigingsplaats van de leverancier zelf deel van het criterium, niet alleen de runtime-locatie. Dat is een ander gesprek — een alternatieve implementatietopologie die elk 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 kopers in de VS zelf en het grootste deel van APAC is het omgekeerde meestal 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 VS-edge rechtvaardigt, plannen we dat samen met u.

Waar dit bericht ons aan committeert

Dit is het plaatje op 2026-05-28. We werken het bij wanneer de stack verandert — leverancier wisselen, regio migreren, een nieuwe externe service. De huidige configuratie is verifieerbaar in onze open vercel.json, de mind-sdk + Mind API-engine draaiend op OVH France, 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 ons dan. We corrigeren liever een ontbrekend detail dan dat u het ontdekt tijdens een contractbeoordeling.

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