Machine Learning com Preservação de Privacidade

Visão geral

Aprendizado de Máquina com Preservação de Privacidade (Privacy-Preserving Machine Learning, PPML) é uma família de técnicas que permite treinar e usar modelos de aprendizado de máquina (machine learning) enquanto reduz o vazamento de informações sensíveis sobre indivíduos, organizações ou conjuntos de dados proprietários. O PPML é motivado por restrições do mundo real — prontuários de saúde, transações financeiras, conteúdo gerado por usuários, rastros de localização e dados de dispositivos — em que centralizar dados brutos ou expor detalhes internos do modelo pode criar um risco de privacidade inaceitável.

PPML não é uma coisa só: ele abrange garantias formais de privacidade (notadamente Privacidade Diferencial (Differential Privacy)), paradigmas de treinamento distribuído (notadamente Aprendizado Federado (Federated Learning)) e proteções de sistemas/criptográficas (agregação segura (secure aggregation), computação segura multipartidária (secure multi-party computation), criptografia homomórfica (homomorphic encryption), hardware confiável (trusted hardware)). Cada abordagem oferece diferentes suposições de ameaça e trade-offs entre:

  • Garantias de privacidade (o que é protegido, contra quem e com que força)
  • Utilidade do modelo (acurácia, calibração, equidade, robustez)
  • Complexidade do sistema (computação/latência, comunicação, esforço de implementação)
  • Modelo de confiança (em quem se deve confiar: servidor, clientes, hardware, criptografia)

Este artigo explica os principais modelos de ameaça, canais de vazamento e técnicas práticas de PPML usadas hoje.

Como é o “vazamento de privacidade” em ML

Mesmo quando você nunca produz explicitamente exemplos de treinamento como saída, modelos e artefatos de treinamento podem vazar informações.

Objetivos comuns de vazamento para um atacante

  • Inferência de pertencimento (membership inference): determinar se um determinado registro estava no conjunto de treinamento.
    • Exemplo: O prontuário médico de Alice foi usado para treinar um classificador de doenças?
  • Inferência de atributos (attribute inference): inferir atributos sensíveis sobre um registro usando informações parciais.
    • Exemplo: Dadas features não sensíveis, inferir um atributo protegido como status de gravidez.
  • Inversão de modelo (model inversion) / reconstrução de dados (data reconstruction): reconstruir exemplos representativos de treinamento ou até entradas exatas sob algumas condições.
    • Exemplo: Reconstruir imagens ou sequências de texto a partir de um modelo ou a partir de gradientes.
  • Extração de dados de treinamento (training data extraction) (especialmente para grandes modelos generativos): recuperar sequências memorizadas literalmente.
    • Exemplo: Extrair um número de telefone ou endereço presente nos dados de ajuste fino (fine-tuning).
  • Vazamento de informação via gradientes/atualizações: em treinamento colaborativo, gradientes podem codificar dados brutos.
    • Exemplo: Em aprendizado distribuído, um servidor que recebe gradientes pode reconstruir entradas do cliente (ataques de vazamento por gradientes (gradient leakage attacks)).

O que pode vazar além dos pesos do modelo?

  • Gradientes (gradients) e estados do otimizador (optimizer states)
  • Ativações intermediárias (intermediate activations) (em aprendizado dividido (split learning) ou em alguns protocolos de MPC)
  • Predições/logits (logits) expostos por uma API de inferência
  • Embeddings (embeddings) ou representações armazenadas a jusante (índices de busca, bancos de dados vetoriais (vector DBs))
  • Metadados (metadata): quem participou, quando, com que frequência e em qual dispositivo

O PPML busca mitigar esses riscos sob suposições explícitas.

Modelos de ameaça: defina “privado contra quem?”

Um sistema de PPML precisa especificar as capacidades e o acesso do atacante. Dimensões comuns:

Posição do atacante

  • Atacante externo: só vê a API do modelo (caixa-preta (black-box)) ou o modelo publicado (caixa-branca (white-box)).
  • Servidor curioso (honesto-mas-curioso (honest-but-curious)):: segue o protocolo, mas tenta inferir dados do cliente.
  • Participante malicioso: um cliente ou servidor desvia do protocolo (por exemplo, envia atualizações elaboradas).
  • Insider: tem acesso a logs, checkpoints, telemetria ou pipelines de dados.

