Un agente que solo sabe continuar no es autónomo. Es una tarea en ejecución buscando a alguien que tire del enchufe.
TL;DR
Enseñar a un agente a ejecutar una tarea sin definir su condición de parada delega riesgo, no trabajo. Un sistema útil debe saber qué resultado completa la tarea, cuánto tiempo, costo y alcance puede consumir, qué acciones exigen autoridad humana y qué hacer cuando la evidencia es insuficiente o el mismo error se repite. Detenerse no es fallar: puede ser concluir, pedir una decisión, rechazar una acción fuera de su autoridad o volver a un estado seguro. La autonomía responsable no se mide por la cantidad de pasos que la máquina dio sola. Se mide por cuánto puede hacer sin cruzar una frontera que debería seguir siendo humana.
Existe una costumbre un poco infantil de medir a un agente por lo dispuesto que parece.
Investiga. Abre pestañas. Llama herramientas. Crea archivos. Intenta otra vez. Llama otra herramienta. Cuando los intentos fallan sin aportar evidencia nueva ni cambiar las condiciones del problema, hace lo que hacen muchos sistemas cuando nadie les enseñó lo contrario: sigue ejecutando.
En una demostración, eso parece autonomía.
En la operación, puede ser una forma cara de no saber terminar.
Un agente necesita más que una lista de cosas que puede hacer. Necesita un contrato de parada: las condiciones en las que debe concluir, pausar, pedir una decisión, rechazar una acción o retroceder.
Sin eso, “sé proactivo” se convierte en el equivalente técnico de entregarle a alguien un taladro y salir de la habitación antes de explicar por dónde pasan las tuberías.
Ejecutar es solo la mitad del verbo
Una automatización determinista suele tener un final razonable: recibe la entrada, aplica la regla y produce una salida. Si una condición no se cumple, falla e informa el error —o debería hacerlo.
Un agente tiene más margen para elegir su siguiente paso. Puede investigar, comparar fuentes, consultar un sistema, preparar un borrador o coordinar otras tareas. Ese margen es justamente lo que lo hace útil en trabajos menos lineales.
También es lo que vuelve insuficiente decir solo: “resuelve esto”.
¿Resolver qué, exactamente? ¿Hasta dónde? ¿Con qué fuentes? ¿En cuánto tiempo? ¿Con qué costo? ¿Qué cuenta como una respuesta aceptable? ¿Quién decide cuándo una excepción supera la autoridad del sistema?
El Marco de Gestión de Riesgos de IA del NIST trata el riesgo como algo dependiente del contexto de uso y señala que la tolerancia al riesgo no la prescribe el documento: debe definirla quien responde por el sistema. Es una estructura voluntaria, no una receta lista para agentes. Pero coloca la pregunta en el lugar correcto: el límite no nace del modelo. Nace de la consecuencia que una operación acepta o no acepta.
Una buena condición de parada convierte esa consecuencia en comportamiento observable.
Cuatro formas correctas de detenerse
Detenerse no significa que toda tarea termina con un error rojo y que alguien pierde la tarde. Un agente bien diseñado puede llegar a cuatro finales legítimos:
- Concluir: entregó un resultado que satisface los criterios de aceptación definidos antes. Los criterios de aceptación son condiciones verificables que separan “parece listo” de “está listo para este uso”.
- Escalar: encontró una decisión que requiere a alguien con autoridad, contexto de negocio o responsabilidad que el sistema no tiene.
- Abstenerse: no hay evidencia suficiente para una recomendación confiable, las fuentes divergen o la tarea pide una afirmación que no puede sostener.
- Retroceder: hubo falla, repetición improductiva o riesgo por encima del límite; el sistema interrumpe el intento y conserva o restaura un estado seguro cuando es posible.
El problema no es que un agente llegue al segundo, tercer o cuarto final.
El problema es ocultarlos porque una presentación comercial prefiere fingir que cada ruta termina en “hecho”.
Un límite no es un único botón rojo gigante
Cuando alguien habla de limitar un agente, mucha gente imagina un único freno de emergencia. Es necesario en algunos contextos, pero no resuelve todo el problema por sí solo.
Una autonomía sana suele tener límites en capas:
| Límite | Pregunta que responde | Ejemplo práctico |
|---|---|---|
| Tiempo | ¿Cuánto puede durar una tarea antes de perder valor? | Interrumpir una investigación después de 20 minutos sin fuente suficiente y devolver la brecha. |
| Costo | ¿Cuánto recurso puede consumir este beneficio? | Cerrar una cadena de consultas antes de convertir una respuesta simple en una pequeña auditoría financiera. |
| Alcance | ¿Qué sistemas, datos y acciones pertenecen a esta tarea? | Consultar el sistema de gestión de relaciones con clientes (CRM) para preparar una respuesta, pero no modificar un registro ni enviar un mensaje. |
| Autoridad | ¿Qué puede hacer el sistema solo y qué solo puede recomendar? | Preparar un pago; nunca aprobarlo ni ejecutarlo sin la persona responsable. |
| Repetición | ¿Cuándo los intentos idénticos dejan de ser persistencia y se vuelven un ciclo de intentos sin avance (bucle)? | Detenerse tras dos fallas de la misma integración y abrir un incidente con contexto. |
| Irreversibilidad | ¿Qué acción no se puede deshacer con seguridad? | Pedir aprobación antes de borrar datos, revocar acceso, publicar o comunicar algo externamente. |
Esto no es burocracia puesta encima de la IA para arruinar la diversión.
Reduce el riesgo de enviar un correo equivocado a cinco mil personas cuando una instrucción ambigua como “limpiar la base” se ejecuta sin revisión.
Escalar no es transferir cada decisión a un humano cansado
También existe el extremo opuesto: un “agente” que pide aprobación para cada clic y llama a eso seguridad. Si alguien debe confirmar cada consulta, clasificación y frase de un borrador, no ganó capacidad. Convirtió cada acción de bajo impacto en un cuello de botella de aprobación.
La cuestión es delimitar la frontera correcta.
Una tarea de bajo impacto puede terminar automáticamente cuando las entradas están completas, la fuente está definida y los criterios son claros. Una tarea con impacto financiero, jurídico, reputacional o humano necesita pasos adicionales de revisión. Entre ambos polos existe un campo enorme de recomendaciones, borradores, simulaciones y acciones reversibles que pueden aliviar trabajo sin fingir que la responsabilidad se evaporó.
La guía de seguridad de agentes de OpenAI recomienda combinar controles en capas y conservar supervisión humana para acciones de mayor impacto. Es orientación del proveedor sobre sus propios recursos, no una certificación de que cualquier flujo construido con ellos sea seguro. Pero el principio es más amplio que una plataforma: la revisión humana debe estar donde cambia la consecuencia, no servir como sello decorativo al final.
Prefiero formular la regla así:
El agente puede avanzar mientras la consecuencia permanezca dentro de la autoridad que recibió y la evidencia siga siendo suficiente. Cuando una de las dos deje de ser verdad, devuelve la decisión con contexto.
Devolverla con contexto importa. “No pude hacerlo” es un aviso. “No pude hacerlo porque dos fuentes oficiales divergen; probé estas consultas, descarté estas alternativas y necesito que elijas entre A y B” es un relevo.
Evidencia terminal: el recibo de que la tarea terminó
En sistemas más complejos, la respuesta final no debería ser solo una frase agradable diciendo que todo se resolvió. Debe dejar un registro terminal: la evidencia mínima de que la tarea acabó, de qué manera acabó y qué quedó pendiente.
Para cada ejecución relevante, quiero poder responder:
- qué objetivo recibió;
- qué fuentes, herramientas y permisos utilizó;
- qué criterio de aceptación se cumplió —o cuál no—;
- qué acción se tomó, por quién y bajo qué autorización;
- qué incertidumbre, excepción o riesgo residual permaneció;
- cómo volver atrás cuando hubo un cambio reversible;
- quién debe decidir el siguiente paso cuando el resultado fue escalado.
No hace falta registrar cada pensamiento intermedio, y menos aún arrojar datos sensibles a un registro de eventos (log). Un registro útil no es voyeurismo de máquina. Es trazabilidad suficiente para comprobar una decisión, corregir el flujo y no tener que reconstruir un incidente mediante arqueología digital.
Esa es la diferencia entre un agente que parece ocupado y un sistema que puede operarse después de que quien lo configuró se vaya de vacaciones.
Las acciones irreversibles merecen una frontera explícita
Hay acciones que se pueden deshacer sin drama: guardar un borrador, crear una tarea interna, producir una simulación, marcar una divergencia para revisión.
Hay otras que se propagan por el mundo antes de que alguien pueda pedir disculpas: publicar un comunicado, borrar datos, cambiar permisos, enviar un cobro, cerrar una cuenta o asumir un compromiso en nombre de otra persona.
No basta con escribir “ten cuidado” en la instrucción que orienta al sistema (prompt). El cuidado es una cualidad humana admirable; como control operativo, es gelatina conceptual.
La frontera debe aparecer en la arquitectura: herramientas separadas, permisos mínimos, entorno de pruebas, confirmación humana cuando haya impacto material y un camino de retorno cuando exista. En el artículo sobre agentes genéricos, expliqué que una demostración casi siempre omite excepciones, fuente de verdad y responsable de la decisión. La condición de parada es donde esas tres omisiones finalmente pasan la factura.
El agente no necesita ser “menos inteligente” para aceptar una frontera.
Solo necesita estar menos irresponsablemente suelto.
Repetir un error no es perseverancia
Otra señal clásica de un contrato mal escrito es el bucle que cambia de ropa con cada intento.
Una integración devuelve un error. El agente intenta otra vez. El error vuelve. Cambia un parámetro aleatorio, intenta otra vez, llama otra herramienta, repite la misma operación y al final produce un informe de doscientas líneas explicando que trabajó mucho.
La persistencia es útil cuando el siguiente intento trae información nueva: se renovó una credencial, volvió una dependencia, apareció una fuente adicional o una persona resolvió una ambigüedad.
Sin cambio de condición, repetir es solo automatizar la terquedad.
Por eso el contrato debe declarar qué cuenta como un intento diferente, qué error termina la operación de inmediato y cuándo el patrón exige escalamiento. Esto se conecta con lo que escribí en “Escribiste, no leíste: la IA no firma por ti”: una salida fluida no termina la responsabilidad. Del mismo modo, una secuencia larga de acciones no prueba progreso.
El rollback empieza antes del error
Rollback es el nombre técnico para volver a un estado anterior conocido cuando un cambio falla o produce una consecuencia no deseada. Pero no aparece por magia después del problema.
Para revertir algo, necesitas haber preservado estado, identificadores, permisos y una ruta probada antes de necesitarla. Por eso una copia de recuperación (backup), versión, aprobación y límite de acción pertenecen a la misma conversación.
En el artículo sobre limpieza operativa, la pregunta era cuándo una automatización puede borrar. Aquí es anterior: ¿cuándo puede un agente cambiar algo sabiendo que quizá tendrá que deshacerlo?
Las dos preguntas tienen la misma respuesta incómoda: no cuando el modelo parece seguro, sino cuando la operación sabe qué protege y cómo recupera.
Autonomía que cabe en una empresa real
No quiero agentes reducidos a asistentes decorativos que piden permiso hasta para respirar. Tampoco quiero una máquina suelta, con demasiado acceso y una instrucción optimista de “haz lo que sea necesario”. Entre esos dos personajes existe ingeniería.
Un agente puede ser muy útil para investigar opciones, consolidar información, encontrar inconsistencias, preparar decisiones, ejecutar acciones reversibles y organizar trabajo. En muchas situaciones, eso libera a las personas para lo que exige negociación, contexto humano, responsabilidad, lectura de consecuencias y dirección.
Pero autonomía no es la cantidad de tareas que abandonaste en manos de un sistema.
Es la calidad del límite que conseguiste diseñar.
En i-9.ai, eso empieza antes de elegir modelo o herramienta: entender la tarea, las fuentes, el impacto, la autoridad, los criterios de aceptación y qué debe ocurrir cuando la realidad se sale del guion. Después viene la arquitectura. Y solo entonces, la autonomía que una empresa realmente puede sostener.
Si tu empresa está discutiendo qué podría hacer un agente, empieza por una pregunta menos simpática y mucho más útil: ¿en qué situación debe detenerse?
Para profundizar
- NIST AI Risk Management Framework 1.0: estructura voluntaria para mapear, medir, gobernar y gestionar riesgo de IA; sustenta la importancia del contexto, la tolerancia al riesgo y la responsabilidad, pero no prescribe un único diseño de agente.
- OpenAI — Safety in building agents: guía técnica sobre guardrails, límites de herramientas y supervisión humana en flujos de agentes; es documentación de proveedor, no validación independiente de una implementación.
- NIST — AI RMF Playbook: ejemplos operativos asociados al marco; sirve como repertorio de preguntas, no sustituye la definición de autoridad y riesgo de una organización.
- Common Weakness Enumeration — CWE-636: referencia para el principio de fallar de forma segura; aplicarlo a agentes en este artículo es una síntesis operativa, no una regla exclusiva de IA.
Referencias y límites de uso
- El NIST sustenta que riesgo, impacto y tolerancia dependen del contexto y que la gobernanza atraviesa el ciclo de vida. No define el límite correcto de costo, tiempo o aprobación para una empresa específica.
- La documentación de OpenAI sustenta controles en capas e intervención humana para acciones de mayor impacto. No garantiza que los guardrails eliminen error, abuso o consecuencias inesperadas.
- CWE-636 sustenta la idea general de que una falla no debe llevar un sistema a un estado menos seguro. Traducirla como “detenerse y escalar cuando falta evidencia” es la interpretación operativa defendida aquí.
Conversación abierta
Continúa la conversación
¿No estás de acuerdo, encontraste una laguna o tienes una experiencia que amplía el tema? Comenta con tu cuenta de GitHub. No publiques datos personales, credenciales ni información sensible.