El concepto AIOps prescribe que para operar un servicio hay que situarse en medio de tres ejes: observabilidad, gestión y automatizaciones. Colocar en la confluencia de los tres una IA, capaz de absorber y entender los datos que vienen de ellos, ayudaría a operarlo con mayor solvencia y permitiría inferir lo que está sucediendo, efectuar correcciones o documentar los procesos. Todo ello automatizado y personalizado para un contexto específico.
Poner en práctica los fundamentos teóricos sobre los que descansan las grandes tendencias no suele ser tarea sencilla y casi siempre exige asociar dos términos rara vez presentes en los reclamos comerciales: experiencia y sentido común.

En un escenario de pura efervescencia como el que estamos viviendo en torno a la IA, hemos hablado con José Antonio Gurucelain, responsable de Innovación en Inetum. Conversamos con él sobre un modelo de aplicación de técnicas de IA en el ámbito de AIOps que está generando un impacto muy positivo en las empresas donde se ha implantado.
AIOps es un modelo de operación concebido por Gartner. A grandes rasgos, consiste en aplicar la inteligencia artificial en el área de operaciones de TI para automatizar y agilizar los flujos de trabajo. Esta IA central estaría alimentada por los datos provenientes de las áreas de observabilidad, gestión y automatización. Hasta aquí la teoría.
En la práctica, según nos cuenta Gurucelain, lo que ocurre es que las grandes herramientas de observabilidad (como Dynatrace o Elastic) han integrado su propia IA para anticipar incidencias en función de la información que reciben de los eventos; lo mismo ocurre con los sistemas de gestión (ServiceNow, Helix…), que la utilizan para analizar la información y ver cuáles son los modelos de respuesta disponibles; o con las herramientas como Ansible, con una IA que ayuda a programar automatismos.
“Pero, aunque todas las herramientas integran la IA, el modelo en sí no está integrado. Nosotros enriquecemos ese escenario a través de una caja blanca: Chew”.
Una caja blanca que valide las decisiones
Según investigadores de la universidad de Stanford, si vas a dejar que una caja negra (ChatGPT o Gemini, por ejemplo) tome decisiones de negocio, deberías construir una caja blanca para validar dichas decisiones. Si consigues que esta caja blanca funcione bien, combina las dos.
“¿Dejarías que ChatGPT manejase una central nuclear? Yo creo que la respuesta es muy clara: debería ser no, porque es necesario tener el control sobre esos procesos. Luego poner una caja blanca que te ayude a validar lo que está pasando no parece una mala idea”.
Por un lado, la caja blanca (algoritmos propios) aporta transparencia, explicabilidad, interpretabilidad y control; además, se puede adaptar mejor a entornos específicos. Por contra, una caja negra (como ChatGPT) es mucho más potente en modelos más complejos.
Chew es una solución de caja blanca que unifica los motores de IA y machine learning de cualquier fuente de datos
“No se trata de cuál es mejor. Cada una tiene su aplicación. Pero la realidad es que nos tenemos que poner en medio de tres ejes —observabilidad, gestión ITSM y automatización— e ir enlazando la información que recibimos a través de herramientas hipervitaminadas, que integran sus propias IA. Eso nos obliga a actuar mucho más rápido para evitar demoras en las decisiones”.
Chew es la herramienta que responde a este contexto: una solución de caja blanca que unifica los motores de IA y machine learning de cualquier fuente de datos; proporciona transparencia —con explicaciones para que el usuario pueda entender las razones que hay detrás de cada resultado— y habilita la intervención y el ajuste de esos procesos.
“Por ejemplo, si desde la observabilidad se recibe un mensaje sobre una incidencia determinada y un modo de resolución, nosotros recuperamos la información para confirmar los datos que llevan a esa decisión. Pero, además de entender por qué nos está diciendo eso, y de validar que la decisión que propone es la adecuada, lo adaptamos a los procesos y protocolos internos de cada compañía”.
La idea es que las empresas puedan gestionar bien este escenario. Chew captura y valida la información y, además, proporciona control para decidir qué hacer y cómo.
Primero, entender
Para poner en contexto cómo trabaja Chew, José Antonio Gurucelain nos habló del proyecto desarrollado para la red de comunicaciones de una entidad de ámbito púbico en España, que da servicio a hospitales, instituciones de Justicia, Policía y a los centros públicos gestionados a nivel de Comunidad Autónoma.
Lo primero fue entender qué estaba pidiendo el usuario. A partir de los datos de 20.000 incidentes crearon algoritmos (como los que usa la IA) para “limpiar” esa información: seleccionar solo las palabras importantes, quedarse con el infinitivo de los verbos o buscar entidades nombradas para anonimizarlas (en caso de información personal) o resaltarlas si, por ejemplo, son nombres de aplicaciones y eso les ayuda a entender qué está pasando.
“Por último, hacemos un análisis de frecuencia para saber de qué está hablando el usuario. Aquí es donde está la diferencia. ChatGPT ha sido entrenado con cientos de billones de datos, tiene más de un billón de tokens y decenas de miles de propiedades para cada palabra. Eso le permite entender el contexto y responder ante preguntas de todo tipo ámbitos (tecnología, viajes, educación o cómo hacer magdalenas)”.
Por el contrario, en Chew, Inetum elabora un entrenamiento específico para cada empresa y para una pila tecnológica concreta. De este modo, esos 20.000 incidentes de la red de comunicaciones se terminan concretando en 1320 palabras, con las que son capaces de entender el 100% de lo que está pidiendo el usuario.
“En la gestión de incidencias, el grado de compresión suele estar por encima del 93% o 95%. Pero cuando se trata de alertas o de peticiones siempre se entiende el 100%, porque nadie pide nada que no esté en un catálogo de peticiones”.
Además, como esto genera pocos tokens, no es necesario cargar modelos. En su lugar, a través algoritmos ya existentes —como por ejemplo el TF-IDF (term frequency – inverse document frequency) de Google—, se ha trabajado en entender de qué está hablando un usuario. A partir de ahí, lo han personalizado para darle contexto y adaptarlo a entornos específicos, lo que ofrece un mayor grado de acierto.
“Recientemente, un cliente me dijo que ‘la tendencia es tener muchos tokens y que los tokens son oro’; sin embargo nosotros le damos pocos tokens, pero muy efectivos. Eso no es oro, son diamantes. Somos una mina de diamantes: sacamos las palabras que, en tu entorno y por pila tecnológica, hacen que se entienda lo que necesitas”.
Y después, mucho más
La propuesta diferenciadora va mucho más allá de entender lo que pide el usuario. Lo que se venía haciendo hasta ahora es que, después de interpretar una alerta, entra en juego la hiperautomatización, ya sea de despliegues —de una máquina o una aplicación— o de ejecuciones de algo concreto, lo que exige que un operador lo ponga en marcha.
Pero, según nos cuenta Gurucelain, cuando entiendes lo que pasa, puedes hacer tres cosas adicionales:
- Inferir información adicional. Si a alguien no puede imprimir, puedes buscar el dispositivo que está fallando sin intervención del usuario.
- Diagnosticar el problema que describe a través de automatismos de diagnósticos ya generados, para después inferir la solución de manera automática.
- Por último, en el caso de que no se disponga de una solución, se puede buscar en la documentación interna de la compañía —utilizando algoritmos semánticos internos o apoyándose en la IA generativa— para enviársela al usuario —o a un agente de soporte—, documentándola todo lo posible.
“Por tanto, se trata de entender y, a partir de ahí, plantear las cinco acciones: desplegar, remediar o ejecutar en una petición, inferir, diagnosticar y buscar documentación adicional. Todo ello junto a un adecuado control de los automatismos”.
Chew y AIOps: ejemplo práctico
Durante la charla, el experto de Inetum compartió una demo de Chew aplicado a la resolución de incidencias por parte del área de ITMS. En el ejemplo, un usuario se queja de no ver bien la pantalla. Para la demo se ha activado el contraste alto, que es lo que genera el problema; un detalle que no se facilita en el ticket, cuya formulación es “No me funciona la pantalla. Parece que está mal la resolución…”.
“No es necesario que el usuario nos diga exactamente qué le pasa. Nos basta con que dispare cerca”.
A partir de ahí, lo primero que hace el sistema es identificar al usuario y dónde está conectado; después se encarga, de forma desatendida, de averiguar qué está pasando (tiene el contraste alto), lanzar la corrección correspondiente para solucionar la incidencia y documentar todo el proceso.
“Lo importante no es que lo haya hecho, sino el tiempo que ha tardado: ha resuelto la incidencia en segundos. Esto sería impensable en un modelo tradicional, donde el técnico debe conectarse a la máquina, acceder a la información, diagnosticar el problema, ejecutar la remediación e introducir la información sobre lo que ha pasado en la incidencia”.
No es necesario que el usuario nos diga exactamente qué le pasa. Nos basta con que dispare cerca
En caso de que no pueda o sepa resolver la incidencia, busca la información y transfiere la consulta a una cola de operador. Pero, en este caso, el ticket que este recibe ya está enriquecido e incluye toda la información que se ha podido capturar respecto al usuario, su localización, el dispositivo o herramienta a los que hace referencia, etc. En su caso, incorporaría también indicaciones extraídas de la documentación interna y que pueden ayudar a solventar el problema.
Todo esto hay que verlo desde la perspectiva del área de operaciones de TI, pero que la mayoría de las incidencias se resuelvan en menos de un minuto también mejora la experiencia del usuario y reduce su fricción con el área de sistemas.
El coste de los tokens
Crece el uso de la IA y con él los costes para las empresas. Es cierto que el de cada interacción individual es reducido, pero el volumen de consultas se ha disparado y lo previsible es continuar por ese camino. Esto se traduce en un mayor consumo, tanto de capacidades de computación como de energía.
En el caso de Chew, toda la computación es local y, además, no usa GPU, ya que la base de datos ocupa en torno a 17 MB y en 20 milisegundos ofrece las respuestas utilizando una sola máquina, lo que quiere decir que puede contestar cincuenta preguntas por segundo o 3000 por minuto, todo ello con una sola máquina. Además, estos algoritmos no consumen apenas energía, porque las bases de datos son muy pequeñas.
“Nuestro modelo ayuda a controlar el gasto, pero también a reducir o eliminar la dependencia de terceros. Esto también afecta al plano ético, porque contamos con una explicación del proceso y podemos validar la transacción antes de ejecutarla”.
Primeros pasos y evolución
Implantar Chew en una empresa es un proceso evolutivo, en el que la herramienta “aprende” de los procesos y modelos internos de la compañía para perfeccionarse con cada interacción.
Es lo que se está haciendo en uno de sus clientes, una entidad bancaria de primer nivel en España. Antes de ello se dedicaron varias horas a analizar su backlog para detectar las incidencias más estratégicas. El siguiente paso fue el entrenamiento personalizado de Chew (entender al usuario), un proceso que llevo algo más de dos meses, para después materializarse en una propuesta de estrategia de automatización (dos semanas), que finalmente se puso en producción.
“En un inicio, el objetivo es que el 24% de los incidentes se resuelvan de forma autónoma; aunque hay que tener en cuenta que, en el 40% de las resoluciones automáticas, hay que preguntar al usuario si está satisfecho”.
Por dar unas cifras aproximadas, cuando se trata de incidentes relacionados con el puesto de trabajo se pueden autorremediar entre el 20% y el 30% de los incidentes; en servidores se puede llegar al 40%; en networking los porcentajes llegan al 50% o incluso 70%”.
“Y la lógica es que este porcentaje crezca, porque, aunque los incidentes genéricos se reutilizan, se van añadiendo simultáneamente los particulares de cada empresa. Hemos empezado por grandes organizaciones, pero el objetivo es llegar a las empresas más pequeñas con el 80% de sus problemas ya automatizados”.

































