Cloud e DevOps ultrapassam a pauta técnica de times de desenvolvimento e operação e chegam à mesa de decisões de arquitetura corporativa. Um episódio do podcast da InfoQ, publicado em agosto de 2026, discute cinco eixos por trás dessa mudança: inteligência artificial, confiabilidade, Platform Engineering, FinOps e soberania digital.
IA chega à infraestrutura de cloud
De assistentes de código a agentes autônomos
Até pouco tempo, a IA generativa aparecia principalmente como assistente de código, restrita ao uso individual de desenvolvedores. Esse uso passou a conviver com agentes que operam no nível dos times e, em alguns casos, atravessam toda a organização. Plataformas de IA, catálogos de modelos e infraestrutura dedicada a agentes entraram nas prioridades de tecnologia de grandes organizações, não apenas de equipes técnicas.
Isso muda a natureza da decisão. Um assistente de código é uma ferramenta que um desenvolvedor liga e desliga. Um agente autônomo, com acesso a sistemas internos e permissões próprias, passa a ter implicações de infraestrutura cloud que exigem:
- Um responsável definido;
- Políticas de acesso claras;
- Monitoramento contínuo.
Esse é um dos sinais mais claros de como a infraestrutura de TI muda ainda em 2026: deixa de ser tema restrito a um time técnico.
O impacto dos agentes na arquitetura
Equipes que ainda não têm processos claros de governança, permissões e coordenação entre áreas ficam expostas a essa mudança. Times diferentes acabam resolvendo o mesmo problema com agentes distintos, sem compartilhar conhecimento, o que gera duplicação de esforço e inconsistência na forma como a IA acessa dados sensíveis.
Uma das abordagens discutidas para lidar com essa complexidade é concentrar parte da governança na camada de API antes de multiplicar portais e integrações por cima dela. Sem esse cuidado, cada agente novo aumenta a superfície de ataque e a complexidade de auditoria, em vez de reduzir o trabalho manual que deveria eliminar.
Confiabilidade volta ao centro da estratégia de cloud
Arquiteturas preparadas para falhas
A conversa menciona interrupções associadas tanto a falhas operacionais quanto a fatores externos, reforçando que a resiliência cloud precisa considerar cenários além da indisponibilidade convencional. O tema reacendeu um debate que a corrida por IA havia deixado em segundo plano: a infraestrutura cloud continua sujeita a indisponibilidades em escala regional, independentemente de quão avançados sejam os modelos rodando em cima dela.
Arquiteturas preparadas para falhas partem do princípio de que uma região pode ficar indisponível a qualquer momento, e são desenhadas para continuar operando mesmo assim. Isso muda decisões básicas, como replicar dados entre regiões e testar failover antes de precisar dele de verdade.
Resiliência, observabilidade e continuidade
As defesas mais citadas contra falhas de disponibilidade são:
- Design multirregião;
- Testes de resiliência recorrentes;
- Prontidão operacional.
Nenhuma dessas práticas é nova, mas elas voltaram a ocupar uma posição central porque a atenção das equipes de arquitetura cloud estava concentrada quase inteiramente em modelos e agentes.
Observabilidade entra como pré-requisito: sem visibilidade sobre o comportamento de cada componente, incluindo os agentes de IA que agora rodam em produção, fica difícil identificar onde um incidente começou e quanto tempo uma falha vai durar antes de virar indisponibilidade para o usuário final.
Platform Engineering ganha uma nova responsabilidade
Da infraestrutura como serviço à plataforma para desenvolvedores
Times de Platform Engineering ampliaram o escopo além de provisionar infraestrutura. A nova responsabilidade inclui padronizar capacidades de IA, definir quais modelos podem ser usados e manter um catálogo central de acesso, para que cada time não precise negociar isso sozinho.
Um modelo citado no episódio organiza essa estrutura em torno de um gateway central de IA, que funciona como gerenciamento de API aplicado a modelos, com um catálogo de modelos aprovados e áreas específicas onde cada time constrói sua própria solução sobre essa base.
Padronização também significa governança
Padronizar facilita o uso e, ao mesmo tempo, define com clareza quem acessa o quê. Em uma enquete informal mencionada no episódio, realizada durante uma apresentação no KubeCon, cerca de 70% das mais de mil pessoas presentes associaram Platform Engineering a uma nova denominação para DevOps.
info: Um catálogo de modelos aprovados funciona como uma camada inicial de governança e controle do uso de IA dentro da empresa.
Essa formação inclui separar com mais clareza dois papéis: o desenvolvedor, que trabalha em camadas mais altas de abstração, e o engenheiro de plataforma, que segue próximo da infraestrutura cloud e da arquitetura que sustenta os agentes de IA em produção.
FinOps precisa acompanhar o crescimento da IA
O custo deixa de ser apenas infraestrutura
O consumo de tokens de IA virou uma linha de despesa relevante nos orçamentos de tecnologia. Equipes de desenvolvimento chegam ao limite do orçamento de tokens sem ter ainda uma métrica clara de quanto valor esse gasto gerou, e parte do preço atual pode estar subsidiada pelos próprios provedores, o que torna a previsão de custo real a longo prazo um desafio a mais para times de FinOps.
Esse é um novo campo de atuação para a disciplina. A prática, tradicionalmente associada à gestão e otimização de custos de infraestrutura cloud, agora amplia o escopo para cobrir uma linha de despesa inédita, sem histórico para comparar.
Consumo precisa ser relacionado ao valor gerado
As práticas de FinOps para IA ainda estão amadurecendo, mas dois caminhos começam a se consolidar: gateways de IA com políticas de consumo por time, que mostram quem está gastando o quê, e roteamento automático de tarefas simples para modelos mais baratos, evitando usar um modelo de ponta para resolver um problema que não exige esse porte.
Juntas, essas práticas dão a essas equipes a visibilidade que faltava para o gasto com IA parar de ser uma surpresa no fim do mês.
Soberania digital entra na arquitetura
Onde os dados são armazenados e processados
Organizações europeias vêm avaliando estratégias de nuvem soberana, embora ainda dependam fortemente de provedores globais para aplicativos e serviços críticos. Steef-Jan Wiggers, editor da InfoQ, resumiu o dilema em uma frase: "para sermos totalmente soberanos, teríamos que reconstruir e reprojetar tudo."
Isso mostra o tamanho do problema: soberania digital exige decisões de arquitetura que envolvem cada aplicação construída nos últimos anos sobre uma base que não foi pensada para isso, muito além de uma configuração que se liga numa conta de nuvem.
Controle, dependência e requisitos regulatórios
Boa parte das alternativas europeias de nuvem enfrenta limitações de escala para substituir os grandes provedores. Ainda assim, algumas organizações europeias também reavaliam a dependência de provedores globais e consideram ampliar o uso de ambientes próprios ou de alternativas soberanas.
No Brasil, uma preocupação semelhante aparece por meio de iniciativas de soberania e proteção de dados, embora em um contexto institucional e regulatório diferente do europeu.
O governo federal vem consolidando, desde 2025, a Nuvem de Governo, operada por Serpro e Dataprev, com mais de R$ 1 bilhão investidos e mais de 250 órgãos federais já conectados. O modelo é híbrido: dados sensíveis ficam sob operação estatal, enquanto parte da infraestrutura ainda depende de provedores globais.
A discussão também envolve legislações extraterritoriais, como o Cloud Act, além de requisitos locais de proteção de dados, continuidade e controle operacional.
Em 2026, essa discussão ganhou uma camada adicional com a IA: o debate sobre soberania digital passou a incluir não só onde o dado fica, mas também quem o usa para treinar modelos, uma das dimensões previstas no Plano Brasileiro de Inteligência Artificial, que prevê R$ 23 bilhões em investimento até 2028, segundo a Agência Gov.
Segurança cloud e soberania digital andam juntas: controlar onde os dados ficam também significa controlar quem acessa e sob qual jurisdição. No Brasil, a própria infraestrutura voltada à soberania digital ainda depende de parceria com provedores internacionais.
O que essas tendências significam para a arquitetura de TI
As tendências de Cloud e DevOps em 2026 discutidas aqui têm um fio condutor: nenhuma delas se resolve escolhendo a ferramenta certa. IA na infraestrutura, confiabilidade, Platform Engineering, FinOps e soberania digital são decisões de arquitetura de TI que precisam ser tomadas em conjunto, porque uma afeta diretamente a outra.
Um agente de IA mal governado ameaça a confiabilidade. Um modelo hospedado na região errada pode comprometer a soberania. Um catálogo sem controle de custos dificulta a atuação do FinOps.
Projetos de arquitetura cloud e infraestrutura de IA precisam considerar essas questões desde o desenho inicial, antes que riscos de custo, governança ou resiliência se materializem.
É nessa interseção entre cloud, dados, IA, segurança e arquitetura que surgem os principais desafios para as empresas. A dataRain atua justamente nesse espaço, ajudando organizações a desenhar e evoluir ambientes preparados para escalar com controle, resiliência e governança.
O futuro de Cloud e DevOps depende de arquitetura
A infraestrutura de nuvem avança em direção a arquiteturas que equilibram velocidade na adoção de IA, controle de custos, resiliência e conformidade regulatória. Organizar processos, times e orçamentos para que a tecnologia evolua com controle importa mais agora do que escolher a ferramenta certa.
Entender essas cinco tendências ajuda as empresas a decidir com mais clareza onde investir em arquitetura.