El pago no autorizado en la era agéntica: qué cambia tras la sentencia Tukowiecka

El pago no autorizado en la era agéntica: qué cambia tras la sentencia Tukowiecka

El 15 de octubre de 2026 el Tribunal de Justicia de la Unión Europea dictó la Sentencia de la Sala Primera en el asunto Tukowiecka, C‑70/25, que interpreta los artículos 73, apartado 1, y 74, apartado 1, de la Directiva (UE) 2015/2366, sobre servicios de pago en el mercado interior. El caso partía de un fraude de phishing clásico. Una clienta de un banco polaco introdujo sus credenciales en una web que imitaba la de su entidad, un tercero ordenó un pago con ellas, y el banco se negó a reembolsarlo alegando que la clienta había actuado con negligencia grave. El Tribunal, en su apartado 52, declara que el proveedor de servicios de pago no puede negarse a reembolsar de inmediato una operación no autorizada por considerar que el cliente la hizo posible por negligencia grave. El reembolso debe producirse a más tardar al final del día hábil siguiente a la notificación. Solo después puede el banco reclamar al cliente la pérdida, y tendrá que probar esa negligencia. La única excepción es la sospecha fundada de fraude del propio cliente, comunicada por escrito a la autoridad nacional. El principio es reembolsar primero y discutir después.

La sentencia llega en un momento en que una parte creciente de los pagos ya no la ordena directamente una persona, sino un agente de inteligencia artificial que compra, contrata o paga por cuenta de su usuario. Eso obliga a preguntarse si esta doctrina protege también al usuario cuyo agente ha realizado un pago que él no quería. La respuesta podría ser afirmativa, pero con una condición previa que la sentencia no resuelve: el pago tiene que calificarse como operación no autorizada. En Tukowiecka el Tribunal partió de que el pago era no autorizado, porque así lo había calificado el órgano remitente, y no examinó esa cuestión. En los pagos agénticos, precisamente ahí está el problema.

En la PSD2 una operación es autorizada cuando el ordenante ha dado su consentimiento para ejecutarla en la forma acordada con su proveedor de servicios de pago (artículo 64 de la Directiva y artículo 36 del Real Decreto-ley 19/2018). Si falta ese consentimiento, la operación es no autorizada y entra el régimen de los artículos 73 y 74, con el reembolso inmediato que ahora confirma el Tribunal. El sistema descansa sobre una premisa implícita: el banco no ve la voluntad del cliente, ve la autenticación, y presume que ambas coinciden porque quien autentica es la persona. En la era agéntica esa premisa se rompe. Entre la voluntad del usuario y la autenticación que recibe el banco se interpone un sistema que decide por sí mismo cuándo, a quién y cuánto pagar. La pregunta ya no es solo si se usaron las credenciales del cliente, sino a qué consintió exactamente el cliente al delegar en el agente.

Hay que partir de que el agente de IA no es un representante en sentido jurídico. No tiene personalidad, no puede ser mandatario y no puede prestar consentimiento propio. Lo que hace el usuario al configurarlo es emitir un consentimiento anticipado y genérico que el agente concreta después en operaciones específicas. El consentimiento sigue siendo del usuario, pero su contenido queda definido por el mandato que le dio al agente. Para delimitar lo autorizado frente a lo no autorizado hay dos lecturas extremas y una intermedia.

La primera lectura, es la que trata al agente como un mero instrumento. Si el usuario entregó al agente sus credenciales o un token y el pago se autenticó correctamente con ellos, hay consentimiento en la forma acordada y la operación es autorizada, sean cuales sean las instrucciones internas que el usuario diera al agente. Es la misma lógica que se aplica a quien presta la tarjeta a un tercero que gasta de más: frente al banco el pago es autorizado y el conflicto se resuelve entre el titular y quien usó la tarjeta.

La segunda lectura, es la que trata el mandato como la medida del consentimiento. Todo pago que el agente ejecute fuera de los límites que el usuario le fijó carece de consentimiento y es no autorizado, aunque técnicamente se haya autenticado bien. El problema de esta tesis es que hace depender la calificación de instrucciones que el banco no conoce ni puede verificar. Eso choca con la idea de que el consentimiento se presta en la forma acordada entre ordenante y proveedor.

