Los marcos de agentes ya preparados no son suficientes para el sector bancario. Sí, ese es el punto de partida, y no, ni una estrategia de indicaciones más clara ni una pasarela de API más estricta cambian esta realidad.
Una pila estándar con LangChain, herramientas, una base de datos vectorial y una pasarela de API puede hacer que un agente sea funcional. Puede enrutar una intención, recuperar el contexto, llamar a una herramienta y devolver una respuesta bien elaborada. De acuerdo. Pero el sector bancario no falla en el nivel de “¿puede llamar a la API?”. El sector bancario falla en lo que respecta a la pregunta: “¿Se autorizó, se delimitó el alcance, se verificó, se registró y era seguro mostrar esta llamada a este cliente?”. Ese es un problema de arquitectura distinto.
Hay tres razones por las que no utilizaría una pila de agentes genérica en entornos de producción de flujos de trabajo bancarios sin añadir una capa de confianza específica.
En primer lugar, los datos financieros son datos sobre pasivos. Una respuesta errónea en un chatbot de comercio minorista resulta embarazosa. Un saldo, un estado de transacción, una explicación de comisiones o una decisión crediticia erróneos pueden suponer un riesgo legal. En virtud de la Deber de la FCA para con los consumidores, por ejemplo, la entidad debe demostrar que los clientes reciben una atención justa, comprensible y adecuada. Si el modelo propone una opción de amortización o explica un producto de forma incorrecta, no se puede encogerse de hombros y echarle la culpa a “la IA”. El banco es responsable del resultado. Por lo tanto, la arquitectura debe tratar cada afirmación objetiva como algo que hay que verificar contrastándola con un sistema de referencia.
En segundo lugar, la multitenencia no es solo una cuestión de diseño del producto. Si prestas servicio a varios clientes bancarios, comerciantes, unidades de negocio o regiones desde una misma plataforma, debe existir aislamiento entre inquilinos en todas las capas: solicitudes, memoria, índices vectoriales, permisos de herramientas, registros, claves de Redis, filas de bases de datos, secretos y exportaciones de auditoría. Una sola fuga entre inquilinos no es un simple informe de error. Puede ser un incidente que deba notificarse. Por eso no me gustan las arquitecturas en las que el agente tiene un acceso amplio y la capa de la aplicación “se acuerda” de filtrar los datos más tarde. Filtrar más tarde es precisamente cómo se producen las fugas de datos.
En tercer lugar, el LLM es el componente menos fiable de la cadena. Puede parecer exagerado, pero es la suposición correcta. El modelo es probabilístico. Puede seguir instrucciones maliciosas, confiar en exceso en el contexto recuperado o revelar datos personales en un resumen. Puede generar una llamada a una herramienta que parezca válida hasta que se revisen los parámetros. Por eso, nunca permitiría que el modelo estuviera en contacto directo con las API bancarias principales.
El enfoque más seguro consiste en dejar que el modelo razone, pero mantener la aplicación de las normas en sistemas determinísticos. El razonamiento corresponde a la capa de agentes. La aplicación de normas corresponde a los validadores de esquemas, las comprobaciones de políticas, los permisos específicos de cada usuario, los controles de aprobación y los registros de auditoría. Una vez realizada esa separación, la arquitectura deja de ser una cadena de llamadas a la API impulsadas por modelos y se convierte en un sistema de confianza controlado, en el que el LLM se trata como un componente de razonamiento útil pero poco fiable.
Hay un enfoque que facilita la aplicación de esa distinción. Cuando analizo un agente bancario, lo que me interesa es cuánta autoridad tiene y qué distancia debe recorrer esa autoridad desde la persona que se la otorgó. La capacidad indica la calidad de la demostración. La autoridad determina cuánto control se permite ejercer al sistema. Un modelo brillante conectado a herramientas de solo lectura es un asistente ligero. Un modelo mediocre que posea una clave permanente con la que se puedan mover fondos es un problema distinto, y necesita todas las capas inferiores. En el artículo, divido ese eje de autoridad en cuatro clases: asistente, orquestador, operador y agente económico. No todos los agentes son agentes económicos.
Contrátanos
Conócenos