Delegar acciones a un agente exige acordar su autoridad, las excepciones y la responsabilidad de quienes lo operan. La supervisión debe poder funcionar en la práctica.
Un agente prepara una respuesta para un cliente. Después, alguien propone que también la envíe. Más adelante, que modifique la orden para resolver el problema. Las tres tareas pueden parecer parte del mismo flujo, pero cada una concede una autoridad distinta.
La conversación sobre autonomía necesita detenerse en esas diferencias. Antes de ampliar lo que un sistema puede hacer, la empresa debería poder explicar quién autorizó esa capacidad, bajo qué condiciones y quién se hará cargo si la acción resulta equivocada.
Poner a una persona “en el circuito” no resuelve automáticamente la cuestión. Si recibe decenas de solicitudes sin contexto, carece de tiempo para revisarlas o no puede detener el proceso, su aprobación difícilmente constituye un control suficiente. La supervisión necesita información, capacidad de intervención y una responsabilidad reconocible.
Delegar una acción concreta
“Automatizar compras” es un alcance demasiado amplio para decidir permisos. Consultar existencias, sugerir una reposición, generar un borrador de pedido y emitirlo a un proveedor son acciones diferentes. Cada una puede necesitar condiciones y responsables propios.
Conviene describir la autoridad del agente con verbos precisos. Qué puede leer, preparar, modificar o enviar. Sobre cuáles registros. Dentro de qué límites. Qué deberá hacer cuando encuentre información contradictoria o cuando la operación solicitada quede fuera de su alcance.
Estos límites deben reflejarse en los accesos y controles del sistema, además de las instrucciones escritas. Un diseño en el que el agente tiene permisos amplios y recibe únicamente la indicación de usarlos con prudencia deja una parte importante del control a la interpretación.
La excepción revela el diseño
Imaginemos una empresa que utiliza un agente para preparar pedidos de reposición. Es un escenario hipotético, no un caso de cliente. El sistema consulta inventario y propone una compra a un proveedor habitual. Después encuentra dos precios distintos y una solicitud para cambiar la cuenta de pago.
Un flujo bien delimitado puede detener esa operación y dirigirla a las personas responsables de compras y validación del proveedor. La capacidad de avanzar en casos ordinarios no debería convertirse en permiso para resolver por su cuenta una discrepancia con consecuencias distintas.
La empresa necesita haber acordado ese recorrido antes del incidente. Quién recibe la excepción, qué evidencia revisa, cuánto puede permanecer pendiente y cómo continúa el trabajo si esa persona no está disponible. Dejar una alerta en una bandeja sin responsable solo cambia de lugar el problema.
También conviene separar responsabilidades. Quien administra la herramienta puede mantenerla funcionando sin tener autoridad para aprobar condiciones comerciales. Quien dirige el proceso debe poder decidir qué delegar y asumir la revisión de sus efectos. Ambas funciones necesitan coordinarse, sin quedar diluidas en una responsabilidad colectiva imposible de ejercer.
Aprobar con información suficiente
Una revisión humana debería mostrar la acción propuesta, su alcance, los datos que la respaldan y cualquier incertidumbre relevante. También tendría que permitir rechazarla o pedir una corrección sin obligar al revisor a reconstruir todo el expediente.
Para acciones de mayor consecuencia, la aprobación debe corresponder a la operación concreta. Autorizar un pedido con ciertos productos y condiciones no equivale a aprobar cualquier versión posterior. Si esos elementos cambian, el proceso debe reconocer que la decisión pendiente también cambió.
El registro de lo ocurrido ayuda a revisar errores y a mejorar el sistema. Importa conservar qué se solicitó, qué información se utilizó, qué acción se ejecutó y quién la autorizó, con las protecciones y los plazos de conservación que correspondan. Registrar todo indiscriminadamente tampoco es una buena política.
Ampliar autonomía con evidencia
Un piloto puede comenzar preparando propuestas sin ejecutarlas. Después, la empresa puede evaluar si tiene sentido autorizar algunas acciones acotadas. Esa progresión debería depender de resultados observados y de la capacidad para detectar y contener errores, no únicamente de que una demostración haya funcionado.
Las pruebas necesitan incluir excepciones, interrupciones y reintentos. También deben comprobar cómo se evita repetir una operación y cómo se recupera el equipo cuando el sistema deja de estar disponible. Algunas acciones admiten reversión; otras requieren un control previo más estricto porque deshacerlas no elimina sus consecuencias.
La pregunta útil para dirección es concreta: si mañana este agente hace algo incorrecto, ¿sabemos quién puede detenerlo, revisar lo ocurrido y decidir cómo continuar? Una respuesta clara permite delegar con mejores fundamentos. Una respuesta vaga señala trabajo pendiente, aunque la tecnología ya esté lista para ejecutar.
