De conversar a actuar:

Cómo gobernar los agentes de inteligencia artificial

Durante los primeros años de la inteligencia artificial generativa nos acostumbramos a conversar con sistemas capaces de resumir documentos, redactar textos y proponer soluciones. El usuario formulaba una petición, el modelo generaba una respuesta y la interacción terminaba en la pantalla.

Los agentes cambian esa relación porque no se limitan a explicar qué debería hacerse. Un chatbot puede describir los pasos para cancelar un pedido; un agente puede identificar la compra, verificar las condiciones de devolución, solicitar autorización, ejecutar la cancelación y confirmar el reembolso.

La diferencia parece pequeña, pero transforma el problema. Cuando el sistema solo produce texto, el riesgo principal está en la calidad de la respuesta. Cuando puede actuar, entran en juego los permisos, la identidad, la seguridad, la trazabilidad, el coste y la responsabilidad por las consecuencias. Por eso el desafío empresarial no consiste únicamente en construir agentes más capaces, sino en decidir qué autoridad se les concede, bajo qué condiciones pueden utilizarla y cómo se mantiene el control cuando intervienen en procesos reales.

Qué es realmente un agente de inteligencia artificial

No existe una definición única, pero sí una descripción práctica: un agente es un sistema de software capaz de interpretar un objetivo, decidir qué pasos seguir, utilizar herramientas y adaptar su comportamiento según los resultados. La autonomía no tiene que ser completa: un agente puede preparar una transferencia y dejar la aprobación final en manos de una persona autorizada.

Conviene distinguir cuatro cosas que suelen confundirse. Un modelo fundacional se entrena con grandes cantidades de información y puede adaptarse a tareas diversas. Un modelo de lenguaje es la clase de modelo fundacional especializada en procesar y generar lenguaje. Un asistente combina ese modelo con instrucciones, una interfaz y, a veces, acceso a información adicional. Un agente añade la capacidad de seleccionar herramientas, ejecutar acciones y continuar trabajando hasta alcanzar el objetivo o encontrar una condición que le obligue a detenerse. La diferencia no está en la fluidez con la que escribe, sino en lo que puede hacer fuera de la conversación.



Y un apunte histórico que se repite mal con frecuencia: ELIZA, el programa que Joseph Weizenbaum publicó en 1966, fue pionero de la conversación en lenguaje natural, pero no era un agente. Funcionaba con patrones y guiones de respuesta. Su verdadera lección es otra: demostró la facilidad con la que atribuimos comprensión a una máquina que imita una conversación.

La anatomía de un agente

Aunque las implementaciones varían, un agente empresarial combina seis componentes.

• El objetivo y las instrucciones. «Gestiona las devoluciones» es demasiado abierto. Una definición operativa indica qué productos pueden devolverse, en qué plazo, qué datos pueden consultarse, qué excepciones requieren revisión y qué acciones necesitan autorización humana. El objetivo no es una frase inicial: es una especificación de comportamiento.

• El modelo. Interpreta la petición y propone el siguiente paso a partir de patrones estadísticos y del contexto recibido. No comprende el proceso como lo haría un profesional, y por eso una respuesta plausible no garantiza que la acción propuesta sea correcta.

• Las herramientas. Funciones que permiten interactuar con otros sistemas: una API, una base de datos, un buscador, una aplicación corporativa. El agente no debería recibir acceso general a la infraestructura: quien consulta facturas necesita permiso de lectura, no autoridad para modificar cuentas.

• El contexto y la memoria. El contexto reúne la información de una ejecución; la memoria conserva datos entre interacciones. Cuanto más recuerda un agente, mayor es la exposición de información personal, confidencial o desactualizada, así que la memoria necesita políticas de consentimiento, conservación, aislamiento entre usuarios y eliminación.

• El ciclo de ejecución. Interpretar, seleccionar una acción, ejecutarla, observar el resultado y decidir el siguiente paso. Es lo que permite abordar procesos que no se resuelven con una sola respuesta — y también lo que permite que un error inicial se propague durante varios pasos.



