De qué está hecha una reunión de InterMIND

Casi todos los productos se construyen con el mismo stack por defecto: el de los grandes SaaS propietarios a los que todo el mundo recurre. Es el camino sin fricción. En cada capa donde viven realmente los datos de su reunión, nosotros tomamos otro: código propio, o código abierto que podamos alojar nosotros mismos.

Este artículo es el complemento de Dónde se ejecuta realmente una reunión de InterMIND, que trazó la geografía: dónde se ejecuta cada servicio y qué datos pasan por él. Aquí respondemos a lo que pregunta a continuación un equipo de seguridad: ¿de qué está hecho esto, y podemos leerlo, auditarlo y reemplazarlo?

No dónde se ejecuta, sino de qué está hecho, capa por capa.

Los valores por defecto y lo que cuestan

Todo producto es un conjunto de decisiones. En la mayoría de los productos, casi todas se toman por defecto: Google Analytics, Firebase, la API de Google Translate, Auth0, React. Son el camino sin fricción y, para la mayoría de los equipos, una decisión razonable. La contrapartida es que cada una deja una parte de su stack detrás de un proveedor al que no puede leer, no puede auditar y del que no puede salir sin reescribir.

Nosotros tomamos una decisión distinta en cada capa donde viven realmente los datos de su reunión: código propio, o software de código abierto que podamos alojar nosotros mismos. Donde una capa no toca el contenido de su reunión, somos pragmáticos y lo decimos. Este es el panorama completo.

La columna vertebral: el motor es código nuestro, no de un tercero

Empecemos por la capa que más importa, porque la mayor parte de su reunión pasa por ella. El transporte en tiempo real y la traducción de voz y chat se ejecutan sobre mind-sdk + la Mind API: nuestro propio motor, en OVH Francia. La forma habitual de construir una reunión traducida es acoplar un SaaS en tiempo real (LiveKit) a una API de traducción (DeepL, Google); nosotros no ejecutamos ninguno de los dos en la ruta en vivo. Ningún modelo de traducción de terceros interviene. (Sí usamos DeepL, pero solo para los documentos que se suben al chat, no para la ruta de voz y chat en vivo; véase el mapa de ejecución. Explicamos la mecánica en Por dentro de los cuatro pipelines de traducción.)

Y esto es lo que no aparece en el mapa de ejecución: el SDK sobre el que corre su reunión es de código abierto con licencia BSD 3-Clause. El cliente mind-sdk es público en gitlab.com/mindlabs/api/sdk, con copyright de MindMeeting OÜ, nuestra entidad estonia titular de la propiedad intelectual. Se comunica con la Mind API en api.mind.com, que operamos nosotros mismos en OVH Francia.

No es un esquema de código visible de «se mira, pero no se toca». BSD 3-Clause es una licencia permisiva aprobada por la OSI. Su equipo de seguridad puede clonar el SDK, leer exactamente cómo se captura, se empaqueta y se transmite su audio y su texto, y auditar esa integración conforme a sus propios requisitos. El motor del lado del servidor con el que se comunica es nuestro, no la caja negra de un tercero. Un motor totalmente autoalojable para el cliente que lo necesite está en nuestra hoja de ruta, pero hoy no lo ofrecemos. Actualizaremos este artículo en cuanto esté disponible.

Capa por capa: el valor por defecto frente a lo que ejecutamos

Dos hilos recorren esa tabla. Código abierto donde la herramienta procesa sus datos, para que pueda auditarse y, en principio, autoalojarse. Estándares abiertos (Postgres, la API de S3, OIDC) donde dependemos de infraestructura, para que nada quede atado a los precios o a la postura de cumplimiento de un solo proveedor. Postgres puede trasladarse a cualquier host de Postgres; el almacenamiento, a cualquier almacén S3; la autenticación se federa con el proveedor de identidad que usted ya gestiona. La última fila responde a un tercer eje: el CRM que guarda los registros de clientes tiene domicilio en la UE (Pipedrive, estonio) en lugar de ser una plataforma de ventas estadounidense; no es de código abierto, pero tampoco está bajo jurisdicción de EE. UU.

Algunas de estas merecen una frase más. PostHog es de código abierto y autoalojable; nosotros lo ejecutamos en la nube europea de PostHog y le aplicamos un proxy de origen propio a través de nuestro dominio, de modo que los bloqueadores de anuncios no descartan los eventos en silencio y tampoco transitan por un dominio de analítica de terceros. La autenticación nunca pasa por un SaaS de terceros que se interponga entre usted y sus sesiones: ejecutamos el flujo OIDC nosotros mismos y lo federamos con su identidad actual de Google o Microsoft. Y las fuentes de cada página se sirven desde nuestro propio dominio; el único lugar donde aparece Google Fonts en nuestro código es un script sin conexión para recursos de marca, nunca la aplicación que cargan sus usuarios.

Dónde somos pragmáticos: lo decimos en voz alta

No fingimos que todo el stack sea de factura propia o no estadounidense. No lo es, y un artículo que afirmara lo contrario quedaría desmentido por nuestro propio mapa de ejecución.

La infraestructura auxiliar (alojamiento y SSR con Vercel, la capacidad de cómputo del servidor de reuniones con Fly.io, los pagos con Stripe, el correo transaccional con Resend) se apoya en SaaS con domicilio en EE. UU. Stripe y Resend gestionan la facturación y las invitaciones y nunca ven el contenido de las reuniones. Vercel y Fly son cómputo alquilado: nuestro propio código se ejecuta en ellos, y el servidor de reuniones en Fly sí gestiona la sesión en vivo y la transcripción que lee nuestro resumen, pero es nuestro código en sus máquinas, no un producto del proveedor que ingiera su reunión. Todo se ejecuta en la UE en tiempo de ejecución (el tema de el mapa de ejecución).

Es una contrapartida deliberada y acotada: código propio y abierto en el plano de datos; el mejor SaaS disponible en el plano de control. Nombrarlo es el objetivo: la «soberanía» significa poco si las excepciones no están sobre la mesa junto a los logros.

Los pasos de IA y el plan que se implantó

Los pasos con modelos de lenguaje (el resumen de IA con temas, decisiones y action items, los resúmenes de documentos, las acciones generativas del editor de notas con IA, Ask AI y Mia) se ejecutan en la pasarela de IA que selecciona su organización: Azure OpenAI en la EU Data Zone por defecto, Vertex AI en el endpoint multirregión de la UE o Amazon Bedrock en Fráncfort si se prefiere, cada uno en nuestro propio tenant, con retención cero de datos y sin entrenamiento con el contenido de los clientes; o su propio endpoint compatible con OpenAI, que mantiene el modelo en una infraestructura que usted controla. El resumen posterior a la reunión y la acción traducir del editor pasan por el circuito de traducción, no por el modelo de lenguaje. La voz, el chat, las notas y los documentos en tiempo real nunca pasaron cerca de un LLM de propósito general.

Esa es la forma honesta de esta capa: los modelos son propietarios y sus proveedores son empresas estadounidenses que operan regiones en la UE, la misma contrapartida que en la infraestructura auxiliar, expuesta junto a ella en lugar de ocultarla. Lo que se implantó en lugar de un modelo propio autoalojado es la posibilidad de elegir: una organización puede desactivar la IA por completo (la transcripción y la traducción siguen funcionando) y puede dirigir cada función de IA a su propio endpoint (vLLM en su propio centro de datos, un despliegue en su propio tenant), lo que sitúa esta capa en el mismo eje de código abierto y autoalojable que el resto del plano de datos. Nuestro benchmark de traducción público lo puntúa un LLM como juez (Gemini, con Claude como alternativa) sobre frases de referencia fijas de FLORES-200, nunca sobre la reunión de nadie.

Por qué importa más allá de nosotros

No es ingeniería por la ingeniería. La razón para construir un stack así se ve en su lado del contrato:

1. Auditable. El SDK sobre el que corre su reunión es código abierto que su equipo de seguridad puede leer, y el motor que hay detrás es el nuestro, no la caja negra de un tercero.
2. Portable. Los estándares abiertos en cada capa de datos (Postgres, S3, OIDC) significan que no hay dependencia de un proveedor propietario. Lo que se puede trasladar no queda atado a un único proveedor.
3. Autoalojable. Las capas de datos de estándar abierto (Postgres, S3, OIDC) ya funcionan en infraestructura que usted controla; un motor de traducción totalmente autoalojado está en la hoja de ruta para el cliente que lo necesite.

Este es el panorama a 2026-06-07. Lo actualizaremos cuando el stack cambie: un proveedor sustituido, una capa reconstruida, el modelo del resumen reemplazado. La configuración actual es verificable en nuestro vercel.json abierto, en nuestro nuxt.config.ts y en el repositorio mind-sdk con licencia BSD-3-Clause enlazado más arriba.

Si una capa de este mapa le parece incorrecta, o su revisión de seguridad necesita una respuesta que este mapa no da, escríbanos. Preferimos corregir un detalle que falta antes que usted lo descubra en una auditoría de código.

Fuentes: el repositorio mind-sdk (BSD-3-Clause), FLORES-200; datos del stack verificados con la configuración desplegada (vercel.json, nuxt.config.ts) y el código en producción, comprobados en agosto de 2026.