Google Cloud Next 2026: 200 Mil Milhões de Capex Não Compram Maturidade de Produção

O artigo de Alex Scroxton na Computer Weekly sobre Google Cloud Next 2026 aterra na inquietação correta — a indústria produz demasiado slop de IA e pouco valor — mas fica um piso aquém de onde eu queria ter a conversa. Como engenheiro de DevOps que tem de pôr realmente estes stacks em produção à escala enterprise, o meu problema com Cloud Next não é o DJ set com Gemini. É a distância entre a keynote e o runbook.

Thomas Kurian abriu o evento com uma frase que devia fazer pestanejar qualquer SRE: "Já ultrapassaram o piloto, a fase experimental ficou para trás." Apoia-o um número real — três quartos dos clientes da Google Cloud já usam a IA da Google de alguma forma — e um cheque real: cerca de 200 mil milhões de dólares de capex comprometidos em infraestrutura de IA. Silício novo (TPU 8i para inferência, TPU 8t para treino). O Gemini Agent Platform apresentado formalmente. O caso Capcom: um workbench multi-agente a correr 30.000 horas humanas por mês de trabalho. Citi Sky, um consultor patrimonial bilingue construído sobre o stack completo de IA da Google.

Esse é o pacote de marketing. O pacote técnico, o que ninguém no Moscone teve vontade de discutir no palco principal, é a fatura operacional que vem com as palavras "em produção".

A crítica do slop tem razão, mas não é o problema que aguenta a carga

A preocupação central de Scroxton é criativa: música gerada por IA, arte gerada por IA, o custo cultural de substituir humanos por mediocridade estatística. É justa, e partilho-a em boa parte a nível pessoal. Mas de onde estou, o slop está a jusante de uma decisão mais perigosa: meter workloads de IA em ambientes de produção partilhados sem a maturidade operacional que esses ambientes exigem.

O slop dilui uma playlist do Spotify. Uma má IA em produção dentro de um banco dilui o audit trail. O primeiro é chato. O segundo é um convite aberto ao regulador.

O enquadramento hype-versus-realidade que a peça da Computer Weekly escolhe é o artístico. Eu quero insistir no de engenharia, porque é aí que vão aparecer os corpos.

"Para além do piloto" não é um vibe. É uma disciplina.

Quando Kurian diz que a fase experimental ficou para trás, a tradução honesta é: muitos clientes têm um notebook em Vertex AI, uma chave de API Gemini e pelo menos uma feature flag a apontar tráfego real para um modelo. Isso não é o mesmo que "em produção" no sentido em que uma equipa de pagamentos ou uma equipa de SRE usa o termo.

Para pôr um modelo em produção, no sentido que defenderia perante um board ou um regulador, no mínimo precisas de:

• Observabilidade que entenda o workload. Latência p99 por modelo e por rota. Custo de tokens por request. Cache hit rate. Eval drift sobre um benchmark congelado. Nada disto vem "de borla" com um deploy do Gemini Agent Platform. Constrói-lo tu.
• Atribuição de custo até à equipa. Se três pods partilham um endpoint de inferência, quem paga que pico? Com 200 mil milhões$ de capex a montante, a fatura da cloud deixa de ser uma nota de rodapé das finanças e passa a ser uma preocupação primária de engenharia.
• Resposta a incidentes que saiba de sistemas não determinísticos. Um modelo que ontem estava certo e hoje se engana não é um bug de deploy. É uma regressão de comportamento sem um alvo claro de rollback. O runbook tem de refletir isso.
• Governance que sobreviva a uma auditoria. Lineage de que template de prompt produziu que decisão, contra que versão de modelo, com que contexto de retrieval. Se não consegues responder isso sob declaração, não tens um sistema de produção. Tens uma demo com tráfego.

Nenhum destes pontos foi manchete em Cloud Next. Foram dados como certos. Esse é o buraco.

O número da Capcom, lido como SRE

O workbench da Capcom é genuinamente impressionante: um agente de inspeção visual sobre Gemini Vision, um agente preditivo sobre dados históricos, um agente de conhecimento institucional, um agente de eficiência de dados. Resultado, segundo a keynote, "30.000 horas humanas todos os meses".

Lê-o como engenheiro de DevOps, não como CMO.

Trinta mil horas por mês significam aproximadamente 170 FTE equivalentes de trabalho de agentes a correr continuamente contra dados de produção. As perguntas a que eu queria resposta antes de assinar:

• Qual é o SLO de cada agente? Não o SLA do fornecedor do LLM. O SLO composto end-to-end, incluindo retrieval, pós-processamento e o loop de revisão humana.
• Qual é o failure mode quando o agente preditivo se engana silenciosamente durante uma semana? As predições não crasham. Driftam. Tens um eval offline a correr contra um golden set congelado, e um alerta quando as saídas do agente divergem mais do que um X%?
• Quem está on-call do stack de agentes? Se o agente de eficiência do pod A está a esfomear o índice de retrieval do pod B de cache, quem pagina quem? "A equipa de plataforma" só funciona se existir e tiver autoridade.
• Qual é o caminho de rollback? Os modelos são versionados, mas os templates de prompts, os índices de retrieval e as definições de ferramentas normalmente não. Uma má mudança em qualquer um destes três pode degradar a qualidade sem disparar um único alarme de deploy clássico.

Nada disto é exótico. É a checklist aborrecida de SRE que tem sido a diferença entre "usamos IA" e "a IA funciona para nós" há dois anos. O tom da keynote — a fase experimental ficou para trás — corre o risco de empurrar os clientes para o primeiro quadrante saltando o segundo.

O stack do Agent Platform: mais camadas, mesmo on-call

