Z czego składa się jedno spotkanie w InterMIND

Prawie każdy produkt jest zbudowany z tego samego domyślnego stosu: wielkich, zamkniętych usług SaaS, po które sięgają wszyscy. To ścieżka bez tarcia. Na każdej warstwie, na której faktycznie znajdują się dane z Twoich spotkań, wybraliśmy inną drogę: nasz własny kod albo open source, który moglibyśmy hostować samodzielnie.

To uzupełnienie wpisu Gdzie naprawdę działa jedno spotkanie w InterMIND, który opisywał geografię: gdzie wykonuje się każda usługa i jakie dane przez nią przechodzą. Ten wpis odpowiada na kolejne pytanie zespołu ds. bezpieczeństwa: z czego to jest zbudowane — i czy możemy to przeczytać, zaudytować i zastąpić?

Nie gdzie działa, lecz z czego jest zrobione, warstwa po warstwie.

Ustawienia domyślne i ich koszt

Każdy produkt to stos decyzji. W większości produktów większość z nich zapada domyślnie: Google Analytics, Firebase, Google Translate API, Auth0, React. To ścieżka bez tarcia i dla większości zespołów to rozsądny wybór. Koszt jest taki, że każde z tych narzędzi stawia fragment Twojego stosu za dostawcą, którego nie możesz przeczytać, zaudytować ani opuścić bez przepisywania kodu.

Na każdej warstwie, na której faktycznie żyją dane z Twoich spotkań, wybraliśmy inaczej: nasz własny kod albo oprogramowanie open source, które moglibyśmy hostować samodzielnie. Tam, gdzie warstwa nie dotyka treści Twojego spotkania, jesteśmy pragmatyczni i mówimy o tym otwarcie. Oto cały obraz.

Kręgosłup: silnik to nasz kod, nie cudzy

Zacznijmy od warstwy, która liczy się najbardziej, bo przechodzi przez nią największa część Twojego spotkania. Transport w czasie rzeczywistym oraz tłumaczenie głosu i czatu działają na mind-sdk + Mind API — naszym własnym silniku, w OVH we Francji. Domyślny sposób budowania przetłumaczonego spotkania to dołożenie SaaS-u czasu rzeczywistego (LiveKit) do API tłumaczeniowego (DeepL, Google); my nie uruchamiamy żadnego z nich w ścieżce na żywo. W pętli nie ma modelu tłumaczeniowego żadnej strony trzeciej. (DeepL używamy, ale tylko do dokumentów wrzucanych na czat, nie w ścieżce głosu i czatu na żywo; zobacz mapę środowiska uruchomieniowego. Mechanikę potoków opisaliśmy w Jak działają cztery potoki tłumaczeniowe.)

Oto część, której nie ma na mapie środowiska uruchomieniowego: SDK, na którym działa Twoje spotkanie, jest open source na licencji BSD 3-Clause — klient mind-sdk jest publiczny pod adresem gitlab.com/mindlabs/api/sdk, prawa autorskie: MindMeeting OÜ, nasz estoński podmiot od własności intelektualnej. Komunikuje się z Mind API pod adresem api.mind.com, które prowadzimy sami w OVH we Francji.

To nie jest układ typu „patrz, ale nie dotykaj”, znany z kodu dostępnego tylko do wglądu. BSD 3-Clause to permisywna licencja zatwierdzona przez OSI. Twój zespół ds. bezpieczeństwa może sklonować SDK, przeczytać dokładnie, jak przechwytywane, ramkowane i strumieniowane są Twój dźwięk i tekst, oraz zaudytować tę integrację pod kątem własnych wymagań. Silnik po stronie serwera, z którym SDK się komunikuje, jest nasz, a nie czarną skrzynką strony trzeciej. W pełni samodzielnie hostowalny silnik dla klienta, który go potrzebuje, jest w naszych planach, ale dziś go nie oferujemy. Zaktualizujemy ten wpis w chwili, gdy się pojawi.

Warstwa po warstwie: ustawienie domyślne a to, co uruchamiamy

Przez tę tabelę przewijają się dwa wątki. Open source tam, gdzie narzędzie przetwarza Twoje dane — aby można je było zaudytować i w zasadzie hostować samodzielnie. Otwarte standardy (Postgres, API S3, OIDC) tam, gdzie polegamy na infrastrukturze — aby nic nie było uwiązane do cennika ani polityki zgodności jednego dostawcy. Postgres można przenieść do dowolnego hosta Postgres; magazyn można przenieść do dowolnego magazynu S3; uwierzytelnianie federuje się z dostawcą tożsamości, którego już używasz. Ostatni wiersz leży na trzeciej osi: CRM przechowujący rekordy klientów ma siedzibę w UE (Pipedrive, estoński), a nie jest amerykańską platformą sprzedażową — nie jest to open source, ale nie podlega też jurysdykcji USA.

Kilka z tych elementów zasługuje na jedno zdanie więcej. PostHog jest open source i można go hostować samodzielnie; my korzystamy z jego chmury w UE i przekazujemy ruch jako first-party przez naszą własną domenę, więc zdarzenia nie są po cichu blokowane przez adblockery i nie przechodzą przez zewnętrzną domenę analityczną. Uwierzytelnianie nigdy nie trafia do zewnętrznego SaaS-u, który stałby między Tobą a Twoimi sesjami — przepływ OIDC prowadzimy sami i federujemy go z Twoją istniejącą tożsamością Google lub Microsoft. A czcionki na każdej stronie są serwowane z naszej własnej domeny; jedyne miejsce, w którym Google Fonts pojawia się w naszym kodzie, to skrypt offline do zasobów marki, nigdy aplikacja, którą ładują Twoi użytkownicy.

