Qué datos no compartir con un agente de IA (y por qué)

Tu cliente te pasa un dump de la base de datos de producción para que reproduzcas un bug que solo aparece con datos reales.

Lo descomprimes en la carpeta del proyecto. Abres el agente. Le dices: “mira el CSV y dime por qué el importe sale a cero en estos pedidos”.

Once mil filas con nombres, DNIs, direcciones y correos acaban de salir de tu portátil.

No ha habido brecha, ni fallo de seguridad, ni nadie ha hecho nada raro. Has trabajado como trabajas todos los días. Y si ese cliente tuviera que responder mañana ante la Agencia Española de Protección de Datos por una transferencia internacional de datos personales sin base legal, el responsable del marrón tiene tu nombre en la factura.

Este post no va sobre si el código que escribe la IA es seguro. Eso ya lo conté en la seguridad de tu código en tiempos de IA, y va de SAST, SCA, dependencias envenenadas y secretos commiteados por error.

Este va de la otra mitad del problema, la que casi nadie mira: qué sale de tu máquina mientras trabajas. Qué se guarda al otro lado, cuánto tiempo, quién puede leerlo y qué tienes que tener firmado para que trabajar así no sea un problema tuyo.

Esto es lo que vas a encontrar aquí:

• Qué viaja de verdad en un prompt (spoiler: mucho más de lo que escribes)
• Cuánto guarda cada proveedor tus sesiones según el plan que pagues, con los números de la letra pequeña
• Los cuatro tipos de dato que no deberían salir nunca de tu red
• Cómo ponerle límites reales a un agente: carpetas, comandos y red
• Por qué tu .gitignore no protege nada y qué sí funciona
• Cuándo un modelo local es la respuesta y cuándo es una excusa cara
• Qué pide la AEPD en sus orientaciones sobre IA agéntica y qué dejar por escrito en el contrato
• Una checklist de diez puntos antes de abrir el agente en un proyecto de cliente

¿Qué viaja de verdad cuando le escribes un prompt a tu agente? ¶

Todo lo que el agente necesita leer para responderte. Y eso casi nunca es solo tu frase.

Cuando escribes tres líneas en la terminal, lo que sale hacia el proveedor del modelo es el paquete completo de contexto que el agente ha construido para poder trabajar. En un agente de código eso incluye, como mínimo, cinco cosas que tú no has tecleado:

1. El contenido de los ficheros que abre. No fragmentos: ficheros enteros, muchas veces varios seguidos mientras “explora” el proyecto.
2. La salida de los comandos que ejecuta. Un docker compose logs, un psql -c "select * from users limit 5", un env mal pedido. Lo que imprime la terminal entra en la conversación tal cual.
3. El historial de la sesión. Cada turno reenvía lo anterior. Ese .env que leyó en el minuto tres sigue viajando en el minuto cuarenta.
4. Tus ficheros de instrucciones. El AGENTS.md, el CLAUDE.md, las reglas del proyecto. Si ahí has escrito la URL del servidor de staging con credenciales “para que no me las pregunte”, felicidades: van en cada petición.
5. Metadatos del entorno. Rutas absolutas, nombre de usuario, sistema operativo, estructura de carpetas. La ruta /Users/marta/clientes/bancosantander-interno/ cuenta una historia por sí sola.

⚠️ El error mental más caro es pensar que el prompt es lo que escribes. El prompt es lo que el agente decide leer para contestarte, y esa decisión la toma él.

Los números respaldan que esto no es paranoia. El informe de adopción y riesgo de IA de Cyberhaven, construido sobre patrones de uso reales de 7 millones de trabajadores, encontró que el 34,8% de los datos corporativos que los empleados meten en herramientas de IA son sensibles, frente al 27,4% del año anterior y al 10,7% de dos años antes. ¿El tipo de dato sensible más común? Código fuente, con el 18,7% del total. Por delante de material de I+D (17,1%) y de datos comerciales (10,7%).

Y el trasvase va rápido: el mismo informe calcula que el 71,7% de las herramientas de IA corporativas presentan riesgo alto o crítico para los datos de la empresa.

