От какво е изградена една среща в InterMIND

Почти всеки продукт е изграден от един и същ стандартен стек: големите проприетарни SaaS решения, към които всички посягат по подразбиране. Те са пътят без триене. На всеки слой, където реално живеят данните от вашите срещи, ние избрахме друг път: наш собствен код или отворен код, който можем да хостваме сами.

Този текст е продължение на Къде всъщност работи една среща в InterMIND, който очерта географията: къде се изпълнява всяка услуга и какви данни минават през нея. Тук отговаряме на следващия въпрос на екипите по сигурност: от какво е изградено това нещо и можем ли да го прочетем, да го одитираме и да го заменим?

Не къде работи, а от какво е направено, слой по слой.

Стандартните избори и какво струват

Всеки продукт е съвкупност от избори. При повечето продукти повечето от тези избори се правят по подразбиране: Google Analytics, Firebase, Google Translate API, Auth0, React. Това е пътят без триене и за повечето екипи е разумно решение. Цената е, че всеки такъв избор поставя част от вашия стек зад доставчик, чийто код не можете да прочетете, не можете да одитирате и от когото не можете да се откажете без пренаписване.

Ние направихме различен избор на всеки слой, където живеят данните от вашите срещи: наш собствен код или софтуер с отворен код, който можем да хостваме сами. Където даден слой не докосва съдържанието на вашата среща, оставаме прагматични и го казваме. Ето цялата картина.

Гръбнакът: машината е наш код, а не на трета страна

Започваме със слоя, който е най-важен, защото през него минава по-голямата част от срещата ви. Транспортът в реално време и преводът на глас и чат работят върху mind-sdk + Mind API: наша собствена машина, на OVH във Франция. Обичайният начин да се изгради преведена среща е да се закачи SaaS за реално време (LiveKit) към API за превод (DeepL, Google); ние не използваме нито едното в живия път. В цикъла няма езиков модел за превод на трета страна. (Използваме DeepL, но само за документи, пуснати в чата, не и за живия път на гласа и чата; вижте картата на изпълнението. Механиката на конвейера сме разгледали в Вътре в четирите конвейера за превод.)

Ето онова, което го няма в картата на изпълнението: SDK, върху който работи вашата среща, е с отворен код под лиценза BSD 3-Clause. Клиентът mind-sdk е публичен на gitlab.com/mindlabs/api/sdk, с авторско право на MindMeeting OÜ, нашето естонско дружество за интелектуална собственост. Той комуникира с Mind API на api.mind.com, който ние самите управляваме на OVH във Франция.

Това не е уговорка от типа „гледай, но не пипай“ с достъпен, но ограничен код. BSD 3-Clause е разрешителен лиценз, одобрен от OSI. Екипът ви по сигурност може да клонира SDK, да прочете точно как се улавят, рамкират и стриймват вашето аудио и текст и да одитира тази интеграция спрямо собствените си изисквания. Сървърната машина, с която комуникира, е наша, не е черна кутия на трета страна. Напълно самостоятелно хостваема машина за клиент, който има нужда от такава, е в нашата пътна карта, но не е нещо, което предлагаме днес. Ще обновим този текст в момента, в който излезе.

Слой по слой: стандартното решение срещу това, което използваме

През тази таблица минават две нишки. Отворен код там, където инструментът обработва вашите данни, за да може да бъде одитиран и по принцип хостван самостоятелно. Отворени стандарти (Postgres, S3 API, OIDC) там, където зависим от инфраструктура, за да не сме обвързани с ценовата политика или с позицията по съответствие на един доставчик. Postgres може да се премести на всеки Postgres хост; хранилището може да се премести на всяко S3 хранилище; автентикацията се федерира към идентификационния доставчик, който вече използвате. Последният ред е на трета ос: CRM, което държи записите за клиенти, е със седалище в ЕС (Pipedrive, естонски), а не американска платформа за продажби. Не е с отворен код, но не е и под юрисдикцията на САЩ.

Някои от тези избори заслужават още едно изречение. PostHog е с отворен код и може да се хоства самостоятелно; ние го ползваме на EU cloud на PostHog и го проксираме като first-party през собствения ни origin, така че събитията да не се губят тихомълком от ad-blocker-и и да не минават през външен аналитичен домейн. Автентикацията никога не отива към външен SaaS за автентикация, който да стои между вас и вашите сесии: ние управляваме OIDC потока сами и го федерираме към съществуващата ви идентичност в Google или Microsoft. А шрифтовете на всяка страница се сервират от нашия собствен домейн; единственото място в кодовата ни база, където се появява Google Fonts, е офлайн скрипт за брандови ресурси, никога приложението, което зареждат потребителите ви.

