Capítulo 5 — Validação de Entrada e Filtragem de Saída

Quinto post do passeio capítulo a capítulo pelo LLM Primer VII: Segurança de IA. O capítulo que transforma o quadro de mitigação em camadas do Capítulo 4 em disciplina operacional — estágios de sanitização, ferramental de guardrail, saída estruturada, red teaming e medidas de segurança que significam alguma coisa.

Por que este capítulo existe

A arquitetura de mitigação em quatro camadas nomeada no Capítulo 4 é tão boa quanto suas camadas são operacionais. O Capítulo 5 desenvolve duas delas: o lado da entrada, em que as requisições do usuário são inspecionadas e passam, se transformam ou são recusadas; e o lado da saída, em que a resposta do modelo é conferida contra um segundo conjunto de portas antes de deixar o sistema. Em torno dos dois estão as disciplinas de prompting estruturado, teste adversarial e medição de segurança. As ferramentas amadureceram — Llama Guard, NeMo Guardrails, Lakera Guard, AWS Bedrock Guardrails, Garak, PyRIT, promptfoo — e os padrões operacionais para conectá-las convergiram.

5.1 Sanitização é em estágios, não single-shot

"Sanitizar entrada" carrega conotações enganosas da era do SQL injection. Em sistemas LLM, sanitização é um processo em estágios — inspecionar, classificar, transformar, passar ou recusar — cuja saída não é uma entrada "segura" e sim uma entrada que passou por um conjunto de portas de política com o resultado registrado. O pipeline geralmente tem quatro tipos de verificação, ordenados por custo. Verificações estruturais são as mais baratas: limites de comprimento, restrições de character set, normalização Unicode NFKC, remoção de caracteres de largura zero e confundíveis que compõem boa parte da literatura de smuggling. Verificações por padrão pegam overrides explícitos e templates adversariais conhecidos; são ruidosas nas duas direções mas úteis como triagem grosseira quando os hits são logados em vez de bloqueados. Verificações de classificação usam modelos de segurança dedicados — Llama Guard, a OpenAI Moderation API e os equivalentes de Lakera e AWS Bedrock — para pontuar a entrada contra uma taxonomia definida. Verificações baseadas em LLM, o tier mais caro, invocam um modelo menor para raciocinar sobre intenção quando a confiança do classificador é intermediária. Cada estágio tem taxa de falso positivo e falso negativo, e as duas precisam ser medidas antes de o pipeline ser confiado ao tráfego de produção.

5.2 Saída estruturada é defesa, não só conveniência de formatação

A arquitetura de defesa em profundidade do Capítulo 4 tem uma terceira camada estrutural que este capítulo desenvolve: restringir a saída do modelo a um schema definido, de modo que mesmo uma saída influenciada por injeção não consiga escapar do envelope estrutural. A forma mais simples é JSON com schema imposto. O modelo é instruído a emitir JSON conforme um schema; a aplicação faz parse e valida; saída não conforme é rejeitada ou retentada. A biblioteca instructor de Jason Liu envolve os clientes OpenAI e Anthropic com modelos pydantic — o desenvolvedor escreve uma classe descrevendo a estrutura da saída e a biblioteca lida com construção de prompt, validação e retentativa. O Guidance da Microsoft Research vai além, restringindo a geração token a token contra um template que define exatamente quais posições podem conter texto livre. Do lado da moderação de saída, a família Llama Guard da Meta — versões 1 a 3, com cobertura multimodal adicionada na 3 — se tornou o classificador de peso aberto canônico ao longo de 2023 a 2025, integrada à maioria das stacks de produção como filtro de resposta. NVIDIA NeMo Guardrails e as ofertas comerciais de Lakera, AWS Bedrock e Cisco AI Defense competem em terreno similar.

5.3 Defesa não medida não é defesa

Red teaming é o que transforma uma alegação de segurança em uma medida. Red teaming manual — testadores adversariais treinados, frequentemente externos — produz prompts específicos que passaram contra o deployment, agrupados por padrão de ataque. Red teaming automatizado escala o trabalho manual pelo espaço de entrada. O NVIDIA Garak, open-source em 2023 e atualizado continuamente, roda uma bateria de probes contra um endpoint alvo e reporta quais passaram; os probes cobrem prompt injection, vazamento de dados, elicitação de discurso de ódio, smuggling de encoding, jailbreaks de role-play e por aí vai. O Microsoft PyRIT (Python Risk Identification Toolkit), lançado em 2024, acrescenta um padrão agêntico de red team em que um modelo gera ataques contra outro. O promptfoo compara prompts e modelos contra conjuntos de avaliação, útil quando a pergunta é qual configuração é mais segura. As métricas que importam compõem dois modos de falha. A taxa de sucesso de ataque responde "que fração de um conjunto de ataques definidos passa?" A calibração de recusa responde "que fração de pedidos recusados não deveria ter sido recusada?" Um sistema com zero de sucesso de ataque e 50% de taxa de recusa não resolveu o problema; ele deslocou o custo de saídas inseguras para saídas inúteis. As duas métricas exigem amostras rotuladas tiradas de distribuições reais de tráfego, e as duas dependem da composição do conjunto de avaliação. Reportar um número único sem a composição é onde alegações de segurança mais frequentemente enganam.

O que o Capítulo 5 prepara

O Capítulo 6 retoma especificamente geração aumentada por recuperação. A camada de entrada desenvolvida aqui trata a mensagem do usuário como a porção não confiável. Sistemas RAG acrescentam uma segunda porção não confiável: os chunks recuperados, cuja proveniência costuma ser menos limpa que a mensagem do usuário. A injeção indireta de prompt de Greshake, a caracterização de Liu de ataques de injeção contra aplicações integradas a LLM, o envenenamento de corpora de recuperação de Zhong e as linhas mais novas PoisonedRAG e BadRAG descrevem como essa segunda superfície falha. O Capítulo 6 percorre as fronteiras de confiança em RAG, os padrões específicos de ataque, a arquitetura de recuperação segura na qual o campo convergiu e as práticas de monitoramento que revelam ataques em nível de recuperação antes que virem incidentes.

Próximo — Capítulo 6: Riscos da Geração Aumentada por Recuperação. Fronteiras de confiança em RAG, injeção maliciosa de documentos, envenenamento de índice pelo caminho de embeddings e o monitoramento que pega os ataques que a sanitização perdeu.