Los bancos en EU ya bloquean agentes de IA que se metieron solos a las cuentas de sus clientes

Por eso William Demchak, CEO de PNC, calificó las transacciones de agentes dentro de cuentas como "incrediblemente inseguras" y agregó algo que vale la pena subrayar: para que esto funcione de forma segura "va a tener que haber leyes sobre a quién le toca la responsabilidad" cuando algo sale mal. Ese es, en esencia, el problema que toda la industria de agentes todavía no resuelve: no existe un estándar compartido de quién responde cuando un agente actúa mal con acceso delegado.

El parche que ya existe (y por qué no es suficiente)

La mayoría de los bancos mencionados en el reporte de Axios ya ofrecen, o están moviéndose hacia, acceso de solo lectura para herramientas externas — el mismo modelo que llevan años usando con software como Quicken: el agente puede ver saldos y movimientos, pero no puede mover un centavo. Es un parche razonable a corto plazo, y probablemente el default correcto para cualquier integración con datos financieros hoy.

Pero no resuelve el problema de fondo, y los propios bancos lo saben. Según Axios, hay ejecutivos que admiten que el dinero solo no alcanza para arreglarlo, porque la tecnología cambia tan rápido que expone debilidades nuevas en tiempo real. El read-only compra tiempo. No es gobernanza.

Lo que sí está funcionando

• Revocar y reescribir términos de servicio en lugar de solo bloquear casos individuales — Morgan Stanley ya empezó a bloquear agentes de terceros de forma activa en su plataforma.
• Separar "ver" de "actuar" como regla dura, no como configuración opcional — ningún banco de los citados permite que un agente mueva dinero, sin excepción.
• Planificar el "día después" — varios bancos están invirtiendo en procesos para restaurar o asegurar el acceso de un cliente rápido si algo sale mal, asumiendo que un incidente va a pasar tarde o temprano.

El patrón que se repite fuera de la banca: compartir contraseñas en vez de dar permisos

Nada de esto es exclusivo de instituciones financieras. El error de fondo — darle a un agente las credenciales reales de una persona en vez de un permiso delegado y limitado — es el mismo que ya se ha visto en herramientas de marketing conectadas a cuentas de anuncios, en agentes de soporte con acceso directo a un CRM, y en asistentes de compras con las contraseñas de un e-commerce. La diferencia es que la banca tiene algo que la mayoría de las industrias todavía no: reglas explícitas de quién puede iniciar sesión, y ejecutivos dispuestos a bloquear agentes incluso a costa de "fricción" para el usuario.

Esa disciplina todavía no existe en la mayoría de los stacks de marketing y producto digital. La mayoría de las integraciones de agentes que hemos visto en el último año se construyeron rápido, conectando un modelo directamente a un panel de administración con una sola credencial compartida, sin capas intermedias de permisos. Funciona en una demo. Es exactamente el patrón que, llevado a un contexto con dinero real, generó la nota de Axios.

Lo que esto significa para agencias, developers y tu producto

En Geek Vibes lo vemos constantemente cuando evaluamos integraciones con clientes que ya están probando agentes para marketing, ventas o soporte: el hueco de gobernanza que describen los bancos es el mismo que enfrenta cualquier agencia o producto el día que conecta un agente de IA a sistemas de un cliente, un CRM, un ERP, o una cuenta de anuncios. Algunas reglas que sacamos directo de este caso:

• Nunca diseñes un flujo donde el agente necesita el usuario y contraseña real de una persona. Si tu arquitectura depende de eso, ya perdiste la trazabilidad antes de escribir una línea de código — es exactamente el error que generó esta historia.
• Usa acceso delegado con scopes explícitos (OAuth, API keys granulares), nunca credenciales compartidas. Define de antemano qué puede ver el agente y qué puede hacer, como categorías separadas y auditable por separado.
• Haz "solo lectura" el default, y "puede actuar" la excepción que se otorga explícitamente, acción por acción si es necesario — moverse de más permisivo a menos permisivo después de un incidente es mucho más caro (en confianza y en cliente) que empezar restrictivo.
• Diseña para poder distinguir "lo pidió el humano" de "lo decidió el agente" en tus logs, desde el día uno. Si hoy no puedes responder esa pregunta con certeza para una acción crítica, tienes la misma brecha que describe Axios.
• Asume que vas a necesitar un plan de "día después" antes de que lo necesites — qué pasa si un agente de un cliente hace algo que no debía, quién se entera primero, y cómo se revierte.

Si tu agencia está construyendo agentes que tocan inventario, campañas pagadas, CRM o facturación de un cliente, la pregunta de Demchak — ¿quién responde cuando el agente se equivoca? — es exactamente la que tu contrato y tu arquitectura deberían contestar antes de que un cliente la haga por ti.

La lección de este caso no es "no uses agentes". Es que la velocidad con la que se están desplegando agentes está adelantada a la velocidad con la que se están diseñando los permisos, los contratos y la responsabilidad legal alrededor de ellos — y eso es exactamente el tipo de brecha que una agencia seria debería cerrar por su cliente, no asumir que el proveedor del modelo ya la resolvió.

Si estás evaluando dar acceso de un agente a sistemas de tu negocio o de un cliente — y quieres hacerlo con permisos bien diseñados en vez de credenciales compartidas — escríbenos a hello@geekvibes.agency.