🤖 AI

Addressing Labelled Data Scarcity: Taxonomy-Agnostic Annotation of PII Values in HTTP Traffic using LLMs

Este artículo propone y evalúa una pipeline de modelo de lenguaje grande multietapa que permite la anotación flexible e independiente de la taxonomía de información de identificación personal en el tráfico HTTP, abordando la escasez de datos mediante la generación de tráfico sintético y demostrando una detección precisa a través de diversas definiciones de privacidad.

Autores originales: Thomas Cory, Axel Küpper

Publicado 2026-05-08

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Thomas Cory, Axel Küpper

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que eres un inspector de privacidad para una ciudad concurrida. Tu trabajo es revisar cada carta, paquete y mensaje digital que sale de la ciudad para asegurarte de que nadie esté enviando accidentalmente información personal secreta (como direcciones de casa, números de teléfono o registros médicos). Esta información secreta se llama PII (Información Personalmente Identificable).

Durante años, los inspectores han utilizado dos herramientas principales:

El Manual de Reglas: Una lista rígida de palabras clave (como "correo electrónico" o "NSS"). Esto funciona bien para cartas simples, pero falla cuando las personas escriben cosas de formas extrañas o utilizan códigos.
El Perro Entrenado: Un modelo de aprendizaje automático entrenado con miles de ejemplos. Es inteligente, pero solo conoce las reglas específicas que se le enseñaron. Si las reglas cambian (por ejemplo, una nueva ley define "datos de salud" de manera diferente), el perro necesita ser reentrenado desde cero, lo cual toma mucho tiempo y requiere un suministro masivo de cartas reales y secretas para estudiar.

El Problema: Las cartas secretas reales son difíciles de conseguir (debido a las leyes de privacidad), y las reglas sobre lo que cuenta como "secreto" están siempre cambiando. Esto deja a los inspectores con una escasez de buenos datos de entrenamiento y herramientas que no pueden adaptarse.

La Nueva Solución: El "Supertraductor"

Este artículo introduce un nuevo enfoque utilizando Modelos de Lenguaje Grandes (LLM). Piensa en un LLM no como un perro entrenado, sino como un traductor superinteligente y flexible que ha leído casi todo en la biblioteca. No necesitas entrenar a este traductor con reglas específicas; simplemente le entregas el manual de reglas en este momento (en tiempo de ejecución), y puede entenderlo instantáneamente.

Así es como los autores construyeron su sistema, utilizando analogías simples:

1. La Línea de Ensamblaje (La Pipeline)

En lugar de pedirle al traductor que haga todo de una vez, los autores construyeron una línea de ensamblaje de tres pasos:

Paso 1: El Limpiador (Preprocesamiento): Antes de que el traductor vea el mensaje, una máquina lo limpia. Desencripta los códigos (como convertir %20 de nuevo en un espacio) para que el traductor vea una oración clara y legible.
Paso 2: El Detective y el Escriba (Anotación en Dos Etapas):
- El Detective: Primero, el LLM mira el mensaje y dice: "Veo un número de teléfono y un nombre aquí, pero no hay registros médicos". Crea una lista corta de qué buscar.
- El Escriba: Luego, un segundo pase se enfoca solo en encontrar el texto exacto para esos elementos específicos. Al estrechar el enfoque, el Escriba no se confunde con otros números o palabras.
Paso 3: El Editor (Revisión): Una verificación final examina el trabajo. Si el Escriba se perdió un número o tomó la palabra incorrecta, el Editor lo corrige.

2. La Fábrica de "Cartas Falsas" (Datos Sintéticos)

Dado que los inspectores no pueden usar las cartas secretas de personas reales para entrenar sus herramientas, los autores construyeron una Fábrica que produce cartas falsas.

Esta fábrica toma un manual de reglas (una taxonomía) y le pide al LLM que escriba cartas que parezcan realistas y que contengan secretos específicos (como "el número de teléfono de Juan Pérez").
Crucialmente, la fábrica también escribe las respuestas (la verdad fundamental) para cada carta que produce.
Por qué esto importa: Esto resuelve el problema de la "escasez". Puedes generar miles de cartas de práctica con respuestas perfectas instantáneamente, sin tocar nunca los datos privados de una persona real.

3. La Prueba de Manejo (Evaluación)

Los autores probaron este sistema con tres "Manuales de Reglas" (Taxonomías) diferentes:

AI4Privacy: Una lista amplia de secretos comunes (nombres, correos electrónicos, identificaciones).
mHealth: Una lista específica para aplicaciones de salud (signos vitales, datos de fitness).
PlayStore: Una lista de alto nivel utilizada por las tiendas de aplicaciones (por ejemplo, "Datos Financieros" o "Ubicación").

Los Resultados:

