Durante tres décadas, proteger los datos personales consistía en controlar dónde se almacenaban los datos y quién podía llegar a la base de datos. Las herramientas de IA desmantelaron ese modelo en unos dieciocho meses.
No es una crítica a la IA. Es la descripción de un cambio estructural — y entenderlo es la diferencia entre una protección de datos que funciona de verdad y una protección que tiene buen aspecto en una auditoría de cumplimiento pero que falla en la práctica en cuanto un profesional del conocimiento abre una ventana de chat.
El modelo antiguo — y por qué funcionaba
La protección de datos personales tradicional se diseñó para datos estructurados: fichas de CRM, sistemas de historiales clínicos, bases de datos de recursos humanos, libros mayores financieros. La amenaza era el acceso no autorizado — un atacante o un empleado no habilitado llegando a datos que no debía alcanzar.
La respuesta era igual de estructurada:
- Tokenización y cifrado a nivel de campo en las bases de datos: se sustituyen los NSS y los números de cuenta por tokens opacos en reposo. Solo los servicios habilitados pueden resolver el token de vuelta al original.
- Controles de acceso por rol: se limita qué empleados pueden consultar qué tablas. Se audita cada lectura.
- DLP de red (prevención de pérdida de datos): se analiza el tráfico saliente en busca de patrones de datos personales estructurados — formato de NSS, números de tarjeta de crédito, patrones de IBAN — y se bloquea la exfiltración antes de que abandone el perímetro corporativo.
- Enmascaramiento de datos en entornos no productivos: se prueba con datos de apariencia realista pero generados sintéticamente, que no contienen ninguna identidad real.
Esto funcionaba porque los datos vivían en ubicaciones acotadas y conocidas. Se podían enumerar los sistemas que contenían datos personales, envolver las capas de almacenamiento y de red en controles, y esos controles aguantaban frente al modelo de amenaza para el que se habían construido.
Lo que cambiaron las herramientas de IA
La superficie de amenaza se desplazó — no porque las herramientas de IA sean inseguras, sino porque introdujeron un camino nuevo y sin fricción desde el almacenamiento controlado hasta el tratamiento externo.
Considere el flujo de trabajo: un profesional del conocimiento abre SharePoint, descarga un PDF de contrato, abre ChatGPT y pega el contenido. Estaba habilitado para acceder al documento — no se vulneró ningún control de acceso. No exfiltró datos en el sentido técnico — usó un dispositivo aprobado en la red corporativa. Pero el documento, con cada nombre, cada dirección y cada cifra financiera que contiene, acaba de transitar a una infraestructura en la nube comercial de la que la organización no ve nada, que ningún contrato gobierna y de la que no hay registro de auditoría alguno.
La herramienta antigua no tiene asidero sobre esto:
- El DLP de red detecta patrones estructurados en las subidas de archivos y los flujos salientes, pero la mayoría de las interacciones con la IA ocurren como peticiones HTTPS POST a una interfaz web — el proxy ve el dominio de destino, no el contenido del cuerpo del mensaje.
- La tokenización en base de datos protege los datos personales en reposo. Para cuando un usuario ha descargado un PDF y lo está leyendo, los datos ya se han extraído del depósito de tokens, reconstruido y mostrado. El sistema de tokens hizo exactamente lo que se esperaba de él — simplemente no se diseñó para el paso siguiente.
- Los controles de acceso quedaron satisfechos en el instante en que el usuario habilitado abrió el archivo. Lo que ocurre aguas abajo de ese acceso queda fuera de su alcance, por diseño.
El modelo antiguo daba por sentado que controlar el acceso a los datos equivalía a controlar lo que se hacía con ellos. Las herramientas de IA rompieron esa premisa en seco. Acceso autorizado más ventana de chat: ahí tiene datos que abandonan la organización — discretamente, legalmente (desde el punto de vista del control de acceso) y en volumen.
Por qué el filtrado del lado de la nube se queda corto
Una respuesta a este hueco es encaminar todo el tráfico de IA por un proxy corporativo que intercepta las peticiones, busca datos personales, los oculta y reenvía la versión saneada. Este enfoque existe y es mejor que nada. Pero tiene límites estructurales:
- Requiere inspección SSL del tráfico HTTPS — técnicamente invasiva, costosa de operar y cada vez más cuestionada por los modelos de seguridad de los navegadores y por el rechazo de los empleados en nombre de su privacidad.
- Requiere configuración por cada herramienta de IA. A medida que la proliferación de herramientas de IA se acelera, la superficie de configuración crece más rápido de lo que ningún equipo de seguridad puede seguir. Una nueva herramienta de IA se convierte en un hueco en el instante en que un usuario la descubre.
- Atrapa patrones de datos personales estructurados (formato de NSS, IBAN) pero le cuesta con los nombres en texto libre, las direcciones y los identificadores que dependen del contexto — que son la mayoría de los datos personales en los documentos profesionales.
- No puede atrapar el copiar y pegar desde aplicaciones fuera del alcance del proxy — dispositivos móviles, equipos personales, flujos de «sin conexión y luego pegar».
El filtrado del lado de la nube trata a la IA como un canal que supervisar en lugar de como un comportamiento que reestructurar. La acción de fondo — un usuario que extrae contenido sensible de un sistema controlado y se lo entrega a un servicio externo — sigue ocurriendo. El filtrado añade un badén en el medio. No ataca la raíz.
La comparación en términos claros
Dimensión DLP tradicional Anonimización del lado del clienteLa frontera correcta: antes de la IA, en el dispositivo
La intervención tiene que producirse antes de que los datos salgan del dispositivo del usuario — ni en el perímetro de la red, ni dentro de la infraestructura del proveedor de IA una vez consumado el hecho.
Esto exige otro modelo mental. En lugar de preguntar «¿cómo supervisamos lo que los usuarios envían a las herramientas de IA?», la pregunta pasa a ser: «¿cómo damos a los usuarios una versión de sus documentos que sea, por diseño, segura de enviar a cualquier herramienta de IA?».
La idea clave es que la IA no necesita identidades para hacer su trabajo. Necesita estructura, idioma y contexto. «Alice Martin, nacida el 14 de marzo de 1987, con domicilio en 14 rue des Acacias, Lyon, referencia de cliente A-2091» no le dice nada adicional a un gran modelo de lenguaje sobre la cláusula contractual que se le pide analizar. Retire la identidad, conserve la cláusula. El resultado de la IA es igual de útil — y los datos originales nunca salieron del dispositivo.
Cómo lo implementa promptShield
promptShield se ejecuta enteramente sin conexión en el dispositivo del usuario — sin inferencia en la nube, sin llamada de red durante la anonimización. La canalización de detección aplica tres capas a cada documento:
- Expresiones regulares — patrones estructurados de alta precisión: IBAN, NSS, correo electrónico, teléfono, número de pasaporte y otros formatos de identificadores de documento en 7 idiomas europeos. Se activan primero, con alta precisión, y no requieren cargar un modelo.
- Detección de entidades nombradas — modelos spaCy y de transformadores ejecutados en local, que detectan nombres, direcciones, organizaciones y fechas en contexto. El mismo nombre de entidad que se repite a lo largo de las páginas queda enlazado, de modo que anonimizar en la página 1 lo suprime automáticamente en la página 4.
- Pasada LLM opcional — para los casos ambiguos, un modelo GGUF ejecutado localmente resuelve las detecciones límite sin enviar datos a ninguna parte.
Cada entidad detectada se sustituye por un token tipado y estable: [PERSON_1], [ADDRESS_2], [IBAN_1]. La correspondencia entre el token y el valor original se guarda en una base de datos SQLite local — el registro de tokens — que nunca sale del dispositivo.
El usuario pega el documento anonimizado en la herramienta de IA que elija. La IA produce su análisis a partir de los tokens. Cuando el usuario quiere aplicar el resultado de la IA al documento original, promptShield sustituye los valores reales. El flujo analítico no cambia. La exposición, en cambio, queda eliminada por diseño.
Qué cambia y qué no
La anonimización del lado del cliente aborda un hueco concreto: el camino sin fricción desde un documento controlado hasta un servicio de IA externo. No sustituye los controles de acceso, no sustituye el registro de auditoría y no elimina la necesidad de formar a los empleados en un uso adecuado de la IA.
Lo que sí cambia es el modelo de riesgo para el caso de uso de la IA en concreto. Una vez que anonimiza antes de pegar, la pregunta «¿qué pasa si un empleado usa ChatGPT con un documento de cliente?» tiene otra respuesta. La IA recibe contenido estructurado — lógica de cláusulas, ratios financieros, arquitectura del contrato — sin ningún identificador adjunto. No hay nada que exponer.
El perímetro antiguo era el almacén de documentos. El perímetro nuevo tiene que ser el documento mismo — en concreto, el momento en que pasa de un sistema acotado a texto libre en manos de un usuario.
Esa frontera es la que el DLP tradicional nunca se diseñó para sostener. Es la que importa ahora.
