Nvidia e Azure impulsionam Confidential Computing para o mainstream

A computação confidencial passou uma década como uma curiosidade de conferências de criptografia — um recurso de hardware que arquitetos empresariais arquivavam como "interessante, mas não urgente". Isso mudou em 2026. Inferência de IA multitenante colocou dados sensíveis e pesos proprietários de modelos nos mesmos clusters compartilhados de GPU, e a criptografia padrão em repouso e em trânsito deixou de ser suficiente, porque no momento em que um modelo é executado, tanto os dados de entrada quanto os pesos ficam em texto claro na memória.

O mercado reflete a mudança: analistas estimam o mercado de computação confidencial em cerca de US$ 16,7 bilhões em 2026, contra aproximadamente US$ 12,3 bilhões em 2025, uma taxa de crescimento acima de 35% ao ano. Serviços financeiros respondem por quase metade da adoção empresarial, saúde por mais de um terço, e cerca de três quartos das agências federais dos EUA agora executam alguma forma de tecnologia de enclave seguro para workloads sensíveis. Isso não é mais uma caixa de conformidade de nicho — está se tornando table stakes para qualquer um que execute IA sobre dados que não pode expor legal ou contratualmente.

O Que Realmente Mudou

O gatilho não foi uma única violação ou regulamentação. Foi a chegada de workloads de IA que exigem duas coisas simultaneamente: os dados sensíveis do cliente (prontuários médicos, posições de trading, dados biométricos) e os pesos proprietários do modelo do fornecedor, colocalizados no mesmo hardware, pertencentes a nenhuma das partes sozinha. Um hospital enviando dados de pacientes para um modelo diagnóstico de terceiros precisa da garantia de que o provedor de nuvem e o fornecedor do modelo não podem ver os dados. O fornecedor do modelo precisa da garantia de que o hospital não pode extrair os pesos. Nenhum dos lados confia na infraestrutura do outro, e nenhum dos lados pode simplesmente "criptografar e descriptografar" para resolver, porque a computação em si tem que acontecer em dados não criptografados em algum ponto — a menos que esse ponto esteja dentro de hardware que nenhuma das partes controla.

Esse é o problema específico que os Trusted Execution Environments (TEEs) resolvem: regiões de memória isoladas e criptografadas por hardware onde código e dados são protegidos até mesmo de um hypervisor comprometido, operador de nuvem ou usuário root. Em 2026, essa raiz de confiança de hardware se estende além da CPU e entra na GPU pela primeira vez em escala.

O Hardware: CPUs e GPUs Agora Fazem Isso

Quatro arquiteturas de TEE dominam as implantações atuais:

• Intel TDX (Trust Domain Extensions) — isola VMs inteiras, usado intensamente em instâncias de VM confidenciais do Azure e Google Cloud.
• AMD SEV-SNP (Secure Encrypted Virtualization–Secure Nested Paging) — a opção mais amplamente implantada na AWS, Azure e Google Cloud, favorecida por menor overhead computacional graças à criptografia de memória acelerada por hardware AES-NI.
• ARM CCA (Confidential Compute Architecture) — mais novo, voltado para dispositivos móveis e edge onde a inferência confidencial precisa acontecer fora do datacenter completamente.
• Nvidia Hopper confidential computing — o H100 foi a primeira GPU com um TEE baseado em hardware ancorado em uma root of trust no die; o H200 estende isso. Essa é a peça que tornou a inferência de IA confidencial viável, porque protege dados e pesos do modelo enquanto a GPU está ativamente computando, não apenas enquanto estão na memória da CPU.

A história de desempenho aqui é melhor do que a maioria dos engenheiros assume. Em workloads de CPU com limite computacional, SEV-SNP e TDX ambos rodam com aproximadamente 1-5% de overhead. No modo de GPU confidencial da Nvidia, benchmarks independentes colocam a inferência típica de LLM em 95-99% do throughput nativo — para a maioria das queries, o overhead fica abaixo de 5%, e se aproxima de zero para modelos maiores e sequências mais longas, já que o custo de criptografia é amortizado por mais computação por byte movido através da fronteira CPU-GPU.

Quem Está Realmente Rodando Isso em Produção

Os três grandes hyperscalers já enviam infraestrutura de IA confidencial hoje, não como item de roadmap. O Azure Confidential Computing combina Intel TDX e AMD SEV com VMs de GPU confidenciais baseadas em H100s, comercializadas especificamente para implantação de LLM em indústrias reguladas. A AWS oferece Nitro Enclaves junto com famílias de instâncias EC2 com suporte a SEV-SNP. O Google Cloud, com Confidential Space e Confidential VMs, mira o mesmo caso de uso, posicionado para colaboração de dados entre múltiplas partes onde nenhuma parte pode ver as entradas das outras.

Implantações concretas confirmam isso. A NTT DATA e a IBM construíram o SimpliZCloud, uma plataforma de nuvem híbrida para instituições financeiras indianas que usa computação confidencial para proteger dados durante o processamento, não apenas no armazenamento. O Departamento de Defesa dos EUA autorizou infraestrutura de nuvem com computação confidencial para operações de missão crítica em vários departamentos federais. Isso não são pilotos — são sistemas financeiros e governamentais em produção onde "criptografamos o banco de dados" não satisfaz mais a barra de conformidade ou contratual.

O Problema Não Resolvido: Atestação

Aqui é onde a narrativa mainstream se adianta em relação à tecnologia. O modelo de confiança da computação confidencial depende de remote attestation — prova criptográfica de que um workload realmente está rodando dentro de um TEE genuíno e não modificado antes de você enviar dados sensíveis. Para um TEE só de CPU, um único fornecedor emite essa prova. Para inferência de IA confidencial, você agora precisa de atestação do fornecedor da CPU e do fornecedor da GPU simultaneamente, cada um com sua própria cadeia de suprimentos, root of trust separada e ferramentas de verificação distintas. Pesquisadores de segurança chamam isso de problema de "atestador composto", e ainda não há um padrão único para verificá-lo de ponta a ponta.

Piora: uma investigação do Register publicada em 4 de julho de 2026 detalhou como vários esquemas propostos de "atestação intra-handshake" — onde o TEE se prova durante o próprio handshake TLS — permanecem vulneráveis a relay attacks, onde um cliente verifica com sucesso um enclave genuíno e confiável, mas acaba enviando tráfego criptografado para um completamente diferente e malicioso. Nenhuma das sete abordagens criptográficas testadas até agora fecha essa lacuna completamente. Isso não é um bug de implementação menor; é uma fraqueza estrutural em como a confiança é estabelecida, e significa que "usamos computação confidencial" não é, por si só, uma alegação de segurança completa sem também perguntar como a atestação é verificada e por quem.

Quando Você Realmente Precisa Disso

A computação confidencial resolve um problema específico: proteger dados enquanto estão sendo computados, por uma parte em que você não confia totalmente com o hardware. Criptografia padrão em repouso e em trânsito continua sendo suficiente quando sua própria infraestrutura executa a computação e você controla o hypervisor. Você precisa de TEEs quando qualquer um destes se aplica:

• Você está executando inferência em uma GPU de nuvem de terceiros e precisa que o próprio provedor de nuvem seja excluído do seu modelo de ameaça — não apenas atacantes externos.
• Você está servindo um modelo proprietário para clientes que poderiam, de outra forma, extrair pesos da memória da GPU durante a inferência.
• Múltiplas partes (por exemplo, dois hospitais, ou um banco e um fornecedor de detecção de fraude) precisam computar conjuntamente sobre