Humano en el circuito: niveles de autonomía para agentes en producción

La discusión sobre agentes de IA en operaciones suele plantearse como una elección binaria: o el agente actúa solo, o un humano revisa todo. Las dos posiciones fallan. La autonomía total sin evidencia previa es un riesgo que ningún responsable de operaciones en un sector regulado debería aceptar. La revisión humana de cada paso, en cambio, convierte al agente en una fuente más de alertas y elimina buena parte de su valor.

La alternativa es tratar la autonomía como una escala graduada y asignarla por caso de uso, no por agente. Un mismo agente puede actuar solo para reiniciar un servicio de pruebas y limitarse a recomendar cuando se trata de una base de datos de producción. Este artículo propone una escala concreta, los criterios para moverse en ella y los controles que hacen falta en cada nivel.

Una escala de cuatro niveles

Proponemos cuatro niveles. Lo importante no es el nombre, sino que cada uno defina con claridad quién decide y quién ejecuta.

1. Observar. El agente lee datos, correlaciona y resume. No sugiere acciones ni toca sistemas. Ejemplo: un resumen del estado de un incidente con las señales relevantes.
2. Recomendar. El agente propone una acción concreta, con la evidencia y el razonamiento que la sostienen. Una persona decide y ejecuta por su cuenta.
3. Actuar con aprobación. El agente prepara la acción lista para ejecutar y la ejecuta solo cuando una persona autorizada la aprueba explícitamente. La aprobación queda registrada.
4. Actuar dentro de límites e informar. El agente ejecuta sin aprobación previa, pero solo dentro de límites definidos de antemano (tipo de acción, sistemas, horario, cantidad), e informa lo que hizo. Fuera de esos límites vuelve al nivel 3.

El nivel 4 no es "autonomía total". Es autonomía acotada, con un perímetro explícito y revisión posterior. En operaciones reguladas recomendamos no definir un nivel por encima de este.

Si quieres el contexto general sobre qué hacen estos agentes, lo cubrimos en agentes de IA en la operación de TI.

Criterios para subir un caso de uso de nivel

Todo caso de uso empieza en el nivel 1 o 2. Subirlo de nivel es una decisión que se toma con evidencia, no por entusiasmo. Recomendamos evaluar cuatro criterios:

Historial de precisión

Antes de dejar que el agente ejecute, hay que saber con qué frecuencia acierta. En el nivel 2 esto se mide directamente: cuántas recomendaciones aceptaron las personas sin cambios, cuántas corrigieron y cuántas descartaron. El umbral exacto depende del caso, pero debe fijarse antes de empezar a medir, no después de ver los resultados. También importa el volumen: unas pocas recomendaciones correctas no son un historial.

Radio de impacto

Qué es lo peor que puede pasar si el agente se equivoca. Un error que afecta a un contenedor de desarrollo no se compara con uno que afecta a la plataforma de pagos. Conviene expresarlo en términos concretos: cuántos servicios, cuántos usuarios, qué procesos de negocio.

Reversibilidad

Una acción que se deshace en segundos y sin pérdida de datos admite más autonomía que una que no se puede revertir. Reiniciar un proceso es reversible; borrar datos, rotar una clave compartida o modificar un compromiso de compra no lo son, al menos no en el corto plazo.

Impacto regulatorio

Si la acción afecta datos personales, controles de seguridad, registros que se usan en auditorías o la relación con clientes, el nivel máximo lo define también Cumplimiento, no solo Operaciones. En estos casos, aunque el historial técnico sea bueno, puede ser obligatorio mantener la aprobación humana.

La regla práctica: un caso de uso sube de nivel solo cuando los cuatro criterios lo permiten. Y baja de nivel de forma automática ante un error relevante, hasta que se analice la causa.

Tareas de ejemplo y nivel recomendado

La siguiente tabla es una orientación de partida para una organización regulada. Cada organización debe ajustarla según su arquitectura, su apetito de riesgo y sus obligaciones.

