LLM-Redactor: An Empirical Evaluation of Eight Techniques for Privacy-Preserving LLM Requests

Resumen Técnico: LLM-Redactor

1. El Problema

Los agentes de codificación y las aplicaciones impulsadas por Modelos de Lenguaje Grande (LLM) envían rutinariamente contenido potencialmente sensible (información de identificación personal - PII, secretos, código propietario y contexto organizacional) a APIs de LLM en la nube. Una vez enviados, estos prompts pueden ser registrados, retenidos para entrenamiento, utilizados para depuración o sujetos a órdenes judiciales.

La herramienta de privacidad existente se limita a:

• Encriptación a nivel de red (TLS): Protege contra observadores pasivos, pero no contra el proveedor de la nube.
• Prevención de pérdida de datos (DLP) a nivel organizacional: Se centra en datos en reposo o en control de versiones, no en el contenido de las solicitudes de API transitorias.
• Escáneres de secretos: Detectan patrones conocidos en el momento del commit, pero no pueden inspeccionar el tráfico de solicitudes en tiempo real.

Existe una falta de un marco sistemático y una implementación de referencia que opere dentro del propio pipeline de solicitudes de LLM para proteger el contenido antes de salir del dispositivo del usuario.

2. Metodología y Evaluación Empírica

Los autores presentan una evaluación sistemática de ocho técnicas distintas para preservar la privacidad en las solicitudes de LLM. Implementaron todas estas técnicas (o un subconjunto viable en etapa de investigación) en un shim (intermediario) de código abierto compatible con MCP y APIs compatibles con OpenAI.

Las ocho técnicas evaluadas:

1. A. Inferencia solo local: No enviar datos a la nube (usando modelos locales pequeños para tareas triviales).
2. B. Ofuscación con restauración de marcadores: Detectar y reemplazar datos sensibles con marcadores tipados (ej. <EMAIL_1>), restaurándolos en la respuesta.
3. C. Reformulación semántica: Reescribir el prompt localmente para eliminar detalles identificativos manteniendo la pregunta técnica.
4. D. Inferencia en Entorno de Ejecución Confiable (TEE): Enviar texto plano a un enclave seguro (ej. AWS Nitro) donde se ejecuta el modelo.
5. E. Inferencia dividida (Split Inference): Ejecutar las primeras capas del modelo localmente y enviar solo las activaciones intermedias.
6. F. Encriptación Homomórfica Total (FHE): Realizar inferencia sobre datos encriptados (actualmente prohibitivo en velocidad).
7. G. Cálculo Seguro Multiparte (MPC): Dividir la entrada entre servidores no colusivos.
8. H. Ruido de Privacidad Diferencial (DP): Añadir ruido calibrado a nivel de palabras para difuminar señales residuales.

Configuración de la Evaluación:

• Benchmarks: Se creó un conjunto de datos de 1.300 muestras con 4.014 anotaciones de "verdad fundamental" (ground-truth) en cuatro clases de carga de trabajo:
  • WL1: Prosa rica en PII.
  • WL2: Configuraciones ricas en secretos (API keys, tokens).
  • WL3: Identidad implícita (ej. "el CFO de Acme cuya esposa trabaja en la competencia").
  • WL4: Código propietario.
• Métricas: Tasa de fuga exacta (texto verbatim), tasa de fuga parcial, latencia, costo y calidad (utilidad).

3. Contribuciones Clave

• Taxonomía y Comparación: Una clasificación de ocho técnicas basada en propiedades de privacidad, costo de utilidad y practicidad actual.
• Modelo de Amenaza Definido: Especificación clara de qué protege cada técnica contra seis escenarios de ataque (desde fugas de registros del proveedor hasta contaminación de entrenamiento).
• Implementación de Referencia: Un sistema abierto que soporta múltiples opciones intercambiables dinámicamente.
• Benchmark Unificado: El primer estudio empírico que compara todas estas clases de técnicas en un mismo conjunto de datos con tasas de fuga medidas.
• Regla de Decisión: Un marco para que los practicantes seleccionen la estrategia óptima según su presupuesto de amenazas y tipo de carga de trabajo.

4. Resultados Principales

Hallazgos sobre Fugas de Datos:

• No hay una solución única: Ninguna técnica domina en todos los escenarios.
• La combinación ganadora (Práctica): La estrategia A + B + C (Enrutar localmente cuando sea posible + Ofuscar + Reformular) es la más efectiva para implementaciones prácticas.
  • Logra una tasa de fuga combinada del 0.6% en PII (WL1).
  • Logra 0 fugas exactas en 500 muestras de PII.
  • Reduce la fuga en código propietario (WL4) al 31.3%.
• Limitación de la Transformación de Contenido: Las técnicas de ofuscación y reformulación (B y C) fallan estrepitosamente con la identidad implícita (WL3). Incluso con la mejor combinación, la tasa de fuga semántica supera el 95% porque la estructura de las relaciones (ej. "el CFO de X") es necesaria para que el prompt tenga sentido, y eliminarla destruye la utilidad.
• Rendimiento de Técnicas Criptográficas: Las opciones D, E, F y G ofrecen protección teórica perfecta (0% de fuga de tokens en texto plano), pero F y G son actualmente inviables para modelos de chat debido a la latencia extrema (10,000x - 100,000x más lento).

Métricas de Utilidad y Costo:

• Latencia:
  • La ofuscación (B) añade <50 ms.
  • La reformulación (C) añade ~1-2 segundos (debido a la llamada al modelo local).
  • El enrutamiento local (A) añade ~300 ms.
• Costo de Tokens: La ofuscación (B) reduce el número de tokens enviados a la nube (entre un 4% y un 12%) porque los marcadores son más cortos que los datos originales (ej. una dirección de email vs. <EMAIL_1>).
• Calidad: La ofuscación reduce la calidad de la respuesta en un 20-25% según evaluaciones de modelos juez, ya que se pierde contexto específico, pero es aceptable para cargas de trabajo priorizadas en privacidad.

5. Significado y Recomendaciones

El estudio concluye que la privacidad en LLM requiere un enfoque estratificado basado en el modelo de amenazas:

1. Tolerancia Cero (λ = 0): Usar Opción A (local) para todo lo que el modelo local pueda manejar. Para el resto, usar Opción D (TEE) o rechazar la solicitud.
2. Tolerancia Baja (λ ≤ 0.05): Usar la combinación A + B + C. Enrutar localmente, y para lo que va a la nube, ofuscar y reformular.
3. Identidad Implícita: Si el riesgo principal es la identidad implícita (contexto que revela quién es el usuario sin PII explícita), las técnicas de ofuscación son insuficientes. Se requiere Opción D (TEE) o aceptar el riesgo.
4. Restricción de Latencia: Si la velocidad es crítica, usar solo Opción B (ofuscación con NER), que ofrece protección significativa con menos de 50 ms de sobrecarga.

Impacto:
El trabajo demuestra que, aunque la encriptación total (FHE/MPC) es el futuro, las técnicas híbridas de enrutamiento local y ofuscación inteligente son la solución práctica inmediata. El código, los benchmarks y la herramienta de evaluación están disponibles públicamente en GitHub (llm-redactor), permitiendo a los desarrolladores implementar estas defensas hoy mismo.

Limitaciones:
El estudio utiliza datos sintéticos (aunque realistas) y evaluadores de calidad basados en modelos locales de tamaño medio. La detección de nombres de organizaciones y IDs de empleados sigue siendo un desafío para los detectores estándar (Presidio), sugiriendo la necesidad de modelos NER específicos de dominio.