Partial Evidence Bench: cuando los agentes responden bien pero con información incompleta

El 8 de mayo, investigadores publicaron en arXiv un benchmark que pone nombre a un problema que muchos equipos que trabajan con agentes empresariales ya habían intuido pero no sabían cómo medir: un agente puede respetar escrupulosamente los controles de acceso y, al mismo tiempo, devolver una respuesta que parece completa cuando en realidad le falta información crítica que el usuario simplemente no tiene autorización para ver.

El paper se llama Partial Evidence Bench y describe el fenómeno como unsafe completeness: el sistema filtra correctamente los datos restringidos, pero no avisa de que los ha filtrado. El resultado es una respuesta confiada y aparentemente exhaustiva construida sobre evidencia parcial.

Qué mide exactamente

El benchmark incluye 72 tareas distribuidas en tres familias de escenarios:

• Due diligence: análisis de empresas o activos donde parte del expediente está bajo restricción.
• Auditoría de cumplimiento: revisiones regulatorias donde ciertos documentos solo son accesibles a roles concretos.
• Respuesta a incidentes de seguridad: investigaciones forenses en las que los logs o alertas relevantes pueden estar fuera del alcance del agente.

Cada tarea incluye un corpus particionado por listas de control de acceso (ACL), una respuesta oracle completa (como si no hubiera restricciones), una respuesta oracle para la vista autorizada, y estructuras de referencia para evaluar la calidad de los informes de brecha (gap reports). La evaluación se articula sobre cuatro ejes: corrección de la respuesta, conciencia de incompletitud, calidad del informe de brechas y comportamiento de completitud insegura.

El hallazgo central: el silencio es el peor escenario

Los resultados de las líneas base incluidas en el repositorio son contundentes: el silent filtering —es decir, filtrar la evidencia restringida sin mencionar que existe— resulta "catastróficamente inseguro" en todas las familias de escenarios. En cambio, un comportamiento de fail-and-report explícito —el agente indica que existe evidencia fuera de su alcance y detalla qué tipo de información falta— elimina el riesgo de completitud insegura sin que el sistema caiga en la abstención trivial de simplemente negarse a responder.

En otras palabras, no se trata de que el agente diga «no lo sé» a todo. Se trata de que diga «esto es lo que puedo ver, y esto es lo que no puedo ver». La distinción parece obvia enunciada así, pero la mayoría de los sistemas actuales no la implementan de forma consistente.

Las pruebas preliminares con modelos reales muestran que el comportamiento varía de forma significativa según el modelo, lo que sugiere que no es un problema que se resuelva solo aumentando capacidad o escala.

Por qué importa para quienes construyen con Claude Code o agentes MCP

Este trabajo es relevante para cualquier equipo que esté desplegando agentes sobre sistemas de recuperación de información con permisos diferenciados. En el contexto del ecosistema Claude, esto incluye arquitecturas donde Claude Code orquesta subagentes con acceso a diferentes MCP servers, o donde los skills invocan herramientas con alcances de autorización distintos.

El escenario típico: un agente de cumplimiento conectado vía MCP a un repositorio documental donde algunos contratos están restringidos a la capa legal. Si el agente recupera solo los documentos accesibles y emite un dictamen sin indicar que existe documentación fuera de su alcance, el analista puede tomar una decisión errónea con total confianza. El benchmark formaliza exactamente ese riesgo.

La metodología de gap reports —estructurar explícitamente qué información faltaba y por qué— es un patrón que los equipos de integración deberían considerar como requisito de diseño, no como mejora opcional.

Una brecha en cómo se evalúa la fiabilidad de los agentes

Hasta ahora, la mayoría de los benchmarks de agentes empresariales se centran en si el agente completa la tarea o no. Partial Evidence Bench introduce una dimensión diferente: si el agente sabe lo que no sabe, y si lo comunica. Es una distinción que los equipos de QA y seguridad necesitarán incorporar a sus procesos de validación a medida que los agentes asuman más responsabilidad en flujos de trabajo con datos sensibles.

Desde ElephantPink, consideramos que este benchmark llena un hueco real en la evaluación de agentes en entornos regulados. El patrón fail-and-report que propone debería convertirse en un estándar de diseño, no en un añadido de última hora.