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

Toda conversación seria de compras empresariales acaba llegando a la misma pregunta: «¿Adónde van estos datos?». El DPO quiere una lista de subencargados. El CIO quiere saber qué proveedores están domiciliados en EE. UU. El departamento jurídico quiere un diagrama con flechas.

Preferimos que tenga el panorama completo antes que ir enviándolo por correo pieza a pieza. Así que aquí tiene la ruta de datos de una reunión: cada servicio externo que toca, dónde se ejecuta cada uno y qué datos lo atraviesan. Verificado contra la configuración real de despliegue el 28-05-2026.

Cada ruta que toca contenido de la reunión está en la UE en tiempo de ejecución, incluidos los pasos de IA posteriores a la reunión, que antes señalábamos como el único hueco y que desde entonces hemos trasladado a procesadores de la UE. Decimos con claridad dónde se aloja el único modelo estadounidense que queda y por qué no ve nunca su reunión.

Esta entrada mapea dónde se ejecuta su reunión. Su acompañante, De qué está hecha 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 con 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. De esto tratan en realidad 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 SaaS. De esto tratan las discusiones sobre la CLOUD Act: el alcance teórico de una coerción estadounidense sobre la entidad matriz del proveedor, con independencia de dónde se ejecute la carga de trabajo.

Casi toda pregunta del tipo «¿esto está en la UE?» es realmente una de estas dos, formulada de forma imprecisa. Las respondemos por separado para cada proveedor más abajo.

La ruta de datos de una reunión

Sigamos una llamada desde la entrada 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 petición/respuesta —cookies de sesión, payloads de API, HTML renderizado en el 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 el navegador del hablante. Local. No sale del dispositivo hasta que la transcripción resultante se envía a traducir. (Explicamos por qué en Por dentro de los cuatro pipelines de traducción.)
4. La traducción de voz y de chat va a nuestro propio motor en OVH Francia. Esto es mind-sdk + la API de Mind: nuestro código, nuestros hosts, en Francia. Ningún modelo de terceros entra en el bucle. Presupuesto subsegundo, pool de WebSocket por idioma, residencia en la UE en cada salto.
5. Un documento soltado en el chat (PDF, DOCX, PPTX, XLSX) va 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 aplicación —usuarios, equipos, mensajes, metadatos de reuniones— viven en Neon Postgres en AWS Fráncfort (eu-central-1). Las instantáneas, en la misma región.
7. Grabaciones, adjuntos, exportaciones se almacenan en Tigris, almacenamiento compatible con S3 en Fly. Replicado en el edge; el bucket es configurable a multirregión UE para los inquilinos que necesiten fijarlo de forma más estricta.
8. Errores y trazas de rendimiento van a la instancia europea de Sentry (de.sentry.io). La organización estadounidense se retiró 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 está en la UE en tiempo de ejecución. El motor de traducción —por donde fluye en realidad la mayor parte de sus datos— es además código propio, no de un tercero. El SDK cliente sobre el que se apoya es de código abierto (BSD-3-Clause) y auditable hoy mismo; 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 —la traducción de voz/chat a través de nuestro propio motor en OVH y la traducción de documentos a través de DeepL— resultan ser también los dos proveedores cuya entidad matriz está en la UE. Eso cubre el grueso del contenido de la reunión. La lista completa de subencargados con el detalle del domicilio corporativo entra en el DPA como práctica estándar; 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 posteriores a la reunión, dichos con claridad

Cuando la llamada termina ejecutamos algunos pasos con modelos de lenguaje sobre lo que se dijo: el resumen de IA (temas, decisiones, acciones, preguntas abiertas), el resumen posterior a la reunión y el editor de notas con IA (traducir una nota, o corregirla / ampliarla / simplificarla). Son los únicos puntos en los que un modelo de propósito general toca contenido derivado de la reunión, y todos ellos se ejecutan ahora en procesadores de la UE:

• El resumen de IA se ejecuta sobre Mistral alojado en la UE (mistral-large-3, con mistral-medium-3.5 como respaldo), accedido a través del AI Gateway de Vercel fijado al proveedor Mistral con retención cero de datos: la petición falla en lugar de recurrir a un host sin ZDR o estadounidense.
• El resumen y la acción traducir del editor pasan por nuestro propio motor en la UE en OVH —el mismo que traduce la voz y el chat en vivo—, de modo que el resumen nunca sale del plano de datos en el que ya vivía la reunión.
• Las acciones generativas del editor (corregir, ampliar, reducir, simplificar, resumir) no pueden ejecutarse sobre un motor de traducción, así que usan la misma ruta de Mistral en la UE con retención cero de datos que el resumen de IA.

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

El único lugar donde sigue habiendo un modelo domiciliado en EE. UU. en el bucle no toca ningún dato de reunión: nuestro benchmark público de calidad de traducción usa un modelo de frontera como juez automatizado, puntuando traducciones automáticas de oraciones de referencia de FLORES-200. Se trata de un conjunto de datos fijo y público, no de la reunión de nadie.

Aún vamos a ir más lejos en los pasos sobre Mistral en la UE: una exclusión controlada por el propietario prevista para desactivar el resumen de IA por completo, y un modelo de pesos abiertos autoalojado (clase Kimi) en OVH para sustituir al Mistral externo en las tareas de resumen que no requieran un razonador de frontera. Ambas cosas están en la hoja de ruta, no entregadas; actualizaremos esta entrada 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 aplican DPA estándar de GDPR— el panorama anterior responde directamente a la pregunta de residencia de datos: cada salto en tiempo de ejecución de su reunión ocurre en la UE. El domicilio del proveedor se revela en la lista de subencargados, como es práctica habitual; nada sorprendente ahí. El mapa de residencia es una pieza; para el resto de las obligaciones de protección de datos —supresión, conservación, portabilidad, consentimiento— sometimos el código base a una auditoría completa y cerramos cada punto contra el código.

Para la souveraineté numérique francesa y la contratación de nivel SecNumCloud, el domicilio corporativo del proveedor es en sí mismo parte del criterio, no solo la ubicación de ejecución. Esa es otra conversación: una topología de despliegue alternativa que mantiene cada componente bajo proveedores de jurisdicción europea. No la ejecutamos por defecto; la pondremos en marcha para un inquilino que la necesite y donde el contrato justifique el esfuerzo.

Para los compradores estadounidenses y la mayoría de los de APAC, suele ser 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 esta entrada

Este es el panorama el 28-05-2026. Lo actualizaremos cuando cambie el stack: 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 + API de Mind que se ejecuta en OVH Francia y en el panel propio de cada proveedor.

Si algo aquí parece equivocado, o su DPO necesita una respuesta que este mapa no le da, escríbanos. Preferimos corregir un detalle que falta antes que dejar que lo descubra en una revisión contractual.