Z czego składa się jedno spotkanie InterMIND

Prawie każdy produkt jest zbudowany z tego samego domyślnego stosu — z wielkich, własnościowych domyślnych rozwiązań SaaS, po które sięga każdy. To ścieżka o najmniejszym oporze. Na każdej warstwie, gdzie faktycznie żyją dane Twojego spotkania, wybraliśmy inną: nasz własny kod lub open-source, który mogliśmy hostować samodzielnie.

To tekst towarzyszący do Gdzie faktycznie działa jedno spotkanie InterMIND, który zmapował geografię — gdzie wykonuje się każda usługa i jakie dane przez nią przepływają. Ten wpis odpowiada na to, o co pyta 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 decyzji. W przypadku większości produktów większość tych decyzji jest podejmowana domyślnie: Google Analytics, Firebase, Google Translate API, Auth0, React. To ścieżka o najmniejszym oporze i dla większości zespołów jest to rozsądny wybór. Kompromis polega na tym, że każde z nich umieszcza część Twojego stosu za dostawcą, którego kodu nie możesz przeczytać, nie możesz poddać audytowi i nie możesz go opuścić bez przebudowy.

Na każdej warstwie, gdzie faktycznie żyją dane Twojego spotkania, podjęliśmy inną decyzję: nasz własny kod lub oprogramowanie open-source, które mogliśmy hostować samodzielnie. Tam, gdzie dana warstwa nie dotyka treści Twojego spotkania, pozostajemy pragmatyczni i mówimy o tym wprost. Oto cały obraz.

Kręgosłup: silnik to nasz kod, 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 tłumaczenie głosu/czatu działają na mind-sdk + Mind API — naszym własnym silniku, na OVH France. Domyślny sposób na zbudowanie spotkania z tłumaczeniem to nałożenie na siebie SaaS w czasie rzeczywistym (LiveKit) i API tłumaczeń (DeepL, Google); my nie używamy żadnego z nich w ścieżce na żywo. W pętli nie znajduje się żaden model tłumaczeniowy strony trzeciej. (Używamy DeepL — ale tylko do dokumentów wrzucanych na czat, a nie na ścieżkę głosu/czatu na żywo; zobacz mapę środowiska uruchomieniowego. Mechanikę potoku opisaliśmy w Wewnątrz czterech potoków tłumaczeń.)

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 publicznie dostępny pod adresem gitlab.com/mindlabs/api/sdk, prawa autorskie: MindMeeting OÜ, nasza estońska jednostka IP. Rozmawia on z Mind API pod adresem api.mind.com, który prowadzimy samodzielnie na OVH France.

To nie jest układ "patrz, ale nie dotykaj" z dostępem do kodu. BSD 3-Clause to permisywna licencja zatwierdzona przez OSI. Twój zespół ds. bezpieczeństwa może sklonować SDK, dokładnie przeczytać, jak Twój dźwięk i tekst są przechwytywane, ramkowane i przesyłane strumieniowo, oraz poddać tę integrację audytowi pod kątem Twoich własnych wymagań. Silnik po stronie serwera, z którym on rozmawia, jest nasz — a nie czarna skrzynka strony trzeciej — a w pełni samohostowalny silnik dla klienta, który go potrzebuje, znajduje się na naszej mapie drogowej, a nie jest czymś, co oferujemy dzisiaj. Zaktualizujemy ten wpis w momencie, gdy to się pojawi.

Warstwa po warstwie: domyślne rozwiązanie kontra to, co prowadzimy my

Przez tę tabelę przechodzą dwa wątki. Open-source tam, gdzie narzędzie przetwarza Twoje dane — dzięki czemu może być poddane audytowi i w zasadzie hostowane samodzielnie. Otwarte standardy (Postgres, API S3, OIDC) tam, gdzie zależymy od infrastruktury — dzięki czemu nic nie jest przywiązane do cen lub postawy Compliance jednego dostawcy. Postgres może zostać przeniesiony na dowolnego hosta Postgresa; magazyn może zostać przeniesiony do dowolnego magazynu S3; uwierzytelnianie federuje się z dostawcą tożsamości, którego już prowadzisz. 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 open-source, ale też nie podlega jurysdykcji USA.

Kilka z tych pozycji zasługuje na jeszcze jedno zdanie. PostHog jest open-source i można go hostować samodzielnie; prowadzimy go na chmurze UE PostHog i ustawiamy dla niego proxy first-party przez nasze własne źródło, więc zdarzenia nie są po cichu blokowane przez ad-blockery i nie przechodzą przez domenę analityczną strony trzeciej. Uwierzytelnianie nigdy nie trafia do zewnętrznego SaaS uwierzytelniającego, który znajdowałby się między Tobą a Twoimi sesjami — sami prowadzimy przepływ OIDC i federujemy go z Twoim istniejącym dostawcą tożsamości Google lub Microsoft. A fonty 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 offline'owy skrypt zasobów marki, a nigdy aplikacja ładowana przez Twoich użytkowników.

