Agentes críticos: por qué un sistema de IA sin revisor falla sistemáticamente

Hay un patrón de fallo que he visto repetirse en casi todos los sistemas de agentes que se construyen deprisa. El agente funciona. Funciona bien durante días. Funciona bien durante semanas. El equipo coge confianza. Se añaden más flujos, más volumen, más dependencias. Y entonces, sin que nadie lo note de inmediato, empieza a fallar. Los errores son pequeños al principio. Una categorización incorrecta aquí, un resumen impreciso allá. El equipo no lo ve porque nadie está mirando esa capa. La confianza que se ganó en las primeras semanas actúa como anestesia. Y cuando el error grande llega, llega en el peor momento posible: en un entregable al cliente, en un informe que ya fue enviado, en una decisión que ya se tomó.

Este artículo trata del componente que más consistentemente se omite en los sistemas de agentes: el agente crítico. No el que produce. El que revisa. Cada crítico rinde mejor con unas skills propias que le fijen el criterio.

El problema de fondo: producir sin revisar

Un agente diseñado para producir output tiene un problema estructural. El mismo componente que genera el contenido no puede evaluar de forma objetiva si ese contenido es correcto. No porque los modelos sean malos. Sino porque cualquier sistema que produce y evalúa con el mismo proceso de razonamiento tiende a validar sus propios sesgos.

En el primer sistema sin critic que montamos, teníamos un agente de análisis de contratos que llevaba tres semanas en producción sin incidentes. El equipo estaba satisfecho. Los outputs eran rápidos, el formato era correcto y los resúmenes tenían buena pinta. Lo que nadie había verificado sistemáticamente era si las cláusulas identificadas como «críticas» eran realmente las más relevantes para el negocio. Cuando revisamos una muestra de 40 contratos procesados, encontramos un 23% con clasificaciones que un abogado hubiera marcado como incorrectas. No errores de formato. Errores de juicio.

El agente no había fallado. Había hecho exactamente lo que estaba diseñado para hacer. El problema era que nadie había diseñado el componente que verificara si lo hacía bien.

Qué es el patrón critic

El patrón critic es simple en concepto y no trivial en implementación. Consiste en un agente separado, estructuralmente distinto del que produce, cuya única función es evaluar el output.

La configuración técnica que usamos en producción define al critic con dos restricciones fundamentales: trabaja en modo planificación —puede razonar pero no ejecutar acciones con efecto— y tiene bloqueadas las herramientas de escritura, edición y ejecución de comandos. Puede leer todo. No puede modificar nada.

Esa asimetría no es arbitraria. Es el corazón del diseño.

Un critic que puede modificar lo que está revisando contamina su propia evaluación. Si el critic puede editar el documento mientras lo analiza, ya no hay separación entre producción y revisión. La independencia del juicio requiere independencia de herramientas. No es una cuestión de confianza en el modelo. Es una decisión arquitectónica.

El critic lee artefactos, analiza coherencia, detecta inconsistencias con los criterios definidos, y emite un veredicto estructurado: aprobado, aprobado con observaciones, o rechazado con justificación específica. Solo emite juicio. Nunca actúa.

Dos formas de desplegarlo en producción

En los sistemas que tengo en producción actualmente, el critic aparece en dos configuraciones distintas. Cada una sirve para un problema diferente.

Enfoque A: critic único al final del flujo. Un solo agente crítico revisa el output completo antes de que salga del sistema. Es el modelo más sencillo y funciona bien en flujos lineales con output acotado. En el sistema de 28 agentes al que hago referencia habitualmente, este critic final actúa como puerta de salida: nada llega al destinatario sin su validación. Es una barrera simple, efectiva y fácil de auditar.

Enfoque B: critics distribuidos por etapas. Para flujos más complejos, un solo critic al final no es suficiente. Los errores que se cuelan en las primeras etapas se amplifican a medida que el flujo avanza. Revisarlos al final es más costoso que detectarlos donde nacen. En el workflow de desarrollo de software que tenemos en producción, el flujo pasa por cinco critics secuenciales: un critic de producto revisa que los requisitos sean coherentes antes de entrar en diseño; un critic de arquitectura valida que las decisiones técnicas sean sostenibles antes de escribir código; un critic de seguridad ejecuta el análisis de amenazas antes de ir a staging; un critic de calidad verifica los tests antes del despliegue; y un critic final revisa el conjunto completo antes del release. Cada critic ve artefactos diferentes. Cada uno tiene criterios específicos. Ninguno tiene acceso a modificar lo que revisa.

Critics inline vs critics de puerta

Hay una distinción que marca una diferencia operativa significativa: critics que actúan durante la ejecución frente a critics que actúan al final de una etapa.

Un critic de puerta —o gate critic— revisa cuando el trabajo de una etapa está completo. Sencillo de implementar, fácil de auditar. Pero si el error está en el razonamiento intermedio, el critic de puerta lo detecta cuando ya hay mucho trabajo acumulado encima.

