O que é computação em nuvem?

Computação em nuvem é o modelo em que você aluga processamento, armazenamento e software de um provedor, pela internet, e paga só pelo que usou no mês, sem comprar servidor. A definição formal é do NIST, de 2011, e vale até hoje. Este guia explica como a nuvem funciona por trás de um clique, o que diferencia IaaS, PaaS e SaaS, quanto ela custa de verdade, o que a LGPD exige quando o dado sai do país e quando o servidor próprio ainda compensa.

• 36% das empresas brasileiras pagavam por processamento em nuvem em 2025, ante 21% em 2017, segundo a TIC Empresas do Cetic.br
• 52,7% das empresas da União Europeia usavam nuvem paga em 2025, segundo a Eurostat
• 843 MW foi a demanda de energia dos data centers brasileiros em 2024, no mapeamento do Cetic.br
• 415 TWh, ou 1,5% da eletricidade mundial, foi o consumo dos data centers em 2024, com projeção de 945 TWh para 2030, segundo a IEA
• Má configuração do cliente, e não falha do provedor, é a principal causa de incidentes em nuvem, segundo a CISA em 2023

O que é computação em nuvem e o que muda em relação ao servidor próprio

Computação em nuvem é o modelo em que você aluga processamento, armazenamento e rede de um provedor, pela internet, paga pelo que usa e não compra máquina nenhuma. O servidor próprio é o contrário disso: você compra o hardware, instala no seu rack, paga a energia e torce para ter acertado o tamanho. Na nuvem, a capacidade aparece com um clique e some com outro.

A definição que a indústria inteira adota veio da publicação SP 800-145 do NIST, o instituto de padronização dos Estados Unidos, em 2011:

“a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources”

Em português: acesso sob demanda, via rede, a um conjunto compartilhado de recursos que você provisiona e libera com esforço mínimo. Cada pedaço dessa frase vira uma característica, e o NIST lista cinco. Vale traduzir cada uma para o contraste com o servidor na sala do fundo:

• Autoatendimento sob demanda: você cria uma máquina virtual às 3h da manhã sem abrir chamado para ninguém. No servidor próprio, capacidade nova é pedido de compra, prazo de entrega e alguém instalando.
• Amplo acesso via rede: o recurso responde por protocolos padrão a notebook, celular e outro servidor. A máquina no escritório muitas vezes só é alcançável de dentro da rede da empresa.
• Pooling de recursos: o provedor atende vários clientes na mesma infraestrutura física (o tal modelo multi-tenant) e realoca capacidade conforme a demanda muda. Seu servidor físico serve só você, ocupado ou parado.
• Elasticidade rápida: a capacidade cresce e encolhe conforme o uso. O hardware comprado tem o tamanho que tinha no dia da compra.
• Serviço mensurado: cada hora de máquina e cada gigabyte gravado entram na fatura, item a item. No servidor próprio ninguém mede nada, porque já está pago.

Isso muda a natureza do gasto. O servidor próprio é investimento: você paga tudo antes e usa depois, inclusive a parte que fica ociosa. A nuvem é despesa corrente. Paga depois, e só o que consumiu.

A ideia de compartilhar recursos computacionais à distância vem da computação em grade dos anos 1990 e 2000, mas a versão comercial que conhecemos tem data e dono. A Amazon, operando o próprio e-commerce, sentiu na pele o custo de provisionar e gerenciar infraestrutura, e transformou isso em produto: o Amazon S3 (armazenamento) e, na sequência, o EC2 (máquinas virtuais sob demanda), ambos lançados na primavera boreal de 2006. Foram os precursores do que hoje se chama infraestrutura como serviço. Cinco anos depois, em 2011, o NIST publicou a definição formal e consolidou o vocabulário que todo provedor repete até hoje.

Como funciona a computação em nuvem por trás de um clique

