Evidência antes de adjetivo: como defender claims sobre sistemas de IA

“Seguro”, “confiável”, “auditável”, “autônomo” e “world-class” parecem resumir maturidade. Sem uma pergunta verificável, porém, esses adjetivos apenas deslocam o trabalho para o leitor: seguro contra qual ameaça, confiável em qual tarefa, auditável por quem, autônomo para fazer o quê?

Um claim responsável não tenta eliminar toda incerteza. Ele informa exatamente o que foi observado, sobre qual objeto, por qual mecanismo, sob quais limites e até quando a evidência permanece válida.

Este artigo propõe uma gramática prática para transformar confiança de linguagem em confiança inspecionável.

Resumo executivo

Provenance é informação verificável sobre onde, quando e como um artefato foi produzido. A especificação SLSA organiza níveis e formatos de attestation para aumentar garantias de supply chain. Isso fortalece origem e integridade do processo declarado, mas não prova a correção semântica do artefato. [R2-C2]

Do mesmo modo, um scanner, teste, eval, revisão ou auditoria examina propriedades específicas. O claim defendível precisa ligar subject → propriedade → mecanismo → evidência → verificador → validade → limite de inferência. Se qualquer elo faltar, o adjetivo deve diminuir de força.

A meta não é escrever mais disclaimers. É permitir que cliente, engenheiro, auditor ou conselho entendam o que podem decidir sem reconstruir toda a história.

A anatomia de um claim

Considere: “O release está seguro.” A frase não identifica objeto, ameaça, controle ou verificador. Uma versão mais defensável seria:

A imagem sha256:… foi produzida pelo workflow release.yml no builder aprovado, possui provenance assinada ligada ao commit X e passou pelo scanner Y sem achados HIGH na política Z em 20/08. Isso não prova ausência de vulnerabilidades nem segurança do runtime.

O claim ficou maior, mas também ficou utilizável. Ele contém:

Provenance, attestation e verificação

Provenance descreve a história relevante da produção. Attestation é uma declaração autenticada sobre um subject. Verificação compara essa declaração e seu artefato a expectativas e raízes de confiança.

As três coisas não são sinônimas:

• provenance sem assinatura pode ajudar diagnóstico, mas oferece garantia limitada;
• attestation assinada por identidade não confiável preserva uma declaração que você não aceita;
• assinatura válida com subject errado autentica o vínculo errado;
• provenance correta não afirma que a regra de negócio está certa;
• verificação sem policy explícita pode apenas confirmar estrutura.

SLSA recomenda ligar provenance ao artefato e verificar subject, assinatura, builder e parâmetros contra expectativas. Ainda assim, a própria fronteira canônica da FORGE permanece: attestation prova a cadeia declarada, não a correção semântica. [R2-C2]

Cinco classes de evidência

Evidência de intenção

Spec, ADR, issue e critério de aceite mostram o que deveria acontecer. São essenciais, mas não demonstram execução.

Evidência de execução

Logs, traces, diffs e receipts mostram ações observadas. Sem identidade e binding, podem pertencer a outro subject ou contexto.

Evidência de propriedade

Testes, scanners e evals verificam uma propriedade sob um método. Seu poder termina na cobertura e na validade desse método.

Evidência de proveniência

Digests, assinaturas, attestations e histórico ligam artefato, origem e processo. Não substituem a evidência de comportamento.

Evidência de outcome

Aceitação por cliente, qualidade percebida, incidentes e métricas de fluxo mostram efeito. Outcome sem causalidade ou baseline ainda exige cuidado ao atribuir a mudança à IA.

Um claim forte combina as classes necessárias, não todas por ritual.

O verificador faz parte do claim

“Revisado” não informa quem revisou, contra qual critério ou com que independência. A mesma equipe que produz o artefato pode fazer auto-revisão valiosa; o erro é apresentá-la como assurance independente.

Declare o modo:

• verificação automática determinística;
• avaliação por modelo;
• revisão humana do autor;
• revisão de especialista diferente do autor;
• auditoria independente com escopo e contrato;
• attestation da plataforma que executou o processo.

Independência não é um sentimento. É uma propriedade de identidade, autoridade, incentivo e acesso à evidência.

Validade: evidência também envelhece

Um relatório pertence a uma versão, um ambiente, uma policy e uma data. Depois de alterar modelo, prompt, ferramenta, dependência, dado ou authority, parte da evidência pode não representar mais o sistema.

Cada claim deve definir eventos de expiração:

• novo subject ou commit;
• mudança de configuração material;
• fonte externa atualizada ou retirada;
• vencimento temporal;
• incidente que contradiz a conclusão;
• descoberta de falha no benchmark ou no verificador.

Correção não deve apagar o claim anterior. Deve registrar nova versão, motivo e alcance.

O Evidence Pack mínimo

Para uma decisão de release, um pacote enxuto pode conter:

1. subject e digest;
2. spec e critérios aceitos;
3. políticas aplicáveis;
4. resultados dos gates ligados ao mesmo subject;
5. provenance e identidade do builder;
6. exceções com owner e expiração;
7. decisão nominal de aceite;
8. claims públicos com inference boundary;
9. caminho de correção ou retirada.

O pacote não é um arquivo enorme. É um índice verificável para evidências que já existem.

Escrevendo claims públicos

Troque:

• “totalmente seguro” por “passou pelos controles X e Y no escopo Z; riscos A e B permanecem”;
• “validado” por “avaliado no banco V, versão N, com resultado R”;
• “auditável” por “ações A–D preservam subject, actor, timestamp e receipt por 90 dias”;
• “autônomo” por “pode executar operações O1/O2 na allowlist, com budget e revogação”;
• “world-class” por referência comparável ou remova o adjetivo.

Precisão não reduz força comercial. Ela permite que confiança sobreviva à primeira pergunta técnica.

Um teste de cinco minutos

Ao revisar uma página, pitch ou relatório, destaque cada adjetivo de confiança e pergunte:

1. Qual é o subject?
2. Qual propriedade observável sustenta a palavra?
3. Onde está a evidência?
4. Quem verificou e com qual independência?
5. O que a frase não permite concluir?

Se as respostas não couberem em poucas linhas, o claim ainda está acima da evidência.

O que este artigo prova — e o que não prova

A especificação SLSA e o bundle canônico sustentam a função da provenance e sua separação da correção semântica. [R2-C2] A gramática de claims e o Evidence Pack são sínteses operacionais da FORGE apoiadas por seus contratos de controls, conformance e assurance.

Nenhum Evidence Pack prova ausência absoluta de risco. Uma attestation pode ser válida e a policy insuficiente. Uma auditoria independente pode ter escopo estreito. O objetivo é tornar limites visíveis e decisões atribuíveis, não produzir certeza total.

Conclusão

Confiança começa quando o adjetivo termina e a evidência pode ser inspecionada.

Um claim defendível fixa o subject, nomeia a propriedade, mostra o mecanismo, preserva a evidência, identifica o verificador e limita validade e inferência. Esse contrato permite dizer “ainda não sabemos” sem paralisar o trabalho — e dizer “está pronto” sem depender apenas de reputação.

Leitura anterior: Autonomia proporcional ao risco. Próxima leitura: *O agente não pode ser seu próprio auditor*, em 22/08 na Trustyu Forge.