7 errores de privacidad de datos con agentes de IA que filtran en silencio los datos de tu empresa (y cómo evitarlos)

La mayoría de las fugas de datos de los agentes de IA no se deben a que el modelo memorice tu empresa en secreto. Provienen de errores de configuración y arquitectura que puedes nombrar y corregir. Los grandes: operar sobre una cuenta de nivel de consumidor cuyos ajustes predeterminados entrenan con tus entradas, dejar que un agente herede los amplios permisos de una persona, conectar un agente de cara al público a sistemas internos y dejar intacta la "tríada letal" (datos privados, contenido no confiable y una vía de envío externa) para que una sola inyección de prompt pueda leer tus datos y enviarlos por correo. Ese último patrón es exactamente cómo EchoLeak (CVE-2025-32711) expuso datos sensibles a través de Microsoft 365 Copilot a partir de un correo electrónico manipulado, sin que el usuario hiciera clic. Las soluciones no son exóticas, y casi todas son decisiones que se toman antes de que el agente se lance, no una lista de comprobación que se te entrega después de que algo se filtra.

Esta es la lista que repasamos antes de poner un agente que hemos construido dentro del stack de otra empresa, escrita para que un propietario no técnico pueda detectar los mismos errores en su propia configuración o en la de un proveedor. Si prefieres que mantengamos esta línea donde debe estar para ti, mira cómo gestionamos la gobernanza y el riesgo de la IA responsable. Todo lo que sigue es tuyo para usarlo de cualquier manera.

Primero, una distinción que casi todos los artículos sobre este tema difuminan, porque equivocarse en ella es el error cero. Hay dos formas completamente distintas en que los datos salen a través de un agente, y tienen soluciones completamente distintas:

• Manejo de datos por parte del proveedor. ¿El proveedor del modelo almacena o entrena con tus entradas? Esto es un contrato que firmas y un nivel de cuenta que eliges. Se resuelve con condiciones y configuración.
• Exfiltración en tiempo de ejecución. ¿Se puede engañar al agente, en el momento en que se ejecuta, para que envíe tus datos a un lugar al que no deberían ir? Esto se resuelve con arquitectura, no con un contrato.

Las cifras de las encuestas indican que los compradores lo perciben aunque no sepan nombrarlo. En la investigación de Cloudera con casi 1.500 líderes de TI sénior de 14 países, el 96% planea ampliar el uso de agentes de IA durante el próximo año, y sin embargo el 53% (más de la mitad) señala la privacidad de los datos como su principal obstáculo de adopción. Los siete errores que siguen son donde ese miedo se convierte en una fuga real, y donde vive la solución.

Error 1: ejecutar agentes de producción en cuentas de nivel de consumidor

Este es el error más barato de cometer y el más fácil de corregir. Alguien conecta un flujo de trabajo a una cuenta personal de ChatGPT o a una cuenta de consumidor de Gemini porque ya está ahí, y ahora los datos de tu negocio se rigen por condiciones de consumidor que nunca se pensaron para ellos.

La brecha entre los niveles de consumidor y de empresa es marcada. En el lado empresarial, el patrón es coherente entre proveedores: sin entrenamiento con tus datos de forma predeterminada, una ventana de retención corta para la monitorización de abusos y opciones más estrictas bajo petición. La API de OpenAI retiene los datos durante 30 días para la monitorización de abusos y luego los elimina, y no entrena con ellos de forma predeterminada. A partir del 14 de septiembre de 2025, Anthropic recortó la retención de registros de la API de 30 días a 7 días, y las entradas y salidas de la API nunca se usan para entrenamiento. La Vertex AI de Google (el nivel de empresa) es configurable sin uso para entrenamiento. En el lado del consumidor los ajustes predeterminados se invierten: el ChatGPT de consumidor almacena las conversaciones de forma indefinida a menos que las elimines, y la retención del Gemini de consumidor llega hasta 36 meses y puede usarse para mejorar productos.

La solución: pon cada agente de producción sobre una API de empresa o una cuenta de negocio, nunca un inicio de sesión personal. La tecnología es idéntica. Las condiciones no lo son, y las condiciones son toda la diferencia entre datos que permanecen gobernados y datos que en silencio se convierten en material de entrenamiento.

Error 2: permisos demasiado amplios que el agente hereda

La fuga en tiempo de ejecución más común no es astuta. A un agente se le entrega el acceso de un empleado, o peor, una clave de administrador, así que técnicamente puede ver todo lo que esa persona puede ver. Luego se le hace una pregunta, o se le engaña para que llegue a una, que va mucho más allá de su trabajo.

