A publicação da ISO/IEC 27090:2026, em 14 de outubro, acrescenta uma referência específica à discussão sobre como proteger sistemas de inteligência artificial. A norma não substitui o Sistema de Gestão de Segurança da Informação nem cria, por si só, uma nova certificação para empresas. Seu papel é mais direcionado: ajudar organizações a compreender, detectar e mitigar ameaças que atingem dados de treinamento, modelos e processos de operação da IA.
O documento, intitulado Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems, foi desenvolvido no âmbito do comitê ISO/IEC JTC 1/SC 27 e se aplica a organizações públicas e privadas, de qualquer porte, que desenvolvam ou utilizem inteligência artificial. São 56 páginas dedicadas a uma preocupação que ganhou dimensão prática: uma aplicação pode ter infraestrutura protegida, controles de acesso e monitoramento convencionais e, ainda assim, apresentar riscos próprios do funcionamento de seus modelos.
O problema não termina na infraestrutura
Um banco de dados exposto, uma credencial comprometida ou um servidor desatualizado continuam sendo problemas conhecidos de Segurança da Informação. Nos sistemas de IA, porém, a superfície de ataque também inclui os dados usados para ensinar o modelo, os conjuntos recuperados durante uma consulta, as instruções recebidas em linguagem natural, os parâmetros do modelo e as integrações que permitem executar ações. Essa combinação exige avaliar não apenas se o ambiente está disponível e protegido, mas se o comportamento do sistema pode ser induzido, alterado ou explorado.
Entre os exemplos destacados pela ISO estão o data poisoning, em que dados manipulados comprometem o treinamento ou a atualização de um modelo, e o roubo de modelos, que pode ocorrer inclusive por meio de consultas aparentemente legítimas. A diferença é importante: um atacante não precisa necessariamente invadir o servidor para tentar extrair informações sobre o funcionamento de um modelo ou influenciar suas respostas. Dependendo da arquitetura, a exploração pode ocorrer na própria interface autorizada de uso.
O risco também não se encerra quando o modelo entra em produção. Dados recebidos durante a operação podem alimentar ciclos posteriores de ajuste ou retreinamento. Se esse material estiver contaminado, o problema pode ser incorporado a uma versão futura do sistema. Por isso, a proteção deve acompanhar a procedência dos dados, as mudanças de versão, os testes e as decisões sobre quais informações podem voltar ao processo de aprendizagem.
Como a ISO/IEC 27090 se relaciona com a 27001 e a 42001
A ISO/IEC 27001 estabelece requisitos para implementar, manter e melhorar continuamente um Sistema de Gestão de Segurança da Informação (SGSI). Sua lógica é organizacional: identificar riscos, definir responsabilidades, selecionar controles e demonstrar que existe um processo de gestão consistente. A ISO/IEC 42001, por sua vez, estabelece requisitos para um sistema de gestão de inteligência artificial, com atenção à governança, aos objetivos e aos riscos associados ao desenvolvimento e ao uso dessa tecnologia.
A ISO/IEC 27090 ocupa outro espaço. Ela apresenta orientações técnicas para compreender ameaças e comprometimentos específicos dos sistemas de IA ao longo de seu ciclo de vida. A relação é complementar, não hierárquica: uma organização pode utilizar a 27001 para estruturar a gestão de segurança, a 42001 para organizar a governança de IA e a 27090 como referência para aprofundar a análise de ameaças, detecção e mitigação. A própria ISO destaca explicitamente a complementaridade da 27090 com a 27001 e a 27002; sua aplicação conjunta com a 42001 é uma integração de gestão coerente com os respectivos escopos, não uma exigência nova criada pela publicação.
Também é necessário separar orientação técnica de certificação. A ISO/IEC 27090 foi publicada como norma de orientação sobre ameaças e medidas de proteção; não deve ser apresentada como uma certificação autônoma equivalente à ISO/IEC 27001 ou à ISO/IEC 42001. Adotar suas recomendações pode fortalecer um programa de segurança, mas não autoriza afirmar que uma empresa se tornou “certificada ISO 27090”.
Os principais pontos de controle abordados pela ISO/IEC 27090
Um aspecto importante da nova norma é que ela não se limita a recomendar a proteção dos dados ou a instalação de ferramentas adicionais. A estrutura do documento relaciona práticas de Segurança da Informação, modalidades de ataque e medidas de mitigação ao longo do ciclo de vida da inteligência artificial. Em sua seção 5, trata de governança de IA, princípios de confiança zero (zero trust), boas práticas de engenharia de software, segurança da cadeia de fornecimento, modelagem de ameaças e exercícios de red teaming. Isso significa que a análise deve alcançar fornecedores de modelos, bibliotecas, conjuntos de dados, ambientes de desenvolvimento, APIs e integrações, não apenas a aplicação que o usuário acessa.
Na seção 6, a ISO/IEC 27090 organiza ameaças que exigem atenção específica. O data poisoning e a manipulação direta do modelo podem comprometer seu comportamento; ataques de evasão procuram produzir respostas incorretas ou contornar mecanismos de classificação; a inferência de participação (membership inference) e a inversão de modelos podem revelar informações sobre os dados utilizados no treinamento. A exfiltração de modelos ameaça propriedade intelectual, enquanto saídas sensíveis, prompt injection e conteúdo de saída contendo instruções maliciosas podem transformar o uso normal do sistema em um caminho para exposição de informações ou execução indevida de ações. O documento aborda, para essas classes de ataque, suas consequências e possibilidades de detecção e mitigação.
Os pontos de controle mais relevantes para uma organização podem ser traduzidos em decisões concretas. É necessário estabelecer responsáveis e critérios de risco para cada sistema de IA; manter a rastreabilidade da origem dos dados e modelos; proteger ambientes de desenvolvimento e atualização; aplicar privilégios mínimos às identidades e ferramentas conectadas; avaliar a segurança de componentes e fornecedores; testar cenários adversariais antes e depois da implantação; e limitar o alcance de comportamentos inesperados durante a operação. A seção 6.11 destaca justamente a limitação de dados, o controle dos efeitos de comportamentos indesejados e a procedência dos sistemas e das informações.
A seção 7 amplia essa discussão ao observar que controles podem interagir entre si e até produzir efeitos conflitantes. Por isso, a norma aborda a continuidade das mitigações ao longo do ciclo de vida, a deterioração de modelos e proteções com o tempo, o registro e monitoramento de eventos, a proteção do ambiente de desenvolvimento, a detecção e filtragem de entradas maliciosas e a limitação da intensidade de uso dos modelos (throttling). Em aplicações corporativas, essas orientações podem resultar em limites de consultas, análise de padrões anormais, validação de entradas, revisão periódica de controles e trilhas de auditoria que permitam investigar incidentes sem transformar os próprios registros em uma nova fonte de vazamento.
Esses são temas e orientações de controle abordados pela ISO/IEC 27090, não uma transcrição de requisitos certificáveis nem uma lista de controles numerados equivalente ao Anexo A da ISO/IEC 27001. A seleção de medidas depende do risco, da arquitetura e da finalidade de cada sistema. Os anexos informativos da 27090 também relacionam ataques a fases do ciclo de vida e ativos de IA, discutem versões específicas de ataques convencionais e apresentam considerações sobre aprendizado federado.
O que muda na avaliação de riscos das empresas
Para empresas brasileiras que utilizam assistentes internos, ferramentas de IA generativa, modelos próprios ou aplicações com recuperação de informações corporativas, a mudança mais relevante é metodológica. O inventário precisa identificar quais modelos são utilizados, quais dados recebem, onde estão hospedados, quem pode consultá-los, que ferramentas acionam e quais informações podem ser expostas ou reutilizadas. Sem esse mapeamento, controles tradicionais podem proteger apenas parte da operação.
Na prática, uma avaliação consistente deve considerar a integridade dos dados de treinamento e atualização, a procedência dos modelos e componentes, a separação entre instruções confiáveis e conteúdo externo, os privilégios concedidos às integrações e a capacidade de registrar eventos relevantes sem expor dados sensíveis nos próprios logs. Testes de segurança também precisam observar comportamentos indevidos da aplicação, incluindo tentativas de manipulação por entradas maliciosas, extração de informações e uso não autorizado de ferramentas. Nenhuma dessas medidas elimina isoladamente o risco; elas formam camadas de proteção que precisam ser revistas à medida que o sistema evolui.
O impacto ultrapassa a área técnica. Um modelo manipulado pode influenciar análises utilizadas em decisões comerciais; uma integração com permissões excessivas pode permitir operações indevidas; a exposição de dados utilizados por um assistente pode gerar consequências contratuais, regulatórias e reputacionais. Em processos críticos, a possibilidade de respostas incorretas ou alteradas intencionalmente também exige supervisão humana, critérios de validação e mecanismos para interromper a operação quando necessário.
A nova norma não resolve esses desafios automaticamente. Sua contribuição é oferecer uma linguagem e uma referência de análise mais próximas dos mecanismos de ataque à IA, ajudando equipes de segurança, desenvolvimento, riscos e auditoria a discutir o mesmo problema com maior precisão. Para organizações que já possuem um SGSI, o caminho mais produtivo tende a ser incorporar essas ameaças aos processos existentes, em vez de criar uma estrutura paralela sem integração com os riscos do negócio.
Be the first to comment