Por trás de um clique na nuvem existe um data center físico, uma camada de virtualização que divide cada servidor em máquinas menores e um software de orquestração que decide em qual delas seu pedido vai rodar. Você vê um botão de “criar instância”. O provedor vê milhares de servidores idênticos, energia, refrigeração e fibra.

O caminho entre o clique e a máquina pronta tem cinco etapas:

1. Você pede um recurso pelo painel ou pela API, com tamanho de memória, CPU e disco definidos.
2. O orquestrador do provedor escolhe um servidor físico com espaço livre em algum data center da região que você marcou.
3. O hipervisor desse servidor recorta uma máquina virtual do tamanho pedido, isolada das outras que rodam no mesmo hardware.
4. A rede virtual liga essa máquina ao seu ambiente, e em minutos você recebe um endereço para acessar.
5. O medidor começa a contar. Quando você desliga, o espaço volta para o pool compartilhado e a cobrança para.

A etapa 3 é o coração do negócio. Seu vizinho de hardware pode ser um banco, um jogo ou uma prefeitura, e nenhum deles enxerga o outro. Esse isolamento por software é o que permite ao provedor encher cada servidor físico até perto do limite em vez de deixar metade parada, como acontece em quase todo rack corporativo.

A elasticidade automática funciona sobre a mesma base: você define regras (se o uso de CPU passar de tanto, crie mais uma máquina; se cair, destrua uma) e o orquestrador executa sozinho. O que ninguém descobre até tentar é que a aplicação precisa ter sido escrita para isso. Um sistema que guarda a sessão do usuário na memória de uma máquina específica não ganha nada com cinco cópias, porque o usuário cai numa cópia que não sabe quem ele é. Ajustar isso antes de ligar o autoscaling é o tipo de trabalho que uma consultoria DevOps faz antes de qualquer migração.

A escala física por trás disso tem número. Os data centers brasileiros demandaram 843 MW de energia em 2024, segundo o mapeamento de infraestrutura digital do Cetic.br. No mundo, os data centers consumiram 415 TWh em 2024, cerca de 1,5% de toda a eletricidade do planeta, com Estados Unidos (45%), China (25%) e Europa (15%) concentrando a maior parte, de acordo com a Agência Internacional de Energia (IEA).

O último degrau dessa abstração é o serverless (computação sem servidor). Você não pede máquina nenhuma: envia só o código de uma função, o provedor executa quando um evento dispara e cobra pelo tempo de execução, em frações de segundo. Servidor, sistema operacional e escala somem da sua vista. O preço dessa conveniência é menos controle sobre o ambiente, e a primeira chamada depois de um período parado costuma esperar o provedor preparar o ambiente antes de responder.

Para que serve a computação em nuvem no dia a dia das empresas?

No dia a dia das empresas brasileiras, a computação em nuvem serve principalmente para rodar e-mail, software de finanças e contabilidade, ferramentas de segurança e pacotes de escritório sem manter servidor para isso. Desenvolver software dentro da nuvem é a fatia menor. A TIC Empresas 2025, do Cetic.br, mostra o que as empresas que contratam nuvem de fato pagam:

• Software de finanças ou contabilidade: 50%
• E-mail em nuvem: 47%
• Software de segurança: 44%
• Software de escritório: 32%
• Plataformas de desenvolvimento, teste e implantação de aplicações: 22%

Repare na ordem. O uso mais comum é o sistema financeiro, e o menos comum é justamente o que aparece em toda palestra sobre nuvem: plataforma para o time de engenharia. Para a maioria das empresas do país, nuvem é o lugar onde mora o ERP contábil e a caixa de e-mail, e não um ambiente de deploy.

A adoção cresce, mas devagar. A proporção de empresas brasileiras que pagam por capacidade de processamento em nuvem foi de 21% em 2017 para 23% em 2019, 29% em 2021, 33% em 2023, 33% em 2024 e 36% em 2025. O que me chamou atenção nessa série foi o degrau parado entre 2023 e 2024: dois anos no mesmo 33% antes de voltar a subir. Ninguém tem uma explicação fechada para isso, e a pesquisa não a oferece.

