Como testar a segurança de uma IA antes de colocá-la em produção
Avaliar se uma inteligência artificial responde corretamente não basta para determinar se ela está pronta para uso real. Antes do lançamento, é necessário verificar como o sistema se comporta diante de usuários mal-intencionados, documentos manipulados, respostas perigosas de ferramentas e falhas nas integrações.
Uma solução de IA não é apenas um modelo. Pode incluir mecanismos de busca e recuperação de dados (RAG), APIs, contas e permissões, bancos de dados, serviços externos, credenciais e infraestrutura. Cada componente amplia a superfície de ataque. Por isso, testes limitados a tentar algumas frases de jailbreak deixam de lado riscos importantes.
Comece pelo modelo de ameaças
Antes de organizar um red team, defina o que a aplicação faz e quais danos poderiam ocorrer. Um chatbot que responde a perguntas frequentes tem um perfil de risco diferente de um agente conectado ao ERP, ao e-mail ou a ferramentas capazes de executar ações.
O mapeamento deve identificar os ativos que precisam de proteção, os dados tratados, os tipos de usuário, as fontes de informação, as ferramentas disponíveis e as permissões concedidas. Também é importante registrar os caminhos de autenticação e autorização, além das consequências de uma resposta ou ação indevida.
Sem essa análise, o red team pode se resumir a experimentar comandos criativos, sem testar os cenários mais relevantes para o negócio.
Teste as fontes de informação
Instruções maliciosas nem sempre aparecem diretamente na conversa. Elas podem estar escondidas em documentos consultados por um sistema RAG, páginas abertas por um agente, mensagens de e-mail ou respostas recebidas de ferramentas.
O objetivo é avaliar se o conteúdo não confiável consegue influenciar o modelo a ultrapassar limites de acesso ou executar ações privilegiadas. Em sistemas com recuperação de documentos, por exemplo, verifique se a aplicação entrega informações pertencentes a outro usuário ou recupera trechos fora do escopo permitido.
Também examine se dados confidenciais aparecem em registros, se são enviados a serviços externos sem autorização ou se a memória de uma sessão acaba misturando informações de usuários diferentes.
Não confie no modelo para autorizar ações
Quando um agente pode chamar ferramentas, cada operação precisa ter controles próprios. A API ou o serviço chamado deve validar identidade, permissões e parâmetros, em vez de presumir que uma solicitação é segura apenas por ter sido gerada pela IA.
Inclua testes com parâmetros inesperados, chamadas repetidas, tentativas de ampliar o escopo e mudanças de identidade. Verifique ainda se uma instrução recebida em contexto não confiável consegue iniciar uma ação administrativa ou contornar uma etapa de aprovação.
A autenticação confirma quem está usando o sistema, mas não significa que essa pessoa tenha autorização para realizar qualquer operação. Esse princípio é especialmente importante em aplicações internas, nas quais a presença de um usuário autenticado pode gerar confiança excessiva.
Combine segurança de IA e AppSec
Controles específicos para modelos não substituem as práticas tradicionais de segurança de aplicações. APIs, bibliotecas, contêineres, armazenamento, segredos e configurações de rede continuam sujeitos a vulnerabilidades conhecidas. Um sistema pode resistir a tentativas de manipular prompts e, ao mesmo tempo, ter uma falha de controle de acesso ou uma configuração insegura.
Por isso, a avaliação deve cobrir tanto os riscos relacionados ao comportamento do modelo quanto as falhas convencionais da aplicação e da infraestrutura. Testar a segurança de IA significa analisar o conjunto, e não apenas a interface de conversa.
Estruture a avaliação com evidências
Uma abordagem útil é organizar o trabalho como um ciclo de teste, avaliação, verificação e validação (TEVV). Na prática, isso significa documentar os cenários, reproduzir os problemas encontrados, corrigir suas causas e repetir os testes para confirmar que a solução funcionou.
Uma coleção de prompts que provocam respostas indesejadas tem pouco valor se a equipe não consegue transformar as descobertas em mudanças verificáveis. Registre as condições do teste, o resultado esperado, o comportamento observado, o impacto e a correção aplicada.
Defina também critérios de aprovação antes do lançamento. Quantos casos de exposição de dados são aceitáveis? Quais ações exigem confirmação humana? Que níveis de erro ou de falso positivo são tolerados? Quais falhas devem bloquear a entrada em produção? Sem respostas acordadas, a decisão tende a se tornar subjetiva justamente quando há pressão para lançar o produto.
Inclua cenários de abuso por usuários legítimos
Nem toda ameaça vem de alguém externo ou sem credenciais. Um usuário autorizado pode tentar consultar informações de outra área, usar uma ferramenta para sair do escopo previsto ou explorar o agente para evitar um processo de aprovação.
Esses testes ajudam a identificar problemas de autorização e de segregação de funções que podem passar despercebidos em avaliações focadas apenas em ataques anônimos. Considere diferentes perfis, níveis de acesso e situações em que a solicitação parece legítima, mas ultrapassa as permissões concedidas.
Planeje o monitoramento depois do lançamento
A homologação não reproduz por completo os dados, os usuários e as condições reais de operação. Além disso, modelos, documentos recuperados e ferramentas podem mudar com o tempo. Uma avaliação aprovada antes do lançamento, portanto, não garante que o sistema permanecerá seguro indefinidamente.
Monitore comportamentos inesperados, tentativas de acesso indevido, chamadas de ferramentas fora do padrão e possíveis exposições de dados. Defina responsáveis e procedimentos para investigar incidentes, suspender funções de risco e atualizar controles quando a aplicação ou suas integrações forem alteradas.
A segurança também precisa ser reavaliada após mudanças relevantes, como a troca de modelo, a inclusão de uma nova fonte de RAG ou a ampliação das permissões de um agente. Cada alteração pode criar caminhos de ataque que não existiam na versão anterior.
Antes de liberar uma IA, a equipe deve conseguir demonstrar não apenas que o sistema funciona, mas também que seus limites foram testados, que falhas críticas foram corrigidas e que existem mecanismos para detectar problemas em produção. O objetivo não é provar que a aplicação nunca será atacada: é reduzir riscos de forma mensurável e limitar o impacto quando algo sair do esperado.