A primeira norma da família 27000 dedicada à segurança de sistemas de inteligência artificial. Este guia resume o que ela cobre, quais ameaças cataloga, como encaixar no que você já opera com a 27001 e a 42001, e por onde começar.
ISO/IEC 27090:2026
Cybersecurity — Artificial intelligence — Addressing security threats and compromises to AI systems
Hardware, rede, software e pessoas continuam atacáveis, e a própria norma lembra que proteger a pilha de software costuma ser o investimento mais eficiente. A IA soma três características novas a essa base.
Quem mexe nos dados de treinamento mexe no modelo. Com aprendizado contínuo, o uso de hoje vira o treino de amanhã.
É difícil explicar por que um modelo respondeu o que respondeu. Um modelo comprometido costuma parecer normal até o dia em que falha.
Prompts, consultas à API e documentos do RAG chegam por interfaces válidas. Firewall e WAF continuam necessários, mas não enxergam isso.
O detalhe que diz tudo: a norma foi escrita pelo SC 27, o comitê de segurança da informação, e não pelo SC 42, o de IA. Por isso ela fala em tríade CID, avaliação de riscos e controles da 27002 por número. Segurança de IA é segurança da informação: muda o objeto protegido, não a profissão.
Cada tipo de ataque é descrito sempre no mesmo formato: descrição, falhas resultantes, detecção e mitigação. Ninguém precisa decorar o catálogo, só saber onde procurar.
Os exemplos que a norma organiza nas Tabelas 1 e 2. São ponto de partida, não lista fechada: a avaliação de riscos continua mandando. Os marcados com “sem atacante” podem acontecer só por descuido ou pelo próprio comportamento do modelo.
| Tipo | O que acontece | IA generativa | IA preditiva |
|---|---|---|---|
| Envenenamento de dados6.2 | Dados indesejados entram no treino e degradam o modelo ou plantam uma porta para depois. | Sim | Sim |
| Evasão6.3 | Entradas levemente alteradas fazem o modelo errar de propósito. | Não | Sim |
| Inferência de pertinência6.4 | Pelo comportamento do modelo, alguém descobre se um registro estava no treino. | Sim | Sim |
| Exfiltração de modelo6.5 | Milhares de consultas válidas viram dataset para treinar um clone funcional. | Sim | Sim |
| Inversão de modelo6.6 | As respostas são usadas para reconstruir, aproximadamente, atributos dos dados de treino. | Sim | Sim |
| Envenenamento direto do modelo6.7 | O próprio modelo, o pipeline ou a arquitetura são adulterados, sem passar pelos dados. | Sim | Sim |
| Prompt injection6.9 | Instruções escondidas na entrada, direta ou vinda de página, e-mail ou documento, mudam o comportamento. | Sim | Não |
| Saída sensível6.8sem atacante | A resposta expõe informação confidencial memorizada ou presente no contexto. | Sim | Não |
| Saída com ataque de injeção6.10sem atacante | A resposta carrega payload, como XSS ou SQL, para o sistema que a consome. | Sim | Não |
| Roubo direto do modeloAnexo B | Os pesos são levados do ambiente de desenvolvimento ou de produção. | Sim | Sim |
| Vazamento de dados de treinoAnexo Bsem atacante | Acesso indevido ao conjunto de treinamento. | Sim | Sim |
| Vazamento de entradaAnexo Bsem atacante | Os dados que usuários enviam ao modelo perdem a confidencialidade. | Sim | Sim |
Tabela condensada e reescrita pela Akantos a partir da classificação da norma.
O risco mais presente para quem usa LLM e agentes. As defesas reduzem, mas não zeram: separar instruções de dados, tratar conteúdo externo como não confiável, filtrar saídas e, principalmente, fazer a aplicação, e não o modelo, decidir o que cada ferramenta pode executar.
Nenhuma falha de código é explorada e cada requisição é válida. Só o padrão agregado de consultas denuncia o ataque. Resposta: throttling, autenticação por requisição e menos informação na saída.
O modelo responde normal até receber o gatilho. Hash e assinatura provam que o artefato não mudou e de onde veio, mas não que está livre de comportamento malicioso. Ambiente de desenvolvimento protegido é obrigatório.
A cláusula 5.3 parte dos princípios de zero trust do controle 8.27 da 27002 e os traduz para as arquiteturas que as empresas realmente usam em 2026.
A 27001 pergunta se a segurança é gerida. A 42001 pergunta se a IA é governada. A 27090 responde quais ameaças técnicas considerar e como detectá-las e mitigá-las. Ela alimenta os dois sistemas de gestão.
| Tema da 27090 | Âncora na 27001/27002 | Âncora na 42001 e normas de IA |
|---|---|---|
| Seleção de controles | 27002, cláusulas 5 a 8, por risco | Complementa o SGIA |
| Avaliação de riscos | 27001, 6.1 | 42001, 6.1 e ISO/IEC 23894 |
| Governança de IA | Políticas e papéis do SGSI | 42001 (implementação) e 38507 (conselho) |
| Desenvolvimento seguro e zero trust | 27002, 8.25 a 8.30, em especial 8.27 | ISO/IEC 5338 |
| Cadeia de suprimentos | 27002, 5.19 a 5.23 e 8.30 | 42001, A.6.2.3 e A.6.2.6 |
| Logging e monitoramento | 27002, 8.15 e 8.16 | Operação do SGIA |
No SGSI: inclua modelos, datasets, pipelines e APIs no inventário de ativos, leve os tipos da cláusula 6 para a avaliação de riscos e registre o tratamento na Declaração de Aplicabilidade, inclusive controles específicos de IA fora do Anexo A.
“Dá para certificar a empresa na 27090.”
Não dá. Ela é orientativa. Certificáveis são o SGSI da 27001 e o SGIA da 42001, que podem usar o conteúdo dela. Desconfie de selo “ISO 27090”.
“Só preciso me preocupar se eu treino modelos.”
Boa parte dos comprometimentos acontece em operação. Quem só consome IA de mercado também está no escopo.
“Ter a 42001 já garante que o modelo é seguro.”
A auditoria da 42001 avalia o sistema de gestão, não a resistência técnica do modelo a ataques. As duas camadas se completam.
“Seguir a 27090 comprova o EU AI Act.”
Ajuda muito no Artigo 15 (robustez e cibersegurança), mas não é norma harmonizada: é referência técnica, não comprovante.
Cinco passos, e o último realimenta o segundo. Defesa de IA é processo contínuo, não projeto com data de fim.
Liste os sistemas de IA e como são usados, inclusive os não oficiais. Shadow AI entra no inventário.
Use os tipos da cláusula 6 como lista de partida, sistema por sistema, com a sua matriz de riscos.
Leve os controles para a Declaração de Aplicabilidade ou para o SGIA, cada um com dono e justificativa.
Threat modelling a cada sistema novo ou alterado, e red teaming periódico em ambiente controlado.
Logs, métricas e revisão. Defesa de IA perde eficácia com o tempo (7.4) e o resultado volta para o passo 2.
Ponto de partida rápido: o inventário do passo 1 já costuma revelar ferramentas de IA em uso sem dono, sem avaliação de risco e com dados da empresa entrando nelas. É ali que a maioria das organizações encontra o primeiro risco real.
Fontes: ISO/IEC 27090:2026 e normas citadas; material de apoio da aula aberta “ISO/IEC 27090: a nova norma de segurança para sistemas de IA”, da TIexames (Prof. Rafael Batista, MSc, out/2026). Este guia é um resumo autoral e não substitui a leitura da norma. Publicado em 2 de novembro de 2026.
Inventário de IA, avaliação de riscos e política de uso, alinhados à 27001, à 42001 e à 27090. Ver Governança de IA