El Cloud Adoption Framework de Microsoft enuncia la regla con claridad: "Concede a los agentes acceso solo a las fuentes de datos específicas que requiere su función. No proporciones acceso amplio a todos los datos de la organización." Un agente de soporte no necesita tu sistema de nóminas. Un agente de programación de citas no necesita la base de datos de clientes. Cuando un agente actúa en nombre de una persona, debe heredar los permisos de esa persona pasando su identidad de forma segura, de modo que un agente de mesa de ayuda muestre a un empleado solo su propio registro de RR. HH., no el de todos.

La solución: dale a cada agente su propia identidad, con un alcance de mínimo privilegio, y haz que herede los permisos del usuario que actúa en lugar de cargar con un superconjunto permanente. La prueba es sencilla. Si mañana se engaña al agente, el daño queda limitado por el conjunto estrecho que se le concedió, no por todo lo que una sola cuenta con permisos excesivos podría alcanzar.

Error 3: agentes de cara al público conectados a datos internos

Un chatbot en tu sitio web y un agente que redacta informes internos son dos mundos de seguridad distintos, y la fuga ocurre en el momento en que alguien les deja compartir un backend. Un agente público recibe entradas de cualquiera en internet. Si ese mismo agente también puede consultar datos internos del negocio, has construido una puerta desde la web pública directamente hacia tus sistemas privados.

El framework de Microsoft traza aquí la línea más dura: "Los agentes de cara al público no deben acceder a datos internos del negocio." Mantén lo confidencial y lo público separados por una frontera física o lógica (su ejemplo usa grupos de gestión "corp" y "online" separados). El punto es que la frontera es estructural, no la esperanza de que el prompt aguante.

La solución: pon una frontera real entre los agentes que reciben entradas públicas no confiables y los agentes que tocan datos confidenciales. Si un único agente realmente debe hacer ambas cosas, ese es el diseño de mayor riesgo que puedes elegir, y necesita los controles que rompen la tríada de los errores siguientes, no solo un prompt de sistema cuidadoso.

Error 4: ignorar la tríada letal

Este es el error que convierte los tres primeros en una exfiltración real. Simon Willison, el experto independiente que acuñó el término "inyección de prompts", nombró la "tríada letal" para los agentes de IA: tres condiciones que, combinadas, permiten que una sola instrucción inyectada robe tus datos.

Cuando las tres están presentes, un atacante esconde una instrucción dentro del contenido no confiable. El modelo, en palabras de Willison, "seguirá con gusto cualquier instrucción que le llegue, provenga o no de su operador o de alguna otra fuente." Lee tus datos privados y los envía fuera, y nada en el prompt le dijo que no confiara en el correo.

La parte cruda, y la razón por la que esto es arquitectura y no un problema de ingeniería de prompts: "todavía no sabemos cómo prevenir esto de forma 100% fiable." Se han documentado exploits que afectaron a Microsoft 365 Copilot, al servidor MCP de GitHub y a GitLab Duo. En una semana de enero de 2026, se revelaron vulnerabilidades de inyección indirecta de prompts en cuatro herramientas de productividad con IA, todas con el mismo patrón de la tríada.

La solución: rompe una pata. Niega la vía de envío externa para que los datos robados no tengan adónde ir, o nunca dejes que un agente que lee contenido no confiable también tenga acceso a datos privados en el mismo contexto. No necesitas ganar la batalla imposible de atrapar cada inyección. Necesitas asegurarte de que incluso una inyección exitosa no tenga ninguna ruta de salida.

Error 5: tratar EchoLeak como un problema ajeno

Vale la pena nombrar un incidente real, porque "la tríada letal" suena abstracta hasta que la ves ejecutada. EchoLeak (CVE-2025-32711) fue un ataque sin clics sobre Microsoft 365 Copilot. Un atacante envió un correo electrónico manipulado. Copilot, haciendo su trabajo normal, procesó ese correo (contenido no confiable), tenía acceso a los datos internos del usuario (datos privados) y tenía una forma de enviar información fuera (comunicación externa). La instrucción oculta completó la exposición de datos sensibles sin ninguna interacción del usuario. Nadie hizo clic en nada.

El error aquí es asumir que una fuga requiere un empleado descuidado. EchoLeak no requirió ninguno. La defensa que importaba no era "capacitar al personal para detectar phishing", porque no había nada que un humano pudiera detectar. La defensa era arquitectónica: un agente que no puede a la vez leer contenido controlado por un atacante y exfiltrar no puede ser usado en tu contra de esta manera.

La solución: asume que el ataque sin clics es el modelo de amenaza, no la excepción. Si tu agente lee cualquier cosa que un externo pueda influir (correo, contenido web, archivos subidos, tickets) y también puede enviar datos fuera, tienes un agujero con forma de EchoLeak hasta que cierres una de esas dos capacidades o blindes la vía de envío.

Error 6: ninguna frontera de residencia o retención de datos

