Casos de Segurança

O que é um Caso de Segurança?

Um caso de segurança (safety case) é um argumento estruturado, apoiado por evidências, de que um sistema é aceitavelmente seguro para um contexto específico de implantação (deployment context). Ele responde a perguntas como:

O que pode dar errado?
Quão ruim seria, e quão provável é?
Que salvaguardas existem, e por que devemos confiar nelas?
Que evidências mostram que essas salvaguardas funcionam neste ambiente e neste momento?
Que risco residual (residual risk) permanece, e quem o está aceitando?

Em IA (AI), um caso de segurança não é apenas um relatório de resultados de testes. Ele é uma justificativa integrada que conecta:

o propósito pretendido do sistema e seus limites,
perigos e cenários de mau uso,
mitigações em camadas de modelo, produto e organização,
evidências de validação (avaliações, auditorias, testes de equipe vermelha (red teaming), monitoramento (monitoring)),
e pressupostos explícitos e incertezas remanescentes.

Casos de segurança são amplamente usados em engenharia crítica para segurança (aviação, ferrovias, dispositivos médicos, nuclear). Sistemas de IA precisam cada vez mais de rigor semelhante — especialmente quando implantados em domínios de alto impacto ou como agentes (agents) atuando no mundo.

Por que Casos de Segurança Importam em IA

Sistemas de IA tendem a ter propriedades que tornam “colocar em produção após testar” insuficiente:

Não determinismo (non-determinism) e mudança de distribuição (distribution shift): desempenho e comportamento podem mudar sob novas entradas, populações ou pressão adversarial.
Modos de falha emergentes (emergent failure modes): especialmente em modelos grandes (large models) e agentes que usam ferramentas (tool-using agents); falhas podem não ser enumeradas por testes unitários (unit tests) simples.
Acoplamento sociotécnico (sociotechnical coupling): muitos danos surgem de como as pessoas usam o sistema, incentivos, interfaces e procedimentos operacionais — não apenas do modelo.
Opacidade (opacity): pode ser difícil explicar por que um modelo tomou uma decisão, complicando a garantia e a responsabilização.

Um caso de segurança força as equipes a migrarem de “rodamos alguns benchmarks” para “conseguimos justificar esta implantação sob pressupostos declarados, com evidências e controles contínuos”.

Isso se encaixa naturalmente em Alinhamento e Segurança (Alignment & Safety): o objetivo não é apenas definir o que significa “seguro” (veja Enquadramento do Problema), mas argumentar e documentar que o sistema implantado atende a esse nível.

Conceitos Centrais e Fundamentos

“Aceitavelmente seguro” é contextual, não absoluto

Casos de segurança não provam que um sistema é perfeitamente seguro. Eles argumentam que o risco residual é aceitável dado:

gravidade do dano potencial,
probabilidade de dano,
exposição e escala,
disponibilidade de mitigações e mecanismos de resposta,
exigências legais/regulatórias,
e tolerância ao risco das partes interessadas.

Por exemplo, uma pequena alucinação em uma ferramenta de escrita criativa geralmente é de baixo risco; a mesma alucinação em orientação sobre dosagem de medicamentos é inaceitável.

Afirmações–Argumentos–Evidências (Claims–Arguments–Evidence, CAE)

A maioria dos métodos de caso de segurança se reduz a três blocos de construção:

Afirmação (Claim): uma declaração que você quer justificar (por exemplo, “O sistema não fornecerá instruções de dosagem.”)
Argumento (Argument): raciocínio que conecta evidências à afirmação (por exemplo, “Impedimos instruções de dosagem via política + classificador + fricção na UI + monitoramento.”)
Evidência (Evidence): artefatos que sustentam o argumento (por exemplo, resultados de avaliação, logs de equipe vermelha, simulações de incidente, docs de design, relatórios de auditoria).

Um modelo mental útil é: O que estamos afirmando, por que alguém deveria acreditar nisso, e que prova temos?

Notações estruturadas (por exemplo, GSN)

Na engenharia de segurança tradicional, casos de segurança costumam ser representados usando Notação de Estruturação de Metas (Goal Structuring Notation, GSN) ou estruturas similares para tornar o argumento explícito e revisável. Você não precisa de ferramentas especializadas, mas a disciplina importa: revisores devem conseguir rastrear cada afirmação de segurança de alto nível até evidências concretas.

Relação com padrões e governança

Casos de segurança frequentemente aparecem ao lado ou dentro de regimes de conformidade, como:

Estrutura de Gestão de Riscos de IA do NIST (NIST AI Risk Management Framework, AI RMF) (identificação, medição, gestão e governança de riscos),
a Lei de IA da UE (EU AI Act) (especialmente para sistemas “de alto risco”),
padrões de domínio (por exemplo, ISO 14971 para gestão de risco em dispositivos médicos, ISO 26262 para segurança funcional automotiva).

Mesmo quando não é exigido, um caso de segurança é uma forte ferramenta de governança interna: ele esclarece pressupostos, cria responsabilização e apoia decisões de aprovação formal (sign-off).

O que Entra em um Caso de Segurança de IA?

Um caso de segurança de IA prático normalmente contém as seções e artefatos a seguir.

1) Definição do sistema e contexto de implantação

Um caso de segurança deve ser explícito sobre que sistema está sendo implantado:

Modelo(s), versão(ões), ferramentas/plugins, fontes de recuperação, camadas de política
População de usuários e uso pretendido
Pontos de integração (APIs, sistemas de prontuário eletrônico (EHR systems), sistemas de pagamento, execução de código)
Ambiente operacional (restrições de latência, supervisão humana, caminhos de escalonamento)
Usos fora do escopo e usos proibidos

É aqui que muitos casos de segurança têm sucesso ou falham: escopo vago leva a afirmações impossíveis de testar e risco sem limites.

2) Objetivos de segurança e critérios de aceitação

Você precisa de critérios mensuráveis ou pelo menos auditáveis. Por exemplo:

“O sistema não deve fornecer diagnóstico médico; ele pode fornecer informações educacionais gerais com um aviso legal e orientação de escalonamento.”
“Em testes de equipe vermelha, a taxa de saídas que violam políticas para instruções de autoagressão deve ser < X a cada 10.000 solicitações, com limites de confiança.”
“Incidentes de alta severidade devem ser detectados em até Y minutos e mitigados em até Z horas.”

Esses objetivos se conectam diretamente a escolhas de enquadramento como utilidade vs. inocuidade vs. honestidade (veja Enquadramento do Problema).

3) Análise de perigos e análise de mau uso

Um caso de segurança deve documentar como os perigos foram identificados e priorizados. Em IA, perigos frequentemente incluem:

Danos de conteúdo: incentivo à autoagressão, ódio, assédio, conteúdo sexual envolvendo menores, instruções ilegais.
Danos de decisão: discriminação, negação de serviço, recomendações inseguras.
Danos de segurança: injeção de prompt (prompt injection), exfiltração de dados (data exfiltration), uso não autorizado de ferramentas.
Danos de privacidade: vazamento de dados pessoais ou memorização de dados de treinamento.
Danos operacionais: degradação silenciosa, pontos cegos de monitoramento, dependências frágeis.

Métodos comuns incluem brainstorming com especialistas no assunto (SMEs), retrospectivas de incidentes, equipe vermelha e análises estruturadas (por exemplo, raciocínio no estilo Análise de Modos de Falha e Efeitos (Failure Mode and Effects Analysis, FMEA), árvores de ataque (attack trees)). O ponto central é mostrar que a descoberta de perigos foi sistemática, não ad hoc.

4) Avaliação e priorização de riscos

A maioria das equipes usa um esquema gravidade × probabilidade, às vezes com fatores de exposição/escala. Em IA, estimar probabilidade é difícil; casos de segurança devem reconhecer a incerteza e usar:

pressupostos conservadores,
testes de estresse,
intervalos de confiança (confidence intervals) em métricas de avaliação,
e gatilhos para revisitar avaliações de risco pós-implantação.

5) Mitigações (controles em camadas)

Segurança em IA raramente é alcançada com uma única correção do lado do modelo. Casos de segurança fortes enfatizam defesa em profundidade (defense in depth), como:

Alinhamento do modelo (model alignment) e ajuste para seguir instruções (instruction-following tuning)
Camada de política e comportamento de recusa (refusal behavior) (potencialmente moldados usando abordagens como I.A. Constitucional (Constitutional AI))
Classificadores e filtros de entrada/saída (input/output classifiers)
Isolamento em sandbox (sandboxing) e controle de permissões (permissioning) no uso de ferramentas
Fricção de UI/UX para ações de alto risco (avisos, confirmações)
Revisão com humano no circuito (human-in-the-loop) para fluxos críticos
Limites de taxa (rate limits), detecção de abuso (abuse detection), verificação de identidade (identity verification) quando apropriado
Registro de logs (logging), monitoramento e planos operacionais de resposta a incidentes (incident response playbooks)

O caso de segurança deve mapear cada perigo principal a uma ou mais mitigações e mostrar por que essa combinação é suficiente.

6) Verificação, validação e evidências

As evidências devem cobrir tanto a garantia pré-implantação (pre-deployment) quanto pós-implantação (post-deployment).

Tipos comuns de evidência:

Resultados de avaliação: taxas de conformidade com políticas (policy compliance rates), testes de robustez (robustness tests), avaliações de viés/equidade (bias/fairness assessments), taxas de alucinação (hallucination rates) em tarefas relevantes.
Relatórios de equipe vermelha: internos e externos, incluindo injeção de prompt e tentativas de quebra de restrições (jailbreak).
Revisões de segurança: modelagem de ameaças (threat modeling), testes de penetração (pentests) para integrações de ferramentas, controles de acesso de menor privilégio (least privilege).
Revisões de privacidade: políticas de retenção de dados, tratamento de dados pessoais identificáveis (PII, personally identifiable information), controles de acesso, testes de vazamento.
Testes de fatores humanos (human factors): estudos de usabilidade (usability studies), se usuários confiam demais nas saídas, clareza de avisos legais.
Prontidão operacional: painéis de monitoramento, escalas de plantão (on-call), simulações de incidentes (incident drills).

Um caso de segurança também deve documentar por que esses testes são representativos e onde não são.

7) Risco residual, pressupostos e aprovação formal

Nenhum caso de segurança está completo sem:

riscos residuais que permanecem,
pressupostos (por exemplo, “usuários são treinados”, “ferramentas não podem executar código arbitrário”, “fontes de recuperação são curadas”),
e propriedade explícita da aceitação de risco (quem aprova, sob quais condições).

8) Monitoramento e o caso de segurança “vivo”

Sistemas de IA mudam: atualizações de modelo, mudanças de política, novo comportamento de usuários, novos adversários. Um caso de segurança deve ser tratado como um documento vivo com:

métricas de monitoramento ligadas a perigos,
procedimentos de resposta a incidentes,
critérios de re-treinamento/reimplantação,
gestão de mudanças (o que aciona revalidação),
auditorias periódicas e atualizações pós-incidente.

Uma Estrutura Prática (Modelo)

Abaixo está uma estrutura leve que muitas equipes conseguem implementar sem ferramentas especializadas:

## Safety Case: <System Name> v<version> for <Deployment Context>

### 1. Scope and Context
- Intended use:
- Users:
- Prohibited use:
- System boundaries:
- Dependencies (tools, data sources, vendors):

### 2. Top-Level Safety Claims
C1:
C2:
C3:

### 3. Hazard Analysis
- Hazard register (ID, description, severity, likelihood, exposure)
- Misuse cases / threat scenarios

### 4. Mitigations and Controls
- Preventative controls:
- Detective controls:
- Corrective controls:
- Human oversight:

### 5. Evidence
- Evaluations (datasets, methods, results, confidence)
- Red team findings and fixes
- Security and privacy reviews
- Operational readiness checks

### 6. Residual Risk and Assumptions
- Residual risk summary
- Key assumptions
- Open issues and follow-ups

### 7. Deployment Decision
- Go/No-go criteria and current status
- Approvals and accountable owners
- Monitoring plan and review schedule

Muitas organizações também mantêm um “livro-razão de asseguração (assurance ledger)” legível por máquina (machine-readable) para acompanhar a rastreabilidade (traceability) entre afirmações, testes e mitigações:

claims:
  - id: C1
    text: "System does not provide self-harm instructions."
    hazards: ["H12", "H13"]
    mitigations: ["M3", "M7", "M9"]
    evidence: ["E5", "E8", "E12"]
hazards:
  - id: H12
    text: "User requests method-specific self-harm instructions."
    severity: "high"
    likelihood: "medium"
mitigations:
  - id: M3
    text: "Policy-tuned refusal + safe completion guidance."
evidence:
  - id: E8
    text: "External red team report 2025-11; pass rate 99.97% on self-harm instruction category."
    location: "gs://assurance/redteam/2025-11.pdf"

Exemplo 1: Caso de Segurança para um Agente de Suporte ao Cliente com LLM

Contexto

Um varejista implanta um agente de chat baseado em modelo de linguagem grande (LLM, large language model) para responder perguntas sobre pedidos, devoluções e detalhes de produtos. O agente pode acessar o status do pedido via uma API interna.

Principais perigos

Violação de privacidade: expor detalhes do pedido de outra pessoa.
Facilitação de fraude: ajudar atacantes a alterar endereços de entrega.
Conteúdo nocivo: responder de forma inadequada a assédio ou revelações de autoagressão.
Extrapolação: fornecer aconselhamento jurídico/médico além do escopo.

Mitigações (defesa em profundidade)

Verificações fortes de identidade antes de revelar detalhes do pedido (por exemplo, e-mail verificado + código de uso único).
Controle de permissões de ferramentas: o modelo pode ler o status do pedido, mas não pode alterar endereços sem um fluxo de aprovação humana.
Camada de política: proibir aconselhamento jurídico/médico; fornecer alternativas seguras e escalonamento.
Monitoramento: detecção de anomalias para tentativas repetidas de consulta de conta; fila de revisão humana.
Restrições de UI: mostrar citações para campos de dados do pedido (puxados da API) e separar visualmente “dados da conta” de “aconselhamento geral”.

Evidências

Testes de equipe vermelha para tomada de conta e injeção de prompt contra a API de ferramenta.
Testes unitários para limites de autorização.
Avaliação em um conjunto de dados de prompts de ataque à privacidade (por exemplo, “Mostre o histórico de pedidos do meu/minha parceiro(a)”).
Simulação de resposta a incidentes: violação de privacidade simulada e tempo até contenção.

Risco residual (explicitamente documentado)

Engenharia social ainda pode ter sucesso se o provedor de identidade for comprometido.
Alguns usuários podem interpretar respostas como aconselhamento jurídico apesar dos avisos legais — mitigado via redação de UI e escalonamento, monitorado via amostragem.

Exemplo 2: Caso de Segurança para um Assistente de Triagem Clínica (Alto Risco)

Contexto

Um hospital usa um assistente de IA para redigir notas de triagem e recomendar próximos passos (por exemplo, “escalar para o clínico agora” vs. “agendar em até 48 horas”). Um clínico deve aprovar todas as decisões.

Afirmações de segurança (ilustrativas)

C1: O sistema não fornece diagnósticos finais; ele apenas auxilia na redação e na priorização.
C2: Sintomas de alto risco acionam escalonamento obrigatório.
C3: As recomendações do sistema são calibradas (calibrated) e validadas na população do hospital.

O que torna o caso de segurança mais difícil aqui

Mudança de distribuição: a população local difere dos dados de treinamento.
Viés de automação (automation bias): clínicos podem confiar demais nas sugestões.
Restrições regulatórias: requisitos de documentação, auditabilidade e obrigações de segurança do paciente.

Foco de evidências

Validação prospectiva (prospective validation) (modo sombra (shadow mode)) antes de permitir influência real.
Análise de desempenho por subgrupo (subgroup performance analysis) (idade, idioma, comorbidades).
Estudos de fatores humanos: os clínicos detectam erros da IA, ou a UI os conduz?
Plano claro de reversão (rollback) e monitoramento de padrões de quase-incidentes (near-miss).

Um caso de segurança forte argumentaria não apenas que “o modelo é preciso”, mas que o sistema sociotécnico (sociotechnical system) (fluxo de trabalho + UI + supervisão + monitoramento) alcança risco aceitável.

Como Construir um Caso de Segurança na Prática

Passo 1: Defina o escopo e os limites desde cedo

Escreva o que o sistema não fará. Isso reduz risco sem limites e torna as afirmações testáveis.

Passo 2: Crie um registro de perigos ligado a cenários reais

Inclua tanto mau uso acidental quanto mau uso adversarial. Para LLMs, sempre inclua injeção de prompt, vazamento de dados e mau uso de ferramentas se existirem ferramentas.

Passo 3: Defina afirmações no nível certo

Boas afirmações são:

específicas (sobre comportamentos ou resultados),
auditáveis (você consegue reunir evidências),
contextuais (para esta implantação, não “em geral”).

Evite afirmações como “O modelo é seguro” ou “O modelo não vai alucinar”.

Passo 4: Mapeie mitigações para perigos (e mostre lacunas de cobertura)

Uma pergunta útil para revisão: Para cada perigo de alta gravidade, o que o previne, o que o detecta e o que limita o dano se ele ocorrer?

Passo 5: Colete evidências com rastreabilidade

As evidências devem ter versionamento e ser reprodutíveis: versão do modelo, conjuntos de prompts, harness de avaliação, sementes (seeds), datas e ambiente.

Passo 6: Planeje mudanças

Defina o que aciona reaprovação:

atualizações de modelo,
novas ferramentas,
novos segmentos de usuários,
taxas de incidentes ultrapassando limites,
sinais de mudança de distribuição.

Passo 7: Torne a aprovação formal explícita e responsável

Um caso de segurança é, em última instância, um artefato de suporte à decisão. Deve ficar claro quem o revisou, o que foi aceito e quais condições se aplicam.

Revisão e Auditoria: Como é o “Bom”

Um revisor (governança interna, auditor externo, regulador) normalmente buscará:

Completude: principais perigos são identificados; pressupostos são documentados.
Raciocínio sólido: argumentos conectam evidências a afirmações sem “mágica”.
Qualidade das evidências: testes realistas, não apenas benchmarks de brinquedo.
Defesa em profundidade: múltiplos controles independentes para perigos severos.
Prontidão operacional: monitoramento, plantão, planos operacionais de incidente, reversão.
Clareza sobre incerteza: desconhecidos conhecidos e planos para reduzi-los.

Armadilhas Comuns

Teatro de benchmarks (benchmark theater): reportar métricas genéricas que não correspondem aos perigos da implantação.
Pensamento apenas no modelo: ignorar UI, incentivos do usuário, supervisão e controles operacionais.
Pressupostos não declarados: por exemplo, “usuários não tentarão burlar”, “a API de ferramenta é segura”, “as fontes de dados não vão mudar”.
Sem seção de risco residual: fingir que segurança é binária em vez de gerida por risco.
Documentos desatualizados: o caso de segurança não é atualizado à medida que o modelo, as ferramentas ou o comportamento do usuário mudam.
Sem resultados negativos: excluir falhas encontradas em equipe vermelha ou implantações piloto mina a credibilidade.

Relação com Métodos de Alinhamento

Métodos como I.A. Constitucional podem fazer parte da história de mitigação (por exemplo, melhorar comportamento de recusa ou reduzir saídas nocivas). Um caso de segurança, porém, fica acima de qualquer técnica isolada:

Ele pode incorporar treinamento de alinhamento, camadas de política pós-treinamento e monitoramento.
Ele força raciocínio explícito sobre o que esses métodos garantem e o que não garantem.
Ele conecta o comportamento em tempo de treinamento ao risco em tempo de implantação com evidências e controles.

Em outras palavras, métodos de alinhamento podem ajudar a produzir um comportamento mais seguro; o caso de segurança argumenta por que o sistema implantado como um todo é aceitavelmente seguro.

Resumo

Casos de segurança são uma forma disciplinada de argumentar e documentar por que um sistema de IA é aceitavelmente seguro para implantação em um contexto específico. Eles combinam:

escopo claro e objetivos de segurança,
análise sistemática de perigos e riscos,
mitigações em camadas entre modelo, produto e operações,
evidências rastreáveis de avaliações e equipe vermelha,
risco residual explícito e aprovação formal com responsabilização,
e um processo de atualização “vivo” conforme o sistema e o ambiente evoluem.

Para sistemas modernos de IA — especialmente agentes que usam ferramentas e aplicações de alto impacto — casos de segurança são cada vez mais uma necessidade prática, não apenas burocracia: é assim que organizações transformam intenção de segurança em decisões de implantação auditáveis e revisáveis.