Dónde se ejecuta realmente una reunión de InterMIND

Tarde o temprano, alguien del lado del anfitrión (el departamento de TI de un cliente, un DPO, un socio prudente) hace la misma pregunta: «¿Adónde van estos datos?». Quiere una lista de subencargados del tratamiento, el domicilio de los proveedores y un diagrama con flechas.

Preferimos que tenga el panorama completo antes que entregárselo por partes en sucesivos correos. Por eso, aquí está la ruta de datos de una reunión: cada servicio externo que interviene, dónde se ejecuta cada uno y qué datos pasan por él. Verificado con la configuración de despliegue real el 2026-05-28.

Todo recorrido que toca el contenido de la reunión se ejecuta en la UE: también los pasos de IA, que corren en la pasarela de IA que elija su organización, en una región de la UE de nuestro propio tenant. Los proveedores que están detrás de esa pasarela son empresas estadounidenses que operan regiones en la UE; lo decimos con claridad más abajo, y también indicamos qué modelo queda completamente fuera de la reunión.

Este artículo describe dónde se ejecuta su reunión. Su complemento, De qué está hecha una reunión de InterMIND, describe de qué está hecha: qué capas son código propio, cuáles son de código abierto y en qué casos somos pragmáticos con el SaaS propietario.

Qué significa realmente «dónde se ejecuta»

En las conversaciones sobre soberanía se mezclan dos cosas que no son lo mismo:

1. Ejecución / ruta de datos. Dónde se procesan físicamente los bytes de su reunión durante la solicitud. Es de lo que tratan las normativas de residencia de datos y la mayoría de los DPA.
2. Domicilio social del proveedor. Dónde está legalmente constituido el proveedor de SaaS. Es el eje de los debates sobre la CLOUD Act: el alcance teórico de un requerimiento estadounidense contra la matriz del proveedor, con independencia de dónde se ejecute la carga de trabajo.

Casi toda pregunta del tipo «¿esto es UE?» es, en realidad, una de estas dos, formulada con imprecisión. Más abajo respondemos a ambas por separado para cada proveedor.

La ruta de datos de una reunión

Sigamos una llamada desde que alguien se une hasta el correo de seguimiento:

1. El navegador abre la página de la reunión. El SSR se ejecuta en Vercel, fijado a fra1 (Fráncfort). Todos los datos de solicitud y respuesta (cookies de sesión, cargas de la API, HTML renderizado en servidor) se procesan en la UE en tiempo de ejecución.
2. El WebSocket se conecta a nuestro servidor de reuniones en París (cdg). Orquestación de la reunión, presencia, señalización: todo en la UE.
3. El reconocimiento de voz se ejecuta en nuestro servidor de medios. El audio llega por WebRTC a nuestro propio motor, la Mind API en OVH, Francia, y se reconoce allí, palabra por palabra, en el mismo servidor que transporta la llamada; ningún servicio de voz de terceros interviene. Las notas de voz del chat son la única excepción: su conversión de voz a texto se ejecuta en Azure AI Speech, el servicio de voz de la pasarela de IA predeterminada (tabla de proveedores más abajo). El pipeline completo se describe en Por dentro de los cuatro pipelines de traducción.
4. La traducción de voz y de chat llega a nuestro propio motor en OVH Francia. Se trata de mind-sdk + la Mind API: nuestro código, nuestros servidores, en Francia. Ningún modelo de terceros interviene. Se genera una traducción por cada idioma de destino presente en la sala, y en cada salto los datos permanecen en la UE.
5. Un documento enviado al chat (PDF, DOCX, DOC, PPTX, XLSX) va, desde el servidor ws de París y del lado del servidor, a DeepL en Colonia. Empresa alemana, procesamiento alemán. La voz y el chat no pasan por DeepL.
6. Los datos de la aplicación (usuarios, equipos, mensajes, metadatos de reuniones) residen en Neon Postgres sobre AWS Fráncfort (eu-central-1). Las instantáneas, en la misma región.
7. Las grabaciones, los archivos adjuntos y las exportaciones se almacenan en Tigris, almacenamiento compatible con S3 sobre Fly. Está replicado en el edge; el bucket se puede configurar como multirregión de la UE para los tenants que necesiten fijarlo con más precisión.
8. Los errores y las trazas de rendimiento van a la instancia de la UE de Sentry (de.sentry.io). La organización de EE. UU. se dio de baja en mayo.
9. La analítica de producto va a PostHog EU (eu.i.posthog.com).
10. El correo transaccional (enlaces mágicos, invitaciones, recibos) sale por Resend desde eu-west-1 (Irlanda).

Todo lo anterior se ejecuta en la UE. El motor de traducción, por el que pasa la mayor parte de sus datos, es además código propio, no de un tercero. El SDK de cliente sobre el que corre es de código abierto (BSD-3-Clause) y auditable hoy; el autoalojamiento del propio motor está en la hoja de ruta para quien lo necesite.

El mapa de proveedores

