Из чего состоит одна встреча в InterMIND
Почти каждый продукт собран из одного и того же стандартного стека — крупных проприетарных SaaS-сервисов по умолчанию, к которым все тянутся. Это путь наименьшего сопротивления. На каждом слое, где реально живут данные вашей встречи, мы пошли другим путём: собственный код или open-source, который можно развернуть у себя.
Это дополнение к статье Где на самом деле работает одна встреча в InterMIND, которая описывала географию — где выполняется каждый сервис и какие данные через него проходят. Эта статья отвечает на следующий вопрос, который задаёт служба безопасности: из чего это сделано — и можем ли мы это прочитать, проаудировать и заменить?
Не где работает — а из чего сделано, слой за слоем.
Стандартные решения и их цена
Любой продукт — это набор решений. Для большинства продуктов большинство этих решений принимается по умолчанию: Google Analytics, Firebase, Google Translate API, Auth0, React. Это путь наименьшего сопротивления, и для большинства команд это разумный выбор. Плата за это в том, что каждый такой выбор оставляет часть вашего стека за поставщиком, чей код вы не можете прочитать, проаудировать и от которого нельзя уйти без переписывания.
Мы сделали другой выбор на каждом слое, где реально живут данные вашей встречи: собственный код или open-source-софт, который мы могли развернуть сами. Там, где слой не касается содержимого вашей встречи, мы остаёмся прагматичными и говорим об этом прямо. Вот полная картина.
Основа: движок — это наш код, а не чужой
Начнём со слоя, который важнее всего, потому что через него проходит большая часть вашей встречи. Транспорт в реальном времени и перевод голоса/чата работают на mind-sdk + Mind API — нашем собственном движке на OVH France. Стандартный способ построить встречу с переводом — это прикрутить SaaS реального времени (LiveKit) к API перевода (DeepL, Google); ни тот, ни другой не участвуют в живом тракте. Никакой сторонней модели перевода в цепочке нет. (Мы используем DeepL — но только для документов, отправленных в чат, не для живого голоса/чата; см. карту runtime. Механику пайплайна мы разобрали в Внутри четырёх пайплайнов перевода.)
Вот что не было в карте runtime: SDK, на котором работает ваша встреча, — это open source под лицензией BSD 3-Clause — клиент mind-sdk опубликован по адресу gitlab.com/mindlabs/api/sdk, copyright MindMeeting OÜ, наше эстонское IP-юрлицо. Он общается с Mind API по адресу api.mind.com, который мы сами разворачиваем на OVH France.
Это не схема «смотри, но не трогай» в духе source-available. BSD 3-Clause — это разрешительная лицензия, одобренная OSI. Ваша служба безопасности может клонировать SDK, прочитать ровно то, как ваше аудио и текст захватываются, упаковываются и передаются, и проаудировать эту интеграцию по своим требованиям. Серверный движок, с которым он общается, — наш, а не чёрный ящик третьей стороны, и полностью self-hosted движок для тенанта, которому он нужен, есть у нас в roadmap, но пока мы его не предлагаем. Мы обновим эту статью сразу, как только он выйдет.
Слой за слоем: стандартное решение vs. то, что используем мы
| Слой | Стандартное решение | Что используем мы | Почему это важно для вас |
|---|---|---|---|
| Движок реального времени + перевода (голос + чат) | LiveKit + API перевода (DeepL / Google) | mind-sdk (клиент под BSD-3-Clause) + наш Mind API, OVH France | Самый тяжёлый поток данных идёт через наш собственный движок, а не через стороннюю модель — и его клиентский SDK открыт и аудируемый |
| Frontend-фреймворк | React (Meta) / Next.js | Vue + Nuxt | OSS под управлением сообщества — ни одна корпорация не владеет фреймворком, на котором работает ваш UI |
| Продуктовая аналитика | Google Analytics | PostHog | Open-source, EU-облако, проксируется как first-party через наш собственный домен — данные об использовании не уходят в стороннюю рекламную платформу |
| Шрифты | Google Fonts CDN | Self-hosted (@nuxt/fonts) | Никаких сторонних запросов за шрифтами со страницы, которую загружают ваши пользователи — частая претензия по GDPR, которой удалось избежать |
| Аутентификация | Auth0 / Clerk / Firebase Auth | Собственный OIDC, федерация с вашим Google / Microsoft | Никакой посредник по аутентификации не держит ваши сессии — вы приносите своего провайдера идентификации |
| Перевод документов | Google Translate | DeepL (Кёльн) | Специализированный EU-вендор, обработка в Германии |
| Контент / документация | Contentful / Sanity (headless CMS) | Nuxt Content (markdown под git) | Слова на нашем сайте живут в нашем репозитории, а не в базе вендора |
| База данных приложения | Firestore / DynamoDB (проприетарные) | Postgres (на Neon) | Открытый стандарт — переносим на любой Postgres-хостинг, нет проприетарного API запросов, который пришлось бы переписывать |
| Объектное хранилище | Проприетарные blob API | Tigris (S3-совместимое) | Открытый протокол — записи и экспорты переносимы в любое S3-хранилище |
| CRM / продажи | Salesforce / HubSpot | Pipedrive (Эстония) | Записи о клиентах и сделках лежат в EU-резидентной CRM, а не в US-платформе продаж |
В этой таблице прослеживаются две линии. Open source там, где инструмент обрабатывает ваши данные — чтобы его можно было проаудировать и в принципе развернуть у себя. Открытые стандарты (Postgres, S3 API, OIDC) там, где мы зависим от инфраструктуры — чтобы ничто не было привязано к ценам и комплаенс-позиции одного вендора. Postgres переносится на любой Postgres-хостинг; хранилище — в любой S3; аутентификация федерируется с провайдером идентификации, который у вас уже есть. Последняя строка лежит на третьей оси: CRM, в которой хранятся записи о клиентах, EU-резидентна (Pipedrive, Эстония), а не US-платформа продаж — это не open source, но и не под юрисдикцией США.
Пара пунктов заслуживают ещё одного предложения. PostHog — open source и self-hostable; мы запускаем его на EU-облаке PostHog и проксируем как first-party через наш собственный origin, чтобы события не блокировались блокировщиками рекламы и не проходили через сторонний аналитический домен. Аутентификация никогда не уходит к стороннему auth-SaaS, который сидел бы между вами и вашими сессиями — мы сами выполняем OIDC-флоу и федерируемся с вашим существующим Google или Microsoft. А шрифты на каждой странице раздаются с нашего собственного домена; единственное место, где Google Fonts встречается в нашей кодовой базе, — это офлайн-скрипт для брендовых ассетов, никогда не приложение, которое загружают ваши пользователи.
Где мы прагматичны — говорим прямо
Мы не делаем вид, что весь стек собран вручную или не из США. Это не так, и статья, утверждающая обратное, противоречила бы нашей же карте runtime.
Сантехника — хостинг и SSR (Vercel), вычислительные ресурсы сервера встреч (Fly.io), платежи (Stripe), транзакционная почта (Resend) — работает на US-резидентных SaaS. Stripe и Resend занимаются биллингом и приглашениями и никогда не видят содержимого встреч. Vercel и Fly — это арендованные вычислительные мощности: на них работает наш собственный код, и сервер встреч на Fly действительно обрабатывает живую сессию и транскрипт, который читает наш digest, — но это наш код на их машинах, а не продукт вендора, поглощающий вашу встречу. Всё это выполняется в ЕС в runtime (об этом — карта runtime).
Это сознательный, ограниченный компромисс: владеем и открываем data plane; используем лучшие доступные SaaS для control plane. Назвать это вслух — и есть смысл: «суверенность» мало что значит, если исключения не лежат на столе рядом с достижениями.
Шаги AI после встречи и план
Ни одна проприетарная US-резидентная модель не касается контента, полученного из встречи. Шаги с языковыми моделями, которые выполняются после звонка, — AI-дайджест (темы, решения, action items), итоги после встречи и AI-редактор заметок — все работают на EU-процессорах. Дайджест и генеративные действия редактора выполняются на EU-hosted Mistral с zero-data-retention (через AI Gateway от Vercel, привязанный к провайдеру Mistral). Итоги и действие перевести в редакторе выполняются на нашем собственном EU-движке на OVH — том же, что стоит за живым голосом и чатом. Голос, чат, заметки и документы в реальном времени с самого начала не приближались к универсальной LLM.
Единственная US-модель, которая ещё остаётся в цепочке, оценивает наш публичный бенчмарк перевода — она ставит оценки машинным переводам фиксированных эталонных предложений FLORES-200, а не чьим-либо встречам.
Мы идём дальше и по шагам на EU-Mistral: управляемый владельцем opt-out, чтобы полностью отключить дайджест, и self-hosted модель суммаризации с открытыми весами на OVH (класса Kimi), чтобы заменить внешний Mistral. Смысл маршрута с открытыми весами не в том, чья лаборатория обучала веса, — а в том, что открытые веса могут работать на инфраструктуре, которую мы контролируем, что удерживает этот шаг на той же оси «открытое и self-hostable», что и остальной data plane. Оба пункта есть в roadmap, но пока не выпущены; мы обновим эту статью, когда они появятся.
Почему это важно за пределами нас
Это не инженерия ради инженерии. Причина строить стек именно так проявляется на вашей стороне контракта:
- Аудируемое. SDK, на котором работает ваша встреча, — это open-source-код, который может прочитать ваша служба безопасности, а движок за ним — наш собственный, а не чёрный ящик третьей стороны.
- Переносимое. Открытые стандарты на каждом слое данных — Postgres, S3, OIDC — означают, что нет проприетарного vendor lock-in. То, что можно перенести, не привязано к одному вендору.
- Self-hostable. Слои данных на открытых стандартах — Postgres, S3, OIDC — уже работают на инфраструктуре, которую вы контролируете; полностью self-hosted движок перевода есть в roadmap для тенанта, которому он нужен.
Это картина на 2026-06-07. Мы обновим её, когда стек изменится — смена вендора, перестройка слоя, замена модели дайджеста. Текущая конфигурация проверяема в нашем открытом vercel.json, нашем nuxt.config.ts и репозитории mind-sdk под BSD-3-Clause, указанном выше.
Если какой-то слой здесь выглядит неверно или вашему review безопасности нужен ответ, которого эта карта не даёт, напишите нам. Мы лучше поправим недостающую деталь, чем дадим вам найти её в ходе аудита кода.