Wells Fargo: el error de tu agente de IA corre por tu cuenta

Wells Fargo convierte a tu agente de IA en tu firma

Desde el 24 de noviembre, cada orden que un agente de IA ejecute dentro de una cuenta de Wells Fargo se considera dada por el titular, sin que el banco verifique nada. Lo dice la nueva sección 15 del Online Access Agreement, el contrato que regula la banca online y la app del cuarto banco estadounidense por activos, ya publicado en su versión definitiva.

Para un founder que ya usa agentes para conciliar gastos o programar pagos, la noticia tiene una consecuencia concreta: si el agente se equivoca, el responsable legal ante el banco eres tú, no el proveedor de la herramienta. Y el banco no tiene ninguna obligación de mirar qué hizo.

¿Qué dice exactamente la sección 15 del contrato?

La sección se titula "Third-Party Artificial Intelligence Agents or Agentic AI" y se despliega en ocho apartados, del 15(a) al 15(h). La definición de partida es deliberadamente ancha: vale como "AI Agent" cualquier software, aplicación o programa que ejecute acciones autónomas, semiautónomas o no autónomas por cuenta de alguien. Leída al pie de la letra, alcanza incluso a un script sin una gota de inteligencia.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El núcleo está en la 15(d): las instrucciones y transacciones iniciadas por el agente "se consideran iniciadas y autorizadas directamente por ti, sin verificación adicional". La 15(e) añade, en mayúsculas en el original, que su uso es "AT YOUR OWN RISK", y extiende la responsabilidad a los errores de interpretación, a las acciones que el agente emprende sin que nadie las pidiera y a las que nacen de entradas "incompletas, inexactas o manipuladas".

Esa última fórmula cubre el escenario que más preocupa a los equipos de seguridad: la prompt injection. Instrucciones ocultas en una web o en un correo que el agente lee y confunde con órdenes de su usuario. Si un agente engañado ordena un pago, para este contrato el pago es del cliente.

El banco, mientras tanto, declara en la 15(b) y la 15(e) que no proporciona, controla ni aprueba ningún agente, que no verifica su seguridad ni sus normas de privacidad y que no monitoriza ni filtra sus actividades. La asimetría es explícita: al cliente le toca vigilar cada paso; al banco le queda el poder de cambiar las reglas.

¿Qué pasa con la revocación y quién debe probarla?

Aquí está la parte que más fricción genera en la práctica. La 15(f) pone la revocación a cargo del cliente: debe hacerse "de forma correcta y oportuna", acompañada de todo lo necesario para que el agente deje de operar, y conservar la prueba para entregarla al banco si la pide. Hasta que no se notifique por los canales de la sección 17(d) —el teléfono 1-800-956-4442, operativo a todas horas, o una carta a la oficina de correspondencia de clientes en Portland, Oregón—, el titular sigue respondiendo de todo lo que el agente haga.

El contrato no define qué vale como prueba. Un portavoz de Wells Fargo dijo a American Banker que la entidad pide ese registro porque "puede no tener visibilidad" sobre cuándo se revocó la autorización. La consultora Elaine Duffus, de Wolters Kluwer, señaló al mismo medio el hueco que queda abierto incluso cumpliendo todo: "¿Qué pasa si hago todo lo que Wells Fargo dice y tengo un montón de pruebas de que le dije al agente que parara, pero el agente se descontroló? ¿De quién es la culpa entonces?".

Douglas Borthwick, exejecutivo de Morgan Stanley y Standard Chartered, fue más directo: "Es razonable que Wells Fargo quiera un registro de cuándo se cortó al agente, porque el banco no puede verlo. No es realista esperar que los clientes lo produzcan". Su argumento: una captura del chat demuestra que pediste el corte, no que el agente se detuvo.

La secuencia que sí deja rastro verificable tiene cuatro pasos:

Desvincular la cuenta desde los ajustes del proveedor del agente y borrar las credenciales guardadas.
Cambiar la contraseña de Wells Fargo Online para que no pueda reutilizar la anterior.
Llamar al número de la sección 17(d) y anotar fecha, hora y operador.
Guardar capturas, correos de confirmación del proveedor y el registro de la llamada.

La 15(g) agrega el otro lado de la moneda: el banco podrá exigir el registro de agentes, modificar, limitar o cerrar API y canales de acceso, y prohibir o suspender a un agente —incluso parcialmente, dejándole leer el saldo pero no pagar—. Si eso ocurre, el contrato dice que Wells Fargo no responde de las consecuencias.

¿Por qué los bancos están bloqueando agentes de IA?

Wells Fargo pone por escrito lo que el resto del sector resuelve con bloqueos técnicos. Axios reportó el 22 de octubre que Morgan Stanley bloquea a los agentes de terceros, mientras JPMorgan, Bank of America y Citi limitan su acceso, según recogió Daily Hodl. El detonante: agentes encontrados dentro de cuentas de clientes sin autorización del banco y comportamientos que parecían ir más allá de lo pedido por el usuario.

