Inteligência de risco de modelos de IA: saiba em quais modelos confiar antes de implantá-los

Quando começamos a pensar em como apresentar o risco de modelos de IA no Evo, a resposta óbvia era aproveitar a forma como avaliamos todo o resto: identificar o problema, atribuir um nível de gravidade e apresentá-lo. Pronto.

A base da nova abordagem é uma pontuação de risco real, construída da maneira como as equipes de segurança já avaliam riscos: Probabilidade × Impacto. A probabilidade vem da Taxa de Sucesso de Ataques (ASR, na sigla em inglês), a proporção de ataques adversariais reais que têm sucesso contra um modelo. O impacto mede o dano causado pelo objetivo do invasor quando o ataque funciona. Combinamos os dois em uma única pontuação de 0 a 1.000 (quanto menor, melhor).

Como os dois fatores são multiplicados, nenhum deles prevalece sozinho: um ataque raro, mas catastrófico, tem seu peso reduzido pela baixa probabilidade, assim como um ataque comum, mas inofensivo, pelo baixo impacto. O que aparece no topo é o que mais importa: os ataques que têm sucesso com frequência e causam danos reais quando funcionam.

Nova metodologia de pontuação de risco

O que diferencia essa abordagem de uma lista de verificação ou de um cartão de segurança de fornecedor é que a ASR vem de testes adversariais reais, como prompts de extração, escalonamento em várias interações, jailbreaks baseados em personas e estratégias de árvore de ataques. Juízes baseados em modelos confirmam se cada ataque teve sucesso de fato.

Esses números não são teóricos nem representam modelos “sem proteção”. Cada ataque do benchmark é executado contra uma defesa básica de reforço do prompt do sistema. Assim, a pontuação de risco reflete o que ainda consegue passar por uma proteção padrão já implementada: os ataques que funcionam em produção, não apenas em laboratório.

O que torna a pontuação prática é seu foco no impacto: ela se baseia no que realmente dá errado quando um ataque funciona, e não apenas em saber se ele teve sucesso. E não para em um número. Evo detalha cada pontuação até chegar ao objetivo específico do invasor, como extrair informações pessoais identificáveis (PII), extrair o prompt do sistema por meio de injeção ou gerar código inseguro. Assim, você vê exatamente onde determinado modelo é vulnerável e pode criar a proteção adequada. Esse nível de precisão é o sinal de que você precisa antes de decidir pela implantação.

Isso faz diferença imediata para as equipes de segurança. Elas veem os riscos de um modelo detalhados por objetivo específico de invasor ao qual ele é vulnerável, em vez de receber um único veredito abstrato de “seguro / inseguro”. Em vez de perguntar se o modelo é seguro em geral, podem começar a perguntar se ele é seguro para o que pretendem criar.

A primeira ideia — identificar o problema, atribuir um nível de gravidade e seguir em frente — tinha um problema sério, e ouvimos isso diretamente dos clientes.

As equipes de segurança analisavam uma descoberta que apontava um problema de “divulgação de informações” em um modelo, e a primeira pergunta era sempre a mesma: o que isso significa na prática e o que devo fazer? O rótulo indicava que havia algo errado. Mas não dizia o quanto era grave, em que contexto, diante de que tipo de ataque nem o que criar para corrigir o problema.

Então, reconstruímos tudo. Veja o que mudou e por quê.

Essa lacuna aparecia repetidamente nas conversas com clientes. Quando começamos a apresentar números concretos — GPT-3.5 com pontuação de 397/1.000 em conteúdo inseguro e GPT-4 com 317/1.000 em viés e equidade —, as equipes pararam de perguntar se um modelo era seguro e começaram a compará-los.

O problema não é a pontuação, e sim o contexto.

A maioria das avaliações de risco de IA trata o modelo como um artefato estático. Executa alguns testes, atribui um rótulo de categoria e publica um cartão de segurança. As equipes analisam o resultado e tentam decidir se devem implantar o modelo.

Mas o risco de IA não funciona assim. O mesmo modelo apresenta riscos fundamentalmente diferentes dependendo de como é implantado. Um agente de programação está sujeito a roubo de credenciais, backdoors, comandos controlados por invasores e envenenamento de dependências. Um chatbot de atendimento ao cliente enfrenta jailbreaks, geração de conteúdo nocivo e extração de prompts. Já um assistente pessoal com acesso a e-mails, calendário e documentos tem uma superfície de ataque completamente diferente.

Uma pontuação de risco que não considera o contexto de implantação não é uma pontuação de risco. É um palpite. Evo incorpora esse contexto ao ponderar o impacto, para que a pontuação reflita como o modelo será realmente usado, e não como se comporta isoladamente.

Há um segundo problema: os ataques indiretos. A maioria das avaliações de modelos se concentra em prompts diretos: alguém digita algo malicioso e verificamos se o modelo resiste. Isso é importante, mas deixa de lado a classe mais perigosa de ataques contra sistemas agentivos: a injeção indireta de prompt insere instruções maliciosas nos dados lidos pelo agente, como um documento recuperado, o resultado de uma ferramenta ou um comentário no código. O usuário nem sequer as vê. O agente as processa como contexto. Se o modelo seguir essas instruções, poderá vazar dados confidenciais, usar ferramentas de forma indevida ou realizar ações não autorizadas. Testes limitados ao modelo nunca detectam isso.

Essa não é uma preocupação teórica. Uma empresa nos procurou com um incidente urgente causado especificamente pelo risco de modelos de LLM, e, em um banco global, um problema semelhante chegou ao CEO. Uma instituição financeira nacional queria ter visibilidade do uso do MCP e inserir proteções. Essas equipes não perguntavam sobre a segurança do modelo em abstrato; queriam saber como ele se comportava em um contexto agentivo específico.

Queríamos que o Risk Intelligence respondesse a outra pergunta: como este modelo se comporta sob ataque da maneira como você realmente planeja implantá-lo?

O que criamos: risco baseado no impacto, até o objetivo do invasor

1. Quais modelos e recursos de IA estão sendo usados na base de código? As equipes de segurança precisam saber onde a IA é usada, quais modelos são chamados e quais recursos ou ferramentas fazem parte do sistema.

2. Como cada modelo se comporta sob ataque? As equipes precisam de perfis de risco baseados em testes adversariais, não em alegações estáticas ou documentação genérica de segurança.

3. Como podemos agir com base nas descobertas? Uma pontuação só é útil se ajudar as equipes a comparar modelos, priorizar proteções e aplicar políticas em aplicações e repositórios.

O principal resultado é uma única pontuação de risco de 0 a 1.000, ponderada pelo impacto real do que um invasor pode conseguir. A Taxa de Sucesso de Ataques é o indicador medido por trás dela.

A pontuação mostra o quanto um modelo está exposto. A taxonomia revela quais ataques contribuíram para esse resultado e por que eles são relevantes para sua implantação.

Evo organiza as descobertas em uma taxonomia de três níveis, baseada no impacto — ou seja, no que realmente dá errado. Uma categoria de impacto de alto nível (como divulgação de informações) se divide em uma subcategoria e, depois, no objetivo específico do invasor, no nível mais detalhado (como extração de PII). Ataques diretos e indiretos são acompanhados como superfícies distintas em toda a taxonomia, porque exigem defesas diferentes. Um agente de programação com alta ASR para injeção indireta por comentários no código precisa de uma proteção diferente da de um chatbot com alta ASR para jailbreaks. A taxonomia deixa essa diferença explícita.

Além disso, cada objetivo de invasor é associado às estruturas com as quais sua equipe já trabalha: OWASP LLM Top 10, OWASP Agentic, MITRE ATLAS e NIST. Assim, uma descoberta não é um rótulo proprietário da Snyk que você precisa traduzir: ela se encaixa diretamente nos padrões que já orientam seu trabalho. Essa associação aparece na aba de perfil de risco, junto com a pontuação.

Essa especificidade permite que as equipes passem da pontuação a um plano de correção. Também permite que Evo conecte as descobertas de risco diretamente à aplicação de políticas, não como um fluxo separado, mas como parte do mesmo processo.

Cobertura de recursos, não apenas de modelos

Rótulos de risco de alto nível não bastam. Informar a uma equipe que um modelo tem um problema de “divulgação de informações” ou “conteúdo inseguro” pode aumentar a conscientização, mas não diz o que corrigir. Uma inteligência de risco útil detalha cada descoberta até chegar ao objetivo específico do invasor. Por exemplo: extração do prompt do sistema por injeção, execução não autorizada de ferramentas, geração de conteúdo nocivo, geração de código inseguro ou exfiltração de dados confidenciais.

Esse nível de detalhe ajuda as equipes a decidir quais proteções criar, quais políticas aplicar e se um modelo é adequado para determinado caso de uso. Também ajuda as lideranças a entender os riscos em diferentes níveis. Uma categoria de alto nível pode mostrar onde a organização está exposta. Uma superfície de ataque mais detalhada pode revelar se os ataques são diretos ou indiretos. Um objetivo específico de invasor pode indicar às equipes de engenharia exatamente o que falhou.

O risco não está apenas nos modelos. Ele está na combinação do modelo, das ferramentas que pode acionar e dos recursos que utiliza. Um modelo com bom desempenho isoladamente pode se comportar de maneira muito diferente quando combinado com uma ferramenta de sistema de arquivos, um ambiente de execução de código ou um repositório de dados confidenciais.

Evo mapeia a cobertura de recursos junto com o risco dos modelos, oferecendo às equipes uma visão clara de quais recursos estão em uso, a quais modelos estão associados e qual é a superfície de ataque combinada. Esse inventário é o que as equipes de segurança precisam antes de tomar decisões de implantação com confiança.

Isso é especialmente relevante para agentes de programação, nos quais o mesmo modelo pode revisar solicitações de pull em um momento e executar comandos de implantação no seguinte. O perfil de risco muda significativamente dependendo do que o modelo está fazendo e das ferramentas às quais tem acesso.

Das evidências à aplicação de políticas

Evo foi criado para ajudar as equipes a entender como os modelos se comportam sob ataque antes de confiar neles em produção. Ao analisar uma base de código, Evo identifica os modelos e recursos de IA em uso e os complementa com perfis de risco baseados em testes adversariais. Esses perfis são construídos com base na Taxa de Sucesso de Ataques, medida contra ataques adversariais reais e ponderada pelo impacto, para que a pontuação reflita as consequências, não apenas a quantidade de ataques.

O Risk Intelligence também organiza as descobertas em uma taxonomia detalhada, que vai de categorias abrangentes a objetivos específicos de invasores. Cada uma é associada ao OWASP LLM Top 10, ao OWASP Agentic, ao MITRE ATLAS e ao NIST. Assim, as equipes podem passar de uma pontuação geral ao padrão exato de ataque que teve sucesso e relacioná-lo à estrutura que já usam em seus relatórios. Como o Risk Intelligence se conecta ao mecanismo de políticas do Evo, as equipes podem transformar insights em ações de aplicação. É possível comparar modelos antes de se comprometer, identificar quais apresentam mais riscos em contextos específicos de implantação, começar com políticas prontas para uso e personalizar limites de acordo com a tolerância a riscos.

A lacuna entre uma pontuação de risco e uma política de aplicação é onde a maioria dos programas de segurança de IA fica estagnada. As equipes recebem uma descoberta, mas não sabem o que fazer com ela.

Evo elimina essa lacuna ao conectar o Risk Intelligence diretamente ao mecanismo de políticas. Quando um modelo apresenta uma pontuação de risco alta para um objetivo específico de invasor ou padrão de ataque, as equipes podem definir limites, aplicar políticas e impedir o uso de modelos de alto risco em contextos sensíveis, tudo no mesmo fluxo de trabalho.

Para os clientes da Snyk, isso amplia uma prática conhecida: descobrir riscos onde os desenvolvedores trabalham, priorizar o que importa e aplicar políticas de forma consistente. A diferença é que a política agora também abrange a seleção de modelos de IA e a configuração de agentes, não apenas o código.

Por que isso importa agora

A segurança de IA não pode depender de suposições. À medida que modelos e agentes passam a fazer parte de aplicações do mundo real, as equipes precisam entender como esses sistemas se comportam sob ataque.

A inteligência de risco de modelos de IA permite que as organizações avaliem o comportamento dos modelos, comparem riscos por caso de uso, priorizem correções e governem a adoção de IA em grande escala. A pergunta já não é simplesmente: “Este modelo é seguro?” A pergunta mais adequada é: “Como este modelo se comporta sob ataque da maneira como planejamos implantá-lo?”

A maioria das equipes com quem conversamos usa modelos de IA que não escolheu explicitamente. Elas os herdaram de um fornecedor, adotaram por meio de uma ferramenta para desenvolvedores ou só os descobriram durante uma auditoria. O novo relatório da Snyk, State of Agentic Adoption, Volume II, analisou dados de telemetria anônimos de AI-BOM de 3.044 organizações. O padrão é consistente: para cada modelo que uma equipe conhece, há cerca de 2,8 outros componentes de IA, bibliotecas, servidores MCP e SDKs em execução sem gerenciamento. E a maioria das organizações não consegue fazer um inventário completo do que tem. Quando uma equipe estimou o esforço necessário, concluiu que um inventário completo de IA levaria de 4 a 5 semanas e envolveria de 10 a 12 pessoas interessadas. O problema de inventariar modelos é real, antes mesmo de começar a conversa sobre pontuação de risco.

A demanda por esse tipo de recurso está crescendo rapidamente. Os recursos aprimorados de AI-SPM já estão disponíveis para clientes atuais. As pontuações de risco baseadas em impacto, calculadas com base na Taxa de Sucesso de Ataques em testes adversariais reais, estarão disponíveis no fim de agosto de 2026. Agende uma demonstração hoje mesmo para saber mais.