IA Agêntica
Redes autônomas não começam com agentes: começam com uma arquitetura preparada para autonomia
Chegar a níveis mais elevados de autonomia não depende apenas de agentes mais inteligentes. Depende de preparar dados, processos, integrações e contexto para que decisões possam atravessar diferentes domínios da operação.
Quando automatizar já não é suficiente
No último artigo, discuti uma questão que começa a ganhar importância à medida que avançamos na adoção da IA agêntica: estamos realmente preparados para dar autonomia à inteligência artificial em ambientes críticos? A pergunta surgiu a partir das discussões que acompanhei durante o Telco Transformation Latam e levou a uma reflexão importante.
Quanto maior a autonomia que pretendemos entregar aos agentes, maior precisa ser nossa capacidade de oferecer contexto, governança e segurança para que eles compreendam o ambiente antes de decidir e agir.
Mas essa discussão leva naturalmente a uma segunda pergunta: como uma operação evolui, de fato, até níveis mais elevados de autonomia?
No setor de Telecom, essa questão vem sendo estruturada pelo TM Forum por meio da jornada de Autonomous Networks, que estabelece uma referência para a evolução desde operações predominantemente manuais até redes capazes de perceber mudanças, tomar decisões e executar ações com níveis crescentes de autonomia.
O modelo estabelece seis níveis, do L0 ao L5, mas seria uma simplificação interpretá-los apenas como uma escala que mede quanto uma empresa já conseguiu automatizar. Nos níveis iniciais, as pessoas ainda possuem participação significativa na observação, análise e tomada de decisão. À medida que a maturidade aumenta, os sistemas assumem progressivamente algumas dessas funções. No L2 já encontramos automação parcial em determinados cenários e, no L3, as máquinas passam a participar mais diretamente da análise e da decisão, embora a supervisão humana continue tendo papel relevante.
O salto para o L4 é particularmente importante porque envolve operações orientadas por intenção, análise preditiva, aprendizado contínuo e closed loops capazes de gerenciar serviços com um grau muito maior de autonomia.
O próprio TM Forum caracteriza essa evolução como uma mudança de processos de automação previamente definidos por humanos para formas efetivas de tomada autônoma de decisão.
Isso não significa que uma operadora simplesmente avance de um nível para outro até que toda a sua rede possa ser declarada L4. A evolução acontece por domínios e cenários específicos. Uma organização pode possuir níveis diferentes de autonomia em fault management, otimização, provisionamento ou assurance, por exemplo, avançando progressivamente à medida que consegue demonstrar segurança, confiabilidade e valor.
Essa perspectiva também ajuda a evitar uma interpretação que tende a ganhar força com a popularização da IA agêntica: imaginar que chegar a uma rede autônoma significa simplesmente adicionar agentes cada vez mais sofisticados à operação.
Um agente pode analisar uma falha, consultar sistemas, recomendar uma alteração e até receber permissão para executar determinadas ações. Tudo isso pode representar um avanço importante, mas autonomia end-to-end envolve um problema maior, porque os incidentes e os serviços raramente respeitam os limites dos domínios tecnológicos nos quais estruturamos nossas operações.
Considere uma falha que começa na rede de acesso, produz sintomas no transporte, afeta uma aplicação e finalmente compromete a experiência de determinado conjunto de clientes. Podemos ter excelentes mecanismos de automação em cada uma dessas áreas e ainda depender de pessoas para perceber que os sinais observados em diferentes plataformas fazem parte do mesmo problema. Para avançar em direção a uma resposta autônoma, é necessário compreender as relações entre esses componentes, identificar os serviços envolvidos e avaliar as consequências de uma ação antes de executá-la.
A arquitetura de referência do TM Forum reflete essa necessidade ao tratar as Autonomous Networks como sistemas orientados por intenção, conscientes de contexto e apoiados por conhecimento e inteligência. A questão deixa de ser apenas onde podemos colocar um agente e passa a ser qual processo ou serviço queremos tornar progressivamente mais autônomo e o que a arquitetura precisa oferecer para que isso aconteça com segurança.
É nesse ponto que aparece um dos conceitos mais interessantes na evolução recente dessa arquitetura: o knowledge plane.
De dados operacionais a conhecimento sobre a operação
Operações de Telecom sempre produziram grandes volumes de dados, e esse volume aumentou significativamente à medida que novas tecnologias e sistemas especializados foram incorporados ao ambiente. Alarmes, métricas, logs, configurações, inventários, topologias, tickets, mudanças e informações sobre serviços estão disponíveis em diferentes plataformas, muitas vezes em tempo real.
Ter acesso a esses dados, entretanto, não significa compreender o que está acontecendo. Durante um incidente, uma plataforma pode registrar perda de pacotes enquanto outra informa uma alteração recente em um equipamento próximo. Um sistema de observabilidade identifica degradação em uma aplicação e, pouco depois, começam a surgir reclamações relacionadas a determinado serviço. Individualmente, cada informação descreve uma parte da realidade. O desafio é descobrir quais delas estão relacionadas e o que essa combinação revela sobre o problema.
É esse trabalho que especialistas experientes realizam diariamente. Eles conhecem a arquitetura, sabem quais sistemas dependem de outros, lembram de mudanças recentes e reconhecem comportamentos aprendidos ao longo do tempo. Quando investigam um incidente, não analisam apenas os dados disponíveis. Interpretam esses dados a partir do conhecimento acumulado sobre aquela operação específica.
Nos artigos anteriores, tenho chamado essa diferença de contexto operacional. O conhecimento técnico explica como determinada tecnologia funciona ou quais causas normalmente produzem determinado tipo de falha. O contexto operacional explica como aquela tecnologia está inserida naquele ambiente, quais componentes se relacionam com ela, o que mudou recentemente e quais serviços podem ser afetados.
Em 2026, o TM Forum aprofundou o conceito de knowledge plane como uma camada capaz de transformar dados fragmentados em conhecimento contextualizado e reutilizável, permitindo que diferentes sistemas e agentes utilizem esse conhecimento para raciocinar, coordenar ações entre domínios e produzir decisões mais explicáveis.
A proposta aponta para uma mudança importante: operações mais autônomas precisam administrar não apenas dados e processos, mas também o conhecimento produzido continuamente a partir deles.
Existe uma convergência importante entre essa proposta e o conceito de contexto operacional. Em termos práticos, uma das funções essenciais de uma camada de conhecimento é permitir que os sinais observados naquele momento sejam interpretados a partir do que já se conhece sobre a arquitetura, as relações, as dependências, os serviços e o histórico daquele ambiente.
Se determinado equipamento apresenta uma falha, por exemplo, não basta conhecer o evento registrado por ele. Para compreender o incidente, pode ser necessário saber quais componentes dependem daquele recurso, quais serviços utilizam aquele caminho, quais mudanças ocorreram recentemente e se outros sinais observados em diferentes plataformas representam sintomas do mesmo problema. São essas relações que ajudam a transformar uma coleção de informações em conhecimento operacional útil para uma decisão.
Esse conhecimento também precisa acompanhar a própria dinâmica do ambiente. Redes mudam continuamente, configurações são alteradas, elementos são adicionados, serviços migram entre infraestruturas e novas dependências surgem.
Se sistemas progressivamente mais autônomos utilizarem essas relações para tomar decisões, a qualidade e a atualização do contexto passam a influenciar diretamente a confiabilidade dessas decisões.
O desafio se torna ainda maior porque as operadoras não estão construindo essa arquitetura a partir de uma folha em branco. Décadas de investimentos produziram ambientes formados por OSS, BSS, sistemas de inventário, ferramentas de monitoramento e observabilidade, automações, plataformas de atendimento e tecnologias de diferentes fornecedores. Parte do conhecimento operacional também pode estar nos procedimentos desenvolvidos pelas equipes, no histórico de incidentes e na experiência acumulada por especialistas.
Preparar uma operação para níveis mais elevados de autonomia envolve, portanto, algumas ações fundacionais que podem parecer menos sofisticadas do que implantar novos agentes, mas são igualmente importantes: integrar ferramentas, organizar dados, disponibilizar APIs, representar relações e dependências e criar mecanismos para que esse conhecimento possa ser utilizado por diferentes partes da operação.
Há também uma consequência estratégica. Ferramentas mudam, modelos de IA evoluem e novos agentes serão incorporados ao ambiente. Mas a arquitetura, as dependências, o histórico, os serviços e as relações que caracterizam aquela operação pertencem à própria organização. Por isso, o conhecimento operacional precisa permanecer disponível e reutilizável, independentemente da tecnologia específica que estiver sendo utilizada para analisá-lo.
Essa talvez seja uma das implicações mais interessantes do conceito de knowledge plane: permitir que pessoas, automações e diferentes formas de inteligência trabalhem sobre uma compreensão mais consistente da mesma operação.
A jornada para autonomia começa antes da autonomia
Se a evolução para redes autônomas exige uma arquitetura capaz de organizar conhecimento e contexto, a próxima questão é definir onde começar. E aqui existe uma característica importante na abordagem do TM Forum: níveis mais elevados de autonomia não precisam surgir como resultado de um grande projeto que transforma toda a rede simultaneamente.
A evolução pode começar por cenários concretos. Fault management é um bom exemplo. Um incidente pode gerar dezenas ou centenas de alarmes distribuídos entre diferentes plataformas, exigindo que especialistas identifiquem relações, avaliem dependências, investiguem mudanças recentes, estimem impacto e decidam qual ação executar. Tornar esse processo progressivamente mais autônomo significa melhorar não apenas a execução da resposta, mas principalmente a capacidade de compreender o incidente antes de agir.
Automatizar apenas a última etapa pode simplesmente aumentar a velocidade com que uma decisão inadequada é executada. A autonomia precisa ser construída sobre uma capacidade crescente de perceber, correlacionar, compreender e avaliar consequências. Por isso, processos conhecidos, bem compreendidos e de menor risco podem receber inicialmente níveis maiores de autonomia, enquanto situações críticas ou ambíguas continuam dependendo da participação humana.
Essa abordagem também ajuda a evitar que Autonomous Networks se transforme em uma corrida tecnológica para alcançar determinado nível de maturidade. O objetivo não deveria ser chegar ao L4 apenas porque o mercado estabeleceu esse nível como referência. O avanço precisa produzir resultados concretos para a operação e para o negócio.
Em junho de 2026, o TM Forum informou que 81% das operadoras consultadas pretendem alcançar L4 ou níveis superiores até 2030. Ao mesmo tempo, a discussão vem deixando de ser motivada apenas por redução de custos e eficiência operacional e passa a incorporar objetivos como resiliência, qualidade dos serviços, experiência do cliente e capacidade de introduzir novos serviços com menor complexidade.
Isso coloca a jornada em uma perspectiva mais adequada. Chegar ao L4 não depende de encontrar um modelo de IA suficientemente poderoso ou de implantar uma plataforma capaz de resolver toda a operação. Exige evolução combinada de arquitetura, dados, processos, conhecimento e governança, aplicada progressivamente aos cenários nos quais a autonomia possa gerar valor.
Os agentes de IA terão um papel importante nessa transformação, mas agentes mais capazes não eliminam os problemas estruturais que já existem na operação. Se os dados permanecerem fragmentados e as relações importantes não estiverem disponíveis, a inteligência também trabalhará a partir de uma compreensão fragmentada.
É por isso que talvez a principal transformação necessária para chegar às redes autônomas aconteça antes da própria autonomia. Precisamos construir operações capazes de representar continuamente sua realidade, conectando dados, relações e conhecimento de forma que possam ser compreendidos pelas pessoas, pelas automações atuais e pelos agentes que progressivamente participarão das decisões.
Redes autônomas não começam quando damos aos agentes permissão para agir. Começam quando construímos uma arquitetura capaz de fornecer conhecimento e contexto suficientes para que decisões autônomas possam ser tomadas com confiança.
Essa é a base sobre a qual a autonomia poderá crescer de forma progressiva, sem perder de vista aquilo que realmente importa: tornar a operação mais eficiente, confiável e capaz de responder às necessidades dos serviços que ela sustenta.
Da visão à prática: ARGUS
Essa discussão sobre knowledge plane e contexto operacional tem uma relação direta com aquilo que temos desenvolvido no ARGUS.
A plataforma conecta dados provenientes de múltiplas fontes operacionais e utiliza mecanismos de correlação, enriquecimento e regras determinísticas que podem representar relações e interdependências específicas do ambiente. Isso permite combinar aquilo que está sendo observado naquele momento com conhecimento previamente estruturado sobre como diferentes componentes da operação se relacionam.
Na prática, o objetivo é ajudar a transformar sinais distribuídos em contexto operacional, reduzindo ruído e permitindo uma compreensão mais consistente dos incidentes. Esse contexto pode apoiar inicialmente os especialistas humanos e as automações existentes e, progressivamente, também agentes de IA que precisem compreender o ambiente antes de recomendar ou executar ações.
Existe, portanto, uma convergência importante com o conceito de knowledge plane apresentado pelo TM Forum. O conceito é mais amplo e envolve diferentes componentes de uma arquitetura de redes autônomas, mas uma de suas necessidades fundamentais é justamente transformar dados fragmentados em conhecimento contextualizado e reutilizável.
É nesse sentido que o ARGUS pode contribuir para a construção de um knowledge plane, fornecendo uma camada de inteligência contextual capaz de correlacionar informações de múltiplas fontes e incorporar relações específicas daquela operação.
Essa perspectiva também amplia a forma como enxergamos o papel de AIOps. Mais do que ajudar equipes a tratar um volume crescente de alarmes, uma plataforma de inteligência operacional pode contribuir para estruturar o contexto que será necessário à medida que pessoas, automações e agentes passem a participar conjuntamente das decisões.
No próximo artigo, vou aprofundar uma consequência dessa transformação: quanto mais agentes especializados colocarmos na operação, maior pode se tornar o risco de criarmos novos silos de inteligência.
Conheça o ARGUS e veja como funciona na prática.
Sobre o autor
Paulo Florêncio de Menezes é cofundador da Target Solutions e atua há mais de 15 anos em projetos relacionados a infraestrutura, monitoramento, observabilidade, automação e operações de TI e Telecom.
É graduado em Processamento de Dados pela Universidade Federal do Amazonas (UFAM), possui MBA em Gestão Empresarial pela Fundação Dom Cabral (FDC) e Mestrado Profissional em Economia pela Fundação Getulio Vargas (FGV).
Em sua pesquisa de Mestrado, desenvolveu o IBEOP-IA (Índice Brasileiro de Exposição Ocupacional Potencial à Inteligência Artificial), investigando a exposição potencial das ocupações brasileiras às capacidades da IA por meio da combinação de dados ocupacionais, patentes de inteligência artificial e técnicas de processamento de linguagem natural.
Sobre a Target Solutions
A Target Solutions é uma empresa brasileira de tecnologia especializada em soluções para ambientes críticos de TI e Telecom.
Ao longo de mais de 15 anos, participamos de projetos envolvendo infraestrutura, monitoramento, observabilidade, automação, integração de plataformas e operações de redes e serviços, trabalhando com grandes organizações e ambientes de alta complexidade.
Essa experiência nos permitiu acompanhar de perto a evolução das operações: do monitoramento tradicional à observabilidade, da automação à AIOps e, agora, aos primeiros passos em direção a operações cada vez mais orientadas por inteligência artificial.
É nesse contexto que desenvolvemos o ARGUS, nossa plataforma AIOps para correlação de eventos, redução de ruído e construção de contexto operacional a partir de múltiplas fontes.