• La evaluación y los límites. Validaciones de formato, reglas de negocio, límites de coste, número máximo de intentos y condiciones de escalamiento a una persona. Cuando el impacto es relevante, la evaluación no puede confiarse al mismo modelo que generó la acción: hacen falta comprobaciones independientes y reglas deterministas. Una transferencia no es válida porque el modelo afirme que la cantidad «parece razonable».
  

La aUTONOMÍA NO ES UN INTERRUPTOR

Hablar de sistemas autónomos sugiere que hay que elegir entre control humano absoluto y libertad completa. En realidad la autonomía es gradual:

La pregunta adecuada no es si un agente debe tener autonomía, sino cuánta necesita para aportar valor sin superar la capacidad de control de la organización. Un sistema que recomienda una película tolera cierto error; uno que bloquea una cuenta o compromete fondos, no.

Dónde aparece el valor

Tres campos concentran hoy los casos más sólidos.

• Experiencia del cliente. Rufus, el asistente de compras de Amazon, combina modelos, catálogo, historial, memoria y herramientas. Amazon afirma que más de 250 millones de clientes lo usaron en 2025 y que quienes lo incorporan a su compra tienen más de un 60% de probabilidad adicional de completarla. Son métricas comunicadas por la propia compañía, no una evaluación independiente — pero ilustran hacia dónde apunta el valor: no conversar mejor, sino reducir pasos y completar una necesidad concreta.

• Automatización de procesos complejos. Los agentes interesan cuando el trabajo exige interpretar información no estructurada y decidir entre fuentes. El asistente de Formula 1 y AWS para investigar incidencias técnicas redujo la clasificación inicial de más de un día a menos de veinte minutos y el tiempo completo de resolución hasta un 86%, según las cifras publicadas por los propios implicados. La lección útil no es la cifra: el proyecto empezó reconstruyendo el proceso de diagnóstico y solo después introdujo la tecnología.

• Desarrollo de software. Los agentes pueden analizar repositorios, generar código, ejecutar pruebas y proponer correcciones. Pero generar código no equivale a producir software fiable: la revisión humana, las pruebas, el análisis de vulnerabilidades y el control de versiones siguen siendo necesarios, y en sistemas heredados el conocimiento del negocio es insustituible.

No todos los problemas necesitan un agente

La popularidad del término ha hecho que chatbots y automatizaciones convencionales se vendan como agentes. Gartner llama a esta práctica agent washing, y prevé que más del 40% de los proyectos de IA agéntica serán cancelados antes de terminar 2027 por costes crecientes, valor difuso o controles de riesgo insuficientes. Son previsiones, no hechos; pero apuntan a algo verificable: un proceso rutinario y predecible se resuelve mejor con software convencional. Si una operación siempre sigue los mismos cinco pasos, añadir un modelo probabilístico eleva el coste y reduce la fiabilidad. Los agentes tienen sentido donde hay variabilidad, información no estructurada y decisiones que no pueden codificarse como secuencia fija — y aun ahí, con reglas deterministas para las operaciones críticas.

De hecho, buena parte de lo que se presenta como «agéntico» son flujos de trabajo con modelos dentro: la secuencia la define el programador y el modelo no elige el recorrido. Anthropic propone exactamente esa distinción entre flujos y agentes, y recomienda empezar por la solución más sencilla y añadir autonomía solo cuando mejore el resultado de forma demostrable. Los patrones intermedios — encadenar pasos, enrutar hacia procesos especializados, paralelizar tareas independientes, revisar con un evaluador, o ciclos de decisión y acción como ReAct — cubren la mayoría de los casos reales sin necesidad de autonomía plena.

