MCP Gateway para agentes de IA en el sector bancario: la capa de control entre la IA y el núcleo bancario

3 de julio de 2026

10 minutos de lectura

Digital connector showing secure links between AI agents and financial infrastructure.
Resumir con IA

En el artículo anterior, desglosé la arquitectura de confianza de cuatro capas para los agentes de IA en el sector bancario: capa de cliente, orquestación de agentes, MCP Gateway y núcleo bancario. Ese modelo te ofrece una visión general del sistema. Este artículo trata sobre la parte que hace que esa visión general resulte útil en la producción.

La pasarela MCP es donde se comprueba la intención del agente.

Un modelo puede determinar que necesita datos de la cuenta, el estado del KYC, la preparación del pago, la evaluación contra el blanqueo de capitales o una señal de fraude. Pero en el sector bancario, “el modelo lo ha decidido” no constituye un control. Antes de que esa solicitud llegue siquiera cerca del núcleo, debe pasar por el ámbito del inquilino, los permisos de usuario, la validación del esquema, el estado de aprobación, el contexto de auditoría y la gestión de errores. Esa es la función de la pasarela. 

Veamos, pues, los aspectos técnicos: RBAC, comprobaciones de esquema, flujos de trabajo de aprobación, registros de auditoría, interruptores de circuito, ámbito de aplicación de los tokens y cómo se aplica todo esto en un proceso de suscripción.

Experto en Blockchain y analista de DeFi

Andrew traduce conceptos descentralizados en herramientas financieras seguras y funcionales. Navega por el volátil panorama DeFi para construir infraestructuras de blockchain escalables que aborden la utilidad del mundo real, pasando de las palabras de moda para ofrecer valor técnico.

La pasarela MCP como punto de control obligatorio

Lo primero que valoraría del MCP Gateway sería lo siguiente: ¿es capaz de rechazar una solicitud que al agente le parece totalmente correcta? 

El modelo puede seleccionar la herramienta adecuada, rellenar los campos correspondientes y generar un resultado que supere el análisis sintáctico básico. Desde el punto de vista del agente, la solicitud parece estar lista. Sin embargo, desde el punto de vista bancario, es posible que aún le falten elementos fundamentales: acceso del titular, rol de usuario, estado del flujo de trabajo, umbral de aprobación, límites del sistema de origen y contexto de auditoría.

Así pues, la pasarela tiene una función muy concreta. Se encarga de cubrir el vacío que existe entre “el agente ha generado una solicitud que parece válida” y “el banco está autorizado a dar curso a dicha solicitud”. No tiene por qué hacer que el modelo sea más inteligente. Lo que debe hacer es que las acciones del modelo sean verificables, rechazables y seguras para su posterior enrutamiento. 

A continuación se explica cómo gestiona MCP Gateway una solicitud de un agente:

AI banking gateway diagram showing role checks, schema validation, approval rules, and final request handling.

Detrás de esa decisión hay seis mecanismos de control: RBAC por inquilino, validación de esquemas, flujos de trabajo de aprobación, registro de auditoría inmutable, cortacircuitos y delimitación del ámbito de los tokens. Cada uno de ellos detecta un tipo diferente de fallo antes de que la solicitud llegue al núcleo bancario.

Control de acceso
Qué bloquea o controla
Ejemplo del sector bancario
RBAC por cliente
Acceso a herramientas y terminales por inquilino, rol, región y flujo de trabajo
Un comerciante dedicado exclusivamente a los pagos puede preparar los pagos, pero no puede acceder a los puntos finales de revisión de KYC.
Validación del esquema
Solicitudes que no se ajustan a los contratos OpenAPI aprobados
Una carga útil de pago mal formada falla antes de llegar al servicio de pago
Flujos de trabajo de aprobación
Operaciones que superan los umbrales de riesgo, importe, beneficiario o póliza
Una transferencia de alto valor pasa a una cola de aprobación en lugar de pasar directamente a la ejecución.
Registro de auditoría de Immutable
El historial completo de la solicitud: quién, qué, cuándo, inquilino, canal, estado de aprobación y resultado
El departamento de cumplimiento normativo puede revisar una exportación en la que se hayan ocultado los datos de carácter personal sin necesidad de leer las transcripciones originales de los chats.
Disyuntores
Llamadas a servicios y proveedores centrales que no funcionan correctamente, son lentos o tienen un límite de velocidad
Una interrupción en el servicio de un proveedor de AML activa el sistema de mensajes de reserva en lugar de repetir las llamadas fallidas.
Ámbito de aplicación de los tokens
Acceso excesivamente amplio a los datos de los clientes, las cuentas o las herramientas de los proveedores
Un token de corta duración puede leer una vista de cuenta, pero no todo el conjunto de datos del inquilino.

