Conheça a nova ISO/IEC 27090

1. A família ISO 27000 chegou à inteligência artificial

Em 14 de outubro de 2026 a ISO publicou a ISO/IEC 27090:2026, primeira edição da primeira norma da família 27000 dedicada à segurança de sistemas de IA. O título oficial é "Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems". Em português: cibersegurança, inteligência artificial, tratamento de ameaças à segurança e comprometimentos de sistemas de IA.

Um detalhe de bastidor ajuda a entender o espírito do documento. A norma foi produzida pelo ISO/IEC JTC 1/SC 27, o mesmo subcomitê responsável pela ISO/IEC 27001, 27002, 27005 e 27701, e não pelo SC 42, o comitê de inteligência artificial que produziu a ISO/IEC 22989, a 23894 e a 42001. A mensagem implícita: segurança de IA é disciplina de segurança da informação. O que muda é o objeto protegido, não a profissão de quem protege.

São cerca de 50 páginas de conteúdo técnico e uma bibliografia com mais de cem referências, boa parte delas artigos de pesquisa sobre ataques reais a modelos de machine learning. É uma norma de diretrizes: orienta, descreve e recomenda, mas não gera certificado. Até a publicação deste artigo, não há versão ABNT NBR nem tradução oficial para o português.

Este artigo explica para que a norma serve, como ela organiza as ameaças a sistemas de IA, e onde ela se encaixa em relação às duas normas certificáveis que toda organização com IA precisa conhecer: a ISO/IEC 27001 e a ISO/IEC 42001.

2. Por que a segurança tradicional não basta para sistemas de IA

A norma começa desfazendo um mal-entendido comum. Sistemas de IA continuam sujeitos a todas as vulnerabilidades, exploits e ataques convencionais. Eles rodam sobre hardware, software e rede, dependem de pessoas e de processos, e nada disso ganhou imunidade por envolver um modelo. O texto chega a afirmar que proteger a pilha de software do sistema costuma ser o ponto de partida mais eficiente: se a preocupação é o roubo do modelo, controlar o acesso ao repositório onde ele está armazenado rende mais do que controles sofisticados contra extração via API.

O problema é que isso não cobre tudo. Três características tornam sistemas de IA diferentes dos sistemas de informação convencionais:

1. Dependência de dados de treinamento. O comportamento do sistema é aprendido a partir de dados, que podem incluir dados de usuários ou dados não verificados coletados da internet. Quem controla os dados influencia o modelo. Em sistemas com aprendizado contínuo, entradas fornecidas durante a operação viram dados de treinamento do próximo ciclo: uma entrada corrompida hoje vira envenenamento do retreinamento de amanhã.
2. Opacidade. Diagnosticar por que um modelo produziu determinada saída é difícil. Um sistema convencional comprometido deixa rastros em código e logs; um modelo que aprendeu errado se comporta de forma plausível até o momento em que falha.
3. Superfícies novas de ataque. Manipulação de dados, de entradas e de ações do modelo não aparecem em nenhum catálogo clássico de ameaças. Um ataque de evasão usa entradas tecnicamente válidas. Um prompt injection chega pelo canal legítimo da aplicação, sem explorar nenhuma vulnerabilidade de código. Firewall, antivírus e WAF não foram projetados para perceber nada disso.

A ISO/IEC 27090 nasce exatamente para esse espaço: descrever o que é específico de IA sem repetir o que a 27001 e a 27002 já cobrem. A premissa é de camadas, não de substituição.

3. Para que serve a ISO/IEC 27090 e para quem ela é

O propósito declarado no escopo é direto: ajudar organizações a entender as consequências das ameaças de segurança específicas de sistemas de IA ao longo de todo o ciclo de vida, e descrever como detectar e mitigar essas ameaças. Na prática, ela funciona como um catálogo comentado: para cada tipo de ataque, a norma descreve o mecanismo, as falhas que ele provoca, os métodos de detecção e as medidas de mitigação, com referências à pesquisa que sustenta cada técnica.

Três características definem sua natureza:

• É uma norma de orientação. Não há certificação ISO/IEC 27090, e não haverá. O papel dela é alimentar sistemas de gestão certificáveis, como o SGSI da 27001 e o SGIA da 42001, com conteúdo técnico sobre IA.
• Vale para quem desenvolve e para quem usa. O escopo cita organizações de todos os tipos e portes, públicas e privadas, incluindo as que apenas consomem IA. Uma empresa que integra um modelo de mercado no seu produto também está no público-alvo, porque várias das ameaças descritas atacam o sistema em operação, não o treinamento.
• Fala a língua do ecossistema de IA. As referências normativas são a ISO/IEC 22989 (conceitos e terminologia de IA) e a ISO/IEC 23053 (framework de sistemas de ML). O vocabulário é o mesmo da 42001 e da 23894, o que facilita integrar os documentos.

Quanto ao público, a norma interessa a perfis diferentes por motivos diferentes. CISOs e equipes de segurança que receberam sistemas de IA no escopo ganham um mapa de ameaças pronto. Engenheiros de ML e de dados encontram as técnicas de detecção e mitigação aplicáveis ao pipeline. Profissionais de GRC e gestores de risco ganham uma taxonomia para alimentar a avaliação de riscos. Auditores e consultores de 27001 e de 42001 passam a ter uma referência objetiva para avaliar se os controles de IA de um cliente fazem sentido técnico.

4. Como a norma está organizada

O corpo da norma tem três capítulos de conteúdo e três anexos informativos:

Dois pontos da cláusula 5 merecem destaque antes de chegarmos aos ataques.

O programa de governança de IA (5.2). Para que sistemas de IA estejam sob governança adequada, incluindo segurança, a norma pede três coisas: manter um inventário dos sistemas de IA e de seus usos, realizar análise de riscos sobre eles e gerenciar esses riscos. Para a perspectiva do conselho, remete à ISO/IEC 38507. Para a implementação, o texto é literal: ver ISO/IEC 42001. Voltamos a essa conexão na seção 7.

Zero trust aplicado a IA (5.3). A norma parte dos seis princípios de zero trust já descritos no controle 8.27 da ISO/IEC 27002 (assumir que já houve violação, nunca confiar e sempre verificar, criptografia de ponta a ponta, verificar cada requisição como se fosse externa, mínimo privilégio, autenticação e autorização sempre) e os traduz para o ciclo de vida de IA: validar procedência e integridade de cada dataset antes de entrar no pipeline, autorizar cada requisição de inferência, isolar aplicações de IA de suas fontes de dados e monitorar desvios de comportamento.

5. As formas de comprometer um sistema de IA

A cláusula 6 organiza os comprometimentos por dois eixos: qual ativo é atingido primeiro (modelo, dados de treinamento, dados de teste, saída ou serviço) e qual propriedade de segurança é violada no incidente inicial (confidencialidade, integridade ou disponibilidade). A tabela abaixo consolida esse mapa. As colunas de IA generativa e preditiva indicam a quais famílias de sistemas cada comprometimento se aplica, e a coluna de atacante indica se o comprometimento exige um adversário ou pode acontecer por acidente.

Três leituras saltam dessa tabela.

As superfícies de generativa e preditiva são diferentes. Evasão é um problema de IA preditiva, típico de classificadores: a imagem levemente alterada que engana o reconhecimento, o malware que passa pelo detector. Prompt injection, saída sensível e injeção na saída são exclusivos de IA generativa. Uma organização que opera os dois tipos precisa de dois mapas de risco.

Nem todo comprometimento exige atacante. Saída sensível, vazamento de dados e injeção na saída podem ocorrer por acidente: um modelo que memoriza dados pessoais do treinamento e os devolve numa resposta comprometeu a confidencialidade sem que ninguém o atacasse. A consequência prática: parte das defesas é controle de projeto, não defesa contra adversário.

Cada ataque vem com o kit completo. Para cada linha da tabela, a cláusula 6 descreve as falhas resultantes, os métodos de detecção e as mitigações, citando técnicas como validação de proveniência dos dados, treinamento adversarial, privacidade diferencial, filtragem de entradas e saídas, e criptografia homomórfica, sempre apontando os estudos que sustentam cada uma. A norma também é honesta sobre limites: avisa que parte dessas técnicas é prática emergente, com custos de desempenho e complexidade, e que algumas só se justificam em sistemas de alto risco.