Dos precisiones que evitan malentendidos frecuentes. Primera: la «reflexión» de un agente no es aprendizaje. Métodos como Reflexion conservan críticas escritas en una memoria y las reutilizan, pero los parámetros del modelo no cambian; un sistema puede corregir un paso en una sesión y repetir el mismo error mañana. Segunda: más agentes no significan mejor resultado. Anthropic midió en su propio sistema de investigación multiagente que los agentes consumen unas cuatro veces más tokens que una conversación, y la arquitectura multiagente unas quince veces más. Es la medición de un sistema concreto, no una ley — pero muestra que la coordinación se paga, y que la arquitectura multiagente debe reservarse para problemas cuyo valor la justifique.

Un apunte de protocolos, porque también se confunden: MCP conecta una aplicación de IA con herramientas, recursos e instrucciones externas; A2A, anunciado por Google en 2025 y donado a la Linux Foundation, comunica agentes entre sí. Se complementan, no compiten. Y ningún protocolo resuelve por sí mismo la seguridad: sigue haciendo falta autenticar, limitar permisos, validar respuestas y registrar operaciones.

La distancia entre la demostración y la producción

Una demostración se prepara con datos limpios, permisos amplios y un recorrido favorable. La producción trae usuarios imprevisibles, datos incompletos, fallos de red y acciones con consecuencias legales. Cruzar esa distancia exige resolver cinco problemas.

• Identidad. Saber quién inicia la operación, qué agente interviene y en nombre de quién actúa. Si una persona no puede consultar los salarios de sus compañeros, el agente que utiliza tampoco debería poder: la autorización debe mantenerse a lo largo de toda la cadena de herramientas.

• Permisos mínimos. Conceder solo lo imprescindible para la función. Un agente de viajes puede consultar calendarios y preparar reservas, pero pedir aprobación antes de comprar, con límite económico y proveedores autorizados. Existen plataformas que ayudan a aislar ejecuciones y administrar identidades — Amazon Bedrock AgentCore es un ejemplo de la categoría —, pero ninguna elimina la responsabilidad de diseñar bien las políticas de acceso.

• Observabilidad. Poder reconstruir qué hizo el sistema: qué información llevó a cada decisión, qué permisos usó, qué costó, qué paso falló, quién aprobó. Un registro que solo conserva la respuesta final es insuficiente para investigar incidentes o demostrar cumplimiento. OpenTelemetry trabaja en convenciones para registrar de forma coherente llamadas a modelos, tokens y herramientas. Y registrar también tiene su riesgo: las trazas pueden contener datos personales y credenciales, así que necesitan sus propios controles de acceso y conservación.

• Evaluación continua. Los modelos cambian, los datos se actualizan y los usuarios descubren usos imprevistos, así que evaluar solo antes del lanzamiento no basta. Y evaluar solo el resultado tampoco: hay que examinar el resultado, la trayectoria (qué decisiones tomó, qué herramientas usó, si respetó las condiciones — un resultado correcto conseguido con una fuente no autorizada no es un éxito), la seguridad (permisos, datos, resistencia a instrucciones maliciosas) y la eficiencia (coste, latencia, reintentos, intervención humana). Con casos normales, situaciones límite y entradas adversariales.



• Control del coste. Cada razonamiento y cada llamada consumen recursos, y un agente atrapado en un ciclo multiplica el gasto sin mejorar nada. Hacen falta límites de pasos, duración, presupuesto por tarea y condiciones de interrupción. El modelo más potente tampoco es siempre la mejor elección: las tareas sencillas pueden ir a modelos pequeños o a software determinista.
  

La seguridad se amplía cuando el modelo puede actuar

Un modelo puede recibir instrucciones maliciosas del usuario o de los documentos que consulta. Esta segunda variante — la inyección indirecta de instrucciones — es la más peligrosa: un correo puede contener una orden oculta para ignorar las reglas y enviar información a otra dirección, y lo que para una persona es parte del documento, el modelo puede interpretarlo como una instrucción. El perfil de IA generativa del NIST señala que estas inyecciones pueden provocar comportamientos no previstos, filtración de información o ejecución de código, y el riesgo crece cuando el modelo está conectado a herramientas capaces de actuar.

