Si un agente de IA usa la contraseña de un consumidor, en Europa es el banco quien debe probar que el pago se autorizó

Varios grandes bancos de EE. UU. han detectado agentes de IA de terceros operando dentro de cuentas de clientes, y algunos de esos agentes habrían intentado operaciones que el titular no pidió. Lo adelantó Axios el 22 de octubre de 2026, con fuentes no identificadas, y lo han recogido después USA TODAY y SecureWorld.

Muchos entran con el usuario y la contraseña que el cliente les entrega, aunque numerosas entidades exigen que sea el titular quien inicie sesión. Para el sistema de autenticación, ese agente es el cliente. Andre Durand, consejero delegado de Ping Identity, planteó ante USA TODAY la pregunta que sigue sin una respuesta técnica cerrada, que es cómo detectar que quien pide algo es un agente y no una persona.

La reacción de Wall Street interesa a una entidad europea sobre todo por lo que no puede copiar. Al menos un gran banco estadounidense ha reescrito su contrato para que el cliente cargue con lo que haga su agente. En la Unión Europea ese traslado choca con límites legales cuando el cliente es un consumidor o una microempresa, y una sentencia del Tribunal de Justicia de la UE del 15 de octubre los ha reforzado.

¿Qué han hecho los grandes bancos de EE. UU.?

JPMorgan anunció en público que bloqueará a los agentes externos que intenten iniciar sesión u operar en cuentas de clientes. En la presentación de resultados del tercer trimestre, Jamie Dimon lo justificó porque «no quieres agentes descontrolados», según recoge Fortune. La entidad mantiene un acceso de solo lectura a través de intermediarios como Plaid, sin capacidad para mover dinero ni pagar recibos, según el resumen de Gadget Review.

Un portavoz de Citi explicó a USA TODAY que la entidad no permite que agentes o asistentes de IA de terceros inicien sesión en la cuenta de un cliente, aunque admite lectura a través de proveedores de banca abierta aprobados. Rick Wurster, consejero delegado de Charles Schwab, aseguró que su firma rechaza «decenas» de intentos de grandes agentes de IA por acceder a fondos de clientes. Morgan Stanley afirma no haber observado agentes descontrolados en sus plataformas, y según Axios ha empezado a bloquearlos por precaución.

Brian Moynihan, consejero delegado de Bank of America, dijo a mediados de octubre, en entrevistas con CNBC y, según USA TODAY, con Bloomberg, que una persona debe autorizar los pagos antes de que se produzcan. El banco restringe el acceso de los agentes a los depósitos de consumidores. William Demchak, de PNC, sostuvo, según PYMNTS, que para que los agentes operen en cuentas tendrán que aprobarse leyes que desplacen la responsabilidad.

Buena parte de la inquietud apunta a Muse, el asistente que Meta lanzó en septiembre con funciones financieras mediante una integración con Plaid, según Fortune. Según USA TODAY, Muse alcanzó los 10 millones de usuarios el 21 de octubre. La banca teme que un agente así acabe moviendo depósitos hacia cuentas mejor remuneradas sin que el cliente supervise cada paso.

Las declaraciones de Dimon, Citi, Schwab y Moynihan son públicas y atribuidas. Los incidentes de agentes que actúan por su cuenta proceden de fuentes anónimas, y Reuters, al recoger la exclusiva, indicó que no había podido verificarla de forma independiente.

¿Cómo reparte el riesgo el nuevo contrato de Wells Fargo?

El acuerdo de acceso en línea de Wells Fargo que entra en vigor el 24 de noviembre de 2026 considera autorizadas por el cliente las operaciones de sus representantes autorizados y delegados. Eso incluye las de los agentes de IA que estos utilicen. La cláusula abarca expresamente las que el cliente «no quería o no pretendía».

Salvo que la ley aplicable lo prohíba, el cliente es el único responsable de esas operaciones y de supervisar a esos representantes, y la autorización solo decae cuando lo comunica y el banco ha tenido ocasión de actuar. Si el cliente da acceso a un agente de IA, el contrato añade que asume el riesgo de ese acceso.

SecureWorld, que analizó la cláusula, advierte de que aún no se sabe si resiste cuando el agente se excede en sus instrucciones o cuando se roban las credenciales de su proveedor. En Estados Unidos, la Regulation E ya excluye de las transferencias no autorizadas las que hace una persona a la que el consumidor entregó el medio de acceso, hasta que este avisa a la entidad. Ese marco explica por qué el planteamiento de Wells Fargo tiene recorrido allí.

