El modelo no es un lugar seguro para guardar secretos

La regla que todos aprenden a las malas: cada byte que metés en una llamada al modelo es potencialmente logueado, reproducido o devuelto en una respuesta. Si el modelo puede leerlo, el modelo puede decirlo. Si el modelo puede decirlo, un atacante puede extraerlo.

Modos de falla reales:

• Fuga por eco. Ponés el email de un cliente en el system prompt para personalización. Otro usuario pregunta "resumime lo que sabés de esta cuenta" y el modelo vuelca el email que vio.
• Fuga al proveedor. Muchos proveedores de modelos loguean los inputs para revisión de seguridad o fine-tuning. Aunque no lo hagan, tus inputs salen de tu red.
• Fuga cross-tenant. Un asistente multi-tenant trae contexto de la base de datos del tenant A y accidentalmente lo sirve al tenant B porque el contexto no estaba scopeado por llamada.

La regla de Atlas: clasificá tus datos antes de cablearlos. El modelo es un empleado junior rapidísimo con una cuenta pública de Twitter. No le digas nada que no twittearías.

Cuatro clases de datos

PII y secretos van a la bóveda. encriptada, audit-logged, nunca en el prompt. Si necesitás actuar sobre ellos, diseñá tools que hagan lookup por referencia (un id de token, no el token mismo) y ejecuten del lado confiable.

Tu ejercicio

A la derecha: seis piezas de datos, tres destinos. Conectá cada pieza a cada destino al que sea seguro mandarla. La bóveda siempre es segura. está encriptada y se queda en la nave. El modelo y el log externo no siempre.

Aprobás cuando tu set de aristas matchea exactamente el set seguro: sin conexiones seguras faltantes, sin extras inseguras.