Resulta habitual pensar que el departamento de IT, por su cercanía natural a la tecnología, va a adoptar un agente de IA sin fricción y con resultados inmediatos. La realidad de los primeros 90 días suele ser más matizada: IT gestiona sistemas heterogéneos, documentación a menudo dispersa o desactualizada, y usuarios internos con paciencia limitada para nuevas herramientas. Gestionar bien la expectativa de este plazo evita tanto el escepticismo del propio equipo técnico —que suele ser el más exigente evaluando estas herramientas, precisamente porque conoce de primera mano las limitaciones de cualquier sistema nuevo— como la desilusión de los usuarios internos si el sistema no responde bien desde el primer día.
Días 1-30: conexión al sistema de tickets y triage inicial
El primer mes se dedica a conectar el agente con el sistema de gestión de incidencias (Jira Service Management, ServiceNow, Freshservice) y con la documentación técnica interna: manuales de procedimientos, preguntas frecuentes de usuarios, guías de acceso a sistemas. Como en otros departamentos, esta documentación suele estar incompleta o desactualizada, y parte del trabajo de este mes consiste en identificar esos huecos antes de que generen respuestas incorrectas a usuarios internos que después cuesta más corregir que prevenir.
El alcance inicial más razonable es el triage de tickets de nivel uno: preguntas frecuentes sobre accesos, incidencias comunes con solución documentada, y clasificación de la urgencia de cada ticket entrante para priorizar la cola del equipo técnico. El equipo de IT recibe formación sobre cómo revisar las clasificaciones y respuestas del agente, y sobre todo sobre cuándo el sistema debe escalar directamente a una persona sin intentar resolver, algo especialmente importante en incidencias que afectan a sistemas críticos.
Conviene también, en este primer mes, definir con claridad qué pasa fuera del horario habitual de soporte: si el agente puede intentar resolver incidencias de madrugada o en fin de semana, o si simplemente debe registrar el ticket y escalar a primera hora del día siguiente. Dejar esta cuestión sin resolver suele generar comportamientos inconsistentes justo en los momentos donde menos supervisión humana hay disponible para corregir un error.
Días 31-60: primeras métricas y ajuste de la base de conocimiento técnico
Con un mes de tickets reales gestionados, se puede medir: porcentaje de tickets de nivel uno resueltos sin necesidad de escalar a nivel dos, tiempo medio de resolución comparado con el proceso anterior, y satisfacción de los usuarios internos con las respuestas recibidas, que suele ser un indicador más sensible en IT que en otros departamentos porque los usuarios internos comparan directamente con la rapidez de un compañero técnico.
Es frecuente descubrir en este tramo que el agente funciona bien con incidencias estandarizadas (restablecer una contraseña, dar acceso a una carpeta) pero mal con problemas que dependen de sistemas heredados o configuraciones no documentadas. Documentar esos casos específicos, en vez de esperar que el sistema los infiera solo, es lo que más mejora la tasa de resolución en este periodo.
También conviene revisar en este tramo si el agente está generando confusión al usuario interno con explicaciones demasiado técnicas o, al contrario, demasiado simplificadas para el tipo de incidencia. Ajustar el nivel de detalle de las respuestas según a quién van dirigidas —un usuario del departamento de ventas no necesita el mismo nivel de detalle técnico que alguien del propio equipo de IT reportando un problema de infraestructura— mejora la percepción del sistema sin cambiar nada de fondo en su capacidad de resolución.
Días 61-90: consolidación y decisión sobre automatizar tareas adicionales
Al llegar al tercer mes, con datos de dos meses de gestión de tickets, se puede valorar si el equipo de IT dedica menos tiempo a incidencias repetitivas y más a proyectos de mayor valor, y si la satisfacción de los usuarios internos se mantiene estable o mejora. Con esos datos, se decide si tiene sentido ampliar el alcance a tareas como el aprovisionamiento de accesos, la monitorización proactiva de sistemas, o la gestión de solicitudes de software.
Si la tasa de resolución de nivel uno sigue siendo baja o irregular, conviene dedicar el trimestre siguiente a mejorar la documentación de base antes de sumar nuevas responsabilidades, porque ampliar el alcance sobre una base de conocimiento débil solo multiplica el volumen de respuestas incorrectas.
Esta decisión debería tomarse también teniendo en cuenta el coste de un fallo en tareas más automatizadas como el aprovisionamiento de accesos, donde un error no es solo una respuesta incorrecta a un usuario sino un problema real de seguridad o de permisos mal configurados. Cuanto mayor sea el impacto potencial de una tarea, más conviene exigir un historial más largo de resultados fiables antes de dársela al agente sin supervisión.
Señales de que el proyecto va bien y señales de que hay que replantear algo
Señales positivas a los 90 días: la proporción de tickets resueltos en nivel uno crece de forma sostenida, los usuarios internos dejan de buscar atajos informales para saltarse el sistema, y el equipo técnico dedica visiblemente más tiempo a proyectos frente a soporte reactivo. Vale la pena revisar también los primeros 90 días de tu proyecto de IA para aplicar el mismo rigor de KPIs al balance de tu proyecto en IT.
Señales de alarma: los usuarios internos evitan el sistema y contactan directamente a un técnico "para ir más rápido", la tasa de escalado a nivel dos no baja con el tiempo, o el equipo técnico sigue sin confiar en las clasificaciones de urgencia del agente. Si algo de esto suena familiar desde las primeras semanas, conviene repasar qué esperar en la primera semana con un agente de IA para distinguir un problema de adopción normal de uno estructural.
Conclusión
Los primeros 90 días de IA en IT dependen sobre todo de la calidad de la documentación técnica conectada desde el inicio y de un alcance bien acotado al triage de nivel uno antes de ampliar a tareas con mayor impacto potencial, como el aprovisionamiento de accesos o la gestión de permisos. Medir la tasa de resolución real y la satisfacción de los usuarios internos, en vez de dar por hecho que el equipo técnico validará el sistema sin más, es lo que permite decidir con criterio los siguientes pasos. Si quieres valorar el estado de tu soporte interno, pide un diagnóstico gratuito.