Permisos, acciones y autonomía: cómo definir qué puede hacer un agente de IA

La autonomía de un agente de IA no es una decisión binaria entre “autónomo” y “no autónomo”. Un agente puede leer, recomendar, modificar o ejecutar, y cada una de esas acciones necesita permisos, límites y niveles de supervisión diferentes. El desafío es diseñar esa autonomía antes de que el agente empiece a operar sobre procesos reales.

---

Cuando una organización comienza a experimentar con agentes de IA, la conversación suele concentrarse en sus capacidades.

• ¿Qué puede resolver?
  
• ¿A qué herramientas puede conectarse?
  
• ¿Puede completar una tarea de punta a punta?

Pero cuando el agente empieza a acercarse a producción, la pregunta cambia.
No importa solamente qué puede hacer técnicamente. Importa qué estamos dispuestos a dejarlo hacer, y bajo qué condiciones.

En una entidad financiera, un agente que consulta información y uno que modifica una operación pueden utilizar la misma tecnología, pero representan situaciones completamente diferentes desde el punto de vista de riesgo, seguridad y gobierno. Por eso, diseñar Agentic AI implica diseñar también sus límites.

La autonomía no es una sola cosa

Hablar de “agentes autónomos” puede llevar a pensar que existe una frontera clara: de un lado, sistemas que necesitan personas; del otro, agentes que actúan solos. En la práctica hay muchos niveles intermedios. Una forma simple de ordenarlos es pensar en cuatro acciones:

Leer

• El agente consulta información, recupera documentos o accede a determinados datos.
  
• No modifica el entorno.
  
• Puede parecer el nivel de menor riesgo, pero sigue siendo necesario definir qué información puede consultar, bajo qué identidad y con qué permisos.

Recomendar

• El agente analiza información y propone una decisión o acción.
  
• Todavía no modifica el sistema, pero su recomendación puede influir sobre una decisión humana.
  
• Acá empiezan a importar la calidad de los datos utilizados, la evaluación del resultado y el nivel de confianza necesario antes de utilizar esa recomendación.

Modificar

• El agente cambia información existente.
  
• Puede actualizar el estado de un caso, completar campos, modificar un registro o intervenir sobre un workflow.
  
• La capacidad de generar consecuencias sobre sistemas reales cambia considerablemente el nivel de control necesario.

Ejecutar

• El agente inicia o completa una acción de negocio.
  
• Puede disparar una transacción, ejecutar un proceso, comunicarse con otro sistema o activar una decisión previamente definida.
  
• En este nivel, identidad, autorización, supervisión, trazabilidad y guardrails dejan de ser complementos.

Leer ≠ recomendar ≠ modificar ≠ ejecutar.
La autonomía debería diseñarse sobre esa diferencia.

Un permiso técnico no es una autorización de negocio

Un error frecuente consiste en asumir que, si un agente tiene acceso técnico a una herramienta, entonces puede utilizar todas sus capacidades.
Pero permitirle conectarse a una API no necesariamente significa permitirle ejecutar cualquiera de sus endpoints.

Acceder a un sistema contable no implica poder modificar todos sus registros.
Consultar información de clientes no significa poder utilizarla para cualquier propósito.

La arquitectura necesita traducir las reglas del negocio a políticas ejecutables.
La pregunta deja de ser ¿Puede acceder? pasa a ser ¿Qué acciones debería poder realizar esta identidad, sobre qué recursos y bajo qué condiciones?
Ahí comienza realmente el diseño de autonomía.

Guardrails: dónde termina la autonomía del agente

Los guardrails son el conjunto de reglas, controles y mecanismos que determinan qué puede hacer un agente, bajo qué condiciones y cuándo debe detenerse, pedir autorización o escalar una decisión.

En Agentic AI, un guardrail puede establecer, por ejemplo:

• qué fuentes de información están permitidas;
  
• qué herramientas puede utilizar;
  
• qué acciones están habilitadas;
  
• qué tipos de operación están prohibidos;
  