Tarea	Nivel recomendado	Motivo principal
Resumir un incidente y correlacionar señales	1. Observar	No modifica nada; el valor está en la síntesis
Proponer la causa probable y el equipo resolutor	2. Recomendar	Requiere criterio humano hasta acumular historial
Proponer cambios de tamaño en producción	2. Recomendar o 3. Actuar con aprobación	Reversible, pero afecta disponibilidad y costo
Actualizar atributos técnicos en la CMDB	3. Actuar con aprobación, luego 4 para atributos de bajo riesgo	Visible y reversible; otros dependen de esos datos
Reiniciar un servicio no crítico según un runbook aprobado	4. Actuar dentro de límites	Reversible, impacto acotado, procedimiento conocido
Escalar capacidad dentro de un rango predefinido	4. Actuar dentro de límites	Límites explícitos de cantidad y costo
Aislar un equipo ante una alerta de seguridad	3. Actuar con aprobación	Alto impacto en el negocio si es un falso positivo
Modificar reglas de firewall o permisos de acceso	2. Recomendar	Control de seguridad con impacto regulatorio
Eliminar datos o recursos con datos	2. Recomendar	No reversible

Para casos concretos de cómo se aplica esta escala, puedes ver el triaje de incidentes con agentes, el rightsizing continuo y la documentación viva.

Permisos y mínimo privilegio

El nivel de autonomía se declara en una política, pero se hace cumplir con permisos. Si el agente tiene credenciales de administrador, el nivel 2 es solo una intención. Recomendamos:

• Una identidad por agente y por caso de uso, nunca credenciales compartidas con personas ni con otros sistemas.
• Permisos de solo lectura por defecto. Los permisos de escritura se otorgan por acción concreta y por alcance (un espacio de nombres, un grupo de recursos), no de forma general.
• Credenciales de corta duración, emitidas para cada ejecución cuando la plataforma lo permite, en lugar de claves permanentes.
• Ejecución por canales existentes. El agente actúa a través de los mismos pipelines, herramientas de automatización o APIs que usan las personas, para que se apliquen los mismos controles.
• Separación entre quien propone y quien aprueba. El agente nunca puede aprobar sus propias acciones del nivel 3.

Interruptor de apagado y registro de auditoría

Dos controles deben existir antes de pasar cualquier caso de uso al nivel 3 o 4.

El interruptor de apagado permite detener al agente, o bajar todos sus casos de uso al nivel 2, con una sola acción y sin depender del propio agente. Debe estar documentado en los procedimientos del centro de operaciones, tener responsables definidos y probarse periódicamente, como cualquier otro control de continuidad. Un interruptor que nadie ha probado no es un control.

El registro de auditoría debe permitir reconstruir, para cada acción, qué datos vio el agente, qué concluyó, qué propuso, quién aprobó y qué ejecutó. Recomendamos que el registro:

• Se almacene fuera del alcance de escritura del agente.
• Incluya la versión del modelo, de las instrucciones y de las herramientas usadas en cada decisión.
• Se vincule con el ticket de cambio o de incidente correspondiente.
• Se conserve según la política de retención que aplica a los registros operativos de la organización.

Este registro sirve para auditorías, pero también para mejorar: es la base para medir la precisión que justifica subir o bajar de nivel.

Marcos de referencia para el gobierno

No hace falta inventar el gobierno de la IA desde cero. Dos referencias públicas ayudan a estructurarlo:

• ISO/IEC 42001 define los requisitos de un sistema de gestión de la inteligencia artificial. Es útil para organizaciones que ya trabajan con sistemas de gestión certificables, como ISO/IEC 27001, porque sigue una estructura similar de políticas, roles, evaluación de riesgos y mejora continua.
• El NIST AI Risk Management Framework (AI RMF) organiza la gestión del riesgo de la IA en cuatro funciones: Gobernar, Mapear, Medir y Gestionar. Es voluntario y no certificable, pero ofrece un vocabulario práctico para discutir riesgos con Riesgo y Cumplimiento.

La escala de niveles de este artículo encaja en ambos: es una forma concreta de documentar qué controles humanos aplican a cada uso de la IA y cómo se revisan. Antes de definir los niveles máximos para casos con impacto regulatorio, conviene validarlos con las áreas de Cumplimiento y Riesgo de tu organización.