Soberanía

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

Un complemento a nuestro mapa de ejecución: no dónde se ejecuta su reunión, sino de qué está construida. La pila capa por capa — dónde ejecutamos nuestro propio código o software de código abierto, dónde somos pragmáticos con el SaaS propietario, y por qué el motor por el que fluye la mayor parte de sus datos es nuestro propio código, con un SDK de cliente público y con licencia BSD.

The Mind.com Team

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

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

Casi todos los productos se construyen con la misma pila predeterminada: los grandes valores predeterminados de SaaS propietario que todos eligen. Son el camino sin fricción. En cada capa donde realmente residen los datos de su reunión, tomamos uno diferente: nuestro propio código o código abierto que podíamos autoalojar.

Este es el complemento de Dónde se ejecuta realmente una reunión de InterMIND, que mapeó la geografía: dónde se ejecuta cada servicio y qué datos pasan por él. Esta publicación responde lo que un equipo de seguridad pregunta a continuación: ¿de qué está construida esta cosa y podemos leerla, auditarla y reemplazarla?

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


Los valores predeterminados y su coste

Cada producto es una pila de decisiones. Para la mayoría de los productos, la mayoría de esas decisiones se toman por defecto: Google Analytics, Firebase, la Google Translate API, Auth0, React. Son el camino sin fricción, y para la mayoría de los equipos es una decisión razonable. El inconveniente es que cada una pone una parte de su pila detrás de un proveedor que no puede leer, no puede auditar y no puede abandonar sin una reescritura.

Tomamos una decisión diferente en cada capa donde realmente residen los datos de su reunión: nuestro propio código o software de código abierto que podíamos autoalojar. Donde una capa no toca el contenido de su reunión, nos mantenemos pragmáticos y lo decimos. Aquí está el panorama completo.


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

Comience por la capa que más importa, porque la mayor parte de su reunión fluye por ella. El transporte en tiempo real y la traducción de voz/chat se ejecutan en mind-sdk + la Mind API — nuestro propio motor, en OVH France. La forma predeterminada de crear una reunión traducida es atornillar un SaaS en tiempo real (LiveKit) a una API de traducción (DeepL, Google); nosotros no ejecutamos ninguno en la ruta en vivo. Ningún modelo de traducción de terceros está en el ciclo. (Usamos DeepL, pero solo para documentos enviados al chat, no en la ruta de voz/chat en vivo; consulte el mapa de ejecución. Cubrimos la mecánica de la canalización en Dentro de los cuatro pipelines de traducción.)

Aquí está la parte que no está en el mapa de ejecución: el SDK en el que se ejecuta su reunión es de 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 PI estonia. Se comunica con la Mind API en api.mind.com, que nosotros mismos ejecutamos en OVH France.

Esto no es un arreglo de "mira, pero no toques" con código disponible. BSD 3-Clause es una licencia permisiva aprobada por OSI. Su equipo de seguridad puede clonar el SDK, leer exactamente cómo se capturan, encuadran y transmiten su audio y texto, y auditar esa integración con sus propios requisitos. El motor del lado del servidor con el que se comunica es nuestro, no una caja negra de un tercero, y un motor totalmente autoalojable para un inquilino que lo necesite está en nuestra hoja de ruta, no es algo que ofrezcamos hoy. Actualizaremos esta publicación en el momento en que se lance.


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

CapaEl valor predeterminado habitualLo que ejecutamosPor qué es importante para usted
Motor en tiempo real + de traducción (voz + chat)LiveKit + una API de traducción (DeepL / Google)mind-sdk (cliente BSD-3-Clause) + nuestra Mind API, OVH FranceEl flujo de datos más pesado es nuestro propio motor, no un modelo de un tercero, y su SDK de cliente es abierto y auditable
Framework frontendReact (Meta) / Next.jsVue + NuxtOSS gobernado por la comunidad: ninguna corporación única es dueña del framework en el que se ejecuta su UI
Análisis de productoGoogle AnalyticsPostHogCódigo abierto, nube europea, proxy de primera parte a través de nuestro propio dominio: los datos de uso no fluyen hacia una plataforma de publicidad de terceros
FuentesGoogle Fonts CDNAutoalojado (@nuxt/fonts)Ninguna llamada a fuentes de terceros desde la página que cargan sus usuarios: un hallazgo recurrente de GDPR, evitado
AutenticaciónAuth0 / Clerk / Firebase AuthOIDC propio, federado a su Google / Microsoftningún intermediario de autenticación retiene sus sesiones: usted aporta su propio proveedor de identidad
Traducción de documentosGoogle TranslateDeepL (Cologne)Proveedor europeo especializado, procesamiento alemán
Contenido / documentaciónContentful / Sanity (CMS headless)Nuxt Content (markdown rastreado por git)Las palabras en nuestro sitio viven en nuestro repositorio, no en la base de datos de un proveedor
Base de datos de la aplicaciónFirestore / DynamoDB (propietario)Postgres (en Neon)Estándar abierto: portable a cualquier host de Postgres, sin API de consulta propietaria que reescribir
Almacenamiento de objetosAPIs de blobs propietariasTigris (compatible con S3)Protocolo abierto: las grabaciones y exportaciones son portables a cualquier almacén S3
CRM / ventasSalesforce / HubSpotPipedrive (estonio)Los registros de clientes y ofertas residen en un CRM con sede en la UE, no en una plataforma de ventas estadounidense