RBAC Es ahí donde la pasarela empieza a amortizarse. En una plataforma bancaria multitenant, el acceso no puede ser amplio solo porque el agente sea “interno”. Cada tenant necesita su propia matriz de permisos. Un comerciante que solo utilice la iniciación de pagos no debería tener acceso a herramientas de KYC. Un agente de soporte de una región no debería ver los controles de tarjetas de otra región. Un flujo de trabajo que solo requiera una explicación del saldo no debería tener acceso a la preparación de transferencias.

Validación del esquema es el siguiente filtro. La pasarela debe validar cada solicitud según las especificaciones OpenAPI aprobadas o contratos equivalentes. De este modo se detectan las cargas útiles erróneas: formato de moneda incorrecto, falta del identificador del beneficiario, canal de pago no admitido, intervalo de fechas imposible o solicitud de estado KYC mal formada. El modelo puede ser elocuente y, aun así, generar una carga útil que el sistema debería descartar.

Flujos de trabajo de aprobación son los casos en los que el modelo sin custodia se materializa. El agente puede preparar una acción, pero las operaciones de alto riesgo requieren una cola de espera, como los umbrales de importe, los nuevos beneficiarios, el estado sospechoso de una cuenta, un proceso de KYC incompleto, señales elevadas de fraude o políticas específicas del cliente. La pasarela debe crear el elemento de aprobación, notificarlo al responsable de la aprobación, supervisar las reglas de tiempo de espera y devolver un estado claro al usuario o al operador.

Registro de auditoría Debe integrarse en la ruta. Por cada solicitud, la pasarela debe crear un registro de solo adición. Este registro debe incluir el cliente, el usuario, el canal, el estado del flujo de trabajo, la herramienta, los parámetros tras la supresión de datos confidenciales, el resultado de la validación, el estado de aprobación, la respuesta posterior y el identificador de correlación. Los equipos de cumplimiento normativo no necesitan una transcripción impecable. Necesitan un registro claro que explique por qué el sistema permitió o bloqueó la acción.

Hay una distinción que conviene dejar clara desde el principio: el registro demuestra lo que se ejecutó, no quién tenía la capacidad para hacerlo. Un rastro puede mostrar perfectamente que una transferencia se realizó de A a B bajo un token determinado. Por sí solo, no puede demostrar que la acción fuera autorizada por un mandante reconocido por ambas partes, ni que la autorización no hubiera sido revocada previamente. En un flujo de un único inquilino, esa laguna es invisible, ya que el registro y los registros de autoridad se encuentran en el mismo lugar. En el momento en que surge una disputa entre un inquilino o una contraparte, esa laguna se convierte en el problema principal. Por lo tanto, el registro debería reflejar la legitimación: qué mandato autorizó la llamada, bajo qué ámbito de aplicación y si seguía siendo válido en ese momento. Profundizo en este punto en mi artículo Un mandato no es lo mismo que gobernar.

Disyuntores Esto es importante porque los proveedores bancarios fallan de formas tediosas, como tiempos de espera agotados, interrupciones parciales, respuestas lentas, estados desactualizados y límites de frecuencia. La pasarela debería detectar ese patrón, volver a intentarlo con un tiempo de espera cuando sea seguro hacerlo, detener las llamadas repetidas cuando no lo sea y ofrecer al usuario una alternativa útil. “El proveedor de AML no está disponible, inténtalo de nuevo más tarde” es mejor que dejar que el agente entre en un bucle, invente un estado o siga insistiendo en un servicio degradado.

