Durante los últimos meses, la conversación empresarial sobre inteligencia artificial ha empezado a cambiar.
Primero nos preguntábamos qué podía responder un modelo. Después, qué tareas podía automatizar. Ahora estamos entrando en una etapa considerablemente más compleja: qué estamos dispuestos a permitirle hacer sin preguntarnos cada vez.
La diferencia parece pequeña, pero no lo es.
Un asistente puede redactar un correo. Un agente puede decidir qué información necesita, consultar sistemas, utilizar herramientas, ejecutar una secuencia de pasos y enviar ese correo. Puede revisar un CRM, clasificar prospectos, actualizar registros, preparar una propuesta, consultar inventarios o activar procesos.
La IA deja de estar únicamente en la conversación y empieza a participar en la operación.
Y cuando una tecnología puede actuar, la pregunta empresarial ya no debería ser solamente:
¿Qué tan inteligente es?
Debería aparecer otra:
¿Quién la autorizó a hacer eso?
De la respuesta a la acción
La evolución es real.
El AI Index 2026 de Stanford reporta que los agentes de inteligencia artificial han avanzado rápidamente en la ejecución de tareas informáticas. En OSWorld, un benchmark que evalúa tareas reales en sistemas operativos y aplicaciones, el mejor desempeño alcanzó 66.3%. Es un salto significativo frente a los niveles de alrededor de 12% observados anteriormente. Sin embargo, el propio informe subraya la otra mitad de la historia: incluso los mejores agentes siguen fallando aproximadamente una de cada tres veces en este tipo de evaluaciones estructuradas.
Ese contraste es importante.
La capacidad ha aumentado lo suficiente para que las organizaciones quieran delegar más trabajo, pero no lo suficiente para asumir que la ejecución será siempre correcta.
Microsoft aporta otra señal del cambio. Su Work Trend Index 2026 señala un crecimiento de 15 veces interanual en agentes activos dentro del ecosistema de Microsoft 365, y de 18 veces en grandes empresas. El mismo estudio insiste en que el reto ya no es únicamente adoptar herramientas, sino rediseñar los sistemas de trabajo alrededor de ellas.
Aquí aparece un cambio conceptual que las empresas necesitan reconocer.
Automatizar una tarea y delegar autonomía no son exactamente la misma cosa.
Un flujo automatizado ejecuta instrucciones
Una automatización tradicional suele funcionar dentro de una secuencia previamente establecida.
Si sucede A, ejecuta B.
Los pasos, las conexiones y buena parte de las decisiones están definidas por anticipado.
Un agente puede decidir cómo llegar al resultado
Un sistema agéntico puede recibir un objetivo, evaluar opciones, utilizar herramientas, incorporar nueva información y modificar su siguiente acción en función de lo que encuentra.
Eso aumenta extraordinariamente su utilidad.
También amplía la superficie de decisión.
Y, por tanto, la superficie de riesgo.
El problema no es darle autonomía a la IA
El problema es darle autonomía sin arquitectura.
Imaginemos una empresa que incorpora un agente comercial.
Su objetivo parece razonable: ayudar al equipo a acelerar el seguimiento de oportunidades.
En una primera versión únicamente consulta información y prepara borradores.
Después se conecta al CRM.
Más adelante obtiene acceso al correo.
Luego puede actualizar oportunidades.
Posteriormente consulta listas de precios.
Finalmente se le permite enviar mensajes directamente a clientes.
En cada paso hemos mejorado su capacidad operativa.
Pero también hemos cambiado algo menos visible: su autoridad.
El agente ya no solamente conoce información. Puede modificarla.
Ya no solamente recomienda una acción. Puede ejecutarla.
Ya no solamente trabaja dentro de una interfaz. Interactúa con otros sistemas empresariales.
Y entonces aparecen preguntas que no pertenecen únicamente al área de tecnología.
¿Qué clientes puede consultar?¿Qué datos puede modificar?¿Puede enviar información fuera de la organización?¿Puede comprometer un precio?¿Puede realizar una acción irreversible?¿Qué ocurre cuando encuentra instrucciones contradictorias?¿Quién revisa las excepciones?¿Cómo sabemos posteriormente por qué ejecutó determinada acción?
Estas preguntas convierten a los agentes en un problema de diseño organizacional, no solamente tecnológico.
Gobernar no significa frenar
Existe un riesgo frecuente en la discusión sobre gobernanza: asumir que gobernar significa agregar tantas restricciones que la tecnología termina perdiendo utilidad.
No debería ser así.
Una buena gobernanza no busca eliminar la autonomía. Busca definir qué autonomía tiene sentido para cada contexto.
NIST, en su perfil de gestión de riesgos para inteligencia artificial generativa, señala precisamente la necesidad de revisar los esquemas de gobernanza, establecer distintos niveles de supervisión humana, incrementar el seguimiento y la documentación cuando sea necesario y restringir aplicaciones que excedan la tolerancia de riesgo de una organización.
Desde la ciberseguridad, el mensaje empieza a ser todavía más concreto.
El OWASP Top 10 for Agentic Applications identifica entre los riesgos relevantes el uso inadecuado de herramientas, el abuso de identidad y privilegios, el secuestro de objetivos del agente y vulnerabilidades asociadas con la cadena de suministro agéntica. Sus recomendaciones relacionadas enfatizan principios conocidos en seguridad, como mínimo privilegio, autorización por solicitud, identificación del usuario y registro de las operaciones realizadas.
La tecnología es nueva.
Varios de los principios para controlarla, curiosamente, no lo son.
PASE: antes de aumentar la autonomía
Para trasladar estas ideas a una conversación empresarial más sencilla, propongo un marco práctico que denomino PASE.
No pretende sustituir un estándar técnico, jurídico o de ciberseguridad. Su función es mucho más simple: obligarnos a hacer cuatro preguntas antes de conceder más autonomía a un agente.
P de Propósito
¿Qué debe conseguir exactamente el agente?
Parece obvio, pero objetivos ambiguos producen comportamientos difíciles de delimitar.
“Mejora las ventas” es una instrucción peligrosamente amplia.
“Identifica oportunidades sin seguimiento durante siete días, prepara un borrador personalizado y entrégalo al ejecutivo responsable para aprobación” define mucho mejor el alcance.
El propósito también debería incluir aquello que el agente no debe hacer.
Definir objetivos sin definir fronteras es dejar incompleto el diseño.
A de Accesos
¿Qué necesita ver y qué necesita poder modificar?
Esta distinción es crítica.
Consultar un CRM no es equivalente a editarlo.
Consultar precios no es equivalente a modificarlos.
Preparar una transferencia no es equivalente a ejecutarla.
Leer una bandeja de entrada no es equivalente a enviar mensajes desde ella.
Cada integración aumenta capacidad, pero también privilegios.
El principio debería parecerse al utilizado desde hace años en ciberseguridad: proporcionar únicamente los permisos necesarios para ejecutar la función prevista.
OWASP recomienda precisamente que el acceso de los agentes siga principios de mínimo privilegio y que las consultas sean autorizadas considerando la identidad y permisos del usuario que originó la solicitud.
Un agente no necesita tener las llaves de todo el edificio simplemente porque alguna vez podría necesitar abrir una puerta.
S de Supervisión
¿Qué puede hacer solo y cuándo necesita detenerse?
Aquí aparece una de las decisiones más importantes.
Supervisión humana no significa necesariamente aprobar cada pequeño paso. Si así fuera, eliminaríamos buena parte del beneficio de utilizar un agente.
Significa diseñar puntos de intervención proporcionalmente al riesgo.
Un agente podría clasificar cientos de documentos automáticamente y solicitar aprobación únicamente cuando detecte una excepción.
Podría generar campañas, pero requerir autorización antes de publicar.
Podría identificar inconsistencias financieras, pero no modificar registros contables.
Podría preparar una propuesta comercial completa, pero detenerse antes de enviarla cuando el descuento supere determinado límite.
El AI Act europeo ofrece un principio útil, aunque sus obligaciones específicas dependen de la clasificación y contexto de cada sistema: para sistemas considerados de alto riesgo contempla mecanismos de supervisión humana, documentación y registro de actividad que permitan entender y controlar su funcionamiento.
La idea puede trasladarse más ampliamente al diseño empresarial:
la supervisión debería colocarse donde una equivocación cambia de ser inconveniente a convertirse en consecuencia.
E de Evidencia
¿Qué podremos reconstruir después?
Esta podría ser la dimensión menos atractiva y una de las más importantes.
Cuando un empleado ejecuta una acción relevante, generalmente existe alguna combinación de usuario, fecha, registro, aprobación, documento o historial.
Un agente también debería dejar evidencia.
¿Qué información consultó?
¿Qué herramienta utilizó?
¿Qué acción ejecutó?
¿Bajo qué identidad?
¿Qué aprobación recibió?
¿Cuál fue el resultado?
¿Hubo una excepción?
La trazabilidad no solamente sirve cuando algo falla. También permite evaluar si el agente realmente genera valor.
Una organización que no puede reconstruir cómo trabaja su agente tendrá dificultades tanto para auditarlo como para mejorarlo.
El AI Act incluye, para determinados sistemas de alto riesgo, obligaciones relacionadas con registros automáticos, documentación y mecanismos que permitan interpretar esos logs. NIST también incorpora seguimiento, evaluación y documentación dentro de sus prácticas de gestión de riesgo.
El error de preguntar solamente si funciona
Cuando evaluamos software tradicional, solemos preguntarnos:
¿Funciona?
Con agentes, esa pregunta resulta insuficiente.
Un agente puede funcionar perfectamente y, aun así, tener permisos excesivos.
Puede completar la tarea solicitada y utilizar para ello información que no debería consultar.
Puede producir buenos resultados durante cien ejecuciones y cometer un error importante en la siguiente.
Puede tomar una decisión razonable que después nadie pueda reconstruir.
Puede incluso mejorar un KPI y hacerlo mediante un comportamiento que la organización nunca habría autorizado conscientemente.
Por eso el rendimiento debe evaluarse junto con el control.
La verdadera unidad de análisis ya no es el agente
Es el sistema en el que opera.
Modelo.Datos.Herramientas.Identidades.Permisos.Personas.Reglas.Registros.Excepciones.Escalaciones.
Todo forma parte del producto.
Esta es, en mi opinión, una de las diferencias más importantes entre experimentar con IA y construir una capacidad organizacional alrededor de ella.
El agente espectacular de una demostración puede impresionar.
El agente empresarial necesita algo adicional: límites claros, responsabilidad y capacidad de ser observado.
De agentes útiles a agentes gobernables
La evolución de los agentes probablemente continuará.
Sus tasas de éxito mejorarán.
Sus herramientas aumentarán.
Los sistemas multiagente serán más comunes.
Las organizaciones encontrarán cada vez más tareas que pueden delegar.
Precisamente por eso, la gobernanza no debería aparecer al final del proyecto como una capa administrativa.
Debería formar parte del diseño.
Cada vez que agreguemos una integración, deberíamos revisar accesos.
Cada vez que aumentemos autonomía, deberíamos revisar supervisión.
Cada vez que el agente pueda producir una consecuencia relevante, deberíamos preguntarnos qué evidencia quedará.
Y cada vez que cambiemos su propósito, deberíamos revisar todo lo anterior.
El futuro empresarial de los agentes no dependerá solamente de construir sistemas capaces de hacer más.
Dependerá de construir sistemas en los que sepamos qué pueden hacer, con qué autoridad, bajo qué límites y quién responde por el resultado.
Porque la pregunta importante ya no será:
“¿Tenemos agentes de inteligencia artificial?”
Será mucho más concreta:
“¿Sabemos exactamente qué les hemos permitido hacer?”
Y quizá esa sea la verdadera diferencia entre tener un agente útil y tener un agente gobernable.
Fuentes
Agentes de IA: autonomía con límites y responsables
2026 AI Index Report
Artificial Intelligence Risk Management Framework: Generative Artificial Profile, NIST AI
OWASP Top 10 for Agentic Applications