Gdzie faktycznie odbywa się jedno spotkanie InterMIND

Każda poważna rozmowa o zakupach korporacyjnych dociera ostatecznie do tego samego pytania: "Gdzie trafiają te dane?" DPO chce listy podprocesorów. CIO chce wiedzieć, którzy dostawcy mają siedzibę w USA. Dział prawny chce diagramu ze strzałkami.

Wolelibyśmy, abyś miał pełny obraz, zamiast wysyłać go fragmentami w e-mailach. Oto ścieżka danych jednego spotkania — każdy zewnętrzny serwis, którego dotyka, gdzie się ono wykonuje i jakie dane przez niego przepływają. Zweryfikowano w stosunku do rzeczywistej konfiguracji wdrożenia z 2026-05-28.

Każda ścieżka dotykająca treści spotkania znajduje się w UE w czasie rzeczywistym — w tym kroki AI po spotkaniu, które wcześniej oznaczaliśmy jako jedyną lukę, a które od tego czasu przenieśliśmy na procesory w UE. Jasno mówimy, gdzie znajduje się jedyny pozostały model z USA i dlaczego nigdy nie ma wglądu w twoje spotkanie.

Ten wpis przedstawia gdzie odbywa się twoje spotkanie. Tekst towarzyszący, Z czego składa się jedno spotkanie InterMIND, przedstawia z czego jest zbudowane — które warstwy to nasz własny kod, które to open-source, a gdzie jesteśmy pragmatyczni wobec własnościowego SaaS.

Co faktycznie oznacza „gdzie to działa”

W rozmowach o kontroli nad danymi myli się dwie rzeczy, które nie są tym samym:

1. Środowisko uruchomieniowe / ścieżka danych. Gdzie bajty twojego spotkania są fizycznie przetwarzane w trakcie żądania. To jest to, czym faktycznie zajmują się przepisy o rezydencji danych i większość umów DPA.
2. Siedziba korporacyjna dostawcy. Gdzie dostawca SaaS jest prawnie zarejestrowany. O tym są dyskusje wokół CLOUD-Act — o teoretyczny zasięg amerykańskiego nakazu wobec jednostki dominującej dostawcy, niezależnie od tego, gdzie wykonuje się obciążenie.

Prawie każde pytanie „czy to jest w UE?” to tak naprawdę jedno z tych dwóch, zadane niedokładnie. Poniżej odpowiadamy na nie oddzielnie dla każdego dostawcy.

Ścieżka danych jednego spotkania

Prześledź jedno połączenie od dołączenia do e-maila z podsumowaniem:

1. Przeglądarka otwiera stronę spotkania. SSR działa na Vercel, przypisane do fra1 (Frankfurt). Wszystkie dane żądań/odpowiedzi — ciasteczka sesyjne, ładunki API, HTML renderowany po stronie serwera — są przetwarzane w UE w czasie rzeczywistym.
2. WebSocket łączy się z naszym serwerem spotkań w Paryżu (cdg). Orkiestracja spotkań, obecność, sygnalizacja — wszystko w UE.
3. Rozpoznawanie mowy odbywa się w przeglądarce mówiącego. Lokalnie. Nie opuszcza urządzenia, dopóki wynikająca z niego transkrypcja nie zostanie wysłana do tłumaczenia. (Powody opisaliśmy w tekście Wewnątrz czterech potoków tłumaczeniowych.)
4. Tłumaczenie głosu i czatu trafia do naszego własnego silnika na OVH France. To jest mind-sdk + Mind API — nasz kod, nasze serwery, we Francji. W pętli nie ma żadnego modelu strony trzeciej. Budżet poniżej sekundy, pula WebSocket dla każdego języka, rezydencja danych w UE na każdym etapie.
5. Dokument upuszczony na czat (PDF, DOCX, PPTX, XLSX) wędruje po stronie serwera z serwera ws w Paryżu do DeepL w Kolonii. Niemiecka firma, niemieckie przetwarzanie. Głos i czat nie mają styczności z DeepL.
6. Dane aplikacji — użytkownicy, zespoły, wiadomości, metadane spotkań — znajdują się w Neon Postgres na AWS Frankfurt (eu-central-1). Migawki w tym samym regionie.
7. Nagrania, załączniki, eksportowane dane są przechowywane na Tigris, pamięci masowej zgodnej z S3 na Fly. Replikowane na krawędzi sieci; zasobnik można skonfigurować dla wielu regionów UE dla tenantów, którzy potrzebują silniejszego przypisania.
8. Błędy i ślady wydajności trafiają do instancji Sentry w UE (de.sentry.io). Organizacja w USA została wycofana w maju.
9. Analityka produktowa trafia do PostHog EU (eu.i.posthog.com).
10. Maile transakcyjne (magiczne linki, zaproszenia, potwierdzenia) są wysyłane przez Resend z eu-west-1 (Irlandia).

Wszystko powyżej odbywa się w UE w czasie rzeczywistym. Silnik tłumaczeniowy — część, przez którą przepływa większość twoich danych — to również nasz własny kod, a nie kod strony trzeciej. Zestaw SDK klienta, na którym działa, jest open-source (BSD-3-Clause) i jest obecnie audytowalny; własny hosting samego silnika znajduje się na naszej mapie drogowej dla klientów, którzy tego potrzebują.

Mapa dostawców

