Robustez e Segurança

O que “Robustez & Segurança” Significa em IA

Robustez (robustness) é a capacidade de um sistema de IA de se comportar de forma confiável sob variação benigna: ruído, dados ausentes, mudança de distribuição, entradas incomuns mas não maliciosas, falhas de hardware e ambientes em mudança.

Segurança (security) trata de resiliência sob pressão maliciosa: adversários manipulando intencionalmente entradas, dados de treinamento, padrões de acesso ao modelo, dependências ou a lógica da aplicação ao redor para causar danos — previsões incorretas, vazamento de dados, bypass de políticas ou interrupção do serviço.

Na prática, robustez e segurança se sobrepõem: muitos ataques exploram fragilidade (por exemplo, excesso de confiança em entradas fora da distribuição), e muitas defesas são defesa em profundidade (defense in depth) ao longo de modelo, dados, infraestrutura e design de produto.

Este artigo apresenta classes comuns de ameaças e as estratégias defensivas mais usadas, com indicações para tópicos mais profundos como Exemplos Adversariais, Envenenamento de Dados & Backdoors, Inferência de Pertencimento e Modelagem de Ameaças para Aplicações de LLM.

Por Que Sistemas de IA São Alvos Únicos de Segurança

Sistemas de IA diferem de software tradicional de várias maneiras:

  • Comportamento estatístico: modelos generalizam a partir de dados em vez de implementar regras explícitas, então falhas podem ser difíceis de prever e enumerar.
  • Entradas de alta dimensionalidade: imagens, áudio e texto admitem perturbações sutis que mudam o comportamento do modelo.
  • Dependência de dados: dados e pipelines de treinamento passam a fazer parte da base de computação confiável (trusted computing base, TCB).
  • Acesso ao modelo como uma API: endpoints de inferência podem vazar informação via saídas, temporização e mensagens de erro.
  • Sistemas composicionais: produtos modernos de IA (especialmente aplicações com modelos de linguagem de grande porte (large language models, LLMs)) encadeiam modelos com ferramentas, recuperação e serviços externos, ampliando a superfície de ataque.

Modelagem de Ameaças: A Base

Antes de selecionar mitigações, especifique o que você está protegendo e de quem. Uma modelagem de ameaças (threat modeling) enxuta normalmente cobre:

Ativos (o que importa para você)

  • Integridade: previsões/ações corretas; conformidade com políticas.
  • Disponibilidade: tempo de atividade, latência, estabilidade de custos.
  • Confidencialidade: dados de treinamento, prompts de usuários, saídas, pesos do modelo, prompts do sistema, lógica proprietária.
  • Segurança (safety): prevenção de conteúdo/ações nocivas, especialmente em domínios de alto risco.

Objetivos do adversário (o que atacantes querem)

  • Evasão (evasion): causar saídas erradas na inferência (por exemplo, classificação incorreta).
  • Envenenamento (poisoning): corromper o treinamento para degradar desempenho ou inserir backdoors.
  • Vazamento de privacidade (privacy leakage): inferir pertencimento ao treinamento, reconstruir dados, extrair segredos.
  • Roubo (theft): copiar comportamento/pesos do modelo, roubar propriedade intelectual.
  • Abuso (abuse): spam, fraude, geração de conteúdo não permitido, automação em escala.
  • Escalada de privilégios (privilege escalation) (aplicações com LLMs): uso indevido de ferramentas, exfiltração de dados via injeção de prompt.

Capacidades do adversário (o que atacantes conseguem fazer)

  • Caixa-preta (black-box) vs. caixa-branca (white-box): eles conseguem ver pesos/gradientes, ou apenas consultar?
  • Orçamento de consultas (query budget): ilimitado ou limitado por taxa?
  • Controle de dados: eles conseguem enviar exemplos de treinamento, feedback ou logs?
  • Controle do ambiente: eles conseguem alterar dependências, contêineres ou checkpoints?

Para sistemas com LLMs em particular, veja Modelagem de Ameaças para Aplicações de LLM para padrões no nível do sistema.

