Aunque un proveedor no use datos del cliente para entrenar, siguen abiertas preguntas sobre acceso, finalidad, retención, logs, memoria, subencargados, inferencias y eliminación.
«No utilizamos sus datos para entrenar nuestros modelos» es una cláusula o promesa relevante. Pero no debería utilizarse como atajo para cerrar una revisión de privacidad, confidencialidad o secreto.
Aunque el proveedor no incorpore los contenidos del cliente a un proceso de entrenamiento, la información puede seguir atravesando una cadena compleja: entrada, procesamiento, memoria, logs, observabilidad, subprocesamiento, retención, soporte, seguridad, backups y eliminación.
La pregunta correcta no es solo si se entrena. Es qué trayectoria sigue la información y qué puede ocurrir con ella en cada punto.
Entrenamiento es una finalidad posible, no toda la arquitectura de datos
El RGPD exige analizar tratamientos de datos personales atendiendo a finalidad, base jurídica, minimización, roles, seguridad, conservación y derechos, entre otras obligaciones cuando resultan aplicables.
El EDPB, en su Opinion 28/2024, aborda cuestiones específicas relativas a modelos de IA y datos personales. Ese marco confirma algo importante para la práctica: reducir la revisión a una pregunta binaria sobre training es demasiado poco.
Un proveedor puede no entrenar y, sin embargo:
- procesar el contenido para prestar el servicio;
- conservar temporalmente inputs y outputs;
- generar logs y metadatos;
- utilizar subencargados;
- permitir acceso de personal autorizado para soporte o seguridad;
- crear memoria persistente por cuenta del cliente;
- producir inferencias a partir de datos de entrada;
- mantener copias residuales o backups;
- trasladar datos entre regiones o proveedores de infraestructura.
Cada una de esas operaciones puede requerir una respuesta distinta.
Confidencialidad y secreto tampoco terminan en el RGPD
No toda información sensible es dato personal. Una empresa puede introducir código, estrategia comercial, documentación técnica, información de clientes, precios, modelos financieros o conocimiento interno protegido por confidencialidad o por la Ley 1/2019 de Secretos Empresariales.
Por eso la arquitectura debe separar, al menos:
- datos personales;
- categorías especiales cuando existan;
- información confidencial contractual;
- secretos empresariales;
- información sometida a deberes profesionales;
- materiales sujetos a licencia o restricciones de uso.
Un mismo prompt puede contener varias de esas capas al mismo tiempo.
Las preguntas que deben venir después de «no entrenamos»
¿Quién accede?
Hay que identificar proveedor, subprocesadores, soporte, seguridad y cualquier otro operador con acceso material o potencial al contenido.
¿Para qué se conserva?
La retención puede responder a prestación del servicio, prevención de abuso, facturación, seguridad, debugging o memoria del usuario. Cada finalidad debe distinguirse.
¿Durante cuánto tiempo?
No basta con una promesa genérica de borrado. Debe entenderse qué se elimina, de qué sistemas, con qué plazo y qué ocurre con backups o logs.
¿Qué se registra?
Un proveedor puede no conservar el contenido completo y sí metadatos, eventos, hashes, identificadores, tiempos o información de uso. La organización necesita saber qué evidencia existe y qué exposición crea.
¿Qué ocurre con la memoria?
La memoria persistente mejora continuidad, pero también puede ampliar superficie de acceso, retención y mezcla de finalidades. Debe gobernarse como una capa propia.
¿Cómo termina la relación?
La salida debe incluir supresión, revocación de credenciales, exportación cuando proceda y tratamiento de copias residuales.
Secreto significa arquitectura, no solo cláusula
Una obligación de confidencialidad puede ser necesaria y seguir siendo insuficiente si el diseño permite accesos innecesarios, mezcla de clientes, permisos demasiado amplios o retenciones incompatibles con la finalidad.
La protección efectiva necesita traducirse en medidas como:
- separación de entornos;
- minimización;
- control de permisos;
- propósito definido;
- límites de retención;
- trazabilidad;
- capacidad de revocación;
- gestión de incidentes.
La confidencialidad contractual y la arquitectura técnica deben coincidir.
Criterio H&C
La frase «no entrenamos con sus datos» responde a una pregunta concreta: una determinada forma de reutilización para entrenamiento. No responde automáticamente a las demás.
Nuestro criterio es reconstruir la trayectoria completa:
entrada → finalidad → acceso → procesamiento → memoria → logs → subprocesadores → retención → recuperación → salida/eliminación.
La Matriz de datos, logs y reutilización convierte esa trayectoria en preguntas verificables.
La revisión debe acabar en una decisión operativa
El objetivo no es producir una lista interminable de riesgos. Es decidir:
- qué información puede entrar;
- qué información debe quedar fuera;
- qué proveedor y configuración son aceptables;
- qué controles deben activarse;
- qué cláusulas faltan;
- qué retenciones y accesos deben limitarse;
- qué evidencias deben conservarse;
- qué ocurre al terminar.
Cuando una organización conoce esas respuestas, «no entrenamos» deja de ser una promesa tranquilizadora aislada y pasa a ocupar su lugar correcto: una pieza dentro de una arquitectura jurídica más amplia.
Fuentes y referencias
Fuentes primarias
- Reglamento (UE) 2016/679 · RGPD · Derecho vigente
- Ley 1/2019, de Secretos Empresariales · Derecho vigente