Ámbito de aplicación de los tokens limita el alcance del impacto. Una llamada a una herramienta debe recibir el acceso mínimo necesario para esa solicitud concreta, ese inquilino, ese usuario y ese estado del flujo de trabajo. Los tokens de corta duración y con ámbito limitado son mucho más seguros que las credenciales de servicio de larga duración que circulan por la capa del agente. Si algo sale mal, la solicitud fallida debería tener un impacto muy limitado.

Controlar el acceso de los agentes de IA antes de que lleguen al sistema bancario central

Innowise te ayuda a garantizar que cada acción cuente con la autorización correspondiente, sea rastreable y esté bajo tu control.

Canal «Safeguard»: 5 medidas de seguridad para los agentes de IA del sector bancario

Ya he hablado del proyecto «Safeguard Pipeline» en el artículo sobre arquitectura, pero aquí quiero analizarlo desde un punto de vista más riguroso: qué se comprueba antes de que el modelo comience a planificar y qué se comprueba antes de que el usuario vea la respuesta o el sistema lleve a cabo una acción.MCP Gateway controla el acceso a las herramientas, mientras que Safeguard Pipeline controla la exposición y los resultados de los modelos. Ambos se encuentran muy próximos entre sí en el flujo, pero detectan fallos distintos.
Guardia
Momento de aplicación
¿Qué pasa si falla?
Detección rápida de inyecciones
Antes de que el agente planifique una trayectoria de la herramienta
La solicitud se bloquea, se elimina el contenido inyectado o se deriva a una revisión manual.
Redactor de datos personales
Antes de que el contexto se incorpore al modelo
Los valores confidenciales innecesarios se ocultan, se tokenizan o se eliminan de la indicación.
Llama Guard/clasificador de seguridad
Antes de continuar con el razonamiento
El flujo se bloquea, se limita a una respuesta segura o se intensifica
Detección de alucinaciones
Antes de que se muestre la respuesta
Las solicitudes sin justificación se comprueban con los sistemas de origen y, a continuación, se corrigen, se vuelven a intentar o se bloquean.
Política de cumplimiento Engine
Antes de la respuesta, la clasificación o la aprobación
La acción está bloqueada, en cola de aprobación o se ha reescrito de acuerdo con la política del inquilino.

El momento en que se realiza es clave. Si se detecta una inyección inoportuna cuando la llamada a la herramienta ya está preparada, el control llega demasiado tarde. Si la ocultación de datos personales se lleva a cabo después de que el modelo haya visto el valor sin procesar, solo se está enmascarando la transcripción. Si la detección de alucinaciones se produce después de que se haya enviado la respuesta, se trata simplemente de un registro a posteriori.

Así que yo mantendría la regla sencilla: los controles de entrada se ejecutan antes de la planificación, y los controles de salida se ejecutan antes de que nada salga del sistema. La pasarela decide si una llamada a una herramienta puede llegar al núcleo bancario. El proceso decide si el modelo ha recibido los datos de entrada correctos y si su resultado es lo suficientemente seguro como para mostrarlo, reintentarlo, bloquearlo, escalarlo o enviarlo a aprobación.

El modelo sin custodia: el agente se encarga de la preparación, pero nunca de la ejecución

Tras el MCP Gateway y el Safeguard Pipeline, hay otra regla más que me gustaría dejar clara en la arquitectura: el agente no debe tener el control sobre la acción. En pocas palabras, no debería poder mover dinero, ejecutar una operación bursátil, aprobar un pago ni formalizar una operación regulada por su cuenta.

A eso me refiero con un modelo sin custodia. El agente puede preparar el siguiente paso, pero la ejecución queda fuera del modelo. Una herramienta de transferencia crea una transacción en espera de confirmación. Una herramienta de intercambio devuelve una cotización, las comisiones, el plazo de vencimiento y una tarjeta de confirmación. Una herramienta de tarjetas puede preparar una solicitud de bloqueo. Una herramienta de KYC puede recopilar los datos que faltan y enviarlos para su revisión. En cada caso, el agente está preparando la operación, no llevándola a cabo entre bastidores.

AI banking workflow showing the agent prepares a transaction while execution stays with core banking.