Principais Ameaças Contra Modelos e Sistemas

1) Exemplos adversariais (evasão em tempo de teste)

Exemplos adversariais (adversarial examples) são entradas construídas para causar um erro do modelo enquanto permanecem “próximas” de uma entrada benigna (frequentemente imperceptíveis em visão). Eles revelam que alta acurácia em dados naturais não implica estabilidade sob pequenas perturbações de pior caso.

  • Exemplo em visão: adicionar uma perturbação minúscula à imagem de uma placa de “pare” faz um classificador rotulá-la como “limite de velocidade”.
  • Exemplo em processamento de linguagem natural (natural language processing, NLP): pequenas edições, sinônimos ou tokens inseridos mudam classificação, detecção de toxicidade ou roteamento de intenção.

Subtipos comuns:

  • Baseados em gradiente (gradient-based) (caixa-branca): FGSM, PGD.
  • Ataques por transferência (transfer attacks): construir em um modelo substituto (surrogate model) e transferir para o alvo.
  • Ataques físicos (physical attacks): perturbações robustas a impressão, iluminação e ângulos de câmera.

Cobertura mais profunda: Exemplos Adversariais.

2) Mudança de distribuição e falhas fora da distribuição (out-of-distribution, OOD)

Nem todas as falhas são adversariais. Um grande risco prático é a mudança (shift) entre treinamento e implantação:

  • Novas populações de usuários
  • Sensores, iluminação, sotaques diferentes
  • Padrões de fraude em mudança
  • Tópicos novos e gírias no texto

Modelos frequentemente produzem previsões superconfiantes (overconfident) em entradas desconhecidas. Isso pode ser explorado, mas também ocorre naturalmente.

Conceitos-chave:

  • Calibração (calibration): as probabilidades previstas refletem a verdadeira chance de acerto?
  • Previsão seletiva (selective prediction): abster-se ou adiar quando incerto.
  • Detecção fora da distribuição (OOD detection): sinalizar entradas novas para fallback ou revisão.

3) Envenenamento de dados e backdoors (ataques em tempo de treinamento)

Em envenenamento de dados (data poisoning), atacantes influenciam dados de treinamento para degradar desempenho ou direcionar comportamento. Em ataques de backdoor (backdoor) (trojan), o modelo se comporta normalmente, exceto quando um padrão gatilho aparece.

  • Exemplo: um atacante contribui com amostras “úteis” de treinamento para um dataset público; mais tarde, qualquer entrada contendo uma sequência específica de tokens faz o modelo produzir texto escolhido pelo atacante.
  • Exemplo (visão): um pequeno adesivo (gatilho) em um objeto causa uma classificação incorreta direcionada.

Essa ameaça é especialmente relevante quando:

  • Usar dados de treinamento coletados por scraping ou gerados por usuários
  • Fazer ajuste fino com feedback do cliente (aprendizado online (online learning))
  • Incorporar datasets ou checkpoints de terceiros

Cobertura mais profunda: Envenenamento de Dados & Backdoors e Segurança da Cadeia de Suprimentos (Modelos, Dependências).

4) Ataques de privacidade: inferência de pertencimento, inversão e extração de dados de treinamento

Mesmo sem acesso direto aos dados de treinamento, atacantes às vezes conseguem inferir ou reconstruir informações sensíveis.

  • Inferência de pertencimento (membership inference): determinar se um registro específico estava no conjunto de treinamento (por exemplo: “Esse paciente estava no dataset?”). Veja Inferência de Pertencimento.
  • Inversão de modelo (model inversion): reconstruir características ou amostras representativas a partir de saídas ou gradientes (por exemplo, reconstruindo rostos a partir de um classificador). Veja Inversão de Modelo.
  • Extração de dados de treinamento (training data extraction): modelos — especialmente os grandes generativos — podem memorizar (memorize) e depois regurgitar (regurgitate) sequências raras (chaves de API, e-mails, texto protegido por copyright). Veja Extração de Dados de Treinamento.

