Imagina entregar uma carta trancada a um contador e ele devolver o imposto de renda calculado, sem nunca abrir o envelope. Parece absurdo, mas é exatamente isso que a criptografia homomórfica faz com dados digitais. E o Google acaba de tornar essa mágica acessível para qualquer desenvolvedor.

O HEIR (Homomorphic Encryption Intermediate Representation) é um compilador open source que permite rodar modelos de IA sobre dados criptografados, sem descriptografar nada em nenhum momento do processo. O servidor recebe ciphertexts, processa tudo no escuro e devolve resultados criptografados que só o dono dos dados consegue ler.

Até pouco tempo, trabalhar com criptografia homomórfica exigia um PhD em criptografia e muita paciência. Agora, com o HEIR, você escreve um programa em Python, marca quais variáveis são secretas e o compilador cuida do resto. Eu testaria isso num fim de semana se tivesse um caso de uso real, e a verdade é que casos de uso reais estão aparecendo mais rápido do que a maioria dos devs percebe.

O que é criptografia homomórfica (e por que você deveria se importar)

Criptografia tradicional funciona assim: você criptografa os dados, manda pro servidor, o servidor descriptografa, processa e devolve. O problema? No momento em que o servidor descriptografa, ele vê tudo. Seus dados médicos, suas transações bancárias, suas consultas de busca. Tudo exposto.

A criptografia homomórfica (FHE, de Fully Homomorphic Encryption) resolve isso permitindo computação diretamente sobre dados criptografados. O servidor nunca vê os dados em texto claro. Ele opera sobre ciphertexts e produz resultados que, quando descriptografados pelo dono dos dados, são matematicamente idênticos aos que seriam obtidos operando sobre os dados originais.

Para quem é mais visual, pense numa tabela:

O conceito existe desde 1978, quando Ron Rivest (o R do RSA) propôs a ideia. Mas a primeira implementação prática só veio em 2009, com Craig Gentry. E era tão lenta que servia mais como curiosidade acadêmica do que como ferramenta real.

De curiosidade acadêmica a ferramenta real: 10.000x mais rápido em 5 anos

Aqui é onde a história fica interessante. Segundo benchmarks publicados pela Duality Technologies em 2026, a performance da criptografia homomórfica melhorou entre 1.000x e 10.000x nos últimos cinco anos, dependendo da operação.

Para colocar em perspectiva:

• Regressão logística criptografada sobre 10.000 registros: de horas para 2 a 10 segundos com CKKS otimizado e batching
• Analytics em batch sobre 1 milhão de registros: minutos em hardware com GPU
• Inferência em modelos rasos: abaixo de 1 segundo com aceleração GPU

O que mudou? Três coisas ao mesmo tempo:

Algoritmos melhores. O esquema CKKS (Cheon-Kim-Kim-Song) trouxe suporte nativo a números de ponto flutuante, que é o que modelos de ML usam o tempo todo. Antes, tudo tinha que ser convertido para inteiros, o que era um pesadelo de engenharia.

Compiladores inteligentes. Ferramentas como o HEIR automatizam a seleção de parâmetros e otimização de circuitos. Antes, um criptógrafo experiente passava semanas ajustando parâmetros manualmente. Agora o compilador faz isso.

Hardware dedicado. Intel HEXL entrega 2x a 5x de speedup usando instruções AVX-512. GPUs aceleram de 10x a 100x para operações em batch. E o programa DARPA DPRIVE está produzindo FPGAs e ASICs com reduções de ordem de grandeza na latência de bootstrapping.

Com tudo somado, o overhead que antes era de 10.000x sobre texto claro caiu para 10x a 100x em workloads otimizados com batching e GPU. Ainda não é grátis, mas já está no território do “vale a pena para certos casos de uso”.

HEIR na prática: Python, decorators e zero criptografia manual

O que o Google fez com o HEIR foi eliminar a barreira de entrada. A API é absurdamente simples para algo tão complexo por baixo dos panos.

O fluxo básico funciona assim:

from heir import compile, Secret

@compile()
def soma_privada(a: Secret[int], b: Secret[int]) -> int:
    return a + b

# Chamada normal - HEIR cuida de criptografar,
# processar e descriptografar
resultado = soma_privada(42, 58)
print(resultado)  # 100