Dos hilos atraviesan esa tabla. Código abierto donde la herramienta procesa sus datos, para que pueda ser auditable y, en principio, autoalojado. Estándares abiertos (Postgres, la API S3, OIDC) donde dependemos de la infraestructura, para que nada esté bloqueado por 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 sitúa en un tercer eje: el CRM que contiene los registros de clientes tiene sede en la UE (Pipedrive, estonio) en lugar de una plataforma de ventas estadounidense; no es de código abierto, pero tampoco está bajo la jurisdicción de EE. UU.

Un par de ellas merecen una frase más. PostHog es de código abierto y autoalojable; lo ejecutamos en la nube europea de PostHog y lo pasamos por un proxy de primera parte a través de nuestro propio origen, por lo que los eventos no son descartados silenciosamente por los bloqueadores de anuncios y no transitan por un dominio de análisis de terceros. La autenticación nunca va a un SaaS de autenticación de terceros que se sentaría entre usted y sus sesiones; nosotros ejecutamos el flujo OIDC y federamos a su identidad existente de Google o Microsoft. Y las fuentes en cada página se sirven desde nuestro propio dominio; el único lugar donde Google Fonts aparece en nuestro código base es en un script de recursos de marca sin conexión, nunca en la aplicación que cargan sus usuarios.


Donde somos pragmáticos — dicho en voz alta

No pretendemos que toda la pila esté hecha a mano o sea no estadounidense. No lo está, y una publicación que afirmara lo contrario sería contradicha por nuestro propio mapa de ejecución.

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

Es un compromiso deliberado y acotado: ser propietarios y de código abierto del plano de datos; utilizar 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 éxitos.


Los pasos de IA posteriores a la reunión y el plan

Ningún modelo propietario con sede en EE. UU. toca el contenido derivado de la reunión. Los pasos del modelo de lenguaje que se ejecutan después de la llamada — el AI digest (temas, decisiones, elementos de acción), el resumen posterior a la reunión y el AI note-editor — se encuentran todos en procesadores europeos. El resumen y las acciones generativas del editor se ejecutan en Mistral alojado en la UE con cero retención de datos (alcanzado a través del AI Gateway de Vercel, fijado al proveedor de Mistral). El resumen y la acción de traducción del editor se ejecutan en nuestro propio motor europeo en OVH — el mismo que está detrás de la voz y el chat en vivo. La voz en tiempo real, el chat, las notas y los documentos nunca se acercaron a un LLM de propósito general en primer lugar.

El único modelo estadounidense que sigue en el ciclo evalúa nuestro benchmark de traducción público — puntuando traducciones automáticas de frases de referencia fijas de FLORES-200, nunca la reunión de nadie.

Seguiremos avanzando en los pasos de la UE-Mistral: un opt-out controlado por el propietario para desactivar el resumen por completo, y un modelo de resumen de pesos abiertos autoalojado en OVH (clase Kimi) para reemplazar el Mistral externo. El objetivo de la ruta de pesos abiertos no es de qué laboratorio se entrenaron los pesos, sino que los pesos abiertos pueden ejecutarse en 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 están lanzados; actualizaremos esta publicación cuando estén listos.


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 muestra en su lado del contrato:

  1. Auditable. El SDK en el que se ejecuta su reunión es código abierto que su equipo de seguridad puede leer, y el motor que está detrás es nuestro, no una caja negra de un tercero.
  2. Portable. Los estándares abiertos en cada capa de datos — Postgres, S3, OIDC — significan que no hay bloqueo propietario. Lo que se puede mover no está ligado a un único proveedor.
  3. Autoalojable. Las capas de datos de estándares abiertos — Postgres, S3, OIDC — ya se ejecutan en infraestructura que usted controla; un motor de traducción totalmente autoalojable está en la hoja de ruta para el inquilino que lo necesite.

Este es el panorama a 2026-06-07. Lo actualizaremos cuando la pila cambie — un cambio de proveedor, una capa reconstruida, el modelo de resumen reemplazado. 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 anteriormente.

Si una capa aquí parece incorrecta, o su revisión de seguridad necesita una respuesta que este mapa no proporciona, escríbanos. Preferimos corregir un detalle faltante antes de que lo encuentre en una auditoría de código.


Fuentes: el repositorio mind-sdk (BSD-3-Clause), FLORES-200; hechos de la pila verificados contra la configuración desplegada (vercel.json, nuxt.config.ts) y el código enviado, comprobado en agosto de 2026.

Reciba nuevos artículos y actualizaciones del producto por correo electrónico

Un correo al mes con nuevas publicaciones y actualizaciones del producto. Cancela la suscripción en cualquier momento.