El agente no puede ser su propio auditor

Un agente realiza la tarea, explica lo que hizo, ejecuta sus pruebas, interpreta los resultados y declara que el trabajo está listo. El flujo parece eficiente: una única inteligencia preserva todo el contexto y resuelve el ciclo completo.

También concentra en un mismo actor la producción, selección de pruebas, interpretación y aceptación. Cuando hay un error de premisa, incentivo, contexto o autoridad, el mismo fallo puede atravesar todas las etapas de una narrativa coherente.

Separar la ejecución de la auditoría no significa eliminar la IA de la verificación. Significa evitar que la declaración final dependa únicamente del ejecutor evaluado.

Resumen ejecutivo

Un segundo modelo puede proporcionar críticas útiles y patrones. evaluador-optimizador Funcionan cuando hay criterios claros y mejoras mensurables. Sin embargo, separar llamadas no crea independencia en sí misma. La evaluación debe estar vinculada al mismo subject, utilizar diferentes criterios y autoridades y preservar evidencia que otro actor pueda inspeccionar.

banco de papel, por ejemplo, utiliza rúbricas jerárquicas y creó un punto de referencia separado para evaluar su criterio por modelo. Este marco reconoce que el evaluador también necesita ser medido. En el límite informado, el mejor agente probado logró una puntuación promedio del 21 % y no superó la línea de base humana; el resultado pertenece a la tarea, el andamio y los modelos examinados, no a todos los agentes.

En FORGE, la regla es: el ejecutor puede probar y autoevaluarse; no puede concederse por sí solo la authority final sobre propiedades críticas.

Cuatro roles que a menudo se confunden

Una persona o sistema puede acumular roles con bajo riesgo. En caso de alto riesgo, la separación aumenta. No se trata de un organigrama; es impedir que la autoridad circule.

Por qué falla la autoevaluación

error compartido

El agente crea una implementación basada en una interpretación incorrecta y luego escribe pruebas que reproducen la misma interpretación. Todo se vuelve verde y la necesidad sigue insatisfecha.

Selección favorable

El ejecutor elige ejemplos, logs o métricas que muestran éxito. Incluso sin intención de engañar, tiende a explorar el camino que mejor conoce.

juez frágil

Un evaluador de modelos puede preferir estilo, extensión o explicaciones convincentes. Si el grader no se ha calibrado frente a humanos o controles deterministas, la calificación añade una precisión aparente.

Subject divergente

La prueba se ejecuta en un commit, entorno o configuración diferente del que se publicará.

Autoridad indebida

El sistema interpreta su propia puntuación como permiso para publicar, enviar o promocionar. Medición y decisión se convierten en el mismo mecanismo.

La independencia tiene dimensiones

No basta con utilizar “otro agente”. Tarifa:

• identidad — ¿Es otra sesión, función, persona u organización?
• contexto — ¿recibió la respuesta del ejecutor o la reconstruyó a partir del subject?
• método — ¿Utiliza criterios independientes o repite la misma justificación?
• herramienta — ¿observar sus propios registros y pruebas o fuentes externas?
• incentivo — ¿Su éxito depende de aprobar rápidamente?
• autoridad — ¿Puedes bloquear o simplemente aconsejar?

Se gradúa la independencia. Una prueba determinista escrita antes de la implementación puede ser más independiente que un segundo modelo al que se le ha ordenado que esté de acuerdo con el primero.

Una arquitectura de seguridad mínima

1. Especificación fuera del ejecutor

La propiedad y los criterios de aceptación existen antes de la solución. El ejecutor puede proponer correcciones, pero no reescribe silenciosamente lo que se considerará un éxito.

2. Primero los controles deterministas

El schema, los types, las propiedades, la seguridad, el diff y los invariants reducen el espacio de interpretación. El resultado por modelo complementa, no borra, un rojo determinista.

3. Evaluaciones versionadas

El banco, los graders, los umbrales, el entorno y la agregación pertenecen a una sola versión. Siguen siendo visibles los casos negativos y las clases de riesgo, no sólo el promedio.

4. El revisor reconstruye el claim

Recibe el subject y las evidencias, identifica límites y verifica si el claim sigue el método. Ante un cambio material, debe poder discrepar y bloquear.

5. El aprobador acepta el riesgo residual

La aceptación registra persona o autoridad, fecha, subject y excepciones. El ejecutor nunca asume la aprobación por falta de respuesta.

Dónde la IA puede evaluar la IA

La IA es valiosa para ampliar la cobertura:

• generar casos contradictorios;
• patrones de fracaso grupal;
• comparar la respuesta con la rúbrica;
• revisar traces extensos;
• buscar inconsistencias entre especificaciones, código y prueba;
• proponer explicaciones y próximos experimentos.

El problema no es que el evaluador sea un modelo. Es el resultado de no tener calibración, límites ni posibilidad de impugnación.

Utilice una combinación de graders:

Evaluar al evaluador

PaperBench no se limitó a juzgar por modelo; construyó un punto de referencia para el juez. Este principio es generalizable: antes de confiar en el evaluador, mida cómo se comporta en ejemplos conocidos, casos ambiguos y fallas críticas.

Preguntar:

• ¿Estás de acuerdo con los expertos en qué tarifa y clase?
• ¿Cuánto cuestan los falsos positivos y negativos?
• ¿Es sensible a la posición, estilo o identidad del modelo?
• ¿Puedes explicar el criterio con evidencia?
• ¿Qué cambio invalida su calibración?
• ¿Existe un camino de recursos humanos?

Un juez sin evaluación es otro ejecutor con otro nombre.

Un protocolo de relaciones públicas humano + IA

1. El autor humano o PO establece la propiedad y los criterios.
2. El agente ejecutor implementa y registra las decisiones.
3. El conjunto determinista comprueba invariantes y casos negativos.
4. El agente revisor inspecciona diff, especificaciones, pruebas y evidencia en un contexto separado.
5. Seguridad especializada/control de calidad verifica las propiedades aplicables.
6. La autoridad humana acepta o rechaza el riesgo residual.
7. Fusione e implemente subject y receipts preservados.
8. La producción retroalimenta las regresiones, sin borrar la historia.

No todas las relaciones públicas requieren ocho personas. Los roles pueden ser mecanismos y los pasos proporcionales al riesgo. El contrato importa más que el número de participantes.

Lo que este artículo prueba y lo que no prueba

La investigación y la práctica pública muestran que el evaluador-optimizador puede mejorar los resultados cuando existen criterios claros; PaperBench demuestra una arquitectura que también evalúa al juez. El paquete FORGE delimita que las fuentes de prueba/evaluación no definen umbrales universales y que los controles deben estar vinculados al contexto. [R3-C1]

Esta evidencia no prueba que todos los sistemas multiagente sean superiores, ni que la revisión humana sea infalible. Las personas comparten prejuicios y las organizaciones también crean una autoridad circular. Es necesario diseñar, medir y declarar la independencia.

Conclusión

El agente puede explicar, probar y criticar su propio trabajo. Esta capacidad reduce los costos y acelera la retroalimentación. No debería convertirse automáticamente en autoridad para declarar que se ha demostrado una propiedad crítica.

La garantía comienza cuando se fija el subject, los criterios sobreviven al ejecutor, el verificador puede suspender el trabajo y el aprobador acepta nominalmente el riesgo residual. El objetivo no es desconfiar de la IA por principio. Se trata de generar una confianza que no dependa de una sola voz, incluso cuando esa voz sea brillante y convincente.

Lectura anterior: Evidencia antes del adjetivo. Siguiente lectura sugerida: Humano responsable, ejecutando IA.