No existe una defensa única. Se necesita la combinación: aislamiento, validación de entradas y salidas, permisos mínimos, separación entre datos e instrucciones, listas de herramientas autorizadas, pruebas adversariales y confirmación humana para acciones sensibles. El Top 10 de OWASP para aplicaciones agénticas ofrece una taxonomía útil de los fallos característicos — envenenamiento de memoria, abuso de privilegios, secuestro del objetivo, fallos en cascada — para diseñar pruebas y controles.

Una forma prudente de empezar

La adopción responsable puede organizarse en cinco decisiones. Elegir un problema real, repetido y medible, con una línea de base que permita comparar antes y después. Conceder la mínima autonomía necesaria: empezar recomendando, avanzar a preparar operaciones y ejecutar solo cuando las pruebas demuestren que el control es suficiente. Limitar herramientas y permisos desde el diseño, porque añadir restricciones después es siempre más difícil. Evaluar recorridos completos, no respuestas que «parecen correctas». Y preparar la operación antes de ampliar el alcance: responsables, supervisión, respuesta a incidentes, reversión y criterios de retirada.

La inteligencia que actúa necesita responsabilidad

Los agentes conectan la capacidad de interpretar lenguaje con la posibilidad de intervenir en procesos digitales. Esa combinación puede mejorar la atención al cliente, reducir trabajo repetitivo y acelerar el desarrollo de software. Pero el valor no procede de la autonomía por sí misma: un agente más independiente también puede equivocarse durante más pasos, usar más información y producir consecuencias más difíciles de revertir.



La pregunta empresarial no es cuántos agentes puede desplegar una organización, sino qué decisiones conviene delegar, qué límites deben mantenerse y cómo se asignará la responsabilidad cuando una máquina actúe en nombre de una persona o una institución. Gobernar la inteligencia significa exactamente eso: no impedir que los sistemas actúen, sino diseñar las condiciones para que lo hagan con una finalidad clara, permisos proporcionales, supervisión efectiva y responsabilidad humana.

Fuentes y lecturas para profundizar

• Joseph Weizenbaum — ELIZA — A Computer Program for the Study of Natural Language Communication Between Man and Machine, Communications of the ACM, 1966. ELIZA — A Computer Program for the Study of Natural Language Communication Between Man and Machine

• Anthropic — Building Effective Agents, diciembre de 2024.

• Anthropic — How we built our multi-agent research system, junio de 2025.
  How we built our multi-agent research system

• Shunyu Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023.
  

• Noah Shinn et al. — Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS 2023.
  

• Anand Rao y Michael Georgeff — BDI Agents: From Theory to Practice, ICMAS 1995.
  

• Model Context Protocol (MCP) — Especificación y documentación oficial.
  

• Google Developers Blog — Announcing the Agent2Agent Protocol (A2A), abril de 2025.
  

• Google Developers Blog — Google Cloud donates A2A to Linux Foundation, junio de 2025.
  

• Gartner — Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, junio de 2025.
  

• Amazon — Amazon Rufus AI assistant: personalized shopping features.
  

• AWS — How Formula 1 uses generative AI to accelerate race-day issue resolution.
  

• AWS — Amazon Bedrock AgentCore, documentación del producto.
  

• NIST — AI Risk Management Framework.
  

• NIST — Generative AI Profile (NIST AI 600-1).

• OWASP Gen AI Security Project — Top 10 for Agentic Applications for 2026

• OpenAI — A Practical Guide to Building Agents, 2025

• LangChain — LangGraph Persistence Documentación sobre puntos de control, persistencia del estado y ejecución tolerante a fallos.

• OpenTelemetry — GenAI semantic conventions. Convenciones para observabilidad y trazabilidad de aplicaciones de inteligencia artificial generativa.