Fatores de risco incluem:

  • Overfitting, datasets pequenos, strings raras
  • Saídas informativas demais (vetores completos de probabilidades, logits (logits))
  • Consultas irrestritas
  • Ajuste fino em dados sensíveis de usuários sem controles de privacidade

5) Extração / roubo de modelo

Atacantes podem clonar (clone) um modelo consultando-o e treinando um substituto (“modelo imitador (knockoff model)”), ou em alguns casos exfiltrar pesos por canais laterais (side channels).

  • Exemplo: um concorrente consulta sua API de classificação em escala, coletando pares (entrada, saída), e então treina um modelo similar.
  • Exemplo: se sua API retorna probabilidades ricas, a extração se torna mais fácil do que se ela retorna apenas rótulos top-1.

Cobertura mais profunda: Extração / Roubo de Modelo.

6) Ameaças específicas de LLM: injeção de prompt e abuso de ferramentas

Quando um LLM está conectado a ferramentas (busca, bancos de dados, e-mail, execução de código), o modelo se torna um controlador (controller) — e adversários podem manipular suas instruções.

Problemas típicos:

  • Injeção de prompt (prompt injection): texto malicioso na entrada do usuário ou em documentos recuperados instrui o modelo a ignorar regras ou exfiltrar segredos.
  • Injeção indireta de prompt (indirect prompt injection): o atacante oculta instruções em páginas da web ou arquivos que o sistema recupera.
  • Exfiltração de dados (data exfiltration): o modelo é enganado para revelar prompts do sistema, credenciais ou dados privados recuperados.
  • Uso indevido de ferramentas (tool misuse): o modelo é induzido a chamar ferramentas com parâmetros controlados pelo atacante (por exemplo, enviar e-mails, transferir fundos, deletar arquivos).

Essas são vulnerabilidades de sistema mais do que “vulnerabilidades do modelo”, e exigem controles na camada de aplicação. Veja Modelagem de Ameaças para Aplicações de LLM.

7) Comprometimento da cadeia de suprimentos

O ML moderno depende de:

  • Checkpoints pré-treinados
  • Hubs de modelos
  • Dependências Python
  • Imagens de contêiner
  • Artefatos de datasets
  • Drivers de GPU e bibliotecas de runtime

Atacantes podem inserir código malicioso, pesos envenenados ou etapas de build comprometidas. Veja Segurança da Cadeia de Suprimentos (Modelos, Dependências).

8) Ataques à disponibilidade e exploração de custos

Mesmo que as saídas permaneçam corretas, atacantes podem prejudicar disponibilidade ou custo:

  • Inundar endpoints de inferência (DDoS)
  • Construir entradas longas de pior caso para LLMs para aumentar o uso de tokens
  • Acionar repetidamente chamadas caras de ferramentas
  • Causar falhas de cache (cache misses) ou comportamento patológico de recuperação

Disponibilidade costuma ser subenfatizada em discussões de ML, mas é um risco operacional primário.

Estratégias Defensivas (Defesa em Profundidade)

Nenhuma técnica única “resolve” a segurança em IA. Programas eficazes aplicam controles em camadas ao longo de: dados, modelo, runtime e operações.

1) Treinamento e avaliação robustos (nível do modelo)

Treinamento adversarial (otimização robusta)

Uma defesa comum para exemplos adversariais é o treinamento adversarial (adversarial training), que treina com perturbações de pior caso dentro de uma bola de norma (norm ball) (por exemplo, PGD). Ele pode melhorar significativamente a robustez, mas frequentemente:

  • reduz a acurácia em dados limpos (clean accuracy),
  • aumenta o custo computacional,
  • é sensível à incompatibilidade do modelo de ameaças (por exemplo, diferentes tipos de perturbação).

Aumento de dados e invariâncias

Para robustez benigna:

  • aumentos (crop, blur, noise, paraphrase),
  • randomização de domínio (sim-to-real),
  • treinamento em ambientes diversos.

