Casi todas las grandes organizaciones han puesto en marcha al menos un proyecto piloto de inteligencia artificial destinado a incidir en la gestión de servicios de TI. Muchas lo interrumpen después de algunos meses, con resultados inferiores a las expectativas, y atribuyen el resultado negativo a la tecnología. En buena parte de los casos, la causa se encuentra en otro lugar: en la forma en que el proyecto había sido planteado desde el principio.
Las causas recurrentes son dos. La primera es la ambición excesiva, que lleva a partir de agentes de IA capaces de operar de forma autónoma aunque la organización todavía no disponga de la madurez necesaria para gestionarlos. La segunda es la ausencia de estructura y de una gobernanza estable y compartida: ningún responsable designado, ninguna métrica de éxito acordada antes del inicio, ningún criterio para decidir si continuar.
Este artículo propone un método para construir un AI ITSM Pilot que produzca resultados verificables y que permita recopilar desde las primeras semanas evidencias útiles para construir y verificar el business case.
Partir de casos de uso de bajo riesgo
La elección correcta del caso de uso determina en gran medida el éxito del proyecto piloto. Un caso de uso de bajo riesgo presenta tres características: los resultados son verificables por una persona en pocos segundos, el error produce consecuencias limitadas y reversibles, y el volumen de solicitudes tratadas es suficiente para generar datos significativos en pocas semanas.
Tres actividades satisfacen estas condiciones.
El triaje de tickets. El sistema propone la categoría, la prioridad y el equipo de asignación de cada solicitud entrante. El operador ve la propuesta y la confirma o la modifica con un clic. Cada interacción genera un dato útil sobre el porcentaje de propuestas correctas.
El resumen de las incidencias. Para los incidentes con muchas anotaciones, el sistema produce un resumen del estado y de las acciones llevadas a cabo. Es especialmente útil en los traspasos entre turnos, donde reconstruir manualmente la cronología de un incidente complejo resta minutos valiosos a la resolución.
Los borradores para la base de conocimiento. Utilizando los tickets resueltos, el sistema genera un primer borrador del artículo, que un redactor revisa y aprueba. La creación de contenidos para la base de conocimiento sigue siendo una de las actividades más sacrificadas por la presión operativa, y una contribución en esta dirección libera tiempo cualificado.
Estas tres actividades comparten una propiedad valiosa para un AI ITSM Pilot: la revisión humana ya forma parte natural del flujo y, por tanto, el control no añade pasos artificiales. Los flujos de trabajo completamente autónomos, por el contrario, solo pueden activarse después de que el sistema haya demostrado una fiabilidad constante a lo largo del tiempo.
Definir las métricas antes del lanzamiento
Antes del inicio del proyecto piloto es necesario definir para cada indicador elegido tres elementos: el valor de partida obtenido a partir de los datos históricos, el objetivo esperado al término del período de prueba y la traducción de esa mejora en términos comprensibles para la dirección de la empresa y para la función financiera. Las fórmulas genéricas como «mayor eficiencia operativa» o «mejor soporte de TI» no superan ni el primer encuentro con la función financiera.
Debe definirse también de antemano el criterio de decisión: qué resultado justifica el paso a la siguiente fase y cuál, en cambio, sugiere detenerse. Establecerlo antes evita que la evaluación final se reduzca a una comparación de opiniones sobre el significado de los resultados obtenidos.
¿Cuántos indicadores y en qué período?
Los indicadores realmente útiles son específicos: reducción de las notificaciones no significativas, tiempo empleado para asignar un ticket al equipo más adecuado, porcentaje de asignaciones correctas en el primer intento, tiempo medio de resolución, calidad de la respuesta a los incidentes de mayor gravedad, percepción de los equipos implicados.
Además, cada indicador debe vincularse a una consecuencia concreta para la empresa, reconocible también fuera del ámbito de TI. Por ejemplo: el tiempo de asignación corresponde a la espera percibida por el usuario; la calidad de los borradores de la base de conocimiento incide en la capacidad de los agentes del service desk para cerrar las solicitudes sin involucrar a los equipos especializados.
Es mejor seleccionar dos o tres indicadores, no más. Cada métrica requiere una definición compartida, una medición inicial precisa y una interpretación al término de la prueba. Un AI ITSM Pilot que monitoriza seis reduce el cuidado dedicado a cada indicador, porque distribuye la atención en demasiados frentes.
Dado que los volúmenes varían considerablemente a lo largo del año, la medición debe extenderse a un período lo suficientemente amplio como para incluir tanto los momentos de pico como los de menor carga.
Responsabilidad y gobernanza
Un AI ITSM Pilot sin un responsable designado se detiene ante el primer obstáculo. La titularidad debe asignarse a una persona, con nombre y apellidos, que responda de los resultados y tenga la autoridad para decidir las eventuales intervenciones correctivas.
Junto a la titularidad se necesitan tres herramientas de trabajo. La primera es un mapa técnico que describe las herramientas de monitorización implicadas, las fuentes de datos utilizadas, las relaciones entre servicios obtenidas de la CMDB, los controles de seguridad aplicados, los límites establecidos para la introducción de automatización y los puntos de integración. La segunda es un registro de riesgos dedicado, en el que anotar las incidencias identificadas, su prioridad y las acciones a realizar. La tercera es un modelo operativo que establece quién mantiene los datos, quién verifica la calidad de las recomendaciones y la frecuencia con la que el sistema se revisa.
El mapa técnico, el registro de riesgos y el modelo operativo funcionan únicamente si la organización dispone de normas compartidas sobre el uso de la IA. En ausencia de una gobernanza definida, cada equipo adopta sus propias herramientas y sus propias convenciones, con el resultado de multiplicar las divergencias en lugar de reducirlas.
Los controles human-in-the-loop
El control humano debe preverse necesariamente allí donde el riesgo es mayor, evitando aplicarlo indistintamente a cada decisión. Tres elementos deben definirse y documentarse antes del inicio del proyecto: qué recomendaciones del sistema requieren la aprobación de un operador antes de hacerse operativas, quién tiene la tarea de aprobarlas y dónde queda registrada esa aprobación.
Debe definirse también qué ocurre cuando el sistema se equivoca: quién detecta el error, cómo se restablece la situación anterior y en cuánto tiempo. Definir este procedimiento durante la fase experimental, cuando las consecuencias siguen siendo limitadas, evita tener que improvisarlo en la fase de producción.
Por qué la tasa de aprobación puede engañar
Una consideración importante tiene que ver con el esfuerzo requerido para rechazar una propuesta. Si la aprobación se obtiene con una única acción (un solo clic), mientras que la corrección obliga a rellenar manualmente los campos, los operadores bajo presión tenderán a confirmar incluso las recomendaciones imprecisas.
El dato sobre la calidad de las propuestas acaba midiendo así las cargas de trabajo del service desk más que el rendimiento del sistema: si el porcentaje de propuestas aprobadas se utiliza como indicador de la precisión del sistema, y si aprobar requiere una acción rápida mientras que corregir impone un trabajo manual, ese porcentaje subirá en los períodos de mayor presión sobre el service desk y bajará cuando la carga se alivie. La solución consiste en hacer que la corrección sea igual de rápida que la aprobación, por ejemplo proponiendo alternativas seleccionables en lugar de un campo vacío.
Introducir la autonomía de forma gradual
En un AI ITSM Pilot, la ampliación de la autonomía debe avanzar por versiones sucesivas, cada una subordinada a los resultados de la anterior.
V1 – Sugerencias con revisión humana
El sistema propone, la persona encargada de la supervisión del proceso decide. Cada propuesta del agente de IA se compara con la elección real del operador, y de esta comparación se obtiene la tasa de concordancia entre la propuesta del sistema y la decisión del operador. La concordancia, sin embargo, no equivale automáticamente a la precisión: una muestra de las decisiones debe verificarse por separado para comprobar su corrección.
V2 – Automatización de los casos de alta fiabilidad
Una vez identificadas las tipologías en las que el sistema alcanza de forma constante niveles de fiabilidad suficientemente elevados, la ejecución automática se activa únicamente en esas. El resto de las solicitudes continúa pasando por la revisión humana. El umbral debe fijarse por separado para cada tipo de propuesta: la asignación de un ticket requiere garantías distintas respecto a la modificación de una prioridad.
V3 – Autonomía ampliada
La ampliación avanza a medida que crece la fiabilidad del sistema y, en consecuencia, la confianza de los operadores humanos. El seguimiento de los resultados es continuo y siempre existe la posibilidad de revertir la automatización cuando el rendimiento se degrada.
Un recorrido de este tipo retoma una lógica de transición gradual de la experimentación a la operación, por la que la fase de observación precede a la introducción en un perímetro controlado y, solo después, la incorporación a la operativa diaria.
Del proyecto piloto a la demostración del valor
El vínculo entre experimentación y retorno económico (ROI) se construye durante el proyecto. En otras palabras, los datos que servirán para demostrar el valor de la inversión deben recopilarse mientras el proyecto piloto está en curso. Los datos históricos recopilados antes del inicio constituyen la baseline respecto a la cual evaluar los resultados del proyecto. Los datos producidos durante la fase V1 sirven, en cambio, para verificar y calibrar el comportamiento del sistema. Y las mejoras registradas en V2 se convierten en la prueba que presentar para solicitar presupuesto adicional para la extensión del proyecto.
Los mismos principios se repiten en las recomendaciones más extendidas sobre la introducción de la IA en la gestión de servicios: partir de casos de uso de alto valor, cuidar la calidad de los datos, adoptar las herramientas adecuadas, formar a las personas, experimentar a pequeña escala y crecer con gradualidad.
Un AI ITSM Pilot planteado de este modo sigue siendo útil cualquiera que sea el resultado. Si el proyecto funciona, la organización dispondrá de datos verificables para justificar su extensión. Si el proyecto no funciona, a cambio de un gasto contenido, la organización sabrá qué carencias subsanar antes de volver a intentarlo. La reflexión que los responsables de la toma de decisiones deben hacer tiene que ver con el grado de madurez de su organización más que con los límites de la tecnología.
FAQs
- ¿Cuánto debe durar un proyecto piloto de IA en ITSM?
El tiempo necesario para recopilar un número suficiente de observaciones sobre el caso de uso elegido. Para actividades de alto volumen como el triaje de tickets, bastan algunas semanas: períodos más breves no permiten distinguir un resultado estable de una variación ocasional. - ¿Por qué conviene evitar los agentes autónomos en la fase inicial?
Porque son necesarios mecanismos de control, umbrales de fiabilidad y responsabilidades definidas que se construyen con la experiencia. Partir de sugerencias sometidas a revisión permite recopilar los datos necesarios para calibrar esos umbrales antes de ampliar la autonomía. - ¿Quién debería liderar el proyecto?
Una única persona, acompañada de referentes para los datos, para la gobernanza y para los equipos operativos implicados. Una titularidad compartida entre varias funciones ralentiza los procesos de toma de decisiones en el momento en que deben mostrarse ágiles. - ¿Cómo se demuestra el retorno de la inversión al término de la experimentación?
Comparando los valores registrados antes del inicio con los obtenidos durante el proyecto, sobre los indicadores acordados de antemano, y convirtiendo los resultados en horas de trabajo liberadas y en costes evitados.
Guía del comprador de ITSM: lecciones de la voz del cliente
Elegir una plataforma de gestión de servicios de TI (ITSM) no es fácil. El mercado está lleno de opciones y, a menudo, las funcionalidades parecen muy similares.
¡Descarga la guía ahora y descubre las tres lecciones clave!
Gartner® Magic Quadrant 2026 para plataformas ITSM
¡Descubre las últimas tendencias en ITSM! Este informe va directo a lo importante, con un análisis independiente, el posicionamiento de los proveedores e insights prácticos para ayudarte a tomar tu próxima decisión en ITSM.