Algunas fugas no son exfiltraciones dramáticas, son una deriva lenta. Los datos terminan almacenados en una región que nunca acordaste, o quedan en registros más tiempo del que permite tu política, simplemente porque nadie fijó la frontera. El framework de Microsoft lo enumera como gobernanza central: identifica la ubicación de cada fuente de datos, tiempo de ejecución del agente y almacenamiento de salida, mantén los datos en regiones o en local que coincidan con tu política de residencia, y mantenlos cifrados en reposo.

La noticia tranquilizadora, que casi ningún artículo expone con claridad, es cuánto puedes fijar. El patrón empresarial entre proveedores es sin entrenamiento de forma predeterminada, más una ventana de retención corta, más garantías más fuertes bajo petición. Anthropic ofrece a las empresas que cumplen los requisitos un acuerdo de Retención Cero de Datos (ZDR), bajo el cual las entradas y salidas no se almacenan más allá de lo necesario para detectar abusos. OpenAI ofrece ZDR mediante un acuerdo negociado y residencia de datos. Ambos te permiten elegir dónde viven los datos. Autoalojar un modelo abierto (por ejemplo, con Ollama) mantiene los datos totalmente locales con retención cero por parte de terceros.

La solución: decide y documenta la frontera antes del lanzamiento. Qué región alberga los datos, cuánto viven los registros, si necesitas ZDR, y si la recuperación de datos sensibles debería ejecutarse en tu propia VPC o en local. El ZDR suele ser solo para API y negociado, y no cubre automáticamente cada producto a menos que lo añadas, así que el detalle importa.

Error 7: tratar la privacidad como una lista de comprobación que entregas

El último error es estructural. La mayoría de las guías, incluido el excelente framework de Microsoft, asumen que construirás y gobernarás el agente tú mismo, así que te entregan una pila de 3.000 palabras de identidades de Entra, etiquetas de Purview y grupos de gestión. Esa es la respuesta correcta para un gran equipo de TI. Para la mayoría de las empresas es una lista de comprobación que nadie tiene el tiempo ni la habilidad especializada para implementar por completo, así que se entrega a medias, y los huecos son exactamente donde se filtran los datos.

El error es tratar los controles como documentación en lugar de como una arquitectura de la que alguien es dueño de principio a fin. Una lista de comprobación que enumera "aislar datos confidenciales" y "restringir las integraciones externas a servidores MCP confiables" solo es tan buena como la persona que lo conecta todo, valida cada comunicación externa y levanta el plan de incidentes para desactivar un agente rápido cuando algo sale mal.

La solución: asegúrate de que una parte realmente sea dueña de la frontera, no solo del documento. O bien construyes la capacidad interna para implementar y mantener el stack completo, o tienes a un operador que diseñe estos modos de fallo para dejarlos fuera y los opere, con una frontera publicada que puedas señalar. El término medio equivocado es una lista de controles y nadie responsable de que se sostengan.

Cómo encajan los siete errores y soluciones

Aquí están los siete en un solo lugar, ordenados según si la solución es un contrato que firmas o una arquitectura que construyes. Esa división es la forma más rápida de saber qué equipo es dueño de cada uno.

Fíjate en que solo dos de los siete se resuelven con un contrato. Los otros cinco son arquitectura y propiedad, que es la parte que un PDF de buenas prácticas no puede hacer por ti. Es también la razón honesta por la que las fuentes autorizadas dejan un hueco: te dicen qué construir, no quién lo construirá correctamente dentro de tus sistemas específicos.

Qué nunca sale realmente, cuando la frontera está bien construida

Es fácil leer siete errores y concluir que los agentes de IA son un campo minado de privacidad. No lo son, cuando la línea se traza deliberadamente. Bajo condiciones de empresa, tus entradas no son datos de entrenamiento, y la retención es de días, no para siempre (7 para la API de Anthropic, 30 para OpenAI, eliminados después). Con ZDR, no se almacenan más allá de la detección de abusos. Con la residencia de datos fijada, permanecen en tu región. Con recuperación en VPC o en local, los datos sensibles nunca salen de tu perímetro en absoluto. Con redacción en la frontera, los campos que nunca deberían viajar se eliminan antes de enviar nada. Con un alcance de mínimo privilegio que hereda los permisos del usuario, el agente solo puede alcanzar lo que la persona que actúa ya podía alcanzar.

Esa es una frontera específica y defendible, y poder enunciarla con claridad es todo el objetivo. El peligro nunca fue que el modelo absorbiera tu empresa en silencio. Son los siete errores de configuración y arquitectura anteriores, cada uno de los cuales se puede prevenir antes de que el primer agente entre en funcionamiento.

Este es el trabajo que hacemos dentro de los stacks de otras empresas: elegir las condiciones, dar alcance a las identidades, aislar lo público de lo confidencial, romper la tríada y ser dueños de la frontera para que se sostenga. Si quieres que estos errores queden diseñados fuera de tus agentes antes de que toquen nada real, reserva una consulta gratuita abajo y trazaremos tu frontera juntos.