Regularização e calibração

  • Decaimento de peso, dropout, early stopping reduzem overfitting (ajuda privacidade e robustez).
  • Métodos de calibração (temperature scaling) melhoram a confiabilidade probabilística, permitindo melhores limiares de abstenção.

Robustez certificada (quando viável)

Para alguns modelos/cenários, defesas certificadas (certified defenses) fornecem garantias de que previsões não mudarão sob perturbações limitadas. Esses métodos podem ser conservadores e menos escaláveis, mas são valiosos em contextos de alta garantia.

Exemplo prático: exemplo adversarial FGSM (estilo PyTorch)

# Illustrative snippet: crafting an FGSM adversarial example for an image classifier
import torch
import torch.nn.functional as F

def fgsm_attack(model, x, y, eps=2/255):
    x = x.clone().detach().requires_grad_(True)
    logits = model(x)
    loss = F.cross_entropy(logits, y)
    loss.backward()

    # perturb in direction of gradient sign
    x_adv = x + eps * x.grad.sign()
    x_adv = torch.clamp(x_adv, 0.0, 1.0)
    return x_adv.detach()

# In practice: evaluate robust accuracy by measuring accuracy on x_adv

Mesmo que você não implante treinamento adversarial, incluir avaliação adversarial em suítes de teste pode revelar fragilidades cedo.

2) Validação de entrada, monitoramento e fallbacks seguros (nível do sistema)

Sistemas robustos detectam e degradam graciosamente:

  • Checagens de esquema e tipo (schema and type checks): rejeitar entradas malformadas cedo.
  • Limites de conteúdo e tamanho: limitar resolução de imagem, duração de áudio, comprimento de texto.
  • Detecção de fora da distribuição/incerteza: se a incerteza for alta, abster-se ou rotear para um modelo/caminho mais seguro.
  • Detecção de anomalias em runtime (runtime anomaly detection): monitorar deriva de distribuição em incorporações (embeddings), logits ou estatísticas de features.
  • Comportamento de fallback (fallback behavior): retornar “Eu não sei”, solicitar esclarecimento ou escalar para revisão humana.

Isso se relaciona de perto a práticas de segurança em Alinhamento & Segurança, mas aqui o foco é entradas adversariais ou inesperadas.

3) Protegendo privacidade e dados sensíveis

Reduzir memorização e vazamento

  • Evite treinar com segredos (chaves, credenciais); faça varredura e filtragem de corpora de treinamento.
  • Prefira minimização de dados (data minimization): manter apenas o necessário, pelo tempo necessário.
  • Use pipelines de remoção de PII (PII scrubbing) e redação para logs e conjuntos de treinamento.

Limitar informação de saída

  • Não retorne vetores completos de probabilidades a menos que seja necessário.
  • Considere arredondamento, top-k ou saídas apenas com rótulo (label-only) para APIs públicas.
  • Tenha cautela com explicações que possam vazar características.

Treinamento com privacidade diferencial (DP) (quando apropriado)

Privacidade diferencial (differential privacy, DP) (por exemplo, DP-SGD) fornece um limite fundamentado de quanto qualquer registro individual pode afetar o modelo treinado, mitigando inferência de pertencimento e alguns riscos de extração — frequentemente com custo de utilidade, especialmente para datasets pequenos.

(Você também pode querer um artigo separado no wiki sobre privacidade diferencial; é um tópico complementar comum a Inferência de Pertencimento.)

4) Protegendo o acesso ao modelo (controles de API e infraestrutura)

Muitos ataques se tornam práticos apenas com acesso em grande escala. Controles comuns incluem:

  • Autenticação e autorização (authn/authz): chaves por tenant, permissões com escopo.
  • Limitação de taxa (rate limiting) e cotas: reduzir extração e abuso.
  • Detecção de abuso (abuse detection): identificar padrões de scraping e consultas repetidas quase duplicadas.
  • Modelagem de resposta (response shaping): minimizar sinal desnecessário (logits, erros detalhados).
  • Marcação d’água (watermarking) / impressão digital (fingerprinting) (quando aplicável): ajudar a detectar saídas de modelo roubadas ou proveniência, conectando a Proveniência & Autenticidade.
  • Implantação segura (secure deployment): isolar a inferência, restringir segredos, usar menor privilégio para integrações com ferramentas.