Acesso do atacante

  • Acesso de caixa-preta: consulta o modelo e observa as saídas.
  • Acesso de caixa-branca: baixa pesos e arquitetura; possivelmente o código de treinamento.
  • Acesso em tempo de treinamento: observa gradientes, atualizações por passo ou mensagens de clientes.
  • Informação auxiliar: o atacante conhece features parciais, demografia ou alguns registros.

Objetivos de privacidade e granularidade

  • Privacidade em nível de registro (record-level privacy): proteger qualquer registro de um único indivíduo.
  • Privacidade em nível de usuário (user-level privacy): proteger todos os dados contribuídos por um usuário ao longo do tempo (em geral, mais estrita).
  • Privacidade de grupo (group privacy): proteger grupos correlacionados (mais difícil; a DP degrada com o tamanho do grupo).
  • Privacidade em nível de feature (feature-level privacy): proteger campos específicos (por exemplo, código de diagnóstico) mais do que outros.

Você não consegue escolher bem uma técnica sem esse modelo de ameaça. Por exemplo, o aprendizado federado pode reduzir o risco de centralização de dados brutos, mas não protege automaticamente contra inferência de pertencimento ou vazamento por gradientes, a menos que seja combinado com mecanismos adicionais.

Privacidade Diferencial (DP): proteção formal contra inferência

Privacidade Diferencial é a definição formal de privacidade mais amplamente usada em ML. Informalmente, um algoritmo aleatorizado é diferencialmente privado se a distribuição de suas saídas muda apenas ligeiramente quando os dados de uma única pessoa são adicionados ou removidos. Isso dificulta que um atacante infira se um indivíduo participou.

Definição central (alto nível)

