La privacidad no es un formulario al final del proyecto. Es una decisión de arquitectura. Si no sabes qué datos entran y qué datos salen, no sabes qué riesgo estás asumiendo.
Qué datos salen
Cada llamada a un modelo envía datos a un proveedor. Puede ser el texto del usuario, el contexto recuperado, una imagen o un audio. En un sistema RAG, también salen los fragmentos de documentos que se recuperan. En un agente, salen los argumentos de las herramientas.
Haz un inventario. Qué datos personales, qué datos de cliente, qué secretos industriales y qué información regulada salen de tu infraestructura. Si no puedes responder a esa pregunta, no puedes evaluar el riesgo.
Minimizar
No envíes más de lo necesario. Si el modelo solo necesita el número de pedido, no mandes el historial completo. Si la tarea se resuelve con un resumen, no envíes el contrato entero. La minimización reduce coste, latencia y superficie de exposición.
También reduce el riesgo de que el modelo mezcle datos de distintos clientes. Un contexto demasiado amplio puede hacer que una respuesta incluya información que no correspondía.
Permisos y acceso
El sistema tiene que respetar los mismos permisos que una persona. Si un comercial no puede ver la ficha de otro cliente, el agente tampoco. Si un documento es confidencial, no puede aparecer en una respuesta a alguien que no tiene acceso.
La comprobación de permisos tiene que ocurrir antes de la generación, no después. Filtrar la respuesta cuando ya se ha generado es tarde. El contexto no debería haber llegado al modelo.
Retención y borrado
Los proveedores tienen políticas de retención distintas. Algunos guardan las peticiones durante un tiempo para abuso o mejora; otros permiten desactivarlo. Léelo antes de firmar. Y decide cuánto guardas tú: trazas, transcripciones, feedback, memoria.
La persona tiene derecho a saber qué se guarda y a pedir que se borre. Si la memoria del sistema guarda una preferencia o un dato personal, tiene que haber una forma de eliminarlo. Un sistema que no puede olvidar es un problema de cumplimiento.
Proveedor cerrado o abierto
Un modelo cerrado envía los datos al proveedor. Un modelo abierto puede ejecutarse en tu infraestructura y no salir de ella. Eso no lo hace automáticamente más seguro: sigues teniendo logs, accesos y errores. Pero cambia dónde está el dato y quién lo controla.
Para datos especialmente sensibles, un modelo local o en tu nube puede ser la única opción. Para otros, un proveedor con un contrato claro y una región concreta es suficiente. La decisión depende del tipo de dato, la obligación legal y el riesgo asumido.
Cumplimiento
En Europa, el RGPD y el Reglamento de IA añaden obligaciones. No necesitas convertirte en abogado, pero sí saber si el sistema entra en un uso de alto riesgo del anexo III, si trata datos sensibles o si toma decisiones automatizadas con efectos significativos. La documentación del sistema forma parte del producto.
Cumplir exige un registro de datos, permisos, retención, evaluación de riesgo y una persona responsable; una casilla no basta. Diseñar esto al principio abarata el proyecto.
Preguntas para el proveedor
Antes de firmar, pregunta. ¿Guardáis las peticiones? ¿Durante cuánto tiempo? ¿Las usáis para entrenar? ¿En qué región se procesan? ¿Quién es el subencargado? ¿Cómo se borran? ¿Qué cifrado hay en tránsito y en reposo? ¿Cómo notificáis un incidente? Las respuestas tienen que estar por escrito, no en una conversación comercial.
Si el proveedor no responde o responde con ambigüedades, eso también es una respuesta. Un sistema de IA que trata datos de clientes necesita un proveedor que sepa explicar su política. La velocidad de la demo no compensa un contrato que no puedes defender.
Fuentes
Sigue leyendo