Un agente de IA crediticio solo modifica su arnés: el gate dejó pasar 144 de 7449 cambios

Un agente LLM que aprende por sí solo en un pipeline de crédito puede adaptarse a una nueva interpretación de las reglas. Pero si se reescribe a sí mismo, el organismo supervisor pierde aquello que debe comprobar: un cambio con nombre, una prueba registrada y una firma de aprobación. Los autores de un nuevo trabajo en arXiv proponen una restricción estricta. Solo puede evolucionar el arnés del agente, mientras que los pesos del modelo permanecen congelados. En la simulación, de 7449 cambios candidatos, el gate de admisión dejó pasar 144, y ninguno empeoró el error en el historial reservado. La versión de control, con la verificación que aplicaría un sistema sin restricciones, dejó pasar 309 cambios dañinos.

Qué se permite modificar exactamente

El arnés (harness) abarca en el artículo tres capas: el texto de las instrucciones, la lógica de llamada a herramientas y la composición de primitivas. Todo lo demás es intocable. La idea es que cualquier adaptación se convierta en un diff con su motivo y una prueba asociada. El revisor no necesita analizar el comportamiento del modelo: lee un cambio concreto.

Sobre esta restricción se construye un motor de dos bucles. Todos los candidatos pasan por un único gate de admisión, que escribe un registro en cadena de hashes antes del despliegue. Ese registro no se puede retocar a posteriori sin romper la cadena. Para el auditor, es un rastro listo para usar: qué se cambió, por qué y con qué prueba se admitió.

Qué mostró la simulación

La salvedad principal: el gate se midió con un agente simulado, y los cambios no los propuso un modelo de lenguaje, sino una búsqueda con semilla fija. Es una prueba del mecanismo de admisión, no del comportamiento de LLM reales. El diseño del experimento incluye tres familias de reinterpretación supervisora de las reglas, tres niveles de gravedad y 10 ejecuciones por celda, es decir, 90 ejecuciones por configuración.

• El gate admitió 144 de 7449 cambios candidatos.
• Ninguno de los cambios admitidos empeoró el error en el historial reservado.
• En todas las celdas de gravedad baja y media, la tasa de falsos positivos volvió al nivel del oráculo sin que aumentaran los flags omitidos.
• Al sustituir el gate por una verificación estándar («menos errores en trazas recientes»), se admitieron 309 cambios dañinos.
• En ese modo, los flags omitidos superaron el 10% en 49 de las 90 ejecuciones.

El último punto revela el mecanismo del fallo. Los falsos positivos de un sistema así no bajaban porque el agente fuera más preciso. Simplemente debilitaba el filtro, y los errores en trazas recientes disminuían a costa de omitir casos problemáticos.

Hay además un resultado poco intuitivo. Si los candidatos se evalúan con el etiquetado anterior al cambio, el gate los rechazó a todos. La nueva interpretación de las reglas debe codificarse como una regla que reetiquete el historial. De lo contrario, la verificación compara al agente con una verdad obsoleta y bloquea cambios correctos.

Dónde choca el gate con su techo

El agente corrigió de forma local los cambios paramétricos y los de ámbito de aplicación. El cambio estructural solo se resolvía sustituyendo una primitiva. En el nivel más alto de gravedad estructural, la tolerancia fija del gate bloqueó la sustitución correcta en la mitad de las ejecuciones. La conservadurismo que protege frente a los cambios dañinos cuesta aquí un cambio útil. Todo apunta a que la tolerancia habrá que ajustarla por separado para los cambios estructurales.

Los autores también contrastan los mecanismos con los requisitos del EU AI Act para el scoring crediticio de alto riesgo. Señalan, además, que las directrices estadounidenses de gestión del riesgo de modelos de abril de 2026 excluyen la IA agéntica de su ámbito de aplicación. El marco regulatorio para estos sistemas sigue vacío en EE. UU., y la auditabilidad hay que construirla por cuenta propia.

Cómo aplicarlo en la práctica

Un equipo que implante agentes en scoring o compliance debería fijar de antemano el límite de lo modificable: instrucciones, herramientas y composición de primitivas en el repositorio, y los pesos fuera de la zona de cambios. Cada modificación debe tener un motivo, una prueba y una entrada en un registro inmutable antes del despliegue. El criterio de admisión debe calcularse sobre un historial reetiquetado según la nueva regla, y conviene vigilar por separado los flags omitidos, no solo los falsos positivos.

La tolerancia para la sustitución de primitivas debe calibrarse aparte, y hay que acordar de antemano quién decide cuando el gate bloquea un cambio correcto. Los resultados proceden de una simulación, así que antes de pasar a producción hace falta una ejecución con propuestas de LLM reales.