O NIST AI Risk Management Framework: mapeando o conjunto principal para a prática de segurança

1. Introdução

Profissionais, fornecedores e formuladores de políticas tratam cada vez mais “o framework de segurança de IA da NIST” como se nomeasse uma única linha de base de controles. Não nomeia. A NIST publicou uma família de documentos voluntários sobre IA desde 2023, e a expressão é usada para pelo menos três coisas distintas: o próprio Artificial Intelligence Risk Management Framework (AI RMF) (NIST AI 100-1); o posterior Cybersecurity Framework Profile for Artificial Intelligence (NIST IR 8596); e, de forma mais solta, a união desses documentos com orientações sobre machine learning adversarial (NIST AI 100-2) e controles ordinários de cibersegurança (CSF 2.0, SP 800-53). Confundi-los produz dois modos de falha. Equipes que queriam um programa de segurança implementam apenas workshops de governança. Equipes que queriam IA confiável implementam apenas checklists de endurecimento de modelos.

O AI RMF foi publicado em 26 de janeiro de 2023 como NIST AI 100-1, sob mandato da National Artificial Intelligence Initiative Act de 2020. É voluntário, preserva direitos, não é específico de setor e independe de caso de uso. Seu objeto não é um sistema de informação no sentido do SP 800-37. Seu objeto é um sistema de IA sociotécnico, e seu critério de sucesso é confiabilidade (trustworthiness), e não apenas confidencialidade, integridade e disponibilidade. A NIST não entregou o framework como um PDF isolado. Entregou um Playbook complementar, um Roadmap de trabalhos futuros, um tratamento detalhado das características de IA confiável dentro do documento principal e um catálogo comunitário de implementações e crosswalks via o Trustworthy and Responsible AI Resource Center. Esses cinco recursos são o programa AI RMF original. Todo o restante da pilha NIST de IA — o Generative AI Profile (AI 600-1), o rascunho do Cyber AI Profile (IR 8596), a taxonomia adversarial (AI 100-2) e perfis para infraestrutura crítica — é uma especialização que se acopla a esse programa.

Este artigo é um mapa, não uma avaliação de modelos e não uma alegação de descoberta empírica. Lemos o corpus público da NIST até agosto de 2026 e as normas ao lado das quais ele foi concebido para se situar. Três observações estruturam o restante do texto.

O conjunto é o framework. O AI RMF 1.0 é a Parte I (como enquadrar risco de IA e o que significa “confiável”) mais a Parte II (quatro funções com categorias e subcategorias). O Playbook, o Roadmap, a discussão de características e o catálogo comunitário são como a NIST esperava que organizações operacionalizassem, estendessem e compartilhassem esse núcleo. Tratar o AI 100-1 como o programa inteiro subestima o que a NIST publicou no primeiro trimestre de 2023.

Segurança é uma característica, não o enquadramento. A NIST lista sete características de IA confiável: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; e fair, with harmful bias managed. Secure and resilient é uma linha dessa lista. As quatro funções — Govern, Map, Measure, Manage — são como uma organização persegue as sete, inclusive as tensões entre elas.

Instrumentos de cibersegurança encaixam; não substituem. O próprio comentário da NIST sobre o Cyber AI Profile é que CSF 2.0, AI RMF e o Profile devem ser usados juntos. O AI 100-2 fornece vocabulário de ataque para Measure e Manage. O SP 800-53 permanece o catálogo de controles para sistemas que precisam de um. ISO/IEC 42001 e o EU AI Act são regimes adjacentes, não documentos NIST, e devem ser crosswalked em vez de fundidos.

Contribuições. Este artigo faz quatro contribuições:

1. Reconstruímos o conjunto original de recursos do AI RMF e mostramos como o Playbook, o Roadmap, as características de confiabilidade e o catálogo comunitário se relacionam ao AI 100-1.
2. Localizamos cibersegurança dentro do modelo de sete características e explicitamos o que “secure and resilient” cobre e o que não cobre.
3. Mapeamos instrumentos NIST posteriores de segurança de IA sobre as quatro funções, incluindo CSF 2.0, IR 8596, AI 100-2, AI 600-1 e a nota conceitual de perfil para infraestrutura crítica.
4. Apresentamos um procedimento de uso e um exemplo trabalhado para um sistema agentico com modelo de linguagem, com modos de falha que seguem de tratar qualquer documento como o programa inteiro.

2. Contexto: risco de IA não é risco de sistema de informação

O Risk Management Framework clássico da NIST (SP 800-37) autoriza um sistema de informação. Categoriza o sistema, seleciona controles SP 800-53, avalia, autoriza operação e monitora. Esse ciclo continua necessário sempre que um sistema de IA roda em infraestrutura federal ou de outra forma controlada. Não é suficiente para IA, e a NIST diz isso: riscos de IA diferem de riscos de software tradicional em espécie, não só em grau.

Três diferenças importam para equipes de segurança.

A unidade de risco é sociotécnica. O comportamento de um sistema de IA depende de dados de treinamento, dados de avaliação, prompts, ferramentas, usuários e processos decisórios downstream. Um modelo confidencial e disponível ainda pode ser injusto, inseguro (unsafe) ou estrategicamente não conforme. O AI RMF, portanto, trata impactos em indivíduos, grupos, comunidades, organizações e sociedade como no escopo, não como externalidades para um escritório de ética separado.

Características de confiabilidade entram em conflito. Um sistema mais fácil de explicar pode vazar mais sobre dados de treinamento. Um sistema que recusa consultas de duplo uso pode ser menos “útil” para um objetivo definido pelo desenvolvedor. A NIST lista esse problema de tradeoff como prioridade do Roadmap em vez de fingir que as características formam um almoço grátis. Um programa de segurança que otimiza só robustez adversarial pode deslocar risco para fairness, privacidade ou safety sem reduzir o dano total.

O framework é voluntário e orientado a resultados. O AI 100-1 não contém um catálogo numerado de controles. Contém funções, categorias e subcategorias que descrevem resultados (“riscos de IA são identificados e documentados”) em vez de mecanismos (“implantar filtragem de entrada X”). O Playbook sugere ações; explicitamente não é um checklist a completar em ordem. Organizações que precisam de um sistema de gestão auditável devem recorrer à ISO/IEC 42001 ou vincular o AI RMF a um limite de autorização RMF existente — não inventar uma certificação a partir do próprio AI 100-1.

Esses fatos explicam a confusão de nomenclatura. Engenheiros de segurança ouvem “framework” e buscam CSF ou SP 800-53. Equipes de governança de IA ouvem “framework” e buscam AI 100-1. Ambos os instintos estão meio certos. O restante deste artigo trata de mantê-los acoplados ao mesmo sistema em vez de substituírem um ao outro.

3. O conjunto original de recursos do AI RMF

O lançamento de janeiro de 2023 da NIST foi um pacote, não um único arquivo. A tabela abaixo lista os cinco recursos que, na prática, as pessoas querem dizer com “o AI RMF”. Perfis e taxonomias posteriores são complementos, não membros desta tabela.

3.1 AI RMF 1.0 (NIST AI 100-1)

O AI 100-1 tem duas partes. A Parte I enquadra risco de IA: quem são os atores de IA, como o dano de IA difere do dano de software e o que significa “confiável”. A Parte II é o Core: quatro funções, cada uma decomposta em categorias e subcategorias.

Govern é transversal. É política organizacional, responsabilização, cultura, governança de terceiros e engajamento com partes afetadas. Map, Measure e Manage correm então como um ciclo sobre um dado sistema ou caso de uso de IA. Map estabelece contexto e inventaria impactos. Measure seleciona métodos, avalia características de confiabilidade e acompanha risco ao longo do tempo. Manage prioriza tratamentos, inclusive risco residual, resposta a incidentes e exposição a terceiros. A NIST apresenta isso como concorrente e iterativo, não como waterfall.

