Need to Know: reescritura de consultas por integridad contextual

¿Qué es esto?

El 2 de junio de 2026, Xinyue Huang, Xiaochun Cao y Wenyuan Yang publicaron Need to Know: Contextual-Integrity-Grounded Query Rewriting for Privacy-Conscious LLM Delegation (arXiv:2606.04067, cs.CR / cs.AI). El artículo aborda una exposición de datos fácil de pasar por alto porque nada «se rompe»: cada vez que un usuario delega una tarea a un LLM alojado en la nube, su prompt lleva habitualmente divulgaciones sensibles no esenciales para la tarea, junto al contenido que de verdad se necesita. El proveedor —y cualquiera con acceso a sus registros— recibe ambos.

El argumento central de los autores es que la mitigación habitual, la censura de PII por tipo, es la herramienta equivocada. Un redactor que enmascara todo lo que parece un nombre, una dirección o un número de tarjeta es independiente del contexto: divulga de más el contexto sensible no tipificado (un detalle médico, una relación, un lugar insinuado en el texto) y elimina de más los fragmentos que portan la respuesta que el modelo necesitaba. La contribución es un replanteamiento, acompañado de un benchmark y un reescritor entrenado, no un ataque.

Cómo funciona

El artículo replantea la reescritura de consultas respetuosa con la privacidad bajo el prisma de la integridad contextual (Contextual Integrity, CI): un flujo de información solo es apropiado si respeta las normas del contexto en el que se compartió. Traducido a una regla para la delegación, se convierte en una sola prueba: un fragmento solo debe enviarse al modelo en la nube si es necesario para la tarea. El criterio de decisión es la necesidad, no el tipo de dato.

Para hacerlo medible, los autores construyen DelegateCI-Bench, presentado como el primer benchmark de integridad contextual orientado a tareas para la delegación respetuosa con la privacidad. Comprende 3.167 muestras que combinan datos sintéticos de 11 tareas y 20 tipos de tarea, consultas reales de usuarios tomadas de WildChat y un conjunto de desafío médico denso en información sensible.

# Decisión conceptual, fragmento a fragmento — descriptivo, no código ejecutable.
# Fuente: arXiv:2606.04067 (Huang, Cao y Yang, 2026).

censura por tipo:        mask(span) si regex/NER dice "PII"     # ciega al contexto
integridad contextual:   forward(span) solo si task_essential(span)
                         si no suppress(span)                  # basada en la necesidad

Sobre el benchmark, entrenan un reescritor de consultas con un marco de aprendizaje por refuerzo guiado por la CI que convierte los fragmentos «esenciales» y «sensibles no esenciales» en señales de optimización verificables: el reescritor recibe recompensa por conservar la información crítica para la tarea mientras retira la divulgación superflua. Resultado reportado: el reescritor aprendido alcanza el mejor equilibrio privacidad-utilidad, hasta +10,1 de utilidad media frente a las líneas base en el dispositivo (on-device).

Por qué importa

Esta es la cara cotidiana de la exposición de datos por los LLM. No hay payload malicioso ni modelo comprometido, solo el volumen de contexto sensible que viaja a proveedores externos porque un prompt es el lugar más cómodo para volcar todo lo que uno sabe. Para flujos de trabajo regulados (salud, jurídico, RR. HH.) ese flujo es tanto una superficie de cumplimiento como un asunto de privacidad, y «censuramos las PII antes de enviar» es un control más débil de lo que parece: los redactores por tipo se pierden el contexto que no es un tipo de PII reconocido, y rompen la utilidad cuando borran el fragmento que portaba la respuesta.

El encuadre de CI es trasladable mucho más allá de este único reescritor. Cualquier equipo que construya una pasarela delante de un modelo en la nube —un proxy, un filtro DLP, un preprocesado en el dispositivo— está tomando implícitamente decisiones de enviar o suprimir. Tomarlas por necesidad en lugar de por tipo de dato es un modelo mental más limpio, y un benchmark como DelegateCI-Bench permite comprobar si un filtro realmente preserva las respuestas mientras reduce las fugas, en lugar de cambiar un fallo por otro.

Defensas

El artículo es la defensa, pero las conclusiones prácticas son concretas. Trate la minimización de datos hacia los LLM en la nube como una prueba de necesidad, no como un pase de regex: pregúntese si cada fragmento sensible cambia la respuesta y suprímalo si no es así. Mida las dos mitades del equilibrio —privacidad y utilidad—, porque un redactor que retira en silencio texto que porta la respuesta falla sin avisar y los usuarios lo rodean. Cuando sea factible, ejecute el paso de reescritura/minimización en el dispositivo o dentro de su perímetro de confianza, para que la supresión ocurra antes de que algo salga, y mantenga un conjunto de evaluación reservado (médico u otro de alta sensibilidad) para detectar regresiones de divulgación excesiva.

Dos advertencias honestas. Un reescritor aprendido es a su vez un modelo: puede clasificar un fragmento como no esencial y descartar algo que importaba, o conservar lo que debía retirar; por tanto, es una capa de reducción de riesgo, no una garantía, y los flujos de alto impacto siguen mereciendo revisión humana y un alcance de mínimo privilegio sobre lo que ve el modelo en la nube. Y la cifra de +10,1 es una media de benchmark de los autores; las ganancias reales dependen de su mezcla de tareas y de cuán sensibles sean realmente sus consultas.

Estado

Elemento	Referencia	Fecha	Notas
Artículo principal	arXiv:2606.04067 (Huang, Cao, Yang)	2026-06-02	cs.CR / cs.AI; v1
Benchmark	DelegateCI-Bench	2026-06	3.167 muestras, 11 tareas, 20 tipos de tarea, WildChat + conjunto médico
Método	Reescritor por aprendizaje por refuerzo guiado por CI	2026-06	Mejor equilibrio privacidad-utilidad, hasta +10,1 de utilidad media frente a líneas base on-device
Encuadre	Integridad contextual: enviar un fragmento solo si es esencial para la tarea	2026-06	Sustituye la censura de PII por tipo, ciega al contexto

Es un resultado de investigación, no una vulnerabilidad de producto divulgada: no hay nada que parchear. La conclusión accionable es arquitectónica: decida qué llega a un LLM en la nube por necesidad, no por tipo de dato, y mida la utilidad junto con la privacidad para que su capa de minimización no borre en silencio la respuesta.