Ao abrir a 81ª Assembleia Geral das Nações Unidas, António Guterres fez um alerta que, à primeira vista, pertence ao campo da geopolítica: poder militar não é garantia de paz, e o mundo precisa evitar a formação de blocos rivais consolidados. A recomendação do secretário-geral por uma multipolaridade representativa soa como discurso diplomático de sempre. Mas para quem trabalha com tecnologia, especialmente com inteligência artificial aplicada, essa fala deveria funcionar como um alerta de arquitetura.
A razão é prática: há décadas operamos sob a premissa de que padrões tecnológicos emergem de forma razoavelmente unificada — a web, os protocolos da internet, os ecossistemas de nuvem — e que qualquer empresa global poderia adotar uma única estratégia de conformidade, uma única pilha de dados, um único modelo de governança de IA. Esse mundo acabou. O que Guterres problematizou no plano diplomático é o espelho exato do que já acontece no setor de tecnologia: a fragmentação em esferas de influência definidas por regimes regulatórios, soberania digital e fronteiras de dados.
A fala ganhou contornos concretos quando olhamos para o hardware, a camada de modelos e a infraestrutura de nuvem. Nenhuma tecnologia de fronteira — e a IA é a maior delas na atualidade — sobrevive na ausência de um ambiente geopolítico minimamente cooperativo. A pergunta que fica é: o que uma ordem multipolar significa na prática da engenharia de software e da estratégia de produto? A resposta exige sair da camada de abstração dos discursos e entrar no código, na nuvem e no planejamento de capacidade.
O bloco tecnológico não morreu: se reorganizou
Quando falamos em multipolaridade, a tentação é associar o termo apenas a países com poderio militar ou econômico. Mas no universo da IA aplicada, os polos são definidos por três forças entrelaçadas: capacidade computacional, volume de dados e régua regulatória. Estados Unidos, China e União Europeia — cada um com suas zonas de influência — estão desenhando o espaço de ação de engenheiros, cientistas de dados e arquitetos de software. E a lista de exemplos concretos é extensa.
De um lado, temos a estratégia americana de controle de exportação de semicondutores, que redefine a cadeia de suprimentos de modelos de larga escala. De outro, a lógica europeia do AI Act, que condiciona a entrada de sistemas de risco elevado a um marco probatório e documental — algo que mexe diretamente com o processo de desenvolvimento de produtos, e não apenas com o resultado final. E a China, por sua vez, com regras próprias de geração de conteúdo algorítmico e recomendações de ranking. A pergunta não é se sua empresa vai operar em conformidade com múltiplos sistemas. A pergunta é: sua arquitetura está preparada para responder de forma diferente a realidades diferentes sem implodir em manutenção?
A tensão entre inovação e controle de dados
Uma das consequências mais diretas de um mundo multipolar para quem implementa IA é o problema da origem dos dados. Modelos de aprendizado de máquina não vivem no vácuo; eles são resultado de trilhões de tokens, imagens e sinais gerados por populações inteiras. Quando você tem regulações que vinculam o uso de dados ao território onde ele foi coletado — como o RGPD na Europa ou a Lei Geral de Proteção de Dados no Brasil —, surge uma dificuldade técnica fundamental: o treinamento de um único modelo com dados de múltiplas jurisdições torna a comprovação de conformidade exponencialmente mais complexa.
Isso não é uma questão que se resolve com termos de consentimento mais longos. Exige decisões de arquitetura desde a concepção: onde cada réplica do modelo está sendo executada, quais dados saem da origem, qual camada de anonimização é aplicada antes de o dado tocar um pipeline de treinamento. Em minha experiência com automação de processos em empresas reguladas, os projetos que falham não são os que subestimam a precisão dos modelos; são os que subestimam os custos de garantir que a origem de cada dado seja auditável. Em uma ordem global unificada, a auditoria é um requisito de negócio. Em uma ordem multipolar, ela é o próprio produto.
Padrões técnicos concorrentes: o retorno dos formatos proprietários?
A ilusão de que a comunidade de engenharia viveria permanentemente em torno do ONNX, do PyTorch e das APIs abertas se depara agora com a pressão pelo controle de ponta a ponta. Empresas líderes de plataforma, de ambos os lados do Atlântico e do Pacífico, estão cada vez menos interessadas em interoperabilidade quando o alvo estratégico é garantir que o ciclo de vida do modelo — do treinamento à inferência — permaneça dentro do seu próprio raio de ação.
Para o engenheiro de software, isso significa avaliar constantemente o quão preso a um ecossistema o seu modelo está. Não apenas na camada de código, mas na camada de decisão: o retorno financeiro associado ao isolamento de um sistema de IA pode ser imenso no curto prazo, porém, em um cenário de sanções e barreiras regulatórias, a trava de plataforma se transforma em passivo competitivo. Minha recomendação sempre foi adotar padrões abertos quando possível, mas manter uma espessa camada de abstração de arquitetura para que a troca de um provedor de modelo não signifique uma reescrita completa no meio do caminho.
A engenharia de conformidade como ativo estratégico
Não faz sentido pensar em desenvolver equipes de IA para o ambiente corporativo sem criar uma função específica de engenharia de conformidade dinâmica. Diferente do compliance tradicional, que atua como auditoria reativa, o novo desenho exige que times de engenharia estejam cientes das mudanças regulatórias enquanto escrevem o código. Na prática, a regulação precisa ser codificada como parte dos requisitos funcionais do sistema. Por isso, sempre oriento líderes técnicos a incluírem os desaberes regulatórios no backlog de produto — não como dívida técnica, mas como um recurso de prioridade crítica.
Um modelo de recomendação que precise operar na União Europeia e na América Latina pode ser o mesmo em dados de treinamento generalizados, porém as camadas de explicação, leitura de dados sensíveis e retenção de informações mudam dramaticamente entre jurisdições. A sensação de que a regulamentação é um problema de advogado está superada. Advogados definem o teto; engenheiros definem o piso da implementação. Cada correlação, cada variável sensível protegida, cada fluxo de retenção que existe em um país e não outro deve ser um candidato natural a feature da sua plataforma.
Implicações para o mercado de trabalho em tecnologia
Para os profissionais que estão trilhando carreira em engenharia de software e IA, a multipolaridade impõe uma mudança de repertório. O especialista em modelos de linguagem que não tem noções fundamentadas de segurança, evidência de viés e governança de dados torna-se um profissional que opera apenas na camada de aplicação — a que mais sofre com a comoditização. Os salários mais altos, a partir de agora, estão vinculados a quem consegue provar a aderência do modelo ao ambiente legal e de mercado onde ele opera. Não é uma habilidade em separado: é a habilidade central do engenheiro de IA na década que se abre.
Essa leitura acaba por afetar também os cientistas de dados que atuam em plataformas de automação de processos. Precisamos entender que um fluxo de automação é em verdade um fluxo de decisão, e que os critérios de decisão estão condicionados não apenas pela qualidade do treinamento, mas pela política local. Um mesmo processo de aprovação de crédito, por exemplo, precisa ser matematicamente explicável na União Europeia, socialmente equânime no Brasil e tecnicamente regido pelas diretrizes de red teaming em outros países. Essa camada de mediação é onde a inteligência de engenharia efetivamente gera valor — e não na posse de uma biblioteca ou na escolha de um framework.
Riscos de uma fragmentação mal gerenciada
Vale a ressalva: a multipolaridade não é um desastre em si. Sistemas políticos com freios e contrapesos distribuídos costumam resistir melhor a abalos. Entretanto, no campo tecnológico, essa fragmentação tem um preço alto quando mal administrada. O custo de uma empresa manter cinco data centers em regiões distintas, com tradutores jurídicos e técnicos para cada regulação, pode facilmente drenar a capacidade de inovação de qualquer time maduro. A saída para as organizações não é escolher um polo vencedor, mas desenvolver uma espinha dorsal de código que aceite configurações regionais de dados e política como parâmetros de ambiente — algo muito próximo do que fazemos com feature flags, porém aplicado à conformidade.
Uma visão prática para navegar o novo cenário
Encerro com uma defesa de método. É imprescindível que as lideranças de tecnologia acompanhem as discussões sobre a ordem mundial atual não por modismo ou por obrigação jornalística, mas porque estão diante do principal driver de modificação do roadmap. Recomendo que times de engenharia criem o hábito de revisar trimestralmente o cenário regulatório dos mercados em que operam. Também sugiro que as decisões de infraestrutura considerem o custo de mudança caso uma rota marítima digital — ou seja, um cabo submarino, um provedor de nuvem ou um datacenter — seja interrompida ou passe a exigir autorização governamental.
O ponto central não é ser pessimista com a possibilidade de cooperação global; é parar de presumir que o contexto externo ficará estável por muito tempo. Quando Guterres pede uma multipolaridade representativa, ele está reconhecendo que o peso das decisões não está mais concentrado em uma única capital. As empresas que internalizarem essa descentralização, adotando arquiteturas modulares e capacitando seus times para a complexidade regulatória, estarão mais preparadas para o ciclo de transformação que começa. As que esperam uma padronização mundial de IA são as que ficarão para trás no momento em que a régua regulatória apertar.
A IA aplicada que vem por aí é multipolar ou não será
Há quem acredite que o debate geopolítico seja distante do trabalho de escrever código. Não é. A forma como conduzimos a implantação de IA em produtos digitais a partir de 2025 está, inevitavelmente, atrelada a um mapa de poder que se reorganiza constantemente. A boa notícia é que a engenharia sempre se beneficiou de limites claros: eles geram criatividade, forçam decisões e tornam o desenvolvimento de software um exercício de equilíbrio entre complexidade técnica e contexto humano.
Na prática, o que observamos é que a multipolaridade global não é um reforço de tendência — é uma nova condição de contorno. Para os engenheiros, a capacidade de operar nesse cenário não será apenas um diferencial competitivo. Será a diferença entre implementar uma prova de conceito que funciona e escalar um produto confiável que dialogue com o mundo de verdade. E isso, quero crer, independe do discurso de qualquer nação. Depende do que fazemos com o código que escrevemos.