Habría una tercera lectura intermedia, que es la que atiende a si el mandato forma parte de la forma de consentimiento pactada con el proveedor de pagos. Cuando los parámetros del mandato están integrados en el instrumento que el banco o el esquema emiten y controlan, el consentimiento queda definido por esos parámetros. Es el caso de los tokens agénticos con límites de importe, comercio, categoría o plazo, de mandatos autenticados con SCA en el momento de su creación o de autorizaciones delegadas registradas ante el proveedor. Un pago que los excede no se ha consentido en la forma acordada y es no autorizado. La analogía más próxima es la domiciliación SEPA, donde un adeudo sin mandato válido es una operación no autorizada aunque el sistema la haya procesado. En cambio, cuando los límites solo viven en la configuración del agente o en las condiciones del proveedor del agente, el banco recibe una autenticación válida sin restricción alguna. Frente a él la operación es autorizada, y el exceso es un incumplimiento del proveedor del agente frente a su usuario. El SCA podría aquí convertirse en el gran aliado de las entidades financieras. 

Aplicado a los dos grandes escenarios, el resultado es el siguiente. Si el pago es una operación no autorizada, la doctrina Tukowiecka se aplica de lleno. El banco debe reembolsar en el día hábil siguiente aunque considere que el usuario fue gravemente negligente al dar credenciales al agente, y solo después podrá reclamarle la pérdida probando esa negligencia. Si el pago se debe a un exceso de mandato, todo depende de dónde estén fijados los límites. Si están integrados en el instrumento frente al banco, el exceso convierte la operación en no autorizada y juega el reembolso inmediato. Si solo existen entre el usuario y el proveedor del agente, frente al banco el pago probablemente se considerará autorizado. En ese caso la sentencia no se aplica y la reclamación debe dirigirse contra el proveedor del agente o contra el comercio.

La distinción se complica en los supuestos de interferencia de terceros, y aquí conviene trazar una segunda línea, entre la toma de control del agente y su manipulación. Hay toma de control cuando un tercero llega a dar las órdenes al agente, por ejemplo mediante robo de tokens, secuestro de sesión o una prompt injection que hace que el agente ejecute instrucciones del atacante. Entonces la iniciativa del pago es del tercero y no del usuario, igual que en Tukowiecka la iniciativa fue del defraudador. La operación debe calificarse como no autorizada aunque se haya ejecutado dentro de los límites técnicos del mandato. Hay manipulación cuando el agente, actuando por cuenta del usuario y dentro de su mandato, es engañado y decide pagar a un comercio fraudulento que parecía legítimo. Entonces la situación se parece más al fraude de pago autorizado (APP fraud), en el que la víctima consiente aunque sea por error. Con el régimen actual de la PSD2 ese pago es autorizado y queda fuera del artículo 73. Los fallos propios del agente, como alucinaciones, errores de interpretación o compras equivocadas dentro de su mandato, siguen la misma suerte: son operaciones autorizadas, y el usuario solo dispondrá, en su caso, de las devoluciones previstas para pagos iniciados por el beneficiario o de acciones contractuales y de consumo.

La carga de la prueba juega a favor del usuario en esta nueva configuración. El artículo 72 de la Directiva y el artículo 44 del Real Decreto-ley obligan al proveedor de pagos a acreditar que la operación fue autenticada, registrada con exactitud y contabilizada, y que no se vio afectada por un fallo técnico. Además, la utilización del instrumento registrada por el proveedor no basta necesariamente por sí sola para probar que el ordenante autorizó la operación. En un pago agéntico, el banco tendrá que demostrar no solo que el token se autenticó, sino que la operación encaja en el consentimiento pactado. Si los parámetros del mandato están integrados en el instrumento, esa prueba depende de sus propios registros. Si no lo están, la prueba de lo que el usuario quiso realmente estará en los registros del proveedor del agente, un tercero ajeno a la relación de servicios de pago, y eso creará problemas probatorios relevantes en los litigios. A ello se suma el artículo 74.2 de la Directiva y su equivalente en el artículo 46 del Real Decreto-ley: si el proveedor del ordenante no exige autenticación reforzada, el ordenante no soporta consecuencias económicas salvo actuación fraudulenta. Queda abierta, eso sí, la discusión sobre cómo opera esta regla en las transacciones iniciadas por el comercio con credenciales almacenadas, que se consideran fuera del ámbito de la autenticación reforzada.

La negligencia grave, que tras Tukowiecka ya solo se discute después del reembolso, también se redefine. Si el usuario utilizó un canal agéntico ofrecido o admitido por su propio proveedor de pagos, difícilmente podrá reprochársele negligencia por delegar en un agente. Si, en cambio, entregó sus credenciales en bruto a un agente que opera por screen scraping o fuera de cualquier marco autorizado, el banco tendrá un argumento serio de incumplimiento de las obligaciones de custodia del artículo 69 de la Directiva y del artículo 41 del Real Decreto-ley, aunque deberá reembolsar primero.