O contraste internacional deixa o número brasileiro mais honesto. Na União Europeia, 52,7% das empresas pagavam por serviços de nuvem em 2025, segundo a Eurostat, com Finlândia (79,2%), Itália (75,6%) e Malta (74,9%) na frente e Bulgária (17,8%) no fim da fila. O Brasil, com 36%, fica abaixo da média europeia e acima dos últimos colocados do bloco. Mais ou menos onde estava a UE uma década antes.

No setor público federal o uso é organizado por política própria. Desde 2018, o Governo Federal promove contratações conjuntas de nuvem entre órgãos, em vez de cada ministério negociar sozinho. A tipologia é a mesma do mercado, com nuvem privada de uso exclusivo do órgão e nuvem pública aberta a qualquer organização, e a diferença está nas exigências de segurança que cada uma carrega. Se você presta serviço para a administração pública, esse é o vocabulário que vai encontrar no edital.

Qual a diferença entre IaaS, PaaS e SaaS

A diferença entre IaaS, PaaS e SaaS está em quanto da pilha você administra: no IaaS o provedor entrega máquina, disco e rede e o resto é seu; no PaaS ele entrega também o sistema operacional e o ambiente de execução; no SaaS ele entrega o software pronto e você só usa. Os três modelos vêm da definição do NIST de 2011, e todo catálogo de provedor se organiza em torno deles.

Modelo	O que o provedor cuida	O que fica com você	Exemplo típico	Quem contrata
IaaS	Data center, servidor físico, rede, virtualização	Sistema operacional, runtime, aplicação, dados	Máquina virtual em que você instala Linux e o banco	Time de infraestrutura que quer controle total
PaaS	Tudo do IaaS mais sistema operacional, runtime e ferramentas de deploy	Código da aplicação e dados	Plataforma que recebe seu código e publica	Time de desenvolvimento sem equipe de operações
SaaS	Tudo, inclusive a aplicação	Configurações de uso e os dados que você insere	E-mail corporativo, CRM, ERP contábil	Área de negócio, muitas vezes sem TI no meio

O IaaS é a nuvem mais parecida com o servidor próprio. A Microsoft descreve o modelo como aquele em que o provedor entrega só a infraestrutura de TI e deixa sistema operacional e aplicações a cargo do cliente. Você ganha elasticidade e perde a obrigação de comprar hardware, mas continua responsável por atualizar o sistema, configurar o firewall e fazer backup. Quem migra do rack para o IaaS sem mudar a rotina de operação troca um problema de compra por um problema de administração idêntico ao anterior.

No PaaS a plataforma já vem pronta para desenvolver, testar e hospedar, sem que você gerencie a infraestrutura por baixo, como o Google Cloud a define. Você envia código, a plataforma cuida do resto. O atrito aparece quando a aplicação precisa de uma biblioteca de sistema ou de uma versão de runtime que a plataforma não oferece, e aí o time descobre que a conveniência tem borda.

O SaaS é o que a maioria das empresas brasileiras chama de nuvem sem saber que está usando a sigla: e-mail, CRM, sistema contábil. Nada para instalar, nada para atualizar. Sua responsabilidade se resume a configurar permissões e cuidar dos dados que você coloca lá dentro.

Há um quarto modelo que a indústria acrescentou depois do NIST. No serverless, você entrega funções em vez de aplicações inteiras e paga pelo tempo de execução de cada chamada. O mercado desse modelo cresceu de cerca de US$ 3 bilhões em 2017 para uma projeção próxima de US$ 22 bilhões em 2025, segundo uma revisão sistemática de 275 artigos científicos. Leia esse número como estimativa de mercado citada na literatura acadêmica, e não como dado de órgão estatístico.

