A ISO 27090 explicada para equipas de segurança da IA

A ISO/IEC 27090:2026 é uma norma internacional que fornece orientações sobre ameaças de segurança e comprometimentos que afetam sistemas de inteligência artificial. Publicada a 14 de outubro de 2026, aborda a forma como as organizações podem compreender, detetar e mitigar essas ameaças ao longo de todo o ciclo de vida da IA. O seu título formal é Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. Registo de publicação da ISO

Para uma equipa de segurança, a pergunta prática é simples: o que poderia um atacante alterar, roubar ou levar um sistema de IA a fazer, e o que limitaria os danos resultantes?

Este guia explica o âmbito da norma ISO 27090, as principais ameaças à segurança da IA, a sua relação com a ISO 27001 e a ISO 42001, e uma forma prática de transformar as orientações em trabalho de segurança com responsáveis, salvaguardas e evidências. A investigação que lhe serve de base foi verificada a 18 de outubro de 2026.

O que abrange a norma ISO 27090

A ISO 27090 centra-se na proteção de sistemas de IA. O seu objeto vai além da IA generativa, dos grandes modelos de linguagem e dos chatbots, abrangendo os sistemas de IA de forma mais ampla. Explicação da ISO sobre a ISO 27090

A norma publicada liga as práticas consolidadas de segurança da informação às ameaças específicas da IA. O seu conteúdo aborda a governação, a segurança da cadeia de abastecimento, a modelação de ameaças e o red teaming, seguindo-se os tipos de comprometimento, incluindo envenenamento, evasão, exposição de informação e injeção de prompts. Considera também a forma como as mitigações interagem entre si e se mantêm eficazes ao longo do tempo. Amostra publicada da ISO/IEC 27090

O âmbito inclui organizações de qualquer dimensão que desenvolvam ou utilizem IA, incluindo empresas, organismos públicos e organizações sem fins lucrativos. Assim, adquirir um serviço de IA de terceiros não coloca uma organização fora do público-alvo. Registo de publicação da IEC

Um bom ponto de partida é uma revisão conjunta que envolva as áreas de segurança, engenharia, dados, compras e o responsável de negócio. Cada uma deve conseguir explicar a parte do sistema que controla e as decisões que depende de outros para tomar.

Porque é que os sistemas de IA precisam de análise de segurança adicional

Uma aplicação de IA liga vários elementos que merecem um escrutínio separado: software, dados, ficheiros ou serviços de modelos, instruções, utilizadores e ações a jusante.

Pense num assistente de documentos ligado a uma base de conhecimento interna. Uma revisão convencional pode examinar a autenticação, a cifragem e as vulnerabilidades de software. Uma revisão de segurança da IA deve também perguntar o que acontece se um documento recuperado tentar alterar as instruções do assistente, se os utilizadores conseguem obter material fora das suas permissões e que ações podem ser desencadeadas pelo resultado gerado.

Estas perguntas ganham mais peso quando um assistente pode atualizar registos ou chamar ferramentas externas. Uma resposta errada e uma ação não autorizada têm consequências diferentes e exigem salvaguardas diferentes.

Na sua primeira revisão, mapeie três perguntas:

• O que pode influenciar o sistema? Inclua dados de treino, conteúdo recuperado, prompts, fornecedores e atualizações de modelos.
• O que pode sair do sistema? Inclua respostas, registos, exportações e ativos de modelos.
• O que pode o sistema alterar? Inclua ficheiros, tickets, contas, transações e outros serviços ligados.

Trata-se de um método prático de delimitação do âmbito para os exemplos seguintes, e não de uma reprodução das cláusulas da norma.

Ameaças à segurança da IA que deve compreender

As explicações seguintes utilizam a terminologia do NIST sobre machine learning adversarial e as orientações da OWASP para aplicações de LLM. Os cenários são ilustrativos. Taxonomia do NIST de machine learning adversarial Orientações da OWASP sobre injeção de prompts Orientações da OWASP sobre tratamento de resultados

