¿Qué proveedor de modelos puede ver los documentos de tus clientes?

Antes o después, el delegado de protección de datos de un cliente te hará una pregunta: cuando tu producto lee nuestras políticas, contratos y archivos de proveedores, ¿quién más los ve? Si tu respuesta es "usamos un proveedor de LLM", el acuerdo se ralentiza. La respuesta que necesitan debe nombrar a cada empresa en la cadena, dónde se ejecuta, cuánto tiempo conserva el texto y qué contrato lo cubre. Esta guía muestra cómo llegar a esa respuesta y cómo nos aseguramos de cumplirla antes de que una función que lee documentos llegue a un cliente.

Empieza con tu rol

En la mayoría de productos de cumplimiento, tu cliente es el responsable del tratamiento de los documentos que sube, y tú los procesas siguiendo sus instrucciones. Esto te convierte en un encargado del tratamiento, y a cada empresa que contrates para manejar esos documentos en un subencargado del tratamiento, actuando en nombre de tu cliente. Si también usas los documentos para tus propios fines, por ejemplo, para mejorar tus modelos, te conviertes en responsable del tratamiento de ese procesamiento, y el resto de esta guía cambia. Decide cuál es tu rol y escríbelo en tu acuerdo de tratamiento de datos.

La cadena es más larga de lo que crees

Un documento que tu producto envía a un modelo suele cruzar tres empresas. Tu propio alojamiento lo recibe primero. A continuación, un enrutador puede recibirlo si usas uno para llegar a varios modelos a través de una sola API (OpenRouter es el caso más común). Por último, un proveedor de inferencia ejecuta el modelo y ve el texto completo. Con modelos de pesos abiertos, el proveedor suele no ser la empresa que entrenó el modelo: un mismo modelo puede ser servido por varios proveedores en varios países, y el enrutador puede elegir uno diferente en cada solicitud a menos que le indiques lo contrario.

Cada uno de ellos que pueda ver el texto es un subencargado del tratamiento. Las políticas y los contratos con proveedores están llenos de datos personales: el nombre de una empresa por sí solo no lo es, pero los firmantes, aprobadores y contactos nombrados detrás de ella sí lo son, incluso en un ámbito puramente profesional.

Cuatro registros por proveedor

Debe estar en tu lista de subencargados, con su ubicación, su rol y el mecanismo de transferencia. Si tus clientes te dan una autorización escrita general para esa lista en tu APD (RGPD Art. 28(2)), añadir un proveedor que no esté en ella significa informarles con antelación para que puedan objetar, dentro del plazo de notificación que establezca tu APD. Según el Art. 28(4), sigues siendo plenamente responsable ante tu cliente del rendimiento de cada proveedor.

Conoces qué contrato lo vincula y puedes producirlo. Se trata ya sea de tu propio acuerdo con el proveedor, o del acuerdo del enrutador que impone las mismas obligaciones del Art. 28(3) sobre él. Léelo para verificar esas obligaciones: instrucciones documentadas, confidencialidad, seguridad, ayuda con las solicitudes de los interesados y las brechas, eliminación al final del servicio, derechos de auditoría. Pide también su certificado ISO 27001 o informe SOC 2; los delegados de protección de datos de los clientes suelen pedirlos antes que el texto del contrato. Si el proveedor está fuera del EEE, verifica la base de transferencia: primero una decisión de adecuación (para un proveedor de EE.UU., si está certificado bajo el Marco de Privacidad de Datos UE-EE.UU.), de lo contrario las Cláusulas Contractuales Tipo 2021 (Módulo 3 entre encargados del tratamiento), con una evaluación de impacto de la transferencia en cualquier caso para las CCT.

Conoces su postura de retención y entrenamiento, y de dónde proviene. La retención cero de datos (ZDR) significa que el proveedor no conserva ninguna copia del prompt ni de la respuesta después de servirla. Verifica si esto proviene de un contrato, de una configuración de cuenta en el enrutador o de una bandera en cada solicitud. Las tres son pruebas útiles; no son la misma evidencia, y un auditor lo preguntará. Lo mismo ocurre con "sin entrenamiento con tus datos". La retención cero también es una de las medidas suplementarias que tu evaluación de impacto de la transferencia puede citar.

Está reflejado en tus registros de actividades de tratamiento (RGPD Art. 30(2) para un encargado del tratamiento, incluyendo cualquier transferencia fuera del EEE y sus garantías), por lo que los registros, la lista de subencargados y los contratos cuentan la misma historia.

Fija la ruta, luego demuestra que está fija

La mayoría de los enrutadores eligen un proveedor por ti y hacen fallback a otro cuando el primero está ocupado. Esto es bueno para la disponibilidad, pero malo para los cuatro registros anteriores: un fallback a un proveedor que nunca incluiste en tu lista es un procesamiento por un subencargado no autorizado, no solo un registro desordenado. Tres configuraciones cierran esta brecha en un enrutador como OpenRouter: fija los proveedores que has verificado, desactiva los fallbacks a otros proveedores y envía los controles de datos en cada solicitud (sin recopilación de datos para entrenamiento, solo puntos finales de retención cero), de modo que una solicitud que no pueda ser atendida bajo esos términos falle en lugar de dirigirse a otro lugar.