La sentencia cambia así, en la práctica, el reparto temporal del riesgo de fraude. Muchas entidades venían usando la alegación de negligencia grave como filtro previo y retenían el reembolso mientras analizaban el caso. El Tribunal deja claro que esa práctica no es conforme con la Directiva: el banco reembolsa primero y litiga después, y tiene que probar la negligencia que antes se limitaba a alegar. En otras palabras, el proveedor de pagos asume la liquidez, el coste de investigación y el coste procesal de cada operación disputada. En importes pequeños, esos costes harán muchas veces antieconómico recuperar el dinero aunque el cliente fuera realmente negligente. La sentencia no crea un nuevo riesgo, pero lo adelanta y lo concentra en el balance de la entidad.

Los pagos agénticos multiplican esa exposición. Cada agente comprometido, cada prompt injection y cada exceso de un mandato integrado en el instrumento es una potencial operación no autorizada que el banco tendrá que reembolsar en el día hábil siguiente. En muchos de esos casos, la información necesaria para reconstruir lo ocurrido no estará en poder del banco, sino del proveedor del agente. Ante este fenómeno, la respuesta que percibo en buena parte del sector es la reticencia: no ofrecer canales agénticos propios, prohibir en las condiciones contractuales la cesión de credenciales a terceros y confiar en que esa prohibición traslade el riesgo al cliente. Es una estrategia comprensible, pero a mi juicio equivocada. Los usuarios ya delegan pagos en agentes, con o sin permiso de su banco, a través de tarjetas almacenadas, credenciales compartidas o automatizaciones que el banco no ve. No admitir a los agentes no elimina el fenómeno. Lo deja fuera del perímetro contractual de la entidad, que pierde así la herramienta más eficaz que tiene para controlar el riesgo: definir la forma del consentimiento. Sin mandatos integrados en el instrumento, cada disputa se convierte en una discusión abierta sobre qué quiso autorizar el cliente, con la carga de la prueba del lado del banco. Y la prohibición contractual de usar agentes solo sirve para alegar negligencia grave en una segunda fase que, tras Tukowiecka, llega tarde y cuesta dinero.

Este riesgo no es exclusivo de la banca. En un mercado cada vez más fintech, casi cualquier empresa acepta pagos, los intermedia o los gestiona por cuenta de terceros: entidades de pago y de dinero electrónico, marketplaces, plataformas de suscripción, proveedores de servicios de criptoactivos con funcionalidades de pago y negocios que integran la iniciación de pagos en su propio producto. Para todas ellas el pago agéntico plantea preguntas que hasta hace poco no se planteaban. Una es si están asumiendo, sin saberlo, las obligaciones de reembolso de un proveedor de servicios de pago. Otra es si el agente que han integrado en su producto presta en realidad un servicio de iniciación de pagos sujeto a autorización. También quién soportará las devoluciones cuando el cliente niegue haber querido una compra que hizo su agente, y si sus contratos con proveedores tecnológicos, adquirentes y usuarios reparten ese riesgo o simplemente no lo contemplan. Los comercios que aceptan pagos iniciados por agentes, además, quedarán expuestos a retrocesiones y reclamaciones cuyo origen ni siquiera podrán identificar.

Por eso el asesoramiento en este terreno debe hacerse con calma y no a golpe de titular. No basta con leer la sentencia como una victoria del consumidor frente al banco. Hay que situar a cada cliente en su posición dentro de la cadena de pago, revisar si su arquitectura técnica permite delimitar el consentimiento y diseñar contratos marco que regulen expresamente las operaciones iniciadas por agentes. También hay que asegurar que alguien conserva los registros que serán la prueba decisiva en cualquier controversia, y valorar con realismo el coste de reembolsar primero y discutir después. Mientras el Tribunal de Justicia no se pronuncie sobre el concepto de consentimiento en pagos delegados a sistemas autónomos, será esa arquitectura contractual y técnica la que determine quién soporta la pérdida. Las entidades que integren a los agentes en su perímetro con mandatos definidos, límites verificables y una asignación clara de responsabilidades podrán gestionar este riesgo e incluso convertirlo en ventaja competitiva. Las que se limiten a prohibirlos seguirán soportándolo igualmente, pero sin control sobre él y con la doctrina del Tribunal de Justicia en contra.

Si eres una entidad financiera y quieres analizar cómo prepararte para la era de la IA, contacta con nosotros. 

ATH21 es la primera firma española de servicios legales integrales especializada en activos digitales y FinTech. Ofrecemos soluciones legales reales para los nuevos modelos de negocios, adaptándonos a cada proyecto, según la jurisdicción del momento en un entorno tan cambiante. Participamos en el desarrollo de proyectos internacionales basados en blockchain y activos digitales desde 2010.

Si quieres saber más sobre nuestros servicios o necesitas asesoría legal personalizada no dudes en escribirnos a hello@ath21.com