O NIST AI 100-2 é a taxonomia de ataques à IA publicada pelo instituto norte-americano de normas e tecnologia: um vocabulário comum da aprendizagem automática adversarial que classifica e codifica as formas de envenenar, enganar, extrair ou desviar um sistema de IA. Para uma equipa europeia, interessa por uma razão prática: o artigo 15.º do AI Act exige proteção contra estes ataques, mas não diz como a provar. Neste artigo, transformamos o NIST AI 100-2 num registo de ameaças, num quadro de correspondência e num dossiê de prova.
O essencial
- O NIST AI 100-2e2025 (março de 2025) é a referência de vocabulário para os ataques à IA: pela nossa contagem, 5 categorias de violação e 25 identificadores de ataque <code>NISTAML</code>.
- Não é um instrumento de conformidade: não cita o AI Act nem qualquer norma ISO/IEC e não decide que risco aceitar.
- O artigo 15.º, n.º 5, enumera as mesmas classes de ataque; os identificadores servem de chave primária para o registo de ameaças, os testes e a documentação técnica.
- As normas que darão conteúdo técnico ao artigo 15.º chegaram em 2026: ETSI EN 304 223, <code>ISO/IEC 27090</code> e, ainda em projeto, a <code>prEN 18282</code>.
- As páginas do NIST dizem agora «Super Intelligence», mas o identificador NIST AI 100-2e2025 não mudou.
O que é o NIST AI 100-2 e o que não é
O título completo é «Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations». A edição em vigor, o NIST AI 100-2e2025, foi aprovada pelo Editorial Review Board do NIST a 20 de março de 2025 e anunciada pelo CSRC a 24 de março (página da publicação). Sucede ao NIST AI 100-2e2023, publicado em janeiro de 2024. Assinam Apostol Vassilev (NIST), Alina Oprea (Northeastern University), Alie Fordyce e Hyrum Anderson (Cisco), Xander Davies (UK AI Security Institute) e Maia Hamin (US AI Safety Institute).
Pela nossa contagem, o NIST AI 100-2e2025 tem 127 páginas e 449 referências numeradas, contra 107 páginas e 354 referências em 2023. O glossário final dá à equipa de segurança, ao jurista e ao fornecedor as mesmas palavras para o mesmo ataque.
O estatuto é voluntário. Uma nota de rodapé precisa que o texto «does not establish any legal standard or any other legal requirement or defense under any law». O documento retoma os conceitos de segurança, resiliência e solidez do NIST AI RMF e, como diz o sumário executivo, não faz recomendações sobre tolerância ao risco.
O que mudou entre o NIST AI 100-2e2023 e o NIST AI 100-2e2025
A mudança mais útil é a introdução dos identificadores estáveis <code>NISTAML</code>, inexistentes em 2023. O termo «abuse», usado para as violações próprias da IA generativa, passou a «misuse». A nova edição acrescenta uma secção dedicada à cadeia de abastecimento da IA generativa e secções novas sobre a segurança dos agentes e sobre benchmarks. Para uma introdução às famílias de ataque, ver o nosso guia sobre IA adversarial.
A etiqueta «Super Intelligence»
Uma ordem executiva norte-americana de 29 de setembro de 2026 (ficha da Casa Branca) obriga as agências federais a escrever «Super Intelligence» em vez de «Artificial Intelligence» nas comunicações oficiais. A página do NCCoE chama-se agora «Super Intelligence: Adversarial Machine Learning» e, a 20 de outubro de 2026, os overlays COSAiS passaram a COSIS, com a garantia de que os documentos já publicados não foram alterados. O identificador NIST AI 100-2e2025 mantém-se. Em março de 2025, o NIST anunciou atualizações anuais; a 22 de outubro de 2026 não encontrámos qualquer edição E2026 nem projeto público.
Como está construída a taxonomia
O NIST AI 100-2 cruza cinco dimensões. A primeira é o tipo de sistema: IA preditiva ou IA generativa. A segunda é a fase do ciclo de vida em que o ataque ocorre, do treino à implementação. A terceira são os objetivos do atacante: disponibilidade, integridade e privacidade, a que se junta, na IA generativa, a utilização indevida («misuse»). A quarta são as capacidades do atacante: controlo dos dados de treino, controlo do modelo, acesso por consulta ou, nos sistemas com RAG e ferramentas, controlo dos recursos que o modelo vai ler. A quinta é o conhecimento do atacante: caixa branca, caixa preta ou caixa cinzenta.
Sobre esta grelha, a edição de 2025 define cinco categorias de violação:
- <code>NISTAML.01</code> disponibilidade;
- <code>NISTAML.02</code> integridade;
- <code>NISTAML.03</code> privacidade;
- <code>NISTAML.04</code> utilização indevida;
- <code>NISTAML.05</code> cadeia de abastecimento.
Por baixo destas categorias encontram-se 25 identificadores de ataque. Porque é que isto importa para um registo? Porque um identificador estável é uma chave primária. Os nomes dos ataques mudam com o fornecedor da ferramenta; <code>NISTAML.033</code> continuará a designar a inferência de pertença quando o scanner for substituído.
Os identificadores ligam-se ainda às técnicas da MITRE ATLAS e às entradas do OWASP Top 10 para LLM, que trazem o detalhe operacional que a taxonomia não pretende dar. Na nossa leitura, o NIST AI 100-2 oferece a melhor chave disponível para três objetos que costumam viver separados: o registo de ameaças de IA, o plano de testes e o dossiê do artigo 15.º. Quem já mantém um programa de segurança da IA não precisa de reescrever os controlos: basta anotar cada um com os identificadores que cobre.
Ataques à IA preditiva: evasão, envenenamento e privacidade
<b>Evasão.</b> A evasão (<code>NISTAML.022</code>) altera uma entrada no momento da inferência para provocar um erro, sem tocar no modelo. A variante em caixa preta (<code>NISTAML.025</code>) dispensa o conhecimento dos pesos: basta consultar o modelo. A transferibilidade agrava o problema, porque um exemplo adversarial construído contra um modelo substituto engana muitas vezes o modelo-alvo. O caso clássico é o sinal de STOP lido como limite de velocidade depois da colocação de autocolantes.
<b>Envenenamento.</b> O NIST AI 100-2 distingue o envenenamento que ataca a disponibilidade (<code>NISTAML.013</code> envenenamento de dados, <code>NISTAML.011</code> envenenamento de modelo, <code>NISTAML.012</code> envenenamento com etiqueta limpa, <code>NISTAML.014</code> ataques de energia e latência), o envenenamento dirigido (<code>NISTAML.024</code>), as portas traseiras (<code>NISTAML.023</code>, e <code>NISTAML.021</code> na variante com etiqueta limpa) e o envenenamento de modelo que visa a integridade (<code>NISTAML.026</code>). Soma-se o envenenamento pela cadeia de abastecimento (<code>NISTAML.051</code>).
<b>Privacidade.</b> Quatro identificadores: extração de modelo (<code>NISTAML.031</code>), reconstrução de dados (<code>NISTAML.032</code>), inferência de pertença (<code>NISTAML.033</code>) e inferência de propriedades (<code>NISTAML.034</code>).
O NIST enumera as mitigações habituais: treino adversarial, suavização aleatória («randomized smoothing») e verificação formal contra a evasão; saneamento dos dados e inspeção do modelo contra o envenenamento; privacidade diferencial contra os ataques à privacidade. O aviso que as acompanha pesa mais do que a lista: as mitigações são sobretudo empíricas e não existem provas de segurança de base teórica para os algoritmos de aprendizagem automática mais usados.
A consequência para quem usa o NIST AI 100-2 é clara: declarar «aplicámos treino adversarial» não prova nada. É preciso mostrar contra que identificadores, com que orçamento de ataque e com que taxa de sucesso residual. O red teaming de IA é a única forma de medir o que a mitigação cobre de facto.
Ataques à IA generativa: cadeia de abastecimento, prompts, injeção indireta e agentes
Na IA generativa, a superfície de ataque muda. A injeção de prompts (<code>NISTAML.018</code>) cobre a solicitação direta e os jailbreaks: o utilizador escreve e o modelo obedece a quem não devia. A injeção indireta (<code>NISTAML.015</code>) é mais insidiosa: a instrução maliciosa chega através de um documento, de uma página web ou de um email que o sistema recupera. Pode até servir ataques de disponibilidade, ao injetar tarefas de fundo demoradas (<code>NISTAML.017</code>).
O NIST AI 100-2 enumera ainda os resultados desalinhados (<code>NISTAML.027</code>), a extração do prompt de sistema (<code>NISTAML.035</code>), a fuga de informação das interações dos utilizadores (<code>NISTAML.036</code>), os ataques aos dados de treino (<code>NISTAML.037</code>), a extração de dados (<code>NISTAML.038</code>) e o comprometimento de recursos ligados ao sistema (<code>NISTAML.039</code>). A cadeia de abastecimento tem agora secção própria no NIST AI 100-2: modelos pré-treinados descarregados de repositórios públicos, conjuntos de dados de afinação e dependências de software são vetores de envenenamento.
<b>Agentes.</b> O NIST reconhece, na secção 3.5, que a investigação em segurança focada especificamente nos agentes «is still in its early stages». O risco, esse, já é concreto: quando um agente usa ferramentas, uma injeção indireta deixa de produzir apenas texto errado e passa a executar código ou a exfiltrar dados com as permissões do agente. Ver o nosso artigo sobre segurança da IA agêntica.
Para testar, o NIST cita benchmarks e ferramentas como JailbreakBench, HarmBench, AgentDojo, Garak e PyRIT. O perfil de IA generativa NIST AI 600-1 completa esta parte do lado da gestão do risco.
O que o NIST AI 100-2 deixa deliberadamente de fora
Fizemos a contagem com pypdf: o NIST AI 100-2e2025 não menciona uma única vez o AI Act nem qualquer norma ISO/IEC; a palavra «compliance» aparece uma vez e «regulation» duas. Não é descuido. A secção 4.2.5 assume-o: «A key question that this taxonomy deliberately leaves aside is how organizations can make decisions about the development and use of AI systems in light of evidence about the increasing diversity of AML attacks and the efficacy and limitations of available mitigations.»
Por outras palavras, a taxonomia diz o que pode acontecer e o que a literatura sabe fazer contra isso, mas recusa-se a dizer como decidir. Ficam igualmente fora do âmbito os ataques clássicos de cibersegurança contra a plataforma (servidores, redes, credenciais), as falhas de conceção não adversariais e a definição da tolerância ao risco. O NIST lembra ainda, com base em investigação recente, que enquanto um modelo tiver alguma probabilidade de um comportamento indesejado, haverá um prompt capaz de o desencadear.
É exatamente este vazio que o Regulamento Europeu de Inteligência Artificial preenche. O artigo 9.º exige um sistema de gestão de riscos que cubra a utilização indevida razoavelmente previsível e, no n.º 5, que o risco residual seja considerado aceitável. O anexo IV, ponto 2, alínea h), pede que a documentação técnica descreva as medidas de cibersegurança adotadas. A decisão que o NIST deixa de lado é, na Europa, uma obrigação com assinatura.
Quem trabalha com o NIST CSF conhece a lógica: um catálogo de ameaças, como o da ENISA em Securing Machine Learning Algorithms (2021), alimenta a análise de risco mas não a substitui.
Do NIST AI 100-2 ao artigo 15.º, n.º 5, do AI Act: quadro de correspondência
O artigo 15.º, n.º 5, do Regulamento (UE) 2024/1689 exige resistência a terceiros não autorizados que explorem vulnerabilidades e determina, em paráfrase fiel (não na letra exata da versão portuguesa), que as soluções técnicas para as vulnerabilidades específicas da IA incluam, quando adequado, medidas para prevenir, detetar, responder, resolver e controlar ataques que procurem manipular o conjunto de dados de treino (envenenamento de dados) ou componentes pré-treinados usados no treino (envenenamento de modelos), entradas concebidas para levar o modelo a errar (exemplos adversariais ou evasão do modelo), ataques à confidencialidade ou falhas do modelo (texto comentado).
O quadro seguinte é trabalho nosso, não do NIST nem da Comissão.
| Termo do artigo 15.º, n.º 5 | Classes e identificadores NIST AI 100-2 | Prova a manter no dossiê |
|---|---|---|
| Envenenamento de dados | <code>NISTAML.013</code>, <code>NISTAML.012</code>, <code>NISTAML.024</code>, portas traseiras <code>NISTAML.021</code> e <code>NISTAML.023</code> | Registos de proveniência e saneamento dos dados de treino, testes de envenenamento, ligação à governação de dados do artigo 10.º |
| Envenenamento de modelos (componentes pré-treinados) | <code>NISTAML.011</code>, <code>NISTAML.026</code>, cadeia de abastecimento <code>NISTAML.051</code> | Lista de materiais de IA, proveniência do modelo e verificação de hashes, declarações dos fornecedores |
| Exemplos adversariais ou evasão do modelo | <code>NISTAML.022</code>, <code>NISTAML.025</code> e, nos sistemas generativos, <code>NISTAML.018</code> e <code>NISTAML.015</code> (leitura nossa) | Plano e resultados dos testes adversariais, métricas de resistência na secção de testes do anexo IV |
| Ataques à confidencialidade | <code>NISTAML.031</code> a <code>NISTAML.039</code> (extração, inferência de pertença e de propriedades, extração de prompts e de dados) | Testes de ataques à privacidade, prova de limitação de pedidos e de filtragem das saídas, ligação à avaliação de impacto do RGPD |
| Falhas do modelo | Em grande parte fora do NIST AI 100-2 (falhas não adversariais) | Testes de exatidão e de resistência ao abrigo do artigo 15.º, n.os 1 a 4 |
| Ciclos de retroalimentação (artigo 15.º, n.º 4) | Envenenamento pela retroalimentação, <code>NISTAML.013</code> e <code>NISTAML.024</code> | Monitorização da deriva e dos dados de entrada, plano de acompanhamento pós-comercialização (artigo 72.º) |
Com o Omnibus Digital sobre a IA (Regulamento (UE) 2026/1744), o artigo 15.º aplica-se aos sistemas de IA de risco elevado do anexo III a partir de 2 de dezembro de 2027 e aos do anexo I a partir de 2 de agosto de 2028. Para os modelos de IA de finalidade geral com risco sistémico, o artigo 55.º, n.º 1, alíneas a) (avaliação com testes adversariais documentados) e d) (proteção de cibersegurança), aplica-se desde 2 de agosto de 2025, e a Comissão pode aplicar coimas aos fornecedores desde 2 de agosto de 2026. O capítulo Safety and Security do Código de Práticas para a IA de finalidade geral, de 10 de julho de 2025, operacionaliza avaliações, testes adversariais e mitigações de segurança.
As normas europeias que vão dar corpo ao artigo 15.º
<b>prEN 18282.</b> Projeto de norma europeia sobre cibersegurança dos sistemas de IA, preparado pelo CEN-CENELEC JTC 21 WG 5 para suportar o artigo 15.º. O inquérito público decorreu de 15 de maio a meados de julho de 2026 e a publicação está prevista entre o final de 2026 e o início de 2027. Só confere presunção de conformidade depois de citada no Jornal Oficial da União Europeia. Projeto confidencial: ficamos pelo nome e pelo estado.
<b>ETSI EN 304 223.</b> Publicada a 14 de janeiro de 2026 (comunicado do ETSI), define 13 princípios distribuídos por cinco fases do ciclo de vida: conceção segura, desenvolvimento, implementação, manutenção e fim de vida. Assenta na ETSI TS 104 223, e o ETSI anunciou o TR 104 159 para a IA generativa.
<b>ISO/IEC 27090:2026.</b> Primeira edição publicada em outubro de 2026, com 56 páginas (heise). É um guia, não uma norma certificável, e cobre envenenamento, manipulação de pesos, evasão, extração, inferência de pertença, inversão de modelo e injeção de prompts: quase todas as classes do NIST AI 100-2.
<b>A via do Cyber Resilience Act.</b> Pelo artigo 12.º do Regulamento (UE) 2024/2847, um sistema de IA de risco elevado que seja também um produto com elementos digitais considera-se conforme com os requisitos de cibersegurança do artigo 15.º quando cumpre o anexo I do CRA e o nível de proteção consta da declaração UE de conformidade do CRA. A exatidão e a resistência continuam sob o AI Act. Desde 11 de setembro de 2026 aplicam-se as obrigações de comunicação do CRA: para vulnerabilidades ativamente exploradas, alerta precoce em 24 horas, notificação em 72 horas e relatório final em 14 dias após a disponibilização de uma medida corretiva, através da plataforma única de comunicação da ENISA. O artigo 42.º, n.º 2, do AI Act acrescenta uma presunção para os sistemas certificados ao abrigo de um esquema do Regulamento (UE) 2019/881.
Em Portugal, a ANACOM foi designada, em setembro de 2025, como autoridade de fiscalização do mercado e ponto de contacto único para o AI Act, e o CNCS (Centro Nacional de Cibersegurança) é a autoridade nacional de cibersegurança. Um dossiê bem construído tem de ser legível pelas duas.
A nossa leitura: todas estas referências enumeram as mesmas classes de ataque. Um registo indexado pelos identificadores <code>NISTAML</code> pode ser reetiquetado para cada norma em vez de ser reconstruído, como já fazemos com a pilha de normas da ISO 42001.
Do NIST AI 100-2 ao dossiê de prova em sete passos
- <b>Inventariar e classificar.</b> Cada sistema de IA é classificado como preditivo, generativo ou agêntico, e como sistema de risco elevado, modelo de finalidade geral ou outro. A classificação determina que identificadores são pertinentes e que obrigações se aplicam. O nosso guia sobre sistemas de IA de risco elevado ajuda na triagem.
- <b>Modelar as ameaças.</b> Para cada sistema, percorrer os 25 identificadores do NIST AI 100-2 e registar as capacidades realistas do atacante: apenas acesso por consulta, API de afinação, ingestão de documentos no RAG, acesso a ferramentas. Os identificadores excluídos ficam registados com justificação.
- <b>Associar controlos.</b> Cada identificador retido liga-se a um ou mais controlos. A MITRE ATLAS e o OWASP dão o detalhe ao nível da técnica.
- <b>Testar.</b> Testes adversariais e red teaming com as ferramentas que o NIST cita, como Garak, PyRIT ou AgentDojo. Registar método, âmbito, versão do modelo e resultados, porque um teste sem âmbito escrito não prova nada perante uma autoridade.
- <b>Decidir e assinar o risco residual.</b> Para cada identificador, alguém com autoridade declara se o risco residual é aceitável. É a decisão que o NIST deixa de lado e que o artigo 9.º, n.º 5, exige.
- <b>Redigir a documentação.</b> A secção de cibersegurança do anexo IV, ponto 2, alínea h), e a parte da declaração relativa ao artigo 15.º remetem para os identificadores do NIST AI 100-2. Um organismo notificado consegue assim seguir o fio do risco até à prova (ver avaliação da conformidade).
- <b>Monitorizar e comunicar.</b> Acompanhamento pós-comercialização (artigo 72.º), comunicação de incidentes graves (artigo 73.º), alerta precoce de 24 horas do CRA para vulnerabilidades ativamente exploradas e revisão anual alinhada com o ciclo de atualização anunciado pelo NIST.
O software de gestão de riscos de IA da AI Sigil reúne este registo, os testes e as decisões de risco residual num único dossiê ligado aos artigos do AI Act.
Perguntas frequentes
<b>O NIST AI 100-2 é obrigatório na Europa?</b>
Não. É uma publicação voluntária do NIST, que declara não criar qualquer requisito legal. Na Europa, as obrigações vêm do AI Act: o artigo 15.º para os sistemas de risco elevado e o artigo 55.º para os modelos de finalidade geral com risco sistémico. Ainda assim, o NIST AI 100-2 é a forma mais económica de dar nome aos ataques que esses artigos enumeram, com identificadores públicos que qualquer autoridade consegue verificar.
<b>O que mudou entre as edições de 2023 e de 2025?</b>
O NIST AI 100-2e2025 introduziu os identificadores <code>NISTAML</code>: 5 categorias de violação e 25 identificadores de ataque, pela nossa contagem. O termo «abuse» passou a «misuse», surgiu uma secção dedicada à cadeia de abastecimento da IA generativa e foram acrescentadas secções sobre a segurança dos agentes e sobre benchmarks. O documento cresceu de 107 para 127 páginas e de 354 para 449 referências.
<b>O NIST AI 100-2 cobre os agentes de IA?</b>
Em parte. A edição de 2025 tem uma secção sobre agentes e cita benchmarks como AgentDojo e AgentHarm, mas admite que a investigação específica ainda está numa fase inicial. Os identificadores mais relevantes são a injeção indireta de prompts (<code>NISTAML.015</code>) e o comprometimento de recursos ligados (<code>NISTAML.039</code>), porque um agente com ferramentas transforma uma instrução injetada em execução de código ou em exfiltração de dados. Os controlos exigem ainda uma modelação de permissões.
<b>Como se relaciona com a MITRE ATLAS e o OWASP Top 10 para aplicações LLM?</b>
São complementares. O NIST AI 100-2 fixa o vocabulário e a classificação; a MITRE ATLAS descreve táticas e técnicas observadas; o OWASP Top 10 para aplicações LLM prioriza os riscos para quem desenvolve aplicações. Na prática, usamos o identificador <code>NISTAML</code> como chave do registo e anotamos, para cada um, as técnicas ATLAS e as entradas OWASP correspondentes. Quando uma das listas é revista, atualiza-se a anotação e não o registo.
<b>Seguir o NIST AI 100-2 basta para cumprir o artigo 15.º do AI Act?</b>
Não. A taxonomia ajuda a identificar e a nomear as ameaças, mas não decide que risco é aceitável, não cobre as falhas de modelo não adversariais nem a cibersegurança clássica da plataforma e não produz a documentação exigida. O artigo 15.º pede medidas contra os ataques; o artigo 9.º pede uma decisão sobre o risco residual; o anexo IV pede a descrição das medidas. A taxonomia é o ponto de partida do dossiê, não o dossiê.
<b>Porque é que as páginas do NIST dizem agora «Super Intelligence»?</b>
Por causa de uma ordem executiva norte-americana de 29 de setembro de 2026 que manda as agências federais usar «Super Intelligence» em vez de «Artificial Intelligence» nas comunicações oficiais. A página do NCCoE passou a «Super Intelligence: Adversarial Machine Learning». O NIST garante que os documentos publicados não foram alterados: o identificador NIST AI 100-2e2025 continua válido, e a ordem não cria obrigações para empresas privadas.
Conclusão
O NIST AI 100-2 não foi escrito para a conformidade europeia, e é precisamente por isso que serve: dá nomes e códigos estáveis aos ataques que o artigo 15.º do AI Act enumera sem os definir, sem impor qualquer decisão sobre o risco. Essa decisão cabe a cada organização, e o regulamento exige que fique escrita e assinada. Com as normas europeias a chegar entre 2026 e 2027 e com o CRA já a exigir comunicações em 24 horas, adiar o registo de ameaças tem um custo. A nossa recomendação é começar pelos sistemas de risco elevado e pelos modelos generativos expostos a conteúdos externos: modelar as ameaças com os 25 identificadores, testar com red teaming, decidir e documentar. Quando chegar a próxima edição do NIST AI 100-2 ou a versão final da <code>prEN 18282</code>, bastará reetiquetar o registo, não reconstruí-lo.