6. O diagrama: onde os ataques acontecem no ciclo de vida

O Anexo A da norma traz a figura que resume todo o capítulo 6 num único mapa: os ataques posicionados sobre a visão funcional de um sistema de IA. Reconstruímos o diagrama abaixo.

Ataques a sistemas de IA mapeados à visão funcional do sistema. Reconstruído a partir da Figura A.2 da ISO/IEC 27090:2026.

Como ler o diagrama:

• A linha tracejada divide dois mundos. Acima dela está o tempo de desenvolvimento, quando o modelo é treinado: incepção, projeto, desenvolvimento, verificação e validação. Abaixo está o tempo de execução, quando o modelo já implantado faz inferências: implantação, operação, monitoramento e reavaliação.
• Caixas claras são ativos, caixas escuras são processos. Dados de treinamento, modelo, entrada e saída são o que precisa ser protegido. As setas vermelhas são as ameaças, apontando para o ativo que cada uma compromete. A letra entre parênteses indica o impacto, conforme a legenda.
• O modelo é o ativo mais cercado. Ele sofre roubo e envenenamento nos dois tempos: durante o desenvolvimento, pelo ambiente e pela cadeia de suprimentos; em execução, pela infraestrutura que o hospeda. É por isso que a norma insiste na proteção do ambiente de desenvolvimento (7.6) como controle de primeira ordem.
• A entrada concentra as ameaças pelo uso. Evasão, inversão, inferência de pertinência, roubo via consultas, negação de serviço e prompt injection chegam todas pelo mesmo canal: requisições legítimas à API ou à interface. Nenhuma delas explora vulnerabilidade de código. Isso explica os controles de runtime do capítulo 7: filtragem de entradas, detecção de consultas fora de distribuição e throttling.
• A camada convencional continua lá. A seta cinza sob a aplicação lembra que SQL injection, quebra de senhas e comprometimento de plugins seguem valendo. A norma dedica o Anexo B inteiro a esses ataques clássicos e às consequências específicas que ganham quando o alvo é um sistema de IA.

O diagrama também serve como ferramenta de trabalho. Numa oficina de threat modelling, basta sobrepor a arquitetura do seu sistema a esse mapa e perguntar, seta por seta: essa ameaça se aplica aqui? Quem a detectaria? Qual controle a mitiga?

7. Como a 27090 se encaixa com a 27001 e a 42001

A pergunta que toda organização com IA vai fazer: já temos ISO/IEC 27001, estamos avaliando a ISO/IEC 42001, onde entra a 27090? A resposta curta: ela é a camada técnica que conecta as duas. A resposta completa começa por entender o que cada norma responde.

No SGSI da 27001, o caminho é direto

1. Incluir os sistemas de IA no escopo do SGSI e no inventário de ativos: modelos, datasets, pipelines e as APIs que os expõem.
2. Levar os comprometimentos da cláusula 6 para a avaliação de riscos exigida pela 27001 (6.1). A tabela da seção 5 deste artigo funciona como lista de partida.
3. Refletir o tratamento na Declaração de Aplicabilidade, usando os controles da 27002 que a própria 27090 aponta nominalmente.

No SGIA da 42001, a 27090 é fonte técnica

A conexão é explícita nos dois sentidos. A 27090 manda estabelecer um programa de governança de IA e remete à 42001 para a implementação. Na direção contrária, ela alimenta o SGIA: é insumo para a avaliação de riscos de IA (junto com a ISO/IEC 23894) e para os controles do Anexo A ligados ao ciclo de vida. Para cadeia de suprimentos, a 27090 cita nominalmente os controles A.6.2.3 e A.6.2.6 da 42001 como ponto de aplicação das ameaças que descreve.

A tabela abaixo resume onde cada tema da 27090 se ancora:

Para quem opera ou planeja um sistema integrado, o raciocínio é o mesmo que descrevemos no artigo Como integrar normas ISO num único sistema de gestão: a 27001 e a 42001 compõem a espinha dorsal certificável, e a 27090 entra como referência técnica compartilhada pelas duas. E o primeiro passo prático, o inventário de sistemas de IA, conversa com o problema que tratamos em Shadow AI: o que é, quais os riscos e como as empresas podem controlar o uso de IA: não dá para proteger o que não se sabe que existe.

