Escalera de autonomía
Marco del I.D.A. que decide, tarea por tarea, qué puede hacer la IA por su cuenta y qué necesita que una persona lo apruebe. La autonomía se da por niveles: poca al principio y más a medida que el agente demuestra que acierta.
En una analogía · Es el carné por puntos del agente: empieza haciendo cositas supervisadas y va ganando permiso para más a medida que demuestra que no choca.
El mecanismo: niveles con criterio de ascenso
No tiene sentido dar todo el control a un agente desde el primer día, ni revisar cada cosa que hace para siempre. La escalera fija, por TIPO de tarea, uno de cuatro niveles, y sobre todo fija el criterio para subir:
| Nivel | Qué hace el agente | Quién firma | Sube cuando… |
|---|---|---|---|
| 0 · Ni lo toca | Nada | La persona | (no aplica) |
| 1 · Propone | Borrador que alguien revisa entero | La persona | 20 tareas seguidas sin corrección de fondo |
| 2 · Ejecuta con revisión | Hace y se revisa por muestreo | Persona, a posteriori | Tasa de rechazo del muestreo < 5% un mes |
| 3 · Autónomo con guardrails | Hace y publica; los límites los vigila la máquina | El sistema | Nunca del todo: este es el techo |
El detalle que separa esto de una buena intención: los umbrales de ascenso se escriben antes de empezar, no se negocian cuando el agente ya trabaja. Y bajar de nivel es automático si el criterio deja de cumplirse.
Un ejemplo real
Así se ve una escalera en un archivo del sistema, no en la cabeza de nadie:
# autonomia.yaml · quién puede hacer qué, y con qué prueba
generar-variante-componente:
nivel: 2
criterio_ascenso: "rechazo < 5% en muestreo mensual"
guardrails: [solo-tokens-del-sistema, sin-css-inline]
publicar-parte-diario:
nivel: 3
guardrails: [verdict != REVISAR, confianza >= 80, sin-personas]
tocar-tokens-primitivos:
nivel: 0 # el vocabulario raíz no se delega
El propio site del Instituto opera así: el cron de El Parte tiene nivel 3 para noticias (con verificador y umbral de confianza como guardrails) y nivel 0 para perfiles de personas, que exigen firma humana siempre.
Cómo se construye, en tres pasos
- Inventaría las tareas que el agente hace o hará (no roles: tareas). Un design system suele tener entre 10 y 20.
- Asigna nivel inicial 1 a todo salvo lo irreversible (nivel 0). La tentación de empezar en 2 es la fuente clásica de incidentes.
- Escribe el criterio de ascenso de cada tarea como un número medible (tasa de rechazo, correcciones por semana). Si no puedes medirlo, la tarea se queda donde está.
La guía Cuatro controles del output agéntico cubre cómo medir ese criterio; los límites de cada nivel se implementan como contratos y guardrails.
Lecturas de referencia
A seguir
Marco propio del Instituto de Diseño Agéntico, no un estándar del sector.
Seguir leyendo
- GuíaFigma MCP para design systems: el circuito diseño-código sin handoffQué expone el servidor MCP de Figma, cómo lo consume un agente como Claude Code o Cursor, y qué tiene que tener tu design system para que el circuito funcione de verdad.
- GuíaCómo se implementa un MCP server para tu design systemAnatomía mínima de un servidor Model Context Protocol que expone los tokens, principios y componentes de tu sistema a un cliente agéntico.
- El ParteAgent Plugins estandarizaAgent Plugins 1.0.0 es una iniciativa que busca estandarizar la forma en que se empacan y distribuyen habilidades de agentes y servidores MCP
Recibe la próxima guía en tu correo
Una guía operativa nueva cada poco: cómo se construye, qué decisiones implica y qué no se hace. Sin ruido, solo cuando hay algo útil.