Como testar a segurança de uma IA antes de colocá-la em produção
Verificar se uma inteligência artificial responde corretamente não basta para concluir que ela está pronta para uso. Antes do lançamento, é necessário avaliar como o sistema se comporta diante de usuários mal-intencionados, documentos contaminados, respostas manipuladoras de ferramentas e integrações com permissões além do necessário.
Uma sequência de tentativas de jailbreak pode revelar algumas fragilidades, mas não representa uma avaliação completa. Uma aplicação de IA envolve muito mais do que o modelo: inclui dados, mecanismos de busca e recuperação (RAG), APIs, identidade, armazenamento, ferramentas, credenciais, infraestrutura e regras de negócio. Os testes precisam considerar todas essas peças e as interações entre elas.
Comece pelo modelo de ameaças
Antes de organizar uma equipe de red team, é importante definir o que a aplicação faz e quais danos poderiam ocorrer se algo desse errado. Um chatbot que responde a perguntas frequentes tem uma exposição diferente da de um agente interno com acesso a e-mail, sistemas de gestão e operações administrativas. Da mesma forma, um classificador de documentos não deve ser avaliado como um agente capaz de executar código.
O modelo de ameaças deve identificar os ativos a proteger, os dados sensíveis, os tipos de usuário, as fontes de informação, as ferramentas disponíveis, os mecanismos de autenticação e autorização e os possíveis impactos de uma falha. Essa análise torna o red teaming mais direcionado: em vez de reunir prompts provocativos sem um objetivo claro, a equipe tenta explorar caminhos que possam causar consequências reais.
Teste as fontes de informação e as integrações
Em aplicações que usam RAG, o conteúdo recuperado pode conter instruções maliciosas ou enganosas. Em agentes que navegam na internet, o risco pode estar nas páginas acessadas. Em sistemas conectados a ferramentas, uma resposta manipuladora pode surgir do próprio retorno da ferramenta. E, em aplicações que processam e-mails, mensagens recebidas também podem servir de vetor de ataque.
O objetivo é verificar se conteúdo não confiável consegue influenciar ações privilegiadas. A IA consegue acessar documentos de outra pessoa ou área? A busca retorna trechos fora do escopo autorizado? Informações sigilosas aparecem nos registros da aplicação? Dados são enviados a serviços externos sem necessidade? O histórico de uma sessão pode contaminar a experiência de outro usuário?
Essas verificações são fundamentais porque muitos riscos não estão no modelo em si, mas nos sistemas de dados que o cercam. Uma configuração incorreta de acesso, por exemplo, pode fazer com que a IA apresente informações que o usuário não teria permissão para consultar diretamente.
Não confie apenas no modelo para autorizar ações
Quando um agente pode acionar ferramentas, cada operação precisa ser validada por controles independentes. A API não deve presumir que uma solicitação é segura apenas porque veio do modelo. É necessário testar parâmetros inesperados, chamadas repetidas, tentativas de ampliar permissões, mudanças de identidade e pedidos para executar tarefas administrativas a partir de um contexto sem autorização.
Autenticação e autorização cumprem papéis diferentes. A primeira confirma quem é o usuário; a segunda determina quais ações ele pode realizar. Portanto, estar conectado não deve dar acesso automático a todas as funções ou dados disponíveis ao agente. Restrições importantes precisam ser aplicadas no sistema que executa a ação, e não depender apenas da capacidade do modelo de interpretar instruções.
Combine segurança de IA com AppSec
Aplicações com IA continuam sujeitas a vulnerabilidades tradicionais. Containers, bibliotecas, APIs, armazenamento, credenciais e redes precisam passar pelos controles de segurança habituais. Um sistema pode ser vulnerável a prompt injection e, ao mesmo tempo, apresentar uma falha de SSRF. Também pode ter respostas bem controladas, mas permitir acesso indevido a registros por meio de uma API vulnerável a IDOR.
Por isso, os testes específicos de IA complementam, mas não substituem, a segurança de aplicações. A avaliação deve abranger tanto a manipulação de instruções e dados quanto os problemas de configuração, exposição de segredos, controle de acesso e proteção da infraestrutura.
Use uma abordagem contínua de avaliação
O modelo de Teste, Avaliação, Verificação e Validação (TEVV), adotado pelo NIST, ajuda a tratar a segurança como um processo ao longo do ciclo de vida do sistema. A equipe precisa registrar os cenários avaliados, reproduzir as falhas, corrigir suas causas e testar novamente. Uma lista de prompts que provocaram respostas inadequadas tem pouco valor se não resultar em melhorias verificáveis.
Também é necessário definir antecipadamente o que significa “passar” nos testes. Qual nível de exposição de dados é inaceitável? Que ações exigem confirmação humana? Qual taxa de falso positivo pode ser tolerada? Quais falhas impedem o lançamento? Sem critérios objetivos, a decisão tende a se tornar subjetiva justamente quando a pressão para colocar o produto no ar é maior.
Inclua usuários legítimos nos cenários adversariais
Nem toda tentativa de abuso vem de alguém externo ou sem acesso ao sistema. Uma pessoa autenticada pode tentar consultar informações de outra equipe, usar uma ferramenta para contornar uma aprovação ou induzir o agente a executar uma tarefa fora de seu escopo. Testar esses casos ajuda a descobrir excessos de confiança em aplicações internas.
A avaliação também deve considerar diferenças entre perfis e níveis de acesso. Um mesmo pedido pode ser permitido para uma função e proibido para outra. É importante confirmar que o sistema mantém essa distinção nas respostas, na recuperação de documentos e em cada chamada de ferramenta.
Prepare-se para mudanças depois do lançamento
Um ambiente de homologação não reproduz perfeitamente o volume, os dados e o comportamento dos usuários em produção. Além disso, modelos podem ser atualizados, documentos incorporados ao RAG podem mudar e novas ferramentas podem ser conectadas. Uma aprovação obtida antes do lançamento, portanto, não garante segurança permanente.
O monitoramento pós-implantação deve procurar sinais de abuso, vazamentos, chamadas fora do padrão e alterações inesperadas no comportamento. Mudanças relevantes no modelo, nas permissões, nas fontes de dados ou nas integrações devem levar a novas avaliações. Quando possível, as equipes também precisam contar com mecanismos para limitar ações, revogar acessos ou interromper temporariamente uma funcionalidade.
Antes de liberar uma IA, verifique se os dados estão isolados por usuário e finalidade, se as permissões são mínimas, se as ferramentas validam cada operação e se os registros não armazenam informações sensíveis sem necessidade. Simule ataques contra os canais que a aplicação realmente utiliza – documentos, páginas, e-mails e respostas de APIs – em vez de se limitar a testar o chat.
Uma IA segura não é apenas aquela que evita respostas inadequadas. É um sistema que protege dados, respeita limites de autorização, resiste à manipulação de suas fontes e permite identificar e corrigir falhas. O melhor momento para descobrir esses problemas é antes de a aplicação receber acesso a usuários e informações reais.