Los agentes de IA en soporte técnico ejecutan acciones por sí solos y rompen la lógica del ticket

Desde finales de los 80, cuando aparecieron los primeros sistemas de registro de solicitudes y la primera versión de ITIL, el soporte cuenta su trabajo en tickets. Llega una solicitud, se asigna a un responsable, se cierra y se mide el tiempo. Han pasado casi cuatro décadas y este esquema se resquebraja: los agentes de IA ya ejecutan acciones en varios sistemas a la vez, desbloquean cuentas, conceden accesos y reinician servicios. Si nadie toma la solicitud para trabajarla, queda por resolver con qué medir entonces el soporte. Es lo que analiza Habr AI. A continuación se resume el análisis y se exponen nuestras conclusiones.

Por qué el ticket fue durante tanto tiempo la unidad principal

El ticket reunía tres funciones a la vez: cola de tareas, registro de eventos y base para los informes. Los SLA, la carga de los empleados, el tiempo de reacción y el tiempo de resolución están ligados a la ficha y a una persona concreta. Toda la construcción se sostiene sobre el supuesto de que entre la solicitud y la acción hay un ejecutor que invierte tiempo y atención. El tiempo se consideraba el recurso principal.

Con un agente, ese supuesto deja de funcionar. No espera en una cola, no cambia de una tarea a otra y no se va a comer. Desbloquear una cuenta lleva segundos, y la acción puede afectar a la vez al directorio de usuarios, al sistema de accesos y a la monitorización.

Qué queda de la solicitud

Lo primero que se rompe son las métricas de velocidad. El tiempo de reacción tiende a cero y el tiempo medio de resolución cae en picado. Con esas cifras no se puede saber si el problema se ha resuelto de verdad o si el usuario simplemente ha dejado de escribir. Un buen resultado y un fallo silencioso tienen el mismo aspecto en el informe.

El segundo cambio afecta a la propia ficha. Si el agente actúa de forma autónoma, el ticket a menudo se crea y se cierra automáticamente, o ni siquiera se crea. Deja de ser una herramienta de trabajo y se convierte en un rastro: un registro de quién hizo qué, con qué fundamento y con qué permisos. El valor se traslada de la cola al registro de acciones.

El tercero tiene que ver con la responsabilidad. Un acceso concedido abre una superficie de ataque real, y un servicio reiniciado puede interrumpir el trabajo de otros. Un comentario de «hecho» en la ficha es una fuente demasiado pobre para un caso así.

Con qué medir el soporte

El anuncio no incluye una lista directa, pero del problema descrito se deduce un conjunto de indicadores que conviene situar junto a los clásicos:

• proporción de solicitudes cerradas por el agente sin intervención humana y proporción de solicitudes repetidas sobre ellas;
• proporción de acciones del agente que una persona revirtió o corrigió;
• tiempo hasta la resolución desde el punto de vista del usuario, no según el estado de la ficha;
• número de escalados a personas y sus motivos;
• coste de tramitar una solicitud, incluidas las llamadas al modelo y el tiempo de revisión;
• completitud de la auditoría: en cada acción quedan registrados el iniciador, el fundamento, los permisos utilizados y el resultado.

Las solicitudes repetidas son aquí el indicador más honesto. Si el usuario vuelve con el mismo problema, el cierre rápido no valía nada.

Por dónde empezar en la práctica

Empiece por los permisos. El agente necesita el acceso mínimo imprescindible, no una cuenta de administrador «por comodidad». Conviene clasificar las acciones por riesgo: restablecer una contraseña o desbloquear una cuenta no es lo mismo que conceder privilegios elevados, y en este último caso hace falta la confirmación de una persona.

Después, revise los informes. Para las solicitudes automatizadas, es preferible sustituir el SLA de tiempo de reacción por indicadores de calidad: repeticiones, reversiones, satisfacción. No hay que tirar el ticket. Conviene conservarlo como registro único para auditoría, aunque ninguna persona haya participado en él.

Por último, deje en manos de las personas las excepciones y el análisis de errores. El trabajo del especialista de soporte pasa de procesar la cola a configurar y verificar agentes, y habrá que evaluarlo de otra forma que por el número de solicitudes cerradas.