Safety case para agentes de IA: como reunir evidências

Segurança precisa ser demonstrada para um escopo concreto

Um agente passa nos testes funcionais, respeita o formato esperado e conclui a maior parte dos casos. O fornecedor mostra controles de acesso, logs e um botão de interrupção. Cada evidência parece positiva. Ainda falta responder uma pergunta executiva: esse conjunto sustenta a decisão de colocar o sistema em operação?

Resultados dispersos dificultam a resposta. Um teste de qualidade não prova isolamento. Uma política de acesso não prova que a credencial real segue a regra. Um kill switch descrito não prova que filas e retentativas param. Uma média alta pode esconder uma falha impeditiva.

Um safety case para agentes de IA reúne uma alegação de segurança delimitada, os argumentos que a sustentam e as evidências verificáveis de cada controle. A expressão vem de práticas de engenharia de segurança em que uma organização precisa explicar por que determinado sistema pode operar dentro de condições definidas.

Para agentes empresariais, o artefato ajuda a decidir se uma versão pode ler, preparar, recomendar ou agir sobre classes específicas de trabalho. Ele também registra limites, incertezas e condições que invalidam a autorização.

O que um safety case responde

A pergunta central precisa mencionar capacidade, versão, processo e fronteira.

Exemplo:

O agente comercial versão 3 pode preparar briefings para oportunidades ativas da unidade brasileira, usando CRM e e-mail autorizados, sem enviar mensagens ou alterar condições comerciais, porque identidade, fontes, qualidade, isolamento, escalonamento e interrupção foram testados dentro do escopo descrito.

A afirmação deixa visível:

• qual agente foi avaliado;
• qual versão entrou no caso;
• que unidade de trabalho ele executa;
• quais fontes pode usar;
• quais ações estão autorizadas;
• que público e ambiente estão cobertos;
• quais consequências permanecem bloqueadas.

“Agente seguro” é amplo demais. Segurança depende da tarefa, do contexto, da permissão, da consequência e da capacidade de resposta. Uma versão aprovada para resumir documentos internos não recebe, por consequência, autorização para enviar comunicações externas.

O sinal de mercado por trás desse artefato

A discussão sobre segurança de IA está migrando de princípios gerais para evidências de capacidade, controles e decisão de implantação.

O AI Risk Management Framework do NIST organiza a gestão de riscos nas funções governar, mapear, medir e gerenciar. Seu perfil para IA generativa destaca testes antes da implantação, proveniência, monitoramento posterior e comunicação de incidentes como práticas relevantes.

Em setembro de 2026, a OpenAI defendeu padrões de segurança baseados em capacidade, avaliações independentes, monitoramento e critérios para desacelerar ou interromper sistemas avançados. O texto é uma posição da empresa sobre modelos de fronteira. Para quem implanta agentes em processos empresariais, a tradução útil é mais estreita: autoridade operacional precisa acompanhar evidência suficiente para a consequência liberada.

O safety case não transforma recomendações de fornecedor em norma. Ele oferece uma forma de organizar a justificativa interna de segurança, usando requisitos legais, contratuais, técnicos e operacionais aplicáveis ao caso concreto.

Safety case, critérios de aceite e avaliação cumprem papéis diferentes

Os três objetos se conectam, mas terminam em entregas próprias.

Avaliação

Mede comportamento e desempenho. Executa casos, coleta resultados, encontra falhas e compara versões.

Critérios de aceite

Definem quais resultados autorizam uma transição contratual ou operacional. Ligam requisito, limite, evidência e decisão.

Safety case

Constrói o argumento de segurança para um escopo. Mostra como ameaças e consequências foram tratadas, quais evidências sustentam cada alegação, que risco residual permanece e em quais condições a autorização perde validade.

O guia sobre critérios de aceite para agentes de IA ajuda a decidir se a entrega atende ao combinado. O safety case concentra a pergunta sobre operação segura e preserva a cadeia entre risco, barreira, teste e autoridade.

Comece pela unidade de trabalho e pela consequência

A análise precisa partir do trabalho real.

Defina:

• evento que inicia a execução;
• objeto empresarial envolvido;
• fontes necessárias;
• decisões intermediárias;
• ferramentas disponíveis;
• resultado válido;
• sistema que confirma o efeito;
• pessoa responsável;
• prazo operacional;
• exceções previsíveis.

Depois liste as consequências possíveis de uma falha.

Em um briefing comercial, elas podem incluir:

• vincular informação à conta errada;
• usar compromisso desatualizado;
• expor dado de outro cliente;
• omitir uma pendência relevante;
• apresentar inferência como fato;
• gerar o material depois da reunião;
• gravar alteração no CRM fora do escopo.

A gravidade muda conforme a ação. Preparar um rascunho revisável possui um perfil. Enviar mensagem, conceder desconto ou alterar estágio comercial aumenta a necessidade de controle e evidência.

Estruture o argumento em alegações menores

Uma afirmação ampla precisa ser decomposta até chegar a pontos testáveis.

Alegação principal

O agente pode operar na capacidade, população, ambiente e autonomia descritos sem ultrapassar o risco aceito pela empresa.

Alegação 1: identidade e escopo estão preservados

O sistema associa cada execução ao objeto correto, usa identidade própria e impede acesso fora do cliente, unidade ou ambiente autorizado.

Evidências possíveis:

• testes de isolamento;
• permissões efetivas;
• traces de casos permitidos e bloqueados;
• tentativa de acesso cruzado;
• revisão de credenciais;
• confirmação no sistema de destino.

Alegação 2: fontes possuem autoridade e validade

O agente consulta registros autorizados, preserva versão e trata conflito ou ausência sem inventar uma resolução.

Evidências possíveis:

• catálogo de fontes;
• regras de precedência;
• casos com documento vencido;
• casos com registros divergentes;
• vínculos entre afirmação e fonte;
• testes de revogação.

Alegação 3: a saída atende à tarefa

Campos, classificação, prazo e formato cumprem o padrão definido para cada classe de caso.

Evidências possíveis:

• dataset representativo;
• rubrica por classe;
• revisão humana;
• erros impeditivos separados da média;
• comparação com linha de base;
• desempenho por versão.

Alegação 4: ações ficam dentro da autoridade

Ferramentas, parâmetros, valores e destinos seguem política e alçada. Ações de maior consequência pedem aprovação ou permanecem bloqueadas.

Evidências possíveis:

• catálogo de ferramentas;
• policy as code;
• testes de parâmetro inválido;
• simulação de aprovação vencida;
• confirmação de efeito;
• logs de bloqueio.

Alegação 5: falhas podem ser detectadas e contidas

A equipe recebe alertas úteis, consegue interromper capacidades e mantém o processo em modo degradado.

Evidências possíveis:

• exercício de kill switch;
• teste de indisponibilidade;
• fila preservada;
• acionamento do responsável;
• execução manual de contingência;
• reconciliação depois da retomada.

Alegação 6: mudanças não entram sem nova verificação

Modelo, instrução, fonte, ferramenta, permissão e fluxo possuem versão. Alterações materiais passam por testes e autorização proporcional.

Evidências possíveis:

• histórico de versões;
• pacote de mudança;
• suíte de regressão;
• implantação limitada;
• rollback exercitado;
• registro de aprovadores.

Essa árvore impede que uma evidência forte em qualidade esconda uma alegação vazia em segurança ou operação.

Ligue cada risco a barreiras independentes

Uma única barreira costuma ser frágil. O safety case deve mostrar defesa em profundidade.

Considere o risco de enviar uma condição comercial não autorizada.

Barreiras possíveis:

1. o agente recebe somente dados de oportunidades ativas;
2. condições comerciais vêm de uma fonte oficial versionada;
3. valores são validados por regra determinística;
4. a ferramenta de envio permanece desabilitada nessa versão;
5. o rascunho exige aprovação do responsável;
6. o aprovador vê fonte, valor e divergências;
7. qualquer envio autorizado usa limite e confirmação;
8. o monitoramento detecta ação fora do padrão;
9. o kill switch bloqueia novos envios;
10. o trace permite reconciliar os casos afetados.

Algumas barreiras previnem. Outras detectam, limitam alcance, permitem resposta ou recuperam o processo. O argumento precisa declarar a função de cada uma.

O artigo sobre guardrails para agentes de IA organiza controles entre entrada e consequência. O safety case verifica se o conjunto cobre o risco relevante e se cada barreira possui prova.

Exija evidência verificável

Documentos mostram intenção. Configuração e testes mostram implementação. Efeitos no destino mostram operação.

Uma escala simples ajuda a avaliar força da evidência.

Fraca

• afirmação do fornecedor;
• apresentação;
• print sem versão;
• política sem teste;
• demonstração escolhida;
• resultado agregado sem acesso aos casos.

Moderada

• configuração exportada;
• teste reproduzível em ambiente controlado;
• amostra com resultado esperado;
• trace ligado à versão;
• revisão por pessoa independente da implementação.

Forte para o escopo

• casos representativos e adversariais;
• confirmação em sistemas de destino;
• testes de barreira e falha;
• operação assistida com usuários reais;
• evidência preservada por versão;
• avaliação independente quando a consequência justifica;
• reteste depois de correção.

Força não significa certeza absoluta. A evidência sustenta uma decisão dentro de condições. O safety case deve registrar lacunas e explicar por que o risco residual foi aceito, restringido ou considerado impeditivo.

Monte um registro de alegações e evidências

Uma tabela pode manter o argumento auditável.

| ID | Alegação | Risco coberto | Controle | Evidência | Resultado | Limite | Dono | |---|---|---|---|---|---|---|---| | SC-01 | cada execução usa a conta correta | mistura de clientes | isolamento por tenant e validação de ID | teste cruzado e trace | aprovado | zero acesso indevido | tecnologia | | SC-02 | condição comercial vem da fonte vigente | valor incorreto | consulta versionada e bloqueio de conflito | casos com versões concorrentes | aprovado com pendência | conflito sempre escala | comercial | | SC-03 | envio externo permanece bloqueado | comunicação sem aprovação | ferramenta desabilitada | inspeção de catálogo e tentativa ativa | aprovado | zero chamadas | segurança | | SC-04 | falha de CRM preserva a tarefa | perda ou duplicidade | fila, idempotência e contingência | simulação de indisponibilidade | reteste necessário | nenhuma unidade perdida | operação |

Cada linha precisa apontar para o artefato real, com ambiente, versão, data e responsável pela execução. “Teste aprovado” sem caminho para o resultado devolve confiança ao relato oral.

Trate ausência de evidência como estado próprio

Uma alegação pode ficar:

• sustentada;
• parcialmente sustentada;
• sem evidência suficiente;
• contradita por teste;
• fora do escopo;
• dependente de correção;
• dependente de decisão de risco.

Evite preencher lacunas com uma média geral ou com experiência do fornecedor em outro cliente. Uma credencial nunca testada continua incerta. Uma contingência nunca exercitada continua uma hipótese.

Quando a incerteza atinge uma consequência alta, restrinja a capacidade. O agente pode permanecer em leitura, modo sombra ou sugestão enquanto a equipe produz a prova necessária.

Preserve risco residual e premissas

Controles reduzem risco, mas raramente eliminam toda possibilidade de falha.

O safety case precisa registrar:

• falhas conhecidas;
• classes excluídas;
• dependências externas;
• taxa e gravidade de erro observadas;
• limitações de detecção;
• revisão humana restante;
• capacidade manual disponível;
• premissas sobre volume e ambiente;
• riscos aceitos;
• autoridade que aceitou;
• data de revisão.

Exemplo:

A autorização cobre até o volume testado, com revisão humana de todos os briefings e sem escrita automática. A indisponibilidade do CRM suspende novas execuções. O risco de atraso permanece aceito pelo dono comercial durante o piloto; mistura de conta continua impeditiva.

A redação impede que “aprovado” seja interpretado como liberdade permanente.

Defina gatilhos que invalidam o safety case

O artefato possui validade condicionada. Reabra a análise quando houver:

• troca de modelo;
• alteração material de instruções;
• nova fonte de dados;
• nova ferramenta ou conector;
• ampliação de permissão;
• mudança de população ou finalidade;
• aumento relevante de volume;
• redução de revisão humana;
• incidente ou quase incidente;
• drift de qualidade;
• mudança regulatória ou contratual;
• fornecedor ou subprocessador novo;
• falha em controle antes considerado eficaz.

O controle de mudanças para agentes de IA ajuda a classificar a alteração, executar regressão e decidir promoção. O safety case deve apontar qual alegação precisa ser retestada, evitando refazer tudo por reflexo ou liberar tudo por conveniência.

Inclua operação posterior à implantação

Evidência de pré-produção envelhece. Fontes mudam, pessoas adotam atalhos, fornecedores atualizam componentes e o volume revela exceções ausentes no piloto.

O caso precisa prever:

Monitoramento

Qualidade, erros críticos, bloqueios, ações, latência, custo, intervenção e resultado por classe.

Amostragem

Revisão dirigida por risco, versão, cliente, exceção e mudança recente.

Incidentes

Critérios de classificação, contenção, preservação de evidência, comunicação e retomada.

Manutenção

Dono de regras, fontes, testes, integrações e documentação.

Reavaliação

Data ou gatilho que obriga nova decisão.

O plano de resposta a incidentes de IA organiza a reação quando um risco se materializa. O safety case registra por que a empresa acreditava que as barreiras eram suficientes e facilita localizar qual alegação falhou.

Dê independência proporcional ao impacto

Quem construiu a solução pode produzir grande parte das evidências. Casos com maior consequência merecem uma revisão que consiga questionar escopo, amostra e interpretação.

A independência pode vir de:

• pessoa de outra equipe;
• função interna de risco ou auditoria;
• especialista do domínio sem responsabilidade pela entrega;
• segurança independente do projeto;
• terceiro contratado com liberdade de reporte.

O avaliador precisa acessar evidências, escolher casos e registrar discordâncias. O guia sobre avaliação independente de agentes de IA mostra como preservar mandato, acesso e decisão.

Independência também possui limite. O avaliador produz uma conclusão técnica. A autoridade da empresa decide aceitar, restringir ou recusar o risco dentro de suas responsabilidades.

Um fluxo prático para construir o primeiro safety case

1. Escolha uma decisão

Defina se o artefato apoiará piloto, produção limitada, ampliação de autonomia, renovação de fornecedor ou retomada após incidente.

2. Delimite a capacidade

Registre versão, unidade de trabalho, população, ambiente, dados, ferramentas, ações e exclusões.

3. Modele consequências

Liste eventos de dano, quase incidente, falha de controle e continuidade. Classifique impacto, alcance, reversibilidade e detecção.

4. Escreva as alegações

Decomponha a afirmação principal em identidade, fontes, qualidade, autoridade, contenção, mudança e operação.

5. Ligue controles

Mostre quais barreiras previnem, detectam, limitam, interrompem ou recuperam cada risco.

6. Reúna evidências

Use testes, configurações, traces, confirmações, exercícios, revisões e resultados de operação assistida.

7. Procure lacunas e contradições

Marque alegações sem prova, controles que falharam e evidências que pertencem a outra versão ou ambiente.

8. Decida o risco residual

A autoridade pode aprovar, restringir, pedir correção, manter em modo sombra ou encerrar.

9. Registre validade e gatilhos

Defina volume, prazo, condições, monitoramento e alterações que exigem reavaliação.

10. Mantenha o caso junto da versão

A execução em produção precisa apontar para a composição autorizada. Se a empresa não consegue identificar qual versão operou, o argumento perde vínculo com a realidade.

Decisões possíveis

O safety case deveria terminar em uma destas rotas:

• autorizado para o escopo descrito;
• autorizado com revisão integral;
• autorizado para classes de baixo impacto;
• autorizado com limite de volume ou período;
• mantido em modo sombra;
• devolvido para correção e reteste;
• suspenso por evidência insuficiente;
• recusado por falha impeditiva;
• encerrado porque o benefício não justifica o risco e o custo.

A decisão deve indicar dono, data, versão e próxima revisão. Aprovação verbal em reunião não sustenta uma mudança de autonomia.

Erros comuns

Copiar um safety case de outro sistema

A estrutura pode ser reutilizada. Riscos, fontes, ações, população e evidências pertencem ao caso concreto.

Usar política como prova de controle

A política define o esperado. Testes e configuração mostram se a barreira existe e funciona.

Somar métricas em uma nota única

Qualidade alta não compensa acesso indevido, impossibilidade de interrupção ou mistura de clientes.

Avaliar somente o modelo

O risco atravessa identidade, contexto, ferramentas, filas, aprovações, pessoas e destinos.

Esconder incerteza para conseguir aprovação

Lacuna explícita permite restrição e plano de teste. Certeza fabricada entrega a surpresa para a produção.

Aprovar capacidade futura

O artefato cobre a versão, o escopo e as ações testadas. Funcionalidade planejada precisa de evidência própria.

Arquivar depois da implantação

O safety case deve acompanhar mudanças, incidentes, monitoramento e reavaliação.

Checklist do safety case para agentes de IA

• A decisão apoiada pelo artefato está explícita?
• Agente, versão, ambiente e unidade de trabalho estão identificados?
• Fontes, dados, ferramentas, ações e exclusões estão delimitados?
• Consequências e classes de risco foram modeladas?
• A alegação principal foi dividida em pontos testáveis?
• Cada risco possui barreiras de prevenção, detecção ou resposta?
• Cada alegação aponta para evidência reproduzível?
• Testes representam casos comuns, difíceis e críticos?
• Efeitos foram confirmados nos sistemas de destino?
• Falhas impeditivas permanecem fora da média?
• Lacunas e contradições estão visíveis?
• Risco residual possui autoridade, justificativa e prazo?
• Limites de volume, população e autonomia foram registrados?
• Mudanças que invalidam o caso estão definidas?
• Monitoramento, incidente, manutenção e reavaliação estão cobertos?
• Uma parte independente revisou os pontos de maior impacto quando necessário?
• A decisão final possui dono, data e versão?

Evidência organiza a coragem de colocar um agente para trabalhar

Empresas precisam avançar além de demonstrações e receios genéricos. Um safety case cria uma superfície de decisão: qual capacidade será liberada, por que as barreiras parecem suficientes, que prova sustenta a conclusão e onde a autorização termina.

O valor aparece quando o documento influencia arquitetura e operação. Uma lacuna reduz autonomia. Um teste reprovado exige correção. Uma evidência forte libera um escopo delimitado. Uma mudança material reabre a análise.

Comece por um agente que já se aproxima da produção. Delimite a unidade de trabalho, modele as consequências, escreva as alegações e procure as provas. Se a justificativa depende de frases amplas, a empresa ainda possui confiança demais e evidência de menos.