Clasificar incidencias de IT con IA en Jira o ServiceNow: qué se puede automatizar y qué no

En muchos equipos de soporte, la primera hora de cada incidencia se va en tareas que no resuelven nada: leer el ticket, adivinar a qué categoría pertenece, decidir la prioridad y pasarlo al grupo que toca. Si el ticket llega mal clasificado, rebota entre grupos y el usuario espera más. Es un trabajo repetitivo, basado en texto y con reglas que casi nadie tiene escritas: justo el tipo de tarea en la que un modelo de lenguaje puede ayudar.

Este artículo explica qué parte del ciclo de una incidencia se puede automatizar con IA dentro de Jira Service Management, ServiceNow u otra herramienta similar, y qué parte conviene dejar a las personas.

Lo que encaja bien

• Clasificar. Leer el asunto y la descripción y proponer categoría, subcategoría y servicio afectado según tu catálogo, no uno genérico.
• Priorizar con criterio explícito. Sugerir impacto y urgencia aplicando la matriz que ya usa el equipo. Si la matriz no está escrita, este es el momento de escribirla.
• Enrutar. Asignar el grupo resolutor a partir de la categoría, el servicio y el historial de tickets parecidos.
• Detectar duplicados. Avisar de que hay otras incidencias abiertas sobre lo mismo, algo habitual cuando cae un servicio y llegan decenas de avisos.
• Sugerir una respuesta. Proponer al técnico un primer mensaje o los pasos de una solución conocida, sacados de la base de conocimiento y de incidencias resueltas, con enlace a la fuente.
• Pedir lo que falta. Si el ticket no trae la información mínima (equipo, usuario afectado, mensaje de error), solicitarla antes de que lo coja nadie.

Todo esto se integra por la API de la herramienta de soporte: la IA lee el ticket, escribe sus propuestas en campos o en una nota interna y la herramienta sigue siendo la misma para el equipo.

Lo que no conviene automatizar

• Cerrar incidencias sin que nadie lo vea. Una respuesta sugerida que suena bien puede no resolver el problema real.
• Ejecutar cambios en sistemas. Reiniciar servicios, cambiar permisos o desbloquear cuentas exige controles propios; si se automatiza, que sea con reglas fijas y aprobación, no por decisión del modelo.
• Las incidencias graves o de seguridad. Cuando hay un incidente mayor o una posible brecha, la IA puede ayudar a reunir información, pero las decisiones y la comunicación son de las personas.
• Responder sin fuente. Si la base de conocimiento no cubre el caso, el asistente debe decirlo y pasar el ticket, no improvisar una solución.

Empezar con la IA como propuesta, no como decisión

La forma prudente de empezar es que la IA proponga y el técnico confirme o corrija. Cada corrección es información valiosa: indica dónde el catálogo es ambiguo, qué categorías se confunden o qué reglas faltan. Cuando las propuestas de un tipo de ticket se aceptan de forma consistente, se puede pasar ese tipo a asignación automática y dejar el resto en revisión.

Dos detalles prácticos que marcan la diferencia:

1. Un catálogo limpio. Si hay categorías duplicadas o que nadie usa, la IA heredará el desorden. Revisarlo antes es parte del proyecto.
2. Permisos y privacidad. Los tickets contienen datos personales y a veces credenciales pegadas por error. El sistema debe ejecutarse en un entorno controlado, respetar quién puede ver qué y no enviar el contenido a servicios que lo usen para entrenar modelos.

Cómo medir si ayuda

Antes de activar nada, conviene tomar una referencia de unas semanas con los indicadores que la herramienta ya da:

• Tiempo hasta la primera respuesta y tiempo hasta la asignación correcta.
• Reasignaciones: cuántas veces cambia de grupo un ticket antes de resolverse.
• Tasa de aceptación de las propuestas de la IA, por categoría.
• Satisfacción del usuario, si ya se mide.

Con la referencia, el piloto se compara contra datos propios y no contra promesas. Si un indicador no mejora, la tasa de aceptación suele indicar por qué.

Cómo lo abordamos

En Valvia empezamos por una cola o un tipo de incidencia concreto, con los datos históricos del cliente y su propia matriz de prioridades, y medimos antes de ampliar. Puedes ver el planteamiento en automatización de incidencias de IT y, si la base de conocimiento es la pieza que falta, en nuestro artículo sobre RAG con la documentación de tu empresa. Si quieres ver cómo encajaría con tu herramienta de soporte, hablemos de tu caso.