De Monitor a Bloquear: manual DLP de IA en 90 días

El despliegue es el producto

Una herramienta de DLP de IA encendida de un día para otro es una herramienta de DLP de IA apagada tres semanas después. Todos los operadores que hemos visto tener éxito a escala han seguido el mismo patrón: un piloto ajustado, un periodo largo en Monitor, un paso progresivo a Anonimizar, un cambio final a Bloquear en las categorías que importan y una revisión trimestral con el patrocinador ejecutivo. Noventa días desde la instalación hasta una postura de aplicación defendible.

Este manual es la versión que recorremos con los CISO de empresas europeas de 500 personas. Operador-directo: quién hace qué cada semana, cómo se ve el éxito, qué vigilar y qué decir en pasillo a RR. HH., legal, CFO y patrocinador ejecutivo. El patrón siempre es el mismo: confíe en los datos, avance despacio y la organización le seguirá.

Tabla de hitos a 90 días

Días 0-7: piloto solo en el equipo de seguridad

Instale la extensión de navegador Zeuslock y el agente de escritorio en las 20 personas del equipo de seguridad e IT. A nadie más. Todas las políticas en Monitor. Empuje vía Intune o MDM de Workspace para ejercitar el canal de despliegue que usará después, no una instalación manual. SSO/SCIM enlazados a Okta o Azure AD desde el día uno.

El objetivo de esta semana no es probar la detección. Es atrapar los falsos positivos que generan los hábitos de su propio equipo. Un ingeniero pega cadenas hex legítimas que parecen claves de API. Un administrador IT pega un identificador interno que coincide con la regex de DNI. Infraestructura pega UUID que se toman por tokens. Quiere ese ruido visible en la Consola del Operador antes de tocar a un solo usuario final.

Quién hace qué. El operador de Zeuslock (una persona nombrada, ingeniero de seguridad sénior) gobierna la consola. El responsable de IT gobierna el canal de despliegue. El CISO recibe briefing dos veces esa semana, no más.

Cómo es el éxito. Veinte instalaciones sanas, 100 % de cobertura de políticas, los diez primeros detectores en falsos positivos identificados, backlog de ajuste abierto. Horas-hasta-el-primer-ajuste registradas. En un piloto sano esta cifra está por debajo de 24.

Conversación a tener. Ninguna fuera de seguridad todavía. No preanuncie. Quiere primero la versión cruda del comportamiento de su equipo.

Días 8-21: 50 power users y la primera línea base

Amplíe a 30 desarrolladores y 20 analistas de soporte. 70 personas en la plataforma. Sigue en Monitor. Esta es la fase en la que empieza a producir los números que pilotarán el resto del despliegue.

Envíe una nota corta a los equipos de ingeniería y soporte. No un correo de marketing. "Hemos activado la detección de IA pero no el bloqueo. Sus prompts pasan con normalidad. Estamos midiendo. Hoy nada cambia. Avisaremos antes de cualquier cambio." Ese es todo el guion. Resista la tentación de añadir un gráfico.

Métricas a vigilar. Prompts-por-ETC-y-día, desglosados por departamento. Tasa de impacto en porcentaje. Top cinco tipos de detección. Latencia mediana añadida por la extensión (por debajo de 50 ms). Número de destinos de IA distintos — espere al menos tres desconocidos, entre ellos una pestaña de Claude que nadie pidió licenciar.

Cómo es el éxito. Un informe semanal limpio para el patrocinador ejecutivo el día 21, con volumen, tasa, top detectores y top destinos. Cero quejas, porque nada se bloquea. El CFO preguntará por el coste — tenga listo el precio por puesto y el encuadre de incidente-evitado.

Días 22-45: Monitor en toda la empresa y sprint de ajuste de falsos positivos

Despliegue la extensión y el agente a las 500 personas vía Intune, Workspace o GPO. Sigue en Monitor para todo el mundo. Tres semanas de visibilidad total antes de cualquier aplicación.

Mantenga una revisión semanal de falsos positivos con el operador y un ingeniero. Ajuste los diez detectores más ruidosos. Use sobreescrituras de detector personalizado para los identificadores propios — tickets internos, códigos de referencia de cliente, SKU de almacén — todo lo que se clasifica mal como tarjeta o identificador nacional. Backtestee cada sobreescritura contra el tráfico de la semana anterior antes de promoverla.

Si se salta el sprint de ajuste, cada falso positivo en la semana 6 se convierte en una queja al helpdesk y una reunión con RR. HH. Ajuste ahora y ahorrará cinco horas de reuniones después.

Conversación con RR. HH. Briefing de 30 minutos. Los empleados no ven nada — la protección es invisible en el endpoint. El dato solo se almacena en la Consola del Operador, restringida a operadores nombrados. Enséñeles la pista de auditoría. Confirme postura RGPD: residencia en la UE, derecho de supresión atendido, DPA archivado, ficha del registro redactada. Visto bueno por escrito antes de la semana 6.

Conversación con legal. Recorra la base jurídica (interés legítimo, test de ponderación documentado) y la notificación al comité de empresa. En España es el momento de informar al comité. Si lo salta, su despliegue muere en la semana 7.

Días 46-65: pasar financiero y PII de Monitor a Anonimizar

Active Anonimizar para credit_card, IBAN, email, teléfono, DNI/NIE, NIR (FR) y Steuer-ID (DE). La anonimización preservando formato envía al LLM un valor estructuralmente válido — un IBAN falso que pasa el dígito de control, un email falso en example.com — para que el razonamiento aguas abajo siga funcionando. El usuario obtiene su respuesta. El dato sale saneado.

Es la primera semana en que el usuario final puede teóricamente notar algo. La mayoría no lo nota, porque las respuestas del LLM siguen siendo útiles. Vigile las métricas de experiencia: ¿siguen útiles las respuestas? ¿se quejan los usuarios? ¿reescriben prompts para evadir la detección? La tasa de evasión es el aviso temprano. Por encima del dos por ciento su anonimización es demasiado agresiva.

Conversación con toda la plantilla. Una nota de una página. Ejemplos concretos, cero jerga. "Desde el lunes, cuando pegue un email de cliente en ChatGPT, será sustituido por user@example.com antes de salir de su equipo. La respuesta del modelo seguirá teniendo sentido. La alternativa es una notificación a la AEPD que preferiríamos no redactar." Fírmela el CISO junto con el director de RR. HH. La gente lee las notas conjuntas.

Métricas a vigilar. Tasa de anonimización por detector, tickets helpdesk etiquetados ai-dlp, intentos de evasión, satisfacción en pulse survey. La tasa de impacto debe caer en las categorías cambiadas.

Días 66-80: pasar credenciales y código fuente de Monitor a Bloquear

Active Bloquear para api_key (todas las variantes: AWS AKIA, Stripe sk_, OpenAI sk-, Azure, Google/Gemini, GitHub ghp_, Slack xoxb-, GitLab glpat-, npm npm_, Bearer), password, private_key, jwt, aws_access_key y github_token. Estas categorías no son negociables. No hay razón legítima de negocio para pegar una clave AWS en ChatGPT, nunca. El mensaje de bloqueo debe ser educado, nombrar lo bloqueado y enlazar al formulario de excepción.

Añada Bloquear para código fuente, acotado a grupos de ingeniería. El resto de la empresa no tiene por qué pegar código, e ingeniería necesita un flujo para los casos en que sí. La CLI de Zeuslock da al desarrollador una verificación local previa antes de pedir excepción.

Qué esperar. Pico medible de tickets al helpdesk en la semana 11. La mayoría no son quejas reales: son sorpresa más un primer bloqueo desconcertante. Forme al helpdesk en el flujo de excepción antes del pico, no después. Guion: "Sí, lo bloqueamos. Aquí tiene el formulario. El operador responde en cuatro horas hábiles. Si es urgente, aquí el teléfono de guardia." Los tickets vuelven a la línea base al final de la semana 12.

Conversación con el CFO. Nota corta cuando aterriza el primer bloqueo de credencial. "A las 14:03 de hoy la plataforma ha bloqueado una clave de acceso AWS de producción que un proveedor estaba a punto de pegar en ChatGPT. Es el tipo de incidente que le preguntará el comité de auditoría. Ya tenemos evidencia de que lo estamos evitando." Así se aprueba el presupuesto del año dos.

Días 81-90: revisar, reportar, renovar

Construya el deck trimestral. Seis diapositivas, no dieciséis. Incidentes evitados por categoría. Top tipos de detección. Top departamentos por tasa. Tasa de falsos positivos por semana, con la curva aplanándose tras el sprint de ajuste. Tiempo medio de resolución. Una diapositiva sobre los próximos 90 días.

Briefe al patrocinador ejecutivo en el idioma que le importa. No conteos de detección, encuadre de incidente-evitado. "En los primeros 90 días, la plataforma ha prevenido una estimación de doce incidentes que habrían requerido una notificación a la AEPD según el artículo 33 del RGPD, y tres incidentes con credenciales de producción que habrían exigido rotación de claves y comunicación a clientes." Elija las dos o tres cifras que el comité de auditoría le repetirá, y póngalas al frente.

Después decida qué viene. Políticas más estrictas en las categorías retenidas. Más detectores personalizados para los identificadores propios descubiertos en la semana 5. Extensión a filiales aparcadas. Integración del flujo de incidentes con el SIEM vía Splunk HEC o Microsoft Sentinel, enrutado de findings críticos a PagerDuty, resúmenes semanales en un Slack privado para el equipo operador.

La checklist

1. Días 0-7: 20 usuarios de seguridad/IT, Monitor, ajustar el ruido que genera su propio equipo.
2. Días 8-21: añadir 50 power users, línea base de prompts-por-ETC y tasa de impacto, primer informe semanal.
3. Días 22-45: desplegar a las 500 personas en Monitor, sprint de ajuste de falsos positivos, briefing escrito a RR. HH. y legal.
4. Días 46-65: cambiar PII y financiero a Anonimizar, enviar la nota sobria de una página firmada por CISO y RR. HH.
5. Días 66-80: cambiar credenciales y código a Bloquear, preparar al helpdesk antes del pico, briefing al CFO con la primera prevención real.
6. Días 81-90: entregar el deck de seis diapositivas al patrocinador ejecutivo, enmarcar incidentes evitados en lenguaje regulador, asegurar el próximo trimestre.

Para el detalle a nivel operador de cada fase, consulte la guía de políticas de detección y la checklist de despliegue.