La decisión clave: antes de ampliar la autonomía de un agente, define sus permisos, las acciones que necesitan aprobación y la forma de detenerlo. Esa es la base de una implantación que podamos supervisar.

Hay una pregunta que me parece especialmente importante cuando hablamos de agentes de inteligencia artificial en las empresas: ¿hasta dónde estamos dispuestos a dejarles actuar?

Podemos diseñar un sistema que lea una solicitud, busque información y prepare una propuesta. También podemos conectarlo al correo, al CRM o a una herramienta de soporte para que ejecute el siguiente paso. Con cada conexión aumentamos su utilidad y ampliamos las consecuencias de una decisión equivocada.

En este artículo llamo agente de IA a un sistema que utiliza un modelo para decidir pasos y recurrir a herramientas al completar una tarea. Su autonomía depende del diseño: consultar un dato, proponer una respuesta y ejecutar una operación son capacidades distintas.

Ahí aparece una cuestión empresarial muy concreta. Cuando un agente actúa utilizando los accesos de una organización, necesitamos saber qué autoridad le hemos delegado y qué límites siguen vigentes aunque el modelo interprete otra cosa.

La seguridad de los agentes ya tiene una agenda propia

El 20 de octubre de 2026, OWASP publicó su GenAI Red Teaming Manual Version 1.0, una guía para evaluar la seguridad, la protección y la robustez de sistemas de IA generativa. Incluye modelos, aplicaciones, interfaces multimodales y agentes, y pone el foco en pruebas éticas, hallazgos reproducibles y resultados medibles.

Es una referencia interesante para quienes quieren comprobar cómo se comporta un sistema ante situaciones adversas. Probar sus límites exige una metodología y un entorno autorizado.

Mi lectura empresarial es esta: si vamos a incorporar agentes a procesos reales, necesitamos reservar tiempo y recursos para comprobar qué sucede cuando reciben información confusa, encuentran una excepción o intentan realizar una operación fuera del alcance previsto.

Cada permiso cambia el alcance del proyecto

Imaginemos un caso hipotético. Una empresa quiere agilizar su atención al cliente mediante un agente que consulta el estado de los pedidos y prepara respuestas.

Durante el diseño surge una ampliación aparentemente pequeña: permitirle modificar la dirección de entrega. Después aparece otra: que pueda cancelar un pedido. Más adelante, que gestione devoluciones.

Cada ampliación puede tener sentido. También cambia el riesgo. Consultar un estado, modificar datos y ejecutar una devolución requieren controles diferentes. Conviene decidir qué personas pueden solicitar esas operaciones, qué condiciones deben cumplirse y qué acciones necesitan una aprobación adicional.

El objetivo de «resolver la consulta del cliente» resulta demasiado amplio para utilizarlo como política de permisos. El sistema necesita reglas que se puedan comprobar en cada operación.

Qué debería quedar definido antes del despliegue

Propongo empezar con una ficha operativa breve para cada agente. Puede ser sencilla, siempre que recoja decisiones concretas y tenga una persona responsable de mantenerla.

El proceso y el resultado esperado

¿Qué tarea tiene asignada? ¿Cómo sabemos que la ha completado correctamente? En el ejemplo anterior, preparar una respuesta sobre un pedido es un objetivo acotado. «Gestionar toda la relación con el cliente» deja demasiadas decisiones abiertas para una primera implantación.

Los datos y las operaciones permitidas

Conviene distinguir la información que puede consultar de aquello que puede modificar, enviar o eliminar. Una política aplicada en la herramienta o la API puede impedir una operación aunque el agente intente solicitarla. Escribir una prohibición en sus instrucciones aporta contexto, pero el control debe comprobarse también donde se ejecuta la acción.

La aprobación y las excepciones

Hay que determinar qué operaciones requieren revisión, quién puede autorizarlas y qué ocurre si esa persona no está disponible. También cuándo el agente debe detenerse: datos contradictorios, identidad sin verificar, falta de información o una petición que exceda su cometido.

La trazabilidad y la intervención

Necesitamos registros suficientes para reconstruir las operaciones: qué se solicitó, qué herramienta se utilizó, qué autorización existía y cuál fue el resultado. Esa trazabilidad debe proteger la información sensible y tener accesos y plazos de conservación adecuados. Además, alguien debe poder detener el proceso y revocar sus accesos.