Duas escolhas estruturais passam fácil.

Primeiro, perfis são de primeira classe. Um perfil é uma implementação das funções para um contexto, tolerância a risco e envelope de recursos específicos. O Generative AI Profile (AI 600-1) e o perfil de infraestrutura crítica em preparação são instâncias de perfil, não frameworks concorrentes.

Segundo, o Core descreve resultados, não ferramentas. “MEASURE 2: AI systems are evaluated for trustworthy characteristics” não nomeia um fornecedor de red team, um benchmark de viés ou uma métrica de robustez adversarial. Essas escolhas ficam no Playbook, num perfil organizacional ou num complemento como o AI 100-2.

3.2 O Playbook

O Playbook é o companheiro de implementação. Para cada subcategoria oferece ações sugeridas, referências informativas e notas sobre documentação. A NIST é explícita em três restrições: o Playbook é voluntário; organizações podem usar quantas sugestões se aplicarem; e não é uma sequência a completar por inteiro. A primeira versão web completa foi anunciada em 30 de março de 2023, com o lançamento do Resource Center. A NIST declarou que o Playbook será atualizado após a revisão do AI RMF 1.0.

Para um leitor de segurança, o Playbook é onde “secure and resilient” vira tático — logging, avaliação, processos de incidente, questões de cadeia de suprimentos — sem virar SP 800-53. Se uma equipe precisa de um ID de controle que possa auditar, saiu do Playbook e deve dizer isso.

3.3 O Roadmap

O Roadmap é a lista de lacunas da NIST na época do 1.0, não um cronograma com datas de entrega. Prioridades publicadas incluem alinhamento com normas internacionais e crosswalks; test, evaluation, verification e validation (TEVV) expandido; perfis do AI RMF; orientação sobre tradeoffs entre características de confiabilidade; métodos para medir a eficácia do próprio AI RMF; estudos de caso; fatores humanos; explicabilidade ligada à gestão de risco; métodos para definir tolerâncias de risco razoáveis; e material educacional.

Várias dessas prioridades desde então viraram documentos próprios (perfis, taxonomias adjacentes a TEVV). Outras permanecem abertas, especialmente orientação sobre tradeoffs e medição de eficácia. Uma equipe que trata o 1.0 como doutrina finalizada se surpreenderá com o processo de revisão.

3.4 Características de IA confiável

As características não são um quinto PDF. São a Parte I do AI 100-1, e são o objeto do MEASURE 2. O ponto importante no nível do conjunto é que a NIST definiu “boa IA” antes de definir as quatro funções. As funções existem para perseguir essas características, inclusive quando puxam em direções opostas.

3.5 O catálogo comunitário (AIRC)

Em 30 de março de 2023 a NIST lançou o Trustworthy and Responsible AI Resource Center para hospedar conteúdo do Playbook, crosswalks, perspectivas e casos de uso contribuídos. Esse é o recurso frequentemente descrito informalmente como “banco de dados de gestão de risco de IA”: um catálogo de implementações comunitárias, não um banco de vulnerabilidades e não uma biblioteca de controles. Sua função é social — perfis e mapeamentos compartilhados — em vez de avaliação técnica. Não deve ser confundido com bancos de incidentes ou com o MITRE ATLAS.

4. Características de confiabilidade e a linha de segurança

O modelo de confiabilidade da NIST é a parte do AI RMF mais frequentemente ignorada por programas de segurança e mais frequentemente tratada como o programa inteiro por programas de IA responsável. Ambos os cortes perdem a estrutura.

4.1 Sete características

O AI 100-1 afirma que sistemas de IA confiáveis são, em combinação:

1. Valid and reliable — performam como previsto em condições esperadas e razoavelmente inesperadas, com limitações documentadas.
2. Safe — não colocam em risco vida, saúde, propriedade ou meio ambiente humanos sob condições de uso definidas.
3. Secure and resilient — resistem a eventos adversos inesperados, inclusive de acesso, uso ou interrupção não autorizados, e se recuperam.
4. Accountable and transparent — atores podem ser identificados, e informação sobre o sistema está disponível a quem precisa.
5. Explainable and interpretable — saída de IA e comportamento do sistema podem ser entendidos num nível adequado ao público e à decisão.
6. Privacy-enhanced — incorporam valores de privacidade como anonimato, confidencialidade e controle.
7. Fair, with harmful bias managed — gerenciam viés prejudicial e riscos relacionados de discriminação.

Validade é descrita como pré-requisito para as outras: um sistema inválido não pode ser justo ou seguro (safe) em sentido robusto. Além disso, a NIST não ranqueia as seis restantes. O Roadmap, em vez disso, sinaliza tradeoffs como problema aberto de pesquisa e orientação.

4.2 O que “secure and resilient” cobre

Na linguagem do RMF, secure and resilient é a característica que se sobrepõe à tríade CIA clássica e aos resultados do CSF. Inclui confidencialidade de pesos de modelo, dados de treinamento e prompts; integridade de dados, modelos e saídas de ferramentas; disponibilidade de inferência e do pipeline circundante; e resiliência sob ataque, shift de distribuição e falha operacional.

Por si só, não inclui:

• se o objetivo declarado do modelo corresponde aos valores do implantador (accountability);
• se recusas e política de duplo uso são adequadas (safety, frequentemente também fairness);
• se explicações são fiéis (explainability);
• se dados de treinamento ou logs criam dano de privacidade (privacy);
• se avaliações são estatisticamente válidas (validity).

Machine learning adversarial fica na fronteira. Evasão, envenenamento, ataques de privacidade e uso indevido generativo são eventos de segurança, mas também de validade, privacidade e safety. Por isso a NIST escreveu uma taxonomia dedicada em vez de dobrar AML inteiramente em Identify-Protect-Detect-Respond-Recover do CSF.

4.3 Como as quatro funções se aplicam à linha de segurança

Uma leitura só de segurança das quatro funções ainda tem conteúdo, e é mais estreita que um programa AI RMF completo:

Govern. Quem é dono de risco de modelo versus segurança de aplicação versus política de safety? Modelos de terceiros, corpora RAG e ferramentas estão no processo de risco de fornecedor? Existe política de uso aceitável que não seja só política de segurança da informação?

Map. O que é o sistema de IA — modelo, prompts, ferramentas, recuperação, avaliadores, humanos no loop? Quem é prejudicado se falhar fechado, falhar aberto ou for direcionado? Quais ambientes são treinamento, avaliação e produção, e o modelo consegue inferir a diferença?

Measure. Que testes existem para jailbreaks, prompt injection, exfiltração de dados, envenenamento, membership inference e abuso de ferramentas — e que testes existem para as características não de segurança que esses ataques podem induzir? Métricas são acompanhadas ao longo do tempo, ou só no lançamento?

Manage. Qual é o risco residual após mitigações? Qual é o caminho de incidente quando uma ação do modelo causa dano que não é incidente clássico de segurança? Como atualizações de modelo de terceiros são tratadas?

Isso ainda não é linha de base de controles. É uma forma de perceber que “fizemos red team uma vez” é atividade de Measure, não sistema de Govern ou Manage.

5. Complementos: cibersegurança e perfis especializados

Se o conjunto é o tronco, os documentos desta seção são os galhos que as pessoas mais frequentemente rotulam erroneamente como “o framework de segurança de IA da NIST”. São reais, úteis e mais estreitos.

5.1 CSF 2.0

O Cybersecurity Framework 2.0 organiza resultados de cibersegurança em seis funções: Govern, Identify, Protect, Detect, Respond, Recover. É neutro em tecnologia e já amplamente implantado. Não sabe o que é peso de modelo, prompt injection ou vazamento de chain-of-thought. Usar só CSF num sistema LLM tipicamente captura a conta de nuvem e a aplicação circundantes e perde modos de falha específicos do modelo.

