Fuga de datos y privacidad

“Todo lo que pones en el prompt lo has dicho en voz alta en una sala que no controlas.”

Fuga de contexto: la más común

La fuga más frecuente es la más simple: todo lo que pones en el prompt puede salir del modelo. Los prompts de sistema se extraen. Los datos de un usuario, dejados en un contexto compartido, asoman en la respuesta de otro usuario. Documentos confidenciales enviados para resumir acaban citados ante alguien que no debería verlos. El modelo no tiene noción de «esta parte es secreta»; el contexto es el contexto.

Las defensas son cuestión de higiene, no de ingenio: nunca pongas en un contexto datos que el usuario que pregunta no esté autorizado a ver; aísla las sesiones para que los datos de un usuario no puedan contaminar los de otro; y da por hecho que tu prompt de sistema es público, porque un usuario decidido acabará extrayéndolo. Diseña como si el prompt fuera legible por cualquiera al que sirvas. Por qué tu prompt de sistema no es un secreto.↗

Extracción de datos de entrenamiento

Los modelos pueden memorizar fragmentos de sus datos de entrenamiento y, con el prompt adecuado, reproducirlos: secretos literales, datos personales, texto protegido por derechos de autor. Esto importa en dos direcciones. Si usas un modelo público, puede emitir contenido memorizado de su conjunto de entrenamiento. Si haces fine-tuning de un modelo con tus propios datos, ese modelo puede filtrar tus datos a cualquiera que lo consulte.

El problema de los terceros

Cuando llamas a la API de un modelo alojado, tu prompt sale de tu infraestructura. Es un evento de tratamiento de datos con peso jurídico: ¿a dónde van los datos, quién puede leerlos, se usan para entrenamiento, cuánto tiempo se conservan, y eso satisface los contratos y regulaciones a los que estás sujeto? «Enviamos registros de clientes a la API de un modelo» es una frase que tus responsables de privacidad y cumplimiento deben haber aprobado.

Posturas prácticas, de mayor a menor control: alojar tú mismo un modelo abierto para que los datos nunca salgan (la mejor propuesta en privacidad, pero con más coste operativo); usar un nivel de API empresarial con una garantía contractual de no entrenamiento y de residencia de los datos; o minimizar y anonimizar: no enviar nunca más de lo que la tarea exige, y retirar los identificadores antes de la llamada. La preferencia de SDEN por la infraestructura autoalojada existe en parte por esta razón. Minimización y anonimización antes de la llamada.↗

El cumplimiento es un requisito de diseño, no una ocurrencia tardía

Si tratas datos personales de personas en Europa, la IA no goza de ninguna exención regulatoria. El RGPD, el Reglamento de IA y las normas sectoriales (sanidad, banca) se aplican todas a los datos que haces pasar por un modelo. Las preguntas son las de siempre: cuál es la base legal, puedes atender una solicitud de supresión, dónde se tratan los datos, y puedes producir una pista de auditoría.

• Residencia de los datos: ¿puedes garantizar dónde se tratan y almacenan los datos?
• Derecho de supresión: si hay datos en un modelo al que se le ha hecho fine-tuning, ¿puedes eliminarlos de verdad? (Por lo general no, sin reentrenar.)
• Limitación de la finalidad: ¿se permite al proveedor del modelo entrenar con tus datos? Consíguelo por escrito.
• Auditabilidad: ¿puedes mostrar qué datos fueron a dónde, ante un regulador o un cliente?
• Minimización: ¿envías solo lo que la tarea requiere, o el registro completo porque era más fácil?

El control de privacidad más barato es el más antiguo: no recopilar ni enviar datos que no necesitas. Un modelo que nunca recibe un número de la seguridad social nunca puede filtrarlo. La minimización en la frontera supera a todos los controles posteriores.