IA empresarial: confidencialidad, proveedores externos y acuerdos

Es habitual pensar solo en el texto que escribe el usuario. En un sistema real viajan más cosas, y algunas se generan sin que nadie las vea. Antes de leer condiciones contractuales conviene dibujar el recorrido completo de una petición.

La última fila es la que más se olvida. Una herramienta de observabilidad que guarda cada petición entera para depurar es, a efectos de confidencialidad, otro destinatario de los datos. Lo mismo ocurre con una plataforma de evaluación de prompts o con un servicio intermedio que enruta peticiones entre varios modelos.

Las condiciones de los proveedores de modelos cambian con el tiempo y varían según el producto y el tipo de cuenta. Por eso no tiene sentido fiarse de lo que se recuerda o de lo que publicó un blog: hay que leer los documentos vigentes del servicio concreto que se va a contratar y guardar la versión aceptada. Las preguntas que conviene responder por escrito son estas:

• ¿Se usan las entradas y salidas para entrenar o mejorar modelos? ¿Es así por defecto o depende de una opción de la cuenta?
• ¿Cuánto tiempo se conservan las peticiones y con qué finalidad (detección de abusos, depuración, soporte)? ¿Puede reducirse ese plazo?
• ¿Qué funciones almacenan datos de forma persistente, como historiales, archivos subidos o índices? ¿Quién y cómo los borra?
• ¿Quién dentro del proveedor puede acceder a una petición concreta y en qué circunstancias?
• ¿Qué subencargados intervienen y cómo se comunica un cambio en la lista?
• ¿Qué ocurre con los datos al cancelar la cuenta?

Un error frecuente es probar un caso de uso con una cuenta personal o un plan de consumo y llevar después ese mismo montaje a producción. Las condiciones de uno y otro pueden ser muy distintas. Para cualquier dato que no sea público, la prueba debería hacerse ya con la cuenta y la configuración que se usarían en producción.

Si por el sistema pasan datos personales, el Reglamento general de protección de datos (RGPD) obliga a identificar papeles. Su artículo 4 define al responsable del tratamiento como quien determina los fines y medios del tratamiento, y al encargado como quien trata datos personales por cuenta del responsable. En un proyecto de IA típico, la empresa que usa el sistema es responsable; la empresa que lo desarrolla y opera, si accede a los datos, suele ser encargada; y el proveedor del modelo puede ser encargado directo de la empresa usuaria o subencargado del integrador, según quién contrate el servicio.

El artículo 28 establece que el responsable elegirá únicamente encargados que ofrezcan garantías suficientes, que el encargado no recurrirá a otro encargado sin autorización previa por escrito (específica o general, y en este último caso informando de los cambios para que el responsable pueda oponerse) y que la relación se regirá por un contrato u otro acto jurídico con un contenido mínimo. Entre otras cosas, ese contrato debe prever que el encargado trate los datos siguiendo instrucciones documentadas, que su personal guarde confidencialidad, que aplique las medidas de seguridad del artículo 32 y que, al terminar, suprima o devuelva los datos según elija el responsable.

En la práctica eso significa que el contrato con el proveedor de IA no puede quedar fuera del análisis por ser «un servicio estándar». Si el integrador contrata el modelo, debe poder trasladar al cliente las condiciones del subencargado y, conforme al apartado 4 del mismo artículo, imponerle las mismas obligaciones de protección de datos. Si el cliente contrata el modelo directamente, el integrador necesita saber qué condiciones aceptó para no diseñar algo incompatible con ellas.

Muchos proveedores de modelos tienen sede o infraestructura fuera del Espacio Económico Europeo. El artículo 44 del RGPD solo permite transferir datos personales a un tercer país si se cumplen las condiciones de su capítulo V. Las dos vías más habituales son una decisión de adecuación de la Comisión sobre ese país (artículo 45) o garantías adecuadas, entre ellas las cláusulas tipo de protección de datos adoptadas por la Comisión (artículo 46, apartado 2, letra c).

Para el diseño técnico importa algo más concreto que la sede del proveedor: dónde se procesa cada petición, dónde se guardan los registros y desde dónde accede el personal de soporte. Algunos servicios permiten elegir región de procesamiento o almacenamiento; conviene comprobar si esa elección abarca todos los flujos de la tabla anterior o solo algunos. La valoración jurídica de la transferencia corresponde al responsable del tratamiento con su asesoría; el equipo técnico debe aportarle un mapa fiel de por dónde pasan los datos.

El contrato fija lo que el proveedor se compromete a hacer. La arquitectura decide cuánta información le llega. El artículo 32 del RGPD menciona expresamente la seudonimización y el cifrado entre las medidas posibles, y ambas tienen traducción directa en un sistema con IA:

• Minimizar la entrada: enviar al modelo solo los campos necesarios para la tarea, no el registro completo del cliente.
• Seudonimizar antes de enviar: sustituir nombres, identificadores o importes por marcadores y recomponer la respuesta en el lado propio, cuando la tarea lo permita.
• Filtrar el contexto recuperado según los permisos del usuario, para que el modelo no reciba documentos que esa persona no podría abrir.
• Usar cuentas de organización con claves separadas por entorno y desactivar las funciones de almacenamiento persistente que no se necesiten.
• Controlar los registros propios: decidir qué se guarda de cada petición, durante cuánto tiempo y quién lo ve, y no copiar peticiones completas en herramientas de terceros sin el mismo análisis.
• Prever una alternativa: si un proveedor cambia sus condiciones, que el sistema pueda pasar a otro modelo o a un flujo manual sin rehacerse.

Entre la empresa usuaria y quien desarrolla el sistema, además del encargo de tratamiento, suele ser útil pactar expresamente estos puntos:

• Relación de proveedores de IA y servicios auxiliares que intervienen, con el tipo de cuenta y la región, y procedimiento para cambiarlos.
• Categorías de información que pueden enviarse al modelo externo y categorías excluidas sin autorización expresa.
• Configuración comprometida: entrenamiento con datos desactivado cuando el servicio lo permita, plazos de retención, funciones de almacenamiento usadas.
• Medidas de minimización y seudonimización previstas en el diseño.
• Notificación de incidentes que afecten a los datos, incluidos los que ocurran en el proveedor del modelo.
• Devolución y borrado al terminar, incluidos índices, archivos subidos y registros.
• Información necesaria para demostrar el cumplimiento y, si se pacta, auditorías proporcionadas.

1. ¿Está dibujado el recorrido completo de los datos, incluidos registros y herramientas auxiliares?
2. ¿Se han leído y guardado las condiciones vigentes del servicio y tipo de cuenta concretos?
3. ¿Están identificados responsable, encargados y subencargados, con sus contratos?
4. ¿Se sabe dónde se procesa y almacena cada flujo y qué vía ampara una transferencia?
5. ¿Envía el diseño solo lo necesario y existe una alternativa si cambian las condiciones?

Si alguna respuesta es «no lo sabemos», el siguiente paso es averiguarlo antes de conectar datos reales. Al plantear un proyecto de IA aplicada podemos ayudarte a preparar ese mapa de flujos y la lista de preguntas para el proveedor y tu asesoría jurídica.