Notas técnicasXendai / Publicación técnica

Dónde debería terminar la autonomía de un agente

REFERENCIA
SN-003
Autor
Pedro Trillo
Publicado
Actualizado
LECTURA
9 min

La autonomía de un agente debería terminar donde deja de existir una delegación que la organización pueda justificar, supervisar y retirar. Ese límite depende de las consecuencias de cada acción, de la posibilidad real de corregirla y de las condiciones en las que se ejecuta. La capacidad del modelo es solo una parte de la decisión.

Un agente puede encadenar herramientas y resolver pasos que antes requerían intervención. Esa capacidad hace posible delegar trabajo, pero no determina qué trabajo conviene delegar ni con qué alcance. La decisión pertenece a quien asume sus efectos.

Por eso, describir un agente como «autónomo» dice poco si no se explica sobre qué puede decidir. Puede tener libertad para buscar información y necesitar autorización para enviarla. Puede preparar cambios y carecer de permiso para aplicarlos. Puede actuar dentro de unos límites que dejan de ser válidos cuando cambia el contexto.

La autonomía útil no es una propiedad general que se activa o desactiva. Es una relación entre un mandato, unas acciones y unas condiciones. Diseñarla exige establecer dónde termina esa relación y qué ocurre cuando el trabajo llega a su frontera.

Delegar exige un mandato reconocible

Un objetivo amplio puede orientar a una persona porque existe alrededor una organización que interpreta sus responsabilidades. En un agente, esa expectativa necesita convertirse en un mandato suficientemente explícito para guiar el sistema y permitir que otros lo examinen.

El mandato debe distinguir el resultado buscado de las decisiones permitidas para alcanzarlo. Pedir que se reduzca una demora no autoriza cualquier intervención que pueda acelerarla. Hay compromisos con terceros, reglas internas y recursos que siguen perteneciendo a otras personas.

También conviene expresar qué puede decidir el agente sin consultar. Si cada paso requiere una confirmación, quizá se haya construido un asistente de preparación, lo que puede ser perfectamente útil. Si existe margen de acción, debe describirse por clases de operación y condiciones, no mediante una promesa imprecisa de prudencia.

Esta definición ofrece una base para resolver desacuerdos. Ante una acción discutible, la pregunta no debería limitarse a si el modelo interpretó bien una frase. Debería poder comprobarse si esa acción estaba dentro del encargo aceptado y quién había autorizado ese alcance.

Un mandato demasiado abierto dificulta atribuir responsabilidades. Uno excesivamente estrecho puede impedir que el sistema aporte valor. El diseño consiste en encontrar un espacio de decisión que responda al trabajo real y pueda mantenerse sin depender de interpretaciones improvisadas.

El límite cambia con las consecuencias

No todas las decisiones de un agente tienen el mismo alcance. Algunas producen una propuesta que una persona todavía puede descartar. Otras modifican información compartida, consumen recursos o crean expectativas fuera de la organización.

Esta diferencia importa más que el número de pasos ejecutados. Un recorrido largo de lectura puede tener consecuencias menores que una única acción de escritura. También una consulta puede resultar sensible si expone información a un destino que no debería recibirla.

La reversibilidad necesita examinarse en términos operativos. Que exista una función de deshacer no significa que puedan retirarse todos los efectos de una acción. Corregir un registro puede ser sencillo mientras que reparar una comunicación ya recibida exige otro trabajo y no borra lo ocurrido.

Por eso, conviene separar la dificultad de ejecutar de la dificultad de corregir. Una herramienta puede hacer trivial una operación cuyas consecuencias requieren revisión. La facilidad técnica no reduce automáticamente la responsabilidad asociada.

El alcance acumulado también cuenta. Muchas acciones pequeñas pueden producir un efecto importante antes de que alguien lo detecte. Una política que solo mira cada operación por separado puede pasar por alto la frecuencia, el volumen o la combinación de decisiones.

La consecuencia de este análisis no es exigir autorización para todo. Es decidir dónde una delegación acotada resulta defendible y dónde la organización necesita conservar una decisión explícita. La respuesta puede ser distinta para dos acciones realizadas por el mismo agente.

