Em junho de 2026, o sinal mais importante para as empresas não é a chegada de mais um LLM nem mesmo a guerra dos benchmarks. A verdadeira viragem, visível em Google Cloud, AWS, Microsoft e Databricks, está noutro ponto: o MLOps torna-se uma disciplina de exploração de agentes, com quatro temas a ganhar peso ao mesmo tempo - contexto de negócio, governança, observabilidade e custo unitário de inferência. Quando todos os grandes players reorganizam os seus anúncios em torno de runtime, identidade, gateways, memória, rastreabilidade e avaliação contínua, isso já não é um efeito de moda; é uma mudança de camada.
Em outras palavras: em 2024, perguntava-se sobretudo qual modelo escolher; em 2026, a questão que decide a passagem para produção é antes quem controla o contexto, as permissões, os rastros, os custos e a capacidade de mudar de fornecedor. Microsoft escreve isso quase explicitamente: o gargalo já não é a capacidade dos modelos, mas o contexto partilhado da empresa. Databricks, por sua vez, explica que o loop agentic visível é apenas uma pequena parte do trabalho e que o resto corresponde a uma dívida técnica oculta feita de segurança, deployment, monitoring, custo e qualidade. AWS insiste agora na melhoria contínua a partir dos traces de produção. Google empurra uma plataforma completa para construir, implantar, governar e otimizar agentes.
Não é a IA que entra no cloud; é o cloud que volta a ser o sistema operativo da IA.
A viragem visível em todos os fornecedores
O ponto em comum dos anúncios desta primavera e deste mês de junho é impressionante. Google Cloud lançou Gemini Enterprise Agent Platform como uma plataforma destinada a construir, escalar, governar e otimizar agentes, reunindo seleção de modelos, ferramentas de integração, DevOps, orquestração e segurança numa única camada. No Google Cloud Next ’26, Google também destacou um Agent Developer Kit baseado em grafos, bem como Agent Studio para construir, testar e publicar agentes em grande escala.
Na Microsoft, a mensagem do Build 2026 é pouco menos explícita. A empresa afirma que o problema já não é a potência do modelo, mas a capacidade de fornecer um contexto de dados coerente a agentes que precisam de atuar nos sistemas de negócio. A página oficial do Build 2026 destaca, entre os principais anúncios, componentes que vão de “observability to ROI for AI agents” à governança portátil de agentes, passando pela implantação e execução em grande escala de Foundry.
AWS, por sua vez, colocou o Bedrock AgentCore numa lógica de exploração industrial. O anúncio de 18 de junho de 2026 sobre as novas capacidades de otimização não insiste primeiro na criação de agentes, mas sim num ciclo em que os traces de produção servem para perceber o que está a acontecer, corrigir o que falha e provar que as correções melhoram realmente o sistema. AWS formula até o verdadeiro risco em termos muito claros: as falhas mais perigosas não são as que devolvem um erro, mas os falhanços silenciosos que só aparecem mais tarde nas reclamações dos clientes.
Databricks segue exatamente a mesma leitura, com outras palavras. No seu artigo da DAIS 2026, a empresa explica que o loop agentic é apenas o “1%” visível, enquanto os “99%” restantes dizem respeito a deployment, capacidade de tokens, segurança, avaliação, observabilidade, contexto e partilha. O mais interessante não é tanto o anúncio de produto, mas o enquadramento: para Databricks, o problema de mercado já não é como fazer uma demo de agente, mas como operar um sistema agentic fiável.
A lição para um decisor é simples: quando Google, AWS, Microsoft e Databricks convergem, cada um com o seu vocabulário, para os mesmos blocos - runtime, identidade, memória, gateways, tracing, scoring, governança - isso significa que se está a sair do ciclo “POC + hype” para entrar num ciclo de arquitetura. O centro de gravidade do MLOps desloca-se, assim, do modelo para a cadeia de exploração.
Porque o MLOps está a tornar-se AgentOps
Essa deslocação muda a própria natureza da stack técnica. Num MLOps clássico, o essencial era versionar dados e modelos, implantar um endpoint, acompanhar algumas métricas e depois reexecutar um pipeline de re-treino. Na stack de 2026, é preciso além disso gerir um runtime de agentes, memória curta e longa, direitos de ação, ferramentas externas, traces de execução, qualidade das respostas, conformidade dos comportamentos e latência de cadeias multi-etapas. Google já documenta esse empilhamento: a Agent Platform oferece um runtime gerido, sessões, uma Memory Bank, funções de logging, tracing e monitoring, bem como uma identidade por agente.
O detalhe mais interessante é provavelmente a ascensão da identidade agentic. Na documentação da Google, a Agent Identity assenta numa identidade cryptographically attested, baseada no standard SPIFFE, para autenticar um agente junto de servidores MCP, recursos cloud, endpoints e outros agentes. Em outras palavras, o problema já não é apenas “quem chama a API?”, mas “que agente atua, em nome de quem, com que perímetro de direitos?”. Trata-se de uma mudança maior: a segurança sobe para o nível do comportamento automatizado.
AWS segue na mesma direção com o AgentCore Gateway, que transforma APIs, funções Lambda e serviços existentes em ferramentas compatíveis com o Model Context Protocol, com autenticação de entrada e saída, integrações prontas a usar e controlo de acesso fino. Esta camada é estratégica porque liga o mundo dos agentes ao do SI real: CRM, mensagens, tickets, documentação, bases de dados, workflows. O MLOps deixa então de ser um tema puramente “model” para se tornar um tema de plataforma + integração + segurança.
A outra viragem é a observabilidade qualitativa. O MLflow 3 da Databricks já unifica o tracking, a avaliação e a observabilidade de aplicações e agentes GenAI com traces em tempo real, scorers, feedback humano e versioning. Em produção, Databricks propõe um monitoring que executa automaticamente scorers sobre amostras de traces para avaliar continuamente a qualidade - sinal de que já não se avalia apenas uma versão antes do deployment, mas o comportamento real após a entrada em circulação. AWS diz o mesmo de outra forma: o AgentCore Observability fornece métricas em tempo real sobre o número de sessões, latência, duração, uso de tokens e taxas de erro, com filtragem por metadados para investigação.
Por fim, a infraestrutura de inferência em si torna-se mais “plataforma” do que “simples alojamento GPU”. A CNCF recorda que o Inference Gateway baseado em Gateway API já está GA e permite rotear tráfego segundo o nome do modelo, os adaptadores LoRA e o estado dos endpoints, para melhor mutualizar pools de servidores e aumentar a utilização de aceleradores. Google reforça este movimento com a integração de NVIDIA Dynamo no GKE Inference Gateway, ao mesmo tempo que anuncia VM G4 fragmentáveis para dimensionar melhor as cargas. Também aqui, a questão já não é apenas onde encontrar GPUs?, mas como utilizar a capacidade de inferência com disciplina, mutualização e arbitragem fina.
O que isto muda do ponto de vista organizacional é decisivo: o MLOps passa a ter de trabalhar com segurança, plataforma cloud, data engineering, equipas IAM, equipas FinOps e, por vezes, jurídico. O “AgentOps” não é uma nova palavra da moda; é a prova de que a exploração da IA sai do silo da data science para entrar no núcleo operacional do SI.
O custo oculto que acaba por regressar ao orçamento
É aqui que o tema se torna verdadeiramente decisional. Segundo o State of the Cloud 2026 da Flexera, 58% das organizações já usam serviços GenAI de cloud público, 45% dizem utilizá-los de forma extensiva, 73% operam em híbrido, 49% recorrem agora a unit economics para ligar a despesa cloud aos resultados de negócio, e a percentagem estimada de desperdício IaaS/PaaS volta a subir para 29%. A Flexera nota também que 64% das organizações medem agora o cloud mais pela valor entregue às equipas de negócio do que pela mera eficiência de custos. Não é um detalhe: a conversa passa de “quanto custa?” para “qual o custo por serviço, por utilização, por workflow, por equipa, por cliente?”.
Esta evolução está alinhada com o que as empresas europeias já observam no terreno. A Reuters relata que grupos como Siemens, Renault, Orange ou ChapsVision multiplicam fornecedores para limitar o risco de dependência, mas também porque o custo por token se torna cada vez mais sensível à medida que os agentes automatizam mais tarefas. O artigo cita explicitamente a subida desta obsessão pelo custo unitário e o exemplo de um orçamento de tokens consumido muito mais depressa do que o previsto. Até os mercados financeiros se preocupam agora com o nível das despesas de infraestrutura de IA dos hyperscalers, sinal de que a questão do retorno económico saiu do círculo técnico.
É preciso acrescentar um ponto frequentemente mal compreendido: a fatura de um sistema agentic não se reduz ao preço da API do modelo. A AWS mostra, na sua própria página de pricing do AgentCore, que se somam custos em torno do modelo - chamadas gateway, memória de curto prazo, armazenamento de memória de longa duração, recuperação de memórias, observability - com linhas de custo separadas. Os exemplos de pricing publicados pela AWS ilustram precisamente essa granularidade: mesmo sem contar o custo do modelo em si, a camada de exploração agentic cria a sua própria economia.
O bom ângulo orçamental para um CIO ou um CFO já não é, portanto, “quanto me custa um prompt?”, mas “qual é o meu custo total por agente útil?”. Esse custo total inclui, no mínimo, o modelo, as ferramentas externas, a memória, o logging, o tracing, a segurança, os guardrails, o storage, os dados de contexto e o tempo humano necessário para avaliação e remediação. Se a empresa não acompanhar esta unidade económica, pode facilmente registar adoção sem saber se está a criar valor ou apenas carga cloud.
É por isso que o FinOps muda de natureza. A Flexera já não anuncia apenas funções clássicas de cloud cost management, mas uma camada de AI Cost Management que cobre aplicações, agentes, modelos, plataformas de dados e compute. A mensagem implícita é clara: a despesa de IA já não é um apêndice da despesa cloud; torna-se uma rubrica de pilotagem distinta, suficientemente complexa para exigir ferramentas dedicadas.
O cloud de IA volta a ser uma escolha de soberania
O outro erro de leitura seria tratar o cloud de IA como uma simples arbitragem técnica entre AWS, Azure e Google Cloud. Na Europa, em junho de 2026, o tema tornou-se também um problema de continuidade de atividade e de soberania operacional. A Comissão Europeia adotou, a 3 de junho, uma proposta de Cloud and AI Development Act, apresentada como uma alavanca para reforçar o ecossistema cloud e IA europeu, os seus investimentos e as suas infraestruturas. Ao mesmo tempo, o calendário oficial recorda que o AI Act será plenamente aplicável a partir de 2 de agosto de 2026, com regras de transparência a entrarem em vigor em agosto de 2026 e um quadro geral que reforça as responsabilidades de fornecedores e deployers.
Esta dimensão política já se traduz nas arquiteturas empresariais. A Reuters explica que grupos europeus aceleram a diversificação dos seus modelos e fornecedores após restrições de acesso a certos serviços norte-americanos, precisamente porque um serviço proprietário remoto pode ser limitado pelo seu fornecedor e não ser necessariamente operável nos próprios servidores do cliente. Nesse artigo, soberania não significa autarcia: Siemens, Orange ou Renault falam sobretudo de flexibilidade, de mix de fornecedores e de capacidade de fallback caso um interveniente corte o acesso ou altere as condições.
É neste contexto que se deve ler o anúncio da OVHcloud. A Reuters relata que o grupo francês quer treinar modelos de fronteira para se tornar um segundo grande player europeu de LLM, com um custo estimado de 150 a 200 milhões de euros para este novo ciclo tecnológico, muito longe do milhar de milhões de euros muitas vezes referido anteriormente. Quer a iniciativa resulte comercialmente ou não, ela diz algo importante: a soberania cloud IA já não é um discurso institucional abstrato; está a subir para a estratégia de produto e infraestrutura de grandes players europeus.
Para uma empresa, a tradução correta desta tensão é concreta. Uma arquitetura “soberana” não é apenas uma arquitetura alojada na Europa. É uma arquitetura capaz de identificar que componentes devem ser operáveis internamente, que ferramentas devem permanecer substituíveis, que dados de contexto não devem ficar prisioneiros de um runtime proprietário e em que prazo um agente crítico pode mudar de modelo ou de fornecedor. A partir do momento em que o agente atua sobre processos de negócio, a dependência do fornecedor torna-se uma variável de risco, não uma simples escolha de developer.
A grelha útil para decidir agora
A questão, portanto, não é “deve-se fazer MLOps para a IA generativa?”, mas sim que tipo de exploração se quer padronizar. A grelha abaixo sintetiza o que os sinais de junho de 2026 realmente mudam para uma empresa. Serve para arbitrar um orçamento, uma trajetória de arquitetura ou uma escolha de fornecedor.
| Eixo de decisão | O que muda em 2026 | Pergunta a colocar em comité |
|---|---|---|
| Arquitetura | A base já não é um endpoint de modelo, mas um conjunto runtime + memória + gateway + identidade + traces + avaliação. | Queremos padronizar um runtime de agentes único, ou manter uma camada portável entre vários clouds e frameworks? |
| Governança | A observabilidade torna-se comportamental: tokens, latência, sessões, ferramentas invocadas, traces, feedback, scoring contínuo. | Que indicadores devemos exigir antes de qualquer passagem para produção: custo, qualidade, groundedness, segurança, tempo de resolução? |
| Orçamento | A despesa de IA torna-se composta: modelo, memória, ferramentas, logs, tracing, segurança, dados, capacidade GPU. A Flexera observa a subida dos unit economics e do desperdício cloud. | Conhecemos o custo total por agente útil, por jornada de utilizador ou por área de negócio? |
| Contexto de negócio | Microsoft insiste que o gargalo já não é o modelo, mas o contexto partilhado; Databricks faz da qualidade do contexto e da governança do conhecimento um pilar da sua plataforma. | Que conjuntos de dados, ontologias, documentos e permissões constituem a nossa “fonte de verdade” para os agentes? |
| Soberania | Na Europa, a resiliência passa pela diversidade de fornecedores, pela substituibilidade e pela capacidade de operar certas componentes localmente; o quadro regulatório aperta-se até agosto de 2026. | Se um fornecedor alterar as regras de acesso, em quantos dias conseguimos fazer fallback de um agente crítico? |
A consequência mais prática é que as compras de cloud IA já não devem ser avaliadas primeiro pelo “melhor modelo disponível”, mas por cinco critérios menos espetaculares e mais decisivos: portabilidade do contexto, qualidade da observabilidade, granularidade dos controlos, visibilidade dos custos e capacidade de fallback. Um fornecedor pode ser excelente em demonstração e fraco em industrialização. É precisamente esse desfasamento que começa a estruturar o mercado.
O que os players mais avançados já perceberam
O sinal a ler com antecedência é este: a próxima batalha da IA empresarial não vai centrar-se principalmente no acesso a um modelo melhor, mas na capacidade de fazer viver agentes dentro de um quadro económico e jurídico sustentável. As organizações que avançam mais não são apenas as que implementam mais depressa; são as que tornam os agentes mensuráveis, alteráveis e governáveis. Tratam o contexto como um ativo estratégico, o custo como uma métrica de produto e a segurança como uma política de ação, e não como uma lista de acessos.
É claro que é preciso manter uma reserva metodológica. Uma parte importante do sinal provém de anúncios de fornecedores e de documentação de produto; algumas funções ainda estão em beta ou em preview, como o monitoring de produção do MLflow 3 na Databricks. Isso significa que a adoção real será mais lenta e mais desigual do que as keynotes sugerem. Mas essa limitação não altera o diagnóstico de fundo: quando os quatro grandes ecossistemas cloud e data convergem para as mesmas primitivas técnicas, o movimento tem fortes probabilidades de durar.
A frase-tese que merece ser retida é, portanto, a seguinte: o verdadeiro tema do MLOps & Cloud IA em 2026 já não é servir um modelo, mas explorar agentes com contexto, provas e guardrails. As empresas que lerem isto apenas como um tema de tooling ficarão para trás. As que virem aqui uma reformulação da pilotagem cloud, do controlo financeiro e da governança operacional estarão melhor posicionadas para absorver a próxima vaga.