Tus agentes de IA necesitan descripciones de puesto, no mejores instrucciones

Pregúntale a una empresa qué puede hacer una nueva analista de cuentas por pagar y obtendrás una respuesta precisa. Trabaja con estos sistemas y estos proveedores, y cualquier importe que supere un límite de aprobación de, por ejemplo, 10.000 dólares, pasa a su gerente para que lo firme. Está a prueba durante sus primeros meses. Todo eso suele quedar registrado en una matriz de delegación de autoridad que auditoría interna revisa cada año.

Pregúntale a esa misma empresa qué puede hacer su nuevo agente de facturación y a menudo te mostrarán una captura de pantalla de una instrucción.

Esa brecha me preocupa más que cualquier evaluación comparativa de modelos. Estamos contratando una fuerza laboral digital sin el sistema de gestión que tardamos un siglo en crear para las personas: nadie deja constancia de sus facultades, nadie pone a prueba su criterio antes de que empiece a trabajar y nadie ha practicado cómo apagarla.

Por qué una instrucción no basta

Una instrucción describe la intención. Explica para qué sirve el agente. Rara vez indica qué no debe hacer nunca, cuáles son sus límites o cuándo debe detenerse y dejar la decisión en manos de una persona.

Y, aunque una instrucción sí lo indique, nada lo hace cumplir. Decirle a un agente que no emita reembolsos superiores a 500 dólares es una petición dirigida a un sistema probabilístico. Ningún auditor aprobaría «le pedimos amablemente a la analista que lo hiciera» como mecanismo de control para una persona, así que no entiendo por qué lo aceptamos en el caso del software.

En seguridad, ya hay un nombre para este resultado. OWASP Top 10 for LLM Applications incluye la agencia excesiva entre los riesgos principales, derivada de una funcionalidad, unos permisos o una autonomía excesivos. En pocas palabras, es como darle a una empleada las llaves de todo desde el primer día. Las directrices de OWASP parecen una lista de comprobación para un buen gerente: darle al agente solo las herramientas que necesita, delimitar sus permisos, exigir la aprobación de una persona para las acciones de gran impacto y hacer cumplir la autorización en los sistemas posteriores, en vez de confiar en que el modelo se controle por sí solo.

Yo subrayaría esto último. La autorización debe estar donde se ejecuta la acción: en la propia identidad de servicio del agente, en los permisos de sus herramientas y en el límite de gasto de la pasarela de API. Usar una cuenta de servicio compartida para varios agentes es como hacer que cinco personas compartan una misma credencial. Cuando algo sale mal, el registro de auditoría indica que actuó la cuenta de servicio, y uno se queda tratando de adivinar cuál de los agentes fue.

Las cancelaciones parecen un problema de gestión

Gartner predice que se cancelará más del 40 % de los proyectos de IA agéntica antes de que termine 2027, debido al aumento de los costos, a un valor comercial poco claro y a controles de riesgo inadecuados.

La exageración y la inmadurez de los productos forman parte de la explicación. Aun así, prueba a leer las tres causas como lo haría un director de operaciones. Los costos se disparan cuando nadie fija un presupuesto. El valor sigue sin estar claro cuando nadie deja por escrito qué resultados debía producir el trabajo. Los controles de riesgo son insuficientes cuando no hay límites, revisiones ni una persona claramente responsable. Gartner no lo plantea así; esa es mi interpretación. Es lo mismo que ocurre cuando se deja a las personas actuar sin un sistema de gestión, y ese problema es mucho más antiguo que la IA.

Los marcos detectan la misma carencia. El Marco de gestión de riesgos de IA del NIST establece que la función de gobernanza atraviesa las de identificación, medición y gestión, y su Perfil de IA generativa extiende ese enfoque a los sistemas generativos. Lo que los marcos no pueden aportar es la maquinaria operativa: las autorizaciones, pruebas y revisiones con las que un equipo trabaja un martes cualquiera. Sin ellas, la gobernanza se queda en un PDF guardado en una unidad compartida.

Cómo adaptar las herramientas de gestión tradicionales a los agentes

Empieza por la descripción del puesto, que en el caso de un agente se convierte en una autorización. Antes de que un agente acceda a un sistema en producción, alguien debería poder redactar un documento de una página que detalle qué puede hacer, qué no debe hacer nunca, cuáles son sus umbrales de aprobación, qué persona es responsable de él y quién puede ampliar sus límites. En la matriz RACI, la persona responsable última debe ser una persona. Si no puedes redactar ese documento, el puesto no está listo para cubrirse; dirías lo mismo de una contratación humana.

Dos reglas tradicionales de delegación de autoridad se aplican tal cual. No puedes delegar una autoridad que no tienes, así que un subagente nunca debería recibir una autorización más amplia que la del agente que lo creó. La segregación de funciones también sigue siendo necesaria. Que un agente pueda crear un proveedor y pagarle sería el mismo hallazgo de auditoría que si lo hiciera una persona.

Después viene la prueba de selección. En general, evaluamos a los agentes como evaluaríamos una calculadora: comprobamos si la respuesta es correcta. Una prueba para un trabajador comprobaría si se mantuvo dentro de los límites de su autorización, pidió aprobación cuando correspondía, escaló el caso cuando la situación excedía sus instrucciones y se detuvo cuando debía hacerlo.

En mi propia investigación, he estado creando una prueba de referencia con 50 escenarios que cubren precisamente estos fallos: superar los límites de aprobación, actuar con datos desactualizados, seguir instrucciones inyectadas que amplían el alcance y conservar el acceso después de un cambio de función. Hasta ahora solo la he ejecutado con agentes programados mediante guiones para comprobar que los escenarios funcionan según lo previsto, así que no tengo resultados de modelos que presentar. Al redactarlos, me sorprendió lo corrientes que son. Son las formas habituales en que los empleados se salen de sus instrucciones, adaptadas al software. La mayoría de las clasificaciones públicas todavía evalúan la ejecución de tareas, y muy pocas miden si el agente respetó sus facultades.

Los conceptos de período de prueba y ascenso se trasladan bastante directamente. Con las personas, empezamos por asignarles un ámbito reducido y lo ampliamos a medida que demuestran tener buen criterio. Los agentes pueden ganarse sus límites de la misma manera: demostrando que se mantienen dentro de ellos, que saben elevar los asuntos cuando corresponde y que se detienen correctamente. Ese historial también puede justificar que se reduzca una autorización.

Los agentes añaden una complicación que no se da con las personas. Cuando un proveedor actualiza el modelo subyacente, en la práctica tienes a una persona recién contratada que lleva la credencial de la anterior. Yo lo trataría como un cambio y volvería a evaluar al agente antes de transferirle la autorización.

Hay que ensayar la rescisión antes de necesitarla. Si tuvieras que detener a este agente y revocarle los accesos durante la próxima hora, ¿podrías hacerlo? ¿Quién tiene autoridad para tomar esa decisión a las 2 de la madrugada? ¿Qué fallaría en los procesos posteriores y qué compromisos en curso tendría que deshacer alguien manualmente? Si nadie ha hecho ese simulacro, estás confiando en que funcione el interruptor de emergencia.

Puedes exigir responsabilidades a un empleado. No puedes responsabilizar a un agente de nada, y ahí es donde deja de funcionar la comparación. Por eso también la autorización debe hacerse cumplir mediante sistemas y cada agente debe tener una persona responsable designada. En cualquier caso, alguien acaba teniendo que rendir cuentas. Por lo general, es quien dio el visto bueno, supiera o no que lo estaba dando.

Qué preguntará la revisión del incidente

Algunos de estos agentes acabarán haciendo algo que no deberían. Cuando eso ocurra, la revisión posterior al incidente planteará las mismas preguntas que ya plantea sobre las personas. ¿Qué tenía permitido hacer y dónde está documentado? ¿Quién aprobó la ampliación de sus accesos? ¿Cuánto se tardó en detenerlo? ¿Quién era responsable?

Si las respuestas sinceras son «un prompt», «nadie se acuerda», «horas» y «no está claro», un modelo mejor no te habría salvado.

Dónde acaba estando la ventaja

Los modelos se están convirtiendo en recursos de alquiler que se sustituyen y actualizan según el calendario del proveedor. Dos empresas pueden usar el mismo modelo y acabar en situaciones muy distintas. Una tiene agentes con presupuestos, límites, responsables y un registro de auditoría de cada acción importante; la otra tiene un piloto costoso que va camino de engrosar las estadísticas de cancelación de alguien.

La diferencia está en el sistema de gestión que rodea al modelo. Ese sistema se construye poco a poco, sobre todo gracias a personas que ya han dirigido organizaciones.

Si mañana tu agente más reciente se excediera de sus atribuciones, ¿alguien en tu empresa se daría cuenta? ¿Y podrías mostrarle por escrito a un auditor dónde estaba el límite?