Supervisar exige tiempo y capacidad para decidir

La supervisión humana merece tanta atención como la parte técnica. Si una persona recibe decenas de solicitudes de aprobación sin contexto, acabará teniendo dificultades para distinguir una operación rutinaria de otra que requiere análisis.

Una revisión útil debería mostrar qué va a cambiar, sobre qué datos, con qué efecto y qué información falta. La persona encargada necesita formación, tiempo y autoridad para rechazar o devolver la propuesta.

También interesa medir el trabajo que genera esa supervisión. Un sistema puede producir respuestas muy deprisa y necesitar correcciones frecuentes. Para valorar su aportación hay que contar el tiempo de revisión, las incidencias y la carga que sigue soportando el equipo.

Qué probar antes de ampliar la autonomía

El OWASP Top 10 for Agentic Applications 2026 ofrece una referencia específica sobre riesgos de sistemas capaces de planificar y actuar. Para una organización, ese trabajo puede servir como punto de partida para formular pruebas adaptadas a su propio proceso.

En nuestro ejemplo hipotético, propondría comprobar al menos estas situaciones:

  • Una solicitud pide modificar un pedido al que el usuario no debería tener acceso.
  • Un documento recibido contiene instrucciones que intentan cambiar la tarea asignada al agente.
  • La operación se ejecuta, pero la herramienta devuelve un error y el agente intenta repetirla.
  • Se revoca un permiso mientras hay una tarea en marcha.
  • Falta la persona que debe autorizar una acción y el proceso necesita una salida segura.

Son propuestas de prueba para este caso, no una certificación de seguridad. Las evidencias obtenidas deberían permitir decidir qué corregir, qué mantener limitado y qué capacidad merece ampliarse.

Cómo medir si podemos ampliar su autonomía

Para decidir el siguiente paso, propongo comparar el piloto con el proceso anterior. Estas métricas deben adaptarse al impacto de cada tarea; no existe un umbral universal que garantice seguridad:

  • Tiempo total por caso: ejecución, revisión humana y correcciones.
  • Calidad del resultado: operaciones correctas y errores que llegan al cliente.
  • Intervenciones necesarias: aprobaciones, rechazos y escalados al equipo.
  • Respeto de los límites: intentos de acceso indebido y respuesta al revocar permisos.

Si el sistema funciona bien solo cuando alguien corrige cada excepción, ese dato también forma parte del resultado. La capacidad técnica debe acompañarse de una capacidad operativa que el equipo pueda sostener.

La gobernanza acompaña al sistema durante toda su vida

El AI Risk Management Framework 1.0 de NIST organiza la gestión del riesgo en cuatro funciones: gobernar, contextualizar, medir y gestionar. Es un marco voluntario que plantea la gobernanza como una actividad transversal y continua.

Esto tiene una traducción práctica: cambiar el modelo, incorporar una herramienta o abrir el acceso a nuevos datos puede exigir revisar las pruebas y los límites. La aprobación inicial de un proyecto necesita un seguimiento posterior.

También conecta con una idea que desarrollé en cómo aplicar IA en una empresa con estrategia: el valor depende del proceso que queremos mejorar y de las decisiones que nos permite tomar.

Empezar con un alcance que podamos sostener

Creo que los agentes abren una oportunidad importante para empresas de distintos tamaños. Pueden ayudar a organizar información, coordinar tareas y reducir fricciones en procesos que consumen mucho tiempo.

Para aprovechar esa capacidad, empezaría por un proceso acotado, con datos adecuados, permisos concretos y una forma de medir el resultado. A partir de ahí, ampliaría la autonomía con evidencias de funcionamiento y capacidad de intervención.

Delegar una tarea a un agente también exige decidir qué autoridad le damos para completarla.

Si tu empresa está valorando incorporar agentes, una buena primera conversación puede empezar con tres preguntas: ¿qué trabajo queremos mejorar?, ¿qué le vamos a permitir hacer? y ¿quién tendrá la capacidad de intervenir?

En BRR abordamos esa conversación desde la formación, la consultoría tecnológica y de IA y la implementación. Puedes contarnos qué proceso quieres mejorar para valorar el siguiente paso.

Bárbara Regina Ribeiro · Fundadora de BRR. Inteligencia artificial y estrategia tecnológica aplicada a empresas.