Copiloto o piloto automático: cuánto control dar a un agente de IA

En 60 segundos: La autonomía no es una propiedad general del agente. Se decide acción por acción. Usá cinco niveles: lectura, recomendación, borrador, ejecución aprobada y autonomía acotada. Evaluá impacto del error, dificultad para revertir, sensibilidad, frecuencia y claridad de la política. Empezá con el nivel más bajo que produzca valor y subí solo con evidencia. Una aprobación humana no alcanza si nadie puede saber qué cambió, detener el flujo o recuperar el estado anterior. Pagos, condiciones comerciales y compromisos difíciles de revertir deben conservar controles separados.

Un agente puede resumir las facturas vencidas con bastante seguridad y, con las mismas credenciales, causar un problema serio si también puede aplicar pagos. Decir que está “supervisado” no aclara qué puede hacer, quién decide ni qué ocurre después de un error.

La unidad de diseño debe ser la acción. Para cada acción, definí qué consulta el agente, qué conclusión puede proponer y qué sistema puede modificar. Así se distingue un copiloto útil de un piloto automático con acceso excesivo.

Sugerir, decidir y ejecutar son actos distintos

Una sugerencia presenta opciones o una prioridad. Por ejemplo: “Conviene contactar primero a estas tres cuentas”. Todavía no crea una obligación.

La decisión selecciona una opción según una política y asume su consecuencia. Puede tomarla una persona, una regla determinista o una autorización previa bien acotada. El modelo no debería ocultar este paso dentro de una respuesta convincente.

La ejecución cambia el mundo fuera del chat: envía un correo, modifica el CRM, confirma un pedido, emite una factura o inicia una instrucción de pago. Exige controles que una sugerencia no necesita. La interfaz debe nombrar estas tres etapas con claridad y conservar sus registros por separado.

Los cinco niveles de autonomía

Nivel 1: lectura

El agente consulta fuentes autorizadas y responde sin modificar registros. Puede reunir oportunidades sin actividad, pedidos bloqueados, facturas vencidas o cifras de un reporte. Cada resultado debería mostrar la fuente y la hora de corte.

Lectura no significa acceso ilimitado. Un asistente gerencial sigue necesitando filtros por empresa, región, campo y rol. Nuestra guía del asistente conectado a ERP, ventas y cobranzas desarrolla esa arquitectura.

Nivel 2: recomendación

Además de leer, el agente ordena opciones o propone el siguiente paso. Puede marcar un pedido para revisión, explicar una variación del reporte o sugerir qué oportunidad necesita seguimiento. La recomendación debe quedar identificada como inferencia y enlazada con los hechos que la sostienen.

En este nivel una persona o una regla externa conserva la decisión. Medí cuántas recomendaciones se aceptan, corrigen o descartan y, sobre todo, qué casos importantes no aparecen.

Nivel 3: borrador

El agente prepara un artefacto que todavía no produce efectos operativos: un correo en borradores, una actualización propuesta para el CRM, un pedido sin confirmar, una factura preliminar o un lote de pagos sin firma.

El borrador debe vivir en un estado separado del registro oficial. La persona revisora necesita ver los datos de origen, los campos que cambiarían y cualquier validación fallida. Copiar el texto a una pantalla de aprobación sin mostrar el efecto completo crea una revisión superficial.

Nivel 4: ejecución aprobada

El agente ejecuta después de que una persona autorizada aprueba una acción concreta. La solicitud debe fijar destinatario, importe, moneda, registros afectados, contenido y vencimiento de la autorización. Si cualquiera de esos elementos cambia, la aprobación deja de ser válida.

Este nivel sirve, por ejemplo, para enviar un seguimiento ya revisado, actualizar una etapa del CRM o confirmar un pedido que pasó controles de stock, precio y cliente. Una aprobación genérica como “procesar pendientes” no debería habilitar una lista que puede cambiar mientras alguien la revisa.

Nivel 5: autonomía acotada

El agente puede ejecutar sin aprobación caso por caso dentro de un perímetro previo: acciones permitidas, importes máximos, destinatarios elegibles, horarios, volumen, sistemas y eventos de parada. Todo lo que quede fuera pasa a una cola con responsable.

Un ejemplo razonable sería completar un campo interno de baja sensibilidad a partir de una fuente verificada y con historial de cambios. Enviar pagos no es una recomendación predeterminada para este nivel. El agente puede detectar duplicados y preparar el lote, mientras la autorización bancaria y la segregación de funciones permanecen fuera de su control.

Matriz para elegir el nivel

Puntuá cada factor del 1 al 5. Usá 1 para riesgo o dificultad bajos y 5 para altos; en claridad de política, 1 significa una regla precisa y 5 una decisión ambigua. La cifra no reemplaza el criterio del dueño del proceso, pero obliga a explicar por qué una acción recibe más autonomía.

Factor	Pregunta para el equipo	Señal para limitar autonomía
Impacto del error	¿Qué pasa si actúa sobre el caso equivocado?	Afecta caja, cliente, cumplimiento o continuidad
Reversibilidad	¿Se puede volver al estado anterior y cuánto tarda?	No existe undo, el tercero ya actuó o la compensación es costosa
Sensibilidad	¿Qué datos y capacidades quedan expuestos?	Incluye credenciales, pagos, datos personales o condiciones reservadas
Frecuencia	¿Cuántas veces puede repetir el error antes de detectarlo?	El volumen amplía rápido el daño potencial
Claridad de política	¿Dos responsables resolverían igual el mismo caso?	Hay excepciones frecuentes o hace falta juicio comercial

Si un factor llega a 5, mantené la acción en lectura, recomendación o borrador hasta diseñar una barrera específica. Una suma baja puede admitir ejecución aprobada, pero no autoriza el nivel 5 automáticamente. La frecuencia alta aporta valor a la automatización y también aumenta el radio de daño.

Esta tabla muestra niveles iniciales, no destinos permanentes:

Acción	Error	Reversión	Sensibilidad	Frecuencia	Política	Nivel inicial
Resumir un reporte desde vistas aprobadas	Bajo	Fácil	Media	Semanal	Clara	1, lectura
Priorizar seguimientos comerciales	Medio	Fácil	Media	Diaria	Media	2, recomendación
Redactar correo a un cliente	Medio	Antes del envío	Media	Diaria	Media	3, borrador
Completar un campo interno del CRM	Bajo	Con historial	Media	Alta	Clara	3; luego 5 con límites
Confirmar un pedido	Alto	Depende del despacho	Media	Alta	Variable	3 o 4
Emitir una factura	Alto	Requiere corrección trazable	Alta	Alta	Clara con excepciones	3 o 4
Preparar un lote de pagos	Muy alto	Difícil después del envío	Muy alta	Variable	Estricta	3, sin ejecución autónoma

El nivel se asigna al paso, no al proceso completo. Un mismo flujo puede leer facturas en nivel 1, recomendar prioridades en nivel 2, redactar mensajes en nivel 3 y exigir nivel 4 para enviarlos.

La aprobación humana necesita una arquitectura

Una persona apurada puede aprobar por costumbre. También puede revisar un resumen correcto mientras el payload ejecutable contiene otro importe o más registros. La aprobación aporta control cuando cumple estas condiciones:

• el aprobador tiene autoridad y contexto para decidir
• la pantalla muestra la acción exacta, sus fuentes y el cambio propuesto
• la autorización vence, no puede reutilizarse y queda ligada a ese payload
• el sistema valida permisos, límites y estado otra vez justo antes de ejecutar
• otra identidad ejecuta y registra el resultado, especialmente en tareas financieras

La trazabilidad permite investigar. La recuperación limita el daño. Hacen falta ambas. Un correo externo casi nunca puede deshacerse; en ese caso el diseño debe prevenir el envío equivocado y definir una acción compensatoria, no prometer un rollback inexistente.

Controles mínimos antes de ejecutar

Aplicá privilegio mínimo por herramienta y acción. La práctica vigente de OAuth recomienda restringir cada token al mínimo necesario y limitar su audiencia al recurso previsto. Usá credenciales propias del agente, separadas por entorno y con expiración o revocación. Nunca reutilices la cuenta personal del responsable.

El log debería responder quién solicitó la acción, qué datos y política se usaron, qué propuso el modelo, quién aprobó, qué herramienta se llamó y cuál fue el resultado. Guardá identificadores y cambios relevantes sin copiar secretos ni más datos personales de los necesarios.

El botón de parada debe estar fuera del razonamiento del agente. Tiene que pausar colas, bloquear nuevas llamadas y permitir revocar sus credenciales. Definí también límites de volumen y velocidad para que un fallo no se repita cientos de veces antes de la alerta.

Prepará la recuperación para cada acción: restaurar un campo desde su historial, cancelar un pedido antes del despacho, emitir una nota de crédito mediante el proceso contable o detener un lote antes de la firma bancaria. Probá estos pasos. El artículo sobre acceso seguro para agentes programadores muestra el mismo patrón aplicado a ramas, credenciales y producción.

Los controles AC-6, AU-12 y CP-10 de NIST SP 800-53 Rev. 5 cubren privilegio mínimo, generación de registros de auditoría y recuperación. RFC 9700, sección 2.3 aplica el mínimo privilegio a tokens de acceso. El perfil de IA generativa de NIST propone gestionar riesgos a lo largo del ciclo de vida y documentar roles de supervisión, medición y respuesta. Son bases de diseño; cada empresa todavía debe traducirlas a sus sistemas y responsabilidades.

Cómo subir de nivel con evidencia

Empezá en modo sombra: el agente observa casos reales y produce una salida que no se usa para actuar. Comparala con la decisión del equipo y registrá errores, omisiones y excepciones.

Pasá a recomendaciones cuando las fuentes sean rastreables. Después habilitá borradores para un solo tipo de acción. Antes del nivel 4, probá duplicados, datos vencidos, cambios entre aprobación y ejecución, interrupciones del conector y recuperación. El nivel 5 necesita además un volumen reducido al inicio y eventos de parada automáticos.

Revisá por período y por cantidad de casos:

• correcciones y omisiones, separadas por tipo de excepción
• intentos fuera del alcance permitido
• acciones ejecutadas con el payload aprobado
• tiempo para detectar, detener y recuperar un fallo
• carga creada para aprobadores y responsables de excepciones

Una tasa alta de aprobación no demuestra calidad si las personas aprueban sin revisar. Buscá desacuerdos explicados, casos límite cubiertos y recuperaciones ensayadas. Cualquier ampliación de sistema, destinatarios o importe vuelve a una fase controlada.

Kiia diseña estos niveles alrededor de un flujo real, con sus permisos, responsables y fallos posibles. El resultado esperado es una secuencia de acciones cuyo control puede demostrarse antes de ampliar la autonomía.