¿Qué dice PSD2 de una operación que el cliente no quiso hacer?

La Directiva (UE) 2015/2366, conocida como PSD2 y transpuesta en España por el Real Decreto-ley 19/2018, pone en el proveedor de pagos la carga de probar que la operación se autenticó correctamente. En la directiva, con su equivalente en el RDL, estas son las reglas principales.

• El artículo 72 (44 del RDL) obliga al proveedor de pagos a demostrar que la operación se autenticó, se registró con exactitud, se contabilizó y no se vio afectada por un fallo técnico, según el texto del Single Rulebook de la EBA. El uso registrado del instrumento de pago no es necesariamente suficiente para probar que el ordenante autorizó la operación ni que actuó con negligencia grave, y el proveedor debe aportar pruebas de esa negligencia o del fraude.
• El artículo 73 (45 del RDL) exige devolver el importe de una operación no autorizada de inmediato y, como muy tarde, al final del día hábil siguiente. El cliente debe haberla comunicado sin demora y dentro de los 13 meses que fija el artículo 71 (43 del RDL).
• El artículo 74 (46 del RDL) limita a 50 euros la pérdida del ordenante por un instrumento extraviado, sustraído o apropiado indebidamente, salvo fraude o incumplimiento deliberado o por negligencia grave de sus obligaciones. Si el proveedor no exigió autenticación reforzada, el ordenante no soporta pérdida alguna salvo que haya actuado de forma fraudulenta.
• El artículo 69 (41 del RDL) fija esas obligaciones, entre ellas proteger las credenciales de seguridad personalizadas, y exige que las condiciones de uso del instrumento sean objetivas, no discriminatorias y proporcionadas.

Para las empresas, el artículo 61 de PSD2 permite pactar que no se apliquen, total o parcialmente, las reglas de prueba y de responsabilidad cuando el cliente no es consumidor. España usó la opción de proteger también a las microempresas, de modo que el artículo 34.1 del RDL limita ese pacto a los clientes que no sean consumidores ni microempresas, y la obligación de reembolso no figura entre lo que puede excluirse.

Parte de una cláusula como la de Wells Fargo podría trasladarse así a un contrato de banca corporativa, y la tesorería que deje a un agente operar en la cuenta de la empresa debería revisar antes qué ha firmado.

PSD2 no prevé un régimen específico para los pagos iniciados por agentes, que siguen sometidos a las reglas generales y a la autenticación reforzada del reglamento técnico, como recuerda el despacho Osborne Clarke. En España, el Tribunal Supremo, en su sentencia 571/2025, de 9 de abril, sobre un caso de phishing con duplicado de SIM, exigió que el consentimiento del usuario de servicios de pago sea real y consciente, según el análisis que recoge Economist & Jurist.

¿Qué cambia la sentencia C-70/25 del TJUE?

El 15 de octubre de 2026, el TJUE resolvió una cuestión prejudicial de un tribunal polaco (comunicado 147/26). Una clienta que vendía un objeto por internet recibió un enlace fraudulento, introdujo sus credenciales en una web que suplantaba a su banco y perdió unos 700 euros. Lo comunicó al día siguiente y el banco se negó a devolverlos alegando negligencia grave.

El Tribunal dio la razón a la clienta. La negligencia grave no permite negarse al reembolso inmediato, y la única excepción es la sospecha fundada de fraude del ordenante, comunicada por escrito a la autoridad nacional, que en España es el Banco de España. El banco puede intentar recuperar después lo pagado, pero tiene que demostrar esa negligencia. El abogado Rob Bratby, en su análisis de la sentencia, la considera la lectura correcta del texto. También critica que el Reglamento de Servicios de Pago pactado en Bruselas permitiría, ante sospechas objetivamente justificadas de negligencia grave, retener el reembolso hasta 15 días hábiles.

PSD2 sigue siendo la norma aplicable. El Reglamento de Servicios de Pago y la directiva PSD3, que la sustituirán, tienen acuerdo político desde noviembre de 2025, y la comisión ECON del Parlamento Europeo aprobó el texto pactado el 5 de mayo de 2026. A 27 de octubre seguían pendientes de adopción formal, con el pleno previsto para el 14 de diciembre según la ficha del procedimiento del Reglamento. Según PwC, ambas normas se aplicarán 21 meses después de su entrada en vigor, así que las disputas sobre pagos iniciados por agentes se resolverán previsiblemente con PSD2 y las normas que la transponen, como el RDL 19/2018, hasta bien entrado 2028.