A sobreposição lexical de “Govern” com o AI RMF é coincidência de nomenclatura e alinhamento de espírito. Govern do CSF é governança de cibersegurança. Govern do AI RMF é governança de confiabilidade de IA, que inclui segurança e muito mais.

5.2 Cyber AI Profile (NIST IR 8596)

O Cybersecurity Framework Profile for Artificial Intelligence, publicado como rascunho preliminar inicial em dezembro de 2025, é o documento NIST mais próximo de um “framework de segurança de IA” no sentido coloquial. Aplica resultados do CSF 2.0 à IA e organiza-se em três áreas de foco:

1. Secure — cibersegurança de componentes do sistema de IA (modelos, dados, pipelines, agentes, infraestrutura).
2. Defend — usar IA para reforçar operações defensivas, inclusive as novas falhas que isso introduz.
3. Thwart — resiliência contra ataques habilitados por IA (phishing automatizado, malware, intrusão).

A intenção declarada da NIST é que CSF 2.0, AI RMF e este Profile sejam usados juntos, não que o Profile substitua o AI 100-1. O rascunho atribui níveis de prioridade a considerações como orientação de planejamento; organizações devem ajustar essas prioridades à própria tolerância a risco. Na redação deste texto o documento permanece rascunho no caminho para um initial public draft após o período de comentários de janeiro de 2026.

5.3 Taxonomia de machine learning adversarial (NIST AI 100-2)

O NIST AI 100-2 é um relatório de terminologia e taxonomia, atualizado em 2025. Classifica ataques por paradigma de aprendizado, estágio do ciclo de vida, objetivos do atacante, capacidades e conhecimento. Para sistemas preditivos as classes principais são evasão, envenenamento e ataques de privacidade. Para sistemas generativos acrescenta misuse. Também discute mitigações e seus limites.

Este é o documento a citar quando Measure precisa de linguagem compartilhada para “o que aconteceu com o modelo”. Não é framework de governança nem perfil CSF. ATLAS é um threat landscape prático relacionado; AI 100-2 é o vocabulário NIST destinado a informar normas e guias de prática futuros.

5.4 Generative AI Profile (NIST AI 600-1)

O NIST AI 600-1 é um perfil AI RMF, não um perfil CSF. Aplica Govern–Map–Measure–Manage a riscos únicos ou amplificados em sistemas generativos: confabulação, privacidade de dados, segurança da informação, conteúdo nocivo, homogeneização, configuração humano–IA e vários outros. Uma equipe que implanta LLMs ou agentes e implementa o 1.0 sem o 600-1 usa o quadro geral sem a lista de riscos GenAI específica que a NIST já escreveu.

5.5 SP 800-53 e overlays de controles de IA

O SP 800-53 permanece o catálogo de controles para sistemas federais dos EUA e para muitos programas privados que já o usam. A NIST vem desenvolvendo overlays de controles orientados a IA: seleções e interpretações de controles existentes para tipos de sistema de IA, em vez de um catálogo substituto. Até overlays finalizarem, o caminho honesto de implementação é: RMF autoriza a plataforma; AI RMF governa o modelo; CSF / Cyber AI Profile priorizam resultados cibernéticos; SP 800-53 (ou catálogo privado) instancia controles técnicos.

5.6 Perfil de infraestrutura crítica

Em abril de 2026 a NIST publicou uma nota conceitual para um perfil AI RMF sobre IA confiável em infraestrutura crítica. O público são operadores de IC em contextos IT, OT e ICS que precisam declarar requisitos de confiabilidade a fornecedores e equipes internas. É um perfil setorial do AI 100-1, não substituto de regulação cibernética setorial.

5.7 Revisão do AI RMF 1.0

A NIST declara que o AI RMF 1.0 está sendo revisado no âmbito do White House AI Action Plan, e que o Playbook será atualizado após essa revisão. Qualquer artigo de mapeamento, inclusive este, deve ser lido como mapa do conjunto da era 1.0 mais os complementos publicados até meados de 2026 — não como congelamento do texto 2.0.