Un critic inline interviene en mitad del proceso. Mientras el agente de producción desarrolla un análisis, el critic inline revisa cada bloque de razonamiento antes de que se use como base para el siguiente. Es más costoso computacionalmente. Pero cuando vimos los datos de rework —trabajo deshecho por errores detectados tarde—, la diferencia era clara: los flujos con critics inline reducían el rework entre un 30 y un 50% respecto a los flujos con critic solo al final. No es una estimación teórica. Es la medición en producción de un mismo tipo de tarea durante dos meses, con y sin critic inline activado.

La decisión de usar critic inline o critic de puerta depende del coste relativo de rehacer trabajo tardío frente al coste de procesar la revisión inline. Para tareas donde los primeros pasos determinan fuertemente los últimos, el critic inline se paga solo.

El critic de seguridad como caso especial

En el dominio de desarrollo de software, hay un tipo de critic que tratamos como obligatorio: el critic de seguridad con análisis STRIDE.

STRIDE es un modelo de análisis de amenazas desarrollado por Microsoft que categoriza los riesgos en seis tipos: suplantación de identidad, manipulación de datos, repudio, divulgación de información, denegación de servicio y escalada de privilegios. Para cualquier nueva feature que llegue al pipeline, el critic de arquitectura de seguridad ejecuta un análisis STRIDE completo antes de aprobar el paso a staging.

La regla es sin excepción: si el critic de seguridad no emite aprobación, la feature no avanza. No importa la presión del calendario. No importa que el equipo esté convencido de que «es un cambio pequeño». El critic de seguridad es el único componente del sistema que puede detener unilateralmente el flujo sin posibilidad de override técnico.

Esto no es burocracia. Es la consecuencia de haber visto lo que pasa cuando el análisis de seguridad se hace a posteriori: se encuentran vulnerabilidades cuando hay código en producción, cuando hay que deshacer trabajo hecho, cuando el cliente ya tiene acceso a la interfaz. El critic de seguridad inline no añade tiempo al proceso. Elimina el tiempo que se pierde remediando en producción.

Por qué cualquier agente se degrada sin critic

Un sistema de agentes sin critic no es un sistema estable. Es un sistema con degradación programada.

Los errores no aparecen de forma dramática. Aparecen de forma gradual. El primer error es pequeño y pasa desapercibido. El segundo también. La confianza en el sistema crece porque el rendimiento visible —velocidad, volumen, formato— sigue siendo bueno. Lo que no se mide no se ve.

Y luego llega el error que sí se ve. El que tiene consecuencias reales. El que ocurre cuando la confianza en el sistema es máxima y la vigilancia es mínima. El que se podría haber detectado semanas antes si hubiera habido un critic revisando los outputs intermedios.

Hay un segundo problema menos obvio: sin critic, no hay forma de saber si el sistema está mejorando o empeorando. No tienes datos. Tienes impresiones. Y las impresiones son un mecanismo de evaluación notoriamente poco fiable para sistemas que procesan cientos de outputs a la semana.

El critic no solo previene errores. Genera los datos que permiten mejorar el sistema. Cada rechazo del critic es información: qué tipo de output falla, en qué condiciones, con qué frecuencia. Sin esa señal, el loop de mejora no cierra.

La puerta que no se puede saltarse

En los sistemas que operamos en producción, el veredicto del critic no es una recomendación. Es una condición de paso.

Un output que no pasa el critic no puede avanzar. No puede ser enviado, publicado, registrado ni usado como input para la siguiente etapa. La arquitectura lo impide. No hay override manual disponible para los operadores del sistema. Si alguien quiere forzar el paso de un output rechazado, tiene que ir a la configuración del critic, modificar los criterios con justificación auditada, y volver a ejecutar la revisión.

Esa fricción es intencionada. El critic como gate duro funciona porque es un gate duro. Un critic que se puede saltar por presión operativa no es un critic. Es un proceso consultivo que la gente ignora cuando tiene prisa.

La diferencia entre un sistema con critic real y un sistema con critic cosmético es exactamente esa: si el rechazo del critic detiene el flujo o si solo genera una notificación que alguien puede ignorar.

Lo que no voy a explicar aquí

Entender qué es un agente crítico y por qué los sistemas sin él fallan de forma sistemática es la parte pública de este tema. Es lo que cualquier directivo debería saber antes de aprobar un presupuesto para un sistema de agentes en producción.

Lo que no voy a detallar aquí es cómo diseñar la cadena de critics específica para tu flujo. Cuántos critics necesitas, dónde colocarlos, qué criterios debe usar cada uno, cómo manejar los falsos negativos, cómo calibrar la sensibilidad para que no bloquee todo ni deje pasar demasiado. Eso depende de tu sistema, de tus datos, de tus tolerancias al error y de lo que pasa si un error llega al cliente. No hay una plantilla universal. Hay principios que se aplican con criterio.

Para profundizar en la capa de especialización que hace posible estos sistemas, puedes leer sobre cómo funcionan los agentes especialistas. Y si te interesa el lado del coste operativo de no hacer esto bien desde el principio, el artículo sobre los errores más comunes al implementar IA en empresa cubre el patrón completo.

Preguntas frecuentes