Éxito: El sistema funcionó increíblemente bien en los dos primeros manuales de reglas. Podía leer un mensaje, consultar el manual de reglas específico proporcionado ese día y encontrar los secretos con precisión.
Desafío: Tuvo un poco más de dificultades con el manual de reglas "PlayStore". Los autores explican que esto se debe a que ese manual utiliza categorías muy amplias (como "Datos Financieros") que son más difíciles de vincular a una palabra específica en un mensaje que cosas concretas como "Número de Teléfono".
El Paso del "Editor": Curiosamente, el paso final del "Editor" no siempre mejoró las cosas. A veces corría errores, pero otras veces introducía nuevos. Los autores sugieren que esto podría ser porque el Editor estaba usando el mismo "cerebro" que el Escriba, por lo que cometía los mismos tipos de errores.

La Conclusión

Este artículo demuestra que no necesitas reentrenar una máquina cada vez que cambian las reglas de privacidad. En su lugar, puedes utilizar una IA flexible que lee las reglas sobre la marcha.

Para Inspectores: Puedes intercambiar manuales de reglas instantáneamente sin reconstruir tus herramientas.
Para la Escasez de Datos: Puedes generar tus propios datos de práctica (cartas falsas) para probar tus herramientas, por lo que no necesitas robar los datos de personas reales.

Los autores concluyen que, aunque esto no es un reemplazo perfecto para detectores ligeros y rápidos todavía, es una herramienta poderosa para crear datos de entrenamiento de alta calidad y auditar sistemas a medida que evolucionan las leyes de privacidad. Sugieren que el mejor camino futuro es utilizar esta IA flexible para crear los datos, y luego enseñar a máquinas más pequeñas y rápidas cómo hacer el trabajo.

Resumen Técnico: Anotación Agnóstica a la Taxonomía de Valores de Información Personalmente Identificable (PII) en Tráfico HTTP mediante Modelos de Lenguaje Grande (LLMs)

Declaración del Problema

Las auditorías de privacidad automatizadas de aplicaciones web y móviles dependen cada vez más del análisis del tráfico HTTP saliente para detectar fugas de Información Personalmente Identificable (PII). Sin embargo, los detectores basados en aprendizaje existentes enfrentan dos limitaciones críticas:

Escasez de Datos: Dependen de conjuntos de datos de alta calidad, etiquetados manualmente, cuya creación es intensiva en mano de obra y difícil de mantener.
Rigidez Taxonómica: Estos modelos están estrechamente acoplados a taxonomías de etiquetas fijas. A medida que las definiciones de privacidad evolucionan o difieren entre dominios (por ejemplo, GDPR vs. mHealth vs. políticas de Play Store), se requiere reentrenamiento y el rendimiento a menudo se degrada significativamente incluso con cambios menores en la taxonomía o la distribución de datos.

El artículo postula que los Modelos de Lenguaje Grande (LLMs), como modelos generalistas capaces de realizar tareas en cero disparos o pocos disparos sin reentrenamiento, ofrecen una solución potencial para habilitar la anotación agnóstica a la taxonomía de valores de PII en tiempo de ejecución.

Metodología

Los autores proponen un marco integral que consta de dos componentes principales: una tubería de anotación multi-etapa y un generador de datos sintéticos.

1. Tubería de Anotación Multi-Etapa
La tubería descompone la tarea compleja de detección de PII en subproblemas especializados para mejorar la precisión y manejar la variabilidad del tráfico HTTP:

Preprocesamiento Determinista: Los cuerpos de los mensajes HTTP se normalizan para mitigar la variabilidad de codificación. Esto incluye la decodificación de URL (RFC 3986), la resolución de referencias de caracteres HTML y la decodificación opcional a nivel de aplicación (por ejemplo, Base64) para subcadenas que coinciden con patrones sintácticos específicos. Tanto las representaciones originales como las normalizadas se preservan para la trazabilidad.
Anotación en Dos Etapas:
- Clasificación a Nivel de Etiqueta: Un LLM predice el conjunto de etiquetas de PII ( $L_m$ ) presentes explícitamente en el mensaje, adheriéndose a un requisito estricto de "valor explícito" (sin inferencia a partir de claves vacías).
- Extracción a Nivel de Instancia: Un segundo LLM realiza un Reconocimiento de Entidades Nombradas (NER) dirigido sobre el cuerpo normalizado, condicionado por las etiquetas predichas. Esta etapa se centra en la detección de límites y la desambiguación utilizando claves contextuales (nombres de claves, patrones de valores, posición estructural).
Revisión Post-Anotación: Una tercera etapa de LLM actúa como revisor, refinando las anotaciones iniciales para corregir falsos negativos, discrepancias de etiquetas y errores de límites.
Entorno de Inferencia LLM: Para garantizar la robustez, la tubería emplea Generación Aumentada por Recuperación (RAG) para inyectar ejemplos relevantes para la tarea (estructurales y específicos de etiquetas) en los prompts. Una capa de validador determinista hace cumplir el cumplimiento del esquema y normaliza las salidas de etiquetas (por ejemplo, mapeando "E-mail" a "Email") utilizando similitud coseno contra la taxonomía objetivo.

