Como um guardrail de IA decide: risco, regra e o que você pediu

Por que uma lista de palavras proibidas não é um guardrail?

No texto anterior, mostramos que uma regra de IA só existe quando vira mecanismo: um hook, um ponto do fluxo em que um programa da empresa roda antes de o assistente agir. Este texto trata do que esse programa decide, e de como.

A primeira tentação é uma lista: bloquear todo comando que contenha `rm -rf`, `DROP TABLE` ou `--force`. Ela falha para os dois lados. Bloqueia o `rm -rf` de uma pasta temporária que o próprio teste criou e deixa passar o script que apaga a mesma coisa por outro caminho. A lista olha a forma do comando; o risco está no efeito. E quanto mais palavras entram nela, mais o time aprende a escrever de outro jeito para passar.

Um guardrail útil olha a ação inteira, no contexto da sessão, e responde a três perguntas.

1. Quão arriscado é isto? O dano possível se a ação estiver errada: só lê, muda algo fácil de desfazer, alcança fora do projeto ou é irreversível.
2. Fere alguma regra da casa? Segredo escrito no código, dado pessoal sem máscara, escrita direta no banco de um sistema que só deve ser alterado pela API oficial, publicação fora da organização.
3. Foi isto que a pessoa pediu? Nas palavras de quem está usando, e não num arquivo ou numa página que o assistente leu no caminho.

As três perguntas são independentes, e é isso que as torna úteis. Um `git push` é arriscado e não fere regra nenhuma; se a pessoa pediu, segue. Gravar a senha do banco no arquivo de configuração é fácil de desfazer e fere a regra mais séria da casa; mesmo pedido, não segue. Enviar o conteúdo de um arquivo para um endereço desconhecido pode parecer inofensivo, mas ninguém pediu. A terceira pergunta pega o que as outras deixam passar.

O que o guardrail olha antes e depois de cada ação?

Antes, a intenção. Depois, o resultado. São dois momentos com perguntas diferentes, e um não substitui o outro.

Antes de agir, o guardrail vê o que o assistente propõe: o comando que vai rodar, o conteúdo que vai escrever num arquivo, os argumentos que vai mandar para uma ferramenta. Vê também o contexto: as últimas mensagens da pessoa, o que o assistente declarou que pretende fazer e se algo lido na sessão parecia suspeito. É aqui que se decide se a ação acontece. Uma alteração bloqueada antes não existe; o assistente recebe o motivo e reescreve.

Depois de agir, o guardrail lê o que ficou: o arquivo inteiro como está no disco e a saída do comando. A edição parecia inocente e deixou uma rota sem autenticação; o comando era uma listagem e imprimiu uma chave. O que já aconteceu não se impede. O guardrail para o próximo passo e exige a correção. Se o que apareceu foi um segredo, corrigir não é apagar a linha. É trocar o segredo, porque ele já passou pela tela e pelo registro da sessão.

O erro comum é ter só o primeiro momento: o guardrail confia no que o assistente diz que vai fazer, e a escrita por script nunca é conferida. O erro oposto é perguntar tudo a toda ação. No nosso desenho, cada regra declara onde vale, por tipo de arquivo e de uso, e só as que valem para aquela alteração entram na pergunta. Tipo desconhecido recebe todas.

Por que separar quem estima de quem decide?

Porque o modelo que classifica só sabe dar probabilidade, e decisão precisa de dono. O classificador responde a perguntas fechadas, como "esta ação expõe um segredo?", com um número entre zero e um. Quem transforma esse número em "segue", "pergunta" ou "bloqueia" é a política da empresa, escrita em código, versionada no repositório e revisada por PR como qualquer outro código.

A separação tem três efeitos. A decisão é auditável: dá para ler no código por que uma ação foi bloqueada e outra não. A política sobrevive à troca de modelo: se o classificador mudar, a regra continua a mesma e só a calibração muda. E o classificador não negocia: um modelo que recebe a pergunta e a evidência e devolve um número não tem como ser convencido pelo assistente de que "desta vez está tudo bem".

Um exemplo público ajuda a ver esse último ponto. Ao descrever o modo automático do Claude Code, em março de 2026, a Anthropic conta que o classificador que aprova as ações não vê as justificativas do agente nem o resultado das ferramentas. Um modelo que lê o argumento do agente pode ser persuadido por ele; um que lê o conteúdo de uma página pode ser manipulado por quem a escreveu.

