Saltar al contenido
Volver al blog

La autonomía es una firma en blanco

Cada grado de autonomía que le concedes a un agente de IA es una restricción que le quitas, y la arquitectura, siguiendo a Gregor Hohpe, es la disciplina de satisfacer restricciones, no de eliminarlas. Este ensayo sostiene que la autonomía funciona como un poder de firma delegado: un límite de aprobación que se fija antes de la transacción, crece con el historial demostrado y vive en el límite, no en revisar cada movimiento después. El trabajo del arquitecto no es maximizar la autonomía del agente, sino calibrar ese límite, porque la autonomía se concede barata y se recupera cara.

La palabra que más se repite en las demos de agentes es «autónomo», y casi siempre se dice como un elogio: mira, decide solo, no hay que aprobarle nada. Pero autonomía no es una virtud que el agente tenga; es una restricción que tú le quitaste. Cada tarea que un agente puede hacer sin pedir permiso es un permiso que dejaste de pedirle, y cuando lo dices así, en voz alta, deja de sonar a logro y empieza a sonar a decisión de arquitectura. Que es exactamente lo que es.

Este ensayo parte del argumento que Gregor Hohpe plantea cuando dice que la arquitectura es un juego de satisfacer restricciones: el progreso técnico va levantando límites que antes dábamos por fijos, y cada vez que uno cae hay que recalibrar las heurísticas que dependían de él. Hohpe lo dice de las restricciones técnicas. Yo quiero aplicarlo a una restricción que no es técnica sino de autoridad: cuánto puede hacer un agente sin que un humano firme. Y quiero añadir algo que su argumento no dice, porque no tenía por qué: que una restricción pueda quitarse no significa que convenga quitarla. A veces el arquitecto vuelve a ponerla, a propósito, con otro nombre.

La autonomía es un poder de firma que delegas

Cuando entra alguien nuevo a una empresa, nadie le da una chequera sin límite el primer día. Se le asigna un poder de firma: puede aprobar gastos hasta cierta cantidad sin consultar, y por encima de esa cantidad necesita a alguien más. El límite se fija antes de la primera transacción, no después de revisar sus compras. Sube con el historial: a los dos años, con un track record limpio, ese límite es más alto. Y el control no está en revisar cada factura una por una (eso no escala y todos lo saben), está en el número. En el límite mismo.

Un agente de IA es exactamente eso: una figura a la que le delegas poder de firma. «Puede abrir un pull request pero no mergearlo» es un límite de aprobación. «Puede desplegar a staging pero no a producción» es otro. «Puede tocar la base de datos de lectura pero no ejecutar migraciones» es otro más. Cuando alguien dice que quiere un agente «más autónomo», lo que está pidiendo es subirle el límite de firma. Y ese es el punto: no estás mejorando al agente, estás firmando en su nombre por adelantado, sin saber todavía qué va a firmar.

La metáfora aguanta la prueba que el propio Hohpe exige en The Mighty Metaphor: no basta con que la imagen se parezca, tienen que coincidir las dinámicas. Y coinciden en lo que importa. Un poder de firma se concede barato: es cambiar un número, marcar una casilla, ampliar un rol de IAM. Se recupera caro: cuando descubres que el límite estaba demasiado alto, ya hay transacciones firmadas con ese poder, y deshacerlas cuesta mucho más que haberlas evitado. La asimetría entre conceder y recuperar es la misma en los dos lados, y es de ahí de donde sale todo lo demás.

Dos modelos de control puestos lado a lado. A la izquierda, revisar cada acción del agente después de que ocurre: una fila de acciones ya ejecutadas con un humano intentando revisarlas una por una y quedándose atrás. A la derecha, fijar el límite de aprobación antes: una sola compuerta configurada por adelantado por la que las acciones pasan solas mientras estén dentro del límite.

Revisar cada acción después no escala; fijar el límite antes sí. El control se muda del final al principio.

Por qué el control tiene que estar en el límite y no en la revisión

Si tuvieras que aprobar cada movimiento del empleado nuevo, no le habrías dado un poder de firma: le habrías dado un formulario. El poder de firma existe precisamente para no tener que mirar cada transacción, y a cambio pone toda la responsabilidad en un sitio: acertar con el número, antes.

Con agentes esto no es una preferencia, es física. Un humano revisa un puñado de acciones por hora con atención de verdad; un agente ejecuta cientos. Revisar cada acción después de que ocurre es la estrategia que garantiza quedarte atrás, porque el agente produce más rápido de lo que tú puedes leer, igual que ya argumenté en El código es inventario, no un activo: ahí el cuello de botella era entender el volumen; aquí es contener el alcance. Son dos problemas distintos del mismo agente. Uno es cuánto produce; este es hasta dónde llega lo que produce.

