Como avaliar segurança de LLMs antes do release

TL;DR

Em 2026, a discussão sobre segurança de LLMs antes do release saiu do campo genérico de “faça testes” e virou prática operacional documentada por vendors. Anthropic, Google DeepMind e OpenAI publicaram materiais que ajudam a transformar avaliação em gate de lançamento, com critérios mais claros para decidir o que pode ou não ir para produção.

Isso importa porque o risco não está só no modelo em si, mas no contexto de uso, no ambiente de avaliação e na capacidade de detectar comportamento perigoso antes do deploy. Para times no Brasil, a diferença aparece quando os testes precisam cobrir PT-BR, gírias, contexto regulado e restrições da LGPD em fluxos que lidam com dados sensíveis.

O que mudou no jeito de avaliar segurança

Durante muito tempo, “avaliar segurança” significava rodar um conjunto de prompts perigosos e ver se o modelo recusava. O problema é que esse tipo de verificação responde só a um pedaço da pergunta: o modelo recusa corretamente? Em 2026, os materiais de vendor blog mostram uma abordagem mais ampla, em que a avaliação passa a medir capacidade, propensão, eficácia de mitigação e condição de release.

No caso da Anthropic, o Responsible Scaling Policy Version 3.0 conecta thresholds de capacidade a salvaguardas obrigatórias e a Risk Reports. A lógica é simples: conforme a capacidade sobe, o pacote de proteção também precisa subir. Já o Frontier Safety Framework da Google DeepMind adiciona Tracked Capability Levels para antecipar sinais de risco antes de chegar ao limiar crítico. A OpenAI, por sua vez, reforça no Testing Agent Skills Systematically with Evals a ideia de usar evals de forma repetível para ajustar comportamento antes de lançar.

Anthropic: thresholds, salvaguardas e Risk Reports

A contribuição mais clara da Anthropic é tratar avaliação como governança de release. O RSP v3.0 descreve uma relação do tipo if-then: se a capacidade do modelo cruza certo threshold, determinadas salvaguardas tornam-se obrigatórias. Em vez de depender de uma revisão subjetiva no fim do ciclo, o processo passa a exigir evidência técnica de que o risco foi mapeado e mitigado.

Na prática, isso tem duas consequências. Primeiro, o time precisa definir quais capacidades importam para o risco que está sendo monitorado. Segundo, precisa produzir documentação rastreável no momento da publicação, o que torna o lançamento mais auditável. Para quem opera sistemas com impacto sensível, esse tipo de gate é mais útil do que um simples relatório de conformidade pós-lançamento.

Anthropic também chamou atenção para o desenho dos experimentos em cibersegurança em Investigating three real-world incidents in our cybersecurity evaluations. O ponto central é que ambientes de eval precisam ser controlados com o mesmo cuidado do runtime, porque o modelo pode inferir que está sendo avaliado e mudar seu comportamento. Isso vale para qualquer pipeline que tente medir abuso, automação ofensiva ou exfiltração de dados em cenário simulado.

O que esse modelo ensina para times de produto

Se o seu produto usa LLM em atendimento, automação ou análise de documentos, não basta perguntar “ele respondeu algo perigoso?”. É preciso definir thresholds, sinais de alerta e ações automáticas quando o modelo cruza limites. Em outras palavras: segurança deixa de ser um teste final e vira parte da política de release.

Google DeepMind: trilhas de risco mais cedo

O update do Frontier Safety Framework adiciona Tracked Capability Levels para acompanhar capacidades que indicam risco antes do cenário extremo. Essa mudança é importante porque nem todo risco aparece como um “evento catastrófico” imediato. Muitas vezes ele surge como uma tendência: melhoria progressiva em planejamento, execução, persuasão ou manipulação de ferramentas.

Outro ponto útil está nos FSF reports, que separam avaliação de propensão e avaliação de eficácia. Isso ajuda a evitar conclusões apressadas. Um sinal automatizado pode indicar que o modelo tende a produzir um comportamento arriscado, mas ainda é preciso medir se essa tendência realmente se traduz em impacto no uso real.

Essa separação é valiosa para equipes que montam benchmarks internos. Se tudo entra no mesmo score, a leitura vira confusa. Ao separar propensão de eficácia, o conjunto de métricas fica mais honesto: uma coisa é o modelo ter abertura para um comportamento indevido, outra é ele conseguir produzi-lo sob condições reais.

OpenAI: eval-driven development para habilidades de agente

O material da OpenAI sobre Evals reforça um fluxo de desenvolvimento guiado por avaliação. Em vez de construir o agente, lançar e torcer para o comportamento se manter estável, o time define habilidades, cria critérios e roda avaliações sistemáticas ao longo do desenvolvimento. O valor disso é reduzir surpresa na fase de release.

Esse padrão funciona bem para agentes que usam ferramentas, tomam decisões em múltiplas etapas ou interagem com dados internos. O ponto não é apenas se o agente “sabe fazer” algo, mas se ele faz de forma consistente, sob critérios objetivos e com limites claros. Para segurança, isso abre espaço para testes mais específicos: jailbreak, instruções conflitantes, abuso de ferramenta e comportamento em contexto parcialmente adversarial.

O fluxo também conversa com versionamento. Quando a capacidade do agente muda a cada ajuste de prompt, ferramenta ou modelo base, o conjunto de evals precisa acompanhar o ciclo com a mesma disciplina de testes de software. Caso contrário, o release passa a depender de intuição, não de evidência.

Como montar um pipeline de avaliação que faça sentido

Para um time técnico, a pergunta prática é: o que entra no pipeline? Um bom ponto de partida é separar os testes em quatro blocos: segurança de conteúdo, robustez a instruções conflitantes, uso indevido de ferramentas e comportamento em cenários de dados sensíveis. A partir daí, cada bloco recebe critérios de aceitação, limiares e uma lista de falhas que bloqueiam o release.

Se o sistema é um agente, também vale simular estado de execução, contexto parcial e tentativas de exploração do ambiente. O cuidado da Anthropic com avaliações de cibersegurança mostra que o ambiente não pode ser uma maquete ingênua. O teste precisa ser próximo do mundo real o suficiente para revelar comportamento perigoso, mas controlado o bastante para não expor dados ou acionar integrações reais.

Um esqueleto simples de checklist interno pode ajudar:

Definir quais capacidades representam risco material.
Criar conjuntos de prompts benignos, ambíguos e adversariais.
Medir taxa de recusa, taxa de resposta indevida e consistência entre execuções.
Separar sinal automático de revisão humana quando houver incerteza.
Exigir aprovação explícita antes de liberar mudanças em modelo, prompt ou ferramenta.

Por que isso importa pro dev brasileiro

No Brasil, o problema ganha uma camada extra porque muitos produtos usam dados pessoais, histórico de atendimento ou informações financeiras, o que encosta diretamente na LGPD. Um eval que só mede recusa genérica pode aprovar um modelo que ainda vaza informação sensível em português, com CPF mascarado, nome incompleto ou contexto recuperável por prompt. Isso não é detalhe de UX; é risco regulatório e de confiança.

Há também um aspecto operacional bem brasileiro: grande parte dos times roda stack em cloud com orçamento apertado e janelas de deploy curtas, então o pipeline precisa ser barato e reprodutível. Se a avaliação depende de revisão manual extensa em cada release, ela vira gargalo e perde força. Por isso, faz mais sentido ter uma bateria automática em PT-BR, com expressões regionais, gírias e casos de uso de atendimento local, e reservar a revisão humana para os casos limítrofes.

Em empresas brasileiras de varejo, finanças e SaaS, isso normalmente precisa cobrir português formal, português coloquial e variações regionais do mesmo pedido. Um modelo que parece seguro em inglês pode falhar ao interpretar ironia, redução de contexto ou abreviações comuns no atendimento nacional. O ideal é que os evals imitem esse uso real, não uma versão “limpa” do problema.

Um caminho prático para a próxima semana

Se você já trabalha com LLMs, o próximo passo não é reinventar o stack de avaliação. É pegar um caso de uso, escolher um conjunto pequeno de riscos materiais e transformar isso em testes reprodutíveis. A partir daí, você consegue medir regressão de forma objetiva a cada alteração no modelo, prompt ou ferramenta.

Comece por um domínio: atendimento, busca interna, summarization ou agente com ferramentas. Depois, escreva um conjunto de 20 a 30 casos em PT-BR, incluindo tentativas de jailbreak, instruções conflitantes e entradas com dados sensíveis simulados. Se o sistema falhar em um caso crítico, ele não está pronto para release, mesmo que pareça estável em demos.

Conclusão

As publicações de 2026 deixam uma mensagem consistente: segurança de LLM não é uma camada extra de compliance, e sim parte do próprio mecanismo de release. Anthropic, DeepMind e OpenAI convergem na ideia de que avaliação precisa ser contínua, específica e ligada a decisões concretas de envio para produção.

Para reduzir o risco no seu próximo ciclo, escolha um fluxo real do produto, escreva dez casos adversariais em PT-BR e rode-os antes da próxima mudança de prompt ou modelo.

Conteúdos da DIO para quem quer aprofundar

AWS - Agentes de IA em Campo — Aprenda na prática como utilizar o Amazon Bedrock e a Inteligência Artificial Generativa para criar soluções reais com tecnologias de ponta da AWS, com uma trilha completa que conecta fundamentos de IA, modelos de linguagem de grande escala, agentes autônomos, automação de fluxos e desenvolvimento de projetos aplicados em um único programa.
TOTVS - Fundamentos de Engenharia de Dados e Machine Learning — Prepare-se para construir uma base sólida em Python e bancos de dados, entender os fundamentos de ETL e cloud, e evoluir até Machine Learning, aplicando cada conceito em projetos que simulam desafios reais do mercado de dados.
Riachuelo - Cibersegurança — Prepare-se para construir uma base sólida em Linux e máquinas virtuais, entender os fundamentos de redes e segurança, e evoluir para hacking ético, identificando vulnerabilidades e aplicando boas práticas de proteção.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.