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

Toda conversación seria de compras corporativas 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 área legal quiere un diagrama con flechas.

Preferimos que tenga el panorama completo antes que ir enviándoselo por correo a trozos. 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 por él. Verificado contra la configuración de despliegue real el 2026-05-28.

Hay una ruta donde el domicilio del proveedor sigue siendo EE. UU., y lo decimos sin rodeos. El resto es UE en tiempo de ejecución.

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 petición. Esto es lo que regulan, en realidad, las normas de residencia de datos y la mayoría de los DPA.
2. Domicilio societario del proveedor. Dónde está legalmente constituido el proveedor SaaS. Esto es lo que está en juego en los debates sobre la CLOUD Act: el alcance teórico de una orden estadounidense contra la matriz del proveedor, independientemente 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 poca precisión. Las respondemos por separado para cada proveedor a continuación.

La ruta de datos de una reunión

Siga una llamada desde la conexión hasta el correo de seguimiento:

1. El navegador abre la página de la reunión. El SSR se ejecuta en Vercel, anclado a fra1 (Fráncfort). Todos los datos de petición/respuesta —cookies de sesión, payloads de 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 el navegador del hablante. Local. Nunca abandona el dispositivo hasta que la transcripción resultante se envía para su traducción. (Explicamos por qué en Por dentro de los cuatro pipelines de traducción.)
4. La traducción de voz y chat pasa por nuestro propio motor en OVH Francia. Esto es mind-sdk-web: nuestro código, nuestros hosts, en Francia. Ningún modelo de terceros está en el bucle. Presupuesto sub-segundo, pool de WebSocket por idioma, residente en la UE en cada salto.
5. Un documento soltado en el chat (PDF, DOCX, PPTX, XLSX) se envía del lado del servidor desde el ws-server 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— residen en Neon Postgres en AWS Fráncfort (eu-central-1). Las instantáneas, en la misma región.
7. Las grabaciones, adjuntos y exportaciones se almacenan en Tigris, almacenamiento compatible con S3 sobre Fly. Replicado en el edge; el bucket se puede configurar como multirregión UE para los inquilinos que necesiten un anclaje más estricto.
8. Los errores y las 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) se envía vía Resend desde eu-west-1 (Irlanda).

Todo lo anterior es UE en tiempo de ejecución. El motor de traducción —la pieza por la que en realidad fluye la mayor parte de sus datos— también es código propio, lo que significa que el motor mismo puede ser auditado o autoalojado por 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— son también los dos proveedores cuya matriz está en la UE. Eso cubre la mayor parte del contenido de la reunión. La lista completa de subencargados con detalle de domicilio societario va en el DPA como práctica estándar; la tabla anterior es la vista en tiempo de ejecución, que es de lo que tratan la mayoría de las cláusulas de residencia de datos.

La única brecha actual, dicha sin rodeos

Cuando termina la llamada, generamos un resumen IA posterior a la reunión: temas, decisiones, acciones, preguntas abiertas. Al modelo que produce el resumen se accede a través del AI Gateway de Vercel (un proxy en región UE), pero los modelos subyacentes son Google Gemini 2.5 Flash con Anthropic Claude Sonnet como respaldo: ambos proveedores domiciliados en EE. UU.

La voz en tiempo real, el chat en tiempo real y la traducción de documentos no pasan por esta ruta. El resumen es un paso aparte, posterior a la reunión, que toma la transcripción que ya hemos producido y escribe un resumen encima.

Estamos cerrando esta brecha de dos formas:

1. Opt-out controlado por el propietario, próximamente. El propietario de un espacio de trabajo podrá desactivar por completo la canalización del resumen IA, en cuyo caso el resumen posterior a la reunión simplemente no se genera y la transcripción se queda donde estaba: en la UE. Desactivado por defecto para nuevos inquilinos; los inquilinos existentes reciben un aviso y pueden dejarlo activo si lo desean.
2. Modelo de resumen autoalojado en la UE. Estamos desplegando un modelo de pesos abiertos (clase Kimi) en OVH para tareas como la generación de resúmenes que no requieren un razonador de frontera. Cuando ese sea el backend del resumen, la disyuntiva desaparece: la misma canalización funciona sin ningún proveedor domiciliado en EE. UU. en ella.

Si el resumen es la diferencia entre «esto nos sirve» y «esto no» para sus compras, díganoslo: lo priorizaremos en consecuencia.

Qué significa esto para su DPA

Para la mayoría de los compradores de la UE —Mittelstand alemán, sectores regulados con DPA de RGPD estándar— el panorama anterior responde directamente a la pregunta de residencia de datos: cada salto en tiempo de ejecución de su reunión es en la UE. El domicilio del proveedor se revela en la lista de subencargados según la práctica habitual; nada sorprendente ahí.

Para la souveraineté numérique francesa y las compras con grado SecNumCloud, el domicilio societario del proveedor es en sí mismo parte del criterio, no solo la ubicación de ejecución. Esa es una conversación distinta: una topología de despliegue alternativa que mantiene cada componente bajo proveedores de jurisdicción europea. No la ofrecemos por defecto; la levantamos para un inquilino que la necesite y cuando el contrato justifique la construcción.

Para los compradores estadounidenses domésticos y la mayoría de los de APAC, suele ocurrir lo contrario: quieren baja latencia desde su región, que es un problema diferente. Hoy operamos en una sola región en 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 el 2026-05-28. 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-web que corre en OVH Francia y en el panel de cada proveedor.

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