Dar herramientas no resuelve la confianza
El mercado está obsesionado con dar más autonomía a los agentes: navegador, terminal, correo, CRM, código e infraestructura. El problema aparece después: qué hizo, por qué lo hizo, con qué evidencia y quién tenía autoridad para permitirlo.
Autonomía útil necesita límites
Un sistema serio distingue lectura de escritura, acciones reversibles de irreversibles, hechos de hipótesis y resultados de modelo de evidencia mecánica. Cuando falta evidencia crítica, debe poder bloquear.
La última palabra sigue siendo humana
Más autonomía no implica menos responsabilidad. La prueba también se audita: entorno, método, hipótesis y suficiencia de evidencia deben poder cuestionarse antes de promover una conclusión o un cambio.
Capacidad y autoridad son dimensiones distintas
Que un agente pueda abrir un navegador, ejecutar comandos o escribir en un CRM describe capacidad técnica. No responde quién le dio permiso para hacerlo en este caso, sobre qué objeto ni con qué consecuencia. La arquitectura debe representar autoridad separadamente: lectura, propuesta, escritura, acciones reversibles y acciones que crean obligaciones no son equivalentes.
La confianza debe ser contextual
No existe una confianza única para “el agente”. Un sistema puede estar autorizado a resumir expedientes y no a enviarlos, a preparar una campaña y no a publicarla, a proponer un cambio y no a desplegarlo. Cuanto más específica sea la frontera, menos necesario es confiar globalmente en un modelo para tareas heterogéneas.
El bloqueo también es comportamiento correcto
Cuando falta una aprobación, una fuente está vencida o una acción excede permisos, detenerse es una salida válida. Diseños obsesionados con completar tareas tienden a interpretar todo bloqueo como fracaso y buscar caminos alternativos. En sistemas con consecuencias, esa perseverancia puede ser exactamente lo que no se quiere.
Registrar el efecto, no sólo el razonamiento
Para auditar autonomía importa qué herramienta se invocó, con qué alcance, qué cambió y qué evidencia justificó la transición. Una explicación posterior del modelo no reemplaza un registro mecánico de la acción. El razonamiento puede ayudar a entender; el estado del sistema debe permitir comprobar.
La métrica equivocada
Contar cuántas tareas terminaron sin intervención humana premia autonomía aunque la tarea no debiera completarse sola. Métricas más útiles distinguen automatización segura, escalaciones correctas, bloqueos necesarios, reversibilidad y errores detectados antes de producir efectos. El objetivo no es ausencia de humanos; es usar autoridad humana donde agrega control real.
Una prueba útil
Una forma concreta de someter esta idea a presión es dar al agente una herramienta real con una acción deliberadamente fuera de su autoridad y verificar que pueda reconocerla, bloquearla y dejar evidencia útil para escalar. La prueba no debería evaluar sólo si aparece una respuesta, sino qué estado queda, qué evidencia se conserva y si otro operador puede entender por qué el sistema actuó así. Ese tipo de ensayo transforma un principio editorial en una propiedad observable y permite descubrir dónde la arquitectura todavía depende de supuestos invisibles.
Lo que esta nota no afirma
Más guardrails no convierten a un agente en infalible; el objetivo es reducir el espacio en el que una equivocación del modelo puede convertirse directamente en una consecuencia no autorizada. Esta distinción importa porque una buena práctica deja de ser útil cuando se convierte en promesa universal. El objetivo es hacer explícita una frontera de diseño que pueda discutirse, probarse y adaptarse al dominio, manteniendo separados hechos, inferencias, permisos y decisiones.