La promesa de los sistemas de agentes de IA es que no se limiten a ejecutar tareas fijas, sino que aprendan, acumulen experiencia y mejoren con el tiempo. Para lograrlo, muchos diseños emplean una biblioteca de habilidades: el agente compone sus respuestas a partir de fragmentos de conocimiento, rutinas de ejecución y heurísticas que han funcionado en el pasado. Esta arquitectura es especialmente atractiva en entornos empresariales, donde se necesita automatizar procesos complejos y adaptarse a datos cambiantes. Sin embargo, una biblioteca que crece sin control también acumula ruido. Las habilidades que ya no sirven, que son contradictorias o que solo funcionaban en una situación muy concreta, acaban degradando el rendimiento global. Por eso los sistemas autoevolutivos necesitan un mecanismo de retirada, un curador capaz de eliminar lo que no aporta valor. En Q2BSTUDIO solemos compararlo con una buena gobernanza del código: no basta con añadir funciones; hay que atreverse a borrar. Pero hay un matiz crucial: si el evaluador que decide qué se retira está sesgado, el curador se convierte en un curador ciego.
Ese curador automático funciona gracias a una señal de evaluación. Cuando una habilidad produce un resultado correcto, se refuerza; cuando falla, se debilita hasta desaparecer. La condición mínima para que el sistema sea viable es que la biblioteca de habilidades nunca haga que el agente funcione peor que un agente sin ninguna habilidad. Esta línea base no es negociable. En tareas con una respuesta objetiva, un ejecutor de código, un test unitario o un verificador formal pueden detectar el fallo con precisión. Pero en tareas sin referencia, como redactar un informe, resumir una conversación o evaluar la calidad de un texto, no existe una respuesta correcta externa. La evaluación cae entonces en manos de un juez de lenguaje, normalmente un modelo de lenguaje grande entrenado para puntuar o comparar resultados. Y ahí es donde la cadena de confianza empieza a romperse.
Un juez de lenguaje no es un oráculo. Puede tener sesgos sistemáticos: preferir textos largos, penalizar estructuras poco habituales, o ser demasiado condescendiente con errores factuales. El estudio que da origen a esta reflexión distingue dos tipos de ruido. Uno es el ruido simétrico: el juez a veces acierta y a veces falla, pero no favorece sistemáticamente a los malos resultados. Ese ruido, aunque incómodo, no destruye el mecanismo de retirada. El otro es el sesgo de falso aprobado: un fallo real que el juez marca como éxito. Este segundo caso es mucho más peligroso, porque el curador no ve el fracaso y, por tanto, no retira la habilidad defectuosa. El sistema puede quedarse atrapado en una zona en la que todas las malas habilidades reciben luz verde y la biblioteca se llena de inutilidades sin que nadie intervenga.
Lo más relevante es que existe un umbral muy marcado. Mientras el porcentaje de errores que reciben aprobación se mantiene bajo, el curador sigue haciendo su trabajo. Pero al superar cierto punto, el mecanismo deja de funcionar por completo. Y no es que empeore gradualmente: se apaga. Lo que hace que este resultado sea contraintuitivo es que no se trata de un problema de cantidad de datos. Más datos de entrenamiento, más ejemplos o más evaluaciones no permiten cruzar el umbral si el juez sigue aprobando fallos. El sesgo no se promedia; se convierte en una característica estructural del sistema. Para una empresa que pretende escalar soluciones de IA, esta idea es fundamental: una métrica agregada de calidad puede seguir estable mientras el mecanismo de seguridad interno ya se ha desactivado.
La investigación también muestra que el problema del mecanismo es universal. Aparece en distintos dominios, con tasas de fallo diferentes y con distintos tipos de agentes. Solo lo evitan los evaluadores con una tasa de falsos aprobados casi nula, algo que en la práctica solo se consigue con verificadores externos o con sistemas de comprobación muy estrictos. Es decir, el fallo no depende de la tarea, sino de la relación entre el evaluador y la realidad que evalúa. Un juez que no puede distinguir un fallo de un acierto no es solo un evaluador ruidoso: es un interruptor que desconecta la supervisión. La consecuencia inmediata es que el curador se vuelve ciego. Sigue presente, sigue procesando habilidades, pero ya no distingue entre las buenas y las malas.
Imaginemos una fábrica en la que un supervisor de calidad nunca rechaza una pieza defectuosa porque su sistema de medición está mal calibrado. La línea de producción no se detiene; los informes de producción siguen mostrando un ritmo aceptable; pero las piezas defectuosas se acumulan en el inventario. Llega un momento en que el almacén está lleno de producto inservible y nadie recuerda cuándo empezó el problema. Algo parecido ocurre con las bibliotecas de habilidades. Si el juez aprueba fallos, las malas habilidades no se retiran, se acumulan, y el sistema pierde su salvaguarda estructural. Lo más peligroso es que los indicadores externos no siempre reflejan el daño: la calidad general puede mantenerse porque la síntesis de nuevas habilidades sigue funcionando, enmascarando el hecho de que la poda se ha detenido.
En el mundo empresarial, esta distinción entre mecanismo y resultado es clave. Las organizaciones suelen medir el rendimiento de un agente por la calidad de sus entregas, no por la salud interna de su biblioteca de habilidades. Si un sistema empieza a generar informes que parecen correctos pero contienen errores no detectados, la primera señal de alarma no aparecerá en la precisión media, sino en la desaparición silenciosa de la capacidad de corregir. Por eso, cuando en Q2BSTUDIO diseñamos soluciones de IA para clientes, insistimos en que la gobernanza del modelo sea parte de la arquitectura desde el primer día, no una capa añadida al final. Un agente autónomo sin un curador fiable es un riesgo operativo, por muy buenas que parezcan sus métricas.
Nuestra experiencia como empresa de desarrollo de software nos ha mostrado que la evaluación de los modelos de lenguaje debe tratarse con el mismo rigor que una auditoría de ciberseguridad. No basta con confiar en el criterio del modelo; hay que auditar al juez. La propuesta de inyectar defectos conocidos en el flujo de evaluación es una forma práctica de hacerlo: se toman habilidades que sabemos que fallan, se introducen en el sistema y se comprueba si el juez las detecta. Si el juez las aprueba, sabemos que está del lado equivocado del umbral y que la retirada de habilidades está desactivada. Esta prueba es barata, se puede ejecutar antes del despliegue y proporciona información muy valiosa sobre los límites del sistema. Es una práctica que conecta directamente con la ciberseguridad: atacar el sistema con casos defectuosos para conocer sus puntos ciegos antes de que lo haga un problema real.
Las implicaciones para el desarrollo de aplicaciones a medida son profundas. Cuando una compañía encarga una plataforma de agentes IA, no está comprando un modelo, está comprando un sistema de comportamiento. Ese sistema necesita políticas de retirada, observabilidad y mecanismos de corrección. En Q2BSTUDIO trabajamos con arquitecturas en cloud AWS/Azure, con pipelines de datos y con cuadros de mando de BI/Power BI, porque todos esos elementos forman parte de la infraestructura que permite vigilar el comportamiento de un agente. No se trata de añadir más inteligencia, sino de saber cuándo una capacidad debe retirarse. Un cuadro de mando que muestre la tasa de aprobación del juez y la tasa de retirada de habilidades puede alertar a tiempo de que el curador se ha desconectado, incluso cuando las métricas de calidad todavía no se han movido.
La conclusión práctica es que los operadores de sistemas autoevolutivos no pueden esperar a que el rendimiento empeore para detectar un juez sesgado. En el momento en que una evaluación sin referencia depende de un modelo de lenguaje, la pregunta correcta no es 'cuánto acierta', sino 'qué pasa cuando se equivoca'. Si los errores se aprueban de forma sistemática, el sistema no tendrá manera de jubilar sus malas habilidades. Y aunque las métricas de resultado se mantengan, la capacidad de autoevaluación estará rota. La auditoría de inyección de defectos ofrece una forma rápida de conocer el terreno antes de pisarlo. En un momento en que los agentes de IA empiezan a asumir tareas críticas, esta distinción entre ruido y sesgo, y entre mecanismo y resultado, debería formar parte del lenguaje común de cualquier equipo de ingeniería.
En definitiva, el curador ciego es un recordatorio de que la autonomía no elimina la necesidad de supervisión; la multiplica. Un agente capaz de aprender también debe ser capaz de olvidar. Y para que el olvido sea útil, algo tiene que ver el fallo. Si ese algo es un juez sesgado que aprueba todo, el sistema pierde su capacidad de renovación sin hacer ruido. La buena noticia es que existen métodos prácticos para detectar el problema antes de que cause daño. La mala noticia es que la mayoría de las empresas aún no los aplica. Construir agentes de IA responsables exige mirar donde nadie mira: no solo a la calidad de las respuestas, sino a la salud del mecanismo que decide qué habilidades merecen seguir vivas. En Q2BSTUDIO ayudamos a las organizaciones a hacer esa mirada con rigor técnico, combinando desarrollo de software, inteligencia artificial, ciberseguridad y datos para que la evolución autónoma no se convierta en un accidente silencioso.
