IA Agêntica
Las redes autónomas exigen contexto operacional compartido
Los datos pueden estar disponibles en decenas de plataformas y, aun así, ninguna de ellas tener una visión completa de lo que está ocurriendo. Para que personas, automatizaciones y agentes puedan decidir mejor, es necesario transformar información fragmentada en una comprensión compartida de la operación.
Tener todos los datos no significa comprender lo que está ocurriendo
En los últimos artículos, he discutido algunos de los cambios que la inteligencia artificial empieza a producir en las operaciones de TI y Telecom. Hablamos sobre autonomía, sobre la arquitectura necesaria para soportarla, sobre el riesgo de crear nuevos silos a medida que los agentes especializados se multiplican y, más recientemente, sobre cuánto control estamos preparados para entregar a esos agentes.
Existe, sin embargo, una cuestión que atraviesa prácticamente todas esas discusiones y que quizá sea anterior a la propia inteligencia artificial: ¿cómo construir una comprensión suficientemente consistente de lo que está ocurriendo en la operación?
En entornos complejos, la información rara vez está concentrada en un solo lugar. Una plataforma monitorea equipos e interfaces, otra acompaña aplicaciones, las herramientas de observabilidad recolectan métricas, traces y logs, el ITSM registra incidentes y cambios, mientras que otros sistemas tienen información sobre inventario, topología, seguridad, clientes o desempeño. Cada uno puede cumplir muy bien su función y, aun así, ninguno ve por sí solo el problema completo.
Durante un incidente, esa fragmentación se vuelve particularmente evidente. Un equipo puede generar una secuencia de alarmas, otra plataforma identificar degradación en componentes relacionados, el sistema de observabilidad percibir un cambio en el comportamiento de una aplicación y el ITSM registrar tickets asociados al mismo servicio. Individualmente, todas esas señales pueden ser correctas. El desafío es descubrir cuáles forman parte del mismo problema, cuáles son consecuencias y qué ayuda realmente a explicar lo que ocurrió.
A lo largo de los años, invertimos mucho en ampliar la visibilidad sobre infraestructura, aplicaciones y servicios. Eso fue esencial para lidiar con entornos cada vez más distribuidos y dinámicos. Pero aumentar la cantidad de señales disponibles no elimina el esfuerzo necesario para interpretarlas. En algunos casos produce el efecto contrario: tenemos más información y, al mismo tiempo, más trabajo para descubrir qué información importa.
Por eso una visión única de la operación no debería confundirse con poner todos los datos en la misma pantalla.
Una visión compartida no surge cuando logramos ver toda la información en el mismo lugar. Surge cuando logramos comprender las relaciones entre ellas.
Imagine que tres plataformas informan una falla en un componente de red, una degradación en determinada aplicación y un aumento en el número de reclamos relacionados con un servicio. Reunir los tres registros mejora la visibilidad, pero no responde a la pregunta principal: ¿existe una relación entre ellos? Para eso, necesitamos comprender dependencias, cambios recientes, el comportamiento de elementos relacionados y otras características específicas de ese entorno.
Es en ese proceso donde empezamos a pasar de la observación de los datos a la construcción de contexto operacional.
Hoy, buena parte de ese trabajo todavía lo realizan las propias personas. Un especialista experimentado no mira solo la alarma que aparece en la pantalla. Conoce la arquitectura, recuerda cambios recientes, entiende dependencias, reconoce patrones y consulta distintos sistemas para completar aquello que todavía no logra explicar.
Una parte importante del contexto de la operación existe, por lo tanto, en la combinación entre lo que informan las herramientas y lo que las personas saben relacionar. Eso se vuelve una limitación cuando pretendemos aumentar la automatización y, sobre todo, cuando los agentes de IA empiezan a participar en el análisis, la decisión y la ejecución.
Si queremos que los sistemas comprendan lo suficiente para decidir, necesitamos hacer explícita una parte del contexto que hoy todavía se construye de forma implícita por las personas.
El contexto operacional no es un dato que está esperando ser encontrado
Con la popularización de los LLM, el RAG, las bases vectoriales y los agentes capaces de consultar distintas fuentes, se volvió más fácil imaginar sistemas que busquen la información necesaria antes de responder o tomar una decisión. Esa capacidad es extremadamente útil, pero existe una diferencia importante entre recuperar información y construir contexto.
Un documento puede explicar cómo funciona determinado equipo. Una base de conocimiento puede contener procedimientos para una falla conocida. Un historial puede mostrar cómo se resolvieron incidentes parecidos. Todo eso enriquece el análisis, pero no representa necesariamente el estado actual de esa operación.
El contexto necesita combinar ese conocimiento relativamente estable con lo que está ocurriendo ahora: eventos recientes, estado de los componentes, cambios realizados, relaciones entre recursos y servicios, dependencias conocidas e información proveniente de distintas plataformas.
Por eso, el contexto operacional no debería tratarse solo como una base de datos más. Es el resultado de un proceso continuo de construcción y actualización.
Considere un ejemplo simple. Una alarma informa que el componente A presentó una falla. Una relación conocida muestra que B depende de A. Otra herramienta identifica degradación en B y un tercer sistema registra impacto en un servicio C, que utiliza B. Por separado, tenemos tres informaciones. Relacionadas, producen una hipótesis operacional mucho más útil sobre la cadena de consecuencias de ese incidente.
En este ejemplo, parte del contexto fue producida dinámicamente por los eventos y parte vino de conocimiento ya existente sobre el entorno. Esa combinación es importante porque no todo necesita ser inferido por la inteligencia artificial.
Una organización ya conoce muchas características determinísticas de su operación: dependencias entre componentes, recursos que soportan ciertos servicios, relaciones conocidas entre eventos y condiciones que deben considerarse durante una investigación. Hacer que ese conocimiento esté explícitamente disponible evita que un modelo tenga que redescubrir, en cada incidente, lo que la propia empresa ya sabe. Al mismo tiempo, los entornos cambian y surgen nuevas correlaciones, lo que exige combinar continuamente ese conocimiento con información dinámica.
Esta discusión empieza a aparecer de manera cada vez más explícita en las arquitecturas orientadas a operaciones autónomas. En agosto de 2026, el TM Forum publicó la guía Context Management for AI-Native Operations, que trata el contexto como la información necesaria para comprender lo que está ocurriendo y decidir qué hacer. La propuesta busca hacer más explícito un proceso que aún depende fuertemente de los profesionales del NOC: reunir información de múltiples fuentes, relacionarla, construir una visión coherente de la situación y ponerla a disposición de distintos sistemas y agentes.
El concepto se aproxima a otra discusión que abordamos antes, el knowledge plane, una capa destinada a transformar datos fragmentados en conocimiento contextualizado y reutilizable por distintas formas de inteligencia. Son perspectivas complementarias: una enfatiza la construcción y gestión del contexto; la otra, una arquitectura capaz de representar y reutilizar conocimiento operacional.
Hay una consecuencia especialmente importante para operaciones críticas: ese conocimiento no necesita estar compuesto solo por inferencias producidas por IA. Relaciones determinísticas, reglas, políticas, modelos y conocimiento acumulado sobre el entorno también pueden participar en esa construcción.
Cuanto más confiable sea esa combinación, mejores serán las condiciones para que personas, automatizaciones y agentes interpreten la misma situación antes de decidir qué hacer.
El contexto debe pertenecer a la operación, no a una herramienta
Cuando empezamos a tratar el contexto como parte de la arquitectura operacional, surge otra cuestión: ¿dónde debe existir ese contexto?
Una herramienta de observabilidad conoce sus aplicaciones, un sistema de red conoce sus elementos, el ITSM conoce incidentes y cambios y, progresivamente, cada una de esas plataformas podrá incorporar sus propios agentes y mecanismos de inteligencia. Si el contexto permanece restringido a cada una de ellas, sin embargo, corremos el riesgo de reproducir en la inteligencia artificial la misma fragmentación que ya existe entre las herramientas.
Como discutimos en el artículo anterior sobre silos de inteligencia, los agentes especializados seguirán siendo importantes. El problema aparece cuando una decisión depende de información que atraviesa redes, aplicaciones, cloud, seguridad, ITSM y otros dominios.
El contexto operacional compartido no significa necesariamente construir una enorme base central con todos los datos de la empresa. Significa crear mecanismos capaces de relacionar información y poner a disposición de quien la necesite una comprensión suficientemente consistente de la situación.
Las fuentes siguen existiendo, los sistemas especializados siguen cumpliendo sus funciones y los agentes pueden permanecer distribuidos. Lo que necesita atravesar esos entornos es el significado operacional necesario para comprender cómo lo que ocurre en una parte puede estar relacionado con lo que se observa en otra.
Esa necesidad aparece también en la evolución de las arquitecturas de Autonomous Networks del TM Forum, que van de la inteligencia dentro de dominios específicos hacia la coordinación cross-domain. Pero el problema no es exclusivo de los operadores de Telecom ni depende de la adopción integral de esa arquitectura. Cualquier operación compleja formada por múltiples tecnologías y herramientas enfrenta alguna versión del mismo desafío.
Es también por eso que el contexto operacional debería tratarse como un activo de la organización, y no como propiedad de determinada herramienta o agente.
Las herramientas serán reemplazadas, los modelos de IA evolucionarán y se incorporarán nuevos agentes. La arquitectura, los servicios, las dependencias, el historial y el conocimiento acumulado sobre cómo funciona esa operación, sin embargo, siguen perteneciendo a la empresa. Preservar ese conocimiento de forma reutilizable crea una base sobre la cual distintas formas de inteligencia pueden trabajar.
Un especialista puede utilizarlo para investigar un incidente, una automatización puede consultarlo antes de ejecutar una acción y un agente puede incorporarlo a su razonamiento antes de producir una recomendación. Eso no significa que todos deban recibir exactamente la misma información. La gobernanza, la seguridad y la finalidad siguen determinando a qué puede acceder cada persona o sistema.
Durante años, gran parte del esfuerzo de integración se concentró en hacer que los sistemas intercambiaran datos. Las APIs y los conectores siguen siendo esenciales, pero la autonomía exige algo adicional: los sistemas necesitan poder utilizar esos datos dentro de una comprensión coherente de la situación en la que están actuando.
Es en este punto donde integración y contexto dejan de ser sinónimos.
Podemos integrar decenas de plataformas y seguir teniendo interpretaciones aisladas. Podemos reunir millones de eventos y seguir dependiendo de una persona para descubrir cuáles forman parte del mismo problema. Podemos poner todos esos datos a disposición de un agente sofisticado y aun así exigirle que reconstruya por sí solo las relaciones que explican esa operación.
El salto ocurre cuando logramos transformar esa información en una representación operacional continuamente enriquecida y compartible.
El camino hacia las redes autónomas no pasa solo por hacer los sistemas más inteligentes. Pasa por permitir que distintas inteligencias comprendan la misma operación.
Este principio conecta las discusiones de los últimos artículos. La autonomía exige confianza, la confianza depende de la calidad de las decisiones y las mejores decisiones dependen no solo del conocimiento técnico de un agente, sino también de la calidad del contexto disponible sobre ese entorno en ese momento.
De la visión a la práctica: ARGUS
En una operación de red, distintas herramientas pueden presentar información correcta sobre sus respectivos dominios y, aun así, ninguna ofrecer una comprensión suficiente del problema como un todo. Esa limitación se vuelve más importante a medida que automatizaciones y agentes pasan a participar en las decisiones.
Es en este escenario donde se conecta la propuesta de ARGUS. La plataforma actúa sobre las herramientas existentes, integrando y correlacionando información de distintas fuentes y relacionando lo que se está observando con el conocimiento previamente estructurado sobre componentes, servicios y dependencias de la operación.
El resultado es la construcción de un contexto operacional que no se limita a reunir datos en un único entorno. Busca representar cómo se relacionan los distintos elementos y cómo esas relaciones ayudan a interpretar eventos, cambios e incidentes.
Este enfoque converge con necesidades presentes en los conceptos de Context Management y knowledge plane discutidos por el TM Forum. ARGUS no sustituye esas arquitecturas más amplias, pero puede contribuir a su implementación al poner a disposición contexto operacional compartido para especialistas, automatizaciones y agentes de IA.
Con AgentOps, la propuesta también contempla el seguimiento y la gobernanza de los agentes que utilizan ese contexto para actuar en la operación.
El desafío de las redes autónomas, por lo tanto, no es solo permitir que más agentes ejecuten actividades. Es garantizar que puedan trabajar sobre una comprensión suficientemente consistente de la red, con mecanismos adecuados de coordinación y control.
Conozca ARGUS y vea cómo funciona en la práctica.
Sobre el autor
Paulo Florêncio de Menezes es emprendedor, socio y cofundador de empresas como Target Solutions, BiPTT y ARGUS.
Es graduado en Procesamiento de Datos por la Universidad Federal del Amazonas (UFAM), tiene un MBA en Gestión Empresarial por la Fundação Dom Cabral (FDC) y una Maestría Profesional en Economía por la Fundação Getulio Vargas (FGV).
En su investigación de Maestría, desarrolló el IBEOP-IA (Índice Brasileño de Exposición Ocupacional Potencial a la Inteligencia Artificial), investigando la exposición potencial de las ocupaciones brasileñas a las capacidades de la IA mediante la combinación de datos ocupacionales, patentes de inteligencia artificial y técnicas de procesamiento de lenguaje natural.