Exemplo prático: conceito simples de limitação de taxa

Embora a limitação de taxa em produção geralmente viva em um gateway de API (API gateway), a lógica é direta:

# Sketch only (not production): per-api-key token bucket rate limiter
import time
from collections import defaultdict

CAPACITY = 60        # tokens
REFILL_PER_SEC = 1   # tokens per second

buckets = defaultdict(lambda: {"tokens": CAPACITY, "ts": time.time()})

def allow(api_key, cost=1):
    b = buckets[api_key]
    now = time.time()
    elapsed = now - b["ts"]
    b["tokens"] = min(CAPACITY, b["tokens"] + elapsed * REFILL_PER_SEC)
    b["ts"] = now
    if b["tokens"] >= cost:
        b["tokens"] -= cost
        return True
    return False

Para LLMs, “cost” pode ser proporcional ao uso esperado de tokens ou chamadas de ferramentas.

5) Defesas para aplicações com LLM: isolamento de ferramentas e resiliência a injeção de prompt

Como aplicações com LLMs frequentemente são agênticas (agentic) e conectadas a recursos externos, você precisa de controles explícitos além de instruções no prompt:

  • Trate texto recuperado como não confiável: isole-o; nunca permita que ele sobreponha políticas.
  • Restrinja ferramentas com listas de permissão (allowlists): domínios, comandos e parâmetros permitidos.
  • Checagens fortes de autorização fora do modelo: o LLM deve solicitar uma ação; uma camada separada de política deve aprová-la.
  • Credenciais de menor privilégio (least-privilege credentials): tokens de curta duração, acesso com escopo (somente leitura quando possível).
  • Interfaces estruturadas de ferramentas: esquemas JSON, chamada de funções (function calling) com validação.
  • Codificação de saída (output encoding): prevenir injeção em interpretadores downstream (SQL/HTML/Markdown).
  • Tratamento de segredos (secret handling): nunca colocar segredos no prompt; use canais laterais seguros.

Esta área é coberta com mais profundidade em Modelagem de Ameaças para Aplicações de LLM.

6) Segurança do pipeline de dados e da cadeia de suprimentos

Para reduzir envenenamento e comprometimento de artefatos:

  • Rastreamento de proveniência (provenance tracking): fontes de dataset, hashes, linhagem.
  • Assinatura e verificação de artefatos (artifact signing and verification): assinar checkpoints de modelo e contêineres.
  • Builds/treinamento reprodutíveis (reproducible builds/training): fixar versões de dependências; registrar configs e seeds.
  • Varredura de dependências (dependency scanning): varredura de CVEs, detecção de pacotes maliciosos.
  • Ambientes de treinamento isolados: reduzir risco de exfiltração.
  • Portões de revisão (review gates) para contribuições de dados e processos de rotulagem.

Veja Segurança da Cadeia de Suprimentos (Modelos, Dependências) para um tratamento mais detalhado.

7) Red teaming, testes e resposta a incidentes

Robustez e segurança não são conquistas pontuais.

  • Red teaming (red teaming) sonda sistematicamente falhas e explorações — especialmente para modelos generativos e aplicações com LLMs. Veja Red Teaming.
  • Avaliação contínua (continuous evaluation): testes de regressão entre versões de modelo; conjuntos de teste adversariais e fora da distribuição; auditorias de privacidade quando relevante.
  • Monitoramento em produção:
    • detecção de deriva (drift detection),
    • picos de recusas/conclusões inseguras,
    • padrões incomuns de consulta,
    • anomalias de latência e custo.
  • Resposta a incidentes (incident response):
    • revogar chaves, rotacionar segredos,
    • corrigir prompts/políticas de ferramentas,
    • hotfix de filtragem ou roteamento,
    • retreinar ou reverter modelos,
    • documentar relatórios pós-incidente (postmortems) e ações preventivas (relacionado a Governança, Risco, Conformidade).