Consecuencias y posibilidad de corrección
Consecuencias de la acciónCorrección viable y comprobableCorrección difícil, parcial o incierta
Acotadas dentro del trabajo previstoValorar una delegación limitada, con comprobación del resultadoReducir alcance y definir intervención antes de actuar
Relevantes para otras personas, recursos o compromisosExigir condiciones explícitas y decidir qué revisión previa correspondeMantener la decisión en una persona autorizada o no ejecutar
Consecuencias de la acción
Acotadas dentro del trabajo previsto
Corrección viable y comprobable
Valorar una delegación limitada, con comprobación del resultado
Consecuencias de la acción
Acotadas dentro del trabajo previsto
Corrección difícil, parcial o incierta
Reducir alcance y definir intervención antes de actuar
Consecuencias de la acción
Relevantes para otras personas, recursos o compromisos
Corrección viable y comprobable
Exigir condiciones explícitas y decidir qué revisión previa corresponde
Consecuencias de la acción
Relevantes para otras personas, recursos o compromisos
Corrección difícil, parcial o incierta
Mantener la decisión en una persona autorizada o no ejecutar

Matriz orientativa para discutir el alcance. La reversibilidad no autoriza una acción por sí sola: también importan los permisos, la información disponible y la acumulación de efectos.

La matriz cruza consecuencias acotadas o relevantes con corrección viable o difícil. Propone desde valorar delegación limitada hasta mantener la decisión en una persona autorizada o no ejecutar. Ninguna celda sustituye a la política concreta de la organización.

Los permisos ejecutan una parte de la política

Los permisos técnicos definen qué recursos están disponibles y qué operaciones acepta una herramienta. Son necesarios para hacer efectivos ciertos límites, pero no expresan por sí solos toda la delegación.

Una credencial puede permitir modificar un conjunto de registros mientras el encargo solo autoriza trabajar sobre una selección concreta. Una herramienta puede admitir una operación válida desde el punto de vista de su API y, aun así, resultar inadecuada para la situación actual.

OWASP identifica el exceso de funciones, permisos y autonomía como dimensiones distintas de la agencia excesiva. Recomienda limitar las capacidades disponibles y aplicar autorización en los sistemas que reciben las acciones, sin confiar esa decisión únicamente al modelo.

La implicación arquitectónica es que una instrucción y un control tienen funciones diferentes. La instrucción ayuda al agente a proponer un comportamiento adecuado. El control determina si una acción concreta puede ejecutarse en las condiciones presentes.

Ese control puede necesitar conocer el recurso afectado, la identidad en cuyo nombre se actúa y el alcance del encargo. No basta con comprobar que la herramienta pertenece a una lista permitida si sus parámetros cambian sustancialmente el efecto de la operación.

Tampoco conviene construir una única barrera abstracta para toda la autonomía. Algunos límites pertenecen a los permisos de acceso; otros, a las reglas del proceso; otros, a una decisión humana. Identificar dónde se aplica cada uno permite comprobarlo y evita que la misma obligación quede asumida por todos y resuelta por nadie.

Aprobar requiere poder decidir

La revisión humana puede conservar una decisión importante dentro de la organización. Para que lo haga, debe presentar un objeto de aprobación comprensible: qué acción se propone, sobre qué elementos y con qué efectos esperados.

Un botón de confirmación no crea ese contexto. Si la persona solo ve una explicación convincente, pero no puede contrastar los cambios relevantes, su intervención puede terminar validando la forma de la propuesta más que su contenido.

El revisor necesita autoridad para decidir y una alternativa real a aceptar. Debe poder rechazar, pedir información o devolver el trabajo sin romper el flujo. Si la presión operativa convierte cada rechazo en una incidencia, el sistema incentiva una aprobación que apenas tiene significado.

También importa qué cubre exactamente la decisión. Aprobar una propuesta no equivale a autorizar cualquier variación posterior. Cuando cambian el destino, el importe, el alcance o las condiciones relevantes, la aplicación debe determinar si la autorización sigue siendo válida.

La revisión tiene un coste que debe formar parte del diseño. Pedir confirmación de demasiadas acciones puede saturar a quien revisa y diluir la atención sobre las que realmente la necesitan. La frecuencia de intervención debe responder a las consecuencias y a la calidad de la información presentada.

Una delegación bien delimitada puede reducir revisiones innecesarias sin eliminar la responsabilidad humana. El objetivo es que la persona intervenga donde su decisión añade criterio o asume un compromiso que el sistema no debe tomar por sí solo.

La autorización tiene condiciones y duración

Una decisión puede ser válida en un momento y dejar de serlo después. Cambia el objeto sobre el que se iba a actuar, se retira una solicitud o aparece información que altera el sentido de la operación.

Por tanto, la autorización necesita una relación con las condiciones que la justificaron. Si el agente prepara una acción, espera y la ejecuta más tarde, el sistema debe saber qué hechos relevantes podrían haber cambiado durante esa espera.