Este modelo modifica la orientación normativa del sistema. Un agente que explica las opciones, recopila información contextual, prepara formularios y tramita las solicitudes resulta mucho más fácil de justificar como una capa de apoyo a la toma de decisiones. En cambio, un agente que ejecuta operaciones financieras de forma autónoma empieza a parecer un ejecutor financiero autónomo, lo que plantea una serie diferente de cuestiones relacionadas con las licencias, la responsabilidad civil, la auditoría y los seguros.

Hay una forma más clara de explicar por qué existe esta regla. En el momento en que un agente transfiere valor a través de un límite organizativo, deja de comportarse como un coordinador interno y empieza a actuar como un agente económico. Esa es la clase que asume la responsabilidad real, y precisamente la clase que no quieres que un modelo probabilístico ocupe por sí sola. Mantener la ejecución fuera del modelo es la forma de evitar que un agente se cuele silenciosamente en él. El límite de clase en este caso se deriva del hecho de que No todos los agentes son agentes económicos..

Esa distinción es importante cuando algo sale mal. Con una configuración sin custodia, se puede mostrar qué preparó el agente, qué comprobaciones de la pasarela se realizaron, quién o qué aprobó la acción y cuándo la ejecutó el sistema bancario central. Sin esa separación, el modelo está demasiado cerca del dinero. Yo no diseñaría un agente bancario de esa manera.

Las opciones tecnológicas y por qué son importantes

Añado la sección sobre la pila por una razón: las afirmaciones sobre la arquitectura no valen nada hasta que se nombran las herramientas que hacen que los controles sean reales. Es fácil decir “aislamos a los inquilinos”, “realizamos comprobaciones de los flujos de trabajo” o “validamos las llamadas a las herramientas”. Lo más difícil es elegir una pila en la que esos controles no se queden solo en diagramas y buenas intenciones. 

En un sistema de agentes bancarios, la pila debe admitir sesiones con un uso intensivo de WebSocket, objetos financieros tipados, flujos de trabajo reproducibles, acceso a herramientas estándar, almacenamiento adaptado a cada cliente y aislamiento en tiempo de ejecución. Si las herramientas no cumplen esos requisitos, la arquitectura empieza a presentar riesgos de forma sutil y discreta: un tenant_id que falta, una carga útil de herramienta sin tipificar, un estado de flujo de trabajo que solo existe en el historial de chat o un conector que nadie puede auditar adecuadamente.

Así que yo analizaría la pila desde una perspectiva sencilla: ¿esta elección facilita que el sistema se pruebe, se detenga, se inspeccione, se recupere y se proteja más adelante? Si la respuesta es sí, hay que tenerla en cuenta. Si no, probablemente se trate solo de una preferencia del desarrollador disfrazada de arquitectura.

Elección de tecnología
¿Por qué esta elección?
El control que ofrece
Motivo bancario
NestJS sobre Python
La capa de agente gestiona las sesiones WebSocket, la lógica del BFF, los adaptadores de canal, los contratos tipados y los objetos financieros, no solo las llamadas al modelo.
Tipos de datos de TypeScript para los identificadores de cliente, saldos, beneficiarios, límites, estados del flujo de trabajo y cargas útiles de las herramientas.
Mantiene el cliente, el BFF y la orquestación más cerca entre sí en una única pila, con LangChain.js y LangGraph.js disponibles.
LangGraph
Los flujos de trabajo bancarios se ramifican, se pausan, se reanudan y se escalan.
Flujos de trabajo dirigidos, estado tipado, transiciones condicionales y puntos de control de PostgreSQL.
Los equipos pueden consultar el recorrido exacto que ha seguido un proceso de KYC, una reclamación, un pago o una evaluación de riesgos.
MCP
Los conectores personalizados dificultan la gestión del acceso a las herramientas, los permisos y las normas de auditoría.
Detección estándar de herramientas, descripciones de herramientas, llamadas con permisos e interfaces de habilidades reutilizables.
Funciones como los pagos, la incorporación de nuevos clientes, los controles de tarjetas, la corrección de datos de KYC y la evaluación de riesgos pueden ofrecer capacidades aprobadas sin necesidad de acceso interno directo.
Aurora PostgreSQL + RLS
El aislamiento de los inquilinos no debería depender únicamente de los filtros «tenant_id» en el código del servicio.
Almacenamiento adaptado a cada cliente para flujos de trabajo, aprobaciones, registros de auditoría, puntos de control y metadatos financieros.
RLS, Redis por inquilino, gVisor o Firecracker, y los almacenes de claves secretas independientes reducen el riesgo de fuga entre inquilinos.

Garantizar que las solicitudes bancarias relacionadas con la IA sean trazables y estén controladas 

Innowise te ayuda a establecer las normas sobre quién puede solicitar, aprobar y actuar

Lo que comprobaría antes de dar por listo para producción a un agente bancario

Antes de considerar que un agente bancario es «implementable», intentaría provocar a propósito un fallo en la pasarela MCP: inquilino incorrecto, rol incorrecto, carga útil mal formada, falta de aprobación, token caducado o proveedor no disponible. El diseño solo estará listo si esos casos fallan de forma clara, dejan un rastro y no requieren que el modelo explique lo que ha ocurrido.

Esta es la lista de comprobación que yo utilizaría:

Consulte
Lo que esperaría ver
RBAC con ámbito de inquilino
Todas las herramientas y los terminales asignados a un inquilino, un rol de usuario, un canal y el estado del flujo de trabajo
Validación del contrato
Las llamadas a herramientas se comprueban según los esquemas aprobados antes de su ejecución
Proceso de aprobación
Colas basadas en umbrales para pagos, nuevos beneficiarios, estados de cuenta de riesgo y excepciones a las políticas
Ejecución sin privación de libertad
El agente prepara las acciones; el usuario, el responsable de la aprobación o el motor de políticas las confirma; y el sistema bancario central las ejecuta
Registro de auditoría
Registros de solo adición con los siguientes datos: cliente, usuario, canal, herramienta, parámetros ocultados, estado de aprobación, resultado e ID de correlación
Gestión de errores del proveedor
Interruptores de circuito, reglas de reintento, comportamiento ante tiempos de espera y mensajes de alternativa para el usuario
Ámbito de aplicación del token
Tokens de corta duración limitados exclusivamente al inquilino, la vista de la cuenta, la herramienta y el paso del flujo de trabajo correspondientes
Control de la respuesta y la actuación
Comprobaciones de alucinaciones y de políticas antes de que se muestre la respuesta o se lleve a cabo la acción

Ahí es donde yo pondría la prueba: ¿puede el banco reconstruir, defender y detener cada paso del flujo de trabajo sin depender de la memoria del modelo ni de la explicación de un desarrollador? Si MCP Gateway puede responder a eso, la arquitectura tiene una oportunidad real fuera de la sala de demostraciones.

Más sobre este tema

    Contáctenos

    Reserve usted una llamada o rellene usted el siguiente formulario y nos pondremos en contacto con usted cuando hayamos procesado su solicitud.

    Envíenos un mensaje de voz
    Adjuntar documentos
    Cargar archivo

    Puede adjuntar 1 archivo de hasta 2 MB. Formatos de archivo válidos: pdf, jpg, jpeg, png.

    Al hacer clic en Enviar, autoriza a Innowise a procesar sus datos personales de acuerdo con nuestra política de privacidad. Política de privacidad para proporcionarle información relevante. Al enviar su número de teléfono, acepta que nos pongamos en contacto con usted a través de llamadas de voz, SMS y aplicaciones de mensajería. Pueden aplicarse tarifas de llamadas, mensajes y datos.

    También puede enviarnos su solicitud
    a contact@innowise.com
    ¿Qué pasa después?
    1

    Una vez recibida y procesada su solicitud, nos pondremos en contacto con usted para detallarle las necesidades de su proyecto y firmar un acuerdo de confidencialidad. Proyecto y firmaremos un acuerdo de confidencialidad.

    2

    Tras examinar sus deseos, necesidades y expectativas, nuestro equipo elaborará una propuesta de proyecto con el alcance del trabajo, el tamaño del equipo, el plazo y los costes estimados con el alcance del trabajo, el tamaño del equipo, el tiempo y las estimaciones de costes.

    3

    Concertaremos una reunión con usted para hablar de la oferta y concretar los detalles.

    4

    Por último, firmaremos un contrato y empezaremos a trabajar en su proyecto de inmediato.

    arrow