Cuando montas un sistema donde una inteligencia artificial produce algo y otra lo revisa, hay una tentación técnica que parece obviamente correcta: compartirles el contexto. Ya pagaste por procesar las instrucciones, el material de investigación y el razonamiento; reutilizarlos en el evaluador abarata la operación y va más rápido. Construyendo un sistema de agentes que escribe y publica, tomé la decisión contraria a propósito, y es de las que más ha mejorado la calidad del resultado: el que evalúa no comparte nada con el que produce.
La idea que ordena todo: un evaluador que conoce las intenciones del productor juzga las intenciones, no el resultado. Si el revisor ve el prompt con el que se escribió algo, la investigación que lo sustentaba y el razonamiento que lo guio, tenderá a aprobar lo que el productor creyó estar haciendo en lugar de lo que realmente hizo. La independencia del juicio cuesta dinero, y ese sobrecosto es exactamente lo que estás comprando.
¿Puede una IA evaluar su propio trabajo?
Puede, pero no si comparte el contexto de quien lo produjo. Un evaluador que ve las instrucciones y el razonamiento originales tiende a aprobar la intención en vez del resultado. Para que el juicio sirva, el revisor debe recibir solo la pieza terminada, igual que la verá el destinatario final, y medirla contra criterios definidos de antemano.
| Rol | Qué ve | Por qué |
|---|---|---|
| El que produce | Instrucciones, material, contexto completo | Necesita todo para hacer bien el trabajo |
| El que evalúa | Solo la pieza terminada | Debe juzgar el resultado, no la intención |
| El que corrige | La pieza y el diagnóstico del evaluador | Arregla lo señalado, sin re-litigarlo |
La fila del medio es la que casi todo el mundo optimiza mal, porque es justo donde más fácil parece ahorrar. Vamos a por qué ese ahorro sale caro.
Por qué compartir contexto corrompe el juicio
El mecanismo es sutil y por eso pasa desapercibido. Cuando un modelo evalúa una pieza y además tiene delante el razonamiento con el que se creó, ya no está leyendo el texto: está leyendo el texto más la explicación de por qué debería estar bien. Y una explicación convincente arrastra el juicio. Es lo mismo que le pasa a un autor humano releyendo lo suyo: ve lo que quiso decir, no lo que escribió.
Por eso, en el sistema que construí, el agente evaluador funciona sin caché compartida con el que redacta. Renuncio deliberadamente al ahorro de reutilizar ese contexto, que es real y medible, porque lo que compro a cambio vale más: un juicio que mira la pieza como la mirará el lector, sin la venda de las buenas intenciones. Es la misma lógica de separar responsabilidades que aplico para que la IA no toque el dinero: cada componente ve exactamente lo que necesita, ni más ni menos.
La rúbrica: hacer objetivo lo que parece subjetivo
Un evaluador independiente sin criterios definidos solo produce opiniones distintas cada vez. Lo que convierte esa independencia en algo útil es una rúbrica escrita antes, con dimensiones y pesos explícitos. En mi caso son cien puntos repartidos en cuatro dimensiones, cada una con sus comprobaciones concretas: si el texto suena a máquina, si respeta la estructura definida, si el enlazado interno cumple las reglas, y si de verdad se diferencia de lo ya publicado.
El detalle que hace que funcione no es el número total, son los pesos y los mínimos por dimensión. Un artículo puede sumar noventa puntos y aun así ser rechazado si una sola dimensión cae por debajo de su mínimo, porque un texto impecable que canibaliza otro no es publicable por muy bien escrito que esté. Definir esos pesos es una decisión editorial, no técnica: estás diciendo qué te importa de verdad, en números que no admiten interpretación.
Los suelos duros: lo que se rechaza sin discusión
Por encima de la puntuación hay una capa que no negocia. Ciertas condiciones provocan rechazo inmediato sin entrar a evaluar nada más: que el texto contenga información inventada, que use lenguaje promocional, que no alcance la extensión mínima o que le falte el bloque de respuesta directa. No importa cuántos puntos sume el resto.
Esos suelos existen porque hay fallos que no se compensan. Un artículo con un dato inventado no es un artículo con un problema, es un artículo que no se publica, y permitir que un buen puntaje en otras dimensiones lo rescate sería tener una regla que en realidad no es una regla. Toda evaluación seria necesita esa distinción entre lo que se puntúa y lo que se descarta, y conviene escribirla antes de que aparezca el primer caso incómodo.
El límite de reintentos: cuándo deja de intentarlo la máquina
La tercera pieza es la que más gente omite: decidir cuántas oportunidades tiene el sistema de arreglarse solo. En el mío hay tres caminos según la puntuación. Por encima del umbral alto, la pieza pasa directo. En la franja intermedia, un agente corrector la revisa una sola vez, no en bucle. Y por debajo del umbral bajo, no se intenta corregir: va a revisión humana.
Ese «una sola vez» es deliberado. Un sistema que reintenta indefinidamente hasta pasar su propio examen no está mejorando la calidad, está buscando la combinación que engaña al evaluador, y además puede gastar sin techo. Y el umbral bajo reconoce algo aún más importante: cuando una pieza está muy lejos del estándar, el problema no suele ser corregible con retoques, es de fondo. Ahí lo barato y lo honesto es que lo mire una persona, no que la máquina insista. Es la misma idea que explica por qué el bot no aprende solo: hay un punto donde el criterio humano es insustituible.
Cómo montar una evaluación que sirva
- Aísla al evaluador: que reciba solo la pieza terminada, sin el prompt, el material ni el razonamiento del productor. Renuncia al ahorro de compartir contexto.
- Escribe la rúbrica antes: dimensiones, pesos y comprobaciones concretas, definidos antes de ver el primer resultado, para no ajustar el criterio a lo que salió.
- Define los suelos duros: la lista corta de cosas que provocan rechazo sin discusión, por muy alto que sea el puntaje.
- Pon un límite de reintentos: una corrección, no un bucle, y un umbral por debajo del cual interviene una persona.
- Revisa la rúbrica con datos reales: si todo aprueba siempre, tu evaluador es complaciente. Qué ocurre después: con estas cuatro piezas, la calidad deja de depender del día y pasa a ser una propiedad del sistema.
Cuándo NO montar todo esto
El matiz honesto: esta maquinaria se justifica por volumen, no por elegancia. Si produces poco, la evaluación más eficiente eres tú leyendo la pieza; montar un evaluador automático para revisar dos cosas por semana es construir un tribunal para juzgar dos casos. Y si lo que produces no tiene un estándar definido, el evaluador no puede medir nada: primero se escribe el criterio, después se automatiza su aplicación, nunca al revés. El caso donde sí rinde es cuando el volumen supera lo que puedes revisar a mano con atención real, porque ahí la alternativa no es evaluación humana cuidadosa, es evaluación humana superficial, que es peor que una máquina con una rúbrica clara. Y aun entonces conviene que una muestra pase por ojos humanos: el evaluador también se degrada, y solo lo notas si lo auditas.
Errores comunes al evaluar salidas de IA
- Compartir el contexto para ahorrar: el evaluador acaba aprobando intenciones. El sobrecosto de aislarlo es lo que estás comprando.
- Evaluar sin rúbrica escrita: sin dimensiones ni pesos definidos antes, cada evaluación es una opinión distinta y el estándar se mueve solo.
- No tener suelos duros: permitir que un buen puntaje general rescate un fallo que nunca debería pasar, como un dato inventado.
- Reintentar en bucle: dejar que el sistema insista hasta aprobar su propio examen. Eso no mejora la pieza, entrena a burlar al evaluador.
- No auditar al evaluador: asumir que quien juzga está bien calibrado. Si aprueba todo, no es que produzcas perfecto, es que tu juez es complaciente.
El experimento completo, con sus números y su conclusión incómoda, está en automatizar un blog con agentes de IA.
Preguntas frecuentes
Porque lo que abaratas es justo lo que le da valor al evaluador. Con el contexto delante, el modelo lee la pieza acompañada de la explicación de por qué debería estar bien, y esa explicación arrastra el juicio hacia la aprobación. Pagas un poco más por cada evaluación y a cambio obtienes un juicio que mira el resultado como lo verá el destinatario, que es lo único que importa.
La pieza terminada y los criterios de evaluación, nada más. Nada del prompt original, del material de investigación ni del razonamiento del productor. Si necesita alguna referencia externa para comprobar diferenciación o exactitud, se le pasa como dato, no como contexto de quien produjo. La regla es simple: el evaluador ve lo que verá el destinatario, más la vara de medir.
Una. Un solo ciclo de corrección sobre el diagnóstico del evaluador, y si no alcanza el estándar, va a una persona. Los bucles de reintento parecen eficientes pero producen dos efectos malos: gasto sin techo y piezas que aprenden a satisfacer al evaluador sin mejorar de verdad. Un límite duro obliga a que el sistema produzca bien a la primera, que es donde estaba el problema.
Mirando la distribución de sus veredictos. Si casi todo aprueba con notas altas, o tu producción es sobrehumana o tu juez no está midiendo. La comprobación honesta es tomar una muestra de piezas aprobadas y leerlas tú con la misma rúbrica: si encuentras cosas que deberían haber fallado, el problema está en el evaluador, no en el productor.
No, aplica a cualquier sistema donde una IA produzca algo que otra valida: clasificaciones, respuestas de soporte, resúmenes, código. El principio es el mismo en todos los casos, porque el sesgo no viene del tipo de trabajo sino de compartir el contexto de quien lo hizo. Separa producción de evaluación, escribe la vara antes, y define qué se rechaza sin discusión.
Decisiones de diseño verificadas construyendo un sistema de agentes que produce y publica contenido en producción, a julio de 2026. Si estás montando un sistema con IA y necesitas que su control de calidad sea confiable en vez de decorativo, ese diseño es parte de lo que hago; hablemos en contacto.
La idea que sostiene la calidad
Un sistema con inteligencia artificial no produce calidad porque el modelo sea bueno, la produce porque alguien diseñó cómo se juzga lo que sale. Y ese diseño se sostiene en cuatro decisiones: aislar al evaluador de todo lo que sepa el productor, escribir la vara de medir antes de ver el primer resultado, definir la lista corta de cosas que se rechazan sin discusión, y poner un límite a los intentos de la máquina antes de llamar a una persona. La tentación siempre será compartir contexto para ahorrar, y ahí es donde se pierde lo único que hacía útil al evaluador. La independencia del juicio cuesta dinero, y es de las pocas cosas en un sistema de IA que conviene pagar sin regatear.
