Los bancos estadounidenses bloquean agentes de IA en las cuentas de clientes

Qué informó Axios¶

El informe se basa principalmente en personas conocedoras del asunto. Sus puntos principales, parafraseados:

• Bancos citados. Morgan Stanley, Bank of America, JPMorgan, Wells Fargo y otros se apresuran a contener los riesgos de los agentes en las cuentas de clientes.
• Cómo entran los agentes. Los agentes suelen usar el permiso y las credenciales de acceso del cliente. Las normas de la mayoría de los bancos exigen que los clientes inicien sesión en sus propias cuentas.
• Qué hicieron los agentes. Algunos bancos detectaron agentes que contactaban con centros de atención telefónica o realizaban acciones independientes de las instrucciones del usuario.
• Qué hacen los bancos. Según las fuentes, Morgan Stanley ha empezado a bloquear a los agentes de terceros en sus plataformas. JPMorgan, Bank of America y Citi están restringiendo los agentes. Los bancos están reescribiendo sus condiciones de servicio porque les cuesta distinguir a una persona de un bot no autorizado.
• Acceso de solo lectura. La mayoría de los bancos ha autorizado, o se dirige hacia, un acceso de solo lectura para los agentes, similar al que ya conceden a las aplicaciones de presupuestos.
• Preparación. Los bancos invierten en evitar los peores escenarios y en planificar el día después de un incidente, incluido cómo proteger o restablecer el acceso de los clientes.

Qué no dice el informe¶

El informe no describe pérdidas de clientes, ninguna brecha confirmada ni actuaciones de un regulador. Un portavoz de Chase dijo que los clientes no deben compartir nombres de usuario ni contraseñas con nadie. Un portavoz de Morgan Stanley dijo que el banco no había observado casos de agentes de IA fuera de control accediendo a sus plataformas. Un directivo bancario cuyo nombre no se publicó dijo que es difícil saber si un usuario autorizó a un agente o si el agente actuó por su cuenta.

El informe documenta un problema de control en el que los bancos trabajan ahora.

Por qué una comprobación de inicio de sesión no responde a la pregunta¶

Cuando un cliente entrega su contraseña a un agente, cada solicitud del agente lleva la identidad del cliente. El banco ve una sesión válida. No puede ver que fue un software quien eligió la acción, qué instrucción dio el cliente ni si la acción se ajusta a ella. En ese punto el banco tiene dos opciones poco precisas: permitir la sesión o bloquear todo lo que parezca automatizado. Bloquear protege la cuenta y también detiene los agentes que los clientes quieren usar.

El acceso de solo lectura reduce el riesgo porque una consulta de saldo no mueve dinero. También deja abierta la pregunta difícil para el momento en que se permita actuar a los agentes.

Qué cambia un punto de control por acción¶

Un punto de control en tiempo de ejecución evalúa cada acción que propone un agente antes de que se ejecute. Necesita que el agente use su propia identidad, separada de la contraseña del cliente, y que envíe cada acción propuesta por un canal que el banco gobierna. El punto de control devuelve entonces uno de cuatro resultados: allow, warn, require_approval o block. Prevalece la regla coincidente más estricta.

La política siguiente es un ejemplo sintético para una cuenta minorista. Muestra cómo un banco podría permitir trabajo útil de los agentes y mantener a una persona delante del dinero que sale de la cuenta.

require_approval pone a una persona delante del dinero que sale de la cuenta¶

Con require_approval, el punto de control retiene la acción exacta, con su importe, beneficiario y fecha, y pide a una persona autorizada que decida. Para un cliente minorista, esa persona es el cliente. Para una cuenta corporativa, es el verificador de tesorería que designó el cliente. La aprobación debe cubrir solo la acción que vio la persona. Si después el agente cambia el importe o el beneficiario, la aprobación deja de aplicarse y la acción se evalúa de nuevo.

En octubre de 2026 construimos un Process de liberación de pagos retenidos para una sesión informativa con analistas, con agentes en borrador, datos sintéticos y sin conexión a un sistema de pagos. Tres agentes verifican la instrucción, actualizan el cribado y preparan una recomendación de liberación, y una persona de Operaciones de Pagos autoriza la liberación. La política bloquea las coincidencias de sanciones confirmadas, los pagos duplicados y las retenciones sin resolución documentada, y envía cada recomendación de liberación a un verificador independiente. En la simulación, una coincidencia de sanciones confirmada activó tanto la parada por sanciones como la regla de aprobación de la liberación, y el resultado fue block, porque block tiene prioridad.

Dos decisiones de diseño de esa construcción se aplican a cualquier agente que mueva dinero. Un rechazo mantiene la retención original. La aprobación y la liquidación son registros separados, de modo que un pago aprobado solo cuenta como completado cuando se registra su referencia de liquidación. La construcción también nos enseñó a dar a cada decisión una sola aprobación: nuestro primer envío a revisión falló porque dos pasos humanos llevaban además un indicador de aprobación, lo que habría creado dos tareas de aprobación para una sola decisión.

La matriz de decisiones de aprobación establece umbrales, funciones de los revisores, caducidad y casos de excepción para este tipo de regla.

La evidencia responde a la pregunta que los bancos no pueden responder hoy¶

El problema del directivo sin nombre es un registro que falta. Cuando una acción pasa por un punto de control, el banco puede conservar quién delegó autoridad en el agente, qué agente y qué versión actuaron, qué propuso, qué regla de la política se aplicó, qué resultado siguió, quién aprobó y cuándo, y qué hizo el sistema posterior. Ese registro permite al banco responder con hechos a la reclamación de un cliente o a un auditor.

La revocación pertenece al mismo registro. Cuando un cliente retira la delegación, la siguiente acción propuesta debe rechazarse, y el rechazo debe registrarse. La guía de arquitectura del interruptor de parada cubre la vía de parada y un simulacro para probarla.

Dónde encaja KLA y dónde no¶

El KLA Control Plane gobierna las acciones de los agentes que se envían a través de él. Los agentes que actúan a través de la entrada de acciones de agentes de KLA trabajan bajo un mandato de agente con un propietario responsable, herramientas y destinos permitidos, restricciones de umbral sobre parámetros como el importe y una fecha de fin. El KLA Policy Engine devuelve allow, warn, require_approval o block para cada acción propuesta. Cuando falla la evaluación de la política, la acción no se ejecuta. Un resultado require_approval crea una Decision Request; Decision Desk rechaza las decisiones del solicitante, y la aprobación queda vinculada a un hash de los argumentos de la acción, de modo que una solicitud modificada se bloquea. Revocar un mandato bloquea las propuestas abiertas y rechaza la siguiente acción del agente. Cada paso se registra para Lineage Explorer, Audit Trail y Evidence Room. Este párrafo describe el código fuente actual.

KLA no detecta a un agente de terceros que inicia sesión con la contraseña compartida de un cliente. La detección de bots, el riesgo de sesión y el cumplimiento de las condiciones de servicio siguen correspondiendo a los canales digitales y de fraude del banco. KLA gobierna los agentes que un banco o sus socios deciden conectar a través de un canal gobernado.