Z czego zbudowane jest jedno spotkanie InterMIND
Prawie każdy produkt jest zbudowany z tego samego domyślnego stosu — z wielkich, zastrzeżonych rozwiązań SaaS, po które sięga każdy. To ścieżka o najmniejszym oporze. Na każdej warstwie, w której faktycznie znajdują się dane Twojego spotkania, wybraliśmy inną: nasz własny kod lub rozwiązanie open-source, które mogliśmy hostować samodzielnie.
Towarzyszy temu tekst Gdzie faktycznie odbywa się jedno spotkanie InterMIND, w którym zmapowaliśmy geografię — gdzie wykonuje się każda usługa i jakie dane przez nią przepływają. Ten wpis odpowiada na pytanie, które zadaje następnie zespół ds. bezpieczeństwa: z czego to jest zbudowane — i czy możemy to przeczytać, poddać audytowi i zastąpić?
Nie gdzie to działa — z czego jest zrobione, warstwa po warstwie.
Domyślne rozwiązania i ich koszt
Każdy produkt to stos wyborów. W przypadku większości produktów większość tych wyborów jest dokonywana domyślnie: Google Analytics, Firebase, Google Translate API, Auth0, React. To ścieżka o najmniejszym oporze, a dla większości zespołów jest to rozsądna decyzja. Kompromis polega na tym, że każde z nich umieszcza część Twojego stosu za dostawcą, którego nie możesz przeczytać, poddać audytowi ani opuścić bez przepisania kodu.
Dokonaliśmy innego wyboru na każdej warstwie, w której faktycznie znajdują się dane Twojego spotkania: nasz własny kod lub oprogramowanie open-source, które mogliśmy hostować samodzielnie. Tam, gdzie warstwa nie dotyka treści Twojego spotkania, pozostajemy pragmatyczni i mówimy o tym wprost. Oto cały obraz.
Rdzeń: silnik to nasz kod, a nie kod strony trzeciej
Zacznijmy od warstwy, która ma największe znaczenie, ponieważ przepływa przez nią większość Twojego spotkania. Transport w czasie rzeczywistym oraz translacja głosu/czatu działają na mind-sdk + Mind API — naszym własnym silniku, na OVH we Francji. Domyślnym sposobem na stworzenie tłumaczonego spotkania jest przyłączenie SaaS-a w czasie rzeczywistym (LiveKit) do API tłumaczeń (DeepL, Google); my nie używamy żadnego z nich na ścieżce na żywo. W pętli nie znajduje się żaden model tłumaczeń strony trzeciej. (Używamy DeepL — ale tylko do dokumentów wrzuconych na czat, a nie na ścieżce głosu/czatu na żywo; patrz mapa środowiska uruchomieniowego. Mechanikę potoku omówiliśmy w tekście Wewnątrz czterech potoków tłumaczeń.)
Oto część, której nie ma na mapie środowiska uruchomieniowego: zestaw SDK, na którym działa Twoje spotkanie, jest open-source na licencji BSD 3-Clause — klient mind-sdk jest publicznie dostępny na gitlab.com/mindlabs/api/sdk, prawa autorskie MindMeeting OÜ, nasza estońska jednostka IP. Komunikuje się z Mind API pod adresem api.mind.com, który samodzielnie prowadzimy na OVH we Francji.
To nie jest układ typu „patrz, ale nie dotykaj” z dostępem do kodu źródłowego. BSD 3-Clause to permisywna licencja zatwierdzona przez OSI. Twój zespół ds. bezpieczeństwa może sklonować zestaw SDK, dokładnie przeczytać, jak Twoje audio i tekst są przechwytywane, umieszczane w ramkach i przesyłane strumieniowo, oraz poddać tę integrację audytowi pod kątem własnych wymagań. Silnik po stronie serwera, z którym się komunikuje, jest nasz — a nie czarna skrzynka strony trzeciej — a w pełni samodzielnie hostowalny silnik dla najemcy, który go potrzebuje, znajduje się na naszym planie działania, a nie w dzisiejszej ofercie. Zaktualizujemy ten wpis w momencie jego udostępnienia.
Warstwa po warstwie: domyślne rozwiązanie a to, co uruchamiamy
| Warstwa | Zwykłe domyślne rozwiązanie | To, co uruchamiamy | Dlaczego to ma dla Ciebie znaczenie |
|---|---|---|---|
| Silnik w czasie rzeczywistym + translacja (głos + czat) | LiveKit + API tłumaczeń (DeepL / Google) | mind-sdk (klient BSD-3-Clause) + nasze Mind API, OVH Francja | Największy przepływ danych to nasz własny silnik, a nie model strony trzeciej — a jego zestaw SDK klienta jest otwarty i audytowalny |
| Framework frontendowy | React (Meta) / Next.js | Vue + Nuxt | Zarządzane przez społeczność OSS — żadna korporacja nie jest właścicielem frameworka, na którym działa Twój interfejs |
| Analityka produktu | Google Analytics | PostHog | Open-source, chmura UE, proxy first-party przez własną domenę — dane o użyciu nie przepływają do platformy reklamowej strony trzeciej |
| Czcionki | Google Fonts CDN | Hostowane samodzielnie (@nuxt/fonts) | Brak wywołania czcionek strony trzeciej ze strony ładowanej przez Twoich użytkowników — powtarzający się problem z RODO, uniknięty |
| Uwierzytelnianie | Auth0 / Clerk / Firebase Auth | Samodzielnie prowadzony OIDC, sfederowany z Twoim Google / Microsoft | Żaden pośrednik autoryzacji nie przechowuje Twoich sesji — przynosisz własnego dostawcę tożsamości |
| Tłumaczenie dokumentów | Google Translate | DeepL (Kolonia) | Specjalistyczny dostawca z UE, przetwarzanie w Niemczech |
| Treść / dokumentacja | Contentful / Sanity (headless CMS) | Nuxt Content (markdown śledzony w git) | Słowa na naszej stronie znajdują się w naszym repozytorium, a nie w bazie danych dostawcy |
| Baza danych aplikacji | Firestore / DynamoDB (zastrzeżone) | Postgres (na Neon) | Otwarty standard — przenośny na dowolnego hosta Postgresa, brak zastrzeżonego API zapytań do przepisywania |
| Pamięć masowa obiektów | Zastrzeżone API blob | Tigris (zgodny z S3) | Otwarty protokół — nagrania i eksporty są przenośne na dowolny magazyn S3 |
| CRM / sprzedaż | Salesforce / HubSpot | Pipedrive (estoński) | Rekordy klientów i transakcji znajdują się w CRM z siedzibą w UE, a nie w amerykańskiej platformie sprzedażowej |
Przez tę tabelę przebiegają dwa wątki. Open-source tam, gdzie narzędzie przetwarza Twoje dane — aby można je było poddać audytowi i, w zasadzie, hostować samodzielnie. Otwarte standardy (Postgres, API S3, OIDC) tam, gdzie zależymy od infrastruktury — aby nic nie było przypisane do cen lub postawy compliance jednego dostawcy. Postgres może zostać przeniesiony na dowolnego hosta Postgresa; pamięć masowa może zostać przeniesiona na dowolny magazyn S3; uwierzytelnianie federacyjne łączy się z dostawcą tożsamości, którym już zarządzasz. Ostatni wiersz znajduje się na trzeciej osi: CRM przechowujący rekordy klientów ma siedzibę w UE (Pipedrive, estoński) zamiast w amerykańskiej platformie sprzedażowej — nie jest open-source, ale nie podlega również jurysdykcji USA.
Kilka z nich zasługuje na jeszcze jedno zdanie. PostHog jest open-source i możliwy do samodzielnego hostowania; uruchamiamy go w chmurze UE PostHog i przekierowujemy przez proxy first-party z naszego własnego źródła, więc zdarzenia nie są po cichu odrzucane przez ad-blockery i nie przepływają przez domenę analityczną strony trzeciej. Uwierzytelnianie nigdy nie trafia do SaaS-a uwierzytelniającego strony trzeciej, który znajdowałby się między Tobą a Twoimi sesjami — sami prowadzimy przepływ OIDC i federujemy z Twoim istniejącym systemem 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 naszej bazie kodu, to skrypt zasobów marki offline, nigdy w aplikacji ładowanej przez Twoich użytkowników.
Gdzie jesteśmy pragmatyczni — powiedziane wprost
Nie udajemy, że cały stos jest tworzony od zera lub poza USA. Nie jest, a wpis, który twierdziłby inaczej, zostałby zdementowany przez naszą własną mapę środowiska uruchomieniowego.
Infrastruktura towarzysząca — hosting i SSR (Vercel), obliczenia serwera spotkań (Fly.io), płatności (Stripe), e-mail transakcyjny (Resend) — działa na rozwiązaniach SaaS z siedzibą w USA. Stripe i Resend obsługują rozliczenia i zaproszenia i nigdy nie widzą treści spotkania. Vercel i Fly to wynajęte zasoby obliczeniowe: na nich działa nasz własny kod, a serwer spotkań na Fly obsługuje sesję na żywo i transkrypcję, którą odczytuje nasze streszczenie — ale to nasz kod na ich maszynach, a nie produkt dostawcy pochłaniający Twoje spotkanie. Całość wykonuje się w UE w czasie działania (temat mapy środowiska uruchomieniowego).
To celowy, ograniczony kompromis: własność i open-source dla płaszczyzny danych; użycie najlepszego dostępnego SaaS-a dla płaszczyzny sterowania. Wskazanie tego jest punktem — „suwerenność” znaczy niewiele, jeśli wyjątki nie leżą na stole obok sukcesów.
Kroki AI po spotkaniu i plan
Żaden zastrzeżony model z siedzibą w USA nie dotyka treści pochodzących ze spotkania. Kroki oparte na modelu językowym, które są uruchamiane po zakończeniu połączenia — streszczenie AI (tematy, decyzje, elementy akcji), podsumowanie po spotkaniu i edytor notatek AI — wszystkie znajdują się na procesorach w UE. Streszczenie i działania generatywne edytora działają na hostowanym w UE modelu Mistral z zerowym retencjonowaniem danych (dostępnym przez bramkę AI Vercel, przypisaną do dostawcy Mistral). Podsumowanie i działanie tłumaczenia edytora działają na naszym własnym silniku w UE na OVH — tym samym, który odpowiada za głos na żywo i czat. Głos w czasie rzeczywistym, czat, notatki i dokumenty w ogóle nigdy nie miały kontaktu z ogólnego przeznaczenia LLM-em.
Jedyny model z USA wciąż obecny w pętli ocenia nasz publiczny benchmark tłumaczeń — punktując tłumaczenia maszynowe z góry ustalonych zdań referencyjnych FLORES-200, a nigdy czyjekolwiek spotkanie.
Wciąż posuwiamy się dalej w krokach EU-Mistral: kontrolowane przez właściciela wyłączenie (opt-out), aby całkowicie wyłączyć streszczenie, oraz samodzielnie hostowany model streszczający z otwartymi wagami na OVH (klasy Kimi), aby zastąpić zewnętrznego Mistrala. Sednem drogi otwartych wag nie jest to, czyje laboratorium wytrenowało wagi — lecz to, że otwarte wagi mogą działać na infrastrukturze, którą kontrolujemy, co utrzymuje je na tej samej osi otwartej i samodzielnie hostowalnej co reszta płaszczyzny danych. Obie funkcje znajdują się na planie działania, nie są jeszcze udostępnione; zaktualizujemy ten wpis, gdy zostaną wdrożone.
Dlaczego to ma znaczenie wykraczające poza nas
To nie jest inżynieria dla samej inżynierii. Powód, by budować stos w ten sposób, objawia się po Twojej stronie umowy:
- Audytowalny. Zestaw SDK, na którym działa Twoje spotkanie, to kod open-source, który Twój zespół ds. bezpieczeństwa może przeczytać, a znajdujący się za nim silnik jest nasz — a nie czarna skrzynka strony trzeciej.
- Przenośny. Otwarte standardy na każdej warstwie danych — Postgres, S3, OIDC — oznaczają brak zastrzeżonego lock-inu. To, co można przenieść, nie jest przywiązane do jednego dostawcy.
- Samodzielnie hostowalny. Warstwy danych otwartych standardów — Postgres, S3, OIDC — działają już na infrastrukturze, którą kontrolujesz; w pełni samodzielnie hostowalny silnik tłumaczeń znajduje się na planie działania dla najemcy, który go potrzebuje.
Tak wygląda sytuacja na 2026-06-07. Zaktualizujemy ją, gdy stos ulegnie zmianie — zmiana dostawcy, przebudowa warstwy, zastąpienie modelu streszczeń. Bieżąca konfiguracja jest weryfikowalna w naszym otwartym pliku vercel.json, naszym nuxt.config.ts oraz w powiązanym powyżej repozytorium mind-sdk na licencji BSD-3-Clause.
Jeśli któraś z warstw wygląda tu niewłaściwie lub Twój przegląd bezpieczeństwa wymaga odpowiedzi, której ta mapa nie udziela, napisz do nas. Wolimy poprawić brakujący szczegół niż sprawić, byś znalazł go podczas audytu kodu.
Źródła: repozytorium mind-sdk (BSD-3-Clause), FLORES-200; fakty dotyczące stosu zweryfikowane względem wdrożonej konfiguracji (vercel.json, nuxt.config.ts) oraz dostarczonego kodu, sprawdzone w sierpniu 2026.