6. Um mapa de uso

A pergunta prática não é qual documento é “o” framework. É qual documento responde a qual pergunta.

1. Quais resultados devemos? → AI RMF 1.0 + perfil (600-1 ou setorial)
2. Como podemos persegui-los? → Playbook + exemplos AIRC
3. Quais são os resultados cibernéticos? → CSF 2.0 + Cyber AI Profile
4. O que pode acontecer com o modelo? → AI 100-2 (+ ATLAS)
5. Quais controles instanciam isso? → SP 800-53 / overlay / ISO 27001

Pular uma linha é comum; alegar que a linha pulada foi coberta é o erro usual.

6.1 Procedimento

1. Nomeie o sistema e os atores (Map). Você deve anotar o(s) modelo(s), repositórios de dados, ferramentas, avaliadores, usuários e partes afetadas. Se esse inventário não existir, nem CSF nem Playbook salvarão o programa.

1. Selecione um perfil. Sistemas gerais usam o 1.0 como está. Sistemas generativos e agenticos somam AI 600-1. Operadores de IC devem acompanhar o perfil de infraestrutura crítica. Um perfil é decisão de escopo, não papelada extra por si mesma.

1. Estabeleça Govern antes de teatro de Measure. Atribua donos para risco de modelo, segurança de aplicação, política de safety e IA de fornecedor. Decida tolerância a risco explicitamente — o item 9 do Roadmap existe porque esse passo costuma ser simulado.

1. Puxe cibersegurança pelo CSF, não por metáfora. Mapeie considerações Secure / Defend / Thwart do IR 8596 sobre categorias CSF existentes. Não reescreva o ISMS em torno de subcategorias do AI 100-1.

1. Dê a Measure um vocabulário de ataque. Use classes do AI 100-2 (evasão, envenenamento, privacidade, misuse) como taxonomia mínima para testes centrados no modelo. Acrescente avaliações não de segurança para validade, fairness, privacidade e safety ou pare de alegar essas características.

1. Instancie controles num catálogo real. SP 800-53, mapeamento de controles de um provedor de nuvem ou ISO/IEC 27001 podem abrigar os objetos técnicos. Registre risco residual em Manage, inclusive danos que nunca aparecerão num SIEM.

1. Documente o espaço negativo. Se a organização implementa só Secure-and-resilient + CSF, diga “operamos um programa de cibersegurança de IA informado pelo AI RMF”, não “implementamos o AI RMF”.

6.2 Exemplo trabalhado: um sistema de chat agentico

Considere um assistente hospedado que recupera documentos privados, chama ferramentas e age em vários turnos — a forma de muitos agentes LLM em produção.

Map. O sistema não é “o modelo”. É o modelo, o system prompt, corpora recuperados, APIs de ferramentas, memória de sessão, avaliadores e operadores humanos. Partes afetadas incluem usuários finais, terceiros cujos dados aparecem na recuperação e quem está do outro lado de uma chamada de ferramenta. A lista de riscos GenAI do AI 600-1 está no escopo; uma leitura só de ML preditivo do 1.0 não está.

Govern. Separe donos para: segurança de aplicação (authn/z, isolamento de tenant); controle de mudança de modelo e prompt; política de safety (recusas, duplo uso); e modelos de fornecedor. Govern de terceiros (GOVERN 6 / MANAGE 3) aplica-se a APIs de modelos fundacionais como a SaaS.

Measure. Classes misuse e privacidade do AI 100-2 cobrem jailbreaks, prompt injection via documentos recuperados e exfiltração de dados por ferramentas. Não cobrem confabulação que prejudica um usuário sem atacante, ou falhas sistemáticas de recusa em alguns idiomas. Essas são medições de validade, safety e fairness. Um relatório de red team que só conta taxa de sucesso de ataque é Measure incompleto em relação ao 600-1.

Manage. Tipos de incidente incluem violações clássicas e ações de ferramenta concluídas nocivas, vazamento de segredos em logs e alignment-faking ou raciocínio enganoso descoberto se o modelo for avaliado para isso. Recuperação pode significar reverter prompt ou modelo, não só rotacionar credenciais.