Където сме прагматични: казано открито

Не се преструваме, че целият стек е писан на ръка или че не е американски. Не е, а текст, който твърди обратното, би бил опроверган от нашата собствена карта на изпълнението.

Спомагателната инфраструктура — хостингът и SSR (Vercel), изчислителната мощ на сървъра за срещи (Fly.io), плащанията (Stripe), транзакционните имейли (Resend) — работи върху SaaS със седалище в САЩ. Stripe и Resend обработват фактурирането и поканите и никога не виждат съдържанието на срещите. Vercel и Fly са наета изчислителна мощ: нашият собствен код работи върху тях, а сървърът за срещи във Fly действително обслужва живата сесия и транскрипта, който чете нашето резюме. Но това е наш код на техни машини, а не продукт на доставчик, който поглъща вашата среща. Всичко се изпълнява в ЕС по време на работа (темата на картата на изпълнението).

Това е съзнателен и ограничен компромис: притежаваме и държим в отворен код равнината на данните, а за равнината на управлението използваме най-добрия наличен SaaS. Назоваването му е смисълът: „суверенитет“ означава малко, ако изключенията не са на масата до постиженията.

AI стъпките и планът, който реално излезе

Стъпките с езикови модели — AI digest (теми, решения, action items), обобщенията на документи, генеративните действия на AI редактора за бележки, Ask AI и Mia — работят върху AI шлюза, който вашата организация избира: по подразбиране Azure OpenAI в EU Data Zone, по избор Vertex AI на многорегионалния endpoint в ЕС или Amazon Bedrock във Франкфурт, всеки в наш собствен tenant, с нулево задържане на данни и без обучение върху съдържанието на клиентите — или собствен OpenAI-съвместим endpoint, който държи модела върху инфраструктура, която контролирате. Резюмето след срещата и действието за превод в редактора минават през преводния тракт, а не през езиковия модел. Гласът, чатът, бележките и документите в реално време никога не са минавали през езиков модел с обща цел.

Това е честният облик на този слой: моделите са проприетарни, а доставчиците им са американски компании, които управляват региони в ЕС. Същият компромис като при спомагателната инфраструктура по-горе, посочен до нея, а не скрит. Вместо наш собствен самостоятелно хостван модел излезе изборът: организацията може изцяло да изключи AI (транскрипцията и преводът продължават да работят) и може да насочи всяка AI функция към свой собствен endpoint — vLLM в свой център за данни, внедряване в свой tenant — което поставя този слой на същата ос на отворено и самостоятелно хоствано като останалата част от равнината на данните. Нашият публичен бенчмарк за превод се оценява от LLM съдия (Gemini, с Claude като резервен) върху фиксирани референтни изречения от FLORES-200, никога върху нечия среща.

Защо това има значение отвъд нас

Това не е инженерство заради самото инженерство. Причината да се изгради стек по този начин проличава от вашата страна на договора:

1. Одитируемост. SDK, върху който работи вашата среща, е код с отворен код, който екипът ви по сигурност може да прочете, а машината зад него е наша собствена, не е черна кутия на трета страна.
2. Преносимост. Отворени стандарти на всеки слой с данни — Postgres, S3, OIDC — означават липса на проприетарна обвързаност. Каквото може да се премести, не е вързано за един доставчик.
3. Самостоятелно хостване. Слоевете с данни на отворени стандарти — Postgres, S3, OIDC — вече работят върху инфраструктура, която контролирате; напълно самостоятелно хостваната машина за превод е в пътната карта за клиента, който има нужда от нея.

Това е картината към 2026-06-07. Ще я обновим, когато стекът се промени — смяна на доставчик, преизграден слой, заменен модел за digest. Текущата конфигурация е проверима в нашия отворен vercel.json, в nuxt.config.ts и в хранилището mind-sdk под BSD-3-Clause, към което има връзка по-горе.

Ако някой слой тук изглежда погрешен или прегледът ви по сигурност се нуждае от отговор, който тази карта не дава, пишете ни. Предпочитаме да поправим липсваща подробност, отколкото да я откриете при одит на кода.

Източници: хранилището mind-sdk (BSD-3-Clause), FLORES-200; фактите за стека са проверени спрямо внедрената конфигурация (vercel.json, nuxt.config.ts) и пуснатия код, проверка от август 2026.