Esto ya reventó una vez de forma sonada. En abril de 2023, ingenieros de Samsung Semiconductor pegaron código interno en ChatGPT para depurar errores en al menos tres ocasiones. Samsung prohibió la IA generativa a toda la plantilla semanas después. Ninguno de esos ingenieros estaba haciendo nada malo. Estaban depurando.

La diferencia es que ellos pegaban a mano. Tu agente lo hace solo, a razón de veinte ficheros por minuto.

Y no es un uso minoritario: la encuesta de desarrolladores de Stack Overflow de 2025 sitúa en el 84% los developers que usan o planean usar herramientas de IA, frente al 76% del año anterior. Curiosamente, la confianza va en dirección contraria: solo el 29% se fía de la exactitud de lo que produce la IA, frente al 40% de 2024. Desconfiamos del resultado, pero le seguimos dando acceso a la carpeta entera.

Guía interactiva gratis

Antes de decidir qué le das al agente, decide con qué cuenta entras

El curso tiene una parada entera sobre el presupuesto (gratis, API o suscripción) y otra sobre permisos por capas al soltar al modelo. Son las dos decisiones que gobiernan todo lo que viene después.

Entra en el curso gratis →

¿Cuánto tiempo guarda tus sesiones cada proveedor? ¶

Depende del plan que pagues, y la diferencia entre planes va de 30 días a 5 años.

Esta es la parte que casi nadie mira y donde está el 80% de la decisión. No es “¿es seguro usar IA?”, es “¿bajo qué contrato estoy usando esta IA en concreto hoy?”. El mismo modelo, la misma herramienta y el mismo prompt tienen consecuencias distintas según con qué cuenta hayas iniciado sesión.

Vamos con los números publicados, que son verificables y cambian con frecuencia.

Anthropic (Claude y Claude Code). La documentación de uso de datos de Claude Code separa dos mundos. En cuentas de consumo (Free, Pro y Max), si dejas activada la opción de mejorar los modelos, la retención es de 5 años. Si la desactivas, baja a 30 días. En cuentas comerciales (Team, Enterprise y API) el estándar son 30 días y no se entrena con tu código salvo que la organización se apunte de forma expresa al programa de partners de desarrollo. El zero data retention existe, pero no viene incluido en el plan Enterprise estándar: se habilita por organización tras confirmar elegibilidad.

Hay dos detalles que se escapan siempre. El primero: los transcripts que envías con /feedback, /bug o /share se guardan 5 años, independientemente de tu plan. El segundo: tu propia máquina guarda las sesiones en texto plano en ~/.claude/projects/ durante 30 días por defecto, ajustable con cleanupPeriodDays. El backup de tu portátil también es una copia de los datos de tu cliente.

OpenAI. Por la API, las entradas y salidas se conservan hasta 30 días para detección de abuso y no se usan para entrenar por defecto, según la documentación de controles de datos de la plataforma. El zero data retention está disponible para clientes de empresa que lo soliciten y cumplan requisitos, y solo en endpoints elegibles. En ChatGPT de consumo, las reglas son otras y dependen de la configuración de la cuenta.

GitHub Copilot. Aquí la línea entre planes es la más nítida del mercado. Para Copilot Business y Enterprise, GitHub no retiene ni registra prompts ni sugerencias una vez procesada la respuesta, y no usa esos datos para entrenar. En las cuentas individuales, los prompts y la telemetría sí se retienen por defecto para mejorar los modelos, con opción de desactivarlo en los ajustes de la cuenta.

Cursor. Con Privacy Mode activo, Cursor mantiene acuerdos de retención cero con los proveedores de modelos y no entrena con tu código. Con un matiz importante que su propia documentación explica: al indexar tu repositorio, el código sube troceado al servidor para calcular embeddings. El texto plano se descarta al terminar la petición, pero los embeddings y metadatos (hashes, nombres de fichero ofuscados) sí se almacenan en base de datos. Privacy Mode no significa que nada salga de tu máquina.

