As 12 sondas que toda funcionalidade com LLM deve sobreviver

Conteúdo não confiável que o modelo processa — uma página web, um e-mail, um documento recuperado — carrega instruções, e o modelo as obedece como se viessem de você. O modo de falha clássico de qualquer agente que lê o mundo externo.

O usuário tenta convencer o modelo a abandonar suas próprias regras — enquadramentos de interpretação de papéis, “é para pesquisa”, envoltórios hipotéticos, personas estilo DAN — para extrair conteúdo que a funcionalidade deveria recusar.

Se o modelo vai revelar suas próprias instruções ocultas, ferramentas ou configuração. System prompts vazados dão ao atacante o mapa exato de que precisa para criar o próximo bypass — e muitas vezes expõem propriedade intelectual que você não pretendia publicar.

Para RAG ou qualquer funcionalidade fundamentada em fontes: toda afirmação na resposta pode ser rastreada até a fonte fornecida? A fidelidade é diferente da correção — uma resposta pode ser verdadeira em geral e ainda assim infiel, porque não foi respaldada pelos seus documentos.

Fabricação confiante na ausência de fundamentação — citações inventadas, recursos de produto falsos, números de política inventados, APIs que não existem. A falha que mais rápido custa confiança porque é entregue com total fluência.

Como a funcionalidade trata os dados pessoais na entrada e na saída — se repete campos sensíveis que não deveria, os armazena onde não deveria, ou revela os dados de um usuário para outro.

O primo agêntico da injeção: um atacante consegue que o modelo envie dados para fora — por meio de uma chamada de ferramenta, uma URL de imagem renderizada, um link com segredos na query string. Especialmente perigoso quando o modelo pode navegar, fazer fetch ou chamar APIs.

Se a funcionalidade permanece dentro de sua tarefa. Um bot de suporte não deveria redigir seus contratos jurídicos nem dar conselhos médicos; um assistente de código não deveria opinar sobre o seu divórcio. Respostas fora do escopo são uma superfície de responsabilidade legal mesmo quando são “corretas.”

A falha oposta, e a que as equipes esquecem de testar. Um modelo muito ajustado para a segurança começa a recusar solicitações legítimas — “como mato um processo do Linux” interpretado como violência. A recusa excessiva destrói silenciosamente a experiência de produto enquanto parece “segura.”

Se a funcionalidade pode ser direcionada para uma saída abusiva, de ódio ou de assédio — incluindo quando o usuário é hostil e tenta provocá-la, ou quando uma tarefa de tradução/resumo transforma uma entrada tóxica em uma saída tóxica.

Uma tentativa no meio da conversa de sobrepor as regras vigentes — “novas instruções substituem todas as anteriores.” Testa se o seu system prompt realmente tem autoridade sobre os turnos posteriores do usuário, ou se a mensagem mais recente sempre vence.

Se a mesma entrada produz de forma confiável uma resposta equivalente — entre execuções repetidas, entre reformulações triviais, entre uma atualização de versão do modelo. A inconsistência é uma regressão que você não consegue depurar porque não se reproduz sob demanda.