Mantenha estas distinções claras durante uma avaliação de riscos. Um documento malicioso recuperado por uma aplicação de geração aumentada por recuperação (RAG) não constitui automaticamente envenenamento de dados de treino: a recuperação, por si só, não atualiza os pesos do modelo. Pode, em vez disso, expor a aplicação a uma injeção indireta de prompts.

Na segurança de LLM, prompts mais robustos, por si só, são uma estratégia de controlo incompleta. A OWASP recomenda salvaguardas como privilégios restritos e aprovação para ações sensíveis, enquanto o NCSC sublinha a gestão da injeção de prompts como um risco contínuo, através da conceção e da operação do sistema. Orientações da OWASP sobre injeção de prompts Orientações do NCSC sobre o risco de injeção de prompts

ISO 27090 vs ISO 27001 e ISO 42001

Estas normas apoiam partes diferentes do trabalho de segurança e de governação da IA de uma organização.

As distinções seguem as descrições dos editores da ISO 27001, da ISO 27002 e da ISO 42001.

Para uma equipa que já opera um SGSI, uma abordagem prática é alargar os registos existentes. Acrescente os sistemas de IA relevantes ao inventário de ativos, avalie os respetivos caminhos de ataque, atribua responsáveis pelo tratamento e associe as evidências de suporte. Para contexto sobre a organização desse trabalho, consulte a lista de verificação para implementação da ISO 27001.

Uma lista de verificação prática para implementar a ISO 27090

Os passos seguintes constituem uma abordagem de implementação construída a partir do objeto da norma e de orientações públicas sobre IA segura. Não são uma lista de verificação oficial da ISO nem uma declaração de cláusulas obrigatórias.

1. Defina o sistema e o seu responsável

Escolha um caso de uso de IA com uma finalidade de negócio clara. Registe o responsável que presta contas, os utilizadores, o fornecedor do modelo, o modelo de alojamento e os serviços ligados.

Em seguida, trace a fronteira da revisão. Inclua a aplicação e as suas dependências, e não apenas o endpoint do modelo. Um assistente orientado para clientes com acesso a ferramentas exige uma avaliação diferente da de um resumidor de texto interno sem permissão para agir.

Resultado útil: um registo do sistema que indique a sua finalidade, fronteiras, dependências, ações permitidas e responsável que presta contas.

2. Rastreie a proveniência dos dados e dos modelos

Registe a origem dos conjuntos de dados e dos artefactos de modelos, quem os pode alterar e que versões estão implementadas. Inclua as entradas de afinação, as coleções de recuperação, os prompts e os canais de feedback relevantes para o sistema.

As orientações de desenvolvimento do NCSC recomendam rastrear os ativos de IA e a sua proveniência, protegê-los e conservar a informação necessária para recuperar versões fiáveis. Orientações do NCSC sobre desenvolvimento seguro de IA

No caso de um modelo adquirido, pergunte ao fornecedor que responsabilidades assume e que informação disponibiliza quando os modelos ou serviços mudam.

Resultado útil: um inventário versionado com origens, regras de acesso, histórico de alterações e responsabilidades dos fornecedores.

3. Modele as ameaças do fluxo de trabalho real

Reveja o sistema na perspetiva de um atacante. Identifique pontos de entrada, ativos sensíveis, permissões e as consequências de um comprometimento bem-sucedido. As orientações de conceção segura do NCSC recomendam a modelação de ameaças e atenção aos componentes de terceiros e ao princípio do menor privilégio. Orientações do NCSC sobre conceção segura de IA

Escreva cenários concretos. «Risco de IA» é demasiado genérico para orientar uma ação útil. «Um documento carregado por uma parte externa convence o assistente a pedir um ficheiro de evidências restrito» dá à equipa algo específico para analisar.

Defina prioridades em função da exposição e dos danos potenciais. Registe quem aceita o risco residual e quando essa decisão deve ser revista.

