A explosão do uso de IA desde 2020 não tem precedentes. Em termos de adoção, a IA avança mais rapidamente do que a nuvem, os dispositivos móveis e, certamente, do que a Internet avançou. A Gartner prevê que mais de 80% das empresas implantarão IA este ano.
Ao classificarmos a jornada de adoção da IA de uma empresa, observamos que a maturidade se divide em quatro categorias, que muitas vezes ocorrem em paralelo, e não de forma sequencial:
- A categoria 1 abrange IA de uso geral e produtividade — pense em funcionários usando ChatGPT, Gemini, Copilot etc.
- A categoria 2 ocorre quando as organizações têm casos de uso internos e desenvolvem chatbots personalizados para áreas como RH ou TI.
- A categoria 3 inclui casos de uso externos, como a criação de aplicações de IA generativa voltadas ao público, incluindo chatbots de atendimento ao cliente.
- A categoria 4 consiste em fluxos de trabalho agênticos, compostos por sistemas complexos que realizam ações de forma autônoma em nome dos usuários.
É nessas três últimas categorias que a segurança se torna crucial. Isso porque as organizações estão desenvolvendo softwares complexos com base em modelos de IA não determinísticos, criando vulnerabilidades que os firewalls tradicionais simplesmente não conseguem detectar.
“Está claro que as empresas que implementam IA precisam de testes automatizados rápidos contra vulnerabilidades conhecidas apenas para estabelecer uma linha de base.”
A segurança é sempre uma prioridade para as empresas, mas, com a IA, a preocupação é diferente — trata-se de um ponto cego. Os líderes de segurança passaram 20 anos implantando e configurando firewalls de aplicações web (WAFs) para proteger suas aplicações web, seus sites e até mesmo suas APIs. No entanto, embora sejam extremamente úteis, os WAFs têm limitações quando se trata de IA. O processamento de linguagem natural usado na IA pode ser problemático para a detecção tradicional dos WAFs; em termos simples, não é possível proteger uma conversa com um firewall. As empresas precisam de uma nova abordagem para proteger seus aplicativos e APIs onde quer que estejam e garantir a segurança de sua IA em todos os lugares.
É por isso que 75% dos CISOs relatam incidentes de segurança envolvendo IA; suas proteções atuais simplesmente não foram projetadas para detectar essas ameaças. Isso também explica por que 91% já detectaram tentativas de ataque à sua infraestrutura de IA e por que impressionantes 94% agora priorizam os testes de seus sistemas de IA.
Novas categorias de ataques cognitivos
Na era da IA, as organizações não estão lidando apenas com vulnerabilidades de código. Elas enfrentam categorias totalmente novas de ataques cognitivos, incluindo:
- Injeção de prompt, tanto direta quanto indireta
- Envenenamento de dados durante a fase de treinamento
- Jailbreak sofisticado técnicas como ataques de linguagem simbólica
- Compressão de tokens, em que invasores ocultam instruções maliciosas em formatos que os modelos de IA conseguem ler, mas os humanos não
As proteções de segurança tradicionais lidam com entradas determinísticas, mas a injeção de prompts e outros ataques em linguagem natural são problemas semânticos, não problemas de correspondência de padrões. Não se trata de falhas isoladas, mas de riscos empresariais sistêmicos introduzidos por arquiteturas orientadas por IA.
Há muitos exemplos reais de como a IA está mudando o modelo de ameaças. Uma violação ocorrida no último verão em um fornecedor internacional de software teve origem em uma falha na lógica de isolamento entre locatários no servidor MCP que permitiu a exposição de dados entre organizações. Esse é um bug clássico de sistemas multilocatário — mas é mais perigoso em sistemas de LLM porque os dados vazados aparecem em linguagem fluente, o que dificulta muito mais sua detecção.
Enquanto isso, um incidente em uma empresa global de tecnologia revelou uma falha diferente: limites de confiança comprometidos. Uma injeção de prompt redefiniu a função de um chatbot, e os sistemas de back-end confiaram nas solicitações de ferramentas feitas por ele sem aplicar a autorização no lado do servidor. O problema não foi o modelo ignorar as regras, mas a autorização ter sido delegada a ele de forma inadequada.
Esses são apenas dois exemplos que fazem parte de um cenário muito mais amplo de riscos emergentes. O setor está correndo para categorizar essas vulnerabilidades de IA. Estão surgindo frameworks como o OWASP Top 10 para Aplicações de Modelos de Linguagem de Grande Escala (LLM), o OWASP Top 10 para Aplicações Agênticas , o Mitre Atlas e o Framework de Gestão de Riscos de IA do NIST, mas ainda não temos um banco de dados definitivo nem um padrão unificado que estabeleça como é, de fato, uma solução segura.
A abordagem antiga não consegue acompanhar
A pressão que o setor enfrenta atualmente para implementar IA é uma questão de sobrevivência. Os desenvolvedores estão usando IA para escrever código 10 vezes mais rápido do que nunca; as organizações estão literalmente lançando novos recursos — e até mesmo produtos — da noite para o dia.
Ao mesmo tempo, a regulamentação está acelerando esse processo no âmbito da conformidade. A Lei de IA da UE, por exemplo, exige explicitamente testes adversariais para sistemas de IA de alto risco e de uso geral. Na prática, isso significa que o red teaming desenvolvido especificamente para esse fim— que testa sistemas de IA por meio de ataques adversariais simulados — deve agora ser considerado um componente essencial da estrutura de segurança de IA, de modo a enfrentar os desafios reais com que esses sistemas se deparam.
À medida que os CISOs e as equipes de segurança tentam proteger mudanças que ocorrem na velocidade das máquinas, a sensação pode ser a de tentar conter um tsunami com um balde. A conta não fecha. A velocidade é incompatível. A superfície de ataque da IA é fundamentalmente diferente, e as abordagens antigas não conseguem acompanhar.
Está claro que o red teaming tradicional é ineficaz e que o red teaming de IA é necessário para resolver o conflito entre velocidade e controle. Com base em conversas com clientes e no trabalho de ajudá-los a proteger seus sistemas de IA, há quatro áreas principais que precisamos considerar:
Em primeiro lugar, a evolução das ameaças: os ataques de IA evoluem mais rapidamente do que os conjuntos de testes estáticos. Assim que as verificações são automatizadas, o modelo de IA ou o ataque muda, e as equipes de segurança acabam tendo que manter os testes em vez de reduzir os riscos.
Em segundo lugar, a complexidade dos agentes: como os agentes de IA não são sistemas determinísticos, quando você adiciona recuperação de informações, ferramentas e memória, as combinações se tornam praticamente infinitas. Você não está mais testando código, mas sim uma conversa que muda de acordo com o contexto.
Em terceiro lugar, automação e escala: a análise manual por equipes vermelhas não é escalável para esses sistemas. Um chatbot pode ser gerenciável. Centenas ou milhares de chatbots, não. Não é possível depender de pessoas para reproduzir milhares de conversas adversariais sempre que o modelo ou o prompt do sistema for atualizado.
Por fim, relatórios que permitam tomar medidas: as constatações devem ser reproduzíveis e viabilizar ações concretas. “O bot se comportou mal” não é uma informação que permita agir. Os engenheiros precisam dos parâmetros da conversa e das condições que desencadearam o comportamento; caso contrário, as correções e a remediação ficarão paralisadas.
Garantindo que a IA se comporte conforme o esperado, mesmo sob ataque
Vamos validar isso com alguns exemplos concretos. Um de nossos clientes é um banco global que opera em um ambiente altamente regulamentado. Quando começamos a trabalhar com esse cliente, ele tinha mais de 50 casos de uso de IA nas áreas de RH, compras e segurança cibernética, mas não conseguia implementar nenhum deles porque não conseguia comprovar a segurança para seus auditores internos.
Os testes de intrusão em IA com o F5 AI Red Team forneceram ao banco as evidências necessárias para entender como seus sistemas de IA realmente se comportavam — onde poderia haver vazamento de dados, como prompts poderiam ser explorados e onde os controles falhavam em seu ambiente.
Este cliente está usando as descobertas do AI Red Team para aprimorar sua postura defensiva com controles de segurança personalizados por meio do F5 AI Guardrails. Essa combinação permite que o banco amplie o uso da IA em toda a empresa com confiança em sua postura de segurança e em seu programa de governança.
No setor público, a necessidade deixa de ser a realização de testes voluntários e passa a ser obrigatória. Orientados por órgãos como o NIST e a CISA, os órgãos do setor público estão adotando medidas, como testes de estresse adversariais, para identificar riscos críticos para a missão, como o uso de dados biológicos como arma. Nesse contexto, o red teaming de IA não se limita à redução de riscos; trata-se de manter a continuidade da missão e a autorização para operar.
Seja para proteger dados de clientes ou serviços públicos, o requisito é o mesmo: uma garantia contínua, respaldada por evidências, de que os sistemas de IA se comportem conforme o esperado, mesmo quando alguém tenta comprometê-los.
Eliminando as lacunas de conformidade
Está claro que as empresas que implementam IA precisam de testes automatizados rápidos contra vulnerabilidades conhecidas apenas para estabelecer uma linha de base. O contexto é a nova superfície de ataque; defesas estáticas falham contra ataques de agentes de IA, portanto, as organizações precisam testar as cargas de trabalho, não apenas os modelos.
Essas são as lacunas do mundo real que as equipes de segurança estão tentando eliminar neste exato momento e os motivos pelos quais o red teaming de IA está ganhando destaque. Nesse cenário, a conformidade é uma vantagem competitiva. Com os relatórios adequados, a segurança deixa de ser um obstáculo e passa a ser o fator que viabiliza a chegada mais rápida da IA de uma empresa ao mercado.
Nesse cenário, o grande número de empresas que planejam implementar IA este ano pode fazê-lo com confiança, em vez de receio, independentemente do estágio em que estejam nessa jornada.
Saiba mais sobre como testar seus sistemas de IA aqui.
Veja os especialistas da F5 demonstrarem como o AI Red Team acelera os testes adversariais contínuos aqui.
Sobre os autores
Publicações relacionadas no blog
IA agêntica em cibersegurança: promessas e riscos
Saiba por que o uso de IA agêntica na cibersegurança é essencial para combater ameaças impulsionadas por IA e por que os agentes também criam novos riscos para as empresas.
Como os clientes da F5 no setor financeiro lidam com a soberania digital sem desacelerar a inovação
Como é a soberania digital na prática? Dois projetos recentes da F5 com clientes mostram como diferentes empresas estão enfrentando esses desafios.
Soberania operacional: construindo resiliência em um mundo imprevisível
Para muitas organizações, a questão já não se resume apenas a controlar os dados. Trata-se de manter a capacidade de operar, adaptar-se e se recuperar à medida que as leis e as condições evoluem.
Segurança de IA com evidências: o que levaremos ao Gartner SRM
Antes de sua sessão no Gartner SRM, o vice-presidente sênior de Marketing de Produtos da F5 explica como a F5 ajuda as organizações a proteger a IA em três etapas práticas.
Gestão de riscos de IA: como as proteções podem ajudar a mitigá-los
O risco da IA é impulsionado por comportamentos probabilísticos e pela explicabilidade limitada, não apenas por falhas de segurança. Uma gestão eficaz exige controle operacional contínuo.
Lei de IA do Colorado (SB 205): o que as empresas precisam saber antes de 2026
A SB 205 do Colorado, a lei pioneira do estado sobre inteligência artificial, foi sancionada pelo governador Jared Polis em 17 de maio de 2024. O projeto de lei estabelece requisitos para que as empresas que utilizam IA implementem controles destinados a proteger os cidadãos do Colorado.