Luego demuestra que está fija donde importa, en producción. Tu configuración dice lo que pretendías; el proveedor nombrado en la respuesta o en tu propio registro de llamadas dice lo que ocurrió. Registra cuál verificaste y cuándo.

Cómo lo hacemos antes de que una función llegue a los clientes

Esta semana activamos la revisión de documentos en ISMS Copilot solo para nuestra propia cuenta de prueba, antes de los clientes: subes una política, un modelo la revisa, y cualquier hallazgo que no cite literalmente el documento se descarta. Envía el texto completo de un documento a un modelo, por lo que pasa dos controles antes de llegar a cualquier cuenta de cliente. El primero se ejecuta en el commit exacto de la versión: cada proveedor de modelos configurado para la ruta de revisión ya debe estar en la sección de subencargados de nuestro APD, en nuestros registros de actividades de tratamiento y en nuestro inventario de APD, o la versión se detiene y la pregunta va al CEO. El segundo pregunta, para cada proveedor que recibirá documentos de clientes, qué acuerdo lo cubre y si podemos producirlo a solicitud. Los modelos de revisión están fijados a un proveedor cuyo complemento de tratamiento de datos está en nuestros archivos, la primera llamada al modelo en producción se registró como servida por ese proveedor, y cambiar una ruta significa volver a ejecutar el primer control.

Redactamos ese control con Claude y pedimos a ISMS Copilot que lo revisara como lo haría un auditor. Cuestionó una línea: una decisión de riesgo registrada documenta por qué se acepta un vacío, pero no es un contrato ni una garantía de transferencia. Esa distinción ahora está escrita en el control.

Si tus clientes necesitan procesamiento exclusivo en la UE

Algunos clientes no aceptarán ninguna transferencia fuera de la UE para este tipo de contenido (escribimos sobre cómo se plantea esa pregunta para un consultor de auditoría). La respuesta limpia es un proveedor con sede en la UE en un punto final cuya obligación de procesamiento en la UE está en el contrato, no solo en una página web, con retención cero. Una trampa: un proveedor puede estar basado en la UE mientras su punto final predeterminado no compromete dónde se ejecuta la inferencia. Mistral, por ejemplo, tiene un punto final global y otro vinculado a la UE (api.eu.mistral.ai); solo el segundo es una respuesta de procesamiento en la UE. Dirige tu código al punto final cuya región puedas poner por escrito y falla de manera explícita si alguien lo cambia.

Y envía menos. Cuando la tarea lo permita, elimina o reemplaza nombres antes de que un documento salga de tu sistema (seudonimización, RGPD Art. 25 y Art. 32). Suele ser la forma más económica de hacer que una transferencia sea más fácil de defender.

Qué hace la API de ISMS Copilot por ti

Construimos la API de ISMS Copilot para equipos que quieren respuestas de nivel de cumplimiento en su propio producto sin tener que reconstruir esta cadena (cómo las plataformas de cumplimiento la usan). Eliges la ruta de procesamiento según el nombre del modelo que llames:

• Modo UE (isms-fast-eu, isms-thinking-eu): procesado por Mistral AI en su proveedor de inferencia vinculado a la UE, bajo nuestro acuerdo comercial de retención cero de datos con Mistral, sin transferencia del procesamiento del modelo fuera del EEE.
• Modo global (isms-fast, isms-thinking, isms-mini): enrutado a través de OpenRouter a un conjunto cerrado de proveedores de inferencia, con retención cero de datos y sin entrenamiento.

Cada respuesta exitosa incluye un encabezado x-isms-processing-region (eu o global), por lo que puedes registrar y alertar sobre el modo de procesamiento de cada solicitud (cómo funciona la retención cero en la API). La lista de subencargados de la API y el acuerdo de tratamiento de datos de la API son públicos en nuestro centro de confianza, por lo que puedes copiar los datos que necesites en tu propia lista en lugar de pedírnoslos. Las nuevas cuentas de API elegibles reciben crédito gratuito mientras dure la oferta.

Una lista de verificación breve

1. Establece tu rol: encargado del tratamiento para tus clientes, o responsable del tratamiento para cualquier cosa que hagas con sus documentos por tu cuenta.
2. Dibuja la cadena para cada función que envía documentos a un modelo: tu alojamiento, el enrutador, cada proveedor que el enrutador pueda elegir.
3. Para cada proveedor, encuentra los cuatro registros: en tu lista, el contrato que lo vincula (con su base de transferencia), su postura de retención y entrenamiento con la fuente, en tus registros de actividades de tratamiento.
4. Fija los proveedores que has verificado, desactiva los fallbacks del enrutador, envía los controles de datos en cada solicitud y lee la fijación en producción.
5. Ofrece una ruta exclusiva para la UE en un punto final vinculado a la UE para los clientes que lo necesiten, haz visible la ruta por solicitud y envía menos datos personales cuando sea posible.

Si desarrollas con Claude, un buen primer paso es pedirle a Claude x ISMS Copilot: Claude lee tu código y redacta la lista de subencargados, luego ISMS Copilot la revisa y la cuestiona como lo haría un auditor. Tú decides qué va en la lista.