Los agentes de IA ya no solo sugieren código: lo escriben, lo prueban y en algunos casos hasta lo despliegan. Aunque el problema de siempre no desapareció —un modelo puede alucinar, jurar que un test pasa cuando nunca llegó a correr— solo que ahora vive dentro de la cadena de producción, no en un chat donde el peor daño es una respuesta rara.
Y ahí apareció la respuesta obvia: si un solo juez de IA puede fallar, pon dos a revisarse entre sí. Si coinciden, hay confianza; si difieren, se re-revisa. Es la técnica que la industria llama LLM-as-a-Judge, llevada un paso más allá: en vez de que un modelo evalúe a otro para medir calidad, dos modelos jueces deciden si algo está listo para producción, sin que una persona dé el visto bueno en el camino normal. La venden como el equivalente de la regla de los dos pares de ojos que usan la aviación y la banca, ahora aplicada a agentes que aprueban su propio trabajo.
Suena bien pero cuanto más la miro, menos me convence. Una parte de esto es ingeniería sólida. Otra sigue siendo, por ahora, una promesa con forma de diagrama —con una analogía central que aguanta bastante menos peso del que parece.
¿Qué tan real es esto de tener dos jueces de IA decidiendo en lugar de una persona? Separando lo sólido de lo aspiracional, y contrastando la analogía central con lo que la evidencia dice, el panorama es más matizado de lo que el discurso sugiere.
Aquí hay que separar tres cosas: lo que es ingeniería estándar legítima, lo que es aspiracional sin construir, y lo que es una analogía que no aguanta el peso que le ponen.
Lo que sí es ingeniería real y probada
No todo en este tipo de propuestas es humo. La columna vertebral técnica —compilar, correr pruebas, verificar que el esquema coincide con el código, confirmar que la versión desplegada es la que se aprobó, hacer rollback a un tag anterior si algo falla— es práctica estándar de entrega continua, bien establecida y sin nada polémico (CI/CD). Un pipeline que bloquea un merge si las pruebas no pasan, o que revierte un despliegue si la versión en vivo no coincide con el commit aprobado, es simplemente buena ingeniería. Nada de esto depende de que un modelo de lenguaje "juzgue" nada; son verificaciones deterministas, verificables y reproducibles.
El problema no está en esa capa. Está en la pieza que se construye encima de ella: usar el consenso entre dos instancias de IA como el mecanismo que decide si algo está listo para el cliente, y reservar a la persona solo para cuando el sistema ya fracasó.
La distancia entre el diagrama y lo que existe
Una señal que conviene mirar con atención en este tipo de propuestas es cuánto de lo que se dibuja como un flujo ya en marcha realmente opera hoy. Es común encontrar, en la letra chica o en una tabla de estado honesta al final del documento, que buena parte del núcleo del sistema —el propio mecanismo de doble juicio con reintento automático, la verificación continua en producción, el contrato formal de criterios de aceptación— todavía no existe. Está marcado como pendiente, como meta, como "falta construir".
Eso no invalida la idea, pero cambia completamente cómo hay que leerla. Un diagrama de flujo con rombos de decisión y rutas de auto-corrección se ve como una máquina ya funcionando. Si la mayoría de sus piezas centrales están sin construir, lo que en realidad se está mostrando es una intención con forma de proceso, no un proceso. Y una intención necesita otro tipo de escrutinio: no "¿esto funciona bien?", sino "¿qué evidencia hay de que funcionará como se espera cuando exista?". Esa pregunta casi nunca se responde en el mismo documento que presenta la visión.
La analogía que no aguanta el peso que le ponen
Aquí está el punto que más vale la pena desarmar con cuidado, porque es el que le presta toda su credibilidad a la propuesta: la comparación con la regla de los dos pares de ojos.
Esa regla es real y funciona en la aviación, la banca y hasta en los protocolos de armas nucleares. Pero su poder no viene de "que dos entidades revisen lo mismo". Viene de algo mucho más específico: dos personas distintas, con incentivos distintos, responsabilidad legal u organizacional diferenciada, y frecuentemente de departamentos separados. En la banca, una persona inicia una transacción y otra, independiente, la revisa y verifica, de modo que ninguna persona sola puede ejecutar una acción de alto riesgo sin supervisión ajena. La independencia no es solo técnica, es de incentivos: a nadie le conviene que el fraude pase, y cada quien responde por su propia decisión.
Nada de esa estructura se traslada de forma automática a "dos instancias de un modelo de lenguaje con prompts distintos". Y la investigación sobre modelos usados como jueces (LLM-as-judge) no es tranquilizadora en este punto. Se ha documentado que estos jueces comparten sesgos sistemáticos: preferencia por ciertas posiciones en el texto, tendencia a favorecer respuestas más largas, y sesgo de auto-favorecimiento hacia salidas que se parecen a las que el propio modelo generaría. Un trabajo que comparó paneles de jueces de IA encontró que estos paneles solo logran reducir el sesgo compartido cuando están compuestos por familias de modelos distintas y disjuntas — no alcanza con cambiar el prompt de la misma arquitectura subyacente y llamar "independiente" al segundo revisor.
Más revelador todavía: estudios recientes que midieron el acuerdo entre jueces de IA distintos encontraron una tasa de coincidencia notablemente más baja que la consistencia de un mismo juez consigo mismo en repeticiones. Es decir, dos jueces de IA distintos se parecen menos entre sí de lo que uno esperaría — y esa tasa de acuerdo, incluso en condiciones favorables, quedó por debajo de las líneas base de acuerdo entre evaluadores humanos en configuraciones controladas. La expectativa de que "es estadísticamente improbable que dos jueces independientes alucinen exactamente lo mismo" suena razonable, pero no está respaldada por los datos que hoy existen sobre cómo se comportan estos sistemas en la práctica; es una intuición presentada con la seguridad de un hecho comprobado.
Hay, además, un límite que ninguna cantidad de jueces adicionales resuelve: si el criterio contra el que se evalúa algo —el contrato, la especificación, el caso de aceptación— no contempla una situación límite, ningún juez la va a detectar, estén de acuerdo entre sí o no. El consenso entre evaluadores cubre errores de ejecución contra una definición dada; no cubre errores en la definición misma del problema. Confundir "los dos jueces coincidieron" con "esto es correcto" es exactamente el tipo de salto que la regla de los dos pares de ojos, aplicada entre humanos, nunca pretendió cubrir tampoco — pero que en su versión humana se compensa con juicio, contexto y responsabilidad real, cosas que dos instancias de un modelo no aportan de la misma manera.
La pregunta que vale la pena hacerse
Ninguno de estos argumentos dice que automatizar más la verificación sea mala idea. Los controles deterministas, la entrega progresiva y los sistemas de reintento acotado con escalamiento son prácticas sólidas y vale la pena adoptarlas. El punto es más específico: la palabra "confianza" no se gana solo con arquitectura elegante ni con una analogía prestada de otro dominio. Se gana con evidencia de que el mecanismo concreto —dos instancias de IA, con la diversidad de modelos y la calibración que de verdad tengan— se comporta como se promete, medido contra una vara real, no contra su propio diagrama de flujo.
Antes de reemplazar el criterio de una persona por un consenso de máquinas, la pregunta que hay que responder no es "¿suena bien la arquitectura?". Es "¿qué tan seguido estos dos jueces, en la práctica, están de acuerdo por las razones correctas — y qué tan seguido lo están simplemente porque comparten el mismo punto ciego?".
Top comments (0)