Contrato de encargado IA: Lo que falta en su contrato
Por qué los contratos estándar no cubren la infraestructura de IA empresarial. Con checklist de requisitos para RRHH y compliance.
Un contrato de encargado de tratamiento para infraestructura IA debe cubrir diez áreas que los contratos SaaS estándar no regulan: políticas de registro de prompts, separación de entornos (dev/staging/prod), cadenas de proveedores de modelos, procesamiento in-flight vs. at-rest, protección de datos de embeddings RAG, acceso desde terceros países a datos de producción, cumplimiento del secreto profesional, tokenización PII, trazabilidad del Decision Layer y verificabilidad de medidas técnicas.
Por qué los contratos estándar de encargado de tratamiento no cubren la infraestructura IA
Un contrato estándar de encargado de tratamiento regula cómo un proveedor de servicios trata datos personales por cuenta del responsable. Define la finalidad, las categorías de datos, las medidas técnicas y organizativas, los subencargados y los plazos de conservación. Para un sistema CRM o un software de RRHH, eso es suficiente.
La infraestructura de IA empresarial crea situaciones que ningún contrato estándar contempla. Un modelo de lenguaje procesa prompts - entradas de texto libre que pueden contener cualquier cosa: datos de personal, información de clientes, secretos empresariales, incluso categorías especiales según el artículo 9 del RGPD cuando un empleado formula una pregunta relacionada con la salud. Los datos fluyen a través de una cadena de sistemas: desde el frontend, pasando por una capa de orquestación, hasta el proveedor del modelo, de vuelta a una base de datos, posiblemente a través de un pipeline RAG con vectores embedding. En cada punto surgen diferentes cuestiones sobre almacenamiento, acceso y supresión.
Cuando solicita a su proveedor de IA su contrato de encargado de tratamiento y recibe un documento estándar, debería alertarse. No porque el proveedor no sea fiable, sino porque los riesgos específicos de la infraestructura IA requieren disposiciones diferentes a las de una aplicación SaaS convencional.
Diez brechas entre el contrato estándar y la realidad de la IA
1. Contenido de prompts como nueva categoría de datos
Los contratos estándar listan categorías de datos: nombre, email, número de empleado. Con agentes IA surge una categoría que no puede predefinirse - el prompt. Un prompt puede ser una pregunta inocua sobre política de vacaciones o una carta completa de cliente con datos personales. El contrato debe establecer que la responsabilidad de clasificación del contenido recae en la organización, no en el proveedor de IA, mientras que el proveedor debe demostrar medidas técnicas que protejan todo el contenido introducido independientemente de su sensibilidad.
2. Política de registro: ¿Qué puede aparecer en los logs?
Con software convencional, se registra lo técnicamente necesario. Con infraestructura IA, el registro adquiere otra dimensión: ¿Se registran los contenidos de los prompts? ¿Se almacenan las respuestas del modelo? ¿Los documentos cargados aparecen en logs de errores?
Un contrato robusto para infraestructura IA debe establecer explícitamente que en el entorno de producción el registro de cuerpos de solicitud/respuesta está desactivado, que solo se registran metadatos técnicos (códigos de estado, latencias, IDs de solicitud), que el registro de depuración en producción está desactivado y que los rastros de pila no contienen contenido de prompts ni documentos.
3. Separación de entornos: Dev, Staging, Producción
Todo despliegue enterprise tiene entornos de desarrollo, pruebas y producción. Con infraestructura IA, la separación es crítica para la seguridad porque datos reales pueden utilizarse como datos de prueba durante el desarrollo. Un contrato específico para IA debe establecer que dev y staging utilizan exclusivamente datos sintéticos o anonimizados, que el acceso a producción está restringido a roles definidos dentro de la UE/EEE y que los casos de soporte se gestionan únicamente con datos de prueba aprobados por la organización.
4. Cadena de proveedores de modelos en lugar de subencargados clásicos
Con software convencional, un proveedor tiene subencargados: un proveedor de hosting, quizás un servicio de email. Con infraestructura IA surge una cadena de tres niveles: el proveedor de infraestructura IA opera la plataforma, los proveedores de modelos (Azure OpenAI, Google Vertex AI, Anthropic) procesan los prompts y los proveedores de plataforma (Supabase, Vercel) alojan base de datos y frontend.
El punto crítico: ¿Quién es el socio contractual de los proveedores de modelos? ¿Los modelos operan en el tenant del proveedor de IA o en el tenant de la organización? Esta distinción determina si el proveedor del modelo es subencargado del proveedor o si la organización gestiona directamente las relaciones con proveedores.
| Componente | En tenant del cliente | En tenant del proveedor |
|---|---|---|
| Azure Entra ID (SSO) | ✓ Cliente | - |
| Azure OpenAI / Vertex AI | ✓ Cliente | - |
| Supabase (Base de datos) | ✓ Cliente | - |
| Vercel (Hosting) | ✓ Cliente | - |
| Plane (Sistema de tickets) | - | ✓ Proveedor |
| GitHub (Hosting de código) | - | ✓ Proveedor |
| Google Workspace (Comunicación) | - | ✓ Proveedor |
Los componentes en el tenant del cliente son gestionados por el cliente en su propio registro de proveedores. Los componentes en el tenant del proveedor están sujetos a la lista de subencargados en el contrato.
5. In-flight vs. at-rest: ¿Dónde permanecen los datos?
Con software convencional, la pregunta es sencilla: los datos residen en una base de datos. Con infraestructura IA existen dos modos de procesamiento. Procesamiento in-flight: el prompt se envía al proveedor del modelo, se procesa y se devuelve la respuesta - sin almacenamiento persistente en el proveedor. Almacenamiento at-rest: chats, archivos cargados y embeddings se almacenan en una base de datos - de forma persistente y asociada al usuario.
El contrato debe establecer disposiciones separadas para ambos modos.
6. RAG y embeddings: Datos vectoriales como nuevo desafío
RAG (Retrieval Augmented Generation) hace que los documentos empresariales sean consultables por IA. Los documentos se convierten en vectores embedding y se almacenan en una base de datos vectorial. Estos vectores son una nueva categoría de datos: no contienen texto legible pero, en determinadas circunstancias, pueden permitir inferencias sobre el contenido original. El contrato debe tratar los embeddings como datos personales cuando se generan a partir de documentos con datos personales.
7. Acceso desde terceros países a datos de producción
Muchos proveedores de IA trabajan con equipos distribuidos. Cuando un desarrollador de un tercer país tiene acceso al entorno de producción, esto constituye una transferencia de datos según el RGPD. El contrato debe definir que el acceso a producción está restringido a la UE/EEE, que el acceso a dev/staging desde terceros países es admisible (porque solo contienen datos sintéticos), que RBAC prevé grupos de administradores separados para producción y dev/staging y que existe un procedimiento de excepción que requiere autorización escrita del responsable.
Para empresas con operaciones en Latinoamérica, las transferencias internacionales requieren mecanismos adicionales bajo las legislaciones locales (LGPD en Brasil, Ley Federal de Protección de Datos Personales en México, etc.).
8. Secreto profesional en la plataforma IA
Para sectores regulados - despachos de abogados, asesores fiscales, auditores, organizaciones sanitarias y empresas con procesos sujetos a secreto profesional - el procesamiento en plataformas IA requiere disposiciones contractuales explícitas. La normativa española contempla la protección del secreto profesional según normativa sectorial. El proveedor debe comprometer a todas las personas con acceso mediante declaraciones escritas de confidencialidad. Las cláusulas estándar de confidencialidad no son suficientes.
9. Tokenización PII como módulo opcional
Filtros de entrada y salida que detectan datos personales y los seudonimizan antes de enviarlos al proveedor del modelo añaden una capa adicional de protección. La tokenización PII no es necesaria en cada despliegue, pero el contrato debe contemplarla como módulo opcional. Importante: si la re-identificación reversible es posible, el contrato debe regular quién tiene acceso a la tabla de mapeo, cómo se almacenan y cifran las claves de mapeo y que la re-identificación solo se realiza con finalidad definida tras autorización documentada.
10. Trazabilidad y Decision Layer
Los agentes IA toman o preparan decisiones. Cada una de estas decisiones debe ser trazable - no solo para la protección de datos, sino también para auditoría interna, auditores externos y el comité de empresa. El Decision Layer descompone cada proceso en pasos de decisión individuales y define para cada paso: humano, motor de reglas o IA. El contrato debe anclar la trazabilidad como componente contractual: ¿Qué datos se registran por decisión? ¿Durante cuánto tiempo se conservan? ¿Quién tiene acceso?
La checklist: 25 preguntas para su proveedor de IA
La siguiente checklist traduce las diez brechas en preguntas de verificación concretas.
Checklist de requisitos: 25 preguntas de verificación para contratos IA →
A - Categorías de datos y finalidades de tratamiento
- ¿Los contenidos de prompts y respuestas del modelo están listados como categorías de datos independientes en el contrato?
- ¿Se establece que la responsabilidad de clasificación del contenido recae en la organización, no en el proveedor?
- ¿Los embeddings/vectores están clasificados como datos potencialmente personales?
- ¿El contrato contempla las categorías especiales del artículo 9 del RGPD que pueden surgir por entradas de usuarios?
B - Registro y monitorización
- ¿El registro de cuerpos de solicitud/respuesta en el entorno de producción está desactivado?
- ¿Qué metadatos se registran (códigos de estado, latencias, IDs de solicitud)?
- ¿El registro de depuración en producción está verificablemente desactivado?
- ¿Los rastros de pila y mensajes de error están configurados para excluir datos de contenido de los logs?
- ¿La verificación de la configuración de registro es parte del proceso de lanzamiento?
C - Separación de entornos y acceso
- ¿Existen entornos separados (dev, staging, producción) con políticas de datos distintas?
- ¿Los entornos dev/staging contienen exclusivamente datos sintéticos o anonimizados?
- ¿El acceso a producción está restringido a roles autorizados dentro de la UE/EEE?
- ¿Existe un procedimiento de excepción documentado para casos de soporte con acceso a datos?
D - Proveedores de modelos y subencargados
- ¿La delimitación es clara: Qué proveedores son subencargados del proveedor y cuáles operan en el tenant de la organización?
- ¿La retención de contenido en los proveedores de modelos está desactivada?
- ¿La exclusión del uso para entrenamiento está documentada contractualmente?
- ¿Dónde se ubican los endpoints de los modelos (región UE, US, otros)?
E - Almacenamiento y supresión de datos
- ¿Se establece dónde se almacenan los datos de contenido persistentes (base de datos, región, proveedor)?
- ¿Qué retención de copias de seguridad aplica y cómo se gestionan los datos eliminados en las copias?
- ¿El usuario individual puede eliminar sus propios datos dentro de la aplicación?
F - Sectores regulados
- ¿El contrato contiene disposiciones de cumplimiento con el secreto profesional (normativa sectorial española o equivalente)?
- ¿Existen compromisos de confidencialidad para todas las personas con acceso?
- ¿La tokenización PII está disponible como módulo opcional?
G - Gobernanza y verificabilidad
- ¿Una trazabilidad de auditoría para decisiones de agentes está anclada como componente contractual?
- ¿Las medidas técnicas y organizativas pueden evidenciarse bajo solicitud (documentación de configuración, extractos de logs anonimizados)?
Del checklist a la arquitectura
Estas 25 preguntas no son una herramienta jurídica. Son una brújula arquitectónica. Cada pregunta que su proveedor de IA no puede responder revela una brecha en su infraestructura - no solo en su contrato.
En Gosign, hemos integrado estos requisitos en la arquitectura: separación de entornos con bloqueo de producción, registro sin datos de contenido, proveedores de modelos en el tenant del cliente, Decision Layer con trazabilidad completa de auditoría. No porque un cliente lo exigiera, sino porque la IA empresarial sin estas bases no es auditable.
Si desea evaluar cómo su infraestructura IA actual se compara con estos 25 puntos - o si está evaluando una nueva plataforma - hablemos.