Medindo Robustez e Segurança

Você não melhora o que não mede. Métricas úteis incluem:

  • Acurácia robusta (robust accuracy): acurácia sob um ataque especificado ou um orçamento de perturbação (por exemplo, PGD em ε=8/255).
  • Métricas de calibração (calibration metrics): ECE (expected calibration error), Brier score.
  • Métricas fora da distribuição (OOD metrics): AUROC para detecção fora da distribuição; curvas de cobertura vs. risco (coverage vs. risk curves) para abstenção.
  • Risco de privacidade (privacy risk): acurácia empírica de ataques de inferência de pertencimento; métricas de exposição (exposure metrics) para memorização.
  • Resistência à extração (extraction resistance): desempenho de modelos imitadores sob orçamentos de consulta; medidas de similaridade.
  • Métricas operacionais (operational metrics): taxa de abuso, tentativas bloqueadas, tempo médio para detectar/responder, indisponibilidade e custo por requisição sob carga.

Um princípio-chave: métricas são dependentes do modelo de ameaças (threat-model-dependent). Robustez a pequeno ruído de pixel em ℓ∞ não implica robustez a rotações, patches ou ataques semânticos (semantic attacks).

Juntando Tudo: Um Checklist Prático

Ao entregar uma funcionalidade de IA, uma linha de base pragmática se parece com:

  1. Definir modelo de ameaças: ativos, adversários, pressupostos de acesso.
  2. Endurecer a interface:
    • autenticação/autorização, limites de taxa, cotas,
    • limites de tamanho de entrada, validação de esquema.
  3. Restringir saídas:
    • retornar o mínimo necessário de informação de confiança,
    • evitar vazar prompts do sistema ou rastros internos.
  4. Treinar e testar para variação esperada:
    • aumentos, testes de estresse (stress tests), checagens fora da distribuição,
    • avaliação adversarial para casos de uso de alto risco.
  5. Proteger o pipeline:
    • proveniência de datasets, assinatura de artefatos, higiene de dependências.
  6. Controles de privacidade:
    • minimização de dados, redação, (opcionalmente) DP,
    • políticas fortes de logging (sem retenção de prompts sensíveis por padrão).
  7. Salvaguardas específicas de LLM (se aplicável):
    • isolamento de ferramentas, listas de permissão, enforcement de política externa.
  8. Prontidão operacional:
    • monitoramento, red teaming, playbooks de incidentes, planos de reversão (rollback).

Como Isso se Relaciona a Outros Tópicos de IA Responsável

  • Mitigações de robustez/segurança frequentemente apoiam segurança (safety), mas não são a mesma coisa. Safety foca em prevenir dano sob uso pretendido e mau uso previsível; segurança assume adversários ativos. Veja Alinhamento & Segurança.
  • Interpretabilidade pode ajudar a depurar falhas e entender features frágeis, mas não previne ataques automaticamente. Veja Explicabilidade/Interpretabilidade.
  • Governança conecta controles técnicos a documentação, auditorias e responsabilização. Veja Governança, Risco, Conformidade.
  • Ferramentas de proveniência ajudam a detectar adulteração, personificação e problemas de autenticidade de conteúdo. Veja Proveniência & Autenticidade.

Principais Conclusões

  • Robustez e segurança em IA exigem pensamento sistêmico (system thinking): qualidade do modelo por si só é insuficiente.
  • Comece com modelagem de ameaças, então aplique defesas em camadas ao longo de treinamento, inferência, APIs, ferramentas e cadeia de suprimentos.
  • Meça contra pressupostos explícitos sobre adversários e mantenha testes contínuos via monitoramento e Red Teaming.
  • Ataques de privacidade, extração e baseados em ferramentas frequentemente são impulsionados por acesso excessivo e detalhe excessivo nas saídas — endurecer interfaces e permissões costuma ser o passo de maior ROI.