Overlay CSF / IR 8596. Secure cobre a pilha de serving e pipeline de treinamento ou fine-tuning. Defend cobre qualquer uso de modelos em fluxos SOC — e o risco de prompt injection que isso cria. Thwart cobre atacantes usando outros modelos contra este sistema (credential stuffing com iscas geradas, descoberta automatizada de vulnerabilidades).

Nada disso exige fingir que IR 8596 é AI 100-1, ou que AI 100-1 é SP 800-53.

6.3 Modos de falha

Observamos quatro erros de categoria recorrentes em alegações públicas (não amostra estatística; tipologia):

• Conformidade de PDF. Tratar uma planilha de Playbook completa como implementação do MEASURE 2.
• Sinécdoque de segurança. Equiparar implementação do AI RMF a uma avaliação de robustez adversarial.
• Sinécdoque de ética. Equiparar implementação do AI RMF a um dashboard de fairness sem caminho de incidente.
• Teatro de certificação. Anunciar “certificado NIST AI RMF” apesar de a NIST não oferecer tal certificação para o 1.0.

O último é o mais enganoso. ISO/IEC 42001 é o sistema de gestão de IA certificável. O AI RMF é um framework voluntário de resultados que pode ser alinhado a esse sistema.

7. Trabalhos relacionados

A própria pilha NIST. Este artigo é leitura dessa pilha, não concorrente dela. Fontes primárias são AI 100-1, Playbook e Roadmap, AIRC, AI 600-1, AI 100-2, CSF 2.0 e IR 8596. SP 800-37 e SP 800-53 permanecem a espinha dorsal de autorização e controles para sistemas de informação federais.

Sistemas de gestão internacionais e lei. ISO/IEC 42001 especifica um sistema de gestão de IA auditável. ISO/IEC 22989 fornece vocabulário; ISO/IEC 42005 trata avaliação de impacto. O Roadmap do AI RMF já listou crosswalks para essa família como prioridade alta. O EU AI Act é regulação vinculante por níveis de risco para sistemas no seu escopo. Não é perfil NIST. Crosswalks são apropriados; identidade, não. Os OECD AI Principles ficam num patamar ainda mais alto e informaram grande parte do vocabulário de IA confiável 2019–2023 que a NIST destilou.

Diretrizes de desenvolvimento seguro. As diretrizes da CISA e NCSC para desenvolvimento seguro de sistemas de IA ficam mais próximas da área Secure do IR 8596 do que do AI 100-1 como um todo. São entrada útil para Measure/Manage, não modelo Govern substituto para fairness ou accountability.

Threat landscapes. O MITRE ATLAS cataloga táticas adversárias contra sistemas de IA. Biggio e Roli fazem survey da primeira década de ML adversarial. Weidinger et al. taxonomizam riscos de modelos de linguagem além do cenário adversarial. Amodei et al. enquadraram risco de acidente que não é primariamente problema de atacante. O AI RMF é deliberadamente mais amplo que qualquer uma dessas listas; AI 100-2 é o documento NIST que mais diretamente absorve o subconjunto adversarial.

Alinhamento como problema de confiabilidade. Trabalho sobre assistentes helpful, honest and harmless e treinamento constitucional aborda safety, accountability e validade mais que cibersegurança clássica. Ainda pertence a Map e Measure para sistemas agenticos: um modelo que cumpre estrategicamente sob supervisão é modo de falha relevante para Manage mesmo quando nenhum controle SP 800-53 falhou. O AI RMF não usa “alignment” como primitivo; organizações que se importam devem tratá-lo como risco nomeado em Map, não sinônimo de secure-and-resilient.

8. Discussão

8.1 O que este mapeamento não faz