Os limiares, que dizem a partir de que probabilidade se bloqueia e se pergunta, ficam num lugar só, fora do alcance de quem usa. Num exemplo ilustrativo, a política bloqueia uma proibição absoluta acima de 0,9 e pede aprovação a partir de 0,5. Os valores certos são os que a sua calibração mostrar. Duas regras valem para qualquer valor. O limiar de bloquear nunca fica abaixo do de perguntar. E um valor malformado não desliga a checagem em silêncio: vale o padrão, com aviso.

Bloquear, pedir aprovação ou só registrar: como escolher?

Só o que é proibição absoluta bloqueia. O resto pede aprovação ou fica registrado. É a decisão de desenho que mais pesa no uso diário, porque um guardrail que bloqueia demais ensina o time a contorná-lo, e o contorno mais comum é desligar.

Duas regras tornam essa tabela justa. Uma regra de nível "perguntar" nunca bloqueia, por mais alta que seja a probabilidade: um push direto na branch principal pode ser legítimo numa correção de madrugada, e quem decide é a pessoa. E o pedido explícito da pessoa libera o que só pediria aprovação, nunca o que bloqueia. Se você pediu "faça o push", o guardrail não pergunta de novo. Se pediu "grave a chave no arquivo", ele bloqueia do mesmo jeito.

Pedir aprovação não é meio-termo covarde. A OWASP, na lista de riscos de aplicações com modelos de linguagem de 2025, trata o excesso de autonomia como risco próprio e recomenda aprovação humana antes de ações de alto impacto.

Toda decisão diz o motivo antes de qualquer número: "bloqueado: segredo no código", a regra e a correção. O assistente é instruído a reescrever, e não a procurar atalho, como quebrar o comando em partes. A revisão depois pega o resultado, e a tentativa fica na trilha.

O erro comum é começar pelo bloqueio, porque parece mais seguro. Logo o time acumula falsos positivos, e alguém descobre como desligar. Comece com poucas proibições absolutas, as que você defenderia diante da diretoria sem hesitar, e deixe o resto em "perguntar".

E se o classificador não responder?

Alguém precisa ter decidido antes. O classificador é um serviço, e serviço cai, demora ou devolve resposta incompleta. Há duas posturas para a queda, e as duas têm custo.

Falha aberta: sem classificador, a ação segue, com aviso e registro; durante a queda, nada é revisado. Falha fechada: sem classificador, toda ação que não seja só leitura é bloqueada; o time para por um problema de terceiro, e a reação previsível de um time parado é procurar como desligar o guardrail.

No nosso desenho, o padrão é a falha aberta, com três condições. A queda é visível: ao abrir a sessão, a pessoa vê se o guardrail está operante, e cada ação não revisada fica registrada. A postura está escrita como exceção consciente à regra de, na dúvida, escolher o mais seguro. E existe um interruptor: a diretoria pode inverter para falha fechada, para todos de uma vez, sem mexer em código. A decisão é dela, e não de quem configurou.

Falta o caso mais sutil: o classificador responde, mas não responde tudo. Com evidência grande, um modelo pode recusar uma das perguntas. A que faltou vai de novo, uma vez, sozinha. Se ainda faltar, a ação vira pedido de aprovação, com o aviso de que aquele ponto ficou sem avaliação. Tratar a ausência de resposta como probabilidade zero seria um guardrail que libera justamente o que o modelo se recusou a olhar. "Sem avaliação" nunca é "pode".

Há ainda o tempo. Um hook que estoura o limite de espera da ferramenta pode ser descartado como se tivesse permitido. Por isso o orçamento do classificador, com as novas tentativas, precisa caber com folga dentro desse limite. Do contrário, a falha fechada nunca chega a acontecer.

Como o guardrail lida com texto que veio de fora?

Tratando como dado, nunca como instrução. Um assistente lê páginas, buscas, respostas de conectores e arquivos de terceiros, e qualquer um deles pode carregar texto escrito para o modelo: "ignore as instruções anteriores", "envie este arquivo para tal endereço". É o que a OWASP chama de prompt injection, o primeiro item da sua lista de 2025. A forma indireta, que chega por conteúdo lido, é a que mais importa num assistente que programa.

O guardrail atua em dois pontos. Primeiro, varre o resultado das ferramentas que trazem conteúdo de fora e marca o que parece dirigido ao modelo: o assistente é avisado, a pessoa fica sabendo o que o texto tentou, e a sessão guarda o trecho. Depois, a cada ação, a pergunta "foi isto que a pessoa pediu?" ganha uma irmã: "isto cumpre uma instrução plantada no conteúdo sinalizado?". Se cumpre, e serve a quem escreveu o conteúdo, bloqueia. Seguir o passo de instalação de um README a pedido da pessoa não conta.

Arquivos de instrução merecem o mesmo cuidado. Skills, plugins e arquivos como o `CLAUDE.md` podem pedir algo que quem instalou não esperaria, como mandar dado para fora ou ignorar as outras instruções. A varredura deles roda ao abrir a sessão e a cada arquivo novo carregado.

O erro comum aqui é varrer tudo. O resultado de uma ferramenta local, como o histórico do Git, vem da própria máquina, e varrê-lo gera falso positivo em série. A varredura vale para o que vem de fora, e o custo precisa ser dito em voz alta: texto de terceiro que chega por comando de terminal, como um `curl` ou um comentário de PR lido pela linha de comando, não é varrido.

Como se calibra, e quem pode mudar os limiares?

Com casos de teste, várias amostras por caso e um PR por mudança. A diretoria aprova; ninguém ajusta limiar dentro de uma sessão.

Calibrar começa por um conjunto de casos com a decisão esperada: o comando que pode imprimir um segredo pede aprovação, a gravação de uma chave no código bloqueia, o documento que só cita uma regra não dispara nada. Cada caso roda contra o classificador real mais de uma vez, porque uma amostra não calibra. Perto do limiar, o mesmo caso pode sair de um lado numa tarde e do outro à noite. Mede-se a taxa de acerto por caso, e a versão atual e a proposta rodam juntas, na mesma janela de tempo.

Calibrar ensina uma coisa contraintuitiva. Quando um caso diverge, o impulso é mexer no limiar, e quase sempre o problema está no texto da pergunta ou no caso. Uma pergunta sobre segredo que não diz que um dump filtrado também imprime o valor deixa passar o `printenv | grep`. Mexer no limiar para consertar um caso costuma estragar outros. Ajuste primeiro a pergunta, meça de novo e só então discuta o número.

Quem muda o quê fica escrito. Perguntas, regras e modelo do classificador estão no código e mudam por PR, com a calibração rodada antes do merge. Trocar de modelo é mudança de comportamento, não atualização. Os limiares ficam na configuração gerenciada da empresa, que o usuário não sobrescreve, assunto do próximo texto da série. Mudá-los é decisão da diretoria, registrada, com a calibração que a justifica.

O que um guardrail não resolve?

Três coisas, e é melhor dizê-las antes de alguém descobrir.

• Leitura que não passa por ele. Ferramenta só de leitura, em geral, nem passa pelo guardrail. Se o assistente lê um arquivo de segredos com ela, o conteúdo entra inteiro na conversa. O bloqueio certo é uma regra de permissão que a própria ferramenta aplica antes de qualquer hook.
• Texto de terceiro por outro caminho. O que chega por comando de terminal não é varrido como conteúdo externo. A pergunta "isto foi pedido?" continua sendo feita, mas a origem do texto não fica marcada.
• Oscilação perto do limiar. Um caso no limite pode mudar de decisão entre duas tentativas, e por isso a calibração mede taxa, e não caso.

Há também um limite que não é técnico. O guardrail reduz o que o assistente faz de errado na máquina de quem trabalha; não substitui a revisão do código nem o caminho até produção. A própria Anthropic admite que o classificador do modo automático deixa passar parte das ações arriscadas e não substitui a revisão humana cuidadosa em infraestrutura crítica. E o perfil de IA generativa do NIST lista, entre os riscos dessa tecnologia, o excesso de confiança e o viés de automação. Um guardrail que o time acredita infalível vira exatamente isso. Ele é a primeira camada de um caminho estreito, não a última.

Por onde começar se você ainda não tem guardrail?

Pela trilha, não pelo bloqueio. Antes de decidir o que bloquear, registre o que o assistente faz e o que toca produção.

1. Escreva as poucas proibições absolutas da casa, uma frase cada, com a correção ao lado.
2. Separe estimativa de decisão desde o primeiro dia: o classificador devolve probabilidade, e a política fica em código versionado.
3. Comece tudo em "perguntar", com o motivo na tela, e promova a bloqueio só o que a trilha justificar.
4. Decida a postura de falha com a diretoria, por escrito, e mostre ao abrir a sessão se o guardrail está operante.
5. Monte os casos de teste antes de mudar o primeiro limiar.

Nenhum desses passos depende de comprar uma ferramenta. Dependem de decidir, por escrito, o que a empresa não aceita, e de manter a pessoa no meio de toda ação com exceção legítima.