Cómo Ser Analista de Soporte en la Era de la IA

Guía técnica para usar IA en un service desk GLPI sin caer en las trampas de campo: la consulta que muestra dónde rinde la IA, por qué el triaje debe seguir siendo determinista (RuleTicket) y la IA solo lo difuso, el error de llamar a la IA de forma síncrona que congela el ticket, y las habilidades que pasan a valer - con AI Assist y la experiencia de mantenimiento de NexTool.

La IA no va a sustituir al analista de soporte, pero el analista que la usa bien sustituirá al que la ignora. En GLPI esto no es un discurso: es un flujo que se configura, se mide y se ajusta. En el mantenimiento de service desks GLPI de clientes, hemos visto fracasar a la IA de dos formas - pegada sin medición (nadie sabe si ayudó) y usada en piloto automático (una sugerencia errónea pegada directamente en la solución). Esta guía muestra cómo operacionalizar la IA en el día a día del ticket, con las consultas y la configuración que ejecutamos en campo.

Empieza midiendo dónde la IA rinde, no dónde impresiona

El error común es apuntar la IA al ticket complejo y raro - el que brilla en la demostración - en lugar del repetitivo de alto volumen, que es donde de verdad devuelve tiempo. Antes de enchufar nada, averigua dónde está el volumen y cuánto cuesta. Esta consulta lista las categorías con más tickets en los últimos 90 días y el tiempo medio hasta la resolución, los candidatos de mayor retorno para respuesta asistida por IA, artículo de base de conocimiento y triaje automático:

-- Categorias de mayor volumen y tiempo medio de resolucion (90 dias).
-- solve_delay_stat esta en segundos; /3600 convierte a horas.
SELECT c.completename            AS categoria,
       COUNT(t.id)               AS tickets,
       ROUND(AVG(t.solve_delay_stat)/3600, 1) AS horas_hasta_resolver
FROM glpi_tickets t
JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
  AND t.is_deleted = 0
  AND t.solvedate IS NOT NULL
GROUP BY t.itilcategories_id, c.completename
HAVING tickets >= 10
ORDER BY tickets DESC
LIMIT 15;

La cima de esa lista es tu mapa: son los asuntos donde un resumen automático, un borrador de respuesta o un artículo de KB rinden más. Una categoría de alto volumen y tiempo alto de resolución es donde la IA como asistente más alivia la cola; una categoría de bajo volumen y alta complejidad sigue siendo trabajo humano - e intentar automatizarla es un desperdicio.

Triaje determinista primero, IA después

La confusión más cara que vemos es pedirle a la IA lo que las reglas de negocio de GLPI ya hacen mejor. Clasificar categoría, definir prioridad y asignar grupo por patrón de asunto, solicitante o entidad es trabajo de las reglas de negocio de tickets (RuleTicket): determinista, auditable y reproducible. La IA generativa entra en lo difuso y que no necesita ser reproducible: resumir un hilo de 50 interacciones, redactar un borrador a partir del historial, señalar el tono del solicitante. Mezclar los dos papeles es el origen de informes de SLA que nadie puede explicar. La matriz que usamos para decidir quién ejecuta qué:

TareaEjecutor idealPor quéRiesgo si se intercambia
Clasificar categoría y prioridadRegla de negocio (RuleTicket)Debe ser reproducible y auditable en el informe de SLALa IA varía la decisión; el SLA se vuelve una caja negra
Resumir un hilo largoIA (AI Assist)Tarea difusa, sin respuesta únicaUna regla fija no resume; el analista lo lee todo a mano
Redactar una respuestaIA + revisión humanaAcelera, pero el analista firmaPegar sin revisar propaga el error a la KB
Enrutar al grupo correctoRegla de negocioDeterminista por entidad/asuntoEl ticket cae en el grupo equivocado y rompe el SLA
Diagnosticar causa raízHumanoVariables no documentadas, contexto realLa IA "alucina" una causa plausible y errónea

Nunca llames a la IA de forma síncrona en el ciclo del ticket

Esta es la trampa que más horas nos costó en mantenimiento. Cuando la integración de IA - o cualquier webhook externo - dispara una llamada HTTP dentro del gancho de creación o actualización del ticket de forma síncrona, el guardado del analista se queda esperando a que la API externa responda. Hemos visto el botón de guardar bloquearse de 30 a 60 segundos porque un hook hacía la petición al momento, y el analista juraba que "GLPI está lento". El enriquecimiento por IA tiene que ser asíncrono: se encola y se procesa fuera del request, por el cron externo de GLPI. Y ese cron debe ser real (modo CLI/externo), no el disparo por visita de página:

# Cron externo de GLPI (MODE_EXTERNAL) - ejecuta las tareas en cola,
# incluidas notificaciones y enriquecimiento asincrono.
# Ejecutar como el usuario del servidor web (www-data / apache), cada minuto:
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1

El error común es dejar las tareas automáticas en modo interno, disparado por quien carga una página. Sin visita, nada se ejecuta; bajo carga, una tarea larga bloquea el estado y las demás no corren. Configura las tareas en GLPI en modo CLI y asegura el crontab de arriba - de lo contrario la automatización "a veces funciona", que es lo mismo que no funcionar.

Lo que sigue siendo trabajo humano

La IA redacta; el humano decide y firma. Diagnosticar un problema con variables no documentadas, negociar con un usuario frustrado, el juicio de escalar o sortear, el contexto político que define la prioridad real - nada de eso lo resuelve la IA. Y hay un detalle que solo percibe quien opera: el campo de solución del ticket alimenta la base de conocimiento, que a su vez alimenta la siguiente sugerencia de la IA. Pegar una respuesta generada sin revisar no es solo un error puntual - entra en el acervo y vuelve amplificado en la sugerencia siguiente. El analista de la era de la IA es el revisor que impide que ese ciclo degrade la calidad del servicio.

Las habilidades técnicas que pasan a valer

  1. Prompt con contexto del ticket: citar el ítem, el historial y el error exacto da una respuesta útil; un prompt genérico da texto genérico.
  2. Leer y ajustar RuleTicket: entender el triaje determinista que sostiene el SLA vale más que cualquier truco de IA.
  3. Medir con SQL: las consultas de arriba prueban, con números, dónde rindió la IA y dónde solo dio trabajo.
  4. Curar la base de conocimiento: la sugerencia de la IA es tan buena como la KB que la alimenta; un artículo desactualizado se vuelve una sugerencia errónea.
  5. Revisar antes de pegar: tú firmas la solución, no la IA. Esa es la frontera que define al analista que aporta valor.

¿Quieres poner la IA a trabajar dentro de GLPI de forma medible, con el módulo AI Assist integrando OpenAI GPT y Google Gemini en el propio ticket? Conoce el servicio de mantenimiento GLPI de NexTool y haz que la IA rinda sin romper lo que ya funciona.


Revisado por el equipo de NexTool Solutions.

Preguntas Frecuentes

Mide antes de automatizar. Ejecuta la consulta de categorías por volumen y tiempo medio de resolución (últimos 90 días) y apunta la IA al alto volumen repetitivo, no al caso raro y complejo que brilla en la demostración. Ahí es donde el resumen automático, el borrador de respuesta y el artículo de base de conocimiento devuelven más tiempo.

No. Clasificación, prioridad y enrutamiento son trabajo de las reglas de negocio de tickets (RuleTicket): determinista, auditable y reproducible en el informe de SLA. Deja la IA para lo difuso - resumir hilos largos, redactar borradores, señalar el tono del solicitante. Mezclar los papeles produce un SLA que nadie puede explicar.

Casi siempre es una llamada HTTP externa (la API de IA o un webhook) disparada de forma síncrona dentro del gancho de creación/actualización del ticket - el guardado espera la respuesta y se bloquea de 30 a 60 segundos. La solución es hacer el enriquecimiento asíncrono: encolarlo y procesarlo por el cron externo de GLPI (front/cron.php en modo CLI), nunca dentro del request.

AI Assist integra OpenAI GPT y Google Gemini directamente en el ticket de GLPI, para resumir hilos, sugerir respuestas basadas en el historial y la base de conocimiento y evaluar el tono del solicitante - sin sacar al analista de la decisión final, que sigue firmando la solución.

No. La IA sustituye tareas repetitivas (resúmenes, borradores, triaje difuso), pero el analista sigue siendo esencial para el diagnóstico de causa raíz con variables no documentadas, la relación con el usuario y el juicio de escalar o sortear. El papel pasa de mecanógrafo a revisor: quien impide que una sugerencia errónea entre en la base y vuelva amplificada.

?Necesitas ayuda?