Los dos flujos de datos más voluminosos (la traducción de voz y chat a través de nuestro propio motor en OVH y la traducción de documentos a través de DeepL) coinciden además en ser los dos proveedores cuya entidad matriz está en la UE. Eso cubre la mayor parte del contenido de las reuniones. La lista completa de subencargados, con el detalle del domicilio social, se incorpora al DPA como práctica habitual; la tabla anterior es la vista de ejecución, que es de lo que tratan la mayoría de las cláusulas de residencia de datos.

Los pasos de IA, con nombre y apellidos

Cuando termina la llamada ejecutamos algunos pasos con modelos de lenguaje sobre lo que se dijo: el AI digest (temas, decisiones, action items, preguntas abiertas), el resumen posterior a la reunión y el editor de notas con IA (traducir una nota, o corregirla, ampliarla o simplificarla). Durante la llamada, el mismo tipo de paso redacta un resumen de cada documento enviado al chat y responde a Ask AI y a Mia. Son los únicos lugares donde un modelo de propósito general toca contenido derivado de la reunión, y todos van a un único destino:

• La pasarela de IA que elige su organización. Un único resolvedor en el código la selecciona para cada punto de llamada; no existe una segunda ruta. La predeterminada es Azure OpenAI en la EU Data Zone; desde su configuración, una organización puede cambiar a Vertex AI en el endpoint multirregión de la UE o a Amazon Bedrock en Fráncfort, o dirigir todas las funciones de IA a su propio endpoint compatible con OpenAI: vLLM en su propio centro de datos, un despliegue en su propio tenant. Cada pasarela alojada se ejecuta en nuestro propio tenant, configurada con retención cero de datos y sin entrenamiento con contenido de clientes; el respaldo permanece en la misma pasarela (una segunda región de la UE o un segundo modelo del mismo proveedor), nunca en otro proveedor. La documentación de funciones de IA enumera las pasarelas y las regiones.
• El resumen y la acción traducir del editor pasan por la vía de traducción, no por el modelo de lenguaje: la misma ruta que traduce el chat en vivo.
• La IA se puede desactivar para toda la organización: la transcripción y la traducción siguen funcionando; el digest, los resúmenes de documentos, el asistente de escritura y Ask AI se detienen.

La voz en tiempo real, el chat en tiempo real, las notas y la traducción de documentos no pasan nunca por ninguno de estos pasos: se ejecutaban en la UE desde el principio.

Dónde se sitúan los proveedores: Microsoft, Google y Amazon son empresas estadounidenses que operan regiones en la UE. Lo decimos con claridad en la página de confianza, sin ocultarlo: es la cuestión del domicilio social con la que abríamos este artículo, respondida para este salto igual que para la infraestructura de base. Hay un modelo que queda por completo fuera de la reunión: nuestro benchmark de calidad de traducción, público, usa un LLM como juez (Gemini, con Claude como respaldo, a través de la AI Gateway de Vercel) para puntuar traducciones automáticas de frases de referencia de FLORES-200. Es un conjunto de datos fijo y público, no la reunión de nadie.

Qué significa esto para su DPA

Para la mayoría de los compradores de la UE (el Mittelstand alemán, los sectores regulados que trabajan con DPA estándar bajo el GDPR), el panorama anterior responde directamente a la cuestión de la residencia de datos: cada salto que da su reunión en tiempo de ejecución está en la UE. El domicilio de los proveedores se declara en la lista de subencargados según la práctica habitual; no hay nada sorprendente ahí. El mapa de residencia es solo una pieza; para el resto de las obligaciones de protección de datos (supresión, conservación, portabilidad, consentimiento) sometimos el código a una auditoría completa y cerramos cada punto contra el código.

Para la souveraineté numérique francesa y las contrataciones de nivel SecNumCloud, el domicilio social del proveedor forma parte del criterio, no solo la ubicación en tiempo de ejecución. Es otra conversación: una topología de despliegue alternativa que mantiene cada componente bajo proveedores sujetos a jurisdicción europea. No la ejecutamos por defecto; la pondremos en marcha para un tenant que la necesite y cuando el contrato justifique la construcción.

Para los compradores de EE. UU. y de la mayor parte de APAC, lo habitual es lo contrario: quieren baja latencia desde su región, que es un problema distinto. Hoy operamos en una sola región, fra1. Si su tráfico justifica un edge en EE. UU., lo planificaremos con usted.

A qué nos compromete este artículo

Este es el panorama a fecha de 2026-05-28. Lo actualizaremos cuando cambie la arquitectura: cambio de proveedor, migración de región, un nuevo servicio externo. La configuración actual es verificable en nuestro vercel.json abierto, en el motor mind-sdk + Mind API que corre en OVH Francia y en el panel de cada proveedor.

Si algo de lo anterior le parece incorrecto, o su DPO necesita una respuesta que este mapa no da, escríbanos. Preferimos corregir un detalle que falta antes que usted lo descubra en una revisión de contrato.

Fuentes: regiones de ejecución y enrutamiento de modelos verificados contra la configuración desplegada (vercel.json, fly.toml) y el código publicado; Vercel AI Gateway (la vía de fijación de proveedor del digest), FLORES-200; comprobado en agosto de 2026.