Anatomía de una fuga hacia la IA: tres historias de nuestra telemetría

Tres incidentes, tres lecciones, ningún nombre de cliente

Lo más útil que podemos publicar no es un benchmark ni un libro blanco. Es lo que ocurre realmente dentro de organizaciones reales la semana siguiente a activar Zeuslock. Las tres historias siguientes son casos compuestos construidos a partir de patrones que vemos repetirse en la telemetría de nuestros clientes. Sectores, plantillas, geografías y detalles se han modificado lo suficiente como para que ninguna organización sea identificable. En cambio, la lógica de detección y la respuesta humana se relatan tal y como sucedieron.

Cada historia sigue el mismo esquema: el contexto (quién estaba haciendo qué), lo que vimos (el hallazgo, con una vista previa enmascarada), lo que se disparó (qué detector, qué severidad, qué acción) y lo que el cliente hizo después (el cambio de política o de proceso que cierra el bucle). El objetivo no es señalar a los empleados. En todos los casos la persona simplemente intentaba ir más rápido en su trabajo. El objetivo es mostrar la brecha entre intención y exposición, y a qué se parece un control útil en el momento adecuado.

Historia 1: una clave AKIA, una traza de error y una sesión honesta de depuración

Un ingeniero de backend en una fintech serie B llevaba tres horas con un incidente en producción. El pipeline de despliegue se había atascado en un error de permisos y el equipo estaba quemando la mañana para entregar un parche antes de la apertura de los mercados europeos. El ingeniero copió la traza de CloudWatch que fallaba, abrió Microsoft Copilot dentro de VS Code y planteó la pregunta obvia: ¿por qué falla esto y qué permiso debo añadir a este rol IAM?

El bloque pegado tenía unas 60 líneas. En la línea 14 estaba escondido el AKIA literal usado por el runner de despliegue, con la forma AKIAIO******************, junto con la región, el ARN del rol y suficiente contexto como para que la credencial fuera trivial de usar si llegaba a salir de la empresa. El ingeniero no había copiado un secreto a propósito. Había copiado una traza que contenía un secreto.

La extensión de navegador y el agente de escritorio de Zeuslock se dispararon en milisegundos. El detector activado fue api_key:aws en la capa regex estricta (prefijo AKIA más 20 caracteres en base32), confirmado en menos de 80 ms por el modelo ML alojado en la UE con una puntuación de confianza alta. Severidad: crítica. Acción en la política de desarrolladores vigente en ese momento: Anonimización. El texto llegó a Copilot con la clave sustituida por un señuelo estructuralmente válido y el resto de la traza intacto. Copilot produjo igualmente una respuesta perfectamente útil sobre el permiso s3:PutObject que faltaba, porque el modelo nunca necesitó la clave real para razonar sobre IAM.

La Consola de Operador registró el incidente con atribución completa: usuario, máquina, URL de origen (github.com/copilot) y un hash con sal del secreto en claro, para que el equipo de seguridad pudiera correlacionar con AWS CloudTrail sin almacenar nunca el secreto. La respuesta del responsable de seguridad fue doble. Primero, la clave AKIA se rotó en la misma hora por higiene, aunque nunca hubiera salido del equipo. Segundo, la política de desarrolladores pasó de Anonimización a Bloqueo para la familia api_key:* en todos los grupos de ingeniería, y se añadió un hook pre-commit con gitleaks en cada repositorio de backend, de modo que la misma clase de fuga se atrapase una capa antes, en el git commit en lugar del pegado en una herramienta de IA.

Historia 2: 200 líneas de historial de cliente, pegadas en ChatGPT para «análisis de sentimiento»

Una analista de soporte senior en un retailer online mid-market estaba preparando el resumen semanal de escalados para el responsable de atención al cliente. La herramienta interna habitual iba lenta ese día, así que la analista exportó la última semana de hilos de reclamación del CRM a un CSV, abrió ChatGPT, pegó las 200 líneas y pidió: resume las tres principales reclamaciones por tema y dime cuáles parecen más enfadadas.

El bloque contenía 47 direcciones de correo de clientes, 31 direcciones postales en Francia, España y Alemania, el historial completo de líneas de pedido para cada reclamación y, en 12 casos, un fragmento de número de tarjeta con la forma **** **** **** 4242. Desde el punto de vista del RGPD era, francamente, una transferencia ulterior ilícita a un subencargado de tratamiento estadounidense fuera de la cadena de tratamiento declarada. La analista no era malintencionada. ChatGPT era más rápido que la herramienta interna y nadie le había explicado lo contrario de forma concreta.

Zeuslock disparó tres detectores en una sola entrega: email (47 hits, alta confianza), address (31 hits, alta confianza, sensible a la localización FR / ES / DE) y credit_card_partial sobre los fragmentos de PAN enmascarados. Severidad: alta. Acción en la política del equipo de soporte: Anonimización. El prompt que llegó realmente a ChatGPT se reescribió al vuelo: cada correo se convirtió en user1@example.com, user2@example.com y así sucesivamente, cada dirección se transformó en una dirección europea estructuralmente válida pero ficticia en el mismo país, y cada PAN parcial se convirtió en un PAN falso pero válido por Luhn. El texto de las líneas de pedido y las frases de reclamación no se tocaron. ChatGPT produjo un resumen perfectamente útil — los tres temas principales fueron retrasos de entrega, inconsistencia de tallas en una gama concreta y un bug de visualización en la facturación — porque ninguno de esos razonamientos necesitaba datos personales reales.

El cliente hizo un cambio pequeño pero de alto apalancamiento. No bloqueó ChatGPT para el equipo de soporte. Añadió una sección de una página al manual de usuario interno titulada «el patrón seguro», con una captura del preview anonimizado de Zeuslock y la frase: así es como llegaba realmente tu prompt al modelo, la respuesta siguió siendo útil, así que puedes seguir usando este patrón. El cumplimiento conductual subió porque el equipo vio, visualmente, que el comportamiento protector no le costaba nada.

El comportamiento que buscamos no es «dejar de usar la IA». Es «usar la IA con libertad, sobre una carga útil de la que ya se han quitado las cosas que jamás deberían haber estado ahí». La anonimización es el puente.

Historia 3: 400 líneas de PI, consejos de refactor y una app de escritorio

Un ingeniero senior en una healthtech europea estaba reescribiendo un módulo en el corazón del motor de scoring propietario que, siendo francos, es la única razón por la que la empresa tiene inversores. El ingeniero abrió la app de escritorio de Claude y pegó un módulo Python de 400 líneas para pedir sugerencias de refactor, en particular cómo aplanar un conjunto de condicionales anidados para hacerlo más testeable. El módulo contenía los pesos de scoring reales, los nombres de funciones que se corresponden directamente con la metodología patentada y el prefijo de paquete interno que solo existe dentro de esa empresa.

Esta es la clase de fuga más difícil de atrapar. No hay regex para «nuestra propiedad intelectual». La detección de Zeuslock que funcionó aquí fue por capas: una heurística genérica source_code marcó la entrega como un gran bloque de Python con alta densidad sintáctica y bajo ratio de lenguaje natural, y un detector personalizado que el cliente había construido tres semanas antes — que coincidía con su prefijo de paquete interno y tres nombres de función reservados — elevó la severidad de media a crítica. Acción en la política del equipo propietario de la PI: Bloqueo. El agente de escritorio interceptó la entrega antes de que abandonara el equipo. Claude no recibió nada. El ingeniero vio una ventana modal que explicaba qué se había detectado, con un enlace a la página de política interna y un camino de un clic para pedir una excepción al equipo de seguridad si el refactor era realmente seguro de hacer fuera.

El cierre fue lo más interesante de los tres en términos operativos. En lugar de endurecer la política para todos, el cliente dividió la política de desarrolladores en dos perfiles. Los equipos que tocan el motor de scoring, las rutas de código patentadas y el pipeline de entrenamiento del modelo trabajan bajo un perfil estricto: source_code y el detector de PI personalizado están ambos en Bloqueo. Los equipos que entregan servicios utilitarios, tooling interno y el sitio público de marketing trabajan bajo un perfil más laxo: source_code se queda en Anonimización, para que sigan recibiendo ayuda de refactor sobre código en el que el coste de un pegado externo es esencialmente nulo. La división se publicó como una nota de política de un párrafo y se hizo aplicable a través de los grupos SCIM existentes, para que ningún ingeniero tuviera que recordar en qué modo estaba: el agente, sí, lo sabe.

Lo que estos tres casos tienen en común

Leídos juntos, los tres relatos riman más de lo que difieren. En todos los casos la persona estaba siendo productiva, no descuidada. En todos los casos el secreto o el dato personal era incidental respecto a la pregunta que se hacía — nadie pegó una clave para filtrar una clave, se pegó una clave porque venía adjunta al mensaje de error sobre el que de verdad se quería ayuda. En todos los casos el modelo habría producido la misma respuesta útil sobre una carga útil anonimizada o vacía. Y en todos los casos el arreglo duradero no fue un memorándum. Fue un cambio de política cableado en el agente, apoyado por un pequeño cambio de proceso cableado en el equipo.

Para poner cifras a lo que conviene hacer este trimestre:

1. Pase la familia api_key:* a Bloqueo para los grupos de ingeniería. La tasa de falsos positivos en los patrones de AWS, Stripe, GitHub, Slack y OpenAI es lo bastante baja para que Bloqueo sea adecuado a partir de la semana 3. Combínelo con un hook pre-commit en los repositorios que importan.
2. Mantenga la PII en Anonimización para los equipos no técnicos y documente el patrón seguro. Muestre el preview enmascarado. Muestre que el modelo sigue siendo útil. El cambio conductual ocurre cuando el comportamiento protector visiblemente no cuesta nada.
3. Construya al menos un detector personalizado para su propia PI. Tome el prefijo de paquete interno, los identificadores de patente, los nombres de función reservados. Hágale backtest sobre los últimos 30 días de incidentes en la Consola de Operador antes de pasarlo a Bloqueo. El detector que construya en una tarde atrapará una fuga que ninguna regex genérica de proveedor habría atrapado.
4. Divida la política de desarrolladores por equipo, no por herramienta. Los equipos propietarios de PI necesitan un perfil distinto de los equipos utilitarios. Cablee la división a través de sus grupos de identidad existentes, para que se aplique automáticamente cuando la gente entra, se mueve o sale.

Nada de esto requiere una herramienta nueva, un proceso nuevo o un memorándum al comité ejecutivo. Requiere mirar las tres filas del panel de incidentes que más le inquietaron este mes y ser honesto sobre qué modo de política las habría detenido. Para el detalle desde el lado del operador, consulte la guía configuración de políticas de detección y la referencia de detectores personalizados. Las tres historias de arriba empezaron en el mismo sitio que las suyas. Terminaron con un cambio de política lo bastante pequeño como para entregarse un viernes.