Os ganhos obtidos com a inteligência artificial raramente aparecem no demonstrativo de resultados, o que geralmente é um problema de arquitetura, e não do modelo em si. As equipes lançam um projeto piloto funcional, mas logo percebem que os resultados são prejudicados por problemas como latência, consumo excessivo de recursos computacionais e incidentes de segurança que não foram previstos no orçamento. O modelo funciona. Mas a infraestrutura subjacente nunca foi projetada para suportar a workload em um ambiente de produção.
A Akamai encomendou dois estudos para testar a pressão onde essa falha acontece. O relatório "The State of AI Inference 2026" entrevistou 200 profissionais que trabalham com inferência em ambientes de produção, sendo três quartos deles engenheiros e arquitetos, e a maioria responsáveis por tomar decisões sobre implementação. O Estudo de Impacto da Segurança de APIs de 2026 entrevistou 1.840 profissionais de segurança em seis setores e 10 países.
Juntos, os dois relatórios apontam para uma única conclusão: A maioria das equipes está expandindo sua infraestrutura, originalmente projetada para treinamento, para que ela também possa ser usada para inferência. No entanto, essa adaptação revela problemas como aumento de custos, latência e exposição.
Essas lacunas são preenchidas quando três fatores se combinam:
Uma arquitetura que se adapta às condições de vida.
Segurança integrada à arquitetura, em vez de adicionada posteriormente.
A inferência foi posicionada de forma estratégica, próxima aos usuários, para atender às metas em tempo real.
Nada disso é uma novidade. O problema é tratá-los como projetos independentes, cada um sob a responsabilidade de equipes diferentes.
Comece pela estrutura. Inferência é o processo em tempo real em que um modelo treinado recebe novos dados e gera um resultado. Toda chamada de inferência é feita por meio de uma chamada de API, portanto, o modelo e a API não são questões independentes. Eles compartilham o mesmo caminho de solicitação, os mesmos modos de falha e a mesma superfície de ataque. Esse tema está presente em ambas as pesquisas.
Onde a centralização realmente falha
A inferência centralizada não está condenada ao fracasso. Para treinamento, processamento em lote e workloads que toleram latência, concentrar os recursos computacionais em algumas grandes regiões é frequentemente a melhor opção, e a Akamai utiliza essa abordagem para executar muitas dessas workloads. A história contada pelos dados é mais concisa e mais útil: A centralização não funciona para um tipo específico e crescente de workload, e muitas equipes ainda não se adaptaram a essa nova realidade.
O relatório sobre o estado da inferência em IA revelou que 75% das organizações já implementaram a inteligência artificial generativa (IA generativa) no ambiente de produção, mas a infraestrutura dessas empresas ainda não conseguiu acompanhar esse avanço. Uma parcela cada vez maior dessas workloads exige requisitos rigorosos de latência em tempo real, que não podem ser atendidos por uma rota até uma região distante. Além disso, 60% dos profissionais consideram a proximidade com os usuários e os dados como “importante” ou “crítica”.
Mesmo assim, 46% ainda realizam a inferência a partir de uma única região centralizada. O problema não é que a centralização falhe em todos os lugares, mas sim que uma parcela crescente da inferência de produção precisa ocorrer mais perto do usuário do que um modelo centralizado permite.
As workloads que falham primeiro são previsíveis: detecção de fraudes em transações em tempo real, agentes de voz, personalização em tempo real e qualquer pipeline agêntico que envolva múltiplas chamadas a modelos antes de retornar uma resposta. Cada salto herda a latência do anterior. Ao concentrar tudo em uma única região, os atrasos nas filas aumentam à medida que o uso cresce, adicionando centenas de milissegundos justamente quando a workload menos pode suportá-la.
Portanto, a verdadeira questão não é centralização versus descentralização como questão de fé. A verdadeira questão é quais workloads precisam de proximidade e quais não precisam. As equipes que fazem isso da maneira certa respondem deliberadamente a essa questão, workload por workload, em vez de simplesmente concentrar tudo em uma única região e arcar com o custo da latência.
Arquitetura adaptável e os custos invisíveis
Um baixo retorno sobre o investimento geralmente indica que uma equipe está compensando falhas operacionais em vez de estruturais. O que importa é a economia unitária: o custo de uma única solicitação de inferência, medido por token ou por consulta. Se você não consegue ver esse número, não consegue otimizá-lo nem perceber quando ele foge do seu controle.
A maioria das equipes não consegue enxergar isso. 77% das organizações não têm uma análise econômica consistente em nível de unidade que permita monitorar e inferir dados, o que significa que a maioria não consegue determinar se uma workload está se tornando mais barata ou mais cara à medida que escala. Essa falta de visibilidade também representa uma falha de segurança. Um aumento repentino e inexplicável no consumo de tokens é frequentemente o primeiro sinal de um ataque de negação de carteira (DoW), no qual um invasor aumenta intencionalmente o volume de inferência para elevar os custos.
Quando a arquitetura não consegue se adaptar por si só, os engenheiros recorrem à intervenção manual. Quando há um aumento repentino de tráfego em uma região, eles redirecionam o fluxo manualmente. Eles comprometem a qualidade das respostas para manter um servidor sobrecarregado em funcionamento. Quando a inferência fica mais lenta, 51% das equipes tentam usar o mesmo modelo novamente, o que geralmente piora o congestionamento em vez de resolvê-lo. Isso é uma medida de contingência, e não é uma estratégia que escala. Aumentar a escala de um sistema rígido também aumenta suas perdas.
A solução é de natureza programática:
Marque cada solicitação de inferência com metadados do modelo e dos tokens, que sejam enviados ao monitoramento em tempo real, para que um modelo que esteja consumindo recursos excessivamente seja identificado antes que comprometa o orçamento.
Defina o comportamento de falha aberta e falha fechada no código, para que o sistema possa recorrer a um resultado armazenado em cache ou a um modelo local menor quando o sistema principal não estiver respondendo, sem precisar acordar um engenheiro às 2 da manhã.
64% dos profissionais já consideram a automação do direcionamento de tráfego um requisito essencial, o que mostra que o mercado já percebe para onde essa tendência está indo.
A distribuição é o mecanismo que garante o desempenho.
Quando o baixo retorno sobre o investimento se manifesta como alta latência e baixa conversão, a causa principal geralmente está relacionada à geografia. A inferência em tempo real é intermitente e sensível à latência e não pode ser realizada de forma confiável pela Internet pública em conjunto com um data center distante.
A matemática não perdoa. Se o seu orçamento total for de 250 milissegundos, sendo 100 ms destinados ao processamento e 50 ms ao handshake da API, restam 100 milissegundos para a transmissão dos dados. Basta atravessar um continente para que o orçamento se esgote antes mesmo de o modelo começar a processar a solicitação.
Realizar a inferência em pontos de presença distribuídos permite que o processamento pesado ocorra na mesma região do usuário, evitando a sobrecarga da Internet pública e eliminando o limite de velocidade imposto por uma infraestrutura centralizada. A resposta parece natural porque, em termos de rede, ela é local.
Quando falamos sobre agentes de inteligência artificial, diz-se que são necessárias cerca de seis interações para que uma tarefa seja realmente concluída. Se o usuário estiver tão distante que a interação leve 100 milissegundos, você já gastará 600 milissegundos. Isso pode ser aceitável para algumas aplicações, mas hoje em dia existem muitas aplicações que são desenvolvidas na borda da rede e que são sensíveis à latência. O sistema de IA integrado ao seu veículo é extremamente importante para garantir que todos os seus dados e informações sejam transmitidos mais rápido.
A distribuição tem mais uma função importante para a segurança. Quando a inferência e a aplicação ocorrem no mesmo local, a rede pode autenticar o usuário, verificar a chamada da API e executar o modelo em um único lugar. Você fecha o ciclo em vez de enviar a solicitação para outras zonas para que ela seja verificada em outro lugar.
A segurança é uma característica da arquitetura, e não um elemento separado.
Se você não garantir a inferência, não conseguirá escalá-la. Se você tratar a segurança como uma atividade paralela, pagará o preço em termos de desempenho. Ambos os estudos afirmam que o verdadeiro problema não está na topologia, mas sim nas APIs que são inseguras, não testadas e invisíveis.
Os dados são alarmantes: 87% das organizações sofreram um incidente de segurança relacionado a APIs no último ano, um aumento significativo em relação aos 76% registrados em 2022. Entre as equipes que enfrentaram incidentes, os ataques a APIs relacionadas à inteligência artificial foram o tipo mais comum de problema de segurança relacionado a APIs mencionado no estudo, com 42% dos casos envolvendo ataques a APIs vinculadas a tecnologias de IA.
Atualmente, o custo médio de um incidente é de US$ 700.000 por ano, enquanto os casos mais graves podem ultrapassar US$ 1,8 milhão. APIs relacionadas à inteligência artificial não representam um risco futuro, mas sim um risco atual.
Você não pode proteger aquilo que não consegue ver
A visibilidade piora quando isso acontece. Apenas 23% das empresas sabem quais APIs retornam dados confidenciais, em comparação com 40% em 2022. Você não pode proteger um patrimônio que não consegue ver, e a IA está expandindo esse patrimônio mais rápido do que um inventário manual é capaz de acompanhar. Os copilotos criam endpoints que nunca passam por uma avaliação de segurança. Interfaces de linguagem natural simplificam a extração de dados por meio de injeção de comandos por um invasor que encontra uma rota desprotegida.
É importante destacar que o ponto de partida não conta toda a história. Um invasor que consegue acessar uma única API exposta tentará se mover lateralmente em direção aos componentes que possuem maior valor: os repositórios de recursos que armazenam dados de IA e os repositórios que contêm os pesos e a lógica dos modelos.
A microssegmentação, uma prática de segurança que isola workloads individuais, é o que limita o impacto de uma explosão. A maioria das organizações ainda não implementou essa medida, mas aquelas que o fizeram conseguem conter ataques de forma significativamente mais rápida. A segmentação baseada em redes legadas é amplamente reconhecida como um processo complexo, trabalhoso e ineficaz. A microssegmentação moderna, impulsionada pela inteligência artificial, resolve esse problema, mas enfrenta desafios relacionados a vieses enraizados. Se você integrar essa segmentação à mesma rede que fornece a inferência, evita o dilema entre proteção e desempenho.
O padrão de implementação é baseado em identidade. As organizações devem:
Defina o acesso com base na identidade da workload, e não no endereço IP, para que um serviço de inferência específico possa acessar apenas um repositório de recursos específico e nada mais.
Realize uma descoberta contínua de APIs para identificar endpoints de teste abandonados que ainda estejam conectados a dados de produção.
A segurança passa a ser uma característica intrínseca do sistema, em vez de uma auditoria pontual que os desenvolvedores precisam contornar.
Um problema com duas vertentes
O problema mais profundo revelado por ambos os estudos é de natureza organizacional, e não técnica. As equipes desenvolvem o tráfego e a segurança em sistemas separados, e é na interseção entre os dois que surgem as falhas.
Essa diferença se manifesta como uma lacuna de confiança: 40% dos líderes executivos relatam que têm um alto nível de maturidade em testes de API, enquanto apenas 28% das equipes de DevSecOps que realizam esse trabalho concordam com essa afirmação. Os líderes acreditam que o problema está resolvido, então a base continua com recursos insuficientes, enquanto os investimentos são direcionados para ferramentas relacionadas. A distância entre o que os líderes acreditam estar protegido e o que está realmente protegido continua aumentando.
Para reduzir essa distância, é necessário que as equipes responsáveis pelo gerenciamento do tráfego e as responsáveis pela segurança do tráfego operem no mesmo plano de controle ou pelo menos em um plano convergente. Quando a detecção e a contenção operam no mesmo nível, um padrão de solicitação anômalo, característico de injeção de comandos ou de ataques DoW, pode acionar automaticamente o isolamento do endpoint de inferência afetado, sem a necessidade de intervenção humana. Essa sincronização só é possível quando a distribuição e a segurança não são sistemas separados.
O que pode ser escalado a partir daqui?
Duas habilidades diferenciam as equipes que crescem daquelas que estagnam:
Portabilidade. Operadores experientes têm muito menos restrições, pois podem transferir workloads entre GPUs gerenciadas, APIs hospedadas e ambientes de execução sem servidor, conforme as variações de custo e capacidade.
Governança em tempo de execução. O controle tanto dos prompts maliciosos de entrada quanto das respostas de saída que vazam dados é aplicado na camada de rede, em vez de ser acrescentado à aplicação posteriormente.
Coloque tudo isso em uma única plataforma onde distribuição, segurança e gerenciamento de tráfego compartilham o mesmo plano de controle, eliminando o conflito entre proteção e desempenho. Você tem uma visão geral do que está em execução, onde ela está ocorrendo e se está sob ataque.
Esse é o problema que a Akamai vem resolvendo nas áreas de entrega de conteúdo e segurança e que agora está resolvendo para a inferência em produção. A mesma rede global que posiciona a inferência próxima aos usuários também gerencia a segurança da API, a microssegmentação e a proteção contra negação de serviço distribuída (DDoS) ao seu redor. É essa capacidade que permite que uma única rede execute ambas as tarefas simultaneamente.
A ROI de IA frágil é um sintoma
O problema é que a infraestrutura ainda não conseguiu integrar arquitetura adaptável, segurança e distribuição em uma única base. A diferença entre desempenho e proteção está aumentando, mas isso não é um problema estrutural nem permanente. Essa lacuna é eliminada quando as equipes responsáveis pelo tráfego são as mesmas que garantem a segurança da infraestrutura, projetada para realizar inferências, em vez de ser adaptada para suportá-las.
Saiba mais
Para saber mais, leia o relatório The State of AI Inference 2026 e o estudo sobre o impacto da segurança de APIs.
Tags
