O Risco que se Calcula sem Ver.
Motorista cifra padrão de direção. Seguradora calcula desconto. Sem ninguém saber onde nem quando ele dirigiu.
Cenário
App de telematics coleta velocidade, frenagem, distância, horário. Hoje envia tudo em claro à seguradora. UBI invasivo.
Problema
Adoção de UBI é limitada por resistência de privacidade. Quem aceita já é o segmento errado para a seguradora.
Garantia
Sob FHE: features cifradas no app. Seguradora calcula score sob cifra. Devolve fator de desconto. Sem profile persistente.
Definir os parâmetros.
Antes de cifrar o padrão de direção, escolhemos os parâmetros CKKS. CKKS é o esquema natural para scoring atuarial sobre vetores de features.
Capacidade · CKKS
O que cada termo significa
CKKS (esquema "aproximado") — Família FHE para números reais. Ruído de aproximação controlado (~10⁻¹⁰). Padrão para scoring atuarial e modelos de risco — exatamente o que UBI precisa.
8 192 slots — Cada ciphertext é um vetor de 8 192 valores. As 8 features de telematics ocupam 8 slots; o restante fica zero. Um único ciphertext carrega todo o padrão semanal de direção.
Profundidade multiplicativa 3 — Quantas multiplicações encadeadas suportadas. Scoring linear (Mul + InnerSum + Add bias) consome poucos níveis.
~128 bits de segurança — Padrão da indústria. Quebrar a chave exigiria ~2128 operações.
Base RLWE — Mesmo problema matemático do ML-KEM/ML-DSA padronizados pelo NIST como criptografia pós-quântica.
Chaves geradas no celular.
A chave secreta nasce dentro do app de telematics no celular do motorista. Nunca sai. A seguradora só recebe a chave pública — pode cifrar comandos para o motorista, mas nunca decifrar nada vindo dele sem o consentimento explícito.
Chaves geradas
Por que isso importa para UBI
Motorista controla o dado — A diferença vs UBI tradicional é fundamental: hoje, ao instalar o app, o motorista entrega controle perpétuo sobre seus dados de movimentação. Sob FHE, ele mantém a chave — pode revogar o serviço a qualquer momento e a seguradora literalmente não consegue mais ler nada que ele já enviou.
Reduz consent fatigue — Como o dado nunca está em claro no servidor da seguradora, a tela de "aceito compartilhar X, Y, Z" pode ser drasticamente simplificada. O usuário aceita "calcular meu desconto" sem precisar enumerar quais campos serão usados.
Extração local antes da cifragem.
As 8 features abaixo são o resultado de um pipeline de processamento que rodou localmente no celular, em claro, sobre os dados brutos de GPS + acelerômetro da semana.
Padrão semanal agregado
O que existe por trás de cada número
Dados brutos (ficam no celular) — Em uma semana típica, o app captura ~10-50 mil pontos GPS + ~500 mil amostras do acelerômetro (100 Hz). Esses dados são altamente identificáveis (revelam rotas, endereços, horários exatos) e NUNCA saem do celular.
Feature extraction local — Um pipeline roda no próprio dispositivo: calcula velocidade via GPS delta, detecta eventos de frenagem via spikes do acelerômetro (< -2 m/s²), categoriza horário, classifica contexto urbano vs rodovia via densidade de POIs. Tudo em claro, localmente.
Só o agregado é cifrado — As 8 features agregadas são suficientes para scoring atuarial — é o padrão usado por Progressive Snapshot e Root Insurance há uma década. Os dados brutos permanecem privados por construção.
O que a seguradora recebe.
A seguradora recebe ~1 MB de bytes pseudoaleatórios. Sem a chave secreta (que ficou no celular), esses bytes são indistinguíveis de ruído puro. Mesmo sob ordem judicial, a seguradora não tem o que entregar.
Amostra dos bytes
74 65 78 74 4d 65 74 61
44 61 74 61 22 3a 7b 22
53 63 61 6c 65 22 3a 7b
...
Por que isso muda o jogo
Sem profile persistente — A seguradora hoje armazena meses de histórico de movimentação em servidor próprio. Sob FHE, ela armazena ciphertext — sem chave nem capacidade de processar fora do contexto da query autorizada.
Resistente a breach — Se a seguradora for invadida (e seguradoras grandes são alvo constante), o invasor leva apenas ciphertext. Não consegue inferir onde nenhum motorista dirigiu.
CLOUD Act compatível — Seguradoras globais podem hospedar em cloud americana sem violar LGPD brasileira. O dado nunca esteve em claro fora do celular do motorista.
Modelo atuarial sob cifra.
A seguradora aplica seu modelo atuarial linear (pesos públicos para cada feature) sobre o vetor cifrado de comportamento. O resultado é um score de risco — ainda cifrado.
O algoritmo
pesos := [+0.4, +1.5, +0.3,
-0.2, +1.2, +0.8,
+0.1, +0.6]
bias := -0.5
// score = bias + Σ(peso·feature)
ctMul := evaluator.Mul(ctF, pesos)
evaluator.Rescale(ctMul)
ctScore := evaluator.InnerSum(ctMul)
evaluator.Add(ctScore, bias)
O que cada peso significa
Pesos positivos (aumentam risco) — frenagem brusca (+1.5), aceleração brusca (+1.2), direção noturna (+0.8), clima ruim (+0.6).
Pesos negativos (reduzem risco) — horário comercial (-0.2). Padrão de motorista que dirige só em horário de trabalho.
Os pesos são públicos — A seguradora publica os pesos do modelo para que motoristas possam entender e auditar como o desconto é calculado. Isso é importante porque AI Act europeu exige explicabilidade em decisões automatizadas que afetam o consumidor.
Cálculo cifrado — Os pesos são públicos, mas o vetor de features é cifrado. A multiplicação plaintext × ciphertext continua ciphertext. Resultado: score cifrado.
Motorista decifra.
FHE vs plaintext.
Seguradora desonesta.
- 1 — Inferir features individuais do score1 número, 8 incógnitas. Sub-determinado.
- 2 — Queries repetidas (semanas)DP adicionada bloqueia. E queries repetidas exigem novo consentimento.
- 3 — Recuperar skRing-LWE em N=16384. Inviável.
UBI privado.
Fluxo
- App cifrou padrão de direção localmente
- Enviou ciphertext à seguradora
- Seguradora calculou score sob cifra (26 ms)
- Devolveu fator de desconto cifrado
- Motorista decifrou: 12.2% de desconto