Agentes de IA: tareas útiles y límites de autonomía

Si un proceso es estable y sus pasos se conocen de antemano, a menudo es mejor un flujo programado con reglas y, como mucho, un modelo en un paso concreto (clasificar o extraer). El agente tiene sentido cuando la variedad de peticiones hace inviable prever todos los caminos y el coste de un paso incorrecto es bajo o se puede revisar.

Cada herramienta que se da a un agente amplía lo que puede hacer, para bien y para mal. Es preferible ofrecer funciones específicas y acotadas («consultar estado de pedido por número») que herramientas genéricas («ejecutar consulta SQL» o «hacer una petición HTTP a cualquier dirección»). Una herramienta específica valida sus parámetros, devuelve solo los campos necesarios y deja un rastro comprensible.

• Separa herramientas de lectura y de escritura; muchas tareas útiles solo necesitan leer.
• Valida en el código de la herramienta, no en las instrucciones al modelo: tipos, rangos, que el registro pertenezca al usuario que pregunta.
• Devuelve errores claros cuando algo no está permitido, para que el agente no insista con variaciones.
• Limita el número de pasos, el tiempo y el volumen de llamadas por tarea, para evitar bucles y consumos desproporcionados.
• Prefiere acciones idempotentes o con confirmación, de modo que repetir un paso no duplique una operación.

Un error frecuente es darle al agente una cuenta de servicio con acceso amplio «para que funcione». El resultado es que cualquier usuario que hable con el agente puede, en la práctica, ver o modificar lo que esa cuenta ve. El criterio sano es que el agente actúe con los permisos del usuario que hace la petición, o con un subconjunto de ellos, nunca con más.

Esto tiene consecuencias de diseño: las herramientas deben recibir la identidad del usuario y aplicar sus permisos en cada llamada, igual que lo haría la aplicación normal. También conviene que ciertas acciones requieran confirmación explícita aunque el usuario tenga permiso, simplemente porque el agente pudo haber entendido mal la petición.

Cuando un agente se equivoca, hay que poder averiguar en qué paso. Eso exige registrar más que la respuesta final. Una traza útil permite a alguien que no estaba presente entender la secuencia completa y reproducir el problema.

• Petición original, usuario, fecha y versión de las instrucciones y del modelo.
• Cada llamada a herramienta con sus parámetros, el resultado devuelto y el tiempo empleado.
• Acciones de escritura con su identificador en el sistema afectado, para poder revisarlas o revertirlas.
• Confirmaciones o rechazos humanos y su motivo.
• Errores, reintentos y el motivo por el que el agente se detuvo.

Las trazas contienen datos de negocio y a veces personales, así que necesitan su propia política de acceso y conservación. Registrar todo para siempre no es una buena respuesta; registrar lo necesario durante el tiempo justificado, sí.

Ayuda mucho fijar por escrito el nivel de autonomía de cada herramienta, en lugar de dejar que lo determine el comportamiento del modelo. Un esquema sencillo es este:

1. Lectura libre: el agente consulta sin pedir permiso, dentro de los permisos del usuario.
2. Escritura con confirmación: el agente prepara la acción y la muestra; el usuario la confirma con un clic y ve exactamente qué se hará.
3. Escritura con aprobación de un tercero: para acciones con efecto económico o externo, la propuesta va a un responsable distinto del solicitante.
4. Fuera de alcance: acciones que el agente no puede realizar aunque se lo pidan; la herramienta simplemente no existe.

Además de la supervisión caso a caso, conviene revisar periódicamente las trazas: qué tipos de petición fallan, qué herramientas se usan de forma inesperada, dónde los usuarios rechazan más propuestas. Esa revisión es la que permite ampliar o recortar la autonomía con datos y no con impresiones.

Un equipo de atención al cliente pasa buena parte del día abriendo tres aplicaciones para responder la misma pregunta. Un agente podría tener cuatro herramientas de solo lectura (pedido, envío, factura e incidencias) y una de escritura: crear un borrador de respuesta en el sistema de tickets, que el agente humano revisa y envía. No puede emitir abonos ni cambiar direcciones; si el cliente lo pide, el agente lo indica y el operador lo tramita por la vía habitual. Todas las consultas quedan en una traza vinculada al ticket.

Es un alcance modesto, pero fácil de evaluar y con un riesgo controlado. Si funciona, la siguiente ampliación (por ejemplo, proponer un cambio de dirección con confirmación) se decide con información real.

1. ¿La variedad de peticiones justifica un agente frente a un flujo programado?
2. ¿Cada herramienta es específica, valida sus parámetros y aplica los permisos del usuario?
3. ¿Está decidido qué acciones requieren confirmación o aprobación y cuáles quedan fuera?
4. ¿Se ha pensado qué ocurre si el agente lee un texto con instrucciones maliciosas?
5. ¿Las trazas permiten reconstruir cada paso y revertir lo que se haya escrito?
6. ¿Hay un conjunto de peticiones de prueba para evaluar el agente antes de cada cambio?

Un agente bien acotado puede quitar mucho trabajo mecánico. Uno con herramientas genéricas y permisos amplios es un riesgo difícil de medir. Si estás valorando un caso concreto, podemos ayudarte a definir herramientas, permisos y puntos de control antes de construirlo.