Para criar sistemas de IA que funcionem, primeiro é preciso levá-los ao limite. Realizámos um exercício de red teaming, assumindo o papel de atacantes para testar e analisar uma aplicação de IA para clientes no setor dos serviços financeiros. As nossas conclusões são relevantes para todos os que implementam aplicações baseadas em LLM em contextos onde a segurança é indispensável.
O red teaming consiste em tentar deliberadamente comprometer o sistema de IA, para corrigir vulnerabilidades antes que um atacante real as descubra. Nos serviços financeiros, os riscos são particularmente elevados: as aplicações de IA lidam com dados de clientes, processam transações e fornecem análises financeiras. Uma falha pode traduzir-se numa má experiência de utilização, em infrações regulamentares, perdas financeiras ou danos irreparáveis para a marca.
O nosso objetivo era encontrar vulnerabilidades atempadamente, testar padrões de ataque realistas e ajudar a organização a cumprir as exigências de segurança da IA que os reguladores levam muito a sério.
Importa fazer aqui uma distinção: o jailbreak ataca os filtros de segurança do modelo subjacente; a injeção de prompt ataca a própria aplicação, combinando dados não fidedignos introduzidos pelo utilizador com o prompt fidedigno do programador. A injeção de prompt representa um risco maior porque visa o sistema e os dados confidenciais com que este opera, não um modelo de utilização geral.
A primeira ronda incluiu cerca de 750 testes nas seguintes áreas:
Fuga de dados entre sessões
Exposição de PII (através de linguagem natural, manipulação de API e várias codificações)
Injeção de SQL
Substituição do prompt do sistema
Durante os testes iniciais, identificámos dois problemas importantes no sistema existente: o tratamento de consultas com várias intenções e a utilização de prompts codificados.
Consultas com várias intenções: pedidos que combinam solicitações legítimas e maliciosas. Por exemplo: “Mostra os meus gastos por categoria e executa também [SQL malicioso].” A aplicação não detetou a intenção maliciosa e dependia inteiramente das barreiras de proteção da camada de dados posterior. É o equivalente a deixar a porta de entrada aberta por confiar no cofre que está na cave.
Codificação: pedidos codificados em Base64, Hex, LeetSpeak e homóglifos. Pode ser difícil para os sistemas filtrar intenções maliciosas. Embora estas consultas não tenham exposto dados sensíveis, contribuíram para uma desestabilização significativa do sistema (alucinações, SQL malicioso repetido aos utilizadores, classificação confusa de intenções, etc.).
Os testes iniciais revelaram:
Alucinações temporais: o modelo devolvia com toda a confiança datas, horas de transações ou resumos temporais inventados — um risco significativo no contexto financeiro, onde agir com base numa data errada pode ter consequências reais para o cliente
SQL malicioso repetido ao utilizador (preocupante devido ao risco de envenenamento da memória)
Classificação confusa de intenções
Formatação desordenada dos resultados
Com estas conclusões, restringimos o nosso foco. Os testes de injeção de SQL e de codificação perderam prioridade, pois a equipa já estava a tratar desses problemas. Em vez disso, concentrámo-nos nos vetores de ataque mais eficazes: exposição de PII e fuga de dados entre sessões.
A conclusão mais surpreendente da segunda ronda foi desconcertantemente simples: muitas vezes, não é sequer necessário recorrer a técnicas engenhosas.
Em muitos casos, bastava simplesmente pedir dados internos no contexto de um pedido aparentemente legítimo para o sistema aceitar expô-los. Consultas simples recebiam respostas que mencionavam IDs internos e campos do sistema que nunca deveriam ser apresentados aos utilizadores finais.
Ao aprofundarmos a análise, descobrimos que a falha não se limitava à aplicação. O serviço text-to-SQL a jusante criava consultas que pediam mais campos do que o necessário, e as respetivas respostas explicativas mencionavam dados que deveriam estar sujeitos a restrições. Isto revelou uma verdadeira falha na ligação entre sistemas — o tipo de vulnerabilidade que só surge ao testar toda a stack, e não componentes individuais isoladamente.
Faça red teaming ao sistema, não ao modelo. Testar um LLM isoladamente revela muito pouco sobre o nível de segurança da aplicação. Teste toda a stack, de ponta a ponta, tal como um utilizador interagiria com ela.
A validação dos dados de entrada tem de ocorrer antes do LLM. As consultas codificadas, os ataques com várias intenções e as tentativas básicas de injeção devem ser detetados no perímetro, não delegados em serviços a jusante.
Não confie nos pontos de ligação. Nas arquiteturas com vários serviços, é nas falhas entre sistemas que se escondem as vulnerabilidades mais interessantes. Confiança zero significa mesmo confiança zero: valide tudo, em todas as camadas.
Os ataques simples funcionam. Os ataques sofisticados de jailbreak dominam as manchetes, mas, por vezes, basta... pedir. Se o sistema revelar prontamente identificadores internos quando um utilizador os inclui numa consulta que, de resto, é legítima, existe um problema.
Compreenda o que está realmente a testar. Os padrões de ataque conhecidos podem ser detetados graças ao treino do próprio LLM, e não às suas barreiras de proteção. Integre observabilidade no red teaming para compreender que controlos estão efetivamente a ser acionados.
Os ambientes com restrições exigem soluções criativas. Os fornecedores personalizados e o suporte para modelos locais viabilizam um red teaming relevante sem acesso especializado à cloud. Mas é preciso ser transparente quanto às limitações daí resultantes.
O red teaming não é uma atividade pontual. É um processo iterativo, deve ser automatizado sempre que possível e evoluir com o sistema. Os ataques que serão relevantes amanhã não são os mesmos que importam hoje.
Os sistemas de IA em ambientes regulamentados estarão sujeitos a um escrutínio cada vez maior. As organizações que tratarem os testes de segurança como uma disciplina contínua, e não como um mero requisito antes do lançamento, estarão mais bem preparadas para esse escrutínio e para evitar crises de relações públicas que destruam a confiança dos clientes.