Na minha leitura, a pergunta que decide o modelo é qual time você tem. Quem tem gente de infraestrutura escolhe IaaS e aproveita o controle. Quem tem só desenvolvedores vai melhor no PaaS ou no serverless. Quem não tem nenhum dos dois deveria comprar SaaS e parar de pensar no assunto. Uma consequência direta: quanto mais baixo na tabela, menos coisa você pode configurar errado.

Nuvem pública, privada e híbrida: quando cada modelo faz sentido

Nuvem pública faz sentido quando você quer pagar só pelo uso e aceita dividir infraestrutura com outros clientes; nuvem privada, quando controle e conformidade pesam mais que o preço; nuvem híbrida, quando parte das cargas precisa ficar sob seu domínio e o restante pode ir para o provedor. O NIST lista quatro modelos de implantação, e o quarto quase ninguém menciona.

• Nuvem pública: infraestrutura operada por um provedor e aberta a qualquer organização. É o que AWS, Azure e Google Cloud vendem.
• Nuvem privada: infraestrutura dedicada a uma única organização, no data center dela ou de terceiro, mas sem compartilhar com outros clientes.
• Nuvem comunitária: compartilhada por organizações com interesses comuns, como órgãos de um mesmo setor com a mesma exigência regulatória.
• Nuvem híbrida: duas ou mais dessas infraestruturas ligadas por tecnologia que permite mover dados e aplicações entre elas.

O governo brasileiro adota a mesma tipologia. A política de computação em nuvem do Governo Federal define a nuvem pública como “uma infraestrutura de nuvem dedicada para uso aberto de qualquer organização” e a privada como infraestrutura de uso exclusivo do órgão e de suas unidades vinculadas, cuja propriedade pode ser do próprio órgão ou de empresas públicas.

A escolha se resolve com três perguntas. Quem precisa ter as chaves do hardware? Se a resposta é “nós, por exigência de contrato ou de norma”, a nuvem privada entra na conta, com todo o custo de operar o próprio ambiente. Qual carga não pode sair de casa? Se for uma parte pequena do total, a híbrida resolve: o sistema legado fica no data center próprio e o site, o e-mail e o ambiente de testes vão para a pública. Quanto você quer gastar com gente de infraestrutura? A pública é a única em que essa resposta pode ser “quase nada”.

A parte estranha é que a híbrida, no papel, é o melhor dos dois mundos, e na prática costuma ser dois ambientes que não conversam. A definição do NIST exige portabilidade entre as infraestruturas. Muita empresa tem um data center e uma conta de nuvem pública, chama isso de híbrida e nunca moveu uma aplicação de um lado para o outro. Sem essa ponte funcionando, você paga duas operações e ganha a flexibilidade de nenhuma.

Quanto custa usar a nuvem e como o modelo pay-as-you-go pode sair caro

Usar a nuvem custa o que você consome, medido hora a hora e gigabyte a gigabyte, e é exatamente essa cobrança por uso que sai cara quando ninguém desliga o que parou de servir. Não existe preço único. Cada provedor tem catálogo próprio, os valores variam por região e mudam com frequência, então qualquer número impresso aqui envelheceria antes de você terminar de ler o artigo.

O modelo pay-per-use está entre os três pilares que a literatura acadêmica brasileira associa à nuvem, ao lado da virtualização e da escalabilidade, e nasce direto da característica de serviço mensurado do NIST. A fatura típica soma três famílias de cobrança:

• Computação: tempo de máquina virtual ligada ou tempo de execução de função, no serverless
• Armazenamento: volume gravado e, em muitos serviços, o número de operações de leitura e escrita
• Tráfego de saída: dados que deixam a rede do provedor rumo à internet ou a outro provedor

O primeiro item é o mais visível. O terceiro é o que surpreende. Colocar dados para dentro costuma ser barato ou gratuito, tirar custa, e essa assimetria é o que torna a saída de um provedor mais cara do que a entrada.

O mesmo medidor que deixa você pagar pouco no primeiro mês deixa a conta crescer sem limite depois. Quatro mecanismos fazem isso acontecer:

1. Recurso ocioso: a máquina de homologação criada para uma demo de sexta-feira segue ligada em dezembro, cobrando toda hora como se fosse produção.
2. Falta de dono: qualquer pessoa com acesso ao painel cria recurso, ninguém etiqueta o que criou, e no fechamento do mês não há como dizer qual projeto gerou qual linha da fatura.
3. Tráfego de saída sem plano: um backup diário que copia tudo para fora do provedor, ou uma integração que devolve arquivos grandes a um sistema externo, transforma egresso em custo fixo.
4. Escala sem teto: as regras de elasticidade sobem máquinas conforme a demanda, e um pico de tráfego (legítimo ou um bot) escala a conta junto, porque ninguém definiu limite máximo nem alerta.

Nenhum desses erros é do provedor. O servidor próprio esconde o desperdício dentro de um investimento já pago; a nuvem o expõe em cada item da fatura. Isso é uma vantagem, desde que alguém leia a fatura.

O que quase todo artigo sobre custo de nuvem erra é tratar o problema como técnico. A conta só fecha quando existe um responsável nomeado por custo, com poder para desligar coisa alheia, e um teto de gasto definido antes do primeiro deploy. Sem isso, o modelo por uso funciona como um táxi com o taxímetro ligado enquanto o passageiro foi almoçar.

Segurança na nuvem: o que fica com o provedor e o que fica com você

Na nuvem, o provedor responde pela segurança do data center, da rede física e dos servidores, e você responde por tudo o que configura em cima disso: sistema operacional, aplicação, permissões e dados. Esse é o modelo de responsabilidade compartilhada, e a linha divisória se move conforme o tipo de serviço contratado. Quanto mais pronto o serviço, menos sobra para o seu lado.

Camada	IaaS	PaaS	SaaS
Data center físico, energia e hardware	Provedor	Provedor	Provedor
Rede e virtualização	Provedor	Provedor	Provedor
Sistema operacional e runtime	Você	Provedor	Provedor
Aplicação	Você	Você	Provedor
Identidades, permissões e configurações de uso	Você	Você	Você
Dados	Você	Você	Você

Repare nas duas últimas linhas. Nenhum modelo tira dados e permissões da sua mão. Um e-mail corporativo em SaaS deixa quase nada para administrar, mas quem define que a pasta da diretoria está aberta para a empresa inteira é o seu administrador, e o provedor vai fazer exatamente o que ele mandou.

É aí que os incidentes acontecem. A arquitetura de referência de segurança em nuvem da CISA, publicada em 2023, aponta a má configuração feita pelo cliente como principal causa de incidentes em ambientes de nuvem das agências federais americanas. A infraestrutura do provedor raramente é a porta de entrada. Um bucket de armazenamento marcado como público por engano expõe mais do que qualquer falha de hipervisor, e ninguém do provedor vai avisar, porque para ele a configuração está correta: foi o que você pediu.

No Brasil, a camada que fica com você inclui a Lei 13.709/2018 (LGPD). Guardar dado pessoal de brasileiro em data center fora do país é transferência internacional de dados, e isso tem regra própria desde 2024:

• Resolução CD/ANPD nº 19/2024: a Agência Nacional de Proteção de Dados (ANPD) regulamentou a transferência internacional com quatro mecanismos: decisão de adequação (até 4 de setembro de 2026, concedida apenas à União Europeia), cláusulas contratuais padrão, cláusulas contratuais específicas e normas corporativas globais para transferências dentro do mesmo grupo
• Cláusulas do Anexo II: o provedor de nuvem precisa adotar as cláusulas-padrão sem alteração, dentro do prazo regulamentar, para que o contrato siga em conformidade com a LGPD mesmo com data center no exterior
• Instrução Normativa nº 5, de 30 de agosto de 2021: requisitos mínimos de segurança da informação para nuvem na administração pública federal
• Norma do GSI/PR de 2025: regra específica para tratar informação classificada em nuvem, publicada pelo Gabinete de Segurança Institucional da Presidência

Se você vende para o governo federal, as duas últimas viram cláusula de edital. Se você guarda CPF de cliente num serviço com servidor nos Estados Unidos, a primeira é a sua. Peça ao provedor a versão assinada das cláusulas antes de migrar, porque depois o custo de descobrir que ele alterou o texto é seu.

Quando a computação em nuvem falha ou não compensa

A computação em nuvem falha quando a conexão cai ou a latência pesa, e deixa de compensar quando a carga é estável e previsível, quando sair do fornecedor ficou caro demais ou quando a norma exige que o dado fique num lugar específico. São situações diferentes, com mecanismos diferentes.

Sem link, sem nuvem. Tudo o que roda no provedor depende do caminho até ele. Uma fábrica no interior com um único link de operadora perde o ERP inteiro quando o link cai, e o servidor na sala ao lado continuaria respondendo. Redundância de conexão resolve, mas entra na conta antes de qualquer migração.

Latência tem física. O data center mais próximo pode estar a centenas de quilômetros, e cada ida e volta custa milissegundos que uma aplicação de controle industrial ou de atendimento em tempo real não tem para gastar. A resposta do mercado é a computação de borda (edge): processar perto do usuário, em dispositivos ou servidores locais, e deixar para a nuvem central o armazenamento e o processamento pesado. Não substitui a nuvem. Divide o trabalho com ela.

Lock-in é lento e silencioso. Serviços gerenciados são convenientes justamente porque têm API própria, e cada um que você adota é um pedaço do sistema que só funciona naquele provedor. Sair significa reescrever esses pedaços. Ninguém decide se prender a um fornecedor; a empresa acorda presa depois de três anos de decisões pequenas.

Carga estável paga elasticidade que não usa. O prêmio da nuvem é a capacidade de crescer e encolher. Um sistema que roda no mesmo tamanho, 24 horas por dia, ano após ano, paga por essa flexibilidade sem nunca exercê-la, e é nesse perfil que o servidor próprio volta a competir. Não há número público consolidado para o ponto de equilíbrio, e ele varia com o preço da energia, o custo da equipe e o tempo de vida do hardware. A conta precisa ser feita caso a caso, com a fatura real na mão.

Soberania de dados é critério eliminatório. Quando contrato, norma setorial ou classificação de sigilo exige que o dado permaneça em território nacional ou sob controle exclusivo do órgão, a nuvem pública só entra se o provedor tiver região e controles que atendam a isso. Se não tiver, a discussão acaba antes de começar.

AWS, Azure e Google Cloud: como escolher o provedor certo

Escolher entre AWS, Azure e Google Cloud se resolve com cinco critérios objetivos: região no Brasil, integração com o que sua empresa já usa, serviços gerenciados de que você precisa, modelo de suporte e conformidade com a LGPD. Os três vendem IaaS, PaaS e serverless. A diferença quase nunca está no catálogo básico.

1. Região no Brasil: confirme se o serviço que você vai usar (e não só a máquina virtual genérica) está disponível numa região dentro do país. Isso decide latência para o usuário brasileiro e simplifica a conversa sobre transferência internacional de dados.
2. Integração com o que já existe: uma empresa que vive de planilha, diretório de usuários e pacote de escritório de um fornecedor tende a ter menos atrito na nuvem desse mesmo fornecedor. Quem já opera contêineres e ferramentas abertas tem mais liberdade de escolha.
3. Serviços gerenciados: liste o que você precisa que o provedor opere por você (banco, fila, autenticação, processamento de dados) e compare item a item. É nessa lista que mora o lock-in futuro, então cada item merece a pergunta “como eu saio disso?”.
4. Suporte: o plano gratuito costuma responder em fórum. Descubra quanto custa ter alguém do provedor ao telefone às 2h de um sábado, e se esse alguém fala português.
5. LGPD no contrato: peça as cláusulas-padrão de transferência internacional já adotadas e a localização exata dos dados em repouso e em backup. Provedor que não responde a isso por escrito não passa do critério.