• qué umbrales puede gestionar automáticamente;
  
• qué condiciones requieren aprobación humana;
  
• cuándo debe detener una ejecución;
  
• qué excepciones deben escalarse.

Esto es importante porque los guardrails no deberían pensarse únicamente como filtros sobre lo que un modelo puede responder.
Cuando el agente actúa sobre sistemas reales, también tienen que controlar lo que puede hacer.

Permisos y guardrails no son lo mismo

Ambos conceptos están relacionados, pero cumplen funciones diferentes.

• Los permisos determinan a qué recursos y acciones tiene acceso una identidad.
  
• Los guardrails determinan las condiciones dentro de las cuales esa capacidad puede utilizarse.

Un agente podría, por ejemplo, tener permiso técnico para modificar una operación pero contar con un guardrail que solo le permita hacerlo por debajo de cierto monto. O tener acceso a una herramienta, pero necesitar aprobación humana para utilizar determinadas funciones. En términos simples:

• Permisos: ¿puede acceder y actuar?
  
• Guardrails: ¿cuándo, cómo y hasta dónde puede hacerlo?

Una arquitectura preparada para producción necesita ambas capas.

Human-in-the-Loop no significa aprobar todo

Una respuesta habitual frente al riesgo es colocar una persona en cada decisión.
Pero si toda acción automatizada necesita una aprobación manual, el beneficio de la automatización puede desaparecer rápidamente.
El objetivo de Human-in-the-Loop no debería ser agregar intervención humana por defecto. Debería ser identificar dónde esa intervención aporta control real.
Por ejemplo:

• una operación frecuente, predecible y de bajo impacto podría ejecutarse automáticamente dentro de límites claros;
  
• una excepción podría requerir revisión;
  
• una acción de mayor impacto podría necesitar aprobación previa;
  
• una situación fuera de política podría detener el workflow completamente.

La supervisión también puede adoptar distintos modelos. En algunos procesos una persona interviene antes de la acción. En otros monitorea y puede intervenir cuando aparece una excepción. La pregunta no es si queremos humanos o agentes. Es cómo distribuimos autoridad entre ambos.

La autonomía debería depender del riesgo de la acción

No todas las acciones merecen el mismo nivel de control. Un agente que clasifica documentación interna no representa el mismo riesgo que uno capaz de modificar información financiera.

Por eso, la autonomía debería diseñarse considerando variables como:

• impacto de una acción incorrecta;
  
• sensibilidad de los datos involucrados;
  
• reversibilidad;
  
• monto o valor económico;
  
• criticidad del proceso;
  
• alcance potencial del error;
  
• requisitos regulatorios;
  
• capacidad de detectar una anomalía;
  
• existencia de mecanismos de rollback o recuperación.

Esto permite evitar dos extremos igualmente problemáticos. Demasiada autonomía, que aumenta innecesariamente la exposición, y demasiado control, que transforma al agente en una automatización incapaz de producir el valor esperado.

En sistemas multiagente, separar responsabilidades puede ser una ventaja

A medida que aumenta la complejidad, no necesariamente un único agente debería tener autoridad para completar todo el proceso.

• Una arquitectura puede distribuir responsabilidades.
  
• Un agente consulta información.
  
• Otro prepara una recomendación.
  
• Otro ejecuta una acción.
  
• Y otro verifica que el resultado cumpla determinadas reglas.

Esto no elimina el riesgo, pero permite trabajar con principios similares a la segregación de funciones que ya existen en procesos financieros. Cada agente puede tener una identidad, permisos y límites distintos. De esta forma, un error o compromiso en un componente no necesariamente habilita acceso a todo el proceso, pero también introduce una nueva necesidad: poder observar y gobernar la interacción entre agentes. Porque a medida que aumentan las dependencias, también aumenta la posibilidad de errores en cascada.

Un ejemplo: conciliaciones financieras

Supongamos que un agente analiza diferencias entre extractos bancarios y registros contables.
En un primer nivel podría:

• leer ambas fuentes
  
• detectar inconsistencias
  
