Monitorización de agentes de IA: registro, alertas y reversión en operación

El lunes por la mañana, una clienta pregunta por qué el viernes por la noche recibió una confirmación de cita para un día que nunca había pedido. La empleada de la oficina abre el buzón y encuentra el mensaje, enviado por el agente. Lo que leyó, lo que dedujo de ello y qué herramientas usó para hacerlo, no lo puede ver. Solo hay el resultado.

Este escenario es inventado, el patrón no. En cuanto un agente no solo genera textos, sino que crea citas, asigna tickets o escribe datos en sistemas, la pregunta pasa de «¿Es buena la respuesta?» a «¿Qué ha hecho realmente?». Un chatbot que se equivoca produce una información errónea. Un agente que se equivoca deja huellas en sus sistemas.

Operar significa por tanto más que poner en marcha. Quien utiliza un agente asume una tarea conocida con los empleados nuevos: al principio se observa con atención, se hace que se expliquen las decisiones y solo poco a poco se cede responsabilidad. La diferencia es que un agente solo puede dar esa explicación si se registró de antemano. Preguntar a posteriori no es posible.

En las pequeñas empresas esto pesa más que en los grandes grupos. No hay un departamento propio que investigue incidentes, y la persona que configuró el agente suele ser la misma que lleva además el negocio diario. Cuando algo sale mal, la calidad del registro decide si aclararlo lleva una hora o media jornada, y si la clienta recibe una respuesta concreta o una excusa.

El software clásico llama la atención cuando se cae. Los agentes rara vez llaman la atención así. Siguen funcionando, entregan resultados de aspecto plausible y aun así se equivocan. Eso hace la supervisión más exigente, porque la señal simple de «funciona» o «no funciona» no dice nada sobre la calidad.

Entre los tipos de fallo más frecuentes está el bucle. El agente llama una y otra vez a la misma herramienta porque la respuesta no encaja con el patrón que espera, y consume tiempo de cálculo y presupuesto sin avanzar. Un segundo tipo es la llamada errónea a una herramienta: la herramienta correcta con parámetros equivocados, o la herramienta equivocada para la tarea. Un tercero son los tiempos de espera agotados, en los que una interfaz no responde y el agente o bien se rinde o bien continúa con información incompleta.

El tipo más pérfido es la interfaz modificada. Un sistema conectado cambia nombres de campos, formatos o códigos de respuesta, y el agente interpreta los datos nuevos según el patrón antiguo. Sigue «funcionando», solo que mal. Aquí no ayuda una alerta por caídas, sino solo la comparación entre el comportamiento esperado y el real.

A ello se suman errores que residen en la propia instrucción. Una formulación que era inequívoca en las pruebas se lee de otro modo ante una entrada inusual. Estos errores no pueden atajarse solo con técnica. Necesitan a una persona que revise regularmente casos reales y los compare con la intención de la instrucción.

Registrar no significa guardarlo todo. Una grabación completa de cada llamada al modelo genera grandes volúmenes de datos que nadie lee y suele contener información personal que no desea conservar más tiempo del necesario. La pregunta es qué datos hacen falta para explicar después un caso.

Suele bastar un registro por paso con cuatro componentes: ¿qué entró, qué decidió el agente a partir de ello, qué acción desencadenó y en qué fuente se apoya la decisión? Complementado con un identificador de caso, una marca de tiempo, la versión de la instrucción utilizada y el resultado de la llamada a la herramienta, se puede reconstruir cualquier caso.

El identificador es más importante de lo que parece al principio. Un caso consta de muchos pasos repartidos por varios sistemas. Solo si la misma clave aparece en la bandeja de entrada, en el registro del agente y en el sistema de destino se puede seguir un incidente desde la queja de la clienta hasta el paso que lo originó. Sin ella, todo queda en trabajo de detective.

Hay un límite que forma parte del asunto: el registro es documentación operativa, no un archivo permanente. Establezca cuánto tiempo se conserva, quién puede consultarlo y qué campos se enmascaran. Con datos personales rige el principio de minimización de datos; la configuración concreta debería aclararla con su delegada de protección de datos. Este texto no es asesoramiento jurídico.

Una prueba práctica de la calidad del rastro: pida a alguien que no haya configurado el agente que explique un caso cualquiera a partir del registro. Si lo logra sin preguntar al desarrollador, el rastro es utilizable. Si tiene que adivinar o buscar en tres sistemas, falta un campo o el identificador no se transmite. Esta prueba cuesta un cuarto de hora y descubre lagunas antes de que lo haga un incidente real.

La solución más obvia sería un panel con cifras clave: número de casos, duración media, tasa de error. Es útil y no basta, porque solo muestra el comportamiento del agente en promedio. Una sola confirmación de cita errónea desaparece en una estadística, pero para la clienta afectada sigue siendo un incidente.

Una segunda opción es dejarlo todo en manos del proveedor del modelo o de la plataforma y usar sus análisis integrados. Eso ahorra esfuerzo, pero ata la trazabilidad a una interfaz ajena. Si cambia de proveedor o combina dos herramientas, el rastro se rompe. Por ello llevaríamos los registros en un formato propio y sencillo en su entorno y usaríamos los valores de la plataforma como complemento.