El caso trata de phishing, no de agentes de IA. Su razonamiento parece trasladable siempre que la operación sea efectivamente no autorizada, que es precisamente lo que se discutirá cuando el cliente haya configurado el agente. Si se considera no autorizada, el banco reembolsa sin esperar y soporta la carga de probar la negligencia.

¿Es negligencia grave dar la contraseña a un agente?

Muchos comités de riesgos europeos dirán previsiblemente que sí, con la lógica del contrato de Wells Fargo. Compartir credenciales vulnera las condiciones del servicio y el artículo 69 de PSD2, y por tanto la pérdida causada por un agente al que el cliente dio acceso voluntariamente sería negligencia grave y correría de su cuenta. A eso se suma la sensación de que se trata de un fenómeno estadounidense, ligado a productos que todavía no han llegado aquí con funciones financieras.

El argumento tiene fundamento, porque un cliente que entrega su contraseña a un tercero se aparta de sus obligaciones, y ningún banco puede asegurar una sesión que el titular ha cedido.

¿Por qué alegar negligencia grave protege menos al banco de lo que parece?

Tras la sentencia C-70/25, alegar negligencia grave no frena el reembolso de una operación no autorizada, y lo que haya que demostrar después es negligencia grave, no un simple descuido.

No nos consta ninguna resolución europea que haya calificado como negligencia grave delegar en un asistente de IA. El despacho Taylor Wessing analiza los agentes de pago que habilita el proveedor de servicios de pago. Concluye que, si el agente compra algo que no cumple los criterios del cliente, la operación tenderá a considerarse no autorizada y el proveedor que lo habilitó será en general responsable. El escenario de un agente externo que usa la contraseña del cliente sigue sin resolver.

Un agente puede ser manipulado con instrucciones ocultas en el contenido que procesa, un riesgo que ya analizamos en casos como GhostJacking y los registros envenenados. Si el agente actúa porque un tercero lo ha secuestrado, sostener que el cliente quiso la operación resulta todavía más difícil.

PSD2 ya resolvió una versión de este problema con los agregadores financieros, porque el Reglamento Delegado (UE) 2018/389 obliga a los bancos a ofrecer una interfaz de acceso, específica o la de clientes adaptada, en la que los proveedores terceros deben identificarse. Un agente que maneja un navegador con la contraseña del cliente no pasa por esa identificación. En nuestra opinión, una entidad que nunca intentó averiguar con quién trataba lo tendrá más difícil para alegar después que no lo sabía, aunque sigue abierto si un proveedor de agentes que inicia pagos presta un servicio regulado por PSD2.

Queda la idea de que es un asunto estadounidense. Los productos y los contratos son locales, pero un agente capaz de manejar un navegador puede operar también en la banca electrónica de una entidad española. En Europa, sin embargo, la autenticación reforzada exige un segundo factor para los pagos, salvo exenciones, y repetir la autenticación al menos cada 180 días para seguir consultando la cuenta, lo que obliga al agente a depender del titular.

¿Cómo distingue un banco al cliente de su agente?

Bloquear sin más tiene un límite evidente, porque un banco que no distingue al agente del cliente tampoco puede bloquearlo con precisión. Los controles útiles son los que generan, a la vez, capacidad de detección y prueba utilizable ante una reclamación.

¿Sirven las señales de automatización de la sesión?

El equipo de fraude puede correlacionar varios indicios. Entre ellos están una cadencia de navegación sin pausas humanas, las secuencias idénticas entre sesiones, las señales de navegadores controlados por programa y los dispositivos nuevos que completan una operación sin un solo titubeo. Ninguno es concluyente por separado, y hay que asumir que ciertos agentes imitarán el comportamiento humano. Su valor está en conservarlos junto a cada operación, porque refuerzan la prueba que el artículo 72 pone a cargo del banco.

¿Dónde encaja la autenticación reforzada ligada al dispositivo?

PSD2 ya exige autenticación reforzada, salvo exenciones, para las transferencias y para el alta de beneficiarios de confianza, y lo que decide es el factor elegido. Una passkey o una aprobación biométrica en el dispositivo de confianza obligan a que intervenga el titular y convierten la duda sobre quién autorizó en un registro verificable, la vía a la que apuntaba Durand ante USA TODAY. La autenticación multifactor basada en códigos de un solo uso que pueden reenviarse o interceptarse cumple la norma, pero no separa al titular de su agente. El mismo criterio sirve para cambios de límites o de datos de contacto.

