La agencia de IA ya está actuando en tu nombre — y la pregunta que nadie logra responder bien todavía es: ¿cómo demostrar que tú autorizaste eso?
Imagina que le pediste a un agente de inteligencia artificial encontrar una camisa por menos de 150 dólares, pero dejaste bien claro: no compres nada. El agente encuentra la camisa. Y hace la compra de todas formas. Cuando vas a reclamar el cobro, cada empresa involucrada muestra su parte de la historia: la tienda dice que el pedido vino de tu cuenta, el proveedor del agente muestra que la instrucción era solo buscar, y el servicio de pago confirma la transacción. Cada registro puede estar correcto. Pero ninguno de ellos conecta el cobro con la tarea que realmente diste: buscar, pero no comprar.
Este escenario no salió de un guion de ciencia ficción. Es una laguna técnica y legal real que ya se está formando mientras los agentes de IA ganan cada vez más autonomía para actuar en nuestro nombre en sistemas diferentes, de empresas diferentes, sin que exista una cadena verificable de autorización que atraviese todo eso. Y el problema se pone mucho más serio cuando dejamos de hablar de camisas y empezamos a hablar de transferencias de dinero, solicitudes médicas o apelaciones de beneficios. Pero vamos por partes. 👇
Qué cambia cuando un agente actúa en tu lugar
Un chatbot tradicional sugiere una camisa y espera. Un agente de IA puede usar tu cuenta, contactar otros servicios y completar la transacción solo. Una única frase dispara una secuencia de acciones repartidas por sistemas operados por empresas diferentes. Y aquí está el punto crítico: cada empresa solo puede verificar la parte que ella misma ve. Resolver una disputa exige una respuesta que atraviese todas al mismo tiempo: ¿este agente, actuando por esta persona, ejecutó esta acción dentro de los límites de esta tarea?
Una agencia de IA es, básicamente, la capacidad que tiene un sistema de inteligencia artificial de actuar de forma autónoma para completar tareas en nombre de una persona. Esto va mucho más allá de responder preguntas o generar textos: el agente puede acceder a sistemas externos, llenar formularios, interactuar con APIs, realizar búsquedas y, dependiendo de los permisos otorgados, cerrar negocios y ejecutar transacciones reales. Lo que era ciencia ficción hace cinco años está pasando ahora, en producción, con usuarios reales, dinero real y consecuencias reales.
Cuando un humano realiza una compra, existe una cadena clara de responsabilidad: la persona elige, confirma, paga y recibe. Si algo sale mal, la reclamación tiene un camino definido. Pero cuando un agente de IA realiza esa misma secuencia, distribuyendo decisiones por varios sistemas al mismo tiempo, la cadena de responsabilidad se fragmenta de una manera que la mayoría de las empresas y reguladores todavía no saben cómo reconectar.
Un proyecto de ley apunta al problema
En Estados Unidos, un proyecto de ley reciente puso el dedo exactamente en esa herida. El senador Mark Warner, de Virginia, presentó en julio de 2026 la llamada AI AGENT Act (S. 5051). El texto define un agente custodial de usuario como aquel autorizado a actuar por una persona de forma transparente, documentada, limitada y revocable, y exige que estos agentes mantengan registros en tiempo real de las acciones ejecutadas en nombre de los usuarios.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
La propuesta también orienta al NIST — el Instituto Nacional de Estándares y Tecnología de EE.UU. — a identificar protocolos o desarrollar estándares técnicos para verificar que un usuario delegó autoridad a un agente, además de mantener registros auditables de las acciones que ese agente ejecuta. Parece la solución perfecta, ¿verdad? Pero hay un detalle importante.
El proyecto no exige expresamente una cadena de evidencias verificable que atraviese los diferentes sistemas involucrados, desde el momento en que el usuario inicia la tarea hasta el resultado final. En el escenario de la camisa, esa cadena necesitaría conectar la instrucción del usuario al agente, las acciones del agente y los registros mantenidos por la tienda y por el servicio de pago. Sin esa conexión completa, cada empresa sigue viendo solo su propio pedazo.
Autorización y transacción: donde el sistema se rompe
El concepto de autorización dentro de sistemas digitales tradicionales es relativamente simple: haces clic en confirmar, escribes una contraseña, lees un código de verificación. Existe un momento claro en que tu intención se convierte en una acción registrada. Con agentes de IA autónomos, ese momento desaparece. La autorización puede haber ocurrido semanas antes, como parte de un permiso amplio concedido a una aplicación, o puede haber sido delegada a otro agente dentro de una cadena de sistemas que el usuario ni sabía que existía.
Muchos sitios usan OAuth, un protocolo de seguridad estándar de la industria para delegar autorización de acceso a servicios online sin exponer contraseñas. Genera un token de acceso que la aplicación presenta para entrar en un servicio protegido. El problema es que esa autorización permanente puede haber sido aprobada mucho antes de la tarea actual. La aplicación todavía puede presentar un token válido que permite finalizar la compra hoy, incluso cuando la instrucción del momento dice solo buscar, y no comprar.
O sea: la tienda ve un token utilizable y concluye la transacción. La restricción específica de esa tarea — no comprar — queda atrapada dentro del proveedor del agente y nunca llega hasta quien procesa el pago. Una transacción ejecutada por un agente recorre varios sistemas independientes: el modelo de lenguaje que decidió, la API que envió el comando, el sistema del proveedor que recibió el pedido, el gateway que procesó el monto. Cada uno tiene sus propios registros, pero no se comunican entre sí de forma lo suficientemente estructurada para responder a la pregunta más básica: ¿el usuario de hecho autorizó esto, en estas condiciones, con este alcance?
Y esto no es hipotético. Investigadores de seguridad ya demostraron cómo los agentes de IA pueden ser manipulados por ataques de inyección de prompt, donde un contenido malicioso encontrado durante la navegación altera las instrucciones que el agente estaba siguiendo. En ese escenario, la transacción ocurre, el registro muestra que el agente actuó dentro de los permisos, pero la autorización real nunca existió — y demostrarlo después, sin una cadena auditable, es casi imposible.
La evidencia necesita viajar junto con la acción
Para que este tipo de rendición de cuentas funcione de verdad, cinco cosas necesitarían estar en su lugar al mismo tiempo: una conexión verificable entre la cuenta del usuario, el agente en ese momento específico y la tarea; límites específicos de esa tarea; una conexión verificable a lo largo de toda la transacción; una verificación antes de cada acción; y registros cuya alteración posterior pueda ser detectada. La buena noticia es que los sistemas de pago ya comenzaron a montar esas piezas.
El primer registro identifica la cuenta autenticada que aprobó la tarea y el agente que recibió la autoridad. La tienda no puede confiar solo en el nombre del proveedor del agente. El proveedor conecta cuenta, agente y tarea en un registro de autorización y lo firma digitalmente, permitiendo que la tienda y el servicio de pago verifiquen quién lo emitió y si fue adulterado.
El proveedor también preserva la solicitud original y la convierte en límites que otros sistemas pueden aplicar. Para la tarea de la camisa: buscar durante 15 minutos, sin compra, sin transferir el poder de compra a otro agente. Antes de que el agente comience, el usuario ve y aprueba esa versión estructurada. Si la traducción está mal, se puede comparar la regla con las palabras que la originaron.
La referencia de tarea que conecta todo
Una forma de crear esa conexión es hacer que una referencia de tarea viaje junto con cada solicitud. Es única para un solo trabajo, no lleva nombre, número de cuenta ni ningún identificador directo, y aparece en el registro de todas las empresas participantes. Los ingenieros ya usan algo parecido, el identificador de rastreo, para correlacionar eventos de una misma operación mientras transita entre servicios.
Esa referencia conecta registros dispersos a un solo trabajo, pero no confiere autoridad por sí sola. Por eso necesita estar vinculada a la regla aprobada por el usuario dentro del registro firmado digitalmente por el proveedor. Como hasta un identificador aleatorio puede conectar actividades entre servicios, lo ideal es que tenga vida corta y sea visible solo para las empresas que participan en esa tarea específica.
Verificar la regla donde se mueve el dinero
Alguien entonces necesita validar la regla exactamente en el punto donde el dinero circula. En el momento del checkout, la tienda valida el registro de autorización firmado y evalúa la compra propuesta contra él. Una prohibición de comprar bloquea la transacción incluso cuando la aplicación tiene acceso más amplio a la cuenta. Una transferencia bancaria o la liberación de registros médicos podría disparar una confirmación nueva. Y cualquier autoridad traspasada a otro agente tendría que mantener la misma referencia de tarea y permanecer dentro del límite original.
Después de la decisión, el sistema de la tienda registra el agente, la referencia de la tarea, la regla evaluada, la hora, la decisión y el resultado. El servicio de pago guarda la misma referencia, y el proveedor mantiene la instrucción y la regla aprobada. Cada empresa mantiene un registro a prueba de adulteración, para que los cambios posteriores puedan ser detectados. Y el usuario recibe un recibo en lenguaje sencillo: tu agente buscó en tres tiendas e intentó finalizar la compra. La compra fue bloqueada porque comprar no estaba autorizado.
Lo que ya se está construyendo — y lo que todavía falta
El Agent Payments Protocol, o AP2, de Google, ya cumple con algunos de estos requisitos. Crea registros capaces de mostrar los límites aprobados por el usuario y la información presentada a cada participante cuando una transacción es disputada. El AP2 muestra cómo la evidencia podría viajar entre sistemas. Lo que todavía no resuelve es quién asume la pérdida, ni por cuánto tiempo cada empresa debe guardar esa evidencia y cómo recuperarla después.
Herramientas que usamos a diario
El NIST, por su parte, está revisando comentarios sobre un documento conceptual publicado en febrero de 2026 sobre identidad y permisos de agentes. Pregunta cómo un agente puede demostrar su autoridad, conectar esa autoridad a una persona y producir registros verificables. Pero el esfuerzo inicial propuesto cubre solo agentes que operan dentro de las organizaciones, donde hay más control y visibilidad. Agentes provenientes de fuentes externas no confiables quedaron fuera de esta primera etapa, aunque el documento dice que los agentes públicos o individuales podrán ser tratados más adelante.
Y es justamente ahí donde está el problema más espinoso. Los agentes de consumo que cruzan fronteras entre empresas representan exactamente el caso que el NIST pospuso. Cada compañía mantiene sus propios identificadores, su propio lenguaje de autorización y sus propias reglas de retención. Una disputa puede quedarse sin solución incluso cuando cada empresa presenta sus registros exactamente como fueron almacenados.
Desde el punto de vista regulatorio en Latinoamérica y España, la situación es igualmente compleja. Las leyes de protección de datos personales, los marcos de comercio electrónico e incluso el reglamento europeo de IA establecen principios importantes sobre responsabilidad y transparencia, pero ninguno de ellos fue diseñado pensando en agentes autónomos que toman decisiones en cadena y ejecutan transacciones sin intervención humana directa en cada etapa.
Por qué esto importa mucho más que una camisa de 150 dólares
Una disputa por una camisa de 150 dólares hasta se puede ignorar sin grandes traumas. Pero los registros pueden fallar exactamente de la misma forma cuando un agente mueve 200 mil dólares, presenta una apelación de beneficios o solicita la renovación de una receta médica en tu nombre. En esos casos, puede hasta ser fácil demostrar que el agente tuvo acceso al servicio. Demostrar si autorizaste o no a ese agente a hacer exactamente lo que hizo en tu nombre es una historia completamente diferente.
La asimetría de información aquí es enorme: quien construye el agente sabe exactamente lo que puede hacer, y quien lo usa muchas veces no tiene la menor idea. Eso convierte a la autorización en un acto que necesita ser mucho más granular, revisable y rastreable de lo que el modelo actual de aceptación única permite. Algunas iniciativas ya van en esa dirección, como el protocolo MCP de Anthropic y las discusiones en el ámbito del W3C sobre identidad de agentes, pero el ecosistema todavía está lejos de cualquier convergencia real.
El camino más realista a corto plazo no es esperar una solución técnica universal ni una regulación integral. Es combinar presión del mercado — usuarios y empresas exigiendo transparencia en las acciones de los agentes — con la adopción voluntaria de buenas prácticas por parte de los desarrolladores, como registros detallados de acción, alcances de permisos bien definidos y mecanismos de reversión accesibles. No es la solución ideal, pero es lo que está al alcance ahora. Y mientras no llega, entender que este problema existe ya es un paso importante — porque solo empieza a resolverse aquello que primero fue claramente visto. 👁️