El caso de Citi es el más explícito. Naveed Anwar, responsable de plataformas y servicios de datos de Citi Services, explicó en Money20/20 que la entidad mantiene bloqueado el acceso agéntico de terceros, salvo funciones de solo lectura vinculadas a la banca abierta, y que antes de abrir esa puerta hace falta un esquema de "conoce a tu agente", informó DiarioBitcoin. Citi, con USD 2,6 billones en activos según ese medio, no discute la utilidad de la IA: discute quién autoriza qué.

El trasfondo económico no es menor. Según Incrypted, el economista jefe de Apollo, Torsten Slok, calculó que JPMorgan, Bank of America y Wells Fargo mantienen juntos US$1,6 billones en depósitos que no devengan intereses, cerca del 16% de sus pasivos. Si un ejército de agentes moviera ese dinero hacia cuentas mejor remuneradas, el costo adicional para los tres bancos rondaría los US$47.000 millones al año, casi la mitad de su beneficio anual combinado. Bloquear agentes también es defender el margen.

¿Qué significa esto para tu startup?

Si tu empresa opera en EE.UU. —o con proveedores que se rigen por contratos estadounidenses— el mensaje es que la responsabilidad se está desplazando hacia quien despliega el agente. La lección aplica igual en LATAM y España, porque el modelo contractual exporta: quien da la contraseña, carga con el riesgo.

Acción 1: separa el agente de la contraseña. Nunca entregues credenciales maestras de la cuenta corporativa a una herramienta externa. Usa acceso de solo lectura o credenciales tokenizadas donde el banco las reconozca, y deja las cuentas de nómina, impuestos y pagos a proveedores fuera del alcance de cualquier agente.

Acción 2: monta un registro de revocación desde el día uno. Define quién en la empresa es el custodio de cada agente financiero, con un log de fecha, hora, canal, captura y confirmación del proveedor. Si mañana hay que cortar a un agente, esa carpeta es tu defensa.

Acción 3: pon límites de gasto y doble aprobación humana. Un agente que puede iniciar pagos sin techo y sin revisión es exactamente el perfil de riesgo que estos contratos castigan. Fija montos máximos por operación y exige aprobación de una segunda persona por encima de un umbral.

Acción 4: revisa el contrato de tu proveedor de agentes. Si el proveedor no asume responsabilidad cuando su modelo se sale del mandato, esa cláusula vale oro en una negociación. El banco ya te dijo que no la asume: averigua quién queda en la cadena.

¿Y en Europa la regla es la misma?

No para consumidores. La PSD2, la directiva europea de servicios de pago, pone la carga de la prueba en el banco cuando el cliente niega haber autorizado una operación (artículo 72) y precisa que el simple registro del uso de credenciales no basta para demostrar la autorización. El artículo 74 limita a 50 euros la pérdida del cliente, salvo fraude o negligencia grave.

El nudo europeo es precisamente esa negligencia grave: entregar la contraseña a un agente podría leerse como incumplir el deber de custodia del artículo 69. La decisión queda caso por caso. El artículo 61 permite excluir esas protecciones solo cuando el cliente no es consumidor, es decir, con empresas.

En el Reino Unido el tema llegó al Parlamento. En una carta del 17 de julio de 2026 a Dame Meg Hillier, el gobernador del Bank of England recordó la posición del Financial Markets Law Committee: para el derecho inglés la IA es una herramienta, no un agente jurídico, porque carece de personalidad jurídica, y la responsabilidad queda en algún punto de la cadena de personas y empresas.

En España el enfoque va por otro lado. El Boletín reportó que en marzo Santander y Mastercard completaron un pago real ejecutado de punta a punta por un agente dentro de un entorno regulado, y que en julio BBVA, CaixaBank, Bankinter y Abanca participaron en transacciones impulsadas por Visa. La diferencia con el caso estadounidense es que ahí hubo autenticación, controles antifraude y autorización identificada, no una contraseña compartida.

Conclusión

Wells Fargo no prohibió los agentes de IA: los dejó entrar y trasladó el riesgo al cliente. Lo interesante es que la misma sección 15 deja abierta la salida, el registro de agentes de la 15(g): un agente con credenciales propias, reconocido por el banco y limitado a ciertas operaciones eliminaría la contraseña compartida, que es el origen del problema.

Mientras ese canal no exista, para Wells Fargo el agente con tu contraseña eres tú. Para un founder, la conclusión práctica es incómoda pero simple: cada agente financiero que despliegas hoy es una línea de responsabilidad que no aparece en tu balance. Conviene tratarla con el mismo rigor que un contrato con un cliente grande.