Ahora la parte incómoda, y la razón por la que esta tabla no es una garantía: una política de retención es una promesa comercial, no una ley de la física.

En mayo de 2025, un tribunal de Nueva York ordenó a OpenAI preservar y segregar los logs de salida que de otro modo se habrían borrado, dentro del pleito con The New York Times. Es decir: la política decía 30 días, y una orden judicial la sobrescribió. Meses después el tribunal levantó esa obligación de preservación a futuro, pero para entonces ya se había ordenado la entrega de 20 millones de conversaciones a los demandantes.

🔑 La retención de tu proveedor puede cambiar por un cambio de términos, por una adquisición o por un juez de otro país. Lo único que controlas de verdad es lo que decides no enviar.

¿Qué cuatro tipos de dato no deberían salir nunca de tu red? ¶

Credenciales vivas, datos personales de terceros, material ajeno bajo NDA y datos de categorías reguladas. Estos cuatro no admiten matices de plan ni de proveedor.

El resto es negociable y depende de tu contrato. Estos cuatro, no.

1. Credenciales vivas. Claves de API de producción, tokens de acceso, cadenas de conexión con contraseña, certificados privados, claves SSH, secretos de firma de JWT. La regla es simple: si con eso alguien puede hacer algo en un sistema que existe, no entra en el contexto. Y si entra por accidente, no se borra el mensaje: se rota la credencial. Un secreto que ha viajado en un prompt es un secreto quemado, esté guardado 30 días o cero.

2. Datos personales de terceros. Todo lo que identifique a personas que no son tú: dumps de base de datos, exports en CSV, logs con correos e IPs, capturas de un panel de administración con nombres reales, tickets de soporte. Aquí no estás arriesgando tu propiedad intelectual, estás tratando datos de gente que no te ha dado permiso para nada. Si necesitas datos para reproducir un bug, genera datos falsos o anonimiza antes. Un faker bien usado te ahorra una notificación de brecha.

3. Material de terceros bajo acuerdo de confidencialidad. El código propietario de tu cliente, sus contratos, su tabla de precios, su roadmap, el informe de la due diligence. Aquí el problema no es técnico: es que probablemente firmaste un NDA que dice que no lo compartes con terceros, y el proveedor del modelo es un tercero. No hay configuración que te salve de un incumplimiento contractual.

4. Datos de categorías especiales y sectores regulados. Salud, biometría, orientación sexual, afiliación sindical, convicciones religiosas (el artículo 9 del RGPD los llama categorías especiales por algo), datos de menores, datos de tarjeta bajo PCI DSS. Si tu proyecto toca esto, la conversación no empieza en “qué agente uso”, empieza en el registro de actividades de tratamiento.

La AEPD tiene una versión de esta lista para el ciudadano de a pie, el decálogo Cuidado con lo que le confIAs, que insiste en no compartir datos personales ni información sensible y en no usar el correo profesional para experimentar con estas herramientas. Si eso se le pide a alguien que solo quiere que le redacten un correo, hazte a la idea de lo que se te pide a ti, que le estás dando acceso a un repositorio entero.

Fíjate en un patrón: tres de los cuatro no son tuyos. Son de otro. Y esa es la diferencia entre un susto y una demanda.

¿Cómo se le ponen límites reales a un agente? ¶

Con reglas de permisos en un fichero de configuración, no con instrucciones en lenguaje natural.

Aquí está el malentendido que más veces he visto, y que ya conté desde otro ángulo en los errores comunes al construir un agente de IA: escribir “NUNCA leas ficheros .env” en el CLAUDE.md y quedarte tranquilo.

Eso no es un límite. Es una sugerencia educada a un sistema probabilístico.

Un límite de verdad tiene tres ejes, y conviene pensarlos por separado.