8. O que a norma não resolve

Para usar bem a 27090, é preciso saber também onde ela para.

Ela não gera certificado nem presunção de conformidade legal. Quem precisa demonstrar conformidade auditável continua dependendo da 27001 e da 42001. No contexto europeu, o Artigo 15 do EU AI Act exige que sistemas de alto risco resistam a ameaças como envenenamento de dados, envenenamento de modelo e exemplos adversariais, exatamente o conteúdo da 27090. Mas, por ser norma de diretrizes e não norma harmonizada, segui-la não gera presunção de conformidade com o regulamento. Na Europa, o requisito certificável de base é a ETSI EN 304 223, publicada em janeiro de 2026, e as normas harmonizadas específicas do AI Act ainda estão em elaboração. A 27090 funciona como referência técnica que ajuda a cumprir, não como comprovante.

Parte das técnicas ainda é fronteira. A própria norma avisa que mitigações como aprendizado federado e criptografia homomórfica são práticas emergentes, com custos de desempenho e complexidade, e que fazem sentido sobretudo em sistemas de alto risco e em organizações com maturidade de segurança já estabelecida.

A lista de ameaças não é exaustiva. O texto reconhece que novas ameaças vão surgir conforme a tecnologia e o cenário adversário evoluem. Agentes de IA são o exemplo mais evidente: a norma os toca nos exemplos de zero trust e nas seções de prompt injection, mas quem constrói agentes e sistemas multiagente precisa de threat modelling e red teaming próprios, além do que está escrito.

Defesa de IA não é projeto com data de fim. A cláusula 7.4 trata da deterioração de modelos e de mitigações ao longo do tempo: o que protege hoje perde eficácia conforme os dados mudam e os atacantes aprendem. O desenho correto é de processo contínuo, com monitoramento, reavaliação e atualização das defesas.

9. Formações da TIexames em segurança e governança de IA

A 27090 confirma um movimento que já estava claro: segurança de IA virou especialidade própria, na interseção entre segurança da informação e governança de IA. A TIexames, Recognised Training Provider da Exemplar Global (EUA) e credenciada EXIN, cobre essa interseção com formações complementares:

• Formação AI Security Leader: para quem vai liderar a segurança de sistemas de IA na organização, exatamente o terreno da 27090.
• EXIN AI Security Professional (AISP): certificação internacional focada em segurança de IA.
• CompTIA SecAI+: certificação técnica de segurança aplicada a IA.
• ISO/IEC 42001 Lead Implementer e ISO/IEC 42001 Lead Auditor: para implementar e auditar o SGIA que a 27090 pressupõe como sistema de gestão.
• Formação AI Governance Manager: a visão completa de governança de IA, preparatória para IAPP AIGP e EXIN AICP.
• MBA AI & Cybersecurity Leadership, reconhecido pelo MEC: para quem quer a trilha acadêmica completa na junção das duas áreas.

10. Por onde começar

A ISO/IEC 27090 entrega o que faltava entre a gestão e a técnica: um catálogo de ameaças específicas de IA com detecção e mitigação para cada uma, escrito na linguagem da família 27000 e conectado por referência explícita à 42001. Quatro passos práticos para sair deste artigo com algo em andamento:

1. Ler o texto oficial. A ISO/IEC 27090:2026 está disponível em inglês na loja da ISO. Reserve atenção especial à cláusula 6 e ao Anexo A.
2. Inventariar os sistemas de IA. Sem inventário não há avaliação de riscos. Inclua os usos não oficiais: o fenômeno da Shadow AI costuma esconder a maior parte da superfície de ataque.
3. Levar as ameaças ao registro de riscos. Use a tabela da seção 5 como ponto de partida na avaliação de riscos do SGSI e, se a organização opera ou planeja um SGIA, também na avaliação de riscos de IA.
4. Atualizar a formação do time. Segurança de IA exige vocabulário e técnica que não estavam no currículo de segurança tradicional. Quem dominar essa interseção primeiro sai na frente, como aconteceu com privacidade em 2018 e com governança de IA em 2024.