Resultado útil: um registo de riscos sucinto que associe cenários de ataque a ativos, consequências, salvaguardas e responsáveis.

4. Coloque as salvaguardas nas fronteiras relevantes

Selecione controlos para o cenário que está a tratar. Para os ativos de modelos, isto pode envolver armazenamento protegido, restrições de acesso e verificações de integridade. Para os serviços implementados, considere a autenticação, a separação entre ambientes e controlos que reduzam o acesso não autorizado ou a exfiltração. Estes são temas das orientações de implementação do NCSC. Orientações do NCSC sobre implementação segura de IA

No caso dos resultados gerados, valide e codifique o conteúdo para o seu destino antes de outro sistema agir com base nele. As orientações da OWASP sobre tratamento de resultados explicam porque é que o resultado de um modelo não deve adquirir autoridade apenas por ter sido produzido pelo modelo. Orientações da OWASP sobre tratamento de resultados

Resultado útil: um registo de controlo que identifique a fronteira que protege, o seu responsável e as evidências utilizadas para o verificar.

5. Teste a aplicação completa

Conceba testes em torno das consequências identificadas na sua modelação de ameaças. Para um assistente RAG, utilize documentos adversariais e utilizadores com permissões diferentes. Para um agente, teste o que acontece quando o conteúdo recuperado lhe pede que exceda as ações permitidas.

Defina o resultado esperado antes de executar o teste. Um exemplo: a aplicação tem de recusar um pedido de ficheiro restrito, mesmo que o modelo tente fazer esse pedido.

Registe a configuração da aplicação, a versão do modelo, as entradas de teste, o resultado e qualquer correção. Escolha dados de teste que não exponham desnecessariamente informação confidencial real.

Resultado útil: testes de segurança repetíveis, associados a riscos específicos e a decisões de lançamento.

6. Monitorize as alterações e prepare uma resposta

Reveja o efeito das atualizações de modelos, dados e prompts. Monitorize as entradas e os resultados relevantes, protegendo a informação sensível nos registos. As orientações operacionais do NCSC destacam a monitorização do comportamento e as implicações de segurança das alterações ao longo de toda a operação. Orientações do NCSC sobre operação segura de IA

Decida antecipadamente quem pode desativar uma ferramenta, revogar uma credencial, isolar uma integração ou reverter um lançamento. Defina gatilhos de revisão, como um novo fornecedor, permissões alargadas, uma atualização significativa do modelo ou um incidente de segurança.

Resultado útil: responsabilidades de monitorização, critérios de revisão de alterações, um procedimento de resposta a incidentes e uma via de recuperação testada.

Transformar os riscos de segurança da IA em evidências

A tabela seguinte é um modelo de trabalho sugerido. Os exemplos de evidências são recomendações práticas, e não uma lista de documentos exigidos pela ISO 27090.

Imagine, por exemplo, uma equipa de segurança que utiliza um assistente para resumir evidências de clientes. Um documento de um fornecedor inclui instruções para carregar as evidências para um endereço externo.

O teste da equipa deve seguir a ação tentada através da aplicação. O assistente dispõe de uma ferramenta que pode carregar ficheiros? Essa ferramenta aplica as permissões do utilizador? Os destinos estão restringidos? É necessária a aprovação da transferência por uma pessoa responsável?

Um registo de revisão útil identificaria o cenário, a fronteira que impede a transferência, o resultado do teste e a pessoa que aprovou o risco residual. Se o sistema mudar, esse registo indica ao próximo revisor o que tem de voltar a ser verificado.

Esta abordagem dá mais substância a uma avaliação do que a afirmação de que o sistema utiliza «IA responsável». Liga a decisão de segurança a algo que outra pessoa pode inspecionar. Para mais informação sobre a organização do material de suporte, consulte como estruturar a preparação para auditorias.

Certificação e requisitos da ISO 27090