2. Generador de Mensajes HTTP Sintéticos
Para abordar la escasez de datos etiquetados sin exponer tráfico de usuarios real, los autores introducen un generador impulsado por taxonomía:

Generación de Escenarios: El LLM crea plantillas de escenarios (por ejemplo, creación de cuenta, pago) basadas en una taxonomía proporcionada.
Instanciación de Mensajes: El LLM genera solicitudes HTTP concretas (y opcionalmente respuestas) que contienen valores de PII explícitos.
Validación: Una capa de validación asegura la buena formación estructural, el cumplimiento de la taxonomía y que todos los valores anotados aparezcan literalmente en la carga útil generada.
Seguimiento de Cobertura: El sistema monitorea la cobertura de etiquetas para garantizar una representación diversa a través de la taxonomía.

Contribuciones Clave

El artículo describe tres contribuciones principales:

C1 (Tubería de Anotación): Un enfoque basado en LLM multi-etapa para la identificación granular de PII en cargas útiles HTTP que admite el cambio en tiempo de ejecución de taxonomías de etiquetas sin reentrenamiento.
C2 (Generador Sintético): Un mecanismo basado en LLM para generar tráfico HTTP sintético con anotaciones de PII de verdad fundamental, reduciendo la dependencia de la curación manual para taxonomías cambiantes.
C3 (Evaluación): Una evaluación integral a través de tres taxonomías distintas (AI4Privacy, mHealth y PlayStore) que cubren diferentes dominios y niveles de granularidad para evaluar la flexibilidad y el rendimiento.

Resultados

La evaluación utilizó tres conjuntos de datos derivados del generador sintético, divididos en 80/20 para evaluación y ejemplos de RAG. El rendimiento se midió utilizando Precisión, Recall y puntuaciones F1 a nivel de etiqueta e instancia.

Rendimiento General: La tubería logró un rendimiento sólido en las taxonomías AI4Privacy (53 clases) y mHealth (38 clases). La detección a nivel de etiqueta estuvo cerca del techo (F1 > 0.98) en la etapa de clasificación, y la extracción a nivel de instancia se mantuvo alta (F1 > 0.95).
Varianza Taxonómica: El rendimiento fue menor en la taxonomía PlayStore (38 clases), que utiliza categorías de nivel superior orientadas a políticas. Esto sugiere que la dificultad de anotación se correlaciona con la granularidad semántica de la taxonomía; las categorías amplias son más difíciles de mapear a valores específicos de carga útil que los tipos concretos de PII.
Impacto Arquitectónico:
- La configuración de dos etapas (clasificación seguida de extracción dirigida) generalmente superó o igualó la anotación de una sola etapa en AI4Privacy y mHealth, mejorando principalmente el recall a nivel de instancia.
- En PlayStore, el enfoque de dos etapas mejoró la detección de etiquetas, pero no se tradujo en una mejor extracción de instancias, lo que indica que las salidas ruidosas del clasificador pueden propagar errores en taxonomías complejas.
Etapa de Revisión: La etapa de revisión proporcionó un beneficio neto limitado, degradando ocasionalmente el rendimiento. Los autores sugieren que esto se debe a que se utilizó la misma familia de modelos para la anotación y la revisión, potencialmente reproduciendo suposiciones compartidas en lugar de proporcionar una corrección independiente.

Significado y Afirmaciones

El artículo afirma que los LLMs sirven como una base prometedora para la anotación de tráfico flexible y agnóstica a la taxonomía. Las conclusiones clave incluyen:

Viabilidad: Los LLMs pueden identificar y anotar con precisión valores de PII transmitidos explícitamente cuando la taxonomía se proporciona en tiempo de ejecución, eliminando la necesidad de reentrenar sobre nuevos conjuntos de etiquetas.
Generación de Datos: El tráfico HTTP sintético con anotaciones de verdad fundamental es un sustrato viable para la evaluación controlada y la indicación con pocos disparos, mitigando la escasez de datos del mundo real etiquetados.
Limitaciones y Alcance: Los autores son modestos respecto a la implementación de este enfoque como un reemplazo directo de detectores de producción ligeros. Señalan que:
- El rendimiento depende en gran medida del diseño de la taxonomía y la estructura de la carga útil.
- Los datos sintéticos, aunque útiles para la evaluación, pueden no capturar completamente la distribución del tráfico del mundo real (por ejemplo, ofuscación, cargas útiles malformadas).
- La evaluación actual se limita a valores transmitidos explícitamente en cuerpos de solicitud, excluyendo encabezados, cookies y tráfico cifrado.
Camino Futuro: Los autores proponen un enfoque híbrido como el camino más prometedor hacia adelante: utilizar la anotación basada en LLM para crear o refinar conjuntos de datos etiquetados bajo taxonomías en evolución y, posteriormente, destilar estas anotaciones en modelos más pequeños y discriminativos para un despliegue de alto rendimiento.