No todas las operaciones necesitan bloquear recursos ni aplicar el mismo mecanismo de concurrencia. Sí necesitan una política sobre información desactualizada. En algunos casos bastará una nueva lectura; en otros habrá que comparar una versión o solicitar otra decisión.

Los límites de duración también ayudan a evitar encargos indefinidos. Un agente no debería conservar un mandato únicamente porque nadie recuerde cerrarlo. El trabajo puede terminar, caducar o quedar suspendido, y cada situación debe tener consecuencias reconocibles sobre lo que puede seguir haciendo.

Algo parecido ocurre con la ampliación del alcance. Si aparece una tarea relacionada, el agente puede proponer incorporarla, pero su proximidad al objetivo original no la convierte automáticamente en parte del encargo. El sistema necesita distinguir una continuación prevista de una delegación nueva.

La autonomía se vuelve más clara cuando las condiciones son observables. En lugar de exigir al agente que interprete si «todavía tiene sentido», la organización puede identificar qué cambios obligan a revisar el mandato. Eso facilita tanto la ejecución como la explicación posterior.

Retirar autoridad también forma parte del diseño

Poder conceder autonomía sin poder retirarla deja incompleta la delegación. La organización necesita una forma de detener nuevas acciones y conocer qué trabajo permanece en curso cuando toma esa decisión.

Retirar un permiso no equivale necesariamente a cancelar todas las operaciones ya aceptadas por otros sistemas. Algunas pueden haber terminado; otras pueden seguir ejecutándose. La respuesta exige identificar sus estados, no asumir que la interrupción del agente ha deshecho sus efectos.

Incluso los mecanismos técnicos de revocación tienen condiciones de funcionamiento. La RFC 7009 sobre revocación de tokens OAuth reconoce la posibilidad de demoras de propagación entre servidores. No es una razón para prescindir de la revocación, sino para conocer qué alcance tiene en la arquitectura utilizada.

El diseño debería distinguir tres preguntas: qué nuevas acciones quedan impedidas, qué operaciones requieren seguimiento y qué efectos necesitan corrección. Resolver una no demuestra que las otras estén resueltas.

También hace falta asignar quién puede ordenar la retirada y quién se hace cargo de sus consecuencias. Un control de parada que nadie sabe utilizar, o cuyo efecto nadie puede comprobar, ofrece una capacidad técnica sin una respuesta operativa completa.

La revocación no debe reservarse para un incidente grave. Puede formar parte de una decisión normal: termina el encargo, cambia la política o se reduce temporalmente el alcance. Tratarla como una operación prevista permite mantener el sistema sin que cada ajuste de autoridad se convierta en una excepción improvisada.

La autonomía necesita una justificación que se mantenga

El alcance inicial de un agente se decide con evidencia limitada. Después de observar su funcionamiento, la organización puede ampliarlo, mantenerlo o reducirlo. Ninguna de esas opciones debería depender exclusivamente de la confianza que transmite una demostración.

Para ampliar autoridad interesa saber qué clases de trabajo resuelve y dónde necesita intervención. También qué errores se detectan antes de producir efectos, cuáles llegan a otros sistemas y cuánto esfuerzo exige recuperarlos. La calidad del resultado y la capacidad de supervisión deben examinarse juntas.

La ausencia de incidentes no demuestra por sí sola que una frontera más amplia sea adecuada. Puede que no se hayan presentado todavía las condiciones que la pondrían a prueba. La decisión requiere relacionar la evidencia disponible con las consecuencias del nuevo alcance.

Tampoco toda limitación es definitiva. Una integración mejor, una comprobación adicional o una definición más precisa pueden hacer viable una delegación que antes no lo era. La autonomía puede crecer como resultado de un diseño más sólido, además de una mejora del modelo.

Su límite debería quedar allí donde la organización deja de poder explicar qué ha delegado, con qué condiciones y cómo conserva el control sobre sus efectos. Ese criterio permite aprovechar la capacidad del agente sin convertir su iniciativa en una fuente de autoridad propia.

KEY TAKEAWAY

La autonomía debe delimitarse por acciones, consecuencias y condiciones de operación. Una delegación defendible identifica qué puede decidir el agente, cuándo necesita intervención y cómo se retira su autoridad. Ampliar ese alcance requiere evidencia sobre el trabajo y sobre la capacidad de la organización para supervisar y corregir sus efectos.

XENDAI CONNECTION

Xendai define el alcance de los agentes junto con las condiciones que lo hacen operativo: qué pueden decidir, qué acciones requieren revisión y cómo se detienen o se retira su autoridad. Esa delegación forma parte de la arquitectura y de la responsabilidad sobre el sistema.