Por eso el sitio donde se pone el límite no es el código que el agente escribe, sino la frontera que el agente no puede cruzar. Una plataforma como Amazon Bedrock AgentCore existe para eso: identidad, permisos y guardrails que se definen antes de que el agente actúe, no controles que revisan lo que ya hizo. Y el flujo dirigido por especificaciones de Kiro hace lo mismo desde el otro extremo: la spec es la frontera, el contrato que dice qué está dentro del poder de firma y qué queda fuera. En los dos casos, el trabajo del arquitecto pasó de vigilar a calibrar. De revisar facturas a fijar el número.

Sé lo que estás a punto de decir

Pero un agente con más autonomía entrega más rápido. Cada aprobación que le quito es fricción que le quito, y la fricción es lo que estoy pagando por eliminar.

Es verdad a corto plazo, y es la trampa entera. Subir el límite de firma siempre acelera hasta el día que no. El empleado con poder ilimitado también cierra tratos más rápido, hasta que firma uno que hunde el trimestre; y entonces la velocidad que ganaste durante meses se la come una sola transacción que nunca debió tener permiso de existir. Lo que compras al ampliar la autonomía no es velocidad, es velocidad más una cola de riesgo que no ves hasta que se materializa.

Y hay una asimetría que la prisa esconde. Cuando el límite es demasiado bajo, el costo es visible y acotado: el agente se detiene, alguien aprueba a mano, pierdes minutos. Cuando el límite es demasiado alto, el costo es invisible hasta que llega, y entonces no es acotado: es todo lo que el agente pudo tocar mientras nadie miraba. Un límite conservador falla en pequeño y en voz alta; un límite generoso falla en grande y en silencio. No son dos errores simétricos que puedas promediar.

La autonomía no es una capacidad que le das al agente: es una restricción que te quitas a ti, y te la vas a querer devolver el día que menos te convenga.

Meme de los dos botones: alguien sudando frente a dos botones, uno rotulado «AGENTE SIN NINGUNA AUTONOMÍA» y otro «AGENTE CON AUTONOMÍA TOTAL», como si hubiera que elegir entre los dos.

Entonces, ¿cuánto cuesta equivocarse con el número?

Pongamos una cuenta, con los supuestos a la vista para que la rehagas con los tuyos. No es la medición de un cliente real; es aritmética para pensar, de las que hace este blog.

Supón un agente que ejecuta 200 acciones al día. Si le fijas un límite bajo, digamos que el 10% de esas acciones caen fuera y necesitan una aprobación humana, cada una cuesta unos 3 minutos de alguien: 20 acciones por 3 minutos son 60 minutos al día de fricción. Molesto, medible, y toda la factura llega hoy.

Ahora súbele el límite hasta que solo el 1% necesite aprobación: 2 acciones al día, 6 minutos. Ganaste casi una hora diaria. Pero ampliaste el alcance de las otras 198 acciones que ahora pasan solas. Basta con que una de esas, en todo un trimestre, sea una que no debió pasar (un borrado, un permiso abierto de más, un gasto que se dispara) para que el costo de contenerla y revertirla se coma con holgura las casi 60 horas que ahorraste en esos tres meses. La cuenta no es «cuánto ahorro en fricción»; es «cuánto ahorro en fricción menos el alcance del peor caso que acabo de habilitar». El segundo término es el que nadie pone en la servilleta, y es el que decide.

Los números son inventados y el tuyo será otro. Lo que no cambia es la forma de la cuenta: el ahorro es lineal y visible, el riesgo es de cola y silencioso, y calibrar el límite es elegir conscientemente dónde cortar entre los dos. Maximizar la autonomía es fijar ese corte en «no lo pienso».

Mi sugerencia

El lunes, lleva una sola pregunta a tu próxima revisión de arquitectura, una por cada agente que ya tengan corriendo: ¿cuál es su límite de aprobación exacto, y quién lo fijó? No vale «tiene los permisos que necesita»; eso es la respuesta de quien no fijó ningún número. Que alguien diga la frontera concreta —hasta dónde puede llegar sin firma humana— y quién decidió que fuera ahí. Si nadie sabe el número, no es que el agente sea muy autónomo: es que le firmaste un cheque en blanco y todavía no ha llegado a cobrarlo.

Y si quieres algo más concreto todavía, haz el ejercicio al revés durante un sprint: parte del límite más bajo con el que el agente sigue siendo útil y súbelo solo cuando el historial lo justifique, como el poder de firma del empleado que lleva dos años sin un tropiezo. Es más lento de arrancar y mucho más barato de sostener. Al fin y al cabo, si de verdad confías en que el límite alto es seguro, ponerlo bajo primero y verlo ganárselo no debería costarte nada. ;)

Referencias

  1. Architecture as constraint satisfaction — Gregor Hohpe
  2. The Mighty Metaphor — Gregor Hohpe
  3. Amazon Bedrock AgentCore — AWS
  4. Kiro — desarrollo dirigido por especificaciones
  5. The Architect Elevator — Gregor Hohpe