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

Toda conversación seria de adquisición empresarial llega eventualmente a la misma pregunta: "¿A dónde van estos datos?". El DPO quiere una lista de subprocesadores. El CIO quiere saber qué proveedores tienen su sede en EE. UU. El departamento legal quiere un diagrama con flechas.

Preferimos que tenga el panorama completo a que se lo enviemos por partes por correo electrónico. Así que aquí está la ruta de datos de una reunión — cada servicio externo que toca, dónde se ejecuta cada uno y qué datos fluyen a través de él. Verificado contra la configuración de despliegue real el 2026-05-28.

Toda ruta que toca el contenido de la reunión está en la UE en tiempo de ejecución — incluyendo los pasos de IA posteriores a la reunión, que solíamos marcar como el único vacío y que desde entonces hemos trasladado a procesadores europeos. Decimos claramente dónde se encuentra el único modelo de EE. UU. que queda, y por qué nunca ve su reunión.

Esta publicación mapea dónde se ejecuta su reunión. Su complemento, De qué está compuesta una reunión de InterMIND, mapea de qué está hecha — qué capas son código propio, cuáles son de código abierto y dónde somos pragmáticos respecto al SaaS propietario.

Qué significa realmente "dónde se ejecuta"

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

1. Tiempo de ejecución / ruta de datos. Dónde se procesan físicamente los bytes de su reunión durante la solicitud. Esto es de lo que tratan realmente las normativas de residencia de datos y la mayoría de los DPA.
2. Domicilio corporativo del proveedor. Dónde está legalmente constituido el proveedor de SaaS. Esto es de lo que tratan las discusiones sobre el CLOUD Act — el alcance teórico de una compulsión de EE. UU. contra la entidad matriz del proveedor, independientemente de dónde se ejecute la carga de trabajo.

Casi todas las preguntas tipo "¿esto es UE?" son en realidad una de estas dos, formuladas de manera imprecisa. Respondemos a ambas por separado para cada proveedor a continuación.

La ruta de datos de una reunión

Rastree una llamada desde la unión hasta el correo de seguimiento:

1. El navegador abre la página de la reunión. El SSR se ejecuta en Vercel, fijado en fra1 (Frankfurt). Todos los datos de solicitud/respuesta — cookies de sesión, cargas útiles de API, HTML renderizado por el servidor — se procesan en la UE en tiempo de ejecución.
2. 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 el navegador del orador. Local. Nunca sale del dispositivo hasta que la transcripción resultante se envía para su traducción. (Cubrimos por qué en Dentro de las cuatro canalizaciones de traducción.)
4. La traducción de voz y chat llega a nuestro propio motor en OVH Francia. Este es mind-sdk + la Mind API — nuestro código, nuestros hosts, en Francia. No hay ningún modelo de terceros en el bucle. Presupuesto inferior a un segundo, grupo de WebSocket por idioma, residente en la UE en cada salto.
5. Un documento enviado al chat (PDF, DOCX, PPTX, XLSX) va del lado del servidor desde el servidor ws de París a DeepL en Colonia. Empresa alemana, procesamiento alemán. La voz y el chat no tocan DeepL.
6. Los datos de la aplicación — usuarios, equipos, mensajes, metadatos de la reunión — residen en Neon Postgres en AWS Frankfurt (eu-central-1). Instantáneas en la misma región.
7. Las grabaciones, archivos adjuntos y exportaciones se almacenan en Tigris, almacenamiento compatible con S3 en Fly. Replicado en el edge; el bucket es configurable para una región múltiple de la UE para inquilinos que necesiten fijarlo de forma más estricta.
8. Los errores y los rastros de rendimiento van a la instancia europea de Sentry (de.sentry.io). La organización de EE. UU. se retiró en mayo.
9. Los análisis de producto van a PostHog UE (eu.i.posthog.com).
10. El correo transaccional (enlaces mágicos, invitaciones, recibos) se envía a través de Resend desde eu-west-1 (Irlanda).

Todo lo anterior está en la UE en tiempo de ejecución. El motor de traducción — la parte a través de la cual fluyen realmente la mayor parte de sus datos — también es código propio, no de un tercero. El SDK de cliente en el que se ejecuta es de código abierto (BSD-3-Clause) y es auditable hoy en día; el autoalojamiento del motor en sí está en la hoja de ruta para un cliente que lo necesite.

El mapa de proveedores