Não medimos se organizações que alegam alinhamento ao AI RMF diferem em taxas de incidente das que não alegam. O item 5 do Roadmap (eficácia do framework) permanece frente de trabalho aberta da NIST. Também não produzimos overlay de controles novo nem crosswalk completo para ISO/IEC 42001 ou EU AI Act; esses são projetos do tamanho de documentos, alguns já no AIRC.

O artigo é, portanto, uma contribuição cartográfica. Seu modo de falha é o usual de mapas: parecer mais autoritativo que o terreno, especialmente enquanto o 1.0 está em revisão.

8.2 Frameworks voluntários e linguagem de procurement

Como o AI 100-1 é voluntário e orientado a resultados, é mau objeto de cláusulas binárias de procurement (“fornecedor deve estar em conformidade com AI RMF”). Uma cláusula mais precisa nomeia o perfil (ex.: AI 600-1), as características no escopo, a evidência esperada para Measure e o catálogo de controles usado para instanciar objetos técnicos Protect/Detect. Onde se exige sistema de gestão certificável, ISO/IEC 42001 é o instrumento desenhado. Onde se exige conjunto de controles de segurança certificável, SP 800-53 ou equivalente permanece o instrumento desenhado.

8.3 A lacuna de medição

Govern e Map podem ser feitos com workshops. Measure não pode. O item TEVV do Roadmap da NIST existe porque avaliação sociotécnica de sistemas de IA ainda é metodologicamente fina em relação às alegações que compradores querem ouvir. Equipes de segurança não devem preencher essa lacuna sobrecarregando taxas pass/fail de red team para substituir validade, fairness e safety. Essa substituição é como “framework de segurança de IA da NIST” vira frase de marketing.

8.4 Agentes, ferramentas e o texto de 2023

O AI 100-1 é anterior à implantação generalizada de agentes que usam ferramentas. AI 600-1 e IR 8596 são os documentos que começam a alcançar. Um agente que pode enviar e-mail, mudar infraestrutura ou escrever código expande o inventário Map e a taxonomia de incidentes Manage. Não exige novo nome de marketing para o AI RMF; exige perfil que nomeie ferramentas, memória e autorização como componentes de primeira classe do sistema.

8.5 Risco de revisão

Leitores que implementam a partir deste artigo devem acompanhar a revisão do 1.0. Nomes de funções podem persistir enquanto subcategorias, expectativas de perfil e ações do Playbook mudam. A alegação estrutural que nos importa — conjunto versus complementos; características versus controles — provavelmente sobrevive; citações em nível de tabela a subcategorias do 1.0 podem não.

9. Conclusão

Não existe um único documento NIST intitulado AI Security Framework. Existe um programa de 2023 — o conjunto AI RMF de AI 100-1, Playbook, Roadmap, características de confiabilidade e catálogo comunitário — e um conjunto de instrumentos posteriores que aprofundam cibersegurança, IA generativa e prática setorial.

Segurança é uma das sete características de IA confiável. As quatro funções operacionalizam as sete. CSF 2.0 e o rascunho do Cyber AI Profile são a camada de resultados de cibersegurança. AI 100-2 é o vocabulário de ataque. SP 800-53 (e overlays futuros) são a camada de controles. ISO/IEC 42001 e EU AI Act são regimes adjacentes.

Usados juntos, esses documentos são coerentes. Usados como sinônimos, produzem programas que são ou segurança com vocabulário de ética, ou ética sem caminho de incidente. A correção mais barata é linguística: diga qual documento responde a qual pergunta, e pare de alegar o restante.

Agradecimentos

Este artigo é uma leitura estruturada de documentos NIST e normas relacionadas disponíveis publicamente. Não é afiliado ao NIST, não constitui aconselhamento jurídico ou de conformidade, e não afirma que qualquer produto implemente o AI RMF.

@online{violet2026nistairmf,
  author = {Haigh, John},
  title = {O NIST AI Risk Management Framework: mapeando o conjunto principal para a prática de segurança},
  date = {2026-09-12},
  year = {2026},
  url = {https://www.violetai.ca/pt-BR/research/nist-ai-rmf/paper},
}