IA Agêntica
Redes autónomas empiezan en la arquitectura, no en agentes
Alcanzar niveles más altos de autonomía no depende solo de agentes más inteligentes. Depende de preparar datos, procesos, integraciones y contexto para que las decisiones puedan atravesar los distintos dominios de la operación.
Cuando automatizar ya no es suficiente
En el último artículo, discutí una cuestión que empieza a ganar importancia a medida que avanzamos en la adopción de la IA agéntica: ¿estamos realmente preparados para dar autonomía a la inteligencia artificial en entornos críticos? La pregunta surgió de las discusiones que acompañé durante el Telco Transformation Latam y llevó a una reflexión importante.
Cuanto mayor sea la autonomía que pretendemos entregar a los agentes, mayor debe ser nuestra capacidad de ofrecer contexto, gobernanza y seguridad para que comprendan el entorno antes de decidir y actuar.
Pero esa discusión lleva de forma natural a una segunda pregunta: ¿cómo evoluciona, de hecho, una operación hacia niveles más altos de autonomía?
En el sector de Telecom, esta cuestión viene siendo estructurada por el TM Forum a través del recorrido de Autonomous Networks, que establece una referencia para la evolución desde operaciones predominantemente manuales hasta redes capaces de percibir cambios, tomar decisiones y ejecutar acciones con niveles crecientes de autonomía.
El modelo establece seis niveles, de L0 a L5, pero sería una simplificación interpretarlos solo como una escala que mide cuánto ha logrado automatizar una empresa. En los niveles iniciales, las personas todavía tienen una participación significativa en la observación, el análisis y la toma de decisiones. A medida que aumenta la madurez, los sistemas asumen progresivamente algunas de esas funciones. En L2 ya encontramos automatización parcial en ciertos escenarios y, en L3, las máquinas pasan a participar más directamente en el análisis y la decisión, aunque la supervisión humana sigue teniendo un papel relevante.
El salto a L4 es particularmente importante porque involucra operaciones orientadas por intención, análisis predictivo, aprendizaje continuo y closed loops capaces de gestionar servicios con un grado mucho mayor de autonomía.
El propio TM Forum caracteriza esta evolución como un cambio de procesos de automatización previamente definidos por humanos hacia formas efectivas de toma autónoma de decisiones.
Eso no significa que un operador simplemente avance de un nivel a otro hasta que toda su red pueda declararse L4. La evolución ocurre por dominios y escenarios específicos. Una organización puede tener niveles distintos de autonomía en fault management, optimización, aprovisionamiento o assurance, por ejemplo, avanzando progresivamente a medida que logra demostrar seguridad, confiabilidad y valor.
Esta perspectiva también ayuda a evitar una interpretación que tiende a ganar fuerza con la popularización de la IA agéntica: imaginar que llegar a una red autónoma significa simplemente añadir agentes cada vez más sofisticados a la operación.
Un agente puede analizar una falla, consultar sistemas, recomendar un cambio e incluso recibir permiso para ejecutar ciertas acciones. Todo eso puede representar un avance importante, pero la autonomía end-to-end implica un problema mayor, porque los incidentes y los servicios rara vez respetan los límites de los dominios tecnológicos en los que estructuramos nuestras operaciones.
Considere una falla que empieza en la red de acceso, produce síntomas en el transporte, afecta una aplicación y finalmente compromete la experiencia de determinado conjunto de clientes. Podemos tener excelentes mecanismos de automatización en cada una de esas áreas y aun así depender de personas para percibir que las señales observadas en distintas plataformas forman parte del mismo problema. Para avanzar hacia una respuesta autónoma, es necesario comprender las relaciones entre esos componentes, identificar los servicios involucrados y evaluar las consecuencias de una acción antes de ejecutarla.
La arquitectura de referencia del TM Forum refleja esta necesidad al tratar las Autonomous Networks como sistemas orientados por intención, conscientes del contexto y apoyados por conocimiento e inteligencia. La cuestión deja de ser solo dónde podemos colocar un agente y pasa a ser qué proceso o servicio queremos volver progresivamente más autónomo y qué necesita ofrecer la arquitectura para que eso ocurra con seguridad.
Es aquí donde aparece uno de los conceptos más interesantes de la evolución reciente de esta arquitectura: el knowledge plane.
De datos operacionales a conocimiento sobre la operación
Las operaciones de Telecom siempre han producido grandes volúmenes de datos, y ese volumen aumentó significativamente a medida que se incorporaron al entorno nuevas tecnologías y sistemas especializados. Alarmas, métricas, logs, configuraciones, inventarios, topologías, tickets, cambios e información sobre servicios están disponibles en distintas plataformas, muchas veces en tiempo real.
Tener acceso a esos datos, sin embargo, no significa comprender lo que está ocurriendo. Durante un incidente, una plataforma puede registrar pérdida de paquetes mientras otra informa un cambio reciente en un equipo cercano. Un sistema de observabilidad identifica degradación en una aplicación y, poco después, empiezan a surgir reclamos relacionados con determinado servicio. Individualmente, cada información describe una parte de la realidad. El desafío es descubrir cuáles de ellas están relacionadas y qué revela esa combinación sobre el problema.
Es ese el trabajo que los especialistas experimentados realizan a diario. Conocen la arquitectura, saben qué sistemas dependen de otros, recuerdan cambios recientes y reconocen comportamientos aprendidos con el tiempo. Cuando investigan un incidente, no analizan solo los datos disponibles. Interpretan esos datos a partir del conocimiento acumulado sobre esa operación específica.
En artículos anteriores, he llamado a esa diferencia contexto operacional. El conocimiento técnico explica cómo funciona determinada tecnología o qué causas suelen producir determinado tipo de falla. El contexto operacional explica cómo esa tecnología está inserta en ese entorno, qué componentes se relacionan con ella, qué cambió recientemente y qué servicios pueden verse afectados.
En 2026, el TM Forum profundizó el concepto de knowledge plane como una capa capaz de transformar datos fragmentados en conocimiento contextualizado y reutilizable, permitiendo que distintos sistemas y agentes usen ese conocimiento para razonar, coordinar acciones entre dominios y producir decisiones más explicables.
La propuesta apunta a un cambio importante: las operaciones más autónomas necesitan administrar no solo datos y procesos, sino también el conocimiento producido continuamente a partir de ellos.
Existe una convergencia importante entre esta propuesta y el concepto de contexto operacional. En términos prácticos, una de las funciones esenciales de una capa de conocimiento es permitir que las señales observadas en ese momento se interpreten a partir de lo que ya se conoce sobre la arquitectura, las relaciones, las dependencias, los servicios y el historial de ese entorno.
Si cierto equipo presenta una falla, por ejemplo, no basta con conocer el evento registrado por él. Para comprender el incidente, puede ser necesario saber qué componentes dependen de ese recurso, qué servicios utilizan ese camino, qué cambios ocurrieron recientemente y si otras señales observadas en distintas plataformas representan síntomas del mismo problema. Son esas relaciones las que ayudan a transformar una colección de informaciones en conocimiento operacional útil para una decisión.
Ese conocimiento también necesita acompañar la propia dinámica del entorno. Las redes cambian continuamente, las configuraciones se alteran, se añaden elementos, los servicios migran entre infraestructuras y surgen nuevas dependencias.
Si sistemas progresivamente más autónomos utilizan esas relaciones para tomar decisiones, la calidad y la actualización del contexto pasan a influir directamente en la confiabilidad de esas decisiones.
El desafío de los entornos legados y de múltiples proveedores
El desafío se vuelve aún mayor porque los operadores no están construyendo esta arquitectura desde una hoja en blanco. Décadas de inversiones produjeron entornos formados por OSS, BSS, sistemas de inventario, herramientas de monitoreo y observabilidad, automatizaciones, plataformas de atención y tecnologías de distintos proveedores. Parte del conocimiento operacional también puede estar en los procedimientos desarrollados por los equipos, en el historial de incidentes y en la experiencia acumulada por los especialistas.
Preparar una operación para niveles más altos de autonomía implica, por lo tanto, algunas acciones fundacionales que pueden parecer menos sofisticadas que implantar nuevos agentes, pero que son igualmente importantes: integrar herramientas, organizar datos, exponer APIs, representar relaciones y dependencias y crear mecanismos para que ese conocimiento pueda ser utilizado por distintas partes de la operación.
Hay también una consecuencia estratégica. Las herramientas cambian, los modelos de IA evolucionan y se incorporarán nuevos agentes al entorno. Pero la arquitectura, las dependencias, el historial, los servicios y las relaciones que caracterizan a esa operación pertenecen a la propia organización. Por eso, el conocimiento operacional necesita permanecer disponible y reutilizable, independientemente de la tecnología específica que se esté usando para analizarlo.
Esta tal vez sea una de las implicaciones más interesantes del concepto de knowledge plane: permitir que personas, automatizaciones y distintas formas de inteligencia trabajen sobre una comprensión más consistente de la misma operación, como profundizo en El camino hacia las redes autónomas pasa por el contexto operacional compartido.
El recorrido hacia la autonomía empieza antes de la autonomía
Si la evolución hacia redes autónomas exige una arquitectura capaz de organizar conocimiento y contexto, la siguiente cuestión es definir por dónde empezar. Y aquí hay una característica importante en el enfoque del TM Forum: los niveles más altos de autonomía no necesitan surgir como resultado de un gran proyecto que transforme toda la red simultáneamente.
La evolución puede comenzar por escenarios concretos. Fault management es un buen ejemplo. Un incidente puede generar decenas o cientos de alarmas distribuidas entre distintas plataformas, exigiendo que los especialistas identifiquen relaciones, evalúen dependencias, investiguen cambios recientes, estimen el impacto y decidan qué acción ejecutar. Hacer que ese proceso sea progresivamente más autónomo significa mejorar no solo la ejecución de la respuesta, sino principalmente la capacidad de comprender el incidente antes de actuar.
Automatizar solo la última etapa puede simplemente aumentar la velocidad con la que se ejecuta una decisión inadecuada. La autonomía necesita construirse sobre una capacidad creciente de percibir, correlacionar, comprender y evaluar consecuencias. Por eso, los procesos conocidos, bien comprendidos y de menor riesgo pueden recibir inicialmente niveles mayores de autonomía, mientras que las situaciones críticas o ambiguas siguen dependiendo de la participación humana.
Este enfoque también ayuda a evitar que Autonomous Networks se convierta en una carrera tecnológica para alcanzar determinado nivel de madurez. El objetivo no debería ser llegar a L4 solo porque el mercado estableció ese nivel como referencia. El avance necesita producir resultados concretos para la operación y para el negocio.
En junio de 2026, el TM Forum informó que el 81% de los operadores consultados pretende alcanzar L4 o niveles superiores hasta 2030. Al mismo tiempo, la discusión deja de estar motivada solo por la reducción de costos y la eficiencia operacional y pasa a incorporar objetivos como resiliencia, calidad de los servicios, experiencia del cliente y capacidad de introducir nuevos servicios con menor complejidad.
Eso coloca el recorrido en una perspectiva más adecuada. Llegar a L4 no depende de encontrar un modelo de IA suficientemente poderoso ni de implantar una plataforma capaz de resolver toda la operación. Exige una evolución combinada de arquitectura, datos, procesos, conocimiento y gobernanza, aplicada progresivamente a los escenarios en los que la autonomía pueda generar valor.
Los agentes de IA tendrán un papel importante en esta transformación, pero agentes más capaces no eliminan los problemas estructurales que ya existen en la operación. Si los datos permanecen fragmentados y las relaciones importantes no están disponibles, la inteligencia también trabajará a partir de una comprensión fragmentada.
Por eso quizá la principal transformación necesaria para llegar a las redes autónomas ocurra antes de la propia autonomía. Necesitamos construir operaciones capaces de representar continuamente su realidad, conectando datos, relaciones y conocimiento de forma que puedan ser comprendidos por las personas, por las automatizaciones actuales y por los agentes que progresivamente participarán en las decisiones.
Las redes autónomas no empiezan cuando damos a los agentes permiso para actuar. Empiezan cuando construimos una arquitectura capaz de proporcionar conocimiento y contexto suficientes para que las decisiones autónomas puedan tomarse con confianza.
Esa es la base sobre la que la autonomía podrá crecer de forma progresiva, sin perder de vista lo que realmente importa: hacer la operación más eficiente, confiable y capaz de responder a las necesidades de los servicios que sustenta.
De la visión a la práctica: ARGUS
La evolución hacia redes autónomas exige más que introducir agentes de IA capaces de ejecutar tareas especializadas. Para que los distintos componentes de la operación puedan actuar de manera coordinada, es necesario construir una base de conocimiento compartido sobre el estado de la red, sus relaciones y sus dependencias.
Esa necesidad está directamente relacionada con el concepto de knowledge plane discutido por el TM Forum y también con la propuesta de ARGUS.
A través de sus capacidades de AIOps, ARGUS conecta información de distintas fuentes operacionales, correlaciona eventos, incorpora reglas y relaciones conocidas del entorno y ayuda a transformar señales distribuidas en contexto operacional compartido. Ese contexto puede apoyar a especialistas, automatizaciones y agentes que necesitan comprender la situación antes de recomendar o ejecutar acciones.
ARGUS no pretende representar, por sí solo, todos los componentes de un knowledge plane. Su contribución está en una capa relevante de esa arquitectura: relacionar información operacional y poner a disposición de distintas formas de inteligencia una comprensión más consistente del entorno.
Con AgentOps y AI Gateway, esta propuesta puede ampliarse para incluir también la orquestación, la observabilidad y la gobernanza de los agentes que pasan a participar en la operación.
La combinación entre conocimiento operacional compartido y mecanismos de control sobre la actuación de los agentes es una de las condiciones para avanzar en el recorrido de la autonomía sin multiplicar los silos de información y decisión.
En el próximo artículo, profundizaré en una consecuencia de esta transformación: cuantos más agentes especializados pongamos en la operación, mayor puede ser el riesgo de crear nuevos silos de inteligencia.
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.