Qué datos no darle a un agente de IA

Un agente de código no manda «un trozo de contexto»: manda ficheros enteros, salidas de terminal, variables de entorno que aparecen por pantalla y todo lo que lee mientras investiga —lo que de verdad ocupa su contexto rara vez es lo que tú crees—. Eso convierte cualquier proyecto de cliente en una transferencia de datos a un tercero, con las consecuencias legales que trae (RGPD, encargado de tratamiento, ubicación de los servidores) y con una lista clara de cosas que no deberían salir de la red del cliente: datos personales de sus usuarios, volcados de base de datos de producción, credenciales, claves y contratos. El malentendido más caro es creer que .gitignore protege: solo dice a git qué no versionar, no impide que el agente abra el fichero y lo mande. Los límites de verdad son técnicos y contractuales a la vez: denegar rutas y comandos con permisos, aislar en sandbox, poner guardarraíles, anonimizar o generar datos de prueba, y dejar por escrito con el cliente qué herramientas de IA se usan y con qué alcance. Súmale que el contenido que el agente lee puede volverse contra ti vía inyección de prompts. El modelo local es una opción legítima cuando el dato no puede salir, y una excusa cuando se usa para no tener la conversación incómoda. Los casos ya existen —los informes de Cyberhaven sobre datos corporativos pegados en herramientas de IA, la filtración de Samsung— y por eso esto va en el mismo cajón que la seguridad del código: checklist antes de abrir el agente en un repo ajeno, no después.