• clasificarlas
  
• y recomendar una resolución.

La organización decide después aumentar su autonomía. Para determinadas diferencias conocidas, el agente puede modificar automáticamente un registro.
Pero solo si:

• el tipo de diferencia está contemplado
  
• el monto se encuentra dentro de un límite
  
• las fuentes cumplen determinados criterios
  
• y no existe una alerta asociada.

Todo lo demás se deriva a una persona. La tecnología del agente puede ser la misma, lo que cambió fue su autoridad, y esa autoridad fue traducida a permisos, políticas, guardrails y mecanismos de supervisión. Eso es diseñar autonomía.

El error es esperar a producción para definir los límites

Durante un MVP es natural simplificar controles para validar rápidamente el caso.
El problema aparece cuando esas decisiones temporales se convierten silenciosamente en la arquitectura definitiva.

• Cuentas con permisos demasiado amplios.
  
• Herramientas habilitadas por completo.
  
• Excepciones que no fueron modeladas.
  
• Aprobaciones que existen solamente en el proceso manual anterior.
  
• Logging incompleto.
  
• Owners poco claros.

Cuando Seguridad, Risk, Compliance o Auditoría intervienen, el proyecto descubre que el agente funciona, pero todavía no está preparado para operar.
Por eso, los límites de autonomía deberían empezar a definirse mientras evoluciona el caso de uso, no después.

7 preguntas para diseñar la autonomía de un agente

Antes de aumentar la capacidad de acción, conviene poder responder:

1. ¿Qué puede leer?
   
2. ¿Qué puede recomendar?
   
3. ¿Qué puede modificar?
   
4. ¿Qué puede ejecutar?
   
5. ¿Bajo qué condiciones están permitidas esas acciones?
   
6. ¿Qué requiere aprobación o escalamiento?
   
7. ¿Podemos detectar, detener y reconstruir una acción incorrecta?

Las respuestas probablemente no sean iguales para todos los agentes, y tampoco deberían permanecer estáticas durante todo su ciclo de vida. A medida que el caso cambia, los permisos y guardrails deberían revisarse.

La autonomía no se habilita. Se diseña.

Agentic AI permite avanzar desde sistemas que generan respuestas hacia sistemas que participan activamente de procesos empresariales. Ahí está buena parte de su potencial, pero también aparece una nueva responsabilidad. No alcanza con decidir que un agente será autónomo. Hay que definir exactamente en qué puede serlo.

En COA abordamos esa conversación dentro de una arquitectura más amplia de Data + Integration + AI + Governance, donde identidad, permisos, guardrails, supervisión, observabilidad y accountability forman parte del diseño del agente.

¿Querés revisar qué tan preparada está tu organización para escalar IA?

Realizá la Evaluación de Madurez de IA de COA y obtené un diagnóstico de tus capacidades actuales, principales brechas y recomendaciones para avanzar.

¿Ya estás trabajando sobre un agente o caso concreto y necesitás definir permisos, autonomía o controles?

Preguntas frecuentes

¿Qué son los guardrails en Agentic AI?

Son reglas y mecanismos de control que determinan qué puede hacer un agente, bajo qué condiciones puede hacerlo y cuándo debe detenerse, pedir autorización o escalar una situación.

¿Cuál es la diferencia entre permisos y guardrails?

Los permisos determinan qué recursos y acciones están disponibles para una identidad. Los guardrails agregan condiciones y límites sobre cómo y cuándo esas capacidades pueden utilizarse.

¿Qué significa Human-in-the-Loop?

Es un modelo en el que una persona participa en determinados puntos del proceso, por ejemplo aprobando acciones de mayor impacto o resolviendo excepciones. No implica que todas las acciones deban aprobarse manualmente.

¿Un agente debería tener autonomía total?

No necesariamente. El nivel apropiado depende del caso de uso, impacto potencial, sensibilidad de los datos, reversibilidad de las acciones y capacidad de supervisión.

Leé también: ¿Bajo qué identidad actúa un agente de IA?