Cuando dos grandes instituciones financieras de Estados Unidos confirman, en la misma semana, que ponen límites a los agentes de IA externos, el mensaje trasciende a la banca. La pregunta ya no es si un agente puede actuar en nombre de un cliente, sino bajo qué reglas, con qué identidad y quién responde cuando algo sale mal.
El 16 de octubre, Rick Wurster, CEO de Charles Schwab, dijo en Bloomberg Television que la firma bloquea a agentes de IA externos que intentan mover dinero de sus clientes, entre ellos Muse, el agente personal de Meta. Según lo reportado por The Next Web y Forkast, Wurster recibe un reporte semanal con decenas de intentos bloqueados. Resumió el problema así: la firma no puede controlar al agente, el cliente tampoco, y si algo sale mal, la pregunta es quién responde.
En la llamada de resultados de JPMorgan, Jamie Dimon advirtió: “no quieres agentes descontrolados”. Un vocero del banco precisó a Fortune el alcance: JPMorgan bloquea a los agentes de terceros que intentan acceder a las cuentas con las credenciales bancarias de los clientes, y respalda el intercambio de datos autorizado por el cliente a través de proveedores de open banking.
El matiz importa. No se trata de rechazar toda IA ni todo agente externo, sino de impedir los que entran con las credenciales del cliente, sin identidad propia ni límites definidos. Schwab ofrece su propio asistente, Charley, y planea habilitar servidores MCP (Model Context Protocol) para que un modelo elegido por el cliente consulte saldos e información de investigación, pero sin mover dinero.
Por qué importa más allá de la banca
El problema de fondo es de control y responsabilidad, y no es exclusivo de las finanzas. Cualquier empresa con clientes, proveedores o empleados que empiecen a usar agentes enfrentará la misma disyuntiva: un distribuidor cuyo agente intenta hacer pedidos en el portal de compras, un cliente cuyo asistente consulta un envío, un empleado que conecta un agente a su CRM. Más que esperar a que alguien más fije las reglas, cada organización necesita definir desde el diseño quién es responsable, qué controles existen y cómo se detiene una acción.
El acceso de solo lectura es un buen primer paso, pero no es inocuo. Un agente que no puede modificar nada igual puede consultar, resumir y exponer información sensible: saldos, precios, contratos, datos de clientes. Por eso “solo lectura” es el comienzo de la conversación, no el final. Hay que definir qué puede ver el agente, en nombre de quién accede, con qué identidad y cómo queda registrada cada consulta para poder auditarla.
Cada acción, sus propias reglas
Un ejemplo sencillo: un agente de atención al cliente puede consultar el estatus de un pedido. Para cambiar la dirección de entrega, en cambio, necesita validar la identidad del cliente y cumplir ciertas condiciones, como que el pedido aún no haya salido del almacén. Y si solicita una devolución de dinero, la operación requiere otro nivel de autorización, quizá la aprobación de una persona. Consultar, modificar y mover dinero son tres acciones distintas, y cada una necesita sus propias reglas.
Hasta hace poco, la conversación sobre agentes giraba alrededor de lo que podían hacer. Ahora gira alrededor de cómo se les permite hacerlo. Incluso Meta, según Fortune, desarrolla con Sierra un protocolo llamado Poppy para que un agente se identifique, obtenga el permiso del cliente y trabaje con la empresa. La identidad del agente se está volviendo infraestructura.
Del principio a la solución
Un agente solo es tan confiable como los sistemas y datos a los que accede, pero conectar el ERP, el CRM y las plataformas de pago es apenas el punto de partida. Para convertir el principio en una solución se necesitan cuatro piezas: permisos por tipo de acción, no solo por sistema; límites de operación, como montos máximos, horarios o tipos de cliente; aprobaciones humanas para las acciones de mayor impacto; y mecanismos para detener una acción, o suspender a un agente, cuando algo no corresponde, con un registro de lo que vio y lo que hizo.
Ahí la integración de sistemas, la arquitectura de datos y el desarrollo de aplicaciones empresariales dejan de ser un tema técnico y se vuelven condición para adoptar agentes con control. La recomendación es empezar por casos de bajo riesgo, como consultas, medir y documentar, y ampliar los permisos de forma gradual conforme las reglas demuestren funcionar.
Qué deberían considerar los líderes
Primero, mapear qué procesos tocarían agentes, propios o externos, y clasificarlos por impacto: consultar, recomendar, ejecutar. Segundo, revisar si las APIs y las integraciones actuales permiten aplicar permisos por tipo de acción y dejar un registro auditable. Tercero, definir quién es responsable de cada decisión automatizada antes del primer incidente. Y cuarto, decidir cuándo interviene una persona y cómo se frena una operación en curso.
Los bancos no están frenando la innovación; están poniendo las reglas del juego antes de que el volumen las ponga por ellos. Es una lección útil para cualquier empresa que esté a pocos meses de recibir su primer agente en la puerta.
¿Tu organización está lista para que los agentes de IA interactúen con tus sistemas de forma segura? Agenda una conversación con un especialista de ISITA aqui y revisemos juntos permisos, límites y aprobaciones sobre tu arquitectura de integración y datos.