Dwa najcięższe pod względem wolumenu przepływy danych — tłumaczenie głosu/czatu przez nasz własny silnik na OVH i tłumaczenie dokumentów przez DeepL — akurat należą do dwóch dostawców, których jednostka dominująca znajduje się w UE. To pokrywa większość treści spotkań. Pełna lista podprocesorów ze szczegółami dotyczącymi siedziby korporacyjnej trafia do DPA zgodnie ze standardową praktyką; powyższa tabela to widok w czasie rzeczywistym, którego dotyczy większość klauzul o rezydencji danych.

Kroki AI po spotkaniu, nazywając rzeczy po imieniu

Po zakończeniu połączenia uruchamiamy kilka kroków modelu językowego na tym, co zostało powiedziane: AI digest (tematy, decyzje, punkty akcji, otwarte pytania), podsumowanie po spotkaniu oraz AI note-editor (przetłumacz notatkę, lub napraw / rozszerz / uprość ją). To jedyne miejsca, w których model ogólnego przeznaczenia ma styczność z treścią pochodzącą ze spotkania — i wszystkie one działają teraz na procesorach w UE:

• Digest działa na hostowanym w UE modelu Mistral (mistral-large-3, z fallbackiem mistral-medium-3.5), osiąganym przez AI Gateway od Vercel przypisanym do dostawcy Mistral z zerowym przechowywaniem danych (zero-data-retention) — żądanie kończy się niepowodzeniem, zamiast przełączać się na host bez ZDR lub w USA.
• Podsumowanie i akcja translate edytora przechodzą przez nasz własny silnik w UE na OVH — ten sam, który tłumaczy na żywo głos i czat — więc podsumowanie nigdy nie opuszcza płaszczyzny danych, w której spotkanie już się odbyło.
• Akcje generatywne edytora (napraw, rozszerz, skróć, uprość, streszcz) nie mogą działać na silniku tłumaczeniowym, więc korzystają z tej samej ścieżki EU Mistral + zero-data-retention, co digest.

Głos w czasie rzeczywistym, czat w czasie rzeczywistym, notatki i tłumaczenie dokumentów nigdy nie przechodzą przez żadne z nich — ich rezydencja od początku znajdowała się w UE.

Jedno miejsce, w którym model z siedzibą w USA jest nadal w pętli, nie dotyka żadnych danych spotkania: nasz publiczny benchmark jakości tłumaczenia wykorzystuje model frontierowy jako zautomatyzowanego sędziego, oceniającego tłumaczenia maszynowe zdań referencyjnych FLORES-200. To jest stały, publiczny zbiór danych — a nie czyjeś spotkanie.

Wciąż idziemy o krok dalej w krokach EU-Mistral: planowane jest opt-out kontrolowane przez właściciela, aby całkowicie wyłączyć digest, oraz samodzielnie hostowany model z otwartymi wagami (klasy Kimi) na OVH, który zastąpi zewnętrznego Mistrala w zadaniach streszczania, które nie wymagają modelu rozumującego klasy frontier. Oba znajdują się na naszej mapie drogowej, nie są jeszcze udostępnione; zaktualizujemy ten wpis, gdy zostaną wdrożone.

Co to oznacza dla twojego DPA

Dla większości kupców z UE — niemieckiego Mittelstandu, branż regulowanych korzystających ze standardowych umów DPA RODO — powyższy obraz bezpośrednio odpowiada na pytanie o rezydencję danych: każdy etap w czasie rzeczywistym, przez który przechodzi twoje spotkanie, znajduje się w UE. Siedziba dostawcy jest ujawniana na liście podprocesorów zgodnie ze standardową praktyką; nie ma tam nic zaskakującego. Mapa rezydencji to jeden element; jeśli chodzi o pozostałe zobowiązania dotyczące ochrony danych — usunięcie, retencja, przenoszalność, zgoda — przeprowadziliśmy pełny audyt bazy kodu i obsłużyliśmy każdy punkt w kodzie.

Dla francuskiej souveraineté numérique i zakupów klasy SecNumCloud, siedziba korporacyjna dostawcy jest sama w sobie częścią kryterium, a nie tylko lokalizacja w czasie rzeczywistym. To inna rozmowa — alternatywna topologia wdrożenia, która utrzymuje każdy komponent u dostawców pod jurysdykcją europejską. Nie uruchamiamy tego domyślnie; stworzymy to dla tenanta, który tego potrzebuje i gdzie umowa uzasadnia takie wdrożenie.

Dla kupców z terytorium USA i większości z regionu APAC zazwyczaj prawdą jest odwrotność — chcą niskich opóźnień ze swojego regionu, co jest innym problemem. Obecnie działamy w jednym regionie w fra1. Jeśli twój ruch uzasadnia węzeł brzegowy w USA, zaplanujemy to z tobą.

Do czego zobowiązuje nas ten wpis

Tak wygląda sytuacja na 2026-05-28. Zaktualizujemy ten wpis, gdy zmieni się nasz stos — zmiana dostawcy, migracja regionu, nowy zewnętrzny serwis. Bieżąca konfiguracja jest weryfikowalna w naszym otwartym vercel.json, w silniku mind-sdk + Mind API działającym na OVH France oraz na panelu każdego z dostawców.

Jeśli coś tutaj wygląda na błędne lub twój DPO potrzebuje odpowiedzi, której nie daje ta mapa, napisz do nas. Wolelibyśmy poprawić brakujący szczegół, niż sprawić, byś odkrył to podczas przeglądu umowy.

Źródła: regiony w czasie rzeczywistym i trasowanie modeli zweryfikowane względem wdrożonej konfiguracji (vercel.json, fly.toml) oraz opublikowanego kodu; Vercel AI Gateway (ścieżka przypisywania dostawcy dla digestu), FLORES-200; sprawdzone w sierpniu 2026.