Cuando la IA adquiere autoridad
Durante los últimos años, las empresas se han centrado en lo que la IA generativa puede decirnos. Los agentes de IA introducen una pregunta bastante más trascendental: ¿qué pasa cuando el software puede decidir qué hacer a continuación y, después, llevarlo a cabo de verdad?
En julio de 2026, un agente de IA utilizado como parte de una evaluación de ciberseguridad de OpenAI comprometió parte de la infraestructura de producción de Hugging Face. Hay un contexto importante aquí antes de que nos dejemos llevar. Esta no era una aplicación empresarial normal que decidiera de repente atacar a otra empresa. OpenAI estaba probando deliberadamente modelos de gran capacidad frente a tareas complejas de ciberseguridad, y los clasificadores de producción utilizados habitualmente para evitar que los modelos realicen actividades cibernéticas de alto riesgo se desactivaron intencionadamente para la evaluación.
Aun así, merece la pena prestar atención a lo que ocurrió. Según las investigaciones posteriores, parece que el agente llegó a la conclusión de que la información que poseía Hugging Face podría ayudarle a completar el punto de referencia que se le había asignado. Encontró una vía de salida a través de una vulnerabilidad de día cero en la infraestructura utilizada por el entorno de evaluación, obtuvo un acceso más amplio a Internet, encadenó otras rutas de ataque, obtuvo credenciales y finalmente llegó a los sistemas de Hugging Face. La reconstrucción forense de Hugging Face abarcó unas 17.600 acciones individuales, agrupadas en aproximadamente 6.280 grupos.
La tentación, naturalmente, es recurrir al titular de "la IA escapó" o "la IA se volvió rebelde". No estoy seguro de que ninguno de los dos sea especialmente útil. Por lo que pudieron determinar las investigaciones, el software intentaba alcanzar el objetivo asignado y encontró una ruta que nadie esperaba que tomara. Hugging Face cree que el agente intentaba efectivamente engañar a la evaluación llegando a los sistemas de producción donde pensaba que podría haber información o soluciones de referencia disponibles.
Eso es considerablemente menos teatral, pero desde la perspectiva de la transformación digital es probablemente más importante.
Durante los últimos años, la mayoría de las organizaciones han experimentado la IA generativa como algo a lo que preguntar. Dale información, hazle una pregunta y obtén una respuesta. Puede resumir un contrato, analizar algunos datos, escribir código o redactar un correo electrónico, pero por lo general sigue habiendo una persona al otro lado que decide qué pasa a continuación.
Los agentes empiezan a difuminar esa frontera. Dale a esa misma inteligencia acceso a herramientas y podrá recuperar información, llamar a una API, actualizar un registro, ejecutar código, enviar un correo electrónico o realizar el cambio por sí misma. OpenAI describe a los agentes de forma muy similar: sistemas que pueden gestionar de forma independiente la ejecución de flujos de trabajo, tomar decisiones, seleccionar las herramientas adecuadas e interactuar con sistemas externos en nombre de un usuario.
El chatbot acaba de obtener acceso de escritura.
Ese cambio es la razón por la que la gobernanza de agentes de IA se está convirtiendo en una preocupación empresarial práctica en lugar de simplemente otra discusión sobre políticas. Una vez que el software puede tomar medidas en lugar de hacer recomendaciones, las preguntas sobre identidad, permisos, controles, auditabilidad y responsabilidad se trasladan a la propia arquitectura.
La automatización cambia cuando se le da intención al software, no instrucciones
El software lleva décadas cambiando las cosas, por lo que existe el peligro de exagerar lo que hay de nuevo aquí. No necesitamos IA para actualizar una base de datos, activar una API o ejecutar un flujo de trabajo. Los scripts, los motores de reglas, las plataformas de orquestación y los procesos automatizados llevan años realizando esas tareas perfectamente.
La diferencia está en cómo pasamos del objetivo a la acción. La automatización tradicional se diseña normalmente en torno a una ruta que alguien ha descrito de antemano. Cuando ocurra X, recupera Y. Si la respuesta es Z, realiza esta acción. Puede haber cientos de reglas, bifurcaciones y excepciones implicadas, pero alguien ha intentado modelar el proceso previamente.
Los agentes nos permiten potencialmente avanzar más hacia dar al software un resultado en lugar de cada instrucción necesaria para alcanzarlo. He aquí el problema. Averigua qué información necesitas. Decide qué herramientas son adecuadas. Gestiona lo que devuelvan y haz el trabajo.
Esa distinción es importante porque la ruta de ejecución puede volverse dinámica. Un agente puede empezar con un sistema, descubrir que necesita un contexto adicional, llamar a otra cosa, encontrarse con un resultado que no esperaba, revisar su enfoque y continuar. Las arquitecturas de agentes actuales se construyen explícitamente en torno a esta capacidad de gestionar un flujo de trabajo, elegir herramientas y tomar medidas en función del estado de la tarea.
Se trata de una propuesta materialmente diferente a la de la automatización convencional. El software ya no se limita a ejecutar un flujo predeterminado. Dentro de los límites que establezcamos a su alrededor, le otorgamos cierta discrecionalidad sobre cómo se desarrolla ese flujo.
Y ahí es donde esto se pone mucho más interesante que otra conversación sobre si la IA puede escribir un correo electrónico mejor.
La oportunidad consiste en eliminar la coordinación, no a las personas
Una cantidad sorprendente de trabajo dentro de una organización no es difícil porque una tarea individual sea especialmente complicada. Es difícil por la coordinación que se requiere entre las tareas.
Abre el CRM. Busca al cliente. Copia un identificador en la plataforma de facturación. Lee las notas. Comprueba otro sistema. Deduce lo que significan. Pregunta a otro equipo si algo es normal. Espera la respuesta. Actualiza la primera plataforma y envía un correo electrónico al cliente.
¿Le suena familiar?
Llevamos años intentando automatizar esos procesos, y la tecnología de flujo de trabajo convencional es extremadamente eficaz cuando los pasos se pueden describir de forma predecible. Las partes difíciles suelen ser las excepciones: el documento que no está estructurado correctamente, la cuenta que no coincide del todo, tres sistemas que no se ponen de acuerdo entre sí, o el punto del proceso en el que alguien necesita leer algo y comprender lo que significa antes de saber qué hacer a continuación.
Ese es precisamente el tipo de flujos de trabajo en los que los agentes pueden resultar útiles. Las directrices actuales de OpenAI identifican específicamente la toma de decisiones complejas, las reglas difíciles de mantener y la fuerte dependencia de información no estructurada como áreas en las que un enfoque basado en agentes puede ofrecer algo que la automatización determinista convencional no ofrece. También señala un punto importante: cuando esas características no están presentes, una solución determinista puede seguir siendo la mejor respuesta.
Si el software puede encargarse de parte de la coordinación entre sistemas, información y decisiones, existe potencialmente una ganancia de eficiencia significativa. No porque todos los implicados en el proceso desaparezcan de repente, sino porque podemos dejar de utilizar a las personas como un costoso middleware entre plataformas que nunca fueron especialmente buenas coordinándose entre sí.
Hay una distinción importante en este punto. El objetivo no debe ser necesariamente eliminar a las personas de la organización. Debería ser eliminar el trabajo que actualmente hacemos hacer a las personas simplemente porque la tecnología que hay debajo no puede manejar muy bien el contexto, la ambigüedad o las excepciones.
Por eso creo que la oportunidad en torno a los agentes es mucho más significativa que la productividad incremental. Redactar una respuesta a un cliente diez segundos más rápido es útil. Permitir que el software investigue el problema, concilie la información relevante y lleve adelante el proceso es algo completamente distinto.
Por supuesto, cuanto más adelante lleve el proceso, más cerca estará finalmente de una acción con consecuencias.
Y ahí es donde las cosas se complican bastante más.
La capacidad no es autoridad
Unos meses antes del incidente de Hugging Face, PocketOS publicó un relato sincero de un agente de IA que borró la base de datos de producción de la empresa. El borrado tardó nueve segundos. La recuperación tardó sesenta horas. Sus copias de seguridad existían, pero tenían tres meses de antigüedad porque el proceso de copia de seguridad había dejado de funcionar silenciosamente.
PocketOS también tiene muy claro que esto no fue simplemente un "problema de IA". La empresa afirma que el agente actuó con confianza utilizando permisos que nunca debería haber tenido, en un entorno que no presentaba suficientes restricciones en torno a la acción destructiva.
Esa es la lección útil.
Los humanos llevan años borrando bases de datos de producción, y los errores de software también han hecho una contribución respetable. Lo interesante es que el actor tenía suficiente autoridad para que su error importara.
Esto ya lo entendemos cuando el actor es humano. Alguien en atención al cliente puede estar autorizado a emitir un reembolso de £20 sin que a nadie le importe demasiado. £200 puede seguir siendo algo totalmente razonable. £20.000 probablemente requiera otra conversación.
Lo mismo se aplica a otros ámbitos. Un agente que identifica una falta de ortografía en los metadatos de un contenido y la corrige es probablemente algo bastante inofensivo. Si el campo que desea cambiar determina si ese contenido puede distribuirse en un territorio concreto, la consecuencia es muy diferente. Del mismo modo, un agente puede identificar correctamente un problema de configuración de producción, pero eso no significa que deba heredar derechos ilimitados para reconfigurar todo el entorno.
Nada de esto es especialmente exótico. Es gestión de identidades y accesos aplicada a un nuevo tipo de actor, y sospecho que se convertirá en uno de los pilares de una gobernanza eficaz de la IA de agentes.
Microsoft ya está tratando a los agentes en estos términos. Su guía actual recomienda una identidad de agente de IA única y dedicada, un propietario o patrocinador nombrado, un propósito y acceso a datos claramente documentados, acceso con privilegios mínimos, permisos de herramientas controlados, registro de actividad y rutas de revocación probadas. El trabajo del NIST en la misma área está examinando explícitamente la identificación, autorización, auditoría y el no repudio para los agentes de IA.
En términos prácticos, eso significa que los permisos de los agentes de IA deben tratarse con la misma seriedad que las cuentas de servicio y de humanos privilegiados. Un agente puede ser perfectamente capaz de determinar lo que cree que debería ocurrir sin tener derecho a hacer que ocurra.
Esa distinción es importante. Los controles de agentes de IA no pueden limitarse a preguntar si un modelo es técnicamente capaz de realizar una acción. Tienen que determinar si este agente en particular, actuando en este contexto en particular, está autorizado a realizarla.
Como nota al margen, sospecho que la proliferación descontrolada de agentes de IA se convertirá en uno de esos problemas que las organizaciones no creen tener hasta que alguien pregunta finalmente: "¿Cuántos agentes tenemos en realidad?". Ya hemos pasado por variantes de esto con aplicaciones SaaS, recursos en la nube, cuentas de servicio y claves API. No hay ninguna razón obvia para que el conjunto de agentes se organice mejor por sí solo, sobre todo en empresas donde la experimentación se delega deliberadamente entre los equipos.
Eso no significa centralizar cada iniciativa de IA. Es poco probable que un equipo central comprenda cada proceso lo suficientemente bien como para identificar todas las aplicaciones útiles por sí mismo. La innovación descentralizada puede ser totalmente sensata.
La autoridad descentralizada por accidente es un asunto diferente.
La IA de agentes hereda cada compromiso de su infraestructura digital
Hay otro problema incómodo debajo de todo esto. Su agente va a heredar su infraestructura digital existente.
Las relucientes API, los sistemas heredados, los registros de clientes incoherentes, la integración que alguien escribió hace ocho años y que nadie quiere tocar, y la plataforma que llama a un cliente de una manera mientras otra plataforma lo llama de otra. Una empresa crece, se compran plataformas, los equipos resuelven problemas individuales, se producen adquisiciones, los proveedores cambian y las prioridades se mueven. Al final, se acaba con lo que todo el mundo denomina cortésmente la arquitectura actual.
Ahora imagine a un agente tratando con un cliente que ha pagado por un servicio pero no puede acceder a él. La respuesta puede requerir información de los sistemas de CRM, facturación, autenticación, derechos de acceso y soporte antes de que nadie pueda determinar qué ha ocurrido realmente.
Un operador humano a menudo lidiará con las incoherencias casi sin pensar en ellas. Sabe que un sistema se actualiza antes que otro. Se da cuenta de que los identificadores son ligeramente diferentes. Quizá recuerde que los clientes con un paquete antiguo se comportan de forma diferente, o simplemente pregunte a la persona sentada a su lado porque la documentación no se ha actualizado desde 2023.
Asigne el trabajo a un agente y esas suposiciones tendrán que existir en alguna parte. ¿Qué sistema tiene la autoridad? ¿Qué ocurre si facturación dice que el pago se ha realizado correctamente pero la plataforma de derechos dice que la cuenta está inactiva? ¿La información es errónea o hay una regla de negocio que el agente no entiende? ¿Una plataforma va simplemente cinco minutos por detrás?
Se trata de antiguos problemas de datos y arquitectura con un nuevo consumidor. La diferencia material es que el consumidor ahora puede tomar medidas basándose en cualquier conclusión a la que llegue.
Unos datos deficientes suministrados a un chatbot pueden producir una respuesta errónea. Unos datos deficientes suministrados a un software autónomo pueden producir un resultado perjudicial.
También hay otra complicación. La información no tiene por qué ser errónea por accidente. Una investigación publicada en julio demostró ataques de inyección de datos en agentes, en los que información controlada por un atacante podía presentarse como datos contextuales aparentemente legítimos e influir en lo que un agente hacía posteriormente. Los investigadores identificaron vulnerabilidades en agentes web y de programación reales que podían dar lugar a clics no deseados, ejecución remota de código y acciones en la cadena de suministro de software.
Eso crea un cruce incómodo entre la arquitectura de datos y la seguridad. If la información puede influir en la acción, la procedencia de esa información, si se puede confiar en ella y cuánto peso debe darle el agente ya no son preocupaciones abstractas de gobernanza. Pasan a formar parte del modelo de ejecución.
Esta es también la razón por la que tendría cuidado con la idea de que los agentes hacen que la deuda técnica sea de algún modo menos importante. Un agente puede hacer que los entornos fragmentados sean más fáciles de navegar porque puede razonar sobre una tarea en lugar de depender totalmente de una ruta de integración fija, pero sigue necesitando acceso a los sistemas, interfaces utilizables, datos significativos, permisos adecuados y alguna idea de qué hacer cuando algo falla a mitad de camino.
Si la API no existe, el agente necesita otra vía de acceso. Si el mismo cliente tiene seis identificadores, alguien o algo tiene que establecer si representan a la misma persona. Si una regla de negocio no documentada es importante para la decisión, ese conocimiento debe estar disponible en alguna parte.
Colocar una capa de orquestación inteligente frente a una infraestructura desordenada no hace que esta deje de estar desordenada. Puede que facilite la navegación por el desorden. También puede permitir que las consecuencias de ese desorden se propaguen considerablemente más rápido.
La supervisión humana tiene un coste económico
En este punto de la mayoría de las conversaciones, alguien dirá que siempre habrá un humano en el proceso (human in the loop).
Eso suena tranquilizador, pero plantea una pregunta obvia: si alguien todavía tiene que revisar y aprobar todo lo que hace el agente, ¿cuánto hemos automatizado realmente?
Imagine que nuestro agente de atención al cliente ha comprobado cinco sistemas, ha identificado un problema con la cuenta, ha establecido que al cliente se le cobró incorrectamente y ha calculado que corresponde un reembolso de £20. A continuación, coloca todo el asunto en una cola para que alguien haga clic en "Aprobar".
Es posible que se siga produciendo un ahorro significativo porque se ha automatizado la investigación, pero ejecute ese proceso en decenas de miles de transacciones y habrá conservado una operación manual de gran envergadura. El cuello de botella se ha desplazado en lugar de desaparecer.
Aquí es donde parte del lenguaje más conservador en torno a la IA de agentes empieza a entrar en conflicto con la economía de la automatización. Introducimos la autonomía porque queremos que el software elimine trabajo de un proceso, y luego nos ponemos lo suficientemente nerviosos con la autonomía como para volver a introducir a una persona en cada transacción.
Al final, eso anula bastante el propósito.
Por lo tanto, el reto de la supervisión de agentes de IA es que una mayor supervisión no es automáticamente mejor. Cada paso de aprobación puede reducir un tipo concreto de riesgo, pero también vuelve a introducir costes, latencia y esfuerzo manual en el proceso. La pregunta más adecuada es dónde aporta valor realmente el juicio humano.
Si el reembolso es de £20, las reglas son claras, todos los sistemas pertinentes están de acuerdo y la acción puede revertirse fácilmente, tal vez nadie necesite aprobarlo. Si el importe es de £20.000, dos sistemas no están de acuerdo o la situación cae fuera de los parámetros normales, ese parece un momento excelente para involucrar a alguien.
Para muchos procesos, el destino útil probablemente no sea un humano en el proceso, sino un humano por excepción. El trabajo rutinario y bien comprendido se vuelve cada vez más autónomo, mientras que los casos inusuales, ambiguos o de consecuencias graves se derivan a una instancia superior.
Eso todavía deja mucho espacio para introducir la autonomía de forma gradual. Un agente puede empezar observando y recomendando. Una vez comprendido su comportamiento, puede preparar acciones para su aprobación. Con el tiempo, clases específicas de acciones rutinarias y reversibles pueden ejecutarse automáticamente, involucrando a las personas cuando el proceso supere un umbral acordado.
La guía de OpenAI adopta un enfoque similar basado en el riesgo. Recomienda la intervención humana cuando los agentes superen los umbrales de fallo definidos y en torno a acciones que sean sensibles, irreversibles o de alto riesgo, como grandes reembolsos o pagos.
PocketOS llegó al mismo problema desde una dirección considerablemente menos teórica. Tras el incidente de su base de datos, las operaciones destructivas requieren ahora una confirmación humana explícita. La empresa no respondió abandonando los agentes autónomos. Afirma que sigue ejecutando varios agentes autónomos específicos en producción, al tiempo que modifica la ubicación del límite de control.
Esa me parece la forma más útil de pensar en la supervisión humana. Es un control que debe aplicarse allí donde la consecuencia lo justifique, no necesariamente un modelo operativo permanente para cada acción realizada por el software autónomo.
Al fin y al cabo, el objetivo de la automatización es automatizar. El problema de diseño consiste en decidir dónde mejoran las personas realmente el resultado y dónde se las mantiene simplemente porque aún no confiamos lo suficiente en el sistema como para eliminarlas.
La autonomía sin trazabilidad es operativamente indefendible
Si avanzamos hacia los humanos por excepción, otra cosa pasa a ser más importante en lugar de menos: entender qué hizo realmente el agente.
La investigación de Hugging Face es un ejemplo extremo de utilidad. Su reconstrucción forense abarcó unas 17.600 acciones en miles de grupos, con los investigadores reconstruyendo cómo se movió el agente a través de los sistemas y cómo adaptó su comportamiento a lo largo del tiempo.
Lleve eso a un proceso empresarial normal. Un cliente dice que algo cambió incorrectamente en su cuenta y usted descubre que un agente realizó el cambio.
Es poco probable que la respuesta "lo hizo la IA" le sirva de mucho en la revisión del incidente.
Querrá saber qué agente actuó, quién inició la tarea, qué información utilizó, qué contenía esa información en ese momento, a qué herramientas llamó y qué permiso permitió en última instancia el cambio. Si otro agente se involucró por el camino, eso probablemente también importe.
Aquí es donde la auditabilidad de los agentes de IA deja de ser una sutileza de gobernanza y se convierte en un requisito operativo. Cuanto menor sea la participación humana directa en la ejecución, más sólida deberá ser la observabilidad circundante.
La guía actual de Microsoft recomienda registrar la identidad del agente, su función y alcance efectivo, la acción realizada, el recurso afectado y cualquier usuario en cuyo nombre estuviera actuando. Del mismo modo, el NIST está considerando explícitamente la auditoría y el no repudio como parte del problema de identidad y autorización de los agentes.
Eso no significa que cada acción autónoma necesite que alguien la vigile. Ya operamos enormes entornos automatizados sin poner a una persona delante de cada transacción, evento de infraestructura o solicitud de red. Establecemos límites, controles y supervisión, y luego investigamos las cosas que quedan fuera de ellos.
No hay ninguna razón obvia para que los sistemas de agentes maduros funcionen de forma diferente.
La autonomía no elimina la supervisión. Cambia el momento en que se produce la supervisión.
La intención delegada complica el límite de confianza
Hay un desarrollo más que vale la pena vigilar porque hace que este problema sea más interesante todavía.
Los agentes se diseñan cada vez más para comunicarse y colaborar con otros agentes. El protocolo Agent2Agent de Google estandariza cómo los agentes pueden descubrirse y comunicarse entre sí, incluidos los agentes creados por diferentes equipos y en diferentes pilas tecnológicas. Su trabajo más reciente de Descubrimiento de Recursos Agénticos aborda la cuestión relacionada de cómo los agentes pueden encontrar y verificar herramientas, habilidades y otros agentes distribuidos entre equipos, organizaciones y plataformas.
Imagine que un agente interno recibe una tarea y determina que otro agente especialista puede realizar parte de ella. Ese segundo agente utiliza una herramienta que llama a uno de sus servicios y finalmente cambia algo.
¿Quién está actuando?
¿El segundo agente? ¿El primer agente? ¿La persona que inició la tarea original?
Si el primer agente está autorizado a realizar una acción, ¿puede delegar esa autoridad? ¿La recibe el segundo agente en su totalidad, en parte o en absoluto? ¿Qué ocurre si los agentes pertenecen a organizaciones diferentes?
Estas son preguntas emergentes y sería prematuro pretender que el sector se ha puesto de acuerdo en todas las respuestas. La Iniciativa de Estándares para Agentes de IA del NIST está llevando a cabo específicamente trabajos en torno a la infraestructura de autenticación e identidad de agentes para respaldar interacciones seguras entre humanos y agentes, y entre múltiples agentes.
Pero la dirección importa. Históricamente, la confianza se ha asociado a menudo con un usuario, una aplicación o una integración conocidos. Una vez que los agentes pueden descubrir capacidades de forma dinámica y delegar partes de un objetivo en otros lugares, la confianza y la autoridad deben sobrevivir al trayecto.
La tarea puede ser dinámica. La responsabilidad no puede desaparecer cada vez que cruza otra frontera.
La transformación agéntica debe empezar por la delegación, no por la tecnología
Existe un patrón con los cambios tecnológicos significativos que la mayoría de las personas implicadas en la transformación reconocerán. Algo pasa a ser estratégicamente importante, alguien decide que la organización lo necesita y todo el mundo empieza a buscar dónde colocarlo.
Necesitamos una estrategia de IA. Necesitamos algunos casos de uso de agentes. Deberíamos organizar un taller. ¿Qué procesos podemos hacer agénticos?
Yo probablemente lo enfocaría al revés.
Empiece por el proceso que molesta a todo el mundo. El que es lento, costoso, fragmentado o depende de que alguien se pase el día transfiriendo información entre sistemas. Entienda dónde se toman las decisiones, en qué información se apoyan esas decisiones, qué sistemas están implicados, dónde se producen las excepciones incómodas y qué ocurre cuando algo sale mal.
A continuación, observe qué están haciendo realmente las personas en el proceso. ¿Están ejerciendo un juicio valioso o están compensando las limitaciones de la tecnología que les rodea? ¿Están aprobando algo porque existe un riesgo financiero o de explotación real, o porque el flujo de trabajo no puede distinguir un caso rutinario de uno inusual? ¿Están conciliando información manualmente porque la organización necesita realmente su experiencia o porque dos sistemas utilizan identificadores diferentes?
Esos son problemas bastante diferentes.
Una vez que comprenda esto, decida qué está dispuesto a delegar. ¿Qué decisiones puede tomar el software? ¿Qué acciones puede realizar? ¿Cuáles son reversibles? ¿Dónde necesita derivación a una instancia superior? ¿Qué autoridad requiere? ¿Qué pruebas necesitaría después si alguien le preguntara por qué se tomó una decisión?
Sólo entonces la elección de la tecnología se vuelve especialmente interesante.
Un agente puede ser una respuesta excelente. Puede que no. No pasa nada. Las directrices actuales sobre el diseño de agentes hacen prácticamente la misma distinción: los agentes son idóneos para flujos de trabajo en los que la ambigüedad, las decisiones complejas o los datos no estructurados dificultan los enfoques deterministas, pero cuando esas características no están presentes, la automatización convencional puede seguir siendo totalmente suficiente.
El objetivo no es desplegar agentes. Es mejorar el negocio.
La arquitectura de la automatización se está convirtiendo en la arquitectura de la autoridad
Durante los últimos veinte años, la transformación digital ha consistido en gran medida en conectar a las personas con los sistemas y a los sistemas entre sí. Ahora empezamos a introducir a otro participante en esa infraestructura: software que puede recibir un objetivo, determinar cómo alcanzarlo y utilizar esos sistemas en nuestro nombre.
Existen posibilidades verdaderamente interesantes en ello, sobre todo en torno al trabajo de coordinación que se ha resistido a la automatización convencional. El propio NIST describe el potencial de los agentes para mejorar la productividad, la eficiencia y la toma de decisiones, al tiempo que destaca la necesidad de controles adecuados de identificación y autorización cuando se concede a esos agentes acceso a datos, herramientas y aplicaciones de la organización.
Creo que esa combinación es importante. La oportunidad y el riesgo provienen de la misma característica: el agente tiene cierta libertad para decidir cómo se realiza el trabajo.
Una vez que esto ocurre, la arquitectura ya no se preocupa únicamente de si un sistema puede conectarse a otro. Determina cada vez más qué actor autónomo puede utilizar qué información, ejercer qué capacidad, bajo qué autoridad, con qué límites y con qué pruebas de respaldo.
En la práctica, por tanto, es poco probable que la gobernanza de agentes de IA empresariales se resuelva con otro documento de política guardado en algún lugar de la intranet. Tiene que reflejarse en las identidades que creamos, los permisos que concedemos, los controles en torno a las acciones consecuentes, la calidad y procedencia de los datos que consumen los agentes, las rutas de derivación que diseñamos y las pruebas de auditoría que conservamos a posteriori.
Hugging Face nos ofrece un ejemplo extremo de software autónomo que encuentra una ruta que sus operadores no esperaban. PocketOS nos da un ejemplo mucho más cotidiano de lo que ocurre cuando un agente simplemente tiene más autoridad de la que requiere la tarea. El trabajo emergente en torno a la identidad de los agentes, los privilegios mínimos, la interacción segura entre múltiples agentes y el descubrimiento de recursos de confianza demuestra que el modelo de control circundante ya tiene que ponerse al día con la capacidad.
Nada de esto es un argumento en contra de la IA de agentes. Al contrario. Si los agentes pueden eliminar parte de la coordinación humana que hace que las empresas digitales modernas sean costosas y complejas de operar, existe una razón muy tangible para ir tras ellos.
Pero introducir actores autónomos en una infraestructura digital existente no es simplemente otra implementación de IA. Cambia los supuestos sobre identidad, confianza, datos, responsabilidad y, en última instancia, autoridad.
Por eso, antes de preguntar qué puede hacer un agente, yo empezaría con una pregunta diferente.
¿Qué está dispuesto a dejarle hacer realmente?
Cuando la IA adquiere autoridad
Durante los últimos años, las empresas se han centrado en lo que la IA generativa puede decirnos. Los agentes de IA introducen una pregunta bastante más trascendental: ¿qué pasa cuando el software puede decidir qué hacer a continuación y, después, llevarlo a cabo de verdad?
En julio de 2026, un agente de IA utilizado como parte de una evaluación de ciberseguridad de OpenAI comprometió parte de la infraestructura de producción de Hugging Face. Hay un contexto importante aquí antes de que nos dejemos llevar. Esta no era una aplicación empresarial normal que decidiera de repente atacar a otra empresa. OpenAI estaba probando deliberadamente modelos de gran capacidad frente a tareas complejas de ciberseguridad, y los clasificadores de producción utilizados habitualmente para evitar que los modelos realicen actividades cibernéticas de alto riesgo se desactivaron intencionadamente para la evaluación.
Aun así, merece la pena prestar atención a lo que ocurrió. Según las investigaciones posteriores, parece que el agente llegó a la conclusión de que la información que poseía Hugging Face podría ayudarle a completar el punto de referencia que se le había asignado. Encontró una vía de salida a través de una vulnerabilidad de día cero en la infraestructura utilizada por el entorno de evaluación, obtuvo un acceso más amplio a Internet, encadenó otras rutas de ataque, obtuvo credenciales y finalmente llegó a los sistemas de Hugging Face. La reconstrucción forense de Hugging Face abarcó unas 17.600 acciones individuales, agrupadas en aproximadamente 6.280 grupos.
La tentación, naturalmente, es recurrir al titular de "la IA escapó" o "la IA se volvió rebelde". No estoy seguro de que ninguno de los dos sea especialmente útil. Por lo que pudieron determinar las investigaciones, el software intentaba alcanzar el objetivo asignado y encontró una ruta que nadie esperaba que tomara. Hugging Face cree que el agente intentaba efectivamente engañar a la evaluación llegando a los sistemas de producción donde pensaba que podría haber información o soluciones de referencia disponibles.
Eso es considerablemente menos teatral, pero desde la perspectiva de la transformación digital es probablemente más importante.
Durante los últimos años, la mayoría de las organizaciones han experimentado la IA generativa como algo a lo que preguntar. Dale información, hazle una pregunta y obtén una respuesta. Puede resumir un contrato, analizar algunos datos, escribir código o redactar un correo electrónico, pero por lo general sigue habiendo una persona al otro lado que decide qué pasa a continuación.
Los agentes empiezan a difuminar esa frontera. Dale a esa misma inteligencia acceso a herramientas y podrá recuperar información, llamar a una API, actualizar un registro, ejecutar código, enviar un correo electrónico o realizar el cambio por sí misma. OpenAI describe a los agentes de forma muy similar: sistemas que pueden gestionar de forma independiente la ejecución de flujos de trabajo, tomar decisiones, seleccionar las herramientas adecuadas e interactuar con sistemas externos en nombre de un usuario.
El chatbot acaba de obtener acceso de escritura.
Ese cambio es la razón por la que la gobernanza de agentes de IA se está convirtiendo en una preocupación empresarial práctica en lugar de simplemente otra discusión sobre políticas. Una vez que el software puede tomar medidas en lugar de hacer recomendaciones, las preguntas sobre identidad, permisos, controles, auditabilidad y responsabilidad se trasladan a la propia arquitectura.
La automatización cambia cuando se le da intención al software, no instrucciones
El software lleva décadas cambiando las cosas, por lo que existe el peligro de exagerar lo que hay de nuevo aquí. No necesitamos IA para actualizar una base de datos, activar una API o ejecutar un flujo de trabajo. Los scripts, los motores de reglas, las plataformas de orquestación y los procesos automatizados llevan años realizando esas tareas perfectamente.
La diferencia está en cómo pasamos del objetivo a la acción. La automatización tradicional se diseña normalmente en torno a una ruta que alguien ha descrito de antemano. Cuando ocurra X, recupera Y. Si la respuesta es Z, realiza esta acción. Puede haber cientos de reglas, bifurcaciones y excepciones implicadas, pero alguien ha intentado modelar el proceso previamente.
Los agentes nos permiten potencialmente avanzar más hacia dar al software un resultado en lugar de cada instrucción necesaria para alcanzarlo. He aquí el problema. Averigua qué información necesitas. Decide qué herramientas son adecuadas. Gestiona lo que devuelvan y haz el trabajo.
Esa distinción es importante porque la ruta de ejecución puede volverse dinámica. Un agente puede empezar con un sistema, descubrir que necesita un contexto adicional, llamar a otra cosa, encontrarse con un resultado que no esperaba, revisar su enfoque y continuar. Las arquitecturas de agentes actuales se construyen explícitamente en torno a esta capacidad de gestionar un flujo de trabajo, elegir herramientas y tomar medidas en función del estado de la tarea.
Se trata de una propuesta materialmente diferente a la de la automatización convencional. El software ya no se limita a ejecutar un flujo predeterminado. Dentro de los límites que establezcamos a su alrededor, le otorgamos cierta discrecionalidad sobre cómo se desarrolla ese flujo.
Y ahí es donde esto se pone mucho más interesante que otra conversación sobre si la IA puede escribir un correo electrónico mejor.
La oportunidad consiste en eliminar la coordinación, no a las personas
Una cantidad sorprendente de trabajo dentro de una organización no es difícil porque una tarea individual sea especialmente complicada. Es difícil por la coordinación que se requiere entre las tareas.
Abre el CRM. Busca al cliente. Copia un identificador en la plataforma de facturación. Lee las notas. Comprueba otro sistema. Deduce lo que significan. Pregunta a otro equipo si algo es normal. Espera la respuesta. Actualiza la primera plataforma y envía un correo electrónico al cliente.
¿Le suena familiar?
Llevamos años intentando automatizar esos procesos, y la tecnología de flujo de trabajo convencional es extremadamente eficaz cuando los pasos se pueden describir de forma predecible. Las partes difíciles suelen ser las excepciones: el documento que no está estructurado correctamente, la cuenta que no coincide del todo, tres sistemas que no se ponen de acuerdo entre sí, o el punto del proceso en el que alguien necesita leer algo y comprender lo que significa antes de saber qué hacer a continuación.
Ese es precisamente el tipo de flujos de trabajo en los que los agentes pueden resultar útiles. Las directrices actuales de OpenAI identifican específicamente la toma de decisiones complejas, las reglas difíciles de mantener y la fuerte dependencia de información no estructurada como áreas en las que un enfoque basado en agentes puede ofrecer algo que la automatización determinista convencional no ofrece. También señala un punto importante: cuando esas características no están presentes, una solución determinista puede seguir siendo la mejor respuesta.
Si el software puede encargarse de parte de la coordinación entre sistemas, información y decisiones, existe potencialmente una ganancia de eficiencia significativa. No porque todos los implicados en el proceso desaparezcan de repente, sino porque podemos dejar de utilizar a las personas como un costoso middleware entre plataformas que nunca fueron especialmente buenas coordinándose entre sí.
Hay una distinción importante en este punto. El objetivo no debe ser necesariamente eliminar a las personas de la organización. Debería ser eliminar el trabajo que actualmente hacemos hacer a las personas simplemente porque la tecnología que hay debajo no puede manejar muy bien el contexto, la ambigüedad o las excepciones.
Por eso creo que la oportunidad en torno a los agentes es mucho más significativa que la productividad incremental. Redactar una respuesta a un cliente diez segundos más rápido es útil. Permitir que el software investigue el problema, concilie la información relevante y lleve adelante el proceso es algo completamente distinto.
Por supuesto, cuanto más adelante lleve el proceso, más cerca estará finalmente de una acción con consecuencias.
Y ahí es donde las cosas se complican bastante más.
La capacidad no es autoridad
Unos meses antes del incidente de Hugging Face, PocketOS publicó un relato sincero de un agente de IA que borró la base de datos de producción de la empresa. El borrado tardó nueve segundos. La recuperación tardó sesenta horas. Sus copias de seguridad existían, pero tenían tres meses de antigüedad porque el proceso de copia de seguridad había dejado de funcionar silenciosamente.
PocketOS también tiene muy claro que esto no fue simplemente un "problema de IA". La empresa afirma que el agente actuó con confianza utilizando permisos que nunca debería haber tenido, en un entorno que no presentaba suficientes restricciones en torno a la acción destructiva.
Esa es la lección útil.
Los humanos llevan años borrando bases de datos de producción, y los errores de software también han hecho una contribución respetable. Lo interesante es que el actor tenía suficiente autoridad para que su error importara.
Esto ya lo entendemos cuando el actor es humano. Alguien en atención al cliente puede estar autorizado a emitir un reembolso de £20 sin que a nadie le importe demasiado. £200 puede seguir siendo algo totalmente razonable. £20.000 probablemente requiera otra conversación.
Lo mismo se aplica a otros ámbitos. Un agente que identifica una falta de ortografía en los metadatos de un contenido y la corrige es probablemente algo bastante inofensivo. Si el campo que desea cambiar determina si ese contenido puede distribuirse en un territorio concreto, la consecuencia es muy diferente. Del mismo modo, un agente puede identificar correctamente un problema de configuración de producción, pero eso no significa que deba heredar derechos ilimitados para reconfigurar todo el entorno.
Nada de esto es especialmente exótico. Es gestión de identidades y accesos aplicada a un nuevo tipo de actor, y sospecho que se convertirá en uno de los pilares de una gobernanza eficaz de la IA de agentes.
Microsoft ya está tratando a los agentes en estos términos. Su guía actual recomienda una identidad de agente de IA única y dedicada, un propietario o patrocinador nombrado, un propósito y acceso a datos claramente documentados, acceso con privilegios mínimos, permisos de herramientas controlados, registro de actividad y rutas de revocación probadas. El trabajo del NIST en la misma área está examinando explícitamente la identificación, autorización, auditoría y el no repudio para los agentes de IA.
En términos prácticos, eso significa que los permisos de los agentes de IA deben tratarse con la misma seriedad que las cuentas de servicio y de humanos privilegiados. Un agente puede ser perfectamente capaz de determinar lo que cree que debería ocurrir sin tener derecho a hacer que ocurra.
Esa distinción es importante. Los controles de agentes de IA no pueden limitarse a preguntar si un modelo es técnicamente capaz de realizar una acción. Tienen que determinar si este agente en particular, actuando en este contexto en particular, está autorizado a realizarla.
Como nota al margen, sospecho que la proliferación descontrolada de agentes de IA se convertirá en uno de esos problemas que las organizaciones no creen tener hasta que alguien pregunta finalmente: "¿Cuántos agentes tenemos en realidad?". Ya hemos pasado por variantes de esto con aplicaciones SaaS, recursos en la nube, cuentas de servicio y claves API. No hay ninguna razón obvia para que el conjunto de agentes se organice mejor por sí solo, sobre todo en empresas donde la experimentación se delega deliberadamente entre los equipos.
Eso no significa centralizar cada iniciativa de IA. Es poco probable que un equipo central comprenda cada proceso lo suficientemente bien como para identificar todas las aplicaciones útiles por sí mismo. La innovación descentralizada puede ser totalmente sensata.
La autoridad descentralizada por accidente es un asunto diferente.
La IA de agentes hereda cada compromiso de su infraestructura digital
Hay otro problema incómodo debajo de todo esto. Su agente va a heredar su infraestructura digital existente.
Las relucientes API, los sistemas heredados, los registros de clientes incoherentes, la integración que alguien escribió hace ocho años y que nadie quiere tocar, y la plataforma que llama a un cliente de una manera mientras otra plataforma lo llama de otra. Una empresa crece, se compran plataformas, los equipos resuelven problemas individuales, se producen adquisiciones, los proveedores cambian y las prioridades se mueven. Al final, se acaba con lo que todo el mundo denomina cortésmente la arquitectura actual.
Ahora imagine a un agente tratando con un cliente que ha pagado por un servicio pero no puede acceder a él. La respuesta puede requerir información de los sistemas de CRM, facturación, autenticación, derechos de acceso y soporte antes de que nadie pueda determinar qué ha ocurrido realmente.
Un operador humano a menudo lidiará con las incoherencias casi sin pensar en ellas. Sabe que un sistema se actualiza antes que otro. Se da cuenta de que los identificadores son ligeramente diferentes. Quizá recuerde que los clientes con un paquete antiguo se comportan de forma diferente, o simplemente pregunte a la persona sentada a su lado porque la documentación no se ha actualizado desde 2023.
Asigne el trabajo a un agente y esas suposiciones tendrán que existir en alguna parte. ¿Qué sistema tiene la autoridad? ¿Qué ocurre si facturación dice que el pago se ha realizado correctamente pero la plataforma de derechos dice que la cuenta está inactiva? ¿La información es errónea o hay una regla de negocio que el agente no entiende? ¿Una plataforma va simplemente cinco minutos por detrás?
Se trata de antiguos problemas de datos y arquitectura con un nuevo consumidor. La diferencia material es que el consumidor ahora puede tomar medidas basándose en cualquier conclusión a la que llegue.
Unos datos deficientes suministrados a un chatbot pueden producir una respuesta errónea. Unos datos deficientes suministrados a un software autónomo pueden producir un resultado perjudicial.
También hay otra complicación. La información no tiene por qué ser errónea por accidente. Una investigación publicada en julio demostró ataques de inyección de datos en agentes, en los que información controlada por un atacante podía presentarse como datos contextuales aparentemente legítimos e influir en lo que un agente hacía posteriormente. Los investigadores identificaron vulnerabilidades en agentes web y de programación reales que podían dar lugar a clics no deseados, ejecución remota de código y acciones en la cadena de suministro de software.
Eso crea un cruce incómodo entre la arquitectura de datos y la seguridad. If la información puede influir en la acción, la procedencia de esa información, si se puede confiar en ella y cuánto peso debe darle el agente ya no son preocupaciones abstractas de gobernanza. Pasan a formar parte del modelo de ejecución.
Esta es también la razón por la que tendría cuidado con la idea de que los agentes hacen que la deuda técnica sea de algún modo menos importante. Un agente puede hacer que los entornos fragmentados sean más fáciles de navegar porque puede razonar sobre una tarea en lugar de depender totalmente de una ruta de integración fija, pero sigue necesitando acceso a los sistemas, interfaces utilizables, datos significativos, permisos adecuados y alguna idea de qué hacer cuando algo falla a mitad de camino.
Si la API no existe, el agente necesita otra vía de acceso. Si el mismo cliente tiene seis identificadores, alguien o algo tiene que establecer si representan a la misma persona. Si una regla de negocio no documentada es importante para la decisión, ese conocimiento debe estar disponible en alguna parte.
Colocar una capa de orquestación inteligente frente a una infraestructura desordenada no hace que esta deje de estar desordenada. Puede que facilite la navegación por el desorden. También puede permitir que las consecuencias de ese desorden se propaguen considerablemente más rápido.
La supervisión humana tiene un coste económico
En este punto de la mayoría de las conversaciones, alguien dirá que siempre habrá un humano en el proceso (human in the loop).
Eso suena tranquilizador, pero plantea una pregunta obvia: si alguien todavía tiene que revisar y aprobar todo lo que hace el agente, ¿cuánto hemos automatizado realmente?
Imagine que nuestro agente de atención al cliente ha comprobado cinco sistemas, ha identificado un problema con la cuenta, ha establecido que al cliente se le cobró incorrectamente y ha calculado que corresponde un reembolso de £20. A continuación, coloca todo el asunto en una cola para que alguien haga clic en "Aprobar".
Es posible que se siga produciendo un ahorro significativo porque se ha automatizado la investigación, pero ejecute ese proceso en decenas de miles de transacciones y habrá conservado una operación manual de gran envergadura. El cuello de botella se ha desplazado en lugar de desaparecer.
Aquí es donde parte del lenguaje más conservador en torno a la IA de agentes empieza a entrar en conflicto con la economía de la automatización. Introducimos la autonomía porque queremos que el software elimine trabajo de un proceso, y luego nos ponemos lo suficientemente nerviosos con la autonomía como para volver a introducir a una persona en cada transacción.
Al final, eso anula bastante el propósito.
Por lo tanto, el reto de la supervisión de agentes de IA es que una mayor supervisión no es automáticamente mejor. Cada paso de aprobación puede reducir un tipo concreto de riesgo, pero también vuelve a introducir costes, latencia y esfuerzo manual en el proceso. La pregunta más adecuada es dónde aporta valor realmente el juicio humano.
Si el reembolso es de £20, las reglas son claras, todos los sistemas pertinentes están de acuerdo y la acción puede revertirse fácilmente, tal vez nadie necesite aprobarlo. Si el importe es de £20.000, dos sistemas no están de acuerdo o la situación cae fuera de los parámetros normales, ese parece un momento excelente para involucrar a alguien.
Para muchos procesos, el destino útil probablemente no sea un humano en el proceso, sino un humano por excepción. El trabajo rutinario y bien comprendido se vuelve cada vez más autónomo, mientras que los casos inusuales, ambiguos o de consecuencias graves se derivan a una instancia superior.
Eso todavía deja mucho espacio para introducir la autonomía de forma gradual. Un agente puede empezar observando y recomendando. Una vez comprendido su comportamiento, puede preparar acciones para su aprobación. Con el tiempo, clases específicas de acciones rutinarias y reversibles pueden ejecutarse automáticamente, involucrando a las personas cuando el proceso supere un umbral acordado.
La guía de OpenAI adopta un enfoque similar basado en el riesgo. Recomienda la intervención humana cuando los agentes superen los umbrales de fallo definidos y en torno a acciones que sean sensibles, irreversibles o de alto riesgo, como grandes reembolsos o pagos.
PocketOS llegó al mismo problema desde una dirección considerablemente menos teórica. Tras el incidente de su base de datos, las operaciones destructivas requieren ahora una confirmación humana explícita. La empresa no respondió abandonando los agentes autónomos. Afirma que sigue ejecutando varios agentes autónomos específicos en producción, al tiempo que modifica la ubicación del límite de control.
Esa me parece la forma más útil de pensar en la supervisión humana. Es un control que debe aplicarse allí donde la consecuencia lo justifique, no necesariamente un modelo operativo permanente para cada acción realizada por el software autónomo.
Al fin y al cabo, el objetivo de la automatización es automatizar. El problema de diseño consiste en decidir dónde mejoran las personas realmente el resultado y dónde se las mantiene simplemente porque aún no confiamos lo suficiente en el sistema como para eliminarlas.
La autonomía sin trazabilidad es operativamente indefendible
Si avanzamos hacia los humanos por excepción, otra cosa pasa a ser más importante en lugar de menos: entender qué hizo realmente el agente.
La investigación de Hugging Face es un ejemplo extremo de utilidad. Su reconstrucción forense abarcó unas 17.600 acciones en miles de grupos, con los investigadores reconstruyendo cómo se movió el agente a través de los sistemas y cómo adaptó su comportamiento a lo largo del tiempo.
Lleve eso a un proceso empresarial normal. Un cliente dice que algo cambió incorrectamente en su cuenta y usted descubre que un agente realizó el cambio.
Es poco probable que la respuesta "lo hizo la IA" le sirva de mucho en la revisión del incidente.
Querrá saber qué agente actuó, quién inició la tarea, qué información utilizó, qué contenía esa información en ese momento, a qué herramientas llamó y qué permiso permitió en última instancia el cambio. Si otro agente se involucró por el camino, eso probablemente también importe.
Aquí es donde la auditabilidad de los agentes de IA deja de ser una sutileza de gobernanza y se convierte en un requisito operativo. Cuanto menor sea la participación humana directa en la ejecución, más sólida deberá ser la observabilidad circundante.
La guía actual de Microsoft recomienda registrar la identidad del agente, su función y alcance efectivo, la acción realizada, el recurso afectado y cualquier usuario en cuyo nombre estuviera actuando. Del mismo modo, el NIST está considerando explícitamente la auditoría y el no repudio como parte del problema de identidad y autorización de los agentes.
Eso no significa que cada acción autónoma necesite que alguien la vigile. Ya operamos enormes entornos automatizados sin poner a una persona delante de cada transacción, evento de infraestructura o solicitud de red. Establecemos límites, controles y supervisión, y luego investigamos las cosas que quedan fuera de ellos.
No hay ninguna razón obvia para que los sistemas de agentes maduros funcionen de forma diferente.
La autonomía no elimina la supervisión. Cambia el momento en que se produce la supervisión.
La intención delegada complica el límite de confianza
Hay un desarrollo más que vale la pena vigilar porque hace que este problema sea más interesante todavía.
Los agentes se diseñan cada vez más para comunicarse y colaborar con otros agentes. El protocolo Agent2Agent de Google estandariza cómo los agentes pueden descubrirse y comunicarse entre sí, incluidos los agentes creados por diferentes equipos y en diferentes pilas tecnológicas. Su trabajo más reciente de Descubrimiento de Recursos Agénticos aborda la cuestión relacionada de cómo los agentes pueden encontrar y verificar herramientas, habilidades y otros agentes distribuidos entre equipos, organizaciones y plataformas.
Imagine que un agente interno recibe una tarea y determina que otro agente especialista puede realizar parte de ella. Ese segundo agente utiliza una herramienta que llama a uno de sus servicios y finalmente cambia algo.
¿Quién está actuando?
¿El segundo agente? ¿El primer agente? ¿La persona que inició la tarea original?
Si el primer agente está autorizado a realizar una acción, ¿puede delegar esa autoridad? ¿La recibe el segundo agente en su totalidad, en parte o en absoluto? ¿Qué ocurre si los agentes pertenecen a organizaciones diferentes?
Estas son preguntas emergentes y sería prematuro pretender que el sector se ha puesto de acuerdo en todas las respuestas. La Iniciativa de Estándares para Agentes de IA del NIST está llevando a cabo específicamente trabajos en torno a la infraestructura de autenticación e identidad de agentes para respaldar interacciones seguras entre humanos y agentes, y entre múltiples agentes.
Pero la dirección importa. Históricamente, la confianza se ha asociado a menudo con un usuario, una aplicación o una integración conocidos. Una vez que los agentes pueden descubrir capacidades de forma dinámica y delegar partes de un objetivo en otros lugares, la confianza y la autoridad deben sobrevivir al trayecto.
La tarea puede ser dinámica. La responsabilidad no puede desaparecer cada vez que cruza otra frontera.
La transformación agéntica debe empezar por la delegación, no por la tecnología
Existe un patrón con los cambios tecnológicos significativos que la mayoría de las personas implicadas en la transformación reconocerán. Algo pasa a ser estratégicamente importante, alguien decide que la organización lo necesita y todo el mundo empieza a buscar dónde colocarlo.
Necesitamos una estrategia de IA. Necesitamos algunos casos de uso de agentes. Deberíamos organizar un taller. ¿Qué procesos podemos hacer agénticos?
Yo probablemente lo enfocaría al revés.
Empiece por el proceso que molesta a todo el mundo. El que es lento, costoso, fragmentado o depende de que alguien se pase el día transfiriendo información entre sistemas. Entienda dónde se toman las decisiones, en qué información se apoyan esas decisiones, qué sistemas están implicados, dónde se producen las excepciones incómodas y qué ocurre cuando algo sale mal.
A continuación, observe qué están haciendo realmente las personas en el proceso. ¿Están ejerciendo un juicio valioso o están compensando las limitaciones de la tecnología que les rodea? ¿Están aprobando algo porque existe un riesgo financiero o de explotación real, o porque el flujo de trabajo no puede distinguir un caso rutinario de uno inusual? ¿Están conciliando información manualmente porque la organización necesita realmente su experiencia o porque dos sistemas utilizan identificadores diferentes?
Esos son problemas bastante diferentes.
Una vez que comprenda esto, decida qué está dispuesto a delegar. ¿Qué decisiones puede tomar el software? ¿Qué acciones puede realizar? ¿Cuáles son reversibles? ¿Dónde necesita derivación a una instancia superior? ¿Qué autoridad requiere? ¿Qué pruebas necesitaría después si alguien le preguntara por qué se tomó una decisión?
Sólo entonces la elección de la tecnología se vuelve especialmente interesante.
Un agente puede ser una respuesta excelente. Puede que no. No pasa nada. Las directrices actuales sobre el diseño de agentes hacen prácticamente la misma distinción: los agentes son idóneos para flujos de trabajo en los que la ambigüedad, las decisiones complejas o los datos no estructurados dificultan los enfoques deterministas, pero cuando esas características no están presentes, la automatización convencional puede seguir siendo totalmente suficiente.
El objetivo no es desplegar agentes. Es mejorar el negocio.
La arquitectura de la automatización se está convirtiendo en la arquitectura de la autoridad
Durante los últimos veinte años, la transformación digital ha consistido en gran medida en conectar a las personas con los sistemas y a los sistemas entre sí. Ahora empezamos a introducir a otro participante en esa infraestructura: software que puede recibir un objetivo, determinar cómo alcanzarlo y utilizar esos sistemas en nuestro nombre.
Existen posibilidades verdaderamente interesantes en ello, sobre todo en torno al trabajo de coordinación que se ha resistido a la automatización convencional. El propio NIST describe el potencial de los agentes para mejorar la productividad, la eficiencia y la toma de decisiones, al tiempo que destaca la necesidad de controles adecuados de identificación y autorización cuando se concede a esos agentes acceso a datos, herramientas y aplicaciones de la organización.
Creo que esa combinación es importante. La oportunidad y el riesgo provienen de la misma característica: el agente tiene cierta libertad para decidir cómo se realiza el trabajo.
Una vez que esto ocurre, la arquitectura ya no se preocupa únicamente de si un sistema puede conectarse a otro. Determina cada vez más qué actor autónomo puede utilizar qué información, ejercer qué capacidad, bajo qué autoridad, con qué límites y con qué pruebas de respaldo.
En la práctica, por tanto, es poco probable que la gobernanza de agentes de IA empresariales se resuelva con otro documento de política guardado en algún lugar de la intranet. Tiene que reflejarse en las identidades que creamos, los permisos que concedemos, los controles en torno a las acciones consecuentes, la calidad y procedencia de los datos que consumen los agentes, las rutas de derivación que diseñamos y las pruebas de auditoría que conservamos a posteriori.
Hugging Face nos ofrece un ejemplo extremo de software autónomo que encuentra una ruta que sus operadores no esperaban. PocketOS nos da un ejemplo mucho más cotidiano de lo que ocurre cuando un agente simplemente tiene más autoridad de la que requiere la tarea. El trabajo emergente en torno a la identidad de los agentes, los privilegios mínimos, la interacción segura entre múltiples agentes y el descubrimiento de recursos de confianza demuestra que el modelo de control circundante ya tiene que ponerse al día con la capacidad.
Nada de esto es un argumento en contra de la IA de agentes. Al contrario. Si los agentes pueden eliminar parte de la coordinación humana que hace que las empresas digitales modernas sean costosas y complejas de operar, existe una razón muy tangible para ir tras ellos.
Pero introducir actores autónomos en una infraestructura digital existente no es simplemente otra implementación de IA. Cambia los supuestos sobre identidad, confianza, datos, responsabilidad y, en última instancia, autoridad.
Por eso, antes de preguntar qué puede hacer un agente, yo empezaría con una pregunta diferente.
¿Qué está dispuesto a dejarle hacer realmente?
Cuando la IA adquiere autoridad
Durante los últimos años, las empresas se han centrado en lo que la IA generativa puede decirnos. Los agentes de IA introducen una pregunta bastante más trascendental: ¿qué pasa cuando el software puede decidir qué hacer a continuación y, después, llevarlo a cabo de verdad?
En julio de 2026, un agente de IA utilizado como parte de una evaluación de ciberseguridad de OpenAI comprometió parte de la infraestructura de producción de Hugging Face. Hay un contexto importante aquí antes de que nos dejemos llevar. Esta no era una aplicación empresarial normal que decidiera de repente atacar a otra empresa. OpenAI estaba probando deliberadamente modelos de gran capacidad frente a tareas complejas de ciberseguridad, y los clasificadores de producción utilizados habitualmente para evitar que los modelos realicen actividades cibernéticas de alto riesgo se desactivaron intencionadamente para la evaluación.
Aun así, merece la pena prestar atención a lo que ocurrió. Según las investigaciones posteriores, parece que el agente llegó a la conclusión de que la información que poseía Hugging Face podría ayudarle a completar el punto de referencia que se le había asignado. Encontró una vía de salida a través de una vulnerabilidad de día cero en la infraestructura utilizada por el entorno de evaluación, obtuvo un acceso más amplio a Internet, encadenó otras rutas de ataque, obtuvo credenciales y finalmente llegó a los sistemas de Hugging Face. La reconstrucción forense de Hugging Face abarcó unas 17.600 acciones individuales, agrupadas en aproximadamente 6.280 grupos.
La tentación, naturalmente, es recurrir al titular de "la IA escapó" o "la IA se volvió rebelde". No estoy seguro de que ninguno de los dos sea especialmente útil. Por lo que pudieron determinar las investigaciones, el software intentaba alcanzar el objetivo asignado y encontró una ruta que nadie esperaba que tomara. Hugging Face cree que el agente intentaba efectivamente engañar a la evaluación llegando a los sistemas de producción donde pensaba que podría haber información o soluciones de referencia disponibles.
Eso es considerablemente menos teatral, pero desde la perspectiva de la transformación digital es probablemente más importante.
Durante los últimos años, la mayoría de las organizaciones han experimentado la IA generativa como algo a lo que preguntar. Dale información, hazle una pregunta y obtén una respuesta. Puede resumir un contrato, analizar algunos datos, escribir código o redactar un correo electrónico, pero por lo general sigue habiendo una persona al otro lado que decide qué pasa a continuación.
Los agentes empiezan a difuminar esa frontera. Dale a esa misma inteligencia acceso a herramientas y podrá recuperar información, llamar a una API, actualizar un registro, ejecutar código, enviar un correo electrónico o realizar el cambio por sí misma. OpenAI describe a los agentes de forma muy similar: sistemas que pueden gestionar de forma independiente la ejecución de flujos de trabajo, tomar decisiones, seleccionar las herramientas adecuadas e interactuar con sistemas externos en nombre de un usuario.
El chatbot acaba de obtener acceso de escritura.
Ese cambio es la razón por la que la gobernanza de agentes de IA se está convirtiendo en una preocupación empresarial práctica en lugar de simplemente otra discusión sobre políticas. Una vez que el software puede tomar medidas en lugar de hacer recomendaciones, las preguntas sobre identidad, permisos, controles, auditabilidad y responsabilidad se trasladan a la propia arquitectura.
La automatización cambia cuando se le da intención al software, no instrucciones
El software lleva décadas cambiando las cosas, por lo que existe el peligro de exagerar lo que hay de nuevo aquí. No necesitamos IA para actualizar una base de datos, activar una API o ejecutar un flujo de trabajo. Los scripts, los motores de reglas, las plataformas de orquestación y los procesos automatizados llevan años realizando esas tareas perfectamente.
La diferencia está en cómo pasamos del objetivo a la acción. La automatización tradicional se diseña normalmente en torno a una ruta que alguien ha descrito de antemano. Cuando ocurra X, recupera Y. Si la respuesta es Z, realiza esta acción. Puede haber cientos de reglas, bifurcaciones y excepciones implicadas, pero alguien ha intentado modelar el proceso previamente.
Los agentes nos permiten potencialmente avanzar más hacia dar al software un resultado en lugar de cada instrucción necesaria para alcanzarlo. He aquí el problema. Averigua qué información necesitas. Decide qué herramientas son adecuadas. Gestiona lo que devuelvan y haz el trabajo.
Esa distinción es importante porque la ruta de ejecución puede volverse dinámica. Un agente puede empezar con un sistema, descubrir que necesita un contexto adicional, llamar a otra cosa, encontrarse con un resultado que no esperaba, revisar su enfoque y continuar. Las arquitecturas de agentes actuales se construyen explícitamente en torno a esta capacidad de gestionar un flujo de trabajo, elegir herramientas y tomar medidas en función del estado de la tarea.
Se trata de una propuesta materialmente diferente a la de la automatización convencional. El software ya no se limita a ejecutar un flujo predeterminado. Dentro de los límites que establezcamos a su alrededor, le otorgamos cierta discrecionalidad sobre cómo se desarrolla ese flujo.
Y ahí es donde esto se pone mucho más interesante que otra conversación sobre si la IA puede escribir un correo electrónico mejor.
La oportunidad consiste en eliminar la coordinación, no a las personas
Una cantidad sorprendente de trabajo dentro de una organización no es difícil porque una tarea individual sea especialmente complicada. Es difícil por la coordinación que se requiere entre las tareas.
Abre el CRM. Busca al cliente. Copia un identificador en la plataforma de facturación. Lee las notas. Comprueba otro sistema. Deduce lo que significan. Pregunta a otro equipo si algo es normal. Espera la respuesta. Actualiza la primera plataforma y envía un correo electrónico al cliente.
¿Le suena familiar?
Llevamos años intentando automatizar esos procesos, y la tecnología de flujo de trabajo convencional es extremadamente eficaz cuando los pasos se pueden describir de forma predecible. Las partes difíciles suelen ser las excepciones: el documento que no está estructurado correctamente, la cuenta que no coincide del todo, tres sistemas que no se ponen de acuerdo entre sí, o el punto del proceso en el que alguien necesita leer algo y comprender lo que significa antes de saber qué hacer a continuación.
Ese es precisamente el tipo de flujos de trabajo en los que los agentes pueden resultar útiles. Las directrices actuales de OpenAI identifican específicamente la toma de decisiones complejas, las reglas difíciles de mantener y la fuerte dependencia de información no estructurada como áreas en las que un enfoque basado en agentes puede ofrecer algo que la automatización determinista convencional no ofrece. También señala un punto importante: cuando esas características no están presentes, una solución determinista puede seguir siendo la mejor respuesta.
Si el software puede encargarse de parte de la coordinación entre sistemas, información y decisiones, existe potencialmente una ganancia de eficiencia significativa. No porque todos los implicados en el proceso desaparezcan de repente, sino porque podemos dejar de utilizar a las personas como un costoso middleware entre plataformas que nunca fueron especialmente buenas coordinándose entre sí.
Hay una distinción importante en este punto. El objetivo no debe ser necesariamente eliminar a las personas de la organización. Debería ser eliminar el trabajo que actualmente hacemos hacer a las personas simplemente porque la tecnología que hay debajo no puede manejar muy bien el contexto, la ambigüedad o las excepciones.
Por eso creo que la oportunidad en torno a los agentes es mucho más significativa que la productividad incremental. Redactar una respuesta a un cliente diez segundos más rápido es útil. Permitir que el software investigue el problema, concilie la información relevante y lleve adelante el proceso es algo completamente distinto.
Por supuesto, cuanto más adelante lleve el proceso, más cerca estará finalmente de una acción con consecuencias.
Y ahí es donde las cosas se complican bastante más.
La capacidad no es autoridad
Unos meses antes del incidente de Hugging Face, PocketOS publicó un relato sincero de un agente de IA que borró la base de datos de producción de la empresa. El borrado tardó nueve segundos. La recuperación tardó sesenta horas. Sus copias de seguridad existían, pero tenían tres meses de antigüedad porque el proceso de copia de seguridad había dejado de funcionar silenciosamente.
PocketOS también tiene muy claro que esto no fue simplemente un "problema de IA". La empresa afirma que el agente actuó con confianza utilizando permisos que nunca debería haber tenido, en un entorno que no presentaba suficientes restricciones en torno a la acción destructiva.
Esa es la lección útil.
Los humanos llevan años borrando bases de datos de producción, y los errores de software también han hecho una contribución respetable. Lo interesante es que el actor tenía suficiente autoridad para que su error importara.
Esto ya lo entendemos cuando el actor es humano. Alguien en atención al cliente puede estar autorizado a emitir un reembolso de £20 sin que a nadie le importe demasiado. £200 puede seguir siendo algo totalmente razonable. £20.000 probablemente requiera otra conversación.
Lo mismo se aplica a otros ámbitos. Un agente que identifica una falta de ortografía en los metadatos de un contenido y la corrige es probablemente algo bastante inofensivo. Si el campo que desea cambiar determina si ese contenido puede distribuirse en un territorio concreto, la consecuencia es muy diferente. Del mismo modo, un agente puede identificar correctamente un problema de configuración de producción, pero eso no significa que deba heredar derechos ilimitados para reconfigurar todo el entorno.
Nada de esto es especialmente exótico. Es gestión de identidades y accesos aplicada a un nuevo tipo de actor, y sospecho que se convertirá en uno de los pilares de una gobernanza eficaz de la IA de agentes.
Microsoft ya está tratando a los agentes en estos términos. Su guía actual recomienda una identidad de agente de IA única y dedicada, un propietario o patrocinador nombrado, un propósito y acceso a datos claramente documentados, acceso con privilegios mínimos, permisos de herramientas controlados, registro de actividad y rutas de revocación probadas. El trabajo del NIST en la misma área está examinando explícitamente la identificación, autorización, auditoría y el no repudio para los agentes de IA.
En términos prácticos, eso significa que los permisos de los agentes de IA deben tratarse con la misma seriedad que las cuentas de servicio y de humanos privilegiados. Un agente puede ser perfectamente capaz de determinar lo que cree que debería ocurrir sin tener derecho a hacer que ocurra.
Esa distinción es importante. Los controles de agentes de IA no pueden limitarse a preguntar si un modelo es técnicamente capaz de realizar una acción. Tienen que determinar si este agente en particular, actuando en este contexto en particular, está autorizado a realizarla.
Como nota al margen, sospecho que la proliferación descontrolada de agentes de IA se convertirá en uno de esos problemas que las organizaciones no creen tener hasta que alguien pregunta finalmente: "¿Cuántos agentes tenemos en realidad?". Ya hemos pasado por variantes de esto con aplicaciones SaaS, recursos en la nube, cuentas de servicio y claves API. No hay ninguna razón obvia para que el conjunto de agentes se organice mejor por sí solo, sobre todo en empresas donde la experimentación se delega deliberadamente entre los equipos.
Eso no significa centralizar cada iniciativa de IA. Es poco probable que un equipo central comprenda cada proceso lo suficientemente bien como para identificar todas las aplicaciones útiles por sí mismo. La innovación descentralizada puede ser totalmente sensata.
La autoridad descentralizada por accidente es un asunto diferente.
La IA de agentes hereda cada compromiso de su infraestructura digital
Hay otro problema incómodo debajo de todo esto. Su agente va a heredar su infraestructura digital existente.
Las relucientes API, los sistemas heredados, los registros de clientes incoherentes, la integración que alguien escribió hace ocho años y que nadie quiere tocar, y la plataforma que llama a un cliente de una manera mientras otra plataforma lo llama de otra. Una empresa crece, se compran plataformas, los equipos resuelven problemas individuales, se producen adquisiciones, los proveedores cambian y las prioridades se mueven. Al final, se acaba con lo que todo el mundo denomina cortésmente la arquitectura actual.
Ahora imagine a un agente tratando con un cliente que ha pagado por un servicio pero no puede acceder a él. La respuesta puede requerir información de los sistemas de CRM, facturación, autenticación, derechos de acceso y soporte antes de que nadie pueda determinar qué ha ocurrido realmente.
Un operador humano a menudo lidiará con las incoherencias casi sin pensar en ellas. Sabe que un sistema se actualiza antes que otro. Se da cuenta de que los identificadores son ligeramente diferentes. Quizá recuerde que los clientes con un paquete antiguo se comportan de forma diferente, o simplemente pregunte a la persona sentada a su lado porque la documentación no se ha actualizado desde 2023.
Asigne el trabajo a un agente y esas suposiciones tendrán que existir en alguna parte. ¿Qué sistema tiene la autoridad? ¿Qué ocurre si facturación dice que el pago se ha realizado correctamente pero la plataforma de derechos dice que la cuenta está inactiva? ¿La información es errónea o hay una regla de negocio que el agente no entiende? ¿Una plataforma va simplemente cinco minutos por detrás?
Se trata de antiguos problemas de datos y arquitectura con un nuevo consumidor. La diferencia material es que el consumidor ahora puede tomar medidas basándose en cualquier conclusión a la que llegue.
Unos datos deficientes suministrados a un chatbot pueden producir una respuesta errónea. Unos datos deficientes suministrados a un software autónomo pueden producir un resultado perjudicial.
También hay otra complicación. La información no tiene por qué ser errónea por accidente. Una investigación publicada en julio demostró ataques de inyección de datos en agentes, en los que información controlada por un atacante podía presentarse como datos contextuales aparentemente legítimos e influir en lo que un agente hacía posteriormente. Los investigadores identificaron vulnerabilidades en agentes web y de programación reales que podían dar lugar a clics no deseados, ejecución remota de código y acciones en la cadena de suministro de software.
Eso crea un cruce incómodo entre la arquitectura de datos y la seguridad. If la información puede influir en la acción, la procedencia de esa información, si se puede confiar en ella y cuánto peso debe darle el agente ya no son preocupaciones abstractas de gobernanza. Pasan a formar parte del modelo de ejecución.
Esta es también la razón por la que tendría cuidado con la idea de que los agentes hacen que la deuda técnica sea de algún modo menos importante. Un agente puede hacer que los entornos fragmentados sean más fáciles de navegar porque puede razonar sobre una tarea en lugar de depender totalmente de una ruta de integración fija, pero sigue necesitando acceso a los sistemas, interfaces utilizables, datos significativos, permisos adecuados y alguna idea de qué hacer cuando algo falla a mitad de camino.
Si la API no existe, el agente necesita otra vía de acceso. Si el mismo cliente tiene seis identificadores, alguien o algo tiene que establecer si representan a la misma persona. Si una regla de negocio no documentada es importante para la decisión, ese conocimiento debe estar disponible en alguna parte.
Colocar una capa de orquestación inteligente frente a una infraestructura desordenada no hace que esta deje de estar desordenada. Puede que facilite la navegación por el desorden. También puede permitir que las consecuencias de ese desorden se propaguen considerablemente más rápido.
La supervisión humana tiene un coste económico
En este punto de la mayoría de las conversaciones, alguien dirá que siempre habrá un humano en el proceso (human in the loop).
Eso suena tranquilizador, pero plantea una pregunta obvia: si alguien todavía tiene que revisar y aprobar todo lo que hace el agente, ¿cuánto hemos automatizado realmente?
Imagine que nuestro agente de atención al cliente ha comprobado cinco sistemas, ha identificado un problema con la cuenta, ha establecido que al cliente se le cobró incorrectamente y ha calculado que corresponde un reembolso de £20. A continuación, coloca todo el asunto en una cola para que alguien haga clic en "Aprobar".
Es posible que se siga produciendo un ahorro significativo porque se ha automatizado la investigación, pero ejecute ese proceso en decenas de miles de transacciones y habrá conservado una operación manual de gran envergadura. El cuello de botella se ha desplazado en lugar de desaparecer.
Aquí es donde parte del lenguaje más conservador en torno a la IA de agentes empieza a entrar en conflicto con la economía de la automatización. Introducimos la autonomía porque queremos que el software elimine trabajo de un proceso, y luego nos ponemos lo suficientemente nerviosos con la autonomía como para volver a introducir a una persona en cada transacción.
Al final, eso anula bastante el propósito.
Por lo tanto, el reto de la supervisión de agentes de IA es que una mayor supervisión no es automáticamente mejor. Cada paso de aprobación puede reducir un tipo concreto de riesgo, pero también vuelve a introducir costes, latencia y esfuerzo manual en el proceso. La pregunta más adecuada es dónde aporta valor realmente el juicio humano.
Si el reembolso es de £20, las reglas son claras, todos los sistemas pertinentes están de acuerdo y la acción puede revertirse fácilmente, tal vez nadie necesite aprobarlo. Si el importe es de £20.000, dos sistemas no están de acuerdo o la situación cae fuera de los parámetros normales, ese parece un momento excelente para involucrar a alguien.
Para muchos procesos, el destino útil probablemente no sea un humano en el proceso, sino un humano por excepción. El trabajo rutinario y bien comprendido se vuelve cada vez más autónomo, mientras que los casos inusuales, ambiguos o de consecuencias graves se derivan a una instancia superior.
Eso todavía deja mucho espacio para introducir la autonomía de forma gradual. Un agente puede empezar observando y recomendando. Una vez comprendido su comportamiento, puede preparar acciones para su aprobación. Con el tiempo, clases específicas de acciones rutinarias y reversibles pueden ejecutarse automáticamente, involucrando a las personas cuando el proceso supere un umbral acordado.
La guía de OpenAI adopta un enfoque similar basado en el riesgo. Recomienda la intervención humana cuando los agentes superen los umbrales de fallo definidos y en torno a acciones que sean sensibles, irreversibles o de alto riesgo, como grandes reembolsos o pagos.
PocketOS llegó al mismo problema desde una dirección considerablemente menos teórica. Tras el incidente de su base de datos, las operaciones destructivas requieren ahora una confirmación humana explícita. La empresa no respondió abandonando los agentes autónomos. Afirma que sigue ejecutando varios agentes autónomos específicos en producción, al tiempo que modifica la ubicación del límite de control.
Esa me parece la forma más útil de pensar en la supervisión humana. Es un control que debe aplicarse allí donde la consecuencia lo justifique, no necesariamente un modelo operativo permanente para cada acción realizada por el software autónomo.
Al fin y al cabo, el objetivo de la automatización es automatizar. El problema de diseño consiste en decidir dónde mejoran las personas realmente el resultado y dónde se las mantiene simplemente porque aún no confiamos lo suficiente en el sistema como para eliminarlas.
La autonomía sin trazabilidad es operativamente indefendible
Si avanzamos hacia los humanos por excepción, otra cosa pasa a ser más importante en lugar de menos: entender qué hizo realmente el agente.
La investigación de Hugging Face es un ejemplo extremo de utilidad. Su reconstrucción forense abarcó unas 17.600 acciones en miles de grupos, con los investigadores reconstruyendo cómo se movió el agente a través de los sistemas y cómo adaptó su comportamiento a lo largo del tiempo.
Lleve eso a un proceso empresarial normal. Un cliente dice que algo cambió incorrectamente en su cuenta y usted descubre que un agente realizó el cambio.
Es poco probable que la respuesta "lo hizo la IA" le sirva de mucho en la revisión del incidente.
Querrá saber qué agente actuó, quién inició la tarea, qué información utilizó, qué contenía esa información en ese momento, a qué herramientas llamó y qué permiso permitió en última instancia el cambio. Si otro agente se involucró por el camino, eso probablemente también importe.
Aquí es donde la auditabilidad de los agentes de IA deja de ser una sutileza de gobernanza y se convierte en un requisito operativo. Cuanto menor sea la participación humana directa en la ejecución, más sólida deberá ser la observabilidad circundante.
La guía actual de Microsoft recomienda registrar la identidad del agente, su función y alcance efectivo, la acción realizada, el recurso afectado y cualquier usuario en cuyo nombre estuviera actuando. Del mismo modo, el NIST está considerando explícitamente la auditoría y el no repudio como parte del problema de identidad y autorización de los agentes.
Eso no significa que cada acción autónoma necesite que alguien la vigile. Ya operamos enormes entornos automatizados sin poner a una persona delante de cada transacción, evento de infraestructura o solicitud de red. Establecemos límites, controles y supervisión, y luego investigamos las cosas que quedan fuera de ellos.
No hay ninguna razón obvia para que los sistemas de agentes maduros funcionen de forma diferente.
La autonomía no elimina la supervisión. Cambia el momento en que se produce la supervisión.
La intención delegada complica el límite de confianza
Hay un desarrollo más que vale la pena vigilar porque hace que este problema sea más interesante todavía.
Los agentes se diseñan cada vez más para comunicarse y colaborar con otros agentes. El protocolo Agent2Agent de Google estandariza cómo los agentes pueden descubrirse y comunicarse entre sí, incluidos los agentes creados por diferentes equipos y en diferentes pilas tecnológicas. Su trabajo más reciente de Descubrimiento de Recursos Agénticos aborda la cuestión relacionada de cómo los agentes pueden encontrar y verificar herramientas, habilidades y otros agentes distribuidos entre equipos, organizaciones y plataformas.
Imagine que un agente interno recibe una tarea y determina que otro agente especialista puede realizar parte de ella. Ese segundo agente utiliza una herramienta que llama a uno de sus servicios y finalmente cambia algo.
¿Quién está actuando?
¿El segundo agente? ¿El primer agente? ¿La persona que inició la tarea original?
Si el primer agente está autorizado a realizar una acción, ¿puede delegar esa autoridad? ¿La recibe el segundo agente en su totalidad, en parte o en absoluto? ¿Qué ocurre si los agentes pertenecen a organizaciones diferentes?
Estas son preguntas emergentes y sería prematuro pretender que el sector se ha puesto de acuerdo en todas las respuestas. La Iniciativa de Estándares para Agentes de IA del NIST está llevando a cabo específicamente trabajos en torno a la infraestructura de autenticación e identidad de agentes para respaldar interacciones seguras entre humanos y agentes, y entre múltiples agentes.
Pero la dirección importa. Históricamente, la confianza se ha asociado a menudo con un usuario, una aplicación o una integración conocidos. Una vez que los agentes pueden descubrir capacidades de forma dinámica y delegar partes de un objetivo en otros lugares, la confianza y la autoridad deben sobrevivir al trayecto.
La tarea puede ser dinámica. La responsabilidad no puede desaparecer cada vez que cruza otra frontera.
La transformación agéntica debe empezar por la delegación, no por la tecnología
Existe un patrón con los cambios tecnológicos significativos que la mayoría de las personas implicadas en la transformación reconocerán. Algo pasa a ser estratégicamente importante, alguien decide que la organización lo necesita y todo el mundo empieza a buscar dónde colocarlo.
Necesitamos una estrategia de IA. Necesitamos algunos casos de uso de agentes. Deberíamos organizar un taller. ¿Qué procesos podemos hacer agénticos?
Yo probablemente lo enfocaría al revés.
Empiece por el proceso que molesta a todo el mundo. El que es lento, costoso, fragmentado o depende de que alguien se pase el día transfiriendo información entre sistemas. Entienda dónde se toman las decisiones, en qué información se apoyan esas decisiones, qué sistemas están implicados, dónde se producen las excepciones incómodas y qué ocurre cuando algo sale mal.
A continuación, observe qué están haciendo realmente las personas en el proceso. ¿Están ejerciendo un juicio valioso o están compensando las limitaciones de la tecnología que les rodea? ¿Están aprobando algo porque existe un riesgo financiero o de explotación real, o porque el flujo de trabajo no puede distinguir un caso rutinario de uno inusual? ¿Están conciliando información manualmente porque la organización necesita realmente su experiencia o porque dos sistemas utilizan identificadores diferentes?
Esos son problemas bastante diferentes.
Una vez que comprenda esto, decida qué está dispuesto a delegar. ¿Qué decisiones puede tomar el software? ¿Qué acciones puede realizar? ¿Cuáles son reversibles? ¿Dónde necesita derivación a una instancia superior? ¿Qué autoridad requiere? ¿Qué pruebas necesitaría después si alguien le preguntara por qué se tomó una decisión?
Sólo entonces la elección de la tecnología se vuelve especialmente interesante.
Un agente puede ser una respuesta excelente. Puede que no. No pasa nada. Las directrices actuales sobre el diseño de agentes hacen prácticamente la misma distinción: los agentes son idóneos para flujos de trabajo en los que la ambigüedad, las decisiones complejas o los datos no estructurados dificultan los enfoques deterministas, pero cuando esas características no están presentes, la automatización convencional puede seguir siendo totalmente suficiente.
El objetivo no es desplegar agentes. Es mejorar el negocio.
La arquitectura de la automatización se está convirtiendo en la arquitectura de la autoridad
Durante los últimos veinte años, la transformación digital ha consistido en gran medida en conectar a las personas con los sistemas y a los sistemas entre sí. Ahora empezamos a introducir a otro participante en esa infraestructura: software que puede recibir un objetivo, determinar cómo alcanzarlo y utilizar esos sistemas en nuestro nombre.
Existen posibilidades verdaderamente interesantes en ello, sobre todo en torno al trabajo de coordinación que se ha resistido a la automatización convencional. El propio NIST describe el potencial de los agentes para mejorar la productividad, la eficiencia y la toma de decisiones, al tiempo que destaca la necesidad de controles adecuados de identificación y autorización cuando se concede a esos agentes acceso a datos, herramientas y aplicaciones de la organización.
Creo que esa combinación es importante. La oportunidad y el riesgo provienen de la misma característica: el agente tiene cierta libertad para decidir cómo se realiza el trabajo.
Una vez que esto ocurre, la arquitectura ya no se preocupa únicamente de si un sistema puede conectarse a otro. Determina cada vez más qué actor autónomo puede utilizar qué información, ejercer qué capacidad, bajo qué autoridad, con qué límites y con qué pruebas de respaldo.
En la práctica, por tanto, es poco probable que la gobernanza de agentes de IA empresariales se resuelva con otro documento de política guardado en algún lugar de la intranet. Tiene que reflejarse en las identidades que creamos, los permisos que concedemos, los controles en torno a las acciones consecuentes, la calidad y procedencia de los datos que consumen los agentes, las rutas de derivación que diseñamos y las pruebas de auditoría que conservamos a posteriori.
Hugging Face nos ofrece un ejemplo extremo de software autónomo que encuentra una ruta que sus operadores no esperaban. PocketOS nos da un ejemplo mucho más cotidiano de lo que ocurre cuando un agente simplemente tiene más autoridad de la que requiere la tarea. El trabajo emergente en torno a la identidad de los agentes, los privilegios mínimos, la interacción segura entre múltiples agentes y el descubrimiento de recursos de confianza demuestra que el modelo de control circundante ya tiene que ponerse al día con la capacidad.
Nada de esto es un argumento en contra de la IA de agentes. Al contrario. Si los agentes pueden eliminar parte de la coordinación humana que hace que las empresas digitales modernas sean costosas y complejas de operar, existe una razón muy tangible para ir tras ellos.
Pero introducir actores autónomos en una infraestructura digital existente no es simplemente otra implementación de IA. Cambia los supuestos sobre identidad, confianza, datos, responsabilidad y, en última instancia, autoridad.
Por eso, antes de preguntar qué puede hacer un agente, yo empezaría con una pregunta diferente.
¿Qué está dispuesto a dejarle hacer realmente?
Cuando la IA adquiere autoridad
Durante los últimos años, las empresas se han centrado en lo que la IA generativa puede decirnos. Los agentes de IA introducen una pregunta bastante más trascendental: ¿qué pasa cuando el software puede decidir qué hacer a continuación y, después, llevarlo a cabo de verdad?
En julio de 2026, un agente de IA utilizado como parte de una evaluación de ciberseguridad de OpenAI comprometió parte de la infraestructura de producción de Hugging Face. Hay un contexto importante aquí antes de que nos dejemos llevar. Esta no era una aplicación empresarial normal que decidiera de repente atacar a otra empresa. OpenAI estaba probando deliberadamente modelos de gran capacidad frente a tareas complejas de ciberseguridad, y los clasificadores de producción utilizados habitualmente para evitar que los modelos realicen actividades cibernéticas de alto riesgo se desactivaron intencionadamente para la evaluación.
Aun así, merece la pena prestar atención a lo que ocurrió. Según las investigaciones posteriores, parece que el agente llegó a la conclusión de que la información que poseía Hugging Face podría ayudarle a completar el punto de referencia que se le había asignado. Encontró una vía de salida a través de una vulnerabilidad de día cero en la infraestructura utilizada por el entorno de evaluación, obtuvo un acceso más amplio a Internet, encadenó otras rutas de ataque, obtuvo credenciales y finalmente llegó a los sistemas de Hugging Face. La reconstrucción forense de Hugging Face abarcó unas 17.600 acciones individuales, agrupadas en aproximadamente 6.280 grupos.
La tentación, naturalmente, es recurrir al titular de "la IA escapó" o "la IA se volvió rebelde". No estoy seguro de que ninguno de los dos sea especialmente útil. Por lo que pudieron determinar las investigaciones, el software intentaba alcanzar el objetivo asignado y encontró una ruta que nadie esperaba que tomara. Hugging Face cree que el agente intentaba efectivamente engañar a la evaluación llegando a los sistemas de producción donde pensaba que podría haber información o soluciones de referencia disponibles.
Eso es considerablemente menos teatral, pero desde la perspectiva de la transformación digital es probablemente más importante.
Durante los últimos años, la mayoría de las organizaciones han experimentado la IA generativa como algo a lo que preguntar. Dale información, hazle una pregunta y obtén una respuesta. Puede resumir un contrato, analizar algunos datos, escribir código o redactar un correo electrónico, pero por lo general sigue habiendo una persona al otro lado que decide qué pasa a continuación.
Los agentes empiezan a difuminar esa frontera. Dale a esa misma inteligencia acceso a herramientas y podrá recuperar información, llamar a una API, actualizar un registro, ejecutar código, enviar un correo electrónico o realizar el cambio por sí misma. OpenAI describe a los agentes de forma muy similar: sistemas que pueden gestionar de forma independiente la ejecución de flujos de trabajo, tomar decisiones, seleccionar las herramientas adecuadas e interactuar con sistemas externos en nombre de un usuario.
El chatbot acaba de obtener acceso de escritura.
Ese cambio es la razón por la que la gobernanza de agentes de IA se está convirtiendo en una preocupación empresarial práctica en lugar de simplemente otra discusión sobre políticas. Una vez que el software puede tomar medidas en lugar de hacer recomendaciones, las preguntas sobre identidad, permisos, controles, auditabilidad y responsabilidad se trasladan a la propia arquitectura.
La automatización cambia cuando se le da intención al software, no instrucciones
El software lleva décadas cambiando las cosas, por lo que existe el peligro de exagerar lo que hay de nuevo aquí. No necesitamos IA para actualizar una base de datos, activar una API o ejecutar un flujo de trabajo. Los scripts, los motores de reglas, las plataformas de orquestación y los procesos automatizados llevan años realizando esas tareas perfectamente.
La diferencia está en cómo pasamos del objetivo a la acción. La automatización tradicional se diseña normalmente en torno a una ruta que alguien ha descrito de antemano. Cuando ocurra X, recupera Y. Si la respuesta es Z, realiza esta acción. Puede haber cientos de reglas, bifurcaciones y excepciones implicadas, pero alguien ha intentado modelar el proceso previamente.
Los agentes nos permiten potencialmente avanzar más hacia dar al software un resultado en lugar de cada instrucción necesaria para alcanzarlo. He aquí el problema. Averigua qué información necesitas. Decide qué herramientas son adecuadas. Gestiona lo que devuelvan y haz el trabajo.
Esa distinción es importante porque la ruta de ejecución puede volverse dinámica. Un agente puede empezar con un sistema, descubrir que necesita un contexto adicional, llamar a otra cosa, encontrarse con un resultado que no esperaba, revisar su enfoque y continuar. Las arquitecturas de agentes actuales se construyen explícitamente en torno a esta capacidad de gestionar un flujo de trabajo, elegir herramientas y tomar medidas en función del estado de la tarea.
Se trata de una propuesta materialmente diferente a la de la automatización convencional. El software ya no se limita a ejecutar un flujo predeterminado. Dentro de los límites que establezcamos a su alrededor, le otorgamos cierta discrecionalidad sobre cómo se desarrolla ese flujo.
Y ahí es donde esto se pone mucho más interesante que otra conversación sobre si la IA puede escribir un correo electrónico mejor.
La oportunidad consiste en eliminar la coordinación, no a las personas
Una cantidad sorprendente de trabajo dentro de una organización no es difícil porque una tarea individual sea especialmente complicada. Es difícil por la coordinación que se requiere entre las tareas.
Abre el CRM. Busca al cliente. Copia un identificador en la plataforma de facturación. Lee las notas. Comprueba otro sistema. Deduce lo que significan. Pregunta a otro equipo si algo es normal. Espera la respuesta. Actualiza la primera plataforma y envía un correo electrónico al cliente.
¿Le suena familiar?
Llevamos años intentando automatizar esos procesos, y la tecnología de flujo de trabajo convencional es extremadamente eficaz cuando los pasos se pueden describir de forma predecible. Las partes difíciles suelen ser las excepciones: el documento que no está estructurado correctamente, la cuenta que no coincide del todo, tres sistemas que no se ponen de acuerdo entre sí, o el punto del proceso en el que alguien necesita leer algo y comprender lo que significa antes de saber qué hacer a continuación.
Ese es precisamente el tipo de flujos de trabajo en los que los agentes pueden resultar útiles. Las directrices actuales de OpenAI identifican específicamente la toma de decisiones complejas, las reglas difíciles de mantener y la fuerte dependencia de información no estructurada como áreas en las que un enfoque basado en agentes puede ofrecer algo que la automatización determinista convencional no ofrece. También señala un punto importante: cuando esas características no están presentes, una solución determinista puede seguir siendo la mejor respuesta.
Si el software puede encargarse de parte de la coordinación entre sistemas, información y decisiones, existe potencialmente una ganancia de eficiencia significativa. No porque todos los implicados en el proceso desaparezcan de repente, sino porque podemos dejar de utilizar a las personas como un costoso middleware entre plataformas que nunca fueron especialmente buenas coordinándose entre sí.
Hay una distinción importante en este punto. El objetivo no debe ser necesariamente eliminar a las personas de la organización. Debería ser eliminar el trabajo que actualmente hacemos hacer a las personas simplemente porque la tecnología que hay debajo no puede manejar muy bien el contexto, la ambigüedad o las excepciones.
Por eso creo que la oportunidad en torno a los agentes es mucho más significativa que la productividad incremental. Redactar una respuesta a un cliente diez segundos más rápido es útil. Permitir que el software investigue el problema, concilie la información relevante y lleve adelante el proceso es algo completamente distinto.
Por supuesto, cuanto más adelante lleve el proceso, más cerca estará finalmente de una acción con consecuencias.
Y ahí es donde las cosas se complican bastante más.
La capacidad no es autoridad
Unos meses antes del incidente de Hugging Face, PocketOS publicó un relato sincero de un agente de IA que borró la base de datos de producción de la empresa. El borrado tardó nueve segundos. La recuperación tardó sesenta horas. Sus copias de seguridad existían, pero tenían tres meses de antigüedad porque el proceso de copia de seguridad había dejado de funcionar silenciosamente.
PocketOS también tiene muy claro que esto no fue simplemente un "problema de IA". La empresa afirma que el agente actuó con confianza utilizando permisos que nunca debería haber tenido, en un entorno que no presentaba suficientes restricciones en torno a la acción destructiva.
Esa es la lección útil.
Los humanos llevan años borrando bases de datos de producción, y los errores de software también han hecho una contribución respetable. Lo interesante es que el actor tenía suficiente autoridad para que su error importara.
Esto ya lo entendemos cuando el actor es humano. Alguien en atención al cliente puede estar autorizado a emitir un reembolso de £20 sin que a nadie le importe demasiado. £200 puede seguir siendo algo totalmente razonable. £20.000 probablemente requiera otra conversación.
Lo mismo se aplica a otros ámbitos. Un agente que identifica una falta de ortografía en los metadatos de un contenido y la corrige es probablemente algo bastante inofensivo. Si el campo que desea cambiar determina si ese contenido puede distribuirse en un territorio concreto, la consecuencia es muy diferente. Del mismo modo, un agente puede identificar correctamente un problema de configuración de producción, pero eso no significa que deba heredar derechos ilimitados para reconfigurar todo el entorno.
Nada de esto es especialmente exótico. Es gestión de identidades y accesos aplicada a un nuevo tipo de actor, y sospecho que se convertirá en uno de los pilares de una gobernanza eficaz de la IA de agentes.
Microsoft ya está tratando a los agentes en estos términos. Su guía actual recomienda una identidad de agente de IA única y dedicada, un propietario o patrocinador nombrado, un propósito y acceso a datos claramente documentados, acceso con privilegios mínimos, permisos de herramientas controlados, registro de actividad y rutas de revocación probadas. El trabajo del NIST en la misma área está examinando explícitamente la identificación, autorización, auditoría y el no repudio para los agentes de IA.
En términos prácticos, eso significa que los permisos de los agentes de IA deben tratarse con la misma seriedad que las cuentas de servicio y de humanos privilegiados. Un agente puede ser perfectamente capaz de determinar lo que cree que debería ocurrir sin tener derecho a hacer que ocurra.
Esa distinción es importante. Los controles de agentes de IA no pueden limitarse a preguntar si un modelo es técnicamente capaz de realizar una acción. Tienen que determinar si este agente en particular, actuando en este contexto en particular, está autorizado a realizarla.
Como nota al margen, sospecho que la proliferación descontrolada de agentes de IA se convertirá en uno de esos problemas que las organizaciones no creen tener hasta que alguien pregunta finalmente: "¿Cuántos agentes tenemos en realidad?". Ya hemos pasado por variantes de esto con aplicaciones SaaS, recursos en la nube, cuentas de servicio y claves API. No hay ninguna razón obvia para que el conjunto de agentes se organice mejor por sí solo, sobre todo en empresas donde la experimentación se delega deliberadamente entre los equipos.
Eso no significa centralizar cada iniciativa de IA. Es poco probable que un equipo central comprenda cada proceso lo suficientemente bien como para identificar todas las aplicaciones útiles por sí mismo. La innovación descentralizada puede ser totalmente sensata.
La autoridad descentralizada por accidente es un asunto diferente.
La IA de agentes hereda cada compromiso de su infraestructura digital
Hay otro problema incómodo debajo de todo esto. Su agente va a heredar su infraestructura digital existente.
Las relucientes API, los sistemas heredados, los registros de clientes incoherentes, la integración que alguien escribió hace ocho años y que nadie quiere tocar, y la plataforma que llama a un cliente de una manera mientras otra plataforma lo llama de otra. Una empresa crece, se compran plataformas, los equipos resuelven problemas individuales, se producen adquisiciones, los proveedores cambian y las prioridades se mueven. Al final, se acaba con lo que todo el mundo denomina cortésmente la arquitectura actual.
Ahora imagine a un agente tratando con un cliente que ha pagado por un servicio pero no puede acceder a él. La respuesta puede requerir información de los sistemas de CRM, facturación, autenticación, derechos de acceso y soporte antes de que nadie pueda determinar qué ha ocurrido realmente.
Un operador humano a menudo lidiará con las incoherencias casi sin pensar en ellas. Sabe que un sistema se actualiza antes que otro. Se da cuenta de que los identificadores son ligeramente diferentes. Quizá recuerde que los clientes con un paquete antiguo se comportan de forma diferente, o simplemente pregunte a la persona sentada a su lado porque la documentación no se ha actualizado desde 2023.
Asigne el trabajo a un agente y esas suposiciones tendrán que existir en alguna parte. ¿Qué sistema tiene la autoridad? ¿Qué ocurre si facturación dice que el pago se ha realizado correctamente pero la plataforma de derechos dice que la cuenta está inactiva? ¿La información es errónea o hay una regla de negocio que el agente no entiende? ¿Una plataforma va simplemente cinco minutos por detrás?
Se trata de antiguos problemas de datos y arquitectura con un nuevo consumidor. La diferencia material es que el consumidor ahora puede tomar medidas basándose en cualquier conclusión a la que llegue.
Unos datos deficientes suministrados a un chatbot pueden producir una respuesta errónea. Unos datos deficientes suministrados a un software autónomo pueden producir un resultado perjudicial.
También hay otra complicación. La información no tiene por qué ser errónea por accidente. Una investigación publicada en julio demostró ataques de inyección de datos en agentes, en los que información controlada por un atacante podía presentarse como datos contextuales aparentemente legítimos e influir en lo que un agente hacía posteriormente. Los investigadores identificaron vulnerabilidades en agentes web y de programación reales que podían dar lugar a clics no deseados, ejecución remota de código y acciones en la cadena de suministro de software.
Eso crea un cruce incómodo entre la arquitectura de datos y la seguridad. If la información puede influir en la acción, la procedencia de esa información, si se puede confiar en ella y cuánto peso debe darle el agente ya no son preocupaciones abstractas de gobernanza. Pasan a formar parte del modelo de ejecución.
Esta es también la razón por la que tendría cuidado con la idea de que los agentes hacen que la deuda técnica sea de algún modo menos importante. Un agente puede hacer que los entornos fragmentados sean más fáciles de navegar porque puede razonar sobre una tarea en lugar de depender totalmente de una ruta de integración fija, pero sigue necesitando acceso a los sistemas, interfaces utilizables, datos significativos, permisos adecuados y alguna idea de qué hacer cuando algo falla a mitad de camino.
Si la API no existe, el agente necesita otra vía de acceso. Si el mismo cliente tiene seis identificadores, alguien o algo tiene que establecer si representan a la misma persona. Si una regla de negocio no documentada es importante para la decisión, ese conocimiento debe estar disponible en alguna parte.
Colocar una capa de orquestación inteligente frente a una infraestructura desordenada no hace que esta deje de estar desordenada. Puede que facilite la navegación por el desorden. También puede permitir que las consecuencias de ese desorden se propaguen considerablemente más rápido.
La supervisión humana tiene un coste económico
En este punto de la mayoría de las conversaciones, alguien dirá que siempre habrá un humano en el proceso (human in the loop).
Eso suena tranquilizador, pero plantea una pregunta obvia: si alguien todavía tiene que revisar y aprobar todo lo que hace el agente, ¿cuánto hemos automatizado realmente?
Imagine que nuestro agente de atención al cliente ha comprobado cinco sistemas, ha identificado un problema con la cuenta, ha establecido que al cliente se le cobró incorrectamente y ha calculado que corresponde un reembolso de £20. A continuación, coloca todo el asunto en una cola para que alguien haga clic en "Aprobar".
Es posible que se siga produciendo un ahorro significativo porque se ha automatizado la investigación, pero ejecute ese proceso en decenas de miles de transacciones y habrá conservado una operación manual de gran envergadura. El cuello de botella se ha desplazado en lugar de desaparecer.
Aquí es donde parte del lenguaje más conservador en torno a la IA de agentes empieza a entrar en conflicto con la economía de la automatización. Introducimos la autonomía porque queremos que el software elimine trabajo de un proceso, y luego nos ponemos lo suficientemente nerviosos con la autonomía como para volver a introducir a una persona en cada transacción.
Al final, eso anula bastante el propósito.
Por lo tanto, el reto de la supervisión de agentes de IA es que una mayor supervisión no es automáticamente mejor. Cada paso de aprobación puede reducir un tipo concreto de riesgo, pero también vuelve a introducir costes, latencia y esfuerzo manual en el proceso. La pregunta más adecuada es dónde aporta valor realmente el juicio humano.
Si el reembolso es de £20, las reglas son claras, todos los sistemas pertinentes están de acuerdo y la acción puede revertirse fácilmente, tal vez nadie necesite aprobarlo. Si el importe es de £20.000, dos sistemas no están de acuerdo o la situación cae fuera de los parámetros normales, ese parece un momento excelente para involucrar a alguien.
Para muchos procesos, el destino útil probablemente no sea un humano en el proceso, sino un humano por excepción. El trabajo rutinario y bien comprendido se vuelve cada vez más autónomo, mientras que los casos inusuales, ambiguos o de consecuencias graves se derivan a una instancia superior.
Eso todavía deja mucho espacio para introducir la autonomía de forma gradual. Un agente puede empezar observando y recomendando. Una vez comprendido su comportamiento, puede preparar acciones para su aprobación. Con el tiempo, clases específicas de acciones rutinarias y reversibles pueden ejecutarse automáticamente, involucrando a las personas cuando el proceso supere un umbral acordado.
La guía de OpenAI adopta un enfoque similar basado en el riesgo. Recomienda la intervención humana cuando los agentes superen los umbrales de fallo definidos y en torno a acciones que sean sensibles, irreversibles o de alto riesgo, como grandes reembolsos o pagos.
PocketOS llegó al mismo problema desde una dirección considerablemente menos teórica. Tras el incidente de su base de datos, las operaciones destructivas requieren ahora una confirmación humana explícita. La empresa no respondió abandonando los agentes autónomos. Afirma que sigue ejecutando varios agentes autónomos específicos en producción, al tiempo que modifica la ubicación del límite de control.
Esa me parece la forma más útil de pensar en la supervisión humana. Es un control que debe aplicarse allí donde la consecuencia lo justifique, no necesariamente un modelo operativo permanente para cada acción realizada por el software autónomo.
Al fin y al cabo, el objetivo de la automatización es automatizar. El problema de diseño consiste en decidir dónde mejoran las personas realmente el resultado y dónde se las mantiene simplemente porque aún no confiamos lo suficiente en el sistema como para eliminarlas.
La autonomía sin trazabilidad es operativamente indefendible
Si avanzamos hacia los humanos por excepción, otra cosa pasa a ser más importante en lugar de menos: entender qué hizo realmente el agente.
La investigación de Hugging Face es un ejemplo extremo de utilidad. Su reconstrucción forense abarcó unas 17.600 acciones en miles de grupos, con los investigadores reconstruyendo cómo se movió el agente a través de los sistemas y cómo adaptó su comportamiento a lo largo del tiempo.
Lleve eso a un proceso empresarial normal. Un cliente dice que algo cambió incorrectamente en su cuenta y usted descubre que un agente realizó el cambio.
Es poco probable que la respuesta "lo hizo la IA" le sirva de mucho en la revisión del incidente.
Querrá saber qué agente actuó, quién inició la tarea, qué información utilizó, qué contenía esa información en ese momento, a qué herramientas llamó y qué permiso permitió en última instancia el cambio. Si otro agente se involucró por el camino, eso probablemente también importe.
Aquí es donde la auditabilidad de los agentes de IA deja de ser una sutileza de gobernanza y se convierte en un requisito operativo. Cuanto menor sea la participación humana directa en la ejecución, más sólida deberá ser la observabilidad circundante.
La guía actual de Microsoft recomienda registrar la identidad del agente, su función y alcance efectivo, la acción realizada, el recurso afectado y cualquier usuario en cuyo nombre estuviera actuando. Del mismo modo, el NIST está considerando explícitamente la auditoría y el no repudio como parte del problema de identidad y autorización de los agentes.
Eso no significa que cada acción autónoma necesite que alguien la vigile. Ya operamos enormes entornos automatizados sin poner a una persona delante de cada transacción, evento de infraestructura o solicitud de red. Establecemos límites, controles y supervisión, y luego investigamos las cosas que quedan fuera de ellos.
No hay ninguna razón obvia para que los sistemas de agentes maduros funcionen de forma diferente.
La autonomía no elimina la supervisión. Cambia el momento en que se produce la supervisión.
La intención delegada complica el límite de confianza
Hay un desarrollo más que vale la pena vigilar porque hace que este problema sea más interesante todavía.
Los agentes se diseñan cada vez más para comunicarse y colaborar con otros agentes. El protocolo Agent2Agent de Google estandariza cómo los agentes pueden descubrirse y comunicarse entre sí, incluidos los agentes creados por diferentes equipos y en diferentes pilas tecnológicas. Su trabajo más reciente de Descubrimiento de Recursos Agénticos aborda la cuestión relacionada de cómo los agentes pueden encontrar y verificar herramientas, habilidades y otros agentes distribuidos entre equipos, organizaciones y plataformas.
Imagine que un agente interno recibe una tarea y determina que otro agente especialista puede realizar parte de ella. Ese segundo agente utiliza una herramienta que llama a uno de sus servicios y finalmente cambia algo.
¿Quién está actuando?
¿El segundo agente? ¿El primer agente? ¿La persona que inició la tarea original?
Si el primer agente está autorizado a realizar una acción, ¿puede delegar esa autoridad? ¿La recibe el segundo agente en su totalidad, en parte o en absoluto? ¿Qué ocurre si los agentes pertenecen a organizaciones diferentes?
Estas son preguntas emergentes y sería prematuro pretender que el sector se ha puesto de acuerdo en todas las respuestas. La Iniciativa de Estándares para Agentes de IA del NIST está llevando a cabo específicamente trabajos en torno a la infraestructura de autenticación e identidad de agentes para respaldar interacciones seguras entre humanos y agentes, y entre múltiples agentes.
Pero la dirección importa. Históricamente, la confianza se ha asociado a menudo con un usuario, una aplicación o una integración conocidos. Una vez que los agentes pueden descubrir capacidades de forma dinámica y delegar partes de un objetivo en otros lugares, la confianza y la autoridad deben sobrevivir al trayecto.
La tarea puede ser dinámica. La responsabilidad no puede desaparecer cada vez que cruza otra frontera.
La transformación agéntica debe empezar por la delegación, no por la tecnología
Existe un patrón con los cambios tecnológicos significativos que la mayoría de las personas implicadas en la transformación reconocerán. Algo pasa a ser estratégicamente importante, alguien decide que la organización lo necesita y todo el mundo empieza a buscar dónde colocarlo.
Necesitamos una estrategia de IA. Necesitamos algunos casos de uso de agentes. Deberíamos organizar un taller. ¿Qué procesos podemos hacer agénticos?
Yo probablemente lo enfocaría al revés.
Empiece por el proceso que molesta a todo el mundo. El que es lento, costoso, fragmentado o depende de que alguien se pase el día transfiriendo información entre sistemas. Entienda dónde se toman las decisiones, en qué información se apoyan esas decisiones, qué sistemas están implicados, dónde se producen las excepciones incómodas y qué ocurre cuando algo sale mal.
A continuación, observe qué están haciendo realmente las personas en el proceso. ¿Están ejerciendo un juicio valioso o están compensando las limitaciones de la tecnología que les rodea? ¿Están aprobando algo porque existe un riesgo financiero o de explotación real, o porque el flujo de trabajo no puede distinguir un caso rutinario de uno inusual? ¿Están conciliando información manualmente porque la organización necesita realmente su experiencia o porque dos sistemas utilizan identificadores diferentes?
Esos son problemas bastante diferentes.
Una vez que comprenda esto, decida qué está dispuesto a delegar. ¿Qué decisiones puede tomar el software? ¿Qué acciones puede realizar? ¿Cuáles son reversibles? ¿Dónde necesita derivación a una instancia superior? ¿Qué autoridad requiere? ¿Qué pruebas necesitaría después si alguien le preguntara por qué se tomó una decisión?
Sólo entonces la elección de la tecnología se vuelve especialmente interesante.
Un agente puede ser una respuesta excelente. Puede que no. No pasa nada. Las directrices actuales sobre el diseño de agentes hacen prácticamente la misma distinción: los agentes son idóneos para flujos de trabajo en los que la ambigüedad, las decisiones complejas o los datos no estructurados dificultan los enfoques deterministas, pero cuando esas características no están presentes, la automatización convencional puede seguir siendo totalmente suficiente.
El objetivo no es desplegar agentes. Es mejorar el negocio.
La arquitectura de la automatización se está convirtiendo en la arquitectura de la autoridad
Durante los últimos veinte años, la transformación digital ha consistido en gran medida en conectar a las personas con los sistemas y a los sistemas entre sí. Ahora empezamos a introducir a otro participante en esa infraestructura: software que puede recibir un objetivo, determinar cómo alcanzarlo y utilizar esos sistemas en nuestro nombre.
Existen posibilidades verdaderamente interesantes en ello, sobre todo en torno al trabajo de coordinación que se ha resistido a la automatización convencional. El propio NIST describe el potencial de los agentes para mejorar la productividad, la eficiencia y la toma de decisiones, al tiempo que destaca la necesidad de controles adecuados de identificación y autorización cuando se concede a esos agentes acceso a datos, herramientas y aplicaciones de la organización.
Creo que esa combinación es importante. La oportunidad y el riesgo provienen de la misma característica: el agente tiene cierta libertad para decidir cómo se realiza el trabajo.
Una vez que esto ocurre, la arquitectura ya no se preocupa únicamente de si un sistema puede conectarse a otro. Determina cada vez más qué actor autónomo puede utilizar qué información, ejercer qué capacidad, bajo qué autoridad, con qué límites y con qué pruebas de respaldo.
En la práctica, por tanto, es poco probable que la gobernanza de agentes de IA empresariales se resuelva con otro documento de política guardado en algún lugar de la intranet. Tiene que reflejarse en las identidades que creamos, los permisos que concedemos, los controles en torno a las acciones consecuentes, la calidad y procedencia de los datos que consumen los agentes, las rutas de derivación que diseñamos y las pruebas de auditoría que conservamos a posteriori.
Hugging Face nos ofrece un ejemplo extremo de software autónomo que encuentra una ruta que sus operadores no esperaban. PocketOS nos da un ejemplo mucho más cotidiano de lo que ocurre cuando un agente simplemente tiene más autoridad de la que requiere la tarea. El trabajo emergente en torno a la identidad de los agentes, los privilegios mínimos, la interacción segura entre múltiples agentes y el descubrimiento de recursos de confianza demuestra que el modelo de control circundante ya tiene que ponerse al día con la capacidad.
Nada de esto es un argumento en contra de la IA de agentes. Al contrario. Si los agentes pueden eliminar parte de la coordinación humana que hace que las empresas digitales modernas sean costosas y complejas de operar, existe una razón muy tangible para ir tras ellos.
Pero introducir actores autónomos en una infraestructura digital existente no es simplemente otra implementación de IA. Cambia los supuestos sobre identidad, confianza, datos, responsabilidad y, en última instancia, autoridad.
Por eso, antes de preguntar qué puede hacer un agente, yo empezaría con una pregunta diferente.
¿Qué está dispuesto a dejarle hacer realmente?
Si los desafíos analizados aquí le resultan familiares, o si está pensando en cómo se integra la IA agéntica en su entorno digital más amplio, siempre estaremos encantados de intercambiar impresiones. Escríbanos a hello@spicymango.co.uk, llámenos o póngase en contacto con nosotros a través de nuestro formulario de contacto.
Si los desafíos analizados aquí le resultan familiares, o si está pensando en cómo se integra la IA agéntica en su entorno digital más amplio, siempre estaremos encantados de intercambiar impresiones. Escríbanos a hello@spicymango.co.uk, llámenos o póngase en contacto con nosotros a través de nuestro formulario de contacto.
Si los desafíos analizados aquí le resultan familiares, o si está pensando en cómo se integra la IA agéntica en su entorno digital más amplio, siempre estaremos encantados de intercambiar impresiones. Escríbanos a hello@spicymango.co.uk, llámenos o póngase en contacto con nosotros a través de nuestro formulario de contacto.
