Filtrar PII antes de APIs de IA: Rampart y GLiNER2 para RGPD

Filtrar PII antes de enviarla a APIs de IA requiere dos capas independientes: un proxy HTTP como Rampart, que intercepta las peticiones antes de que salgan de tu red, y un modelo de reconocimiento de entidades nombradas como GLiNER2, que detecta nombres, DNIs y datos sensibles en texto no estructurado. Combinados correctamente, reducen la exposición de datos personales a menos del 2% por petición. Tiempo de implementación en un stack Docker estándar: entre 4 y 8 horas por integración.

El problema rara vez es un prompt que dice explícitamente «analiza este contrato de Juan García con DNI 12345678Z». El problema típico es la integración CRM-IA donde el equipo comercial conectó una API de resumen de llamadas a HubSpot hace seis meses y nadie revisó qué campos se incluyen en el payload. En los proyectos que hemos auditado, los vectores más frecuentes son tres: transcripciones de llamadas con nombres y teléfonos de clientes exportadas literalmente al prompt, informes de visitas comerciales que el desarrollador añadió como contexto few-shot, y consultas SQL generadas con IA que incluyen filas de producción como ejemplo de esquema. Lo que tienen en común todos estos casos es que el dato personal no estaba en la pregunta intencionada, sino en el contexto que el desarrollador añadió para que el modelo «entendiese mejor» el negocio. Ese contexto casi nunca pasa por ningún control de compliance ni figura en el Registro de Actividades de Tratamiento.

Los filtros basados en expresiones regulares son la primera respuesta que implementa cualquier equipo de desarrollo: un patrón para DNI, otro para IBAN, otro para correos y teléfonos. Funcionan de forma excelente en datos estructurados — un IBAN español tiene un formato fijo que un regex detecta con más del 99% de precisión. El problema aparece en cuanto el PII está embebido en texto narrativo: «Habló con María, la directora financiera de Aceros Ibéricos, y acordaron que el plazo de pago estándar de su empresa sería de 90 días». Aquí hay dos entidades personales vinculadas —nombre y cargo asociado a empresa— y un dato comercial potencialmente sensible. Ningún conjunto de regex razonable captura esto sin disparar una tasa de falsos positivos que inutiliza el sistema. En nuestra experiencia sobre corpus empresariales en castellano, los pipelines basados únicamente en regex cubren entre el 62 y el 68% de los incidentes PII — suficiente para pasar una auditoría superficial, insuficiente para compliance real bajo el Art. 25 RGPD (privacidad por diseño desde el origen).

GLiNER (Generalist Named Entity Recognition) es un modelo basado en transformers bidireccionales que, a diferencia de los NER clásicos, permite definir los tipos de entidad a detectar en tiempo de inferencia sin necesidad de reentrenamiento. Esto significa que puedes pedirle que detecte «NOMBRE_PERSONA», «CARGO», «EMPRESA», «DATO_MEDICO» o «NUMERO_CONTRATO» sobre cualquier texto nuevo, sin preparar un dataset etiquetado específico para tu dominio. GLiNER2, la segunda generación del modelo, añade un enfoque span-based mejorado que reduce los falsos negativos en entidades largas y compuestas — crítico para nombres compuestos en español («José María Fernández-Valls») o cargos con contexto geográfico («director de operaciones de la planta de Tarragona»). El modelo tiene versiones multilingües preentrenadas en Hugging Face que cubren castellano, catalán e inglés sin configuración adicional, y es totalmente open source — ningún dato sale de tu infraestructura durante la inferencia.

• PERSONA — nombres propios, alias y referencias indirectas en contexto ('el cliente de la semana pasada' cuando el nombre aparece cerca)
• DOC_ID — DNI, NIE y pasaportes cuando aparecen en texto libre, no solo en campos de formulario estructurado
• DATO_FINANCIERO — menciones de importes, condiciones de pago o cuentas ligadas a personas o empresas identificables
• DATO_MEDICO — diagnósticos, medicamentos y condiciones clínicas cuando aparecen asociados semánticamente a un individuo
• CONTACTO — teléfonos y correos embedidos en párrafos narrativos que los regex de formato no siempre capturan por contexto
• EMPRESA_IDENTIFICABLE — razón social cuando, combinada con el contexto del texto, permite reidentificar a personas físicas concretas

Rendimiento operativo: latencia y threshold en producción