Los dos flujos de datos más pesados por volumen — traducción de voz/chat a través de nuestro propio motor en OVH y traducción de documentos a través de DeepL — también resultan ser los dos proveedores cuya entidad matriz está en la UE. Eso cubre la mayor parte del contenido de la reunión. La lista completa de subprocesadores con detalles del domicilio corporativo entra en el DPA como práctica estándar; la tabla anterior es la vista de tiempo de ejecución, que es de lo que tratan la mayoría de las cláusulas de residencia de datos.

Los pasos de IA posteriores a la reunión, explicados con claridad

Después de que termina la llamada, ejecutamos algunos pasos del modelo de lenguaje sobre lo que se dijo: el resumen de IA (temas, decisiones, elementos de acción, preguntas abiertas), el resumen posterior a la reunión y el editor de notas de IA (traducir una nota, o corregir / ampliar / simplificarla). Estos son los únicos lugares donde un modelo de propósito general toca contenido derivado de la reunión — y todos ellos ahora se ejecutan en procesadores europeos:

• El resumen se ejecuta en Mistral alojado en la UE (mistral-large-3, mistral-medium-3.5 como respaldo), al que se llega a través de la pasarela de IA de Vercel fijada en el proveedor de Mistral con cero retención de datos — la solicitud falla en lugar de recurrir a un host que no sea ZDR o de EE. UU.
• El resumen y la acción de traducir del editor pasan por nuestro propio motor europeo en OVH — el mismo que traduce voz y chat en vivo — por lo que el resumen nunca sale del plano de datos en el que ya vivió la reunión.
• Las acciones generativas del editor (corregir, ampliar, reducir, simplificar, resumir) no pueden ejecutarse en un motor de traducción, por lo que utilizan la misma ruta de Mistral en la UE + cero retención de datos que el resumen.

La voz en tiempo real, el chat en tiempo real, las notas y la traducción de documentos nunca pasan por ninguno de estos — fueron residentes en la UE desde el principio.

El único lugar donde un modelo con sede en EE. UU. sigue en el bucle no toca datos de la reunión: nuestro benchmark público de calidad de traducción utiliza un modelo frontera como juez automatizado, evaluando las traducciones automáticas de las frases de referencia de FLORES-200. Es un conjunto de datos público y fijo — no la reunión de nadie.

Seguiremos avanzando en los pasos de Mistral en la UE: una exclusión controlada por el propietario planificada para desactivar el resumen por completo, y un modelo de pesos abiertos autoalojado (clase Kimi) en OVH para reemplazar el Mistral externo en las tareas de resumen que no necesitan un modelo de razonamiento frontera. Ambos están en la hoja de ruta, no enviados; actualizaremos esta publicación cuando lleguen.

Qué significa esto para su DPA

Para la mayoría de los compradores de la UE — el Mittelstand alemán, industrias reguladas que ejecutan DPA estándar del GDPR — el panorama anterior responde directamente a la pregunta de residencia de datos: cada salto en tiempo de ejecución que da su reunión está en la UE. El domicilio del proveedor se revela en la lista de subprocesadores según la práctica normal; no hay nada sorprendente allí. El mapa de residencia es una pieza; para el resto de las obligaciones de protección de datos — supresión, retención, portabilidad, consentimiento — pasamos el código base por una auditoría completa y cerramos cada elemento contra el código.

Para la souveraineté numérique francesa y las adquisiciones de nivel SecNumCloud, el domicilio corporativo del proveedor es en sí mismo parte del criterio, no solo la ubicación en tiempo de ejecución. Esa es una conversación diferente — una topología de despliegue alternativa que mantiene cada componente bajo proveedores de jurisdicción europea. No ejecutamos eso por defecto; lo lanzaremos para un inquilino que lo necesite y donde el contrato justifique la construcción.

Para los compradores nacionales de EE. UU. y la mayoría de los de APAC, suele ser cierto lo contrario: quieren baja latencia desde su región, lo cual es un problema diferente. Hoy en día ejecutamos una única región en fra1. Si su tráfico justifica un edge en EE. UU., lo planificaremos con usted.

A qué nos compromete esta publicación

Este es el panorama el 2026-05-28. Lo actualizaremos cuando cambie la pila — cambio de proveedor, migración de región, un nuevo servicio externo. La configuración actual es verificable en nuestro vercel.json abierto, el motor mind-sdk + Mind API ejecutándose en OVH Francia, y en el panel propio de cada proveedor.

Si algo aquí parece incorrecto, o su DPO necesita una respuesta que este mapa no proporciona, escríbanos. Preferimos corregir un detalle faltante a que usted lo descubra en una revisión de contrato.

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