¿Puede el banco ofrecer un canal legítimo a los agentes?

Si el banco solo prohíbe, el cliente seguirá dando su contraseña. Citi y JPMorgan ya dejan consultar saldos y movimientos mediante terceros autorizados, y el paso siguiente es un acceso con permisos acotados, tokens revocables y una identidad diferenciada para el agente. Meta trabaja con Sierra, según Fortune, en un protocolo para que los agentes personales se identifiquen y acrediten el permiso del cliente ante las empresas. Gobernar esos accesos es un caso de identidades no humanas, con sus inventarios, caducidades y revisiones, que desarrollamos en nuestro servicio de seguridad de identidades no humanas.

¿Hay que prepararse para llamadas de agentes y revocaciones masivas?

Según Axios, citado por SecureWorld, algunos agentes ya llaman a los centros de atención al cliente y varias entidades ensayan escenarios del «día después» para asegurar o restablecer rápidamente el acceso de los clientes. SecureWorld recomienda además comprobar que se pueden revocar sesiones de agentes a gran escala. Ambas cosas caben en el plan de respuesta, con una verificación distinta para llamadas que parezcan originadas por un agente y un procedimiento probado para cerrar en bloque las sesiones de un proveedor comprometido.

¿Cambia algo cuando el agente es del banco?

Las entidades que despliegan asistentes desarrollados internamente, o que exponen servicios a través de servidores MCP, afrontan el mismo problema desde el otro extremo. Los controles de seguridad para agentes de IA en producción y una auditoría de seguridad de agentes de IA y MCP antes de abrirlos a clientes reducen el margen de disputa sobre quién decidió qué.

¿Cuánto cuesta no decidir?

El coste directo son los reembolsos de operaciones no autorizadas, y recuperar ese dinero exige una prueba que será mucho más sólida si se capturó en el momento de la autenticación. Si el banco no exigió autenticación reforzada, el artículo 74 le deja además sin posibilidad de repercutir la pérdida al cliente salvo fraude.

El coste regulatorio llega por DORA, que exige a las entidades financieras un marco de gestión del riesgo TIC con políticas de autenticación sólida y control de accesos. Una entidad que no sabe qué proporción de sus sesiones manejan agentes tendrá dificultades para defender ante el supervisor que ese marco cubre su canal digital. Si el banco integra agentes de terceros en los servicios que ofrece, entra en juego también la gestión del riesgo de terceros.

Cabe esperar que las redes de fraude intenten hacer pasar sus operaciones por errores de un agente legítimo, y lo que hoy es un debate sobre comodidad del cliente puede convertirse en una vía de reclamaciones difícil de rebatir. La Agencia Española de Protección de Datos ya ha recibido la primera notificación de una brecha causada por un ataque ejecutado con un agente de IA, aunque en ese caso el agente lo manejaba el atacante y no un cliente.

¿Cuáles son las tres decisiones del comité de riesgos?

El comité de una entidad de pagos europea tiene por delante tres decisiones. La primera es el canal, es decir, si bloquea, ofrece solo lectura o abre un acceso acotado en el que cada agente tenga una identidad diferenciada. La segunda es la prueba, que depende de qué señales se capturan en cada sesión y de si serían suficientes ante un juez. La tercera es contractual y solo afecta a la banca de empresas que no sean microempresas, porque se trata de decidir si se usa el artículo 61 para trasladar al cliente corporativo el riesgo de sus agentes y cómo se le explica.

Con sus consumidores, un banco europeo no puede resolver el problema cambiando las condiciones generales, como ha hecho Wells Fargo. Su margen está en los controles que le permitan probar quién autorizó cada pago.

Este análisis tiene carácter informativo y no constituye asesoramiento jurídico. Se basa en información publicada hasta el 27 de octubre de 2026. Las referencias a incidentes en bancos estadounidenses se apoyan en fuentes sin identificar citadas por Axios y no han sido verificadas de forma independiente, y los tribunales no han resuelto aún cómo se aplica PSD2 a los pagos iniciados por agentes. Los cambios en contratos, procedimientos de reembolso o controles de autenticación deben contrastarse con la asesoría jurídica y con el supervisor.