Um mecanismo (M) é ((\varepsilon, \delta))-DP se, para quaisquer dois conjuntos de dados adjacentes (adjacent) (D) e (D') (diferindo em um indivíduo) e qualquer evento (S):

[ \Pr[M(D) \in S] \le e^\varepsilon \Pr[M(D') \in S] + \delta ]

  • (\varepsilon) (epsilon) controla a perda de privacidade: quanto menor, mais forte a privacidade.
  • (\delta) é uma pequena probabilidade de falha (frequentemente definida perto de (1/N) ou menor).

DP no treinamento: DP-SGD

A técnica mais comum é Descida do Gradiente Estocástica com Privacidade Diferencial (Differentially Private Stochastic Gradient Descent, DP-SGD):

  1. Calcular gradientes por exemplo (per-example gradients).
  2. Clipping (clip) de cada gradiente a uma norma máxima (C) (limita a sensibilidade).
  3. Adicionar ruído gaussiano calibrado por (C) e pelo multiplicador de ruído (\sigma) (noise multiplier).
  4. Aplicar a atualização do gradiente ruidoso e agregado.
  5. Acompanhar a perda de privacidade cumulativa com um contador de privacidade (privacy accountant) (por exemplo, DP de Rényi (Rényi DP)).

Implicações práticas:

  • O clipping impede que qualquer registro individual domine a atualização.
  • O ruído degrada a acurácia; modelos/dados maiores frequentemente conseguem “absorver” mais ruído.
  • DP em nível de usuário é mais estrita do que DP em nível de registro (frequentemente requer agrupar todos os registros de um usuário antes do clipping).

Exemplo mínimo (loop conceitual de DP-SGD)

for step in training_steps:
    batch = sample_minibatch(data)

    per_example_grads = [grad(loss(model(x_i), y_i), model.params)
                         for (x_i, y_i) in batch]

    clipped = [g * min(1.0, C / (l2_norm(g) + 1e-12)) for g in per_example_grads]

    summed = sum(clipped)
    noise = Normal(0, (sigma * C)**2).sample(shape=summed.shape)

    noisy_grad = (summed + noise) / batch_size
    model.params = optimizer.update(model.params, noisy_grad)

    accountant.update(batch_size, sigma)  # tracks (epsilon, delta)

Em implementações reais, calcular gradientes por exemplo de forma eficiente requer suporte do framework (por exemplo, vetorização (vectorization)) e engenharia cuidadosa.

DP para inferência e saídas

A DP também pode ser aplicada a:

  • Estatísticas divulgadas (por exemplo, contagens DP, histogramas)
  • Publicação do modelo treinado (o treinamento com DP protege o modelo publicado)
  • Resposta a consultas (ruído DP adicionado às saídas, ou orçamento de privacidade por usuário/chave de API)

Um erro comum: proteger o modelo treinado com DP não protege automaticamente prompts sensíveis enviados posteriormente a uma API de inferência (isso é um problema separado de tratamento de dados).

Exemplo prático: treinar uma regressão logística DP para analytics

Suponha que você treine um modelo para prever churn a partir de eventos de usuário. Você pode:

  • Usar DP-SGD (ou versões DP de otimização convexa)
  • Acompanhar ((\varepsilon, \delta))
  • Liberar o modelo para analistas sem fornecer dados brutos

Isso pode reduzir o risco de que analistas (ou atacantes com o modelo) determinem se o registro de um usuário específico foi usado.

Trade-offs e armadilhas da DP

  • Privacidade–utilidade: (\varepsilon) menor geralmente reduz a acurácia.
  • Sensibilidade a hiperparâmetros: norma de clipping (C), ruído (\sigma), tamanho do lote (batch size) e número de passos afetam fortemente utilidade e privacidade.
  • Composição (composition): a perda de privacidade se acumula ao longo dos passos de treinamento e ao longo de múltiplas divulgações.
  • Qualidade dos dados ainda importa: DP não corrige ruído nos rótulos, viés ou mudança de distribuição; ela pode amplificá-los.
  • Interpretação: (\varepsilon) não é uma “porcentagem de privacidade”; é um limite com um significado específico.

Aprendizado Federado (FL): mantenha os dados locais, compartilhe atualizações

Aprendizado Federado treina um modelo global enviando o modelo a dispositivos ou silos, realizando treinamento local e agregando atualizações — sem centralizar dados brutos de treinamento.

Por que FL ajuda

  • Reduz a centralização de dados brutos: menos lugares armazenam dados sensíveis.
  • Habilita aprendizado no dispositivo (on-device learning): útil para teclados móveis, personalização e ambientes regulados.
  • Minimização de dados: alinha-se a princípios de privacidade desde a concepção (privacy-by-design).

Por que FL sozinho não é “privacidade”

FL é um método de treinamento distribuído, não uma garantia formal de privacidade. Atacantes ainda podem aprender informações sensíveis a partir de:

  • Atualizações/gradientes do modelo (vazamento por gradientes)
  • Sinais de participação (quem treinou e quando)
  • Comportamento do modelo final (inferência de pertencimento)

Por isso, FL frequentemente é combinado com agregação segura, privacidade diferencial e defesas de robustez.

Exemplo prático: predição da próxima palavra no dispositivo

Um padrão comum:

  1. O servidor envia o modelo de linguagem atual aos celulares.
  2. Os celulares treinam localmente no texto digitado recentemente.
  3. Os celulares enviam atualizações do modelo.
  4. O servidor agrega em um novo modelo.

Para tornar isso preservador de privacidade na prática, sistemas frequentemente:

  • Usam agregação segura para ocultar atualizações individuais do servidor.
  • Usam DP (frequentemente DP em nível de cliente (client-level DP)) para limitar o que o modelo final pode revelar sobre os dados de qualquer dispositivo.

Agregação segura: ocultar atualizações individuais dos clientes

Agregação segura é um protocolo que permite a um servidor calcular a soma (ou média) das atualizações dos clientes sem aprender a atualização de nenhum cliente individual. Isso é crucial em FL quando o servidor não é totalmente confiável.

Intuição

Cada cliente mascara sua atualização usando segredos pareados com outros clientes. As máscaras se cancelam quando somadas, então o servidor só vê o agregado.

Propriedades de segurança (típicas)

  • O servidor aprende apenas a atualização agregada, não atualizações por cliente.
  • Frequentemente tolera a saída de alguns clientes (dropouts) (via esquemas de limiar (threshold schemes)).
  • Em geral assume clientes honestos; clientes maliciosos ainda podem atacar o treinamento via envenenamento (poisoning) a menos que existam defesas adicionais.

Trade-offs

  • Mais rodadas de comunicação e complexidade do protocolo.
  • Gerenciamento de chaves, tratamento de dropouts e problemas de escala.
  • Não impede vazamento pelo modelo final; ela protege principalmente atualizações em trânsito.

Métodos criptográficos: compute sobre dados que você não consegue ver

Métodos criptográficos de PPML visam computar treinamento ou inferência enquanto mantêm entradas ocultas de uma ou mais partes. Em comparação com DP e FL, eles frequentemente oferecem confidencialidade mais forte, porém a um custo maior.

Computação Segura Multipartidária (MPC)

Computação Segura Multipartidária (Secure Multi-Party Computation, MPC) permite que múltiplas partes computem conjuntamente uma função sobre suas entradas mantendo essas entradas privadas.

Casos de uso:

  • Vários hospitais treinam conjuntamente um modelo sem compartilhar registros brutos.
  • Duas empresas computam analytics conjunto sem revelar listas de clientes (frequentemente via interseção privada de conjuntos (private set intersection) como sub-rotina).

Prós:

  • Confidencialidade forte sob suposições criptográficas.
  • Sem necessidade de confiar a dados brutos a um único servidor.

Contras:

  • Overhead significativo de computação/comunicação.
  • Engenharia complexa e ajuste de desempenho.
  • O modelo de adversário importa (segurança semi-honesta (semi-honest) vs segurança maliciosa (malicious security)).

Criptografia Homomórfica (HE)

Criptografia homomórfica (Homomorphic Encryption, HE) permite computação sobre dados criptografados, produzindo um resultado criptografado que pode ser descriptografado depois.

Caso de uso comum:

  • Inferência privada (private inference): um cliente criptografa features, o servidor executa um modelo criptografado e o cliente descriptografa a predição.

Prós:

  • O servidor nunca vê as entradas (e às vezes nunca vê as saídas).
  • Boa opção quando um cliente quer consultar um modelo sem revelar a consulta.

Contras:

  • Frequentemente alta latência e operações suportadas limitadas (especialmente para redes profundas).
  • Requer adaptação do modelo (por exemplo, aproximações polinomiais para ativações).
  • Gerenciamento de chaves e expansão do ciphertext (ciphertext expansion).

Ambientes de Execução Confiáveis (TEEs)

Ambientes de execução confiáveis (Trusted Execution Environments, TEEs) (por exemplo, enclaves de hardware) executam código em um ambiente isolado destinado a proteger dados durante a computação.

Prós:

  • Frequentemente mais rápido do que HE/MPC para modelos complexos.
  • Pode proteger a lógica de treinamento/inferência e dados em uso.

Contras:

  • Requer confiar no hardware e em seu modelo de segurança.
  • Vulnerável a alguns ataques por canal lateral (side-channel attacks) se não for cuidadosamente projetado.
  • Complexidade operacional (atestado (attestation), builds de enclave, limites de memória).

Quando a criptografia é a ferramenta certa

  • Você precisa ocultar entradas no momento da inferência do provedor do modelo (inferência privada).
  • Você precisa de computação entre organizações onde nenhuma parte possa ver os dados brutos da outra.
  • Restrições regulatórias ou contratuais proíbem o compartilhamento de dados mesmo com controles fortes de acesso.

Na prática, sistemas frequentemente combinam criptografia com DP/FL para cobrir diferentes canais de vazamento.

Juntando tudo: padrões comuns de sistemas PPML

Padrão 1: Aprendizado Federado + Agregação Segura + (Opcional) DP

Esta é uma abordagem comum para ecossistemas de dispositivos:

  • FL reduz a centralização de dados brutos.
  • Agregação segura impede que o servidor inspecione atualizações individuais.
  • DP limita vazamento pelo modelo final e fornece uma garantia mensurável.

Bom para:

  • Personalização no dispositivo (teclados, recomendações)
  • Grandes populações de clientes
  • Modelo de ameaça moderado: servidor curioso + riscos de publicação do modelo em caixa-preta/caixa-branca

Padrão 2: Treinamento central com DP (DP-SGD) + publicação controlada do modelo

Quando uma única organização treina em dados sensíveis centralizados:

  • Treinar com DP-SGD
  • Liberar o modelo treinado interna ou externamente com risco de privacidade limitado
  • Combinar com controles de segurança padrão (controle de acesso, logging, criptografia)

Bom para:

  • Compartilhar um modelo com analistas, parceiros ou o público
  • Mitigar risco de inferência de pertencimento a partir de modelos publicados

Padrão 3: MPC/HE para inferência privada

Quando consultas do cliente são sensíveis:

  • O cliente criptografa a entrada (HE) ou participa de um protocolo MPC.
  • O servidor computa a predição sem aprender as entradas.

Bom para:

  • Suporte à decisão médica onde as features são sensíveis
  • Consultas proprietárias de usuários
  • Cenários em que o provedor do modelo não pode ver os dados do usuário

Padrão 4: Aprendizado dividido + criptografia/TEEs (especializado)

No aprendizado dividido, parte do modelo roda no cliente e parte no servidor. Isso pode reduzir a exposição de dados brutos, mas pode vazar por representações intermediárias a menos que seja combinado com DP, criptografia ou TEEs.

Principais trade-offs: garantias de privacidade vs utilidade vs complexidade

PPML é, fundamentalmente, sobre equilibrar três forças.

Garantias de privacidade

  • Garantia formal mais forte: privacidade diferencial (para vazamento do tipo inferência de pertencimento).
  • Confidencialidade mais forte: métodos criptográficos (ocultam dados durante a computação).
  • Melhor “minimização de dados”: aprendizado federado (dados permanecem locais), mas requer mecanismos extras para privacidade formal.

Utilidade do modelo

  • DP frequentemente reduz acurácia; o impacto depende de:
    • tamanho do conjunto de dados (mais dados ajudam)
    • complexidade da tarefa
    • configurações de clipping/ruído
    • arquitetura do modelo e estabilidade do treinamento
  • Inferência criptográfica pode preservar a acurácia do modelo, mas pode exigir aproximações (HE) e restringir arquiteturas.
  • FL pode igualar o desempenho centralizado em alguns casos, mas sofre com:
    • dados não-IID (non-IID) entre clientes
    • variabilidade de disponibilidade dos clientes
    • limites de comunicação

Complexidade e custo do sistema

  • Treinamento com DP requer contabilidade de privacidade, gradientes por exemplo e ajuste fino.
  • FL requer orquestração, gestão de dispositivos e protocolos seguros em escala.
  • Agregação segura adiciona rodadas e modos de falha (dropouts).
  • MPC/HE/TEEs adicionam overhead substancial de engenharia e operação.

Uma heurística prática de decisão:

  • Se seu principal risco é publicação do modelo / inferência de pertencimento, comece com treinamento com DP.
  • Se sua principal restrição é não centralizar dados brutos, considere FL, mas assuma que você também vai precisar de agregação segura e frequentemente de DP.
  • Se seu principal risco é confidencialidade no momento da inferência (consultas do usuário), considere HE/MPC ou TEEs.

Orientações práticas e exemplos

Exemplo: construindo um classificador de texto com DP (treinamento central)

Objetivo: Treinar um classificador em tickets de suporte ao cliente e depois compartilhá-lo com múltiplas equipes.

Passos:

  1. Remover identificadores diretos e minimizar os campos coletados (higiene de privacidade ainda importa).
  2. Usar DP-SGD com um alvo ((\varepsilon, \delta)).
  3. Validar utilidade em dados de validação (holdout); ajustar clipping/ruído.
  4. Documentar parâmetros de privacidade e uso pretendido (por exemplo, um model card interno).
  5. Restringir e registrar (log) acesso ao modelo para reduzir vazamento secundário via mau uso.

Dicas de engenharia:

  • Use uma biblioteca de DP (por exemplo, otimizadores DP integrados ao framework) em vez de ruído ad-hoc.
  • Fique atento à instabilidade de treinamento; DP frequentemente precisa de batches maiores e agendas cuidadosas de taxa de aprendizado.

Exemplo: treinamento entre hospitais sem compartilhamento de dados

Objetivo: Treinar um modelo entre hospitais que não podem trocar dados em nível de paciente.

Opções:

  • Aprendizado federado (FL em silos (silo FL)): cada hospital treina localmente; um coordenador agrega.
    • Adicione agregação segura se o coordenador não for totalmente confiável.
    • Considere DP se o modelo final for compartilhado amplamente.
  • MPC: confidencialidade mais forte, mas custo maior.
  • TEEs: um meio-termo se a confiança no hardware for aceitável.

A escolha certa depende de:

  • número de hospitais
  • latência e custo aceitáveis
  • fronteiras legais de confiança
  • se o próprio modelo final é considerado sensível

Exemplo: inferência privada para um vetor de features sensível

Objetivo: Um usuário consulta um modelo de risco (de um fornecedor) sem revelar as entradas.

Opções:

  • Inferência baseada em HE: criptografar features; o fornecedor computa; o usuário descriptografa.
  • MPC: usuário e fornecedor computam conjuntamente.
  • TEEs: usuário envia plaintext para um enclave com atestado.

Se o fornecedor também quiser proteger os pesos do modelo, abordagens baseadas em MPC ou TEEs podem ajudar, embora riscos de extração do modelo ainda precisem ser considerados.

Armadilhas comuns

  • “Anonimizamos os dados”: anonimização ingênua frequentemente falha contra ataques de ligação; PPML tipicamente requer garantias mais fortes ou proteções criptográficas.
  • Confundir FL com DP: FL não impede inferência de pertencimento por si só.
  • Ignorar metadados: participação e timing podem ser sensíveis (por exemplo, um dispositivo participando de um estudo médico).
  • Sem avaliação de privacidade: mesmo com DP, você ainda deve realizar testes no estilo equipe vermelha (red-team) (ataques de inferência de pertencimento) para capturar erros de implementação.
  • Desconsiderar envenenamento/robustez: em FL, clientes maliciosos podem envenenar atualizações; privacidade e segurança são relacionadas, mas distintas.

Avaliação: como medir privacidade na prática

Uma avaliação madura de PPML inclui:

  • Parâmetros formais (se usar DP): ((\varepsilon, \delta)) reportados, definição de adjacência (registro vs usuário) e método de contador.
  • Testes empíricos de privacidade: benchmarks de inferência de pertencimento e ataques de reconstrução sob suposições realistas de acesso.
  • Métricas de utilidade: acurácia, calibração, desempenho por subgrupo (mecanismos de privacidade podem prejudicar desproporcionalmente grupos minoritários).
  • Métricas de sistemas: latência, largura de banda, taxas de falha, impacto na bateria do dispositivo (para FL).
  • Documentação: modelo de ameaça, objetivos de privacidade e controles operacionais.

Direções atuais e desafios em aberto

  • DP escalável em nível de usuário para grandes conjuntos de dados de usuários, de longa duração (mais difícil do que em nível de registro).
  • Melhor utilidade sob DP para aprendizado profundo (deep learning), especialmente para classes raras e grandes modelos generativos.
  • Privacidade para embeddings e sistemas de recuperação (bancos de dados vetoriais podem vazar informação sensível mesmo se o modelo base for treinado com DP).
  • Privacidade composicional em pipelines complexos (ajuste fino, RLHF, avaliação, logging).
  • Sistemas híbridos que combinem FL + agregação segura + DP + TEEs de maneira fundamentada.

Resumo

O aprendizado de máquina com preservação de privacidade é melhor entendido como uma caixa de ferramentas:

  • Privacidade Diferencial fornece proteção formal e quantificável contra vazamento da influência de dados individuais através do modelo.
  • Aprendizado Federado reduz a centralização de dados brutos, mas precisa de medidas adicionais para lidar com vazamento por gradientes e ataques de inferência baseados no modelo.
  • Agregação segura protege atualizações individuais de clientes em FL contra um servidor curioso.
  • Métodos criptográficos (MPC, HE) e hardware confiável (TEEs) protegem dados durante a computação, frequentemente permitindo treinamento ou inferência privados através de fronteiras de confiança.

Escolher a abordagem certa exige um modelo de ameaça claro e um balanceamento deliberado entre força de privacidade, utilidade do modelo e complexidade do sistema.