Um sexto critério aparece em toda apresentação comercial e vale pouco. Os anúncios de investimentos bilionários dos três em data centers no Brasil para 2026 a 2030 circulam na imprensa especializada. Até constarem de balanço auditado ou ato regulatório, trate-os como plano de expansão e decida pela região que existe hoje.

Na prática, a escolha errada mais comum é a por preço de tabela. Os três publicam calculadoras, e as três dão resultado diferente para a mesma carga porque cobram por itens diferentes. Comparar exige modelar o seu uso real, com tráfego de saída e armazenamento incluídos, e esse inventário é o primeiro passo de qualquer consultoria de IA ou de infraestrutura séria. Sem ele, você compra a nuvem do vendedor mais simpático.

O que mudou na computação em nuvem com a explosão da IA generativa

A inteligência artificial (IA) generativa mudou a computação em nuvem em duas direções ao mesmo tempo: concentrou nos data centers centrais uma carga de treinamento que consome eletricidade numa escala nova, e empurrou parte da inferência para servidores e dispositivos perto do usuário. A nuvem que hospedava e-mail e ERP passou a hospedar modelos, e essa carga consome energia em outra ordem de grandeza.

Os números da eletricidade contam a história. O consumo dos data centers cresceu cerca de 12% ao ano desde 2017, mais de quatro vezes o ritmo do consumo total de eletricidade, e saltou 17% só em 2025, puxado pelos data centers voltados a IA, segundo a Agência Internacional de Energia (IEA). O relatório Energy and AI da mesma agência projeta que esse consumo dobre até 2030 e chegue a cerca de 945 TWh, quase 3% da eletricidade mundial projetada para aquele ano. A base de comparação, em 2024, era de 415 TWh e 1,5%.

Por que o treinamento fica no centro e a inferência sai dele? Treinar um modelo é trabalho em lote: milhares de processadores ocupados por semanas, sem ninguém esperando resposta do outro lado. Isso cabe onde existe energia, refrigeração e hardware em quantidade, ou seja, no data center central. A inferência é o inverso. Cada pergunta a um modelo é uma chamada com um usuário esperando, muitas vezes com um dado que não deveria viajar mil quilômetros para ser processado.

Daí nasce o que a pesquisa chama de continuum edge-cloud. A revisão de 2026 da Frontiers in the Internet of Things sobre gerenciamento de recursos orientado por IA nesse continuum aponta a orquestração de computação, armazenamento, comunicação e energia entre nós heterogêneos e geograficamente distribuídos como o principal desafio de pesquisa do ano. Em termos práticos: parte da inferência roda perto do usuário, por latência e por privacidade, enquanto o treinamento e o armazenamento em larga escala seguem na nuvem central. Uma coisa complementa a outra.

Quem coloca um agente de IA em produção sente isso na arquitetura antes de sentir na fatura. O modelo pode morar num data center distante, mas o índice de documentos que ele consulta e o histórico da conversa tendem a ficar perto do usuário, porque cada ida e volta custa tempo de resposta e porque a LGPD pergunta onde o dado esteve. O que a IA não alterou foi a lógica de cobrança: continua por uso. Só que agora a unidade que pesa é o tempo de processamento de cada chamada, e cem usuários simultâneos são cem chamadas ocupando hardware especializado no mesmo instante.

Perguntas frequentes sobre computação em nuvem

O que é cloud computing em palavras simples?

Cloud computing (computação em nuvem) é alugar computador de alguém pela internet em vez de comprar o seu. Você usa processamento, disco e programas que rodam num data center do provedor, paga pelo que consumiu no mês e devolve o que não precisa mais. O NIST, instituto de padronização dos Estados Unidos, formalizou essa definição em 2011, e ela vale até hoje.

Qual a diferença entre nuvem e internet?

A internet é a rede que conecta os computadores. A nuvem é o serviço de computação que você acessa por essa rede: o data center, a máquina virtual, o software rodando do outro lado do cabo. Sem internet não há como chegar à nuvem, mas a internet existiu por décadas sem que ninguém alugasse servidor por ela.

Armazenamento em nuvem é seguro?

O armazenamento em nuvem é seguro na camada do provedor e vulnerável na camada do cliente. A CISA, agência de segurança cibernética dos Estados Unidos, apontou em 2023 a má configuração feita pelo próprio cliente como principal causa de incidentes em nuvem nas agências federais americanas. Um bucket marcado como público por engano é o cenário típico. Permissões, criptografia e revisão de quem acessa o quê ficam com você em qualquer modelo de serviço.

Onde ficam os dados da nuvem?

Os dados ficam em data centers físicos do provedor, na região que você escolheu ao criar o serviço, dentro ou fora do Brasil. Dado pessoal de brasileiro guardado no exterior é transferência internacional, regulada pela Resolução CD/ANPD nº 19/2024. Peça ao provedor, por escrito, a localização dos dados em repouso e do backup, porque os dois podem estar em países diferentes.

Qual a diferença entre computação em nuvem e data center próprio?

No data center próprio você compra, instala e opera o hardware, e paga tudo antes de usar. Na nuvem o provedor opera o hardware e você paga por hora e por gigabyte, só o que consumiu. A nuvem ganha quando a carga oscila. O data center próprio volta a competir quando a carga é estável e previsível, ou quando a norma exige que o dado permaneça sob seu controle direto.

O que é cloud machine?

Cloud machine é o nome informal da máquina virtual na nuvem: uma fatia de um servidor físico, com CPU, memória e disco definidos por você, criada em minutos e cobrada por hora enquanto estiver ligada. Nos catálogos dos provedores ela aparece como instância ou VM. É o produto básico do modelo IaaS e existe desde o lançamento do Amazon EC2, em 2006.

Pequena empresa precisa de nuvem?

Quase sempre precisa, e provavelmente já usa sem chamar assim: e-mail corporativo, sistema contábil e ferramentas de escritório contratados como serviço são nuvem no modelo SaaS. Entre as empresas brasileiras que pagam por nuvem em 2025, 50% pagam por software de finanças ou contabilidade e 47% por e-mail, segundo a TIC Empresas do Cetic.br. Máquina virtual e plataforma de desenvolvimento só fazem sentido quando existe alguém na empresa para operá-las.

Quem inventou a computação em nuvem?

Ninguém inventou a computação em nuvem sozinho. A ideia de compartilhar recursos computacionais à distância vem da computação em grade dos anos 1990 e 2000. A versão comercial nasceu na Amazon Web Services com o lançamento do S3 e do EC2 em 2006, e o NIST publicou em 2011 a definição que a indústria inteira adota.

Por onde começar a migrar para a nuvem

Comece a migrar para a computação em nuvem pelo inventário: liste cada sistema que roda hoje, quem usa, quanto a carga oscila e que dado ele guarda. Sem essa lista você compra capacidade no escuro.

Depois, quatro passos, nessa ordem:

1. Escolha uma primeira carga de baixo risco, como e-mail ou backup, que já existe pronta em SaaS e não derruba a operação se algo der errado.
2. Nomeie um responsável por custo, com poder de desligar recurso alheio, e outro por segurança, dono das permissões.
3. Confira a LGPD antes de subir qualquer dado pessoal: onde os dados vão ficar e se o provedor adotou as cláusulas-padrão da ANPD sem alteração.
4. Defina um teto de gasto e um alerta antes do primeiro deploy.

A migração está dando certo quando a fatura do mês bate com o inventário, ninguém abriu chamado para criar máquina e o backup restaurou num teste real. Se quiser esse roteiro aplicado ao seu ambiente, fale com o time da AlphaCorp AI: as pessoas que atendem são as mesmas que constroem.