F5 AI Red Team: barreira pontual ou prática contínua?

Keiko CheungEstagiário de Marketing de Produto | F5

O que acontece com a pontuação de segurança do seu modelo de IA depois que você para de testá-lo?

A maioria das equipes presume que a resposta seja "nada", pois realizou uma avaliação de red team antes do lançamento, obteve uma boa pontuação e seguiu em frente. No entanto, todas as organizações estão mudando as mesmas três coisas ao mesmo tempo: velocidade, escala e segurança. Elas querem lançar recursos de IA rapidamente, mantê-los confiáveis e fazer as duas coisas em um ecossistema crescente de modelos, agentes e integrações, sem abrir mão de nada.

Mas, na prática, priorizar demais um desses aspectos quase sempre prejudica outro. Uma equipe que lança um modelo atualizado a cada poucas semanas não dispõe de seis semanas para realizar uma análise manual a cada atualização. Por isso, os resultados do mês anterior acabam sendo considerados ainda válidos, ou um modelo não validado permanece exposto. Red teaming costumava ser apenas uma etapa a cumprir antes do lançamento, mas agora os testes estáticos e pontuais já não conseguem acompanhar a rapidez com que as ameaças de IA evoluem.

Testes genéricos e padronizados não conseguem acompanhar os riscos específicos dos fluxos de trabalho, do setor e do contexto regulatório de cada organização. É exatamente por isso que os profissionais precisam de red teaming adaptado ao seu ambiente específico e que alguns clientes já o executam de forma integrada diretamente aos seus pipelines e à sua infraestrutura.

O que as pontuações CASI e ARS realmente medem

Os testes estáticos podem indicar que um modelo foi aprovado em um determinado momento, mas não revelam como ele resiste a ataques persistentes, sofisticados ou em constante evolução. Por isso, a F5 Labs desenvolveu duas métricas objetivas — o Índice Abrangente de Segurança de IA (CASI) e a Pontuação de Resistência Agêntica (ARS) — para oferecer às equipes de segurança uma maneira clara de avaliar modelos, acompanhar a postura de segurança ao longo do tempo e comunicar os riscos à liderança. Veja o que cada uma delas realmente mede.

Índice Abrangente de Segurança de IA (CASI) – O CASI é uma métrica composta desenvolvida para medir a segurança geral de um modelo (metodologia aqui). Ele considera fatores como quantos ataques foram bem-sucedidos, a gravidade das possíveis consequências e o esforço necessário para que um invasor chegasse a esse resultado. Quanto maior a pontuação, mais robusta é a postura geral de segurança do modelo.

Pontuação de Resistência Agêntica (ARS) – A ARS mede a capacidade de todo o sistema de IA de resistir quando uma equipe de agentes autônomos de ataque tenta ativamente comprometê-lo, extrair informações confidenciais, mapear a arquitetura do sistema ou manipular o modelo por meio de engenharia social. Uma ARS alta significa que o sistema mantém suas proteções intactas mesmo sob pressão contínua e direcionada, e não apenas diante de uma única tentativa.

Como estamos vendo CASI, ARS e F5 AI Red Team serem usados na prática

A maioria das equipes de segurança já usa ferramentas tradicionais, como o Teste Estático de Segurança de Aplicações (SAST), para analisar o código-fonte, e o Teste Dinâmico de Segurança de Aplicações (DAST), para testar a aplicação em execução. Nenhuma dessas ferramentas foi projetada para verificar se o modelo de IA subjacente à aplicação pode ser enganado, manipulado ou gradualmente enfraquecido.

Uma pontuação CASI é precisa no momento em que é medida, mas os modelos e as ameaças não ficam parados. Um modelo com pontuação em torno de 93 em um ciclo de testes pode obter de 73 a 77 alguns meses depois. Isso representa uma variação de 15 a 20 pontos sem qualquer alteração no código por parte do cliente, simplesmente porque o modelo subjacente mudou. É por isso que vemos alguns clientes da F5 AI Red Team incorporarem novos testes diretamente ao pipeline de lançamento de CI/CD. Sempre que uma nova versão do modelo ou uma variação com ajuste fino é lançada, ou quando já se passou tempo suficiente, os valores de referência de CASI e ARS são verificados novamente, em vez de se presumir que a pontuação do último trimestre ainda seja válida.

O ranking do CASI acompanha como as pontuações CASI de modelos populares de IA mudaram mês a mês.

Regulamentação de intenções personalizadas

Uma execução padrão do CASI mostra como um modelo se comporta diante de uma ampla biblioteca de ataques conhecidos, mas não detecta automaticamente um risco associado a um novo recurso específico ou a uma exigência legal. Por exemplo, a inclusão de um verificador de sintomas em um chatbot de saúde ou a concessão a um agente financeiro da capacidade de iniciar uma transferência bancária são riscos que um teste genérico não teria motivo para procurar. Em cenários como esses, os clientes criam intenções de ataque personalizadas e com escopo definido em torno de uma funcionalidade específica ou de uma exigência regulatória.

Por exemplo, uma ferramenta multinacional de gestão de contratos pode precisar ser testada em relação às obrigações da Lei de IA da UE em uma região e a um padrão de PII completamente diferente em outra. As intenções personalizadas permitem que as equipes testem exatamente a regra ou o recurso cuja conformidade precisam comprovar, em vez de depender de uma cobertura genérica.

Criando um centro interno de excelência em red teaming

Algumas organizações de maior porte (incluindo pelo menos um grande escritório de advocacia) foram além e criaram uma pequena equipe interna dedicada, cuja função é exclusivamente realizar testes de red team em aplicações de IA para as demais áreas da empresa. Essa equipe conhece o cenário de ameaças da organização e seus resultados de CASI e ARS, além de trabalhar diretamente com as equipes de produto e de gestão de vulnerabilidades à medida que novos recursos de IA são desenvolvidos.

As equipes de segurança compartilham os resultados do CASI com os desenvolvedores de aplicações para deixar claro um ponto simples: nem todos os modelos têm a mesma postura de segurança; presumir o contrário é o que permite que riscos passem despercebidos. Isso elimina uma lacuna de conhecimento entre as equipes de InfoSec e DevOps, que, de outra forma, talvez nem considerassem os riscos no nível do modelo.

A principal conclusão é que o cenário de ameaças está mudando mais rápido do que a maioria das equipes de segurança consegue acompanhar manualmente. O red teaming de IA é uma prática contínua que precisa evoluir no mesmo ritmo dos sistemas que protege. Para isso, é necessário:

• Ser contínuo: Testes manuais que levam semanas não conseguem acompanhar a velocidade com que modelos e agentes mudam.
• Reduza o intervalo entre a identificação de um risco e sua correção: Os resultados do red teaming são incorporados diretamente ao processo de correção, transformando os testes de um relatório estático em um impulsionador de ações mais rápidas e priorizadas contra exposições reais.
• Dê às equipes de segurança uma forma de comprovar o trabalho: Cada avaliação gera uma pontuação CASI e ARS, oferecendo às equipes uma maneira objetiva e comparável de acompanhar a postura de segurança ao longo do tempo e comunicar claramente os riscos à liderança.

O cenário de segurança atual está mudando mais rápido do que qualquer pessoa poderia prever, mas, com o F5 AI Red Team, o CASI e o ARS, as equipes de segurança podem contar com proteções contínuas orientadas por informações sobre ameaças.

Saiba mais acessando as páginas do F5 AI Red Team e dos rankings CASI e ARS do F5 Labs.

Sobre o autor

Keiko CheungEstagiário de Marketing de Produto | F5

Mais publicações de Keiko Cheung