1. Enquadre a questão da aquisição
A questão da aquisição é quanto um comprador deve pagar hoje por um negócio de automação de rede cuja proposta se estende das operações atuais de 4G e 5G para AI-RAN e a arquitetura futura de 6G. A resposta exige várias avaliações dentro de uma única transação. A receita existente de assinaturas e serviços pode ser avaliada por meio de contratos, margens, retenção e conversão de caixa. Os benefícios operacionais para o cliente exigem atribuição técnica. A portabilidade exige evidências entre redes e fornecedores. A participação futura em padrões cria uma opção cujas condições de exercício permanecem incertas.
Um comprador disciplinado começa pelo problema operacional resolvido. A automação de rede pode melhorar o uso de energia, a capacidade, a taxa de transferência, a qualidade, a gestão de falhas, o planejamento ou a produtividade de engenharia. Cada caso de uso tem um requisito de dados, um intervalo de decisão, uma carga de integração e uma consequência de falha diferentes. Um produto que recomenda uma alteração de configuração semanal é economicamente e operacionalmente diferente de um controlador em malha fechada que atua em segundos.
A tese da transação deve indicar quais casos de uso criam valor, onde esse valor aparece, quem o recebe e quais evidências o comprovam. O comprador pode então testar se a empresa-alvo possui um produto, uma prática de integração, dados proprietários, um fluxo de trabalho específico do cliente ou um conjunto de componentes de terceiros.
Tabela 1. Camadas de valor da automação de rede e tratamento na transação
| Camada de valor | Evidência atual | Questão principal de diligência | Tratamento da transação |
|---|---|---|---|
| Software contratado | Receita recorrente contratada e histórico de renovações | A receita sobrevive a mudanças de controle e de fornecedor? | Valor empresarial base |
| Melhoria operacional | KPI de rede mensurado e efeito sobre custos | O contrafactual é crível e persistente? | Incremento validado ou earn-out |
| Capacidade de implantação | Implantações recorrentes e registros de integração | O produto consegue funcionar em diferentes operadoras e stacks tecnológicos? | Prêmio de portabilidade |
| Dados e modelos | Direitos legais, linhagem e reprodutibilidade | O comprador pode continuar o treinamento e a operação? | Valor do ativo sujeito a direitos |
| Posição no ecossistema | Contribuições para padrões e aceitação por parceiros | A influência se traduz em adoção? | Opção estratégica |
| Prontidão para 6G | Arquitetura e testes alinhados a padrões | Qual capacidade existe antes do 6G comercial? | Opção com teto, baseada em marcos |
Cada camada exige evidências, economia e tratamento de risco separados.
2. Separe o valor atual do valor da opção futura
O valor atual decorre de produtos que as operadoras implantam, pagam e renovam. Ele inclui receita recorrente de software, receita de implementação que apoia a adoção e benefícios mensuráveis para o cliente que melhoram a renovação ou a expansão. O valor da opção futura decorre de capacidades que podem se tornar úteis à medida que interfaces, arquiteturas, arranjos de espectro e planos de investimento das operadoras amadurecem.
A separação evita uma tese circular. Um alvo não pode justificar um preço alto por meio de um mercado futuro e depois usar o preço como evidência de que o mercado existe. O comprador deve identificar o produto atual, o cliente atual, a decisão atual e o benefício econômico atual. Funcionalidades futuras pertencem a um registro de opções separado, com gatilhos, condições de expiração e necessidades adicionais de capital.
O valor da opção é mais forte quando a plataforma atual cria aprendizado que permanece útil ao longo de gerações de padrões. A capacidade de engenharia de dados, a governança de modelos, as ferramentas de integração e a confiança do operador podem ser duráveis. Uma afirmação vinculada a uma interface provisória ou a uma implementação restrita de fornecedor pode se deteriorar. O comprador deve pagar por capacidade transferível, e não por um rótulo.
3. Entenda o calendário dos padrões
O calendário dos padrões estabelece limites em torno da certeza técnica. A Recomendação ITU-R M.2160 descreve a estrutura IMT-2030 e seis cenários de uso. A ITU informou em março de 2026 que requisitos técnicos de desempenho em rascunho haviam sido acordados para vinte requisitos, incluindo sete novos, com aprovação formal prevista para dezembro de 2026. A metodologia de avaliação e o trabalho de tecnologias candidatas continuam no âmbito do processo internacional.
Esse cronograma é importante porque descrições comerciais podem avançar além de requisitos técnicos aprovados e de sistemas implantáveis. Uma empresa-alvo pode realizar pesquisas relevantes para 6G sem possuir um produto 6G. Ela também pode criar valor significativo nas redes atuais por meio de técnicas com probabilidade de persistir em gerações futuras.
A equipe de diligência devida deve construir uma matriz de padrões. Cada funcionalidade relevante deve ser mapeada para uma especificação aprovada, um item em rascunho, um conceito de pesquisa ou uma implementação proprietária. A matriz deve indicar a interface, a versão, a dependência e o risco esperado de mudança. A avaliação deve acompanhar a maturidade da dependência subjacente.
4. Diferencie os significados de AI-RAN
AI-RAN pode descrever AI usado para melhorar a rede de rádio, cargas de trabalho de AI compartilhando computação de rede, ou capacidade de rede projetada para atender aplicações de AI. Essas proposições têm clientes, ativos e dinâmicas econômicas diferentes. Um caso de aquisição deve declarar qual significado se aplica a cada produto.
AI para RAN inclui previsão de tráfego, gestão de energia, otimização de mobilidade, detecção de anomalias, planejamento de capacidade e controle de parâmetros. AI e RAN podem combinar cargas de trabalho de telecomunicações e de computação acelerada em infraestrutura comum. AI em RAN pode se referir a inferência distribuída ou a serviços viabilizados pelo alcance da rede. Uma empresa-alvo pode participar de mais de uma categoria, mas o comprador não deve unificar seus mercados endereçáveis.
A documentação do produto, os contratos e os diagramas de implantação devem usar terminologia consistente. Quando a gestão usa um rótulo amplo, a equipe de diligência devida deve traduzi-lo em entradas de dados, saídas de modelos, ações de rede, dependências de hardware, níveis de serviço e unidades faturadas.
5. Mapeie a arquitetura de controle
A arquitetura de controle mostra como observações se tornam ações. A telemetria pode originar-se de células, rádios, equipamentos de usuário, transporte, funções de núcleo, sistemas de energia e sistemas de suporte operacional. Ela é normalizada e governada antes que modelos ou políticas a utilizem. As ações podem retornar por meio de gerenciamento de serviços e orquestração, controladores não em tempo real, controladores quase em tempo real ou sistemas específicos de fornecedores.
A arquitetura O-RAN distingue funções não em tempo real e quase em tempo real e define interfaces incluindo A1, R1 e E2. Aplicações não em tempo real podem dar suporte a políticas, treinamento de modelos e otimização de horizonte mais longo. Aplicações quase em tempo real podem influenciar o comportamento da rede em intervalos menores. O posicionamento real da empresa-alvo determina requisitos de latência, integração e segurança.
O comprador deve rastrear um caso de uso de ponta a ponta. O rastreamento deve identificar cada fonte de dados, transformação, interface, decisão, salvaguarda e ação de rede. Elos ausentes revelam onde serviços humanos ou ferramentas de fornecedores estabelecidos completam o produto.
A diligência devida acompanha uma decisão desde a telemetria governada, passando por modelos e políticas, até uma ação de rede reversível.
6. Construa uma escada de evidências
Uma escada de evidências impede que uma demonstração promissora receba o mesmo peso que uma economia de produção repetível. O primeiro degrau é a evidência de simulação ou de laboratório. O segundo é um teste de campo controlado. O terceiro é um teste em rede comercial com escopo definido. O quarto é uma implantação limitada em produção. O quinto é o desempenho repetido ao longo de períodos, regiões, configurações e operadoras.
Cada degrau deve registrar quem projetou o teste, quem controlou a linha de base, quais tráfego e hardware foram incluídos, por quanto tempo durou a observação e se resultados adversos foram medidos. Estudos de caso de fornecedores e operadoras podem demonstrar viabilidade. Eles exigem reprodução específica da transação antes de sustentar um prêmio de aquisição relevante.
As evidências podem evoluir para baixo e também para cima. Um modelo pode apresentar bom desempenho após a implantação e se degradar quando tráfego, dispositivos, software ou configurações de rádio mudarem. A empresa-alvo deve demonstrar monitoramento, retreinamento, aprovação e reversão. O comprador está adquirindo um sistema de desempenho, não um resultado estático de precisão.
7. Estabeleça o contrafactual
O contrafactual é o resultado que teria ocorrido sem o produto da empresa-alvo. Ele pode ser uma área de controle pareada, um switchback aleatorizado, uma implantação escalonada, um período comparável ou um modelo de engenharia. Uma comparação simples de antes e depois pode atribuir erroneamente ao software clima, tráfego, renovação de hardware, mudanças de espectro ou outra otimização.
A equipe de diligência devida deve reproduzir cálculos-chave a partir de dados brutos ou controlados. A empresa-alvo deve divulgar exclusões, períodos ausentes e intervenção manual. A análise deve mostrar tendência central, distribuição e casos de falha, em vez de um único resultado de pico.
A atribuição econômica segue a atribuição técnica. Se um produto reduz a energia por unidade de tráfego, o comprador deve identificar preços de eletricidade, estados dos equipamentos, crescimento do tráfego e qualquer custo de hardware necessário. Se ele melhora o throughput, o comprador deve mostrar se o benefício adia despesas de capital, protege a experiência do cliente ou cria capacidade comercializável.
8. Teste a persistência dos KPIs
Os ganhos de desempenho da rede podem diminuir. As operadoras mudam software, padrões de tráfego, configurações de frequência, hardware e prioridades comerciais. Portanto, as evidências da empresa-alvo devem abranger a persistência, não apenas o ganho inicial.
O comprador deve inspecionar curvas de coorte por local, região, caso de uso e tempo desde a implantação. Uma média estável pode ocultar deterioração em ambientes de alta carga ou incomuns. O modelo deve registrar com que frequência os engenheiros sobrepõem recomendações e com que frequência a reversão é acionada.
A persistência também influencia a precificação. Uma melhoria de engenharia pontual pode sustentar receita de projeto. Uma otimização monitorada continuamente com ganhos duradouros pode sustentar taxas recorrentes de software ou compartilhamento de benefícios. A economia contratual deve corresponder ao trabalho realizado após o lançamento.
9. Concilie throughput e eficiência espectral
Throughput e eficiência espectral estão relacionados, mas são distintos. Um modelo pode melhorar a taxa experimentada por usuários selecionados enquanto altera a equidade, a cobertura ou o uso de recursos em outros locais. O comprador deve evitar valorizar um percentual de destaque sem o denominador e o contexto da rede.
A análise deve separar o desempenho médio, mediano e de cauda. Deve identificar carga de célula, condições de rádio, mix de dispositivos, espectro, agendador, mobilidade e período de medição. O desempenho durante congestionamento pode ter mais valor comercial do que o desempenho quando há abundância de capacidade.
A SoftBank e a Ericsson relataram, em agosto de 2026, que um teste AI-in-RAN em rede comercial alcançou ganhos dependentes da localização, incluindo até 25% de eficiência espectral e até 50% de throughput de usuário no downlink, com uma melhoria média de aproximadamente 10% nas localizações avaliadas. Esses resultados de fornecedores e operadoras mostram viabilidade. Eles não estabelecem resultados transferíveis para outro alvo ou rede.
10. Validar a análise econômica de energia
A automação de energia pode alternar capacidade, ajustar estados de rádio, coordenar refrigeração ou gerenciar a infraestrutura do site. O benefício deve ser medido em relação a tráfego, cobertura, níveis de serviço, configuração de equipamentos e condições ambientais. A economia de energia que depende de novos rádios ou equipamentos de site deve ser separada dos efeitos de software.
Casos publicados de fornecedores e operadoras relatam resultados significativos em implantações específicas. A Ericsson e a Far EasTone relataram, no caso delas, economia diária de energia de RAN de 25% sem impacto adverso no desempenho da rede. Outro caso da Ericsson descreve uma economia de 14% proveniente de gestão de energia MIMO assistida por aprendizado de máquina. Esses resultados são pontos de referência úteis e permanecem específicos aos ambientes declarados.
O modelo de aquisição deve usar implantações-alvo verificadas, tarifas locais e persistência esperada. Deve deduzir custos de computação, integração, licenciamento e operacionais. O benefício só pode ser capitalizado quando a operadora puder retê-lo e o software tiver um direito duradouro sobre o fluxo de caixa resultante.
11. Medir disponibilidade e resiliência
Um produto de automação pode criar valor ao operar normalmente e destruir valor quando se comporta de forma incorreta. A análise de disponibilidade deve abranger a aplicação, o pipeline de dados, os controladores, as interfaces e a função de rede alvo. A equipe deve revisar os modos de falha e o tempo de recuperação.
A implantação segura exige salvaguardas, ações limitadas, liberações canário, aprovações humanas quando apropriado e reversão automática. Os logs devem permitir que uma operadora reconstrua por que uma recomendação ou ação ocorreu. Um modelo que não pode ser explicado no nível operacional ainda pode ser utilizável se os controles tornarem seu comportamento observável e reversível.
As garantias da transação devem refletir o controle real. O fornecedor pode garantir seu software, segurança e conformidade. A operadora controla a configuração da rede, a implementação e a aceitação. A responsabilidade compartilhada deve ser documentada, em vez de deixada a um acordo genérico de nível de serviço.
12. Quantificar a produtividade de engenharia
A automação pode reduzir ciclos de planejamento, triagem de alarmes, ajuste de parâmetros e análises repetitivas. O valor de produtividade depende de o tempo do engenheiro ser eliminado, realocado ou consumido por novas tarefas de integração e monitoramento.
O comprador deve mapear o fluxo de trabalho anterior e o fluxo de trabalho automatizado. Deve contar atividades, transferências, tempo decorrido, intervenções e exceções. Um modelo que produz recomendações sem integração pode deslocar o trabalho em vez de eliminá-lo.
A produtividade também sustenta a escala. Uma operadora pode gerenciar maior complexidade de rede sem crescimento proporcional do quadro de pessoal. A avaliação deve conectar esse efeito a planos de pessoal aprovados, terceirização evitada ou entrega mais rápida. Estimativas sem suporte devem permanecer como premissas da administração e não devem ser apresentadas como economias observadas.
13. Testar a interoperabilidade em produção
A conformidade com uma interface é necessária e pode ser insuficiente para a interoperabilidade em produção. Os fornecedores podem implementar recursos opcionais de maneira diferente. A semântica dos dados, o desempenho, a segurança e os procedimentos operacionais podem variar. O comprador deve distinguir alinhamento a padrões, conformidade em laboratório, sucesso de integração e uso sustentado em produção.
A empresa-alvo deve fornecer uma matriz de implantação abrangendo operadora, geografia, fornecedor de rede, versão de software, interface, hardware e caso de uso. A implantação repetida com um núcleo de produto estável é evidência mais forte do que múltiplos projetos sob medida.
A portabilidade deve ser medida pelo tempo decorrido de implantação, esforço de engenharia, componentes reutilizados, defeitos de regressão e desempenho retido. Uma empresa-alvo que exige uma grande equipe personalizada ainda pode ser valiosa como integradora especializada; ela deve receber a economia de um integrador, e não um prêmio de produto.
14. Avaliar dependências de O-RAN
O O-RAN cria uma arquitetura para funções de rede de rádio desagregadas e inteligentes. Os grupos de trabalho abrangem gerenciamento e orquestração de serviços, o controlador não em tempo real, o controlador quase em tempo real, interfaces e ecossistemas de aplicativos. A Release 5, concluída em junho de 2026, incluiu AI e aprimoramentos de fluxos de trabalho de aprendizado de máquina e recursos adicionais de otimização.
O comprador deve listar de quais especificações o produto depende, quais versões os clientes usam e quais funções permanecem específicas do fornecedor. Deve identificar se a empresa-alvo vende um rApp, xApp, controlador, plataforma de dados, camada de garantia ou capacidade de integração.
A participação em padrões pode melhorar informações, credibilidade e acesso a parceiros. Não garante contratação. A avaliação deve seguir interoperabilidade em operação, aceitação por operadoras e contratos comerciais. As contribuições para padrões pertencem ao cenário de opção estratégica.
15. Analisar a dependência de fornecedores incumbentes
Muitos produtos de automação de rede dependem de dados, APIs, acesso à configuração ou comportamento do controlador de fornecedores incumbentes. Uma mudança na política de acesso, no licenciamento, na versão de software ou no roteiro pode afetar o produto da empresa-alvo.
A equipe de diligência devida deve identificar cada dependência crítica e proteção contratual. Deve verificar se a empresa-alvo tem interfaces documentadas, compromissos de suporte, certificação e rotas de escalonamento. Acesso obtido por engenharia reversa ou não oficial pode criar risco de continuidade e risco jurídico.
A dependência não é automaticamente negativa. Uma parceria forte pode acelerar a distribuição e a integração. Seu valor depende de durabilidade, economia, exclusividade e tratamento de mudança de controle. O comprador deve modelar tanto a continuidade quanto a perda da relação.
16. Auditar direitos sobre dados
A telemetria de rede pode conter informações comercialmente sensíveis, sensíveis à segurança ou pessoais. A empresa-alvo precisa de direitos para acessar, processar, reter e usar dados para a finalidade contratada. Os direitos para treinar modelos gerais podem ser mais restritos do que os direitos para otimizar a rede de um cliente.
O registro de dados deve identificar origem, controlador, processador, localização, retenção, finalidade permitida, uso em modelos, compartilhamento e exclusão. Deve conectar contratos aos pipelines reais. Uma declaração ampla de que a empresa-alvo é proprietária de seus dados não deve receber peso na avaliação sem evidências.
A aquisição pode alterar o uso permitido ou a contraparte. Disposições de mudança de controle, políticas de operadoras e controles de segurança nacional podem afetar a continuidade. O comprador deve obter consentimentos ou estruturar o acesso antes da conclusão.
17. Inspecionar a linhagem do modelo
A linhagem do modelo registra o código, os dados de treinamento, as características, os parâmetros, os conjuntos de avaliação, as aprovações e as versões implantadas. Ela permite a reprodutibilidade e ajuda a determinar a quem pertencem as melhorias: à empresa-alvo, ao cliente ou ao fornecedor de tecnologia.
A empresa-alvo deve demonstrar como evita vazamentos entre clientes e protege configurações confidenciais. Deve documentar componentes de modelo de código aberto e de terceiros, licenças e obrigações. A infraestrutura de treinamento e inferência deve ser identificável e ter seus custos calculados.
A linhagem torna-se um ativo de aquisição quando encurta a validação, apoia a auditoria e permite o desenvolvimento contínuo. Uma linhagem fraca pode transformar desempenho proprietário em uma alegação não verificável. O comprador deve condicionar o valor a um registro limpo e utilizável.
18. Revisar MLOps e o controle do ciclo de vida
Modelos de rede em produção exigem monitoramento, detecção de desvio, retreinamento, testes, promoção, reversão e desativação. Esses processos devem operar entre clientes sem criar um ônus de liberação difícil de administrar.
A equipe de diligência devida deve inspecionar papéis de aprovação, testes automatizados, modo sombra, implantação canário e tratamento de incidentes. Deve comparar o processo documentado com os registros de liberação. Um slide que descreve MLOps é mais fraco do que evidências de mudanças controladas no modelo.
O custo do ciclo de vida deve entrar na análise de margem bruta. Modelos específicos por cliente, retreinamento manual e intervenção frequente podem tornar a receita de software reportada intensiva em serviços. A projeção deve incluir recursos de computação, engenharia e garantia necessários para manter o desempenho prometido.
19. Avaliar a segurança cibernética e a cadeia de suprimentos
A automação de rede está próxima da infraestrutura crítica. Um comprometimento poderia expor dados operacionais, alterar configurações ou interromper o serviço. A segurança deve abranger o desenvolvimento de software, dependências, identidade, segredos, dados, mecanismos de atualização e acesso operacional.
O comprador deve revisar evidências de desenvolvimento seguro, gestão de vulnerabilidades, testes de penetração, histórico de incidentes, listas de materiais de software e controles de acesso privilegiado. Deve testar se a arquitetura de implantação limita o raio de impacto e permite revogação rápida.
Requisitos nacionais e políticas de operadoras podem restringir hospedagem, locais de suporte e propriedade de fornecedores. Essas restrições podem afetar o acesso ao mercado e o custo de integração. O plano de aquisição deve incluir a correção de segurança e a reaprovação pelos clientes.
20. Identificar o risco de concentração
Empresas iniciantes de software de rede frequentemente dependem de um pequeno número de operadoras, fornecedores ou regiões. A concentração pode proporcionar validação aprofundada e criar risco de negociação.
A análise de receita deve separar a produção paga, o teste pago, o projeto, o repasse e a receita não recorrente. O comprador deve inspecionar os termos de renovação, expansão, rescisão, aceitação e de nação mais favorecida. A probabilidade do pipeline deve refletir o histórico de compras e a prontidão de implantação.
A concentração técnica importa tanto quanto a concentração de receita. Um produto comprovado em uma pilha de rede pode exigir trabalho relevante em outra. A avaliação não deve tratar a presença de um único operador como participação de mercado geral.
21. Normalize as métricas comerciais
A receita recorrente anual deve incluir apenas a contraprestação recorrente e contratada por um serviço contínuo. Implementação, hardware, repasse de nuvem e projetos de engenharia devem ser identificados separadamente. A receita de compartilhamento de benefícios deve ser avaliada em relação às disposições de medição e disputa.
A margem bruta deve incluir engenharia de implantação, suporte ao cliente, computação, movimentação de dados, licenças de terceiros e trabalho de ciclo de vida. O desenvolvimento capitalizado pode fazer a lucratividade atual parecer mais forte, ao mesmo tempo que posterga o custo para o balanço patrimonial.
A retenção deve distinguir retenção de clientes (logo), de contratos e de produtos. A expansão pode surgir de mais células, regiões, módulos ou benefícios medidos. O comprador deve entender qual unidade impulsiona o preço e se ela cresce com o valor entregue.
22. Conecte os benefícios de rede ao fluxo de caixa
A melhoria técnica só se torna valor de aquisição quando afeta o fluxo de caixa. Economias de energia podem reduzir despesas operacionais. A melhoria de capacidade pode postergar investimentos em rádios ou espectro. Uma melhor experiência pode proteger a receita ou reduzir reclamações. Planejamento mais rápido pode acelerar a implantação.
A ponte deve identificar o benefício do operador, a captura contratual pela empresa-alvo e o período de propriedade do comprador. Um benefício ao cliente não reverte automaticamente para o fornecedor de software. Evidências fortes podem sustentar renovação e precificação, mas o contrato determina a receita realizada.
Os benefícios devem ser descontados por atribuição, persistência, custo de implementação e compartilhamento. A equipe deve evitar adicionar o mesmo benefício tanto às economias do cliente quanto à receita projetada da empresa-alvo.
Tabela 2. Escada de evidências para o valor da automação de rede
| Estágio de evidências | Registro obrigatório | Limitação típica | Resposta de avaliação |
|---|---|---|---|
| Simulação ou laboratório | Conjunto de dados, modelo, ambiente e resultado reproduzível | Realismo de rede limitado | Apenas ativo de pesquisa |
| Teste de campo controlado | Linha de base, controle, escopo e resultado assinado | Duração curta ou configuração restrita | Valor técnico contingente |
| Teste em rede comercial | Escopo em produção, salvaguardas e validação do operador | A economia do teste pode não se repetir | Valor de marco |
| Produção limitada | Contrato, nível de serviço e KPI persistente | Concentração de clientes ou fornecedores | Valor operacional descontado |
| Produção recorrente com múltiplos operadores | Evidências de renovações, margens e portabilidade | Riscos remanescentes de escala e de mercado | Valor central da empresa |
O valor de aquisição aumenta quando as evidências passam da possibilidade técnica para uma economia contratada e repetível.
23. Criar o scorecard de KPIs de automação
O scorecard deve combinar desempenho, economia e controle. As medidas de desempenho incluem throughput, eficiência espectral, energia, disponibilidade e precisão de otimização. As medidas econômicas incluem custo evitado, esforço de implantação, margem bruta e renovação. As medidas de controle incluem substituições manuais, reversão, incidentes e completude de auditoria.
Cada KPI deve identificar fonte, responsável, frequência, linha de base e limite. O desempenho máximo alegado deve ser mostrado ao lado das médias observadas e de premissas de aquisição conservadoras. Isso evita que um resultado de pico domine a avaliação.
O scorecard deve continuar útil após a conclusão. Ele pode apoiar prioridades de integração, testes de earn-out e relatórios para clientes. As definições devem ser acordadas antes da assinatura, porque alterar a medição após o fechamento gera disputas.
Pontuações ilustrativas de índice mostram como a diligência devida desconta uma alegação de destaque por escopo, persistência e captura.
24. Modelar a curva de capex
A automação pode alterar o momento do capex de rede. O melhor uso da capacidade existente pode atrasar a densificação. Um planejamento mais preciso pode reduzir a construção excessiva. Computação compartilhada ou novos controladores podem exigir capital adicional.
O modelo deve comparar um plano convencional com um plano habilitado por automação, ano a ano. Ele deve usar as mesmas premissas de tráfego, cobertura, espectro e serviço. O capital diferido deve ser distinguido do capital permanentemente evitado, porque o atraso ainda tem valor e um efeito terminal diferente.
O custo de implementação e de computação deve ser incluído. Se um modelo exigir computação acelerada em muitos sites, a curva líquida pode diferir materialmente de um serviço de otimização centralizado. O comprador deve testar carga, energia e hardware na arquitetura alvo.
Premissas gerenciais ilustrativas; a automação adia parte da densificação, mas exige investimento em integração e computação.
25. Avaliar o negócio atual
O negócio atual pode ser avaliado por meio de um método de fluxo de caixa descontado, transações comparáveis ou múltiplos de receita e lucro, sujeito à disponibilidade e à comparabilidade. A projeção deve começar pela receita contratada e evoluir por meio de expansão baseada em evidências.
O comprador deve normalizar subvenções de pesquisa, projetos-piloto, hardware e engenharia não recorrente. Deve incluir gastos com produtização e conformidade necessários para escalar. Uma taxa de crescimento elevada deve estar vinculada a orçamentos de operadoras, ciclos de aquisição e capacidade de implantação.
Empresas comparáveis podem combinar software, equipamentos e serviços. A equipe da transação deve ajustar para mix de negócios, margem, concentração, crescimento, propriedade intelectual e maturidade. Um múltiplo genérico AI ou de software pode obscurecer a economia das telecomunicações.
26. Precificar o valor validado para o cliente
O valor validado para o cliente pode sustentar um prêmio quando é medido de forma independente, repetível e vinculado à captura comercial. O comprador pode comparar o valor presente do benefício para o cliente com as tarifas de assinatura e os custos de troca.
O prêmio deve ser limitado por alternativas competitivas e termos contratuais. As operadoras podem desenvolver capacidade semelhante, obtê-la de fornecedores de rede ou contratar outro fornecedor independente. Interfaces abertas podem ampliar o mercado e reduzir barreiras.
As evidências de benefício são mais fortes quando os clientes renovam, expandem e permitem uso como referência. O comprador deve conversar diretamente com stakeholders técnicos, operacionais e de compras. O entusiasmo de uma equipe de inovação não substitui um orçamento de produção.
27. Portabilidade de valor
A portabilidade reduz a dependência de um único cliente e de uma única stack de fornecedor. Pode acelerar o crescimento da receita e melhorar a relevância estratégica. Seu valor depende de software reutilizável, interfaces estáveis, onboarding automatizado e evidências de que o desempenho sobrevive à transferência.
A equipe deve calcular um coeficiente de portabilidade: a proporção de código, modelos, testes e ativos de integração reutilizados na próxima implantação. Deve medir o tempo de implantação e o esforço de engenharia. Essas medidas devem ser verificadas nos registros do projeto.
O prêmio pode ser escalonado. Parte pode ser paga no fechamento por implantações comprovadas. Contraprestação adicional pode ocorrer após a aceitação em uma nova operadora ou stack. Isso alinha o preço à transferibilidade realizada.
28. Limitar o valor da opção 6G
A opção 6G representa o direito de participar dos gastos futuros das operadoras e da arquitetura. Não deve ser avaliada como receita 6G projetada quando produtos, prazos e compras permanecem incertos.
Um registro de opções pode pontuar relevância para padrões, reutilização técnica, acesso a parceiros, propriedade intelectual, investimento exigido e tempo até evidência comercial. O valor deve ser limitado pelo capital incremental necessário e pela probabilidade de exercício.
Marcos podem incluir padrões aprovados, interfaces aceitas, testes bem-sucedidos, orçamentos de operadoras e contratos assinados. A contraprestação vinculada a esses eventos protege o potencial de valorização do vendedor e o capital do comprador.
29. Construir a ponte de avaliação
A ponte de avaliação começa com o negócio atual e adiciona apenas valor distinto e comprovável. Ela pode adicionar economia de KPIs validada, portabilidade e opções estratégicas. Ela subtrai riscos de integração, concentração, direitos, cibersegurança, desempenho e padrões.
No caso hipotético, as partes discutem um valor da empresa de USD 300 million. A ponte é um instrumento de apoio à decisão, e não uma opinião de avaliação. Os valores mostram como o método impede que a narrativa 6G sustente todo o preço.
O comprador deve elaborar cenários pessimista, base e otimista. Cada ajuste precisa de um responsável pelas evidências e de um tratamento no fechamento. Riscos que possam ser sanados antes da assinatura devem ser condições. Riscos cujo resultado surja após o fechamento devem ser refletidos por meio de contraprestação contingente ou retenção de preço.
Premissas ilustrativas da administração em USD milhões; a opção de padrões futuros é deliberadamente limitada.
30. Estruturar a contraprestação
O caixa no fechamento deve financiar o valor presente verificado. O rollover do vendedor pode manter o alinhamento quando fundadores e líderes técnicos continuam importantes. Earn-outs podem remunerar receita, implantação de produção ou portabilidade validada após o fechamento.
Earn-outs técnicos exigem definições objetivas. O contrato deve indicar o escopo da rede, a linha de base, o KPI, o período de medição, as condições de controle, o verificador independente e as consequências das decisões do comprador. Um marco vago convida ao conflito.
Pagamentos por marcos podem tratar da incerteza sobre padrões e 6G. Devem recompensar resultados dentro da influência do vendedor e considerar o financiamento do comprador. Cronogramas longos precisam de governança, informações e disposições sobre disputas.
31. Utilizar declarações e indenizações
As declarações devem abranger propriedade, licenças, direitos sobre dados, uso de código aberto, segurança, alegações sobre padrões, contratos com clientes, registros de modelos e conformidade regulatória. Devem refletir fatos divulgados e controle efetivo.
Indenizações específicas ou depósito em garantia podem tratar de questões identificadas de cadeia de titularidade, cibersegurança ou consentimento do cliente. O seguro pode suportar partes do risco e pode excluir desempenho prospectivo.
Alegações técnicas usadas na avaliação devem constar nos registros de diligência devida e nos anexos da transação. A linguagem de marketing não deve se tornar uma garantia não intencional, e evidências materiais não devem permanecer fora dos documentos da operação.
32. Proteger pessoas-chave e know-how
O valor da automação de rede pode depender de engenheiros que entendem sistemas de operadoras, comportamento de modelos e caminhos informais de integração. O comprador deve mapear a concentração de pessoas-chave e as lacunas de documentação.
A retenção deve combinar clareza de função, incentivos, trajetória de carreira e recursos. Covenants restritivos exigem orientação específica por jurisdição. A transferência de conhecimento deve ser medida por documentação concluída, testes e capacidade dos sucessores.
O modelo operacional deve reduzir a dependência de esforços heroicos. Produto, implantação, ciência de dados, padrões e responsabilidade pela relação com o cliente devem ter líderes responsáveis e processos repetíveis.
33. Planeje a integração antes da assinatura
Decisões de integração afetam a credibilidade do produto. Operadoras podem precisar aprovar uma mudança de propriedade, hospedagem ou suporte. Combinar repositórios de código e processos de segurança rápido demais pode interromper versões.
O primeiro plano deve preservar a continuidade do serviço, a confiança do cliente, o acesso privilegiado e o foco no roadmap. Sistemas corporativos podem ser integrados em etapas. A arquitetura do produto só deve mudar por meio de um plano testado.
As sinergias devem identificar responsável, custo, prazo e dependência. A sinergia de receita pelos canais do comprador exige capacitação técnica e acesso a compras. A sinergia de custo não deve eliminar a capacidade de engenharia necessária para a entrega.
34. Construa o primeiro plano de 100 dias
Os primeiros 100 dias devem validar direitos, compromissos com clientes, versões de produto, controles de segurança e linhas de base de KPIs. O comprador deve congelar um inventário verificado de código, modelos, dados, interfaces e implantações.
Reuniões com clientes devem confirmar planos de continuidade e expansão. Equipes de produto devem reproduzir evidências materiais e estabelecer um padrão comum de medição. Equipes financeiras devem conciliar a qualidade da receita e o custo de entrega.
O conselho deve aprovar separadamente o roadmap de valor presente e o roadmap de opções. O capital para trabalho futuro em padrões deve seguir marcos técnicos e comerciais.
35. Crie um dashboard para o conselho
O dashboard do conselho deve abranger receita recorrente, renovação, margem bruta, tempo de implantação, portabilidade, persistência de KPIs, incidentes, substituições manuais e marcos de padrões. Cada métrica precisa de uma definição estável.
O dashboard deve mostrar valores observados, validados por clientes e do cenário de aquisição. Deve distinguir resultados máximos de médias da base instalada. As exceções devem permanecer visíveis.
A gestão pode usar o painel para decidir se escala, remedia ou interrompe um caso de uso. Uma pontuação composta não deve ocultar falhas em segurança, direitos ou resiliência.
Tabela 3. Caso hipotético de transação e financiamento
| Item | Premissa base | Condição de diligência devida | Resposta da transação |
|---|---|---|---|
| Discussão do valor da empresa | USD 300 million | O negócio atual sustenta a maior parte do valor | Limitar o caixa na conclusão |
| Receita recorrente contratada | USD 36 million | Revisão de contrato, renovação e qualidade da receita | Entrada de valor base |
| Ajustado EBITDA | USD 8 million | Incluir custo de entrega, computação e ciclo de vida | Normalizar lucros |
| Valor validado do KPI | Contribuição de ponte USD 32 million | Reprodução independente e persistência | Earn-out ou prêmio |
| Valor de portabilidade | Contribuição de ponte USD 26 million | Implantação aceita em outra stack tecnológica | Pagamento por marco |
| opção 6G | USD 18 million contribuição limitada | Padrões, teste e etapas contratadas de adoção | Pagamento diferido de opção |
| Deduções de risco | USD 21 million | Integração, concentração, direitos e padrões | Ajuste de preço ou depósito em garantia |
Apenas premissas ilustrativas da administração; nenhum valor representa dados observados da empresa ou uma opinião de avaliação.
36. Estabelecer o plano de trabalho de diligência devida
O plano de trabalho deve unir diligência devida comercial, técnica, operacional, jurídica, regulatória, de cibersegurança e financeira. Frentes separadas devem usar um único registro de alegações, para que o mesmo benefício não seja aceito em uma frente de trabalho e contestado em outra.
As alegações relevantes devem identificar evidência, responsável, verificador e consequência transacional. A equipe deve priorizar alegações portadoras de valor: receita recorrente, economias para clientes, portabilidade, direitos e dependências de opções futuras.
Os testes devem incluir revisão de código e arquitetura, mapeamento de direitos sobre dados, reprodução de modelos, amostragem de implantação, chamadas com clientes e conciliação contratual. As conclusões devem fluir para avaliação, condições, covenants e integração.
37. Preparar o data room
O data room deve incluir registros de entidades, cessões de propriedade intelectual, inventário de código-fonte, licenças, linhagem de modelos, arquitetura, evidências de segurança, contratos com clientes, implantações, estudos de KPI, histórico de incidentes, registros financeiros e contribuições para padrões.
As evidências devem ser atribuíveis e datadas. Capturas de tela e apresentações devem remeter aos registros subjacentes. Dados de rede sensíveis a clientes podem exigir revisão controlada em vez de divulgação ampla.
A empresa-alvo deve manter um registro de sinais de alerta com responsáveis e datas de conclusão. Um data room organizado encurta o tempo da transação e melhora a confiança; não substitui evidências substantivas.
38. Aplicar uma decisão de avançar, reajustar o preço ou parar
Uma decisão de avançar exige um negócio atual defensável, direitos utilizáveis, integração gerenciável e um caminho crível para escala. A reprecificação é apropriada quando o ativo permanece útil e as alegações de valor excedem as evidências. Uma decisão de interromper é apropriada quando direitos críticos, segurança, continuidade de clientes ou atribuição técnica não puderem ser sanados.
A decisão deve ser explícita quanto à optionalidade futura. Um comprador pode adquirir um negócio valioso de automação 5G atribuindo pouco valor ao 6G. Também pode buscar uma parceria ou opção em vez de adquirir uma plataforma imatura.
Os registros de decisão devem identificar premissas e questões não resolvidas. Isso preserva a responsabilização quando a tecnologia e os padrões evoluem.
Tabela 4. Painel de avaliação do conselho e da diligência devida
| Domínio | Evidência mínima | Sinal de alerta | Resposta à decisão |
|---|---|---|---|
| Receita | Contratos, faturas, renovações e ponte de margem | Receita de teste apresentada como recorrente | Normalizar ou reprecificar |
| Impacto nos KPIs | Linha de base, contrafactual, persistência e validação de clientes | Alegação de pico sem evidência bruta | Excluir o incremento |
| Interoperabilidade | Implantação repetida em stacks definidas | Integração sob medida disfarçada de produto | Reduzir o prêmio do produto |
| Dados e modelos | Direitos, linhagem, reprodutibilidade e controle do ciclo de vida | Direitos de treinamento indefinidos | Sanar antes da conclusão |
| Garantia | Desenvolvimento seguro, controle de acesso e evidências de incidentes | Exposição a infraestruturas críticas | Corrigir ou interromper |
| opção 6G | Mapa de padrões, capacidade reutilizável e marco de adoção | Previsão de receita antes da definição do produto | Limitar e diferir valor |
Cada domínio exige evidências antes da atribuição de valor material.
39. Reconheça as limitações
Esta estrutura apoia a análise de aquisições. Ela não determina se um produto é seguro, está em conformidade ou é adequado para uma rede específica. É necessária assessoria qualificada nas áreas técnica, regulatória, de segurança, jurídica, fiscal, contábil e de avaliação.
Padrões, interfaces e planos dos operadores continuam a evoluir. Os resultados publicados por fornecedores e operadores são específicos para as implantações que descrevem. Não devem ser generalizados sem reprodução.
O caso hipotético demonstra um método. Receitas, custos, benefícios, probabilidades, condições e valores reais exigem evidências específicas da transação. Nenhum número no caso é uma previsão ou recomendação.
40. Conclua com evidências antes da opcionalidade
A automação de redes pode criar valor mensurável antes do 6G. Ela pode reduzir o consumo de energia, melhorar a capacidade, reforçar a resiliência e tornar a engenharia mais produtiva. O valor da aquisição surge quando esses efeitos são atribuíveis, persistentes, capturados contratualmente e portáveis.
A atividade de arquitetura e padrões AI-RAN amplia a oportunidade estratégica. Ela também aumenta a necessidade de definições precisas. O alinhamento de padrões deve ser mapeado; a interoperabilidade deve ser demonstrada; o valor futuro deve ser escalonado.
A sequência disciplinada da transação consiste em avaliar o negócio operacional atual, verificar os resultados dos clientes, testar a portabilidade, precificar o risco de integração e de direitos e posicionar o potencial de valorização do 6G atrás de marcos observáveis. Essa abordagem permite que um comprador participe da inteligência de rede futura enquanto paga hoje por evidências que existem hoje.
Referências
- União Internacional das Telecomunicações. Requisitos técnicos de desempenho do IMT-2030 para o futuro 6G. 17 de março de 2026. https://www.itu.int/hub/2026/03/imt-2030-technical-requirements-for-the-6g-future/
- União Internacional das Telecomunicações. Portal e processo do IMT-2030. https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-2030/pages/default.aspx
- União Internacional de Telecomunicações. Recomendação UIT-R M.2160-0: Estrutura e objetivos gerais do desenvolvimento futuro do IMT para 2030 e além. 2023. https://www.itu.int/rec/R-REC-M.2160-0-202311-I
- União Internacional de Telecomunicações. Programa de trabalho: estrutura para arquitetura de rede para IMT-2030. https://www.itu.int/itu-t/workprog/wp_item.aspx?isn=23853
- O-RAN Alliance. Grupo de Trabalho 2: RIC não em tempo real e interfaces A1/R1. https://www.o-ran.org/technical-groups/wg2
- O-RAN Alliance. Grupos técnicos. https://www.o-ran.org/technical-groups
- O-RAN Alliance. O-RAN Alliance concluiu a Versão 5 da especificação. 8 de junho de 2026. https://www.o-ran.org/blog/o-ran-alliance-completed-its-specification-release-5-o-ran-r005
- O-RAN Alliance. 60 documentos técnicos O-RAN novos ou atualizados lançados desde março de 2025. https://www.o-ran.org/blog/60-new-or-updated-o-ran-technical-documents-released-since-march-2025
- O-RAN Alliance. Prioridades de RAN abertas e orientadas por AI. 28 de março de 2025. https://mediastorage.o-ran.org/press-release/O-RAN.EC.2025-03-28.PR%20MWC25%20summit%20messages.pdf
- Projeto de Parceria de Terceira Geração. Destaques do 3GPP, edição 10. https://www.3gpp.org/images/newsletters/3GPP_Highlights_Issue_10_WEB.pdf
- Ericsson. Far EasTone usa AI e aprendizado de máquina para economia de energia da RAN. 2023. https://www.ericsson.com/en/cases/2023/ericsson-far-eastone
- Ericsson. Aprimorando o gerenciamento de energia de MIMO com aprendizado de máquina e AI. https://www.ericsson.com/en/cases/2019/augmenting-mimo-energy-management-with-machine-learning-and-ai
- Ericsson. Caso de eficiência energética da Elisa Finlândia e da Ericsson. 2023. https://www.ericsson.com/en/cases/2023/elisa-finland-and-ericsson
- Ericsson e SoftBank. Teste de AI em RAN em rede comercial no Japão. 20 de agosto de 2026. https://www.ericsson.com/en/press-releases/2/2026/softbank-corp-and-ericsson-conduct-japans-first-trial-of-ericsson-ai-in-ran-on-5g-commercial-network
- Ericsson. A RAN fica mais inteligente: a Ericsson coloca AI onde importa. Junho de 2026. https://www.ericsson.com/en/news/2026/6/the-ran-gets-smarter-ericsson-puts-ai-where-it-matters
- Ericsson e KDDI. rApps de otimização de RAN com AI em produção. 2026. https://www.ericsson.com/en/cases/2026/kddi-boosts-uplink-with-live-ai-powered-ran-optimization-rapps
- Ericsson e AT&T. Moldando as redes do amanhã com uma rede programável. 2025. https://www.ericsson.com/en/cases/2025/shaping-networks-of-tomorrow
- Ericsson e TAWAL. Operações de infraestrutura energética na Arábia Saudita. 2023. https://www.ericsson.com/en/press-releases/5/2023/tawal-reaps-benefits-of-ericsson-energy-infrastructure-operations-in-saudi-arabia
- SoftBank. AI-RAN: Revelando o futuro das telecomunicações com inovações transformadoras. 7 de fevereiro de 2025, versão 1.1. https://www.softbank.jp/corp/set/data/technology/research/story-event/wp_location/pdf/SoftBank_AI-RAN%20Unveiling%20the%20Future%20of%20Telecom%20with%20Breakthrough%20Innovations_Feb7_2025_Ver.1.1.pdf
- Fundação IFRS. IFRS 3 Combinações de Negócios. https://www.ifrs.org/issued-standards/list-of-standards/ifrs-3-business-combinations/
- Fundação IFRS. IAS 36 Redução ao Valor Recuperável de Ativos. https://www.ifrs.org/issued-standards/list-of-standards/ias-36-impairment-of-assets/
- Fundação IFRS. IAS 38 Ativos Intangíveis. https://www.ifrs.org/issued-standards/list-of-standards/ias-38-intangible-assets/
- Fundação IFRS. IFRS 13 Mensuração do Valor Justo. https://www.ifrs.org/issued-standards/list-of-standards/ifrs-13-fair-value-measurement/
Sobre o Autor
Chennakeshav (CK) é um executivo de finanças corporativas e investment banking com mais de 25 anos de experiência global em originação, estruturação e execução de negócios nas áreas de M&A, capital de crescimento e estratégia corporativa. Ele liderou mandatos de criação de valor para fundadores, empresas e fundos — conectando a visão da alta administração à execução prática e ao fechamento.
Sua carreira abrange Morgan Stanley, HSBC, Lloyds Banking Group, EWEC, empresas do portfólio da ADQ e Emirates Growth Fund, nos setores de TMT, imobiliário, fintech, deeptech, cleantech, infraestrutura e energia. Ele atuou em parceria com líderes da alta administração, fundos de private equity e de capital de risco, fundos soberanos e family offices para financiar captações de fundos complexas e empreendimentos em expansão, e liderou iniciativas de diligência devida de M&A, integração pós-fusão e transformação de negócios para criar valor.
Na Matchpoint Partners, ele é Sócio-Gerente e lidera a prática de finanças corporativas, M&A e captação de capital da firma. Ele possui um MBA pela London Business School, uma graduação em engenharia pela VTU e um Master of Laws (LLM, em andamento) pela UCL London.
Mentor ativo de startups, CK atua como mentor na Techstars, DIFC FinTech Hive, Startup Grind, Founder Institute e IN5, é Entrepreneur Mentor in Residence (EMiR) na London Business School e é jurado da Entrepreneurship World Cup.
https://www.linkedin.com/in/ckadya/
https://www.matchpoint-partners.com/team/ck-adya.html
Este artigo faz parte de uma série contínua sobre a estrutura dos mercados privados e alternativos. As opiniões expressas são de responsabilidade do autor. O artigo tem caráter meramente informativo, descreve a estrutura de mercado em termos gerais e não constitui aconselhamento de investimento, jurídico, fiscal ou regulatório, nem recomendação em relação a qualquer valor mobiliário, veículo ou contraparte.