Gdzie jesteśmy pragmatyczni — powiedziane na głos

Nie udajemy, że cały stos jest tworzony ręcznie lub poza USA. Nie jest, a wpis, który twierdziłby inaczej, zostałby obalony przez naszą własną mapę środowiska uruchomieniowego.

Infrastruktura techniczna — hosting i SSR (Vercel), obliczenia serwera spotkań (Fly.io), płatności (Stripe), e-maile transakcyjne (Resend) — działa na SaaS z siedzibą w USA. Stripe i Resend obsługują rozliczenia i zaproszenia i nigdy nie widzą treści spotkań. Vercel i Fly to wynajęta moc obliczeniowa: działa na nich 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. Wszystko to wykonuje się w UE w czasie działania (temat mapy środowiska uruchomieniowego).

To celowy, ograniczony kompromis: posiadanie i open-source'owanie płaszczyzny danych; użycie najlepszego dostępnego SaaS dla płaszczyzny sterującej. Wskazanie tego jest tu istotą — "suwerenność" znaczy niewiele, jeśli wyjątki nie leżą na stole obok sukcesów.

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

Kroki z użyciem modelu językowego — AI digest (tematy, decyzje, punkty akcji), streszczenia dokumentów, akcje generatywne AI note-editor, Ask AI i Mia — działają na bramce AI wybranej przez Twoją organizację: domyślnie Azure OpenAI w EU Data Zone, opcjonalnie Vertex AI na punkcie końcowym w wieloregionie UE lub Amazon Bedrock we Frankfurcie, w naszym własnym dzierżawcy z zerowym retencją danych i bez trenowania na treściach klientów — lub na Twoim własnym, kompatybilnym z OpenAI punkcie końcowym, który utrzymuje model na infrastrukturze, którą kontrolujesz. Spotkaniowe streszczenie oraz akcja translate edytora przechodzą przez potok tłumaczeniowy, a nie przez model językowy. Głos w czasie rzeczywistym, czat, notatki i dokumenty w ogóle nie miały kontaktu z modelem LLM ogólnego przeznaczenia.

To jest uczciwy kształt tej warstwy: modele są własnościowe, a ich dostawcy to amerykańskie firmy prowadzące regiony w UE — ten sam kompromis co infrastruktura techniczna powyżej, wskazany obok niej, a nie ukryty. Zamiast samohostowanego modelu naszej własnej produkcji, wdrożyliśmy wybór: organizacja może całkowicie wyłączyć AI (transkrypcja i tłumaczenie nadal działają), a także może skierować każdą funkcję AI na swój własny punkt końcowy — vLLM we własnym centrum danych, wdrożenie we własnym dzierżawcy — co stawia tę warstwę na tej samej osi otwartej-i-samohostowalnej co reszta płaszczyzny danych. Nasz publiczny benchmark tłumaczeń jest oceniany przez sędziego LLM (Gemini, z Claude jako fallback) na ustalonych zdaniach referencyjnych FLORES-200 — nigdy na czyimkolwiek spotkaniu.

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:

1. Podlegający audytowi. SDK, na którym działa Twoje spotkanie, to kod open-source, który Twój zespół ds. bezpieczeństwa może przeczytać, a silnik za nim jest nasz — a nie czarna skrzynka strony trzeciej.
2. Przenośny. Otwarte standardy na każdej warstwie danych — Postgres, S3, OIDC — oznaczają brak własnościowego zamknięcia. To, co można przenieść, nie jest związane z jednym dostawcą.
3. Samohostowalny. Warstwy danych oparte na otwartych standardach — Postgres, S3, OIDC — już działają na infrastrukturze, którą kontrolujesz; w pełni samohostowalny silnik tłumaczeniowy znajduje się na mapie drogowej dla klienta, który go potrzebuje.

To jest obraz na dzień 2026-06-07. Zaktualizujemy go, gdy stos ulegnie zmianie — wymiana dostawcy, przebudowa warstwy, zastąpienie modelu streszczeń. Bieżąca konfiguracja jest weryfikowalna w naszym otwartym vercel.json, naszym nuxt.config.ts oraz repozytorium mind-sdk na licencji BSD-3-Clause zlinkowanym powyżej.

Jeśli któraś z warstw wydaje się tu błędna lub Twoje przeglądy bezpieczeństwa wymagają odpowiedzi, której ta mapa nie dostarcza, 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 o stosie zweryfikowane względem wdrożonej konfiguracji (vercel.json, nuxt.config.ts) i dostarczonego kodu, sprawdzone w sierpniu 2026.