Summary: NIST AI 100-1 — a voluntary, sector-agnostic framework organised around seven trustworthiness characteristics and four functions (GOVERN, MAP, MEASURE, MANAGE).
Sources: raw/Laws/NIST.AI.100-1.md
Last updated: 2026-07-28
Directed by the National Artificial Intelligence Initiative Act of 2020 (P.L. 116-283). Explicitly “voluntary, rights-preserving, non-sector-specific, and use-case agnostic” (source: NIST.AI.100-1.md).
The definition it uses
An AI system is “an engineered or machine-based system that can, for a given set of objectives, generate outputs such as predictions, recommendations, or decisions influencing real or virtual environments. AI systems are designed to operate with varying levels of autonomy” — adapted from OECD Recommendation on AI:2019 and ISO/IEC 22989:2022 (source: NIST.AI.100-1.md).
This is the same lineage as the OECD definition, which is why the two frameworks interlock cleanly.
The four functions
GOVERN — cross-cutting. It “cultivates and implements a culture of risk management,” connects “technical aspects of AI system design and development to organizational values,” and “addresses full product lifecycle and associated processes, including legal and other issues concerning use of third-party software or hardware systems and data.”
The framework is explicit that GOVERN “is a cross-cutting function that is infused throughout AI risk management and enables the other functions… Aspects of GOVERN, especially those related to compliance or evaluation, should be integrated into each of the other functions.”
MAP — establishes context. Its stated motivation is a supply-chain problem: “AI actors in charge of one part of the process often do not have full visibility or control over other parts and their associated contexts… the best intentions within one dimension of the AI lifecycle can be undermined via interactions with decisions and conditions in other, later activities.”
MEASURE — quantitative, qualitative and mixed-method analysis. Requires “rigorous software testing and performance assessment methodologies with associated measures of uncertainty, comparisons to performance benchmarks, and formalized reporting.” Notes that “Processes for independent review can improve the effectiveness of testing and can mitigate internal biases and potential conflicts of interest,” and that measurement outcomes must be revisited “as knowledge, methodologies, risks, and impacts evolve.”
MANAGE — allocates resources to mapped and measured risks. “Risk treatment comprises plans to respond to, recover from, and communicate about incidents or events.” MANAGE 1.3 lists response options as “mitigating, transferring, avoiding, or accepting”; MANAGE 1.4 requires documenting “Negative residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers of AI systems and end users.”
That residual-risk disclosure to downstream acquirers is the RMF’s version of the Art 53(1)(b) documentation duty in the AI Act.
The seven trustworthiness characteristics
Covered in trustworthy-ai-characteristics. Security-relevant summary: Secure and Resilient names “adversarial examples, data poisoning, and the exfiltration of models, training data, or other intellectual property through AI system endpoints,” and points to the NIST Cybersecurity Framework and Risk Management Framework as applicable (source: NIST.AI.100-1.md).
Appendix B — why AI risk is not software risk
The framework’s most quotable section. AI-specific risks that are “new or increased” include (source: NIST.AI.100-1.md):
- Training data that “may not be a true or appropriate representation of the context or intended use,” with ground truth that “may either not exist or not be available.”
- “Intentional or unintentional changes during training may fundamentally alter AI system performance.”
- Datasets that “become detached from their original and intended context or may become stale.”
- Scale and complexity — “many systems contain billions or even trillions of decision points.”
- Pre-trained models increasing “statistical uncertainty” and causing “issues with bias management, scientific validity, and reproducibility.”
- “Higher degree of difficulty in predicting failure modes for emergent properties of large-scale pre-trained models.”
- More frequent maintenance “due to data, model, or concept drift.”
- “Underdeveloped software testing standards” and difficulty “determining what to test, since AI systems are not subject to the same controls as traditional code development.”
- “Inability to predict or detect the side effects of AI-based systems beyond statistical measures.”
Two of these are load-bearing for security work: intentional changes during training is data/model poisoning by another name, and inability to predict failure modes for emergent properties is why red teaming cannot be exhaustive.
Profiles
Section 6 covers AI RMF Profiles — use-case or sector-specific instantiations. This is the mechanism by which the RMF gets specialised, and the natural home for an AI-security-specific profile.
Relationship to the AI Act
The RMF is voluntary and process-oriented; the AI Act is binding and outcome-oriented. They cover much of the same ground:
| AI RMF | AI Act |
|---|---|
| GOVERN | Art 17 quality management system |
| MAP | Art 9 risk management system |
| MEASURE (TEVV) | Art 15(2) benchmarks; Art 55(1)(a) model evaluation |
| MANAGE | Art 9, Art 72 post-market monitoring |
| Secure and Resilient | Art 15(5) |
An organisation running the RMF properly is doing most of what Chapter III Section 2 asks for. Neither source in this corpus claims formal mapping between them.