A ISO 27090 fornece orientações de segurança, e não requisitos de certificação de um sistema de gestão. A explicação da ISO distingue a sua finalidade dos requisitos do SGIA da ISO 42001. Explicação da ISO sobre a ISO 27090

Defina primeiro a garantia de que precisa: uma revisão de segurança, uma resposta de garantia a um cliente, uma avaliação interna de lacunas ou uma certificação face a uma norma de sistema de gestão aplicável.

Peça a quem oferecer uma avaliação que indique o seu âmbito, os critérios e o esquema de garantia. Isso torna o resultado mais fácil de interpretar e evita confundir uma revisão das práticas de segurança da IA com a certificação de um sistema de gestão.

Num projeto de implementação, obtenha a norma publicada, reveja as orientações face aos seus próprios sistemas e registe porque é que determinadas salvaguardas são adequadas. Os exemplos deste artigo fornecem uma estrutura inicial para esse trabalho.

A ISO 27090 e o Regulamento da IA da UE

A aplicação de uma norma internacional não estabelece automaticamente a conformidade com o Regulamento da IA da UE (AI Act). O artigo 40.º associa uma presunção de conformidade às normas harmonizadas cujas referências tenham sido publicadas no Jornal Oficial da UE, e apenas na medida em que abranjam os requisitos ou obrigações relevantes. Artigo 40.º do Regulamento da IA da UE

Utilize uma revisão de segurança segundo a ISO 27090 como um dos contributos para uma avaliação de conformidade com âmbito definido separadamente. Mantenha um registo da obrigação legal em avaliação, das evidências que a suportam e de qualquer lacuna remanescente.

Perguntas frequentes sobre a ISO 27090

Qual é a data de publicação da ISO 27090?

A primeira edição, ISO/IEC 27090:2026, foi publicada a 14 de outubro de 2026. Consulte o registo atual do editor quando material mais antigo se referir a um projeto de norma ou a um ano anterior. Registo de publicação da IEC

A ISO 27090 abrange a IA generativa e a segurança de LLM?

O seu conteúdo publicado inclui a injeção de prompts e resultados sensíveis de modelos, o que a torna relevante para a segurança da IA generativa. O seu âmbito inclui também outros sistemas de IA. Amostra publicada da ISO/IEC 27090 Explicação da ISO sobre a ISO 27090

Uma empresa que utiliza IA de terceiros pode aplicar a norma?

Sim. O público-alvo declarado inclui organizações que utilizam IA, bem como organizações que a desenvolvem. Comece pelos riscos e responsabilidades sob o seu controlo e identifique o que precisa de compreender sobre os seus fornecedores. Registo de publicação da IEC

A certificação ISO 27001 significa que um sistema de IA é seguro?

A certificação de um sistema de gestão não garante que uma aplicação individual resista a todos os ataques. Utilize o sistema de gestão para organizar as decisões sobre riscos e avalie a conceção, a configuração e o comportamento reais do sistema de IA. A ISO 27090 pode ajudar a fundamentar esse trabalho de segurança.

Onde posso obter o PDF da ISO 27090?

Utilize o catálogo oficial da ISO ou a IEC Webstore para obter a norma publicada e as opções de licenciamento. Verifique se a designação é ISO/IEC 27090:2026. Um artigo ou uma pré-visualização disponibiliza apenas parte do material.

Torne o trabalho de segurança da IA passível de revisão

Comece por um caso de uso de IA com consequências relevantes. Identifique como pode ser comprometido, escolha salvaguardas para as fronteiras relevantes e defina as evidências que demonstrarão que essas salvaguardas estão a funcionar. Atribua a cada ação um responsável e um gatilho de revisão.

A Secani liga requisitos, riscos, controlos, evidências, responsáveis e decisões de revisão num espaço de trabalho partilhado de segurança e conformidade. Fale com a Secani sobre a organização do seu trabalho de segurança da IA, para que as equipas vejam o que foi avaliado, o que exige atenção e quem é responsável.