Gdzie jesteśmy pragmatyczni — mówimy to wprost

Nie udajemy, że cały stos jest napisany własnoręcznie albo że nie ma w nim amerykańskich usług. Tak nie jest, a wpis twierdzący inaczej zostałby podważony przez naszą własną mapę środowiska uruchomieniowego.

Infrastruktura pomocnicza — hosting i SSR (Vercel), moc obliczeniowa serwera spotkań (Fly.io), płatności (Stripe), e-maile transakcyjne (Resend) — działa na SaaS-ach z siedzibą w USA. Stripe i Resend obsługują rozliczenia i zaproszenia i nigdy nie widzą treści spotkań. Vercel i Fly to wynajmowana moc obliczeniowa: działa na nich nasz własny kod, a serwer spotkań na Fly obsługuje sesję na żywo i transkrypt, który czyta nasz digest — ale to nasz kod na ich maszynach, a nie produkt dostawcy, który przyjmuje Twoje spotkanie. Całość wykonuje się w czasie działania w UE (to temat mapy środowiska uruchomieniowego).

To świadomy, ograniczony kompromis: warstwa danych jest nasza lub oparta na open source; w warstwie sterowania używamy najlepszego dostępnego SaaS-u. Nazwanie tego wprost jest sednem — „suwerenność” niewiele znaczy, jeśli wyjątki nie leżą na stole obok sukcesów.

Kroki AI i plan, który został wdrożony

Kroki oparte na modelach językowych — AI digest (tematy, decyzje, action items), podsumowania dokumentów, generatywne akcje edytora notatek AI, Ask AI i Mia — działają na bramce AI wybranej przez Twoją organizację: domyślnie Azure OpenAI w EU Data Zone, Vertex AI na wieloregionowym endpoincie UE lub Amazon Bedrock we Frankfurcie, do wyboru, każdy w naszym własnym tenancie, z zerowym przechowywaniem danych i bez trenowania na treściach klientów — albo na Twoim własnym endpoincie zgodnym z OpenAI, który utrzymuje model na infrastrukturze, którą kontrolujesz. Podsumowanie po spotkaniu oraz akcja tłumacz w edytorze przechodzą przez ścieżkę tłumaczeniową, a nie przez model językowy. Głos, czat, notatki i dokumenty w czasie rzeczywistym nigdy nie trafiały do ogólnego LLM.

Taki jest uczciwy kształt tej warstwy: modele są zamknięte, a ich dostawcy to amerykańskie firmy prowadzące regiony w UE — ten sam kompromis co w infrastrukturze pomocniczej powyżej, podany obok niej, a nie ukryty. Zamiast własnego, samodzielnie hostowanego modelu wdrożyliśmy wybór: organizacja może całkowicie wyłączyć AI (transkrypcja i tłumaczenie nadal działają) i może skierować każdą funkcję AI na własny endpoint — vLLM we własnym centrum danych, wdrożenie we własnym tenancie — co stawia tę warstwę na tej samej osi „otwarte i samodzielnie hostowalne” co reszta warstwy danych. Nasz publiczny benchmark tłumaczeń jest oceniany przez LLM jako sędziego (Gemini, z Claude jako rozwiązaniem zapasowym) na stałych zdaniach referencyjnych FLORES-200 — nigdy na niczyim spotkaniu.

Dlaczego to ma znaczenie także poza nami

To nie jest inżynieria dla samej inżynierii. Powód, by budować stos w ten sposób, widać po Twojej stronie umowy:

1. Audytowalność. SDK, na którym działa Twoje spotkanie, to kod open source, który może przeczytać Twój zespół ds. bezpieczeństwa, a silnik za nim jest nasz własny — nie czarna skrzynka strony trzeciej.
2. Przenośność. Otwarte standardy na każdej warstwie danych — Postgres, S3, OIDC — oznaczają brak zamkniętego uzależnienia od dostawcy. To, co można przenieść, nie jest przywiązane do jednego dostawcy.
3. Możliwość samodzielnego hostowania. Otwarte warstwy danych — Postgres, S3, OIDC — już dziś działają na infrastrukturze, którą kontrolujesz; w pełni samodzielnie hostowany silnik tłumaczeniowy jest w planach dla klienta, który go potrzebuje.

Taki jest obraz na dzień 2026-06-07. Zaktualizujemy go, gdy stos się zmieni — wymiana dostawcy, przebudowana warstwa, zastąpiony model digestu. Obecną konfigurację można zweryfikować w naszym otwartym vercel.json, w nuxt.config.ts oraz w repozytorium mind-sdk na licencji BSD-3-Clause, do którego link podano wyżej.

Jeśli jakaś warstwa wygląda tu źle albo Twój przegląd bezpieczeństwa wymaga odpowiedzi, której ta mapa nie daje, napisz do nas. Wolimy poprawić brakujący szczegół, niż żebyś znalazł go podczas audytu kodu.

Źródła: repozytorium mind-sdk (BSD-3-Clause), FLORES-200; fakty o stosie zweryfikowano na podstawie wdrożonej konfiguracji (vercel.json, nuxt.config.ts) i wydanego kodu, sprawdzone w sierpniu 2026.