Carpetas: qué puede leer. El agente trabaja en un directorio y solo debería ver lo que necesita. En Claude Code las reglas de permisos van en .claude/settings.json y se evalúan en orden deny → ask → allow, de modo que un deny gana siempre:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(~/.ssh/**)",
      "Read(./data/dumps/**)"
    ]
  }
}

Un detalle que la documentación deja claro y que ahorra sorpresas: una regla Read deniega también la edición sobre esa ruta, pero Write y NotebookEdit no quedan cubiertos, así que para rutas que nadie debe tocar hace falta añadir la regla Edit equivalente. Y ojo con los enlaces simbólicos: las reglas se comprueban contra el enlace y contra su destino, de forma que un symlink que apunta a un fichero denegado queda denegado también.

Comandos: qué puede ejecutar. Bloquear la lectura no sirve de nada si el agente puede lanzar cualquier cosa en la terminal. Merece la pena denegar de forma explícita las herramientas de red y los comandos que se llevan datos fuera:

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(scp *)",
      "Bash(git push *)"
    ],
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint)"
    ]
  }
}

Red: hacia dónde puede salir. La documentación de permisos avisa con toda claridad de que restringir WebFetch no basta: “si Bash está permitido, Claude todavía puede usar curl, wget u otras herramientas para alcanzar cualquier URL”. El filtrado por URL dentro de un comando de shell es frágil (basta un redirect, una variable o un espacio de más para saltárselo), así que el orden correcto es bloquear las herramientas de red en Bash y luego abrir dominios concretos con WebFetch(domain:github.com).

En otras herramientas el mecanismo cambia de nombre pero la idea es la misma. GitHub Copilot tiene content exclusion, que acepta patrones fnmatch y se configura por repositorio, organización o empresa — con dos límites que conviene conocer: solo está disponible en Business y Enterprise, y no se aplica a enlaces simbólicos ni a repositorios en sistemas de ficheros remotos. Cursor tiene su .cursorignore y el Privacy Mode.

Esto tiene nombre propio en las orientaciones de la AEPD, y es el mismo que usan los militares: aplicar el principio need to know. En sus palabras, para cada tratamiento “debe estar claramente definido qué servicios y repositorios de datos pueden ser accedidos por los agentes y deben garantizarse la eficacia de tales restricciones de acceso”.

Fíjate en las cuatro últimas palabras, porque son las que separan un límite de una intención.

💡 Regla práctica: si el límite no está en un fichero de configuración que puedas enseñar en una auditoría, ese límite no existe.

¿Por qué tu .gitignore no protege tus secretos del agente? ¶

Porque .gitignore le habla a git, y el agente no es git.

Esto suena obvio escrito así, y aun así es el fallo más repetido del sector. La lógica intuitiva dice: “el .env está en el .gitignore, luego está protegido”. Y no. .gitignore decide qué ficheros entran en un commit. No decide qué ficheros puede abrir un proceso que se ejecuta en tu máquina con tu usuario.

No es una interpretación mía. En marzo de 2026 se abrió el issue #34456 en el repositorio de Claude Code con el título, sin matices, de que Claude ignora .gitignore y lee claves secretas del .env. Se cerró como not planned. El comportamiento no es un bug: es que ese fichero nunca fue un mecanismo de control de acceso.

El segundo escalón del mismo error es inventarse un .claudeignore porque suena a que debería funcionar. Hay otro issue abierto precisamente porque ese fichero se ignora en silencio. Y en el issue #52182 alguien documentó el caso completo: el fichero estaba en .gitignore, estaba en .claudeignore, el CLAUDE.md decía “nunca leas ficheros .env”… y el agente ejecutó cat backend/.env desde Bash en modo auto-aprobar. Contraseña de base de datos, SECRET_KEY y ENCRYPTION_KEY dentro del contexto. Toca rotar en desarrollo y en producción.

Lo que sí funciona son las reglas deny que has visto en la sección anterior. Y conviene entender hasta dónde llegan, porque la propia documentación es honesta al respecto:

Las reglas deny de Read y Edit se aplican a las herramientas de fichero integradas y a los comandos de fichero que Claude Code reconoce en Bash, como cat, head, tail y sed. No se aplican a subprocesos arbitrarios que leen o escriben ficheros de forma indirecta, como un script de Python o de Node que abre ficheros por su cuenta.

Traducido: la regla deny cubre las vías normales, incluidos los comandos de shell habituales. Lo que no puede cubrir es un python leer.py que abre el fichero por dentro, porque desde fuera eso es un proceso cualquiera. Para eso hace falta cumplimiento a nivel de sistema operativo, que es lo que hace el sandbox.

Aquí es donde cobra sentido lo de garantizar la eficacia de la restricción que pide la AEPD. Un .gitignore es una restricción declarada; una regla deny es una restricción que se comprueba; el sandbox es una restricción que impone el sistema operativo. Las tres se parecen sobre el papel y solo dos se sostienen delante de alguien que te audite.

Y de ahí sale la única defensa que no depende de la buena voluntad de ninguna herramienta: que el secreto no esté en la carpeta. Un gestor de secretos que inyecta variables en tiempo de ejecución, credenciales de desarrollo distintas de las de producción, y dumps de datos fuera del árbol del proyecto. Si el fichero no está donde el agente trabaja, ninguna configuración tiene que salvarte.

Dónde está tu línea roja

El semáforo para decidir qué le delegas y qué no

Todo este post dibuja un borde: qué entra en el contexto y qué se queda fuera. En este audio premium está el semáforo completo para decidir qué delegas — verde para lo mecánico, ámbar para lo que tú accionas, rojo para autenticación, pagos y datos sensibles — junto a los otros cuatro efectos colaterales de meter la IA en el día a día.

Ver el semáforo entero →

Audio premium · Acceso con suscripción Web Reactiva Premium

¿Cuándo un modelo local es la respuesta y cuándo es una excusa? ¶

Es la respuesta cuando el dato no puede salir por obligación legal o contractual. Es una excusa cuando lo usas para sentirte a salvo mientras el trabajo de verdad lo sigues haciendo en la nube.

El argumento a favor es sólido y no lo voy a discutir: si el modelo se ejecuta en tu máquina, el prompt no cruza ninguna frontera, no hay transferencia internacional, no hay encargado del tratamiento nuevo y no hay política de retención que revisar. Para datos de salud, para categorías especiales o para un cliente que tiene prohibido por contrato que su código salga de su red, esa es la conversación completa.

Y lo dice el regulador con una frase que vale su peso en oro cuando te toque justificarlo por escrito: “Cuando un agente de IA se ejecute de forma totalmente local no cabría más análisis de la responsabilidad”. Todo el análisis de encargados, subencargados y transferencias que ocupa la sección siguiente desaparece de un plumazo. Ese es el premio, y es grande.

Ahora las tres trampas.

Trampa 1: confundir local con “de código abierto en la nube”. Ejecutar un modelo de pesos abiertos en la infraestructura de otro no es lo mismo que ejecutarlo en tu portátil. Es exactamente el mismo tratamiento de datos que con cualquier otro proveedor, solo que con menos documentación de cumplimiento. Lo detallo con los modelos concretos y sus condiciones en modelos de Ollama Cloud en 2026: “Ollama” no es sinónimo de “local”.

Trampa 2: el modelo local como coartada. El patrón es este. Montas un modelo pequeño para “las cosas sensibles”. A la media hora te atascas, el modelo pequeño no llega, abres el agente de siempre y le pasas el mismo fichero. Has pagado el coste de calidad del modelo local y no te has llevado ninguna de las garantías. Si vas a trabajar con datos que no pueden salir, la restricción tiene que ser dura: sin fallback, o con un fallback sobre datos ya anonimizados.

Trampa 3: creer que local significa seguro. Un modelo en tu máquina no tiene retención en la nube, cierto. Pero sigue teniendo prompt injection, sigue pudiendo ejecutar comandos si le das permisos y tu disco sigue sin estar cifrado si no lo has cifrado. Local resuelve el problema de la transferencia. No resuelve el de los permisos.

Hay un camino intermedio que funciona mejor de lo que parece y que casi nadie usa: anonimizar en la entrada. Si el bug se reproduce con datos falsos, no necesitas los reales. Si necesitas un esquema de base de datos, manda el CREATE TABLE, no un SELECT *. Si necesitas entender un log, sustituye los identificadores antes de pegarlo. La mayoría de las veces el modelo no necesita el dato: necesita la forma del dato.

¿Qué tienes que poner por escrito cuando trabajas con un cliente? ¶

Que usas herramientas de IA, cuáles, con qué plan y con qué garantías. Y necesitas su autorización previa por escrito antes de la primera sesión.

Y no es una opinión de un tipo que escribe un blog. En febrero de 2026 la Agencia Española de Protección de Datos publicó Inteligencia Artificial agéntica desde la perspectiva de protección de datos, 76 páginas dirigidas justo a quien decide meter agentes en un tratamiento de datos personales.

Si has llegado hasta aquí, lo que dice te va a sonar. Sobre qué evaluar antes de elegir proveedor, la Agencia es explícita: “Es necesario evaluar el grado de cumplimiento normativo de las alternativas analizadas, en particular con relación, entre otros, al artículo 28 del RGPD, transferencias internacionales, conservación de datos”. Y si delegas el servicio entero en otra entidad, añade las obligaciones “relativa a la cadena de subencargados”.

Sobre transferencias no deja escapatoria: si no existen las garantías del Capítulo V del RGPD, “habrá que plantearse el rediseño de los agentes o la elección de otro tipo de IA agéntica”. Es decir, cambiar de herramienta.

Y sobre la retención, la medida que recomienda es exactamente la que has visto en la tabla de más arriba: una “política de ‘no log’ o política de cero retención de datos a nivel de componente”, además de plazos estrictos y de poder desactivar la memoria persistente.

Hay un concepto suyo que merece la pena robarle. Al problema de montarte tu propio flujo agéntico al margen de las políticas de la organización lo llaman BYOAgentic, heredero del BYOD de los móviles. Si eres el freelance que decide por su cuenta qué agente entra en el proyecto del cliente, el BYOAgentic eres tú.

Aquí es donde esto deja de ser una cuestión técnica. Si tú tratas datos personales por cuenta de tu cliente, en el reparto del RGPD tu cliente es el responsable del tratamiento y tú eres el encargado. El artículo 28 exige un contrato por escrito que fije objeto, duración, naturaleza y finalidad del tratamiento, tipos de datos y categorías de interesados.

Y aquí llega la parte que afecta directamente a tu agente: cuando tú, como encargado, metes un proveedor propio en la ecuación (el proveedor del modelo), ese proveedor es un subencargado. El artículo 28 es explícito: el responsable tiene que autorizar la subcontratación y poder oponerse a nuevos subencargados, y las mismas obligaciones tienen que trasladarse aguas abajo. Si el subencargado incumple, el encargado sigue respondiendo frente al responsable.

Traducido a tu situación real: meter Claude, Copilot o Cursor en un proyecto con datos de tu cliente sin decírselo es una subcontratación no autorizada. Con o sin brecha. Y las resoluciones recientes de la AEPD ya no se limitan a comprobar que el contrato existe: analizan su contenido.

Añade la capa de transferencias internacionales. La mayoría de estos proveedores están en Estados Unidos. El marco EU-US Data Privacy Framework sobrevivió al primer envite judicial (el Tribunal General de la UE desestimó el recurso en septiembre de 2025), pero hay un desafío de noyb en marcha y nadie serio recomienda apoyar toda la estrategia de cumplimiento en una única decisión de adecuación. Para proveedores no certificados, toca Cláusulas Contractuales Tipo y una evaluación de impacto de la transferencia.

Un apunte para no mezclar churras con merinas: desde el 2 de agosto de 2026 aplican las obligaciones del Reglamento de IA para sistemas de alto riesgo y las de transparencia del artículo 50, con la AESIA asumiendo potestad sancionadora y multas de hasta 35 millones de euros o el 7% de la facturación global. Eso regula el sistema de IA que tú construyes y pones en el mercado, no el hecho de que uses un asistente para programar. Son dos normas distintas y confundirlas te va a hacer perder tiempo en la reunión equivocada.

Las cinco cláusulas que deberías tener firmadas ¶

No soy abogado y esto no es asesoramiento legal — pero sí son las cinco cosas que un cliente serio te va a pedir y que es mejor que propongas tú:

1. Autorización expresa de uso de herramientas de IA, con el listado nominal de las que usas y el plan contratado en cada una.
2. Compromiso de plan comercial, no de consumo. Nada de cuentas Free o Pro personales sobre datos del cliente.
3. Prohibición explícita de tratar datos personales de producción en el entorno de desarrollo, con la obligación de anonimizar como contrapartida.
4. Régimen de subencargados: quiénes son, dónde están, con qué garantía de transferencia y con qué plazo de preaviso si cambias de proveedor.
5. Obligación de notificación: qué pasa y en cuánto tiempo avisas si un secreto o un dato personal acaba en un contexto por accidente.

Si al leer esto has pensado “esto en mi equipo no lo tiene nadie”, no eres una excepción. Es justo el tipo de conversación que acabamos teniendo cuando trabajamos con equipos que quieren adoptar IA en serio y descubren que la parte difícil no era elegir modelo.

Checklist antes de abrir el agente en un proyecto de cliente ¶

Diez minutos la primera vez, treinta segundos las siguientes.

• [ ] ¿Estoy en una cuenta comercial y no en mi Pro personal?
• [ ] ¿He revisado la configuración de entrenamiento y retención de esa cuenta este trimestre?
• [ ] ¿Hay algún dump, export o CSV con datos reales dentro del árbol del proyecto?
• [ ] ¿Los .env de este repo tienen credenciales de producción o solo de desarrollo?
• [ ] ¿Existe un .claude/settings.json con reglas deny para secretos, dumps y ~/.ssh?
• [ ] ¿Están bloqueadas las herramientas de red en Bash (curl, wget, scp)?
• [ ] ¿Sé dónde se guardan los transcripts locales y cuánto duran?
• [ ] ¿El cliente sabe por escrito que uso estas herramientas?
• [ ] Si mañana me pide el registro de subencargados, ¿lo tengo?
• [ ] Si un secreto acaba en un contexto hoy, ¿sé qué rotar y a quién avisar?

Las siete primeras las arreglas tú esta tarde. Las tres últimas necesitan un correo. Manda el correo.

TL;DR ¶

• 🔍 El prompt no es lo que escribes: es todo lo que el agente decide leer, ejecutar y arrastrar en el historial para contestarte.
• ⏳ La retención va de 30 días a 5 años según el plan. En Claude, las cuentas de consumo con mejora de modelos activada guardan 5 años; las comerciales, 30 días.
• 🚫 Cuatro cosas no salen nunca: credenciales vivas, datos personales de terceros, material bajo NDA y categorías especiales del artículo 9.
• 🔒 .gitignore no protege nada frente a un agente. El issue que lo reportaba se cerró como not planned. Lo que funciona son reglas deny en .claude/settings.json.
• 📄 Usar IA con datos de un cliente sin decírselo es una subcontratación no autorizada bajo el artículo 28 del RGPD, haya brecha o no. Las orientaciones de la AEPD sobre IA agéntica piden exactamente lo mismo que este post: acceso mínimo, supervisión humana y registro de lo que hace el agente.

Preguntas frecuentes ¶

¿Mi código se usa para entrenar modelos si uso Claude Code?
Depende del plan. En cuentas Free, Pro y Max se entrena si dejas activada la opción de mejora de modelos, y la retención sube a 5 años. En cuentas Team, Enterprise y API no se entrena con tu código bajo términos comerciales, salvo que la organización se apunte de forma expresa al programa de partners de desarrollo.

¿El .gitignore impide que el agente lea mi fichero .env?
No. .gitignore solo le dice a git qué no versionar; no restringe qué ficheros puede abrir un proceso en tu máquina. En Claude Code hay issues públicos documentando lecturas de .env pese a estar en .gitignore, cerrados como comportamiento esperado. La forma correcta es una regla deny de tipo Read(./.env) en .claude/settings.json.

¿Sirve de algo crear un fichero .claudeignore?
No es un mecanismo oficial de control de acceso y hay issues abiertos reportando que se ignora en silencio. Usa permissions.deny en .claude/settings.json, que sí está documentado y sí se aplica.

¿Una regla deny bloquea también los comandos de la terminal?
Cubre las herramientas de fichero integradas y los comandos de shell que la herramienta reconoce, como cat, head, tail o sed. No cubre subprocesos arbitrarios, como un script de Python que abre el fichero por su cuenta. Para eso hace falta el sandbox, que actúa a nivel de sistema operativo.

¿Puedo pasarle a un agente el dump de la base de datos de mi cliente?
No, salvo que esté anonimizado o el cliente lo haya autorizado por escrito con las garantías del artículo 28 del RGPD. Un dump con datos personales convierte al proveedor del modelo en subencargado del tratamiento, y esa subcontratación necesita autorización previa del responsable.

¿Qué hago si un secreto acaba dentro de una conversación con el agente?
Rotar la credencial de inmediato. Borrar el mensaje no basta: el secreto ya viajó, ya está en el historial de la sesión y puede estar en copias locales y en los logs del proveedor durante el periodo de retención que aplique a tu plan.

¿Un modelo local elimina el problema legal?
Elimina la transferencia de datos a un tercero, que es la parte más pesada del cumplimiento. No elimina la necesidad de controlar permisos, ni el riesgo de prompt injection, ni tu obligación de proteger el dato en reposo en tu propia máquina.

¿Ollama es local?
Ollama ejecutando modelos en tu máquina, sí. Ollama Cloud, no: ahí el modelo se ejecuta en infraestructura ajena y aplica el mismo análisis de tratamiento de datos que con cualquier otro proveedor.

¿Qué diferencia hay entre desactivar el entrenamiento y la retención cero?
Son dos controles independientes. Desactivar el entrenamiento evita que tus datos entren en el próximo modelo, pero pueden seguir almacenados durante el periodo de retención. La retención cero evita el almacenamiento en servidor, y suele estar reservada a cuentas de empresa que la solicitan y cumplen requisitos.

¿Qué dice la AEPD sobre el uso de agentes de IA?
En febrero de 2026 publicó un documento de 76 páginas, Inteligencia Artificial agéntica desde la perspectiva de protección de datos. Entre sus medidas: aplicar el principio need to know definiendo qué repositorios puede tocar el agente y garantizando la eficacia de esas restricciones, política de no log o cero retención a nivel de componente, plazos de retención estrictos, compartimentación de la memoria, supervisión humana efectiva y determinación clara de los roles de responsable y encargado en la cadena de suministro.

¿Me afecta el Reglamento de IA por usar un asistente para programar?
Como regla general, no. El Reglamento de IA regula los sistemas de IA que se ponen en el mercado y su clasificación de riesgo, no el hecho de usar un asistente en tu flujo de trabajo. Tus obligaciones al programar con IA sobre datos de clientes vienen del RGPD y de tu contrato, no del Reglamento de IA.

Fuentes ¶

• Uso de datos en Claude Code — Documentación oficial de Anthropic
• Configurar permisos en Claude Code — Documentación oficial de Anthropic
• Controles de datos en la plataforma OpenAI — Documentación oficial de OpenAI
• Content exclusion para GitHub Copilot — GitHub Docs
• Cyberhaven AI Adoption and Risk Report — Datos sobre uso de 7 millones de trabajadores
• Inteligencia Artificial agéntica desde la perspectiva de protección de datos — AEPD, V1.2 de febrero de 2026 (76 páginas)
• Responsable y encargado del tratamiento — Agencia Española de Protección de Datos
• Decálogo Cuidado con lo que le confIAs — AEPD
• Respuesta de OpenAI a las demandas de datos del NYT — OpenAI
• Issue #34456: Claude ignora .gitignore y lee claves del .env — Repositorio de Claude Code
• 2025 Stack Overflow Developer Survey — Adopción y confianza en herramientas de IA

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter