Por que a cibersegurança clássica não protege sistemas de IA

As empresas protegem modelos de IA com ferramentas clássicas de DevSecOps, mas isso é criticamente insuficiente. Os ataques a modelos de linguagem e agentes de IA não acontecem na infraestrutura, e sim nas camadas de dados, contexto e lógica do próprio modelo: prompt injection, envenenamento de dados, manipulação do comportamento dos agentes. Ainda não existe um padrão único de segurança para IA, mas o setor já formou referências de trabalho: o OWASP Top 10 para LLMs e aplicações agênticas, o mapa de riscos SAIF do Google e a base de ataques MITRE ATLAS. Essas ferramentas bastam para montar uma proteção prática sem esperar por um «GOST» geral.

Processado por IA de Habr AI; editado por Hamidun News
Por que a cibersegurança clássica não protege sistemas de IA
Fonte: Habr AI. Colagem: Hamidun News.
Ouvir artigo

Metade das empresas que implantaram um agente de IA ou um modelo de linguagem o protege exatamente como um microsserviço comum: com firewall, scanner de dependências e política de acessos. Parece razoável, mas na prática é como instalar uma porta de aço numa casa a que falta uma parede. Boris Matsakov, engenheiro de Data Science da Cloud.ru, formulou com precisão, em sua análise no Habr, um problema que o setor prefere continuar ignorando: o DevSecOps clássico e a segurança de IA são dois perímetros diferentes, e um não substitui o outro.

A raiz da divergência é simples e, ao mesmo tempo, fundamental. O DevSecOps foi construído ao longo de décadas em torno de um modelo de ameaças bem compreendido: há um perímetro, há dependências, há infraestrutura e direitos de acesso. Proteja cada uma dessas camadas e o sistema estará seguro.

Mas os modelos de IA são atacados de maneira completamente diferente. O prompt injection permite que um invasor assuma o controle do comportamento do modelo por meio de um texto especialmente elaborado. O envenenamento dos dados de treinamento distorce a própria lógica de decisão muito antes de o modelo chegar à produção.

A manipulação de contexto faz um agente de IA executar ações que seus criadores não previram. Nenhum desses ataques toca a infraestrutura no sentido tradicional: eles atingem aquilo que faz da IA uma inteligência artificial, ou seja, os dados e a capacidade do modelo de interpretá-los.

O problema é especialmente agudo nos sistemas agênticos: agentes de IA autônomos que não apenas geram texto, mas tomam decisões, chamam APIs externas, trabalham com bancos de dados e executam cadeias de ações. Se um modelo de linguagem comum pode ser comparado, de forma aproximada, a um consultor que dá conselhos, um agente de IA é um funcionário com acesso aos sistemas corporativos. Comprometer esse funcionário via prompt injection significa obter não só uma resposta errada, mas impacto real nos processos de negócio. E aqui a proteção de infraestrutura é impotente por definição: do ponto de vista do firewall, o agente faz exatamente o que lhe é permitido, enviar requisições e receber respostas.

A boa notícia é que o setor não está parado. Nos últimos um ano e meio, surgiram vários documentos de referência sérios que permitem montar um sistema de proteção prático. A OWASP publicou duas listas Top 10 de vulnerabilidades separadas, uma para aplicações com LLMs e outra para sistemas agênticos.

O Google apresentou o SAIF, o Secure AI Framework, com um mapa de riscos que ajuda as empresas a avaliar ameaças de forma sistemática. A MITRE expandiu sua lendária base ATT&CK no projeto ATLAS, que cataloga técnicas de ataque específicas a sistemas de aprendizado de máquina. Cada ferramenta cobre um nicho: a OWASP traz um checklist de vulnerabilidades concretas, o SAIF uma metodologia de avaliação de riscos e o ATLAS uma linguagem para descrever ataques e construir modelos de ameaças.

A má notícia é que ainda não existe um padrão único. Não há «GOST», nem norma ISO, nem framework obrigatório que prescreva às empresas um conjunto específico de medidas. Cada equipe interpreta a seu modo o que é um «sistema de IA seguro», e essa interpretação costuma se resumir ao que os engenheiros de DevSecOps da casa já sabem fazer. Isso cria uma perigosa ilusão de proteção: formalmente todos os procedimentos são cumpridos, os scanners estão verdes, os acessos estão segregados, mas o modelo continua vulnerável a ataques que a equipe de segurança pode nem suspeitar que existam.

A conclusão prática para as empresas é esta: a segurança de IA deve ser tratada como um perímetro separado, sobreposto ao DevSecOps existente, e não embutido nele. Isso significa competências específicas na equipe, um conjunto próprio de ferramentas de teste (red teaming de modelos, verificação de prompt injection, auditoria dos dados de treinamento) e um modelo de ameaças próprio, construído considerando as particularidades do aprendizado de máquina. Os frameworks OWASP, SAIF e ATLAS oferecem base suficiente para não reinventar a roda.

O setor de segurança de IA está hoje mais ou menos onde a cibersegurança clássica estava no início dos anos 2000: as ameaças são reais, as ferramentas estão surgindo, mas ainda não há padrões maduros. As empresas que começarem a construir esse perímetro agora terão não só uma vantagem técnica, mas também competitiva, porque em dois ou três anos os reguladores inevitavelmente virão com exigências, e será mais fácil se adaptar para quem já estiver preparado.

História
ZK
Zhemal Khamidun — CPO da Alpina Digital, gerente de produto do AlpinaGPT. Cria produtos de IA desde 2019. O Hamidun News é um projeto pessoal que virou um agregador em produção com mais de 6.000 leitores.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
O que você acha?
Carregando comentários…