Quando você decora uma função com @compile(), o HEIR:

1. Analisa o código e identifica os tipos marcados como Secret
2. Escolhe o esquema de criptografia mais adequado (BGV, CKKS ou CGGI)
3. Otimiza os circuitos aritméticos para minimizar profundidade
4. Compila para código de máquina via backend OpenFHE
5. Na execução, criptografa as entradas, roda o circuito e descriptografa o resultado

Tudo isso acontece sem que o desenvolvedor precise entender a diferença entre BGV e CKKS, o que é bootstrapping, ou como selecionar parâmetros de segurança. O compilador toma essas decisões.

O HEIR suporta mais de 25 dialetos internos para diferentes camadas de abstração:

• BGV: ideal para operações com inteiros
• CKKS: melhor para ponto flutuante (ML/IA)
• CGGI: otimizado para circuitos booleanos
• LWE: operações de baixo nível
• RNS: aritmética polinomial com resíduo
• HECO: otimizações SIMD automáticas

As 4 aplicações que o Google demonstrou

O Google não ficou só na teoria. Junto com o anúncio do HEIR, a equipe publicou quatro aplicações compiladas com o framework, todas com números de latência medidos em CPU single-threaded:

1. Modelo de recomendação

O caso clássico: você quer recomendar produtos sem ver o que o usuário pesquisou. A loja processa as preferências criptografadas e devolve recomendações que só o dispositivo do usuário consegue ler. Nenhum servidor intermediário vê o histórico de navegação.

2. Detector de hotword

Pense no “Ok Google” ou “Hey Siri”, mas rodando sobre áudio criptografado. O servidor identifica a palavra-chave sem nunca ouvir o que você disse. Parece ficção científica, mas é exatamente o tipo de operação onde FHE funciona bem: o modelo é raso e a entrada é pequena.

3. Detecção de fraude

Bancos e fintechs processam transações criptografadas para identificar padrões suspeitos. O modelo de fraude opera sobre os dados sem ver valores, destinatários ou histórico da conta. Apenas o resultado (“suspeito” ou “ok”) é descriptografado.

4. Classificação de imagens

Redes neurais convolucionais rodando sobre pixels criptografados. O overhead aqui é maior, mas para aplicações médicas (classificar radiografias sem expor dados do paciente), o trade-off faz sentido.

As limitações que ninguém quer admitir

Eu seria irresponsável se pintasse um quadro só de flores. A criptografia homomórfica em 2026 ainda tem problemas sérios, e a comunidade do Hacker News não perdoou na discussão sobre o HEIR.

O overhead ainda é brutal para uso geral. Um pesquisador que fez mestrado em Privacy Preserving ML apontou que o overhead de FHE para tarefas de inferência gira em torno de 10³ (mil vezes mais lento). Para modelos grandes, a conta não fecha. Uma estimativa para rodar GPT-2 small com FHE deu 0,00008 tokens por segundo. Isso equivale a 3,33 horas por token. Para gerar uma frase de 20 palavras, você esperaria quase 3 dias.

Branching é um pesadelo. Como dados criptografados não permitem comparações condicionais (o servidor não sabe se X > Y porque não vê X nem Y), qualquer if/else precisa avaliar ambos os branches. Algoritmos de ordenação, que são essencialmente uma cascata de comparações, ficam absurdamente lentos. Operações de ML como multiplicação de matrizes e soma (que são lineares) funcionam melhor.

Ciphertexts são enormes. Um único inteiro criptografado ocupa cerca de 25 KB. Chaves especiais de criptografia chegam a 0,5 GB ou até dezenas de GBs dependendo do esquema. Imagine transmitir uma imagem de 1 MB criptografada homomorficamente: o payload pode chegar a centenas de MBs.

Não serve para LLMs (ainda). Pesquisas de 2026 mostram latência de aproximadamente 1.000 segundos por bloco de transformer. Um modelo com 12 blocos levaria mais de 3 horas para processar um único token. Para chatbots e geração de texto, é inviável no estado atual.

Onde FHE já faz sentido hoje

Apesar das limitações, existem nichos onde o overhead de 10x a 1000x é aceitável, porque a alternativa é não processar os dados de nenhuma forma:

Healthcare. Hospitais querem usar IA para diagnóstico mas não podem enviar dados de pacientes para a nuvem sem violar HIPAA/LGPD. Com FHE, um modelo de classificação pode analisar exames criptografados e devolver diagnósticos sem que o provedor de nuvem veja uma única radiografia.

Finanças. Bancos precisam compartilhar dados para detecção de fraude entre instituições, mas regulações proíbem o compartilhamento direto. FHE permite que um modelo analise transações de múltiplos bancos sem que nenhum banco veja os dados dos outros.

Publicidade privacy-first. Com o fim dos cookies de terceiros e regulações como GDPR, anunciantes precisam segmentar audiências sem rastrear indivíduos. FHE permite computar segmentação sobre dados criptografados do usuário.

Votação eletrônica. Computar resultados de eleições sobre votos criptografados, onde ninguém (nem o sistema de apuração) vê votos individuais, apenas o resultado agregado.

Para esses cenários, transformar uma operação de 1ms em 1 segundo ainda é aceitável, porque a alternativa seria não fazer a operação ou expor dados sensíveis.

Como começar com o HEIR

Se você quer experimentar, o caminho mais direto é clonar o repositório do GitHub:

git clone https://github.com/google/heir.git
cd heir

# Build com Bazel
bazel build //...

# Rodar os testes
bazel test //...

Para quem quer algo mais simples para entender o conceito antes de mergulhar no HEIR, a biblioteca simplefhe no PyPI oferece uma API minimalista:

pip install simplefhe

from simplefhe import encrypt, decrypt, generate_keys

# Gerar par de chaves
public_key, secret_key = generate_keys()

# Criptografar dois números
a_enc = encrypt(42, public_key)
b_enc = encrypt(58, public_key)

# Somar sobre dados criptografados
resultado_enc = a_enc + b_enc

# Só o dono da chave secreta consegue ler
print(decrypt(resultado_enc, secret_key))  # 100

O ponto aqui não é que simplefhe seja production-ready. É que o conceito funciona: você opera sobre dados criptografados e o resultado é correto quando descriptografado.

O ecossistema ao redor do HEIR

O Google não está sozinho nessa corrida. O ecossistema de FHE em 2026 está surpreendentemente movimentado:

O HEIR se diferencia por ser um compilador, não uma biblioteca. Em vez de exigir que o desenvolvedor escolha esquemas, configure parâmetros e otimize circuitos manualmente, ele toma essas decisões automaticamente. É a diferença entre escrever assembly e escrever Python: o resultado final é similar, mas a experiência do desenvolvedor é outra.

O projeto DARPA DPRIVE merece menção especial. É um programa do governo americano que está financiando o desenvolvimento de hardware dedicado para FHE: FPGAs e ASICs projetados especificamente para acelerar operações sobre ciphertexts. Quando esses chips chegarem ao mercado, o overhead de FHE pode cair mais uma ou duas ordens de grandeza.

O que vem pela frente

A trajetória é clara. De 2009 a 2021, FHE saiu de “impossível na prática” para “possível mas impraticável”. De 2021 a 2026, foi de “impraticável” para “viável em nichos específicos”. Se a curva de melhoria de 1.000x a cada 5 anos se mantiver (e os investimentos em hardware sugerem que vai), por volta de 2030 podemos ver FHE competitivo para inferência de modelos médios em tempo quase real.

O HEIR do Google é uma aposta de que a barreira não é mais a criptografia em si, mas a acessibilidade. Se qualquer dev Python conseguir usar FHE sem entender a matemática por trás, a adoção explode. E quando a adoção explode, o incentivo para otimizar hardware e algoritmos se multiplica.

A pergunta não é mais “criptografia homomórfica funciona?”. Funciona. A pergunta agora é: “para o seu caso de uso específico, o overhead atual é aceitável?”. E a cada ano que passa, a resposta é “sim” para mais cenários.

Se você trabalha com dados sensíveis (e quem não trabalha?), vale manter o HEIR no radar. Não para usar amanhã em produção, mas para estar pronto quando o overhead cair o suficiente para o seu caso. E pelo ritmo que as coisas estão andando, isso pode ser mais cedo do que parece.

Fonte de inspiração: How Google is Making Private AI Practical with Homomorphic Encryption (Google Blog)