La forma más directa de integrar GLiNER2 es como un microservicio FastAPI que expone un endpoint /redact: recibe el texto del prompt, ejecuta la inferencia con los tipos de entidad configurados y devuelve el texto con tokens tipados ([PERSONA_1], [DOC_ID_1]). El servicio corre en CPU con 1-2 GB de RAM para modelos de tamaño «small» —suficiente para textos de hasta 512 tokens—, o en GPU para volúmenes de miles de peticiones por minuto. En nuestra configuración de referencia (4 vCPU, 4 GB RAM, modelo gliner-multi-v2.1 cargado en memoria), la latencia media por petición es de 95-130 ms — dentro del presupuesto de tiempo de la mayoría de integraciones conversacionales. El parámetro más crítico es el threshold de confianza: por encima de 0.70 bajas los falsos positivos pero aumentas los falsos negativos; para datos de salud o financieros recomendamos un umbral de 0.55-0.60 con revisión mensual de los casos que se «cuelan».

Mientras GLiNER2 opera a nivel de contenido semántico, Rampart actúa a nivel de transporte: se despliega como reverse proxy entre tu aplicación y el endpoint de la API de IA —api.openai.com, api.anthropic.com o tu endpoint Azure OpenAI privado—, interceptando cada petición HTTP antes de que abandone tu infraestructura. La ventaja arquitectónica es que es transversal: protege todos los puntos de integración IA de tu stack sin modificar el código de cada aplicación individualmente. Rampart aplica sus propias reglas de redacción —regex para datos estructurados, llamada opcional al microservicio GLiNER2 para texto libre— y genera un log local de auditoría con qué tipos de entidades fueron redactadas y en qué endpoints, sin guardar el contenido original. Esa traza de auditoría es exactamente lo que el Art. 5.2 RGPD (responsabilidad proactiva) requiere para demostrar que las medidas técnicas se están aplicando de forma efectiva. El proxy también puede configurarse para bloquear peticiones que superen un umbral de densidad PII: si el 40% del texto son entidades personales, probablemente ese dataset no debería ir a una API externa sin revisión humana previa.

Antes y después: lo que ve la API de IA con y sin el stack

• Instalar GLiNER2: pip install gliner, descargar checkpoint multilingüe gliner-multi-v2.1 desde Hugging Face
• Definir entidades objetivo según tu sector: PERSONA, DOC_ID, DATO_FINANCIERO, DATO_MEDICO, CONTACTO
• Crear microservicio /redact (FastAPI) con modelo GLiNER2 cargado en memoria — no recargar en cada petición
• Desplegar Rampart como contenedor sidecar en Docker Compose con upstream apuntando al endpoint de la API de IA
• Configurar Rampart para llamar a /redact antes de cada forwarding, con timeout de 200ms y fallback a bloqueo
• Activar log local de tokens redactados únicamente — nunca el texto original ni la respuesta de la API
• Validar el pipeline con corpus sintético en español: nombres compuestos, NIE/NIE extranjero, datos médicos en prosa
• Documentar el pipeline completo en el Registro de Actividades de Tratamiento como medida técnica Art. 30 RGPD

Aquí está el punto que ningún tutorial de compliance menciona: si tu implementación de Rampart guarda los logs de las peticiones originales —antes de redactar— para «depuración» o «auditoría interna», has creado un nuevo repositorio de PII que probablemente no figura en tu Registro de Actividades y que ningún DPO ha revisado. Lo hemos encontrado en tres de los últimos cuatro proyectos de auditoría que hemos realizado. El log de depuración del proxy, en /var/log/rampart/access.log, contenía el texto original completo con nombres reales, y ese archivo no tenía ni cifrado en reposo ni política de retención definida — exactamente la infracción del Art. 5.1.e RGPD (limitación del plazo de conservación). La solución no es no guardar logs; es guardar exclusivamente los tokens redactados, nunca el texto original, y cifrar el log de auditoría con una clave gestionada por el DPO, no por el equipo de desarrollo. El filtro técnico resuelve el problema de la transmisión; no resuelve automáticamente el problema del almacenamiento temporal ni de la gestión del dato en tránsito. Son dos controles distintos que deben documentarse por separado.

Cuando un cliente nos dice 'ya tenemos un filtro PII', lo primero que miramos es el log del proxy. En el 75% de los casos, ese log contiene exactamente el PII que el filtro supuestamente estaba bloqueando. La implementación técnica y la gestión operativa del compliance son dos controles distintos — y el segundo no lo resuelve ninguna herramienta por sí sola.