Un chatbot que responde incorrectamente genera una mala experiencia. Un AI agent que bloquea una cuenta, modifica un límite o inicia una operación incorrecta puede generar pérdidas financieras, consecuencias regulatorias y una investigación difícil de reconstruir.
Esa diferencia cambia el problema de infraestructura.
Los AI agents no se limitan a procesar una entrada y devolver una respuesta. Consultan sistemas, seleccionan herramientas, encadenan acciones y utilizan el resultado de una etapa para decidir la siguiente. En el sector financiero, este loop puede involucrar datos personales, motores de crédito, sistemas antifraude, APIs de pago y servicios de Open Finance.
Por eso, proteger el endpoint no es suficiente. La institución necesita controlar qué puede consultar, recomendar y ejecutar cada agent, además de interrumpir el flujo cuando su comportamiento supera los límites esperados.
Los principales riesgos aparecen cuando la autonomía del agent crece más rápido que los controles que lo rodean.
Riesgo 1: el agent obtiene acceso al sistema, pero no una identidad propia
Muchos AI agents llegan a producción utilizando las mismas credenciales de servicios ya existentes. La integración funciona, pero la institución pierde la capacidad de distinguir quién realizó cada acción.
Si varios agents comparten una cuenta de servicio, los logs muestran que una credencial consultó una API o modificó un registro. No necesariamente muestran qué agent inició la acción, qué tarea estaba ejecutando o qué permisos necesitaba realmente en ese momento.
El problema aumenta cuando las credenciales tienen scopes amplios. Un agent creado para consultar el estado de una transacción puede terminar técnicamente autorizado para iniciar pagos. Otro, destinado a apoyar un análisis de crédito, puede acceder a datos de clientes que no forman parte del caso evaluado.
En los sistemas tradicionales, los permisos excesivos ya representan un riesgo. Con agents, adquieren escala y velocidad: una decisión incorrecta puede repetirse en cientos de sesiones antes de que alguien detecte el patrón.
La arquitectura de la institución debe tratar a cada agent como una identidad operacional independiente. Esto puede implicar credenciales propias, scopes mínimos, tokens de corta duración y políticas diferentes para lectura, recomendación y ejecución.
La autenticación machine-to-machine es solo el comienzo. Una credencial válida responde quién está llamando a la API. La política de autorización debe determinar qué puede hacer esa identidad, sobre qué recursos, en qué contexto y dentro de qué límites.
Riesgo 2: una decisión probabilística produce una acción financiera determinística
Los modelos trabajan con probabilidades. Los pagos, bloqueos de cuentas, cambios de datos y decisiones de crédito producen efectos concretos.
Cuando un agent conecta estas dos capas, una respuesta imprecisa deja de ser solamente contenido incorrecto y puede convertirse en una acción ejecutada en un sistema real. El riesgo no depende únicamente de la calidad del modelo. También depende de las herramientas disponibles y de los controles existentes entre la decisión y su ejecución.
Un agent de atención al cliente puede consultar una factura sin aprobación adicional. Para modificar una dirección de facturación, la institución puede exigir una validación adicional de identidad. Para aumentar un límite o iniciar una transferencia, la política puede exigir una nueva autenticación, aprobación humana o validación por otro sistema.
Esta separación reduce el radio de impacto sin eliminar toda la autonomía del agent. La institución puede definir controles según el riesgo de cada acción:
- las consultas de bajo riesgo pueden continuar automáticamente;
- los cambios de datos pueden requerir validaciones adicionales;
- las decisiones con impacto financiero pueden estar sujetas a límites de valor, frecuencia y destinatario;
- las acciones críticas pueden requerir aprobación humana antes de su ejecución.
El punto de control debe estar fuera de las instrucciones del modelo. Un prompt que indica al agent que no debe aprobar operaciones por encima de determinado valor es una orientación, no una barrera de seguridad. El límite debe ser aplicado por un mecanismo que el agent no pueda ignorar ni modificar.
ConAzion Functions, las instituciones pueden ejecutar lógica programable en el camino de la solicitud antes de que llegue a la API de origen. Esta capacidad puede utilizarse como parte de una capa de enforcement para evaluar solicitudes y aplicar reglas definidas por la institución antes de encaminarlas a los sistemas de origen.
Riesgo 3: una acción válida de forma aislada puede formar un comportamiento peligroso
No todos los incidentes comienzan con una solicitud malformada o una credencial inválida.
Un agent autenticado puede realizar únicamente llamadas permitidas y, aun así, presentar un comportamiento incompatible con su función. Puede consultar demasiados clientes en poco tiempo, recorrer una secuencia inusual de endpoints, repetir una acción después de resultados inconclusos o continuar ejecutando un flujo que debería haberse detenido.
Cada solicitud puede parecer normal cuando se analiza de forma aislada. El riesgo aparece en la secuencia.
Existe una diferencia entre verificar una transacción y observar una sesión completa. Una consulta de saldo es legítima. Consultar miles de cuentas diferentes con la misma identidad en pocos minutos requiere investigación. Un intento de pago puede ser esperado. Repetir la operación después de una respuesta ambigua puede generar duplicidades o aumentar costos.
Los rate limits genéricos por IP no resuelven todo el problema. Una arquitectura de control de agents necesita considerar factores como identidad, tipo de acción, frecuencia, secuencia de llamadas y recursos consultados.
Azion Bot Manager combina señales de comportamiento, fingerprint y reputación de red para clasificar tráfico automatizado. Esta clasificación proporciona una señal adicional para políticas de seguridad y mitigación de automatizaciones no deseadas. Sin embargo, la autorización de un AI agent para ejecutar una determinada acción debe continuar siendo definida y aplicada por los mecanismos de identidad y autorización adoptados por la institución.
Riesgo 4: el volumen de entrada no revela el radio de impacto
En una aplicación convencional, una solicitud normalmente genera un conjunto previsible de llamadas. En un AI agent, una tarea puede iniciar un loop con consultas, inferencias, llamadas a herramientas y nuevos intentos.
El banco puede recibir solamente cien solicitudes de clientes, pero el agent puede transformar cada una en decenas de interacciones con APIs internas. Si una lógica es incorrecta, el volumen de acciones downstream puede crecer sin que el tráfico inicial parezca anómalo.
Por eso, la capacidad y el riesgo no deben medirse únicamente por las solicitudes recibidas. La institución también necesita monitorear cuántas acciones genera cada tarea, cuánto tiempo permanece activo el flujo, qué sistemas se utilizan y cuántas veces el agent vuelve a intentarlo.
La arquitectura del agent puede definir circuit breakers y límites contextuales para reducir este radio de impacto. Por ejemplo, el sistema puede interrumpir una tarea cuando supera el número esperado de pasos, repite excesivamente una operación o excede límites establecidos por la institución.
La implementación de estos controles requiere que la arquitectura mantenga el contexto y el estado necesarios para evaluar el comportamiento acumulado de la tarea. Los controles en el camino de las solicitudes pueden complementar este diseño aplicando reglas sobre llamadas individuales y protegiendo los sistemas de origen.
Estas medidas también protegen la operación contra fallos que no son ataques. Un endpoint que responde de forma ambigua, una integración no disponible o una instrucción mal interpretada pueden mantener al agent en un loop y consumir capacidad de origen incluso con credenciales válidas.
Riesgo 5: los logs de API no forman una trazabilidad de decisiones
Los dashboards tradicionales muestran si la API estaba disponible, cuánto tardó en responder y cuántos errores se produjeron. Para auditar un AI agent, esta información es necesaria, pero insuficiente.
Cuando se cuestiona una acción financiera, la institución necesita reconstruir el flujo completo:
- qué agent recibió la tarea;
- qué identidad y permisos utilizó;
- qué datos y sistemas consultó;
- qué herramientas utilizó y en qué orden;
- qué acción recomendó o ejecutó;
- qué política autorizó, bloqueó o encaminó la acción para aprobación;
- cuál fue el resultado en cada sistema involucrado.
Sin un identificador que conecte estas etapas, la investigación queda fragmentada entre logs de autenticación, APIs, modelos, herramientas y sistemas transaccionales. La institución sabe que ocurrió una operación, pero no puede reconstruir con claridad cómo llegó el agent hasta ella.
Azion Real-Time Events proporciona visibilidad sobre eventos asociados al tráfico procesado por la plataforma.Data Stream permite enviar eventos continuamente a destinos de observabilidad y análisis, incluidas plataformas como Splunk, Azure Monitor, Datadog y S3.
Cuando la aplicación propaga identificadores de contexto consistentes, esta telemetría puede contribuir, junto con los registros del propio agent, los mecanismos de identidad y los sistemas financieros, a una trazabilidad correlacionada en el entorno de observabilidad o SIEM de la institución.
La infraestructura de tráfico proporciona una parte de esta visibilidad. La reconstrucción completa de una decisión requiere instrumentación en todos los componentes involucrados en el flujo del agent.
Cómo organizar los controles por nivel de autonomía
No todos los AI agents financieros requieren la misma arquitectura. Los controles deben acompañar la autoridad concedida al sistema.
Nivel de autonomía | Ejemplo | Controles que la institución debe considerar |
Consulta | Consultar el estado de un pago o información de una cuenta | Identidad propia, acceso de solo lectura y límites por recurso |
Recomendación | Sugerir una decisión de crédito o señalar fraude | Registro de los datos consultados, versión de la política y revisión humana cuando sea necesaria |
Modificación | Actualizar datos, bloquear una tarjeta o modificar parámetros | Validación adicional de identidad y contexto, mecanismos de recuperación y rollback |
Transacción | Iniciar un pago, transferencia o concesión de crédito | Límites de valor y frecuencia, segregación de funciones, aprobación y mecanismos de interrupción |
Esta clasificación evita dos extremos. El primero es aplicar controles tan rígidos que el agent no pueda operar. El segundo es conceder a una automatización de producción el mismo nivel de confianza que a un servicio interno tradicional, incluso cuando decide dinámicamente qué acciones ejecutar.
Cuanto mayor sea la autonomía, más debe contemplar la arquitectura la posibilidad de que el agent se equivoque, sea inducido a actuar fuera de los límites esperados o utilice un permiso válido en un contexto inadecuado.
Una capa de control antes de los sistemas financieros
No todos los controles necesarios para AI agents pertenecen a la misma capa de la arquitectura.
La identidad, autorización, aprobación humana, segregación de funciones y estado de la tarea deben ser definidos por los sistemas y procesos adecuados de la institución. Al mismo tiempo, los controles aplicados en el camino de las solicitudes pueden impedir que llamadas inadecuadas lleguen a APIs y sistemas críticos, además de proporcionar señales de seguridad y telemetría para investigación.
En esta capa de tráfico, la arquitectura puede aplicar verificaciones y protecciones a las solicitudes antes de encaminarlas al origen.
En la plataforma de Azion,Functions permite ejecutar lógica programable en el camino de la solicitud;Bot Manager utiliza señales de comportamiento, fingerprint y reputación para clasificar tráfico automatizado;Web Application Firewall inspecciona y protege solicitudes en la capa de aplicación; yReal-Time Events yData Stream proporcionan recursos de visibilidad y envío de telemetría.
Estas capacidades no sustituyen los mecanismos de identidad, autorización o workflow transaccional de la institución. Pueden formar parte de una capa de enforcement, protección y observabilidad entre agents y APIs, integrada con los demás controles de la arquitectura financiera.
La pregunta que viene antes de poner un agent en producción
Gran parte del debate sobre AI agents en el sector financiero pregunta si el modelo es preciso, si puede presentar sesgos o si está sujeto a alucinaciones. Estas preguntas siguen siendo importantes. Pero no determinan por sí solas si el sistema está listo para operar.
Antes del deploy, la institución necesita responder otra pregunta: ¿cuál es la acción de mayor impacto que este agent puede ejecutar con los permisos que posee actualmente?
La respuesta revela los controles necesarios.
Si el agent solamente consulta información, el riesgo está principalmente en el acceso indebido y la exposición de datos. Si recomienda decisiones, entran en juego la trazabilidad y la revisión. Si modifica sistemas o mueve recursos, los límites transaccionales, la segregación de funciones, la aprobación y los mecanismos de interrupción pasan a formar parte del diseño de seguridad.
Los AI agents en producción deben tratarse como identidades operacionales con autoridad delimitada, no como interfaces inteligentes conectadas a credenciales de servicio.
La diferencia entre una demostración convincente y una operación financiera segura no está solamente en el modelo. Está en una arquitectura capaz de definir, aplicar y demostrar qué podía hacer cada agent — y en controles de infraestructura capaces de proteger los sistemas que reciben esas acciones.
Lea también:
