El NPCI de India auditó a los agentes de IA de un banco: hasta un 12% de «éxitos» con pasos omitidos

National Payments Corporation of India (NPCI), la organización que gestiona la infraestructura nacional de pagos del país, ha publicado el benchmark TauIndianBankBench. Es un conjunto de 1000 tareas en las que un modelo de lenguaje actúa como asistente de un banco minorista. El modelo conversa con un cliente interpretado por otro modelo y llama a herramientas: bloquea una tarjeta, cancela un depósito, consulta el calendario de pagos. La conclusión principal de los autores: si solo se comprueba el estado final de la base de datos, como hacen la mayoría de las pruebas de este tipo, entre el 6,5 y el 12,0% de las sesiones «exitosas» de todos los modelos contienen en realidad una violación del procedimiento.

Por qué no basta con la base de datos final

Los bancos indios atienden hoy a sus clientes con páginas de preguntas frecuentes (FAQ) y chatbots con guion y respuestas fijas. Un modelo podría responder más rápido y resolver consultas que no figuran en las FAQ. Pero un banco solo puede confiarle esa tarea si el modelo da información correcta y respeta las normas internas: un error perjudica al cliente de inmediato.

El problema es que muchos pasos obligatorios del reglamento no escriben nada en la base de datos. Ejemplos del trabajo:

• antes de cancelar un depósito hay que obtener el cálculo de cancelación para que el cliente conozca el importe de la penalización; • antes de abrir un depósito por una cantidad que quizá no cubra el saldo de la cuenta, hay que localizar la regla del saldo mínimo; • antes de bloquear una tarjeta hay que comprobar su estado.

Un agente que se salte todo esto dejará en la base de datos exactamente los mismos registros. La comprobación del estado final lo dará por bueno, pero el cliente no recibirá la información para la que existen esos pasos. En India, muchos de ellos están fijados por la normativa: la actualización periódica del KYC (verificación de la identidad del cliente), la retención de impuestos en origen (TDS) con sus formularios de exención y las condiciones legales de participación en los planes públicos de ahorro.

Dos comprobaciones en lugar de una

Cada sesión recibe dos veredictos de «superada/no superada»:

• Comprobación del estado final. La cadena de llamadas de referencia se ejecuta sobre una copia idéntica de la base de datos y después se comparan los registros. Antes de la comparación se eliminan los campos que cambian de una ejecución a otra: números generados, referencias y notas libres. • Comprobación de acciones. El agente debe realizar todas las llamadas de la cadena de referencia, incluidas las de lectura, y el orden no importa. Cualquier cambio que el cliente no haya pedido suspende la sesión. Incluso si el agente lo revierte después: mientras estuvo en vigor, el cliente ya salió perjudicado.

La sesión solo cuenta si se superan ambas comprobaciones. No hay puntuación parcial: tres llamadas de cuatro dan cero, igual que no hacer nada. La evaluación es totalmente determinista y no usa un modelo juez, que puede mostrar sesgos a favor de las respuestas largas y de su propio estilo.

Cómo está construido el benchmark

• Un banco sintético con 944 clientes: cuentas, tarjetas, depósitos, créditos, órdenes permanentes, estado del KYC e historial de operaciones. • 34 herramientas: 33 de servicio y una para transferir al cliente a un empleado humano. De las de servicio, 20 solo leen datos y 13 son de escritura (11 modifican registros y dos tramitan el pedido de un talonario o de un duplicado de extracto).

• 24 documentos de base de conocimiento: límites de pago, actualización del KYC, seguro de depósitos, impuesto sobre intereses, plazos de devolución de pagos y planes públicos. • 50 familias de tareas en cuatro categorías: multipaso con dependencias, tareas con una condición que hay que detectar antes de actuar (por ejemplo, que el cliente no cumpla los requisitos), operaciones poco frecuentes y pruebas de control sencillas. La cadena de llamadas tiene de media 3,54 llamadas, entre una y seis.

• De las 1000 tareas, 962 requieren al menos una llamada de lectura y 114 no requieren ninguna escritura.

Hay varias particiones: el conjunto completo de 1000 tareas, una versión reducida de 200 (cuatro de cada familia) y su división en partes de entrenamiento y de prueba, para poder afinar un modelo y medir el resultado con honestidad.

No fue una persona quien escribió las tareas desde cero: las esbozó un modelo de lenguaje y pasaron por cuatro filtros. Los primeros mensajes del cliente deben diferir: no más del 40% de las tareas de una familia pueden empezar igual, y debe haber al menos ocho variantes. En las tareas complejas, la cadena no puede tener menos de tres llamadas. Una tarea no puede estar a la vez en la parte de entrenamiento y en la de prueba. Y la cadena de referencia debe superar ambas comprobaciones.

Qué mostraron los seis modelos

Los autores probaron seis modelos abiertos, cinco de ellos de la familia Gemma 4. Resultados:

• en todos los modelos, entre el 6,5 y el 12,0% de las sesiones pasan la comprobación del estado final aunque el agente se saltara una llamada obligatoria o hiciera un cambio innecesario; • en los tres modelos más fuertes, la mayoría de las sesiones que suspenden exactamente una comprobación son violaciones del procedimiento que solo detecta la comprobación de acciones; • en el modelo más débil ocurre lo contrario: hace todas las llamadas necesarias, pero termina con registros incorrectos, y eso solo lo detecta la comprobación del estado final; • los agentes ficticios basados en scripts no superan ni una sola tarea; • en las tareas de control, el resultado no depende del tamaño del modelo, mientras que las tres categorías más difíciles sí distinguen a unos modelos de otros.

Para verificar la fiabilidad de la propia comparación, la implementación del evaluador se contrastó con una independiente en 600 sesiones grabadas, y los veredictos coincidieron en todas. Antes de la publicación, el paquete recalculó 5000 sesiones y reprodujo todas las puntuaciones. La clasificación de los modelos se repitió también con otra instalación para ejecutarlos.

Qué significa para bancos y desarrolladores

Quien elija o afine un modelo para banca no puede fijarse solo en el estado final de los datos: parte de las sesiones «exitosas» incumplió en realidad el reglamento y el cliente no recibió la información obligatoria. El código, los datos y los resultados de referencia están publicados en GitHub y Hugging Face. Las limitaciones también están claras: el banco es sintético, el cliente lo interpreta un modelo y solo se probaron modelos abiertos.