De qué está construida una reunión de InterMIND
Casi todos los productos se construyen sobre la misma pila por defecto — los grandes valores predeterminados de SaaS propietario a los que todos recurren. Son el camino sin fricción. En cada capa donde realmente residen los datos de su reunión, nosotros tomamos otra dirección: nuestro propio código, o código abierto que pudiéramos autoalojar.
Este es el complemento a 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. Esta publicación responde a la siguiente pregunta de un equipo de seguridad: ¿de qué está hecha esta cosa — y podemos leerla, auditarla y reemplazarla?
No dónde se ejecuta — de qué está hecha, capa por capa.
Los valores predeterminados, y lo que cuestan
Cada producto es una pila de decisiones. Para la mayoría de los productos, casi todas esas decisiones 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 es una elección razonable. La contrapartida es que cada una pone una parte de su pila detrás de un proveedor que no puede leer, no puede auditar y del que no puede salir sin reescribir todo.
Tomamos una decisión distinta en cada capa donde realmente residen los datos de su reunión: nuestro propio código, o software de código abierto que pudiéramos autoalojar. Cuando una capa no toca el contenido de su reunión, somos pragmáticos y lo decimos. Aquí está el panorama completo.
La columna vertebral: el motor es nuestro código, no el de un tercero
Empecemos por la capa que más importa, porque la mayor parte de su reunión fluye a través de ella. El transporte en tiempo real y la traducción de voz/chat se ejecutan ambos sobre mind-sdk + la API de Mind — 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 está en el bucle. (Sí usamos DeepL — pero solo para documentos compartidos en el chat, no en la ruta de voz/chat en vivo; consulte el mapa de runtime. Cubrimos la mecánica del pipeline en Dentro de los cuatro pipelines de traducción.)
Esta es la parte que no está en el mapa de runtime: el SDK sobre el que se ejecuta su reunión es código abierto bajo la licencia BSD 3-Clause — el cliente mind-sdk es público en gitlab.com/mindlabs/api/sdk, copyright MindMeeting OÜ, nuestra entidad de propiedad intelectual estonia. Se comunica con la API de Mind en api.mind.com, que ejecutamos nosotros mismos en OVH Francia.
No se trata de un acuerdo de "mirar, pero no tocar" con código a la vista. 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, encuadra y transmite su audio y texto, y auditar esa integración frente a sus propios requisitos. El motor del lado del servidor con el que habla es nuestro — no la caja negra de un tercero — y un motor completamente autoalojable para un cliente que lo necesite está en nuestra hoja de ruta, no es algo que ofrezcamos hoy. Actualizaremos esta publicación en cuanto se lance.
Capa por capa: el predeterminado frente a lo que ejecutamos
| Capa | El predeterminado habitual | Lo que ejecutamos | Por qué le importa a usted |
|---|---|---|---|
| Motor en tiempo real + traducción (voz + chat) | LiveKit + una API de traducción (DeepL / Google) | mind-sdk (cliente BSD-3-Clause) + nuestra API de Mind, OVH Francia | El flujo de datos más pesado es nuestro propio motor, no un modelo de terceros — y su SDK de cliente es abierto y auditable |
| Framework de frontend | React (Meta) / Next.js | Vue + Nuxt | OSS gobernado por la comunidad — ninguna corporación es dueña del framework sobre el que viaja su UI |
| Analítica de producto | Google Analytics | PostHog | Código abierto, nube de la UE, proxy first-party a través de nuestro propio dominio — los datos de uso no fluyen a una plataforma publicitaria de terceros |
| Fuentes | CDN de Google Fonts | Autoalojadas (@nuxt/fonts) | Ninguna llamada a fuentes de terceros desde la página que cargan sus usuarios — un hallazgo recurrente de GDPR, evitado |
| Autenticación | Auth0 / Clerk / Firebase Auth | OIDC autogestionado, federado a su Google / Microsoft | Ningún intermediario de autenticación retiene sus sesiones — usted aporta su propio proveedor de identidad |
| Traducción de documentos | Google Translate | DeepL (Colonia) | Proveedor especializado de la UE, procesamiento alemán |
| Contenido / documentación | Contentful / Sanity (CMS headless) | Nuxt Content (markdown versionado en git) | Las palabras de nuestro sitio viven en nuestro repositorio, no en la base de datos de un proveedor |
| Base de datos de la aplicación | Firestore / DynamoDB (propietarias) | Postgres (en Neon) | Estándar abierto — portable a cualquier host de Postgres, sin API de consulta propietaria que reescribir |
| Almacenamiento de objetos | APIs de blob propietarias | Tigris (compatible con S3) | Protocolo abierto — las grabaciones y exportaciones son portables a cualquier almacén S3 |
| CRM / ventas | Salesforce / HubSpot | Pipedrive (estonio) | Los registros de clientes y operaciones se ubican en un CRM domiciliado en la UE, no en una plataforma de ventas estadounidense |
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 S3, OIDC) donde dependemos de la infraestructura — para que nada quede atado a los precios o la postura de cumplimiento de un único proveedor. Postgres puede moverse a cualquier host de Postgres; el almacenamiento puede moverse a cualquier almacén S3; la autenticación se federa al proveedor de identidad que ya ejecuta. La última fila se apoya en un tercer eje: el CRM que guarda los registros de clientes está domiciliado en la UE (Pipedrive, estonio) en lugar de en una plataforma de ventas estadounidense — no es código abierto, pero tampoco está bajo jurisdicción estadounidense.
Un par de estos merecen una frase más. PostHog es de código abierto y autoalojable; nosotros lo ejecutamos en la nube europea de PostHog y lo servimos vía proxy first-party a través de nuestro propio origen, de modo que los eventos no son descartados silenciosamente por los bloqueadores de anuncios y no transitan por un dominio de analítica de terceros. La autenticación nunca pasa por un SaaS de autenticación de terceros que se interpondría entre usted y sus sesiones — ejecutamos el flujo OIDC nosotros mismos y lo federamos a su identidad existente de Google o Microsoft. Y las fuentes de cada página se sirven desde nuestro propio dominio; el único lugar en el que Google Fonts aparece en nuestro código base es un script offline de activos de marca, nunca en la aplicación que cargan sus usuarios.
Dónde somos pragmáticos — dicho en voz alta
No fingimos que toda la pila esté hecha a mano o no sea estadounidense. No lo está, y una publicación que afirmara lo contrario sería contradicha por nuestro propio mapa de runtime.
La fontanería — hosting y SSR (Vercel), el cómputo del servidor de reuniones (Fly.io), pagos (Stripe), correo transaccional (Resend) — se ejecuta sobre SaaS domiciliado en EE. UU. Stripe y Resend gestionan facturación e invitaciones y nunca ven el contenido de las reuniones. Vercel y Fly son cómputo alquilado: nuestro propio código se ejecuta sobre ellos, y el servidor de reuniones en Fly sí maneja la sesión en vivo y la transcripción que lee nuestro digest — pero es nuestro código sobre sus máquinas, no un producto de proveedor que ingiera su reunión. Todo se ejecuta en la UE en tiempo de ejecución (el tema de el mapa de runtime).
Es una contrapartida deliberada y acotada: poseer y abrir el plano de datos; usar el mejor SaaS disponible para el plano de control. Nombrarlo es el punto — la "soberanía" significa poco si las excepciones no están sobre la mesa junto a los logros.
Los pasos de IA posteriores a la reunión, y el plan
Ningún modelo propietario domiciliado en EE. UU. toca el contenido derivado de las reuniones. Los pasos del modelo de lenguaje que se ejecutan después de la llamada — el digest de IA (temas, decisiones, elementos de acción), el resumen posterior a la reunión y el editor de notas con IA — todos se apoyan en procesadores de la UE. El digest y las acciones generativas del editor se ejecutan sobre Mistral alojado en la UE con retención cero de datos (accedido a través de AI Gateway de Vercel, fijado al proveedor Mistral). El resumen y la acción traducir del editor se ejecutan sobre nuestro propio motor en la UE en OVH — el mismo que está detrás de la voz y el chat en vivo. La voz, el chat, las notas y los documentos en tiempo real nunca pasaron por un LLM de propósito general, para empezar.
El único modelo estadounidense que sigue en el bucle es el que evalúa nuestro benchmark de traducción público — puntuando traducciones automáticas de oraciones de referencia fijas de FLORES-200, nunca la reunión de nadie.
Vamos aún más allá en los pasos sobre Mistral-UE: una exclusión controlada por el propietario para desactivar el digest por completo, y un modelo de resumen autoalojado y de pesos abiertos en OVH (clase Kimi) para reemplazar al Mistral externo. La razón de la vía de pesos abiertos no es qué laboratorio entrenó los pesos — es que los pesos abiertos pueden ejecutarse sobre infraestructura que controlamos, lo que lo mantiene en el mismo eje abierto-y-autoalojable que el resto del plano de datos. Ambos están en la hoja de ruta, no entregados; actualizaremos esta publicación cuando lleguen.
Por qué esto importa más allá de nosotros
Esto no es ingeniería por sí misma. La razón para construir una pila de esta manera se manifiesta de su lado del contrato:
- Auditable. El SDK sobre el que se ejecuta su reunión es código abierto que su equipo de seguridad puede leer, y el motor detrás de él es nuestro — no la caja negra de un tercero.
- Portable. Estándares abiertos en cada capa de datos — Postgres, S3, OIDC — significan que no hay bloqueo propietario. Lo que se puede mover no está atado a un único proveedor.
- Autoalojable. Las capas de datos basadas en estándares abiertos — Postgres, S3, OIDC — ya se ejecutan sobre infraestructura que usted controla; un motor de traducción totalmente autoalojado está en la hoja de ruta para el cliente que lo necesite.
Esta es la foto al 2026-06-07. La actualizaremos cuando cambie la pila — un cambio de proveedor, una capa reconstruida, el modelo del digest sustituido. La configuración actual es verificable en nuestro vercel.json abierto, nuestro nuxt.config.ts y el repositorio mind-sdk con licencia BSD-3-Clause enlazado más arriba.
Si alguna capa aquí parece equivocada, o su revisión de seguridad necesita una respuesta que este mapa no proporciona, escríbanos. Preferimos corregir un detalle que falte a que usted lo encuentre en una auditoría de código.