O Gemini Agent Platform senta em cima do Vertex AI que senta em cima do TPU que senta em cima da nova geração 8i/8t. Da perspetiva de um comprador parece uma história integrada. Da perspetiva de DevOps parece quatro camadas a mais no grafo de dependências, cada uma com o seu próprio failure mode, o seu próprio sistema de quotas, a sua própria curva de preços e a sua própria consola onde um incidente se pode esconder.

Combina-o com a realidade genuinamente multi-cloud da maioria das empresas e sai um padrão familiar: um Gemini Agent a integrar-se com workloads em AWS, dados em Snowflake, auth em Okta, observabilidade dividida entre Datadog e um Grafana self-hosted. O slide limpo do Moscone esconde um novelo.

Duas consequências às quais eu, como CTO, prestaria atenção agora mesmo:

1. O vendor lock-in já não é uma pergunta de compras, é uma questão operacional. Uma vez que os teus templates de prompts, suites de evals e orquestração de agentes vivem dentro da plataforma de um vendor, o custo de migração deixa de medir-se em licenças e passa a medir-se em meses de trabalho de SRE.
2. Os compromissos de capex são apostas que fazes em nome de outro. Quando um hyperscaler anuncia 200 mil milhões$ de capex, a promessa implícita é que os preços se mantêm favoráveis enquanto sobe a carga. O risco implícito é que, três anos depois, a unidade económica force um reset de preços que aterra diretamente na roadmap da tua equipa de plataforma.

Nenhuma destas coisas é apocalíptica. Ambas são o tipo de risco que constróis num plano de plataforma a três anos quando o escreves honestamente.

Citi Sky e a parte do anúncio que sim subscrevo

O caso que eu levantaria contra a crítica do slop é Citi Sky. Um consultor patrimonial bilingue, construído sobre o stack de IA da Google, explicitamente enquadrado como aumento dos consultores humanos, não como substituição. Esse enquadramento é o que repito em cada post deste blog: a IA é implementável e valiosa quando amplia o que um especialista consegue fazer por hora, não quando tenta substituir o especialista.

Citi Sky deixa também um sinal mais silencioso que vale a pena recolher: uma instituição financeira regulada não aposta um produto de consultoria patrimonial à IA sem controlos sérios por baixo. Seja o que for que a keynote mostre, a equipa que está por trás tem data lineage, logging de decisões, revisão de model-risk-management e um padrão human-in-the-loop que conseguem defender perante a OCC. Essa é a parte do icebergue que o congresso não põe no slide.

Se a tua iniciativa de IA não tem um icebergue equivalente, não tens um Citi Sky. Tens um chatbot com marca.

O que queria ver na keynote do ano que vem

Se a Google Cloud Next 2027 quer convencer as pessoas que realmente mantêm estes sistemas de pé, isto é o que eu poria no palco principal em vez de um DJ com Gemini:

1. Padrões de produção para sistemas agênticos com SLOs nomeados. Não "corremos 30.000 horas por mês". Mostra-me latência p99, bandas de eval drift e a taxa de revisão humana, e diz-me que números não são negociáveis.
2. Uma história de cost-attribution de primeira classe. Por equipa, por agente, por rota. Com primitivas de chargeback dentro da própria plataforma, não coladas por cima por cada cliente.
3. Failure modes honestos para o Agent Platform. O que acontece quando o retrieval está stale? Quando as chamadas a ferramentas entram em loop? Quando uma API a jusante rate-limita um agente a meio de uma conversa?
4. Um modelo operacional de referência para equipas de plataforma. Dimensionamento, rotação de on-call, separação entre engenheiros de produto de agentes e engenheiros de plataforma. O pitch da Coinbase dos solo operators puros é um extremo; a assunção não dita de que o hyperscaler vai absorver a complexidade operacional por ti é o outro. Ambos estão errados.
5. Uma conversa adulta sobre evals. Como mostrou o próprio paper de ActionNex da Microsoft para AIOps, o estado da arte em incidentes reais ronda os 53% de recall. Esse não é um número que pões atrás de um consultor patrimonial sem uma camada de revisão humana muito grossa. O tom da keynote devia refleti-lo, não maquilhá-lo.

A linha que desenho

Scroxton tem razão em que a indústria produz demasiado slop. Mas o slop é um problema de economia criativa. O problema de infraestrutura — e é aquele com que eu tenho de conviver — é que "em produção" foi redefinido silenciosamente como "a chamar um LLM a partir de uma request path que já serve utilizadores." Não são o mesmo. O primeiro requer SLOs, observabilidade, cost-attribution, governance e resposta a incidentes pensados para sistemas não determinísticos. O segundo requer uma chave de API.

Duzentos mil milhões de dólares de capex compram muitos TPUs. Não compram uma equipa de plataforma. Não compram um runbook. Não compram a maturidade operacional que decide se a IA do teu stack é um multiplicador de produtividade ou um incidente latente à espera da sua primeira sexta-feira má.

As empresas que ganharem os próximos dois anos de IA não serão as que adotaram mais depressa. Serão aquelas cuja equipa de plataforma se recusou a chamar "produção" a algo que ainda não o era de verdade.

---

Fontes:

• Alex Scroxton, Google Cloud Next: It's time to create value, not slop, from the AI boom, Computer Weekly, 23 de abril de 2026. computerweekly.com
• Keynote da Google Cloud Next 2026, Thomas Kurian — números de adoção de clientes, TPU 8i/8t, Gemini Agent Platform.
• Estudos de caso da Capcom e Citi tal como apresentados em Google Cloud Next 2026.

A pôr IA em produção e não tens a certeza se a tua plataforma aguenta o peso operacional? Fala com um CTO — ajudamos-te a separar a keynote do runbook.