Por qué el DLP de red falla frente a ChatGPT

El punto ciego que su proveedor de DLP nunca mencionará

Abra su SIEM y busque incidentes de DLP asociados a chatgpt.com, claude.ai o gemini.google.com en los últimos treinta días. En la mayoría de las organizaciones, el contador está en cero. No porque nadie haya pegado datos sensibles — la telemetría de uso indica que un trabajador del conocimiento medio entra a ChatGPT 22 veces por semana — sino porque la pila DLP es físicamente incapaz de ver dentro de la sesión. El handshake TLS finaliza, llega la respuesta en streaming, y el proxy se queda contando bytes que no puede analizar.

No es un problema de afinado. Es un problema de arquitectura. Cada categoría de DLP anterior a 2023 — Symantec, Forcepoint, Microsoft Purview usado a nivel de red, Netskope CASB, Zscaler — fue diseñada para una web que ya no existe. Veamos por qué, y qué entregan realmente las alternativas en producción.

TLS 1.3, fijación de certificados y el final del MITM

El DLP de pasarela clásico funciona terminando TLS en el medio. La autoridad certificadora corporativa se distribuye a todos los equipos gestionados, el proxy presenta un certificado falso para chatgpt.com, el navegador del usuario confía porque la raíz está instalada, y el proxy lee el contenido en claro. Este modelo aguantó una década. Está estructuralmente roto por tres razones.

Primero, TLS 1.3 con reanudación 0-RTT oculta gran parte del handshake — incluido el SNI en muchas configuraciones — detrás de datos tempranos. Segundo, los navegadores modernos incorporan una lista cableada de fijaciones de certificado para dominios de alto valor, y Chromium aplica cada vez más Certificate Transparency con validación SCT. Un proxy que inyecta su propio certificado provoca un fallo duro en esos dominios, no un aviso que el usuario pueda saltarse. Tercero, Encrypted Client Hello (ECH) se está desplegando ahora mismo en los servicios fronteados por Cloudflare. Cuando ECH sea obligatorio, el proxy ni siquiera podrá ver qué nombre de host se está contactando, mucho menos el contenido del cuerpo.

La aplicación de escritorio de OpenAI y la Consola de Anthropic fijan explícitamente sus llamadas de API de primera parte. Un intento de MITM no inspecciona en silencio — rompe la conexión. Los equipos de seguridad que intentan forzar este paso terminan con una avalancha de tickets de soporte y cero visibilidad.

El framing WebSocket mata la inspección de contenido aun cuando el MITM funcione

Supongamos por un momento que usted consigue terminar TLS en su propio proxy. Aun así no podrá leer la conversación. ChatGPT y Claude no envían una petición y reciben una respuesta JSON. Abren un WebSocket persistente (o un flujo Server-Sent Events) en el mismo canal TLS y intercambian tramas binarias que llevan tanto el prompt del usuario como la respuesta en streaming, token a token.

La mayoría de los motores DLP de proxy ni siquiera parsean tramas WebSocket. Los que lo hacen aplican coincidencia de patrones sobre un framing opaco sin entender el protocolo conversacional — ven un blob de bytes, se pierden el límite del prompt, y o dejan pasar todo o bloquean todo. Lo mismo aplica al transporte gRPC-Web de Gemini. El streaming es la UX por defecto de la IA moderna, y el streaming es exactamente lo que el DLP de pasarela nunca se diseñó para leer.

La trampa de "bloqueamos el dominio y listo"

La primera reacción de un equipo de seguridad saturado es la regla de cortafuegos: bloquear chat.openai.com en la salida. Es el equivalente cibernético de cerrar la puerta principal mientras se dejan todas las ventanas abiertas. Tres cosas pasan en una semana.

• Los empleados se pasan al móvil. Los 22 prompts por semana se convierten en 22 prompts por semana en un teléfono personal, fuera de la red, sin ningún registro.
• El shadow AI explota. La gente abre cuentas personales con correos personales y usa herramientas que el equipo de seguridad nunca ha oído nombrar — DeepSeek, Poe, You.com, Le Chat de Mistral, una docena de wrappers de ChatGPT.
• El negocio exige una excepción. Marketing, jurídico, ingeniería argumentan — con razón — que necesitan la herramienta. TI concede excepciones por usuario y la política se desmorona.

Bloquear el dominio crea la ilusión de control mientras hace que la fuga real sea más difícil de ver. La AEPD, el BfDI y el ICO han publicado orientaciones que recuerdan que un uso no supervisado es una postura de cumplimiento peor que el uso supervisado, incluso cuando este último cruza técnicamente una frontera.

CASB: mejor, con un agujero del tamaño de "cada nueva herramienta de IA"

Las plataformas CASB (Netskope, Zscaler, Microsoft Defender for Cloud Apps) mejoraron la situación al volverse nativas de la nube. Tienen integraciones API con el SaaS sancionado, pueden aplicar política a tenants de OpenAI Enterprise, y entienden más del handshake moderno que las cajas heredadas. Para ChatGPT Enterprise y Microsoft Copilot para M365, un CASB hace trabajo real.

El agujero es la cola larga. CASB exige que el proveedor haya escrito un conector para esa herramienta en concreto. No hay conector Netskope para Le Chat de Mistral en su nivel gratuito, ni política Zscaler para una instancia Ollama auto-alojada en el portátil de un desarrollador, ni visibilidad de Defender sobre las diecisiete extensiones de navegador de ChatGPT que un empleado instaló. Los proveedores CASB lo llaman "modo Universal" o "cobertura cualquier app", y casi siempre significa heurísticas de patrón de tráfico, no inspección de contenido. Usted ve que algo fue a algún lugar con pinta de IA; no ve qué había en el prompt.

Sume la latencia. CASB en modo inline enruta cada sesión de navegador a través de un PoP del proveedor. Para un usuario de Madrid consultando Claude en us-east-1, es una penalización medible sobre una respuesta en streaming ya sensible a la latencia. Los usuarios lo notan. Los usuarios buscan atajos.

Aislamiento de navegador: funciona, y casi nadie lo usa dos veces

Cloudflare Browser Isolation, Forcepoint RBI y Menlo resuelven el problema de inspección moviendo el propio navegador a la nube. La pantalla local recibe solo píxeles; copiar y pegar y la subida de archivos se interceptan en la capa de aislamiento. Desde el punto de vista DLP puro, es la opción de pasarela más sólida.

El coste lo sienten los usuarios de inmediato. Latencia al copiar y pegar, renderizado Markdown roto, desconexiones WebSocket ocasionales en completados largos de Claude, bucles de SSO de Google, generación de imágenes que se descarga como una captura plana en lugar de un archivo real. Las encuestas de adopción muestran de forma consistente que los despliegues de aislamiento se desmoronan en seis meses, salvo que el equipo de seguridad acepte que del 30 al 50 % de los usuarios encontrará la vuelta. La economía también es brutal: el precio por puesto del RBI suele situarse 4 a 8 veces por encima de un enfoque client-side.

El aislamiento de navegador es la respuesta técnicamente correcta a una pregunta que nadie fuera de seguridad quiere hacer. Funciona en el laboratorio y muere en el organigrama.

El enfoque client-side: situarse dentro del navegador, no delante

La única arquitectura que sobrevive a TLS 1.3, ECH, al framing WebSocket, al repliegue al móvil y al shadow AI es la que se ejecuta entre el usuario y la capa de cifrado: en el propio navegador, como extensión, y en el equipo como agente nativo para las apps que esquivan el navegador. Ese es el enfoque de Zeuslock.

Al engancharse al DOM y a la API WebSocket del navegador, el prompt se inspecciona antes de que TLS lo envuelva. El pipeline de detección de tres capas — regex local para coincidencias obvias, un modelo NER ajustado, luego heurísticas de contexto — corre en cliente en milisegundos, con confirmación opcional desde una API ML alojada en la UE. Ningún certificado que instalar. Ningún tráfico que reenrutar. Ninguna latencia añadida al flujo de respuesta. El usuario ve un aviso inline, una anonimización automática (una clave AWS AKIA real reemplazada por una falsa estructuralmente válida), o un bloqueo duro, según el modo de política.

El mismo motor se extiende a Claude Code, Cursor, Copilot CLI y Aider mediante el CLI de Zeuslock y el agente de escritorio. El tráfico MCP entre agentes y herramientas se inspecciona en la frontera del protocolo. El modo Universal cubre herramientas que el equipo no ha oído nombrar, porque la detección actúa sobre el contenido del prompt, no sobre una lista blanca de proveedores.

Comparativa honesta

Qué hacer este trimestre

1. Saque un informe de 30 días de su DLP actual filtrado por chatgpt.com, claude.ai, gemini.google.com y copilot.microsoft.com. Si el contador de incidentes está sospechosamente bajo, ahí tiene el punto ciego.
2. Mida el uso real con un piloto de telemetría en navegador durante 2 semanas. Espere de 5 a 10 veces más tráfico IA del que ve su pasarela.
3. Despliegue una extensión client-side en modo Monitor las semanas 1-2, Anonymize las semanas 3-5, Block para los tipos de detección más sensibles a partir de la semana 6. La progresión está en la guía de configuración de políticas.
4. Desactive las reglas de proxy que apuntan a dominios de IA. Solo le dan un falso consuelo.