Prevención de pérdida de datos (DLP)
En seguridad del dato, el DLP (prevención de pérdida de datos) clasifica, vigila y bloquea información sensible cuando sale de una organización. Los canales han cambiado: junto al correo y los soportes extraíbles, hoy los datos salen por SaaS, por el navegador, por almacenamiento personal, por repositorios de código y, sobre todo, pegados en un asistente de IA. Se compra dentro de una plataforma SSE o de endpoint más amplia.
Qué es la prevención de pérdida de datos
La prevención de pérdida de datos (DLP, por sus siglas en inglés) es el conjunto de medidas y tecnologías que evitan que información sensible salga de una organización sin autorización: información financiera, datos personales, propiedad intelectual o secretos comerciales.
Hace tres cosas. Vigila la actividad sobre los datos en redes, equipos y almacenamiento para detectar transferencias y accesos que se salen del patrón. Aplica las políticas de la organización sobre esos datos, desde la clasificación y la restricción por rol hasta el bloqueo de una transferencia. Y avisa, para que alguien pueda mirar lo que se ha bloqueado y decidir.
Cómo funciona
El DLP identifica contenido sensible (por patrón, por huella o por la etiqueta que le puso un esquema de clasificación de datos) y vigila los puntos por los que podría salir, tomando una acción cuando ve una coincidencia: registrar, avisar o bloquear. En un despliegue moderno la aplicación ocurre en varios sitios a la vez: en el endpoint mediante un agente, en el navegador, y en el cloud mediante un SSE o un cloud access security broker que inspecciona el tráfico hacia las aplicaciones SaaS. El producto de hace una década, de un solo appliance y un solo canal, ha quedado absorbido por estas plataformas, porque los datos ya no salen por la única pasarela que vigilaba el DLP antiguo.
Qué sale mal
La idea anticuada es que los datos se fugan por correo, por subidas y por soportes extraíbles, y un DLP afinado solo para eso no ve por dónde salen ahora. En 2026 la información sensible sale por una aplicación SaaS que el equipo de seguridad no controla, por un cliente de sincronización que copia una carpeta a almacenamiento personal, por un secreto subido a un repositorio público, o por un párrafo pegado en un asistente de IA público, que es el canal de la shadow AI y no deja ningún evento de exfiltración que capturar. Desde la posición de un interno o de un atacante, la jugada ganadora es el canal que el DLP no inspecciona: el pegado, el cloud personal, el navegador no gestionado. Cubrir los canales antiguos mientras los nuevos siguen abiertos es una falsa sensación de control.
Dónde aparece esto en una auditoría
Probamos por dónde pueden salir de verdad los datos sensibles, no por dónde apunta el DLP. Eso significa comprobar los canales modernos (pegar desde el navegador en herramientas de IA, sincronizar con almacenamiento personal, repositorios de código, SaaS no autorizado) además del correo y los soportes extraíbles, y confirmar si la plataforma puede siquiera observar cada uno. Lo evaluamos junto al escenario de amenaza interna, porque quien filtra suele estar autorizado. El hallazgo se escribe contra el canal no inspeccionado. Esto forma parte de cómo probamos por dónde pueden salir los datos sensibles.