Se cerró el Innovate Americas hace unos días, y volvió sobre el foco que ya hacía fuerza desde el DTW Ignite en junio: The Future. Faster. El llamado de TM Forum fue llevar la innovación tecnológica a la operación, con resultados que impacten el negocio. Para esto, un tema central fue la confianza en la inteligencia artificial.
Para Latinoamérica, el debate llega en un momento interesante. La automatización de OSS gana espacio en las conversaciones de los operadores, mientras distintas iniciativas de datos e inteligencia artificial empiezan a tomar forma. Sin embargo, se mantiene la desconfianza en la IA como una barrera natural ante la entrada de esta tecnología en las operaciones.
Cuándo confiar para tomar decisiones
La confianza tiene su justo lugar en esta discusión. No es lo mismo usar IA para resumir información o asistir a un operador que permitirle recomendar cambios sobre una red, ejecutar acciones correctivas o intervenir en procesos que afectan a miles de clientes.
En estos últimos casos, no alcanza con que el modelo produzca una respuesta razonable. Es necesario saber con qué información trabajó, si esa información representa correctamente el estado de la operación, qué reglas limitan sus decisiones y cómo verificar el resultado de las acciones que ejecuta.
Para avanzar en esa dirección no es necesario empezar por los casos de uso más ambiciosos. Se puede partir por procesos acotados, con objetivos medibles y mecanismos de supervisión. Lo importante es que cada paso permita construir capacidades reutilizables, en lugar de sumar scripts y automatizaciones aisladas que después sean difíciles de mantener o integrar.
Innovate Americas reforzó esta perspectiva. Entre sus sesiones se discutieron justamente los mecanismos para llevar la gobernanza de la IA a la práctica y convertir los datos en productos confiables, preparados para alimentar aplicaciones a escala.
Latinoamérica a distintos ritmos
En la región, estos debates conviven con realidades muy diferentes. Hay operadores que llevan años automatizando determinados procesos, otros que están modernizando sus plataformas OSS y muchos otros que necesitan resolver cuestiones previas de integración y calidad de datos antes de implementar nuevas iniciativas.
Sin embargo, empieza a notarse un cambio en las conversaciones sobre tecnología y negocio. La automatización OSS resulta cada vez más relevante para mejorar los tiempos de resolución, disminuir errores y dar mejores respuestas a las necesidades de clientes.
Algo similar pasa con la IA y las redes autónomas. Algunos operadores están trabajando en sus plataformas de datos y sus data lakes, otros avanzan en modelos analíticos, asistentes o aplicaciones específicas, y otros se encuentran definiendo prioridades y casos de uso. No existe una única secuencia ni todos parten del mismo lugar, pero sí hay una búsqueda compartida: encontrar aplicaciones que les aporten valor en base a los datos que ya tienen en sus redes, y que puedan extenderse más allá de una prueba de concepto.
Como en toda transformación tecnológica de esta industria, avanzar es un desafío grande mientras se mantienen en funcionamiento redes y sistemas de distintas generaciones. Por eso, adoptar las tendencias globales significa identificar qué capacidades son prioritarias, cuáles son las dependencias que pueden frenar su desarrollo y cómo aprovechar las plataformas existentes. En ese contexto, los estándares como Open APIs y Open Digital Architecture pueden ayudar a establecer modelos comunes de integración e información, facilitando que distintas plataformas y proveedores trabajen juntos sin convertir cada nuevo proyecto en una integración a medida.
La confianza empieza antes del modelo
Para que estas iniciativas funcionen, hay una condición que suele vivir en segundo plano hasta que hay que enfrentarse a ella: los datos deben representar correctamente la realidad sobre la que se pretende actuar. No alcanza con tener grandes volúmenes de información disponibles ni con reunirlos en un data lake. Si los datos están incompletos, desactualizados o describen una misma realidad de maneras diferentes, los modelos van a heredar esas limitaciones. Y si cada aplicación necesita corregir, completar o interpretar la información por su cuenta, escalar se hace difícil.
En una telco, además, los datos no son una colección de elementos independientes. Una placa pertenece a un equipo, un equipo forma parte de un sitio, una conexión vincula recursos de distintos dominios y un servicio depende de varios de esos componentes. También importa dónde está cada elemento, qué representa dentro de la red y qué otros servicios podrían verse afectados si cambia su estado. Para entender una incidencia, planificar una modificación o decidir cómo actuar, es necesario conocer esas relaciones, no solamente disponer de una lista de recursos.
Por eso, hace falta un modelo común que permita representar los recursos y servicios de manera consistente, relacionarlos entre sí y mantener esas relaciones actualizadas a medida que la red evoluciona. Una estructura basada en grafos, por ejemplo, permite representar de forma natural las conexiones y jerarquías entre elementos, mientras que la información geográfica aporta otra dimensión necesaria para localizar recursos y entender su distribución. La representación de los elementos también debe ser consistente entre dominios, de modo que los sistemas puedan reconocerlos y relacionarlos sin depender de interpretaciones particulares de cada aplicación.
Es ahí donde el inventario del operador gana una relevancia que va más allá de registrar qué equipos tiene. Un gestor de inventario que abarque recursos, servicios y sus relaciones puede convertirse en la referencia común sobre la que se construyan los modelos y las aplicaciones de la operación. En otras palabras, una single source of truth o única fuente de verdad, en oposición a la existencia de muchos inventarios que no se hablen entre ellos y manejen datos incompatibles.
Si cada dominio mantiene su propio inventario, con estructuras y criterios diferentes, cualquier iniciativa transversal tendrá que resolver esas diferencias antes de poder actuar. En cambio, una base común permite que distintas aplicaciones consulten la misma representación de la operación y la usen para sus propios objetivos. Una herramienta de gestión de fallas podría relacionar una incidencia con los servicios afectados, un proceso de provisión podría verificar las dependencias de un recurso antes de ejecutar un cambio, y un modelo de IA podría utilizar ese contexto para elaborar un diagnóstico o recomendar una acción. Cada caso necesitaría sus propias reglas y fuentes, pero no tendría que reconstruir las relaciones de la red.
Esto no significa que un inventario por sí mismo garantice el éxito de una iniciativa de IA. También es necesario definir responsabilidades sobre la información, establecer cómo se actualiza y validar que lo representado coincida con la realidad. Sin embargo, contar con una referencia consistente de los recursos, servicios y sus relaciones es una condición necesaria para que las aplicaciones que se construyan sobre esa base puedan operar.
A medida que crece el interés por la automatización OSS y la IA, esta revisión merece un lugar en la agenda. Antes de sumar otro modelo o aplicación, es necesario comprobar qué datos lo van a alimentar, dónde los obtiene y qué tan confiables son. Al final, la confianza en la IA no solo se construye validando modelos o controlando decisiones, sino también asegurándose de que la información sobre la que opera represente fielmente la realidad, porque difícilmente podamos confiar en las decisiones de un sistema si no podemos confiar en los datos con los que las toma.