Como tercera posibilidad se ofrece el control puramente manual: alguien lee casos con regularidad. Es imprescindible, pero por sí solo no es sostenible, porque no escala y encuentra los errores solo cuando ya han ocurrido. Por eso combinamos tres niveles que se complementan: alertas automáticas para infracciones claras de las reglas, cifras clave continuas para las tendencias y muestreos por personas para lo que ningún conjunto de reglas detecta.

Esta combinación es un compromiso. Más alertas significan más interrupciones y, con el tiempo, insensibilización; más muestreos consumen tiempo. Dónde se sitúa el umbral depende de lo que cueste un error. Un agente que clasifica notas internas puede supervisarse con menos rigor que uno que escribe a clientes o prepara ofertas.

Una alerta solo es útil si alguien sabe qué hacer a continuación. Por eso vinculamos cada alerta a una breve instrucción de actuación: quién recibe el aviso, qué se comprueba, ¿puede el agente seguir funcionando o se pausa? Según nuestra experiencia, las alertas sin un siguiente paso definido acaban en la bandeja de entrada y se ignoran.

En la monitorización de costes importa menos el importe total que la desviación respecto al comportamiento normal. Un agente que de repente necesita muchas más llamadas al modelo por operación suele tener un problema de bucles, de contexto demasiado largo o de reintentos erróneos. Un tope estricto por operación y un límite diario acotan el daño antes de que una persona pueda intervenir. Al alcanzar el límite, la operación debería traspasarse a una persona, no descartarse en silencio.

Las revisiones por muestreo cubren el hueco que las alertas no ven. Empezaríamos con un ritmo fijo, por ejemplo un pequeño número de operaciones elegidas al azar por semana, más todas aquellas en las que el agente tuvo dudas o las traspasó a una persona. El revisor ve entrada, traza y resultado uno junto a otro y los valora con una escala breve: correcto, aceptable, incorrecto.

De esa escala surge conocimiento. Si se acumulan valoraciones de «aceptable» en un tipo concreto de consulta, la instrucción es demasiado abierta en ese punto. Si se acumulan valoraciones de «incorrecto» a partir de una fecha determinada, merece la pena revisar un cambio en la interfaz o en la instrucción. La revisión es, por tanto, control de calidad y sistema de alerta temprana a la vez.

El esfuerzo es asumible si la traza se lee bien. Un revisor necesita pocos minutos por operación, siempre que no tenga que reunir antes datos de tres sistemas. Es otro motivo para invertir en la estructura del registro antes de que el primer agente entre en producción.

La instrucción que le dice a un agente cómo actuar es la palanca más eficaz y, al mismo tiempo, la fuente de errores más frecuente. Una frase modificada puede cambiar el comportamiento en casos en los que nadie pensó al hacer el cambio. Aun así, las instrucciones suelen editarse en un campo de texto, sin historial y sin aprobación.

Por eso las tratamos como código. Cada cambio recibe un número de versión, una breve justificación y un responsable. El registro deja constancia de con qué versión se generó cada paso. Así, ante un incidente se puede responder si ocurrió antes o después de un cambio y qué operaciones se vieron afectadas por una versión defectuosa.

Antes de la activación, un conjunto de pruebas fijo comprueba la nueva versión: casos estándar, casos especiales conocidos y fallos anteriores que no deben repetirse nunca. Esto no sustituye la observación en producción, pero detecta retrocesos graves. Después, la nueva versión se ejecuta primero solo para una parte pequeña de las operaciones o únicamente para tipos de consulta no críticos.

Lo decisivo es la vuelta atrás. Una versión anterior debe poder reactivarse con un solo gesto, sin que nadie tenga que reconstruir el texto antiguo a partir de un correo. Las operaciones que se hayan procesado entretanto con la versión defectuosa pueden localizarse y revisarse a través del registro. No toda acción es reversible, por ejemplo un mensaje ya enviado. Por eso, al revertir también hay que preguntarse qué podía desencadenar el agente por su cuenta durante el período crítico.

Técnicamente, para empezar basta con una estructura manejable. Cada paso se escribe como un registro estructurado, no como texto libre, por ejemplo en formato JSON en una base de datos o en un sistema de logs. Estructurado significa que campos como identificador de operación, paso, herramienta, parámetros, estado de la respuesta, duración y versión de la instrucción se pueden buscar por separado. El texto libre se reserva para justificaciones y citas de la fuente.

El registro pertenece a la capa que llama a las herramientas, no a la instrucción. Si es el propio agente quien debe «registrar», la integridad depende de que obedezca. Si cada llamada a una herramienta pasa por una capa intermedia que guarda automáticamente la entrada y el resultado, la traza es completa incluso cuando el agente se comporta de forma distinta a la prevista.

En esta capa también pueden colocarse los mecanismos de protección: un tope de llamadas por operación, un límite de tiempo por paso, una comprobación del formato de respuesta frente al esquema esperado. Si el esquema no coincide, por ejemplo porque falta un campo o tiene otro nombre, no se adivina: se detiene la operación y se avisa. Así se detectan los cambios silenciosos de interfaz que un agente por sí solo no percibe.

Para las alertas bastan al principio reglas sencillas: la misma llamada más de tres veces seguidas, un paso que supera el tiempo establecido, costes por encima del umbral, esquema de respuesta incumplido. Los avisos van a un canal que alguien lea de verdad. La detección sofisticada de anomalías solo compensa cuando hay suficientes datos de operación para saber qué es normal.

Un caso especial es el cambio gradual. Nada se rompe, pero la calidad se desvía: aparecen nuevos tipos de consulta, cambia el nombre de un producto, se ajusta una regla interna sin que la instrucción se actualice. Ni las alertas ni las tasas de error muestran estas desviaciones. Se detectan en los muestreos, sobre todo cuando los revisores también buscan patrones y no solo valoran operaciones individuales.

Un segundo caso son los errores con retraso. Hoy el agente crea mal un registro y el problema solo se manifiesta semanas después, cuando alguien accede a él. Aquí la traza demuestra su valor, porque muestra qué operaciones tuvieron la misma causa. Quien solo mira el sistema de destino ve un único dato erróneo. Con el registro se pueden encontrar todos los casos similares y corregirlos conjuntamente.

En tercer lugar, la interacción entre varios agentes o con otras automatizaciones. Si un agente escribe un correo al que otro sistema reacciona automáticamente, pueden surgir reacciones en cadena que ninguna de las dos partes causó por sí sola. Las contramedidas son topes para las acciones posteriores desencadenadas automáticamente y una marca que indique qué mensajes se generaron por máquina.

Y, por último, el fallo de la propia monitorización. Si el registro deja de funcionar, nadie se da cuenta mientras el agente siga trabajando. Por eso configuraríamos una alarma inversa: si no llegan entradas de registro en un plazo esperado aunque haya operaciones en curso, se avisa. Un agente supervisado con una supervisión caída sin que nadie lo note es más arriesgado que uno deliberadamente muy acotado.

La monitorización no hace más inteligente a un agente, lo hace controlable. El beneficio está en que los errores se detectan antes, las causas se encuentran más rápido y los cambios son menos arriesgados. Cuánto se nota en el día a día depende del uso: del número de operaciones, de los sistemas conectados y de lo graves que sean las consecuencias de un error.

Se puede medir con magnitudes cercanas a la operativa. Entre ellas, el tiempo que transcurre entre la aparición de un error y su detección, la proporción de operaciones traspasadas a personas, la distribución de las valoraciones del muestreo a lo largo de las semanas y la evolución del coste por operación. Registre estos valores desde el principio, aunque al comienzo parezcan poco llamativos. Solo una evolución de varias semanas permite emitir un juicio.

Lo que no se puede prometer: ausencia de errores. Un agente sigue siendo un sistema que trabaja con probabilidades, y una buena supervisión reduce los daños, pero no los excluye. Tampoco se puede decir de antemano cuántas alertas habrá al principio. En la fase de implantación suelen ser más que después, porque los umbrales todavía no están ajustados a la operativa real.

Otro beneficio honesto es la tranquilidad. Si sabe que cada acción es rastreable, puede ir encomendando más tareas al agente. Sin esa base, el uso queda limitado a ámbitos en los que un error no cuesta nada, y ese rara vez es el ámbito en el que un agente más alivia la carga.

De este análisis se pueden extraer pocas reglas. Primera: registre antes de que el agente entre en producción, no después. Una traza añadida a posteriori solo muestra el futuro, no el incidente que la motivó. Segunda: mantenga la traza pequeña y estructurada, con las cuatro preguntas: entrada, decisión, acción y fuente. Tercera: tome en serio las instrucciones como software, con versiones, pruebas y vuelta atrás.

En cuarto lugar, hay que aclarar la responsabilidad. ¿Quién lee las alertas, quién toma las muestras, quién puede revertir una versión? Sin personas designadas, la mejor monitorización se queda en una carpeta llena de datos. En quinto lugar, ayuda empezar de forma acotada: un proceso, un tipo de consulta, pocas herramientas. Cómo se elige ese proceso piloto lo hemos descrito en un estudio aparte.

En sexto lugar, conviene introducir las alertas con moderación y criterio. Cinco reglas que alguien se toma en serio son mejores que veinte que se silencian al cabo de una semana. Las nuevas reglas se añaden solo cuando un incidente real demuestra que hay una laguna. Así el conjunto de reglas crece según la experiencia real y no según una lista de comprobación de manual.

Su siguiente paso es pequeño. Tome una operación que hoy tramita un agente o una automatización y pregúntese: ¿podría explicar en cinco minutos por qué se decidió exactamente así este paso? Si no, falta la traza. Con mucho gusto revisamos su proceso juntos y le decimos con franqueza qué supervisión es adecuada en su caso y cuál sería excesiva.