Implementing the NIST AI Risk Management Framework
The AI RMF tells you what good looks like. It deliberately doesn't tell you how to build it. This page is our working reference for closing that gap — every function and category, what each one demands in practice, and the specific services on Azure, AWS, and Google Cloud that satisfy it with evidence an auditor will accept.
Four functions, nineteen categories, one continuous loop
NIST AI 100-1 organizes AI risk management into four functions. Three of them — MAP, MEASURE, MANAGE — run as a cycle for every AI system you operate. The fourth, GOVERN, sits underneath all of them and is the one most organizations skip, which is why their AI programs stall at the first audit.
Figure 1. The AI RMF Core, adapted from NIST AI 100-1. Category counts are ours, taken from the framework's own category list. GOVERN is drawn at the centre rather than as a fourth step because it is a precondition, not a phase — MAP, MEASURE and MANAGE produce nothing durable without it.
The framework is voluntary. Your obligations may not be.
NIST describes the AI RMF as voluntary, rights-preserving, non-sector-specific and use-case agnostic. That framing matters, because it means the framework will never tell you what your risk tolerance should be — NIST is explicit that tolerance is "highly contextual and application and use-case specific."
What we see in practice is that the RMF becomes non-optional by a different route: it gets written into customer security questionnaires, insurance renewals, and procurement requirements long before any regulator asks. Organizations that treat it as a paperwork exercise end up rebuilding it as an engineering exercise eighteen months later.
Seven characteristics — and only one of them is a foundation
NIST names seven characteristics of trustworthy AI, but it does not treat them as a flat checklist. Validity and reliability are a precondition: a system that doesn't work correctly cannot be made trustworthy by adding governance on top. Accountability and transparency cut across every other characteristic rather than sitting beside them.
Figure 2. Adapted from NIST AI 100-1 Figure 4. The arrangement is NIST's: "Valid & Reliable" is drawn as the base because it is a necessary condition of trustworthiness, and "Accountable & Transparent" as a vertical band because it relates to all the others. The "needs" lines beneath each characteristic are ours — they are what we look for during an assessment.
Risk enters early and gets expensive late
The framework maps its functions onto an AI system lifecycle organized around key dimensions — application context, data and input, the model itself, task and output, and at the centre, people and planet. Most of the risk decisions that matter are made in the first two stages, long before anything reaches production, and long before most security teams are invited.
Figure 3. Lifecycle stages and dimensions adapted from NIST AI 100-1 Figures 2 and 3. The function-coverage bars are our reading of where each function does most of its work — the framework does not draw hard boundaries, and neither should you.
All nineteen categories, and what each one costs you to satisfy
Quoted text is NIST's, verbatim from AI 100-1. Everything under it is ours: what the category means once you stop reading and start building, and the artefact we produce so the category is demonstrably met rather than merely claimed.
Figure 4. The three classes of harm, adapted from NIST AI 100-1 Figure 1. A risk register that only counts harm to the organization will pass an internal review and fail an external one.
GOVERN — six categories
The function that makes the other three repeatable. If you implement nothing else this quarter, implement GOVERN 1, 2 and 6 — policy, accountability, and third-party risk are the three that show up in every customer security questionnaire.
"Policies, processes, procedures, and practices across the organization related to the mapping, measuring, and managing of AI risks are in place, transparent, and implemented effectively."
An AI acceptable-use policy is table stakes; this category asks for more than that. It wants the legal and regulatory requirements that apply to your AI use documented, risk tolerance stated rather than assumed, and a mechanism for retiring AI systems as deliberately as you stand them up.
What we deliver: an AI policy set tied to your actual use cases — not a template — plus a written risk-tolerance statement signed at executive level, and a decommissioning runbook that covers model, data, index, and access removal.
"Accountability structures are in place so that the appropriate teams and individuals are empowered, responsible, and trained for mapping, measuring, and managing AI risks."
The word doing the work is empowered. Naming an AI risk owner who cannot stop a launch satisfies the org chart and not the category. NIST is asking for documented roles, real authority, and training proportional to the risk of the systems in scope.
What we deliver: a RACI covering model owners, data owners, TEVV, and the executive who holds residual risk; a defined escalation and stop-ship path; and role-specific enablement for engineering, security, and legal.
"Workforce diversity, equity, inclusion, and accessibility processes are prioritized in the mapping, measuring, and managing of AI risks throughout the lifecycle."
This is a technical control, not a values statement. Homogeneous teams systematically fail to anticipate failure modes that affect populations they don't belong to, and those failures surface as bias findings after launch, when they are most expensive to fix.
What we deliver: structured impact-review sessions that deliberately widen participation beyond the build team, and documented human–AI configuration decisions — where a person stays in the loop, and on what authority.
"Organizational teams are committed to a culture that considers and communicates AI risk."
Culture is measured here by whether bad news travels. The practical test: can an engineer report that a model is behaving badly, without it costing them, and does that report reach someone who can act within a defined window?
What we deliver: an AI incident and near-miss reporting channel wired into your existing incident process, with defined severity levels for AI-specific failures — harmful output, data leakage through the model, and unsafe autonomous action.
"Processes are in place for robust engagement with relevant AI actors."
Feedback from the people your system acts on has to reach the people who can change it. For most enterprises this means a route for customers and employees to contest an AI-influenced decision, and evidence that contested cases changed something.
What we deliver: feedback and redress paths designed into the application rather than bolted on, plus a review cadence where collected feedback is demonstrably fed back into MAP.
"Policies and procedures are in place to address AI risks and benefits arising from third-party software and data and other supply chain issues."
Almost every enterprise AI system is mostly other people's software: a foundation model you did not train, an embedding model you did not evaluate, a vector database, and a long tail of libraries. This category is where most estates are weakest, because the supply chain is invisible until you inventory it.
What we deliver: a model and AI-service inventory including shadow usage, third-party evaluation criteria applied before a model is approved for a risk tier, and contractual and technical controls for data leaving your tenant.
MAP — five categories
Run once per system before build, and again whenever the use case moves. MAP is cheap to do early and nearly impossible to reconstruct honestly after launch.
"Context is established and understood."
Intended purpose, expected setting, who the system is for, and — the part usually missing — the specific benefit that justifies accepting the risk. Without a stated benefit there is no basis on which to accept anything.
What we deliver: a one-page system context record per AI use case: purpose, users, affected parties, expected benefit, and the norms and requirements that apply.
"Categorization of the AI system is performed."
What task the system performs, what methods it uses, and how it is deployed. This is what lets you apply proportionate controls — a retrieval-augmented internal search tool and an agent with write access to a payments system should not attract the same review.
What we deliver: a risk-tiering scheme calibrated to your business, applied to every system, with the tier driving mandatory controls automatically rather than by negotiation.
"AI capabilities, targeted usage, goals, and expected benefits and costs compared with appropriate benchmarks are understood."
Benchmarked against what? The honest comparison is against the current non-AI process, including its existing error rate. Teams routinely hold AI to a standard of perfection while never having measured the human baseline it replaces.
What we deliver: a baseline measurement of the existing process before the AI system is introduced, so post-launch performance can be argued from evidence rather than sentiment.
"Risks and benefits are mapped for all components of the AI system including third-party software and data."
All components. The base model, fine-tuning data, retrieval corpus, orchestration framework, plugins and tools the model can call, and the identity each of those runs as. Agentic systems make this materially harder, because the component list changes at runtime.
What we deliver: a component-level risk map per system, including the tools an agent may invoke and the blast radius of each, plus provenance and licence position for training and grounding data.
"Impacts to individuals, groups, communities, organizations, and society are characterized."
The category Figure 4 above exists to serve. Impacts must be characterised across all three classes of harm and along NIST's four axes — long or short term, likely or unlikely, systemic or localised, high or low impact.
What we deliver: a structured impact assessment per system that survives external scrutiny, and which maps cleanly onto EU AI Act and ISO/IEC 42001 evidence requests without being redone.
MEASURE — four categories
The function that separates an AI governance programme from an AI governance document. Almost every organization we assess is weakest here, because measurement requires engineering rather than policy.
"Appropriate methods and metrics are identified and applied."
Metrics have to be chosen per system and per risk, documented, and — importantly — assessed for what they miss. NIST asks you to state which risks are not being measured and why, which is the line most programmes quietly skip.
What we deliver: an evaluation plan naming each metric, its threshold, its owner, and an explicit register of unmeasured risks carried as accepted uncertainty.
"AI systems are evaluated for trustworthy characteristics."
All seven characteristics from Figure 2, evaluated with real methods: adversarial and red-team testing for security and resilience, groundedness and citation checks for validity, disaggregated evaluation for fairness, and privacy testing for memorisation and leakage.
What we deliver: automated evaluation suites wired into your deployment pipeline plus scheduled adversarial testing, run by people who did not build the system.
"Mechanisms for tracking identified AI risks over time are in place."
Point-in-time assurance is worthless for systems whose behaviour changes when the vendor updates a model beneath you. This category is about telemetry: drift, guardrail trigger rates, refusal rates, and the emergence of risks nobody anticipated at MAP time.
What we deliver: AI-specific monitoring and alerting into your existing SIEM, with model-version change detection so a silent upstream update triggers re-evaluation rather than an incident.
"Feedback about efficacy of measurement is gathered and assessed."
Are the measurements themselves any good? Evaluations decay: a red-team suite written a year ago tests attacks that no longer represent the threat, and a benchmark the model has since been trained on tells you nothing.
What we deliver: a periodic review of the evaluation suite against current threat intelligence, including our own adversarial-AI research, with retired and refreshed tests recorded.
MANAGE — four categories
Acting on what MEASURE found, and being able to show you acted. This is the function auditors test hardest, because it produces the clearest artefacts.
"AI risks based on assessments and other analytical output from the MAP and MEASURE functions are prioritized, responded to, and managed."
NIST is explicit that eliminating all risk is counterproductive and that resources should be allocated by assessed risk level. It is equally explicit that residual risk must be documented — including what it means for the end user, who did not choose to accept it.
What we deliver: a live AI risk register with treatment decisions, owners and dates, and a residual-risk statement written in language an affected customer could actually read.
"Strategies to maximize AI benefits and minimize negative impacts are planned, prepared, implemented, documented, and informed by input from relevant AI actors."
The operative words are prepared and documented. This is where the mechanism to deactivate or roll back a system lives — and where most organizations discover they have no way to turn a deployed AI feature off without a code release.
What we deliver: runtime kill-switches and feature flags for every AI surface, tested; documented sunset criteria; and guardrail configurations under version control alongside the application.
"AI risks and benefits from third-party entities are managed."
GOVERN 6 sets the policy; MANAGE 3 operates it. Ongoing monitoring of third-party models and services, and a defined response when a provider changes terms, deprecates a model, or discloses a vulnerability affecting you.
What we deliver: continuous inventory of third-party AI in the estate — including shadow usage — and a provider-change response plan tied to each model's risk tier.
"Risk treatments, including response and recovery, and communication plans for the identified and measured AI risks are documented and monitored regularly."
What happens at 2am when a model starts producing harmful output, or an agent takes an action it should not have? Who is called, what gets disabled, who tells the customer, and how do you reconstruct what the model saw and did?
What we deliver: AI incident response playbooks exercised as tabletop scenarios, with prompt-and-response logging sufficient to reconstruct an incident without capturing more sensitive data than you can defend holding.
From category to control to evidence
A framework category is not a control, and a control is not evidence. The work of an AI RMF implementation is turning each category into something your platform enforces and something your auditor can read — without a human assembling a screenshot pack every quarter.
Figure 5. How one category becomes auditable. The same shape applies to all nineteen; what changes is which platform primitive does the enforcing.
Azure is the only one of the three with a control set that names the AI RMF directly — Purview Compliance Manager ships a NIST AI RMF 1.0 assessment template alongside EU AI Act and ISO/IEC 42001. That makes GOVERN evidence considerably cheaper here.
| Capability | Service | Categories it evidences |
|---|---|---|
| AI platform & model catalog | Microsoft FoundryModel Catalog; the Control Plane Assets pane gives fleet-wide inventory | MAP 2 · MAP 4 · GOVERN 6 |
| Shadow AI discovery | Microsoft Purview DSPM for AI + Defender for Cloud AppsFinds AI use outside sanctioned platforms | GOVERN 6 · MANAGE 3 |
| Inference guardrails | Content Safety in the Foundry Control PlanePrompt Shields for direct jailbreak and indirect injection, groundedness detection, protected material | MEASURE 2 · MANAGE 2 |
| Evaluation & red teaming | Foundry Evaluations + AI Red Teaming AgentBuilt on PyRIT; the Control Plane can schedule automated red-team scans | MEASURE 1 · MEASURE 2 · MEASURE 4 |
| Data classification | Microsoft Purview Information ProtectionSensitivity labelling for training and grounding data | MAP 4 · MEASURE 2 |
| AI security posture | Microsoft Defender for Cloud — AI-SPM under the Defender CSPM planNotably also covers AWS and Google Cloud, so it can serve as the cross-cloud row | MEASURE 3 · MANAGE 1 |
| Policy enforcement | Azure PolicyDenies or audits non-conforming AI resources at deployment | GOVERN 1 · MANAGE 2 |
| Audit logging | Azure Monitor / Activity Log + Purview AuditPrompt and response logging requires deliberate configuration | MEASURE 3 · MANAGE 4 |
| Model documentation | Transparency NotesMicrosoft-authored for Microsoft services — not an artefact you write for your own models | GOVERN 6 (partial) |
| Framework control set | Purview Compliance Manager — NIST AI RMF 1.0 assessment templatePremium regulation; A5/E5/G5 include three free. Also EU AI Act, ISO/IEC 42001:2023, ISO/IEC 23894:2023 | GOVERN 1 · cross-cutting |
Licensing change worth planning around
As of 1 July 2026, AI agent discovery and posture for Foundry and third-party cloud agents moved out of Defender CSPM and now require a Microsoft Agent 365 license. Defender CSPM still discovers Foundry accounts and projects. Microsoft is currently running two control planes — Foundry Control Plane for agents you build, Agent 365 for agents deployed across the tenant — and the boundary is still moving. Assume anything you design for Azure agent governance needs revisiting inside a year.
AWS has the strongest automated evidence story of the three via Audit Manager, but be careful how you describe it: the Generative AI Best Practices Framework is not a NIST AI RMF mapping, and AWS does not claim it is. Its eight principles align conceptually. Presenting it as AI RMF coverage is the kind of overstatement that fails an audit rather than passing one.
| Capability | Service | Categories it evidences |
|---|---|---|
| AI platform | Amazon Bedrock (generative AI and agents) + Amazon SageMaker AI (custom ML)Two distinct governance surfaces; most estates have both | MAP 2 · MAP 4 |
| Model catalog & registry | Bedrock foundation-model catalog + SageMaker Model Registry / SageMaker Catalog | MAP 2 · GOVERN 6 |
| Shadow AI discovery | AWS Security Hub AI InventoryLaunched July 2026, free in Security Hub Essentials. Covers Bedrock, AgentCore and SageMaker via Config; self-hosted Ollama, vLLM and TGI via SBOM; genuine shadow AI — third-party model endpoints — via GuardDuty DNS telemetry | GOVERN 6 · MANAGE 3 |
| Inference guardrails | Amazon Bedrock GuardrailsContent filters, denied topics, contextual grounding, PII redaction | MEASURE 2 · MANAGE 2 |
| Evaluation | Amazon Bedrock Evaluations + SageMaker ClarifyAutomatic, LLM-as-a-judge, human, and RAG evaluation; Clarify for bias and explainability | MEASURE 1 · MEASURE 2 |
| Data classification | Amazon Macie | MAP 4 · MEASURE 2 |
| Security posture | AWS Security Hub | MEASURE 3 · MANAGE 1 |
| Policy enforcement | AWS Organizations SCPs + AWS Control Tower + AWS Config | GOVERN 1 · MANAGE 2 |
| Audit logging | AWS CloudTrail + Bedrock model invocation loggingInvocation logging is off by default | MEASURE 3 · MANAGE 4 |
| Model documentation | AWS AI Service Cards + SageMaker Model CardsModel Cards are authorable for your own models — a real GOVERN 6 and MAP 2 artefact | GOVERN 6 · MAP 2 |
| Framework control set | AWS Generative AI Best Practices Framework v2 in Audit ManagerEight control sets, 72 automated and 38 manual controls, covering Bedrock and SageMaker AI. Conceptually adjacent to the AI RMF; no NIST mapping is claimed | Adjacent — map manually |
Google Cloud has the cleanest AI discovery story and no NIST AI RMF control set at all. Security Command Center's Compliance Manager ships an AI Essentials framework, CIS benchmarks and CIS Critical Security Controls — useful, but not an AI RMF mapping. Expect to author a custom framework. Note also the platform rename: Vertex AI became the Gemini Enterprise Agent Platform in April 2026, though the sub-products kept their names.
| Capability | Service | Categories it evidences |
|---|---|---|
| AI platform | Gemini Enterprise Agent PlatformFormerly Vertex AI; renamed April 2026 | MAP 2 · MAP 4 |
| Model catalog & registry | Model Garden + Model RegistryBoth kept their names through the platform rename | MAP 2 · GOVERN 6 |
| Shadow AI discovery | Security Command Center — AI Protection, AI DiscoveryCovers declarative, inferred, and Model-as-a-Service assets | GOVERN 6 · MANAGE 3 |
| Inference guardrails | Model ArmorPart of Security Command Center; screens both prompts and responses | MEASURE 2 · MANAGE 2 |
| Evaluation | Gen AI evaluation service | MEASURE 1 · MEASURE 2 |
| Data classification | Sensitive Data ProtectionFormerly Cloud DLP | MAP 4 · MEASURE 2 |
| Security posture | Security Command Center + AI ProtectionStandard tier gives discovery; Premium and Enterprise add risk, threat detection and AI frameworks | MEASURE 3 · MANAGE 1 |
| Policy enforcement | Organization Policy Service | GOVERN 1 · MANAGE 2 |
| Audit logging | Cloud Audit Logs / Cloud Logging | MEASURE 3 · MANAGE 4 |
| Model documentation | Model cards in Model GardenAuthorable for your own models | GOVERN 6 · MAP 2 |
| Framework control set | None for the AI RMFCompliance Manager offers Google Recommended AI Essentials, CIS GCP Foundations v3.0, CIS GKE 1.7 and CIS Critical Security Controls v8. Custom framework authoring is required | Build it yourself |
Service names verified August 2026. This layer moves fast — three of the products above were renamed within the preceding eighteen months. We re-verify these mappings each quarter; if you are reading this well after that date, ask us for the current version.
What none of the three clouds will do for you
Vendors market AI governance as though buying the platform buys the programme. It does not. Roughly half the framework is organizational and cannot be purchased — and knowing which half saves you from paying for tooling that was never going to close the finding.
Figure 6. Our assessment of platform coverage as of August 2026, not a vendor claim. "Strong" means the platform produces evidence without bespoke engineering; "partial" means it produces inputs you still have to assemble; "thin" means you are building the control set yourself.
Evidence does not aggregate across clouds
Each platform generates its own evidence in its own shape. If you run AI on two of the three — most enterprises do — nothing joins them into one answer to "show me MEASURE 2 coverage across the estate." Defender for Cloud's AI-SPM reaching into AWS and Google Cloud is the closest thing to a cross-cloud row, and it is partial.
Agents break component inventory
MAP 4 asks you to map risks for all components. An agent that selects its tools at runtime does not have a fixed component list. Every platform's inventory is a snapshot of declared resources, not of what the agent actually invoked at 3pm on Tuesday. Closing this needs runtime tool-call logging that you have to design.
Logging fights privacy
MEASURE 3 and MANAGE 4 want prompt and response logs detailed enough to reconstruct an incident. Privacy-Enhanced wants you to hold as little as possible. Prompt logging is off by default on all three platforms for exactly this reason. The resolution is a deliberate, documented retention and redaction design — not a default.
Sixteen weeks to a defensible programme, then it runs itself
We do not deliver a gap assessment and leave. The point of the engagement is that the controls end up in your platform and the evidence generates itself, so the fourth phase costs you a fraction of the first three.
Figure 7. Our standard engagement shape. The deliverable that matters is phase four costing you very little.
What you hold at the end
- A category-by-category position against all nineteen categories, with evidence links rather than assertions
- An AI system inventory that stays current because it is generated, not maintained
- Policy, RACI and risk-tolerance documents your legal and audit teams have already accepted
- Guardrails, evaluation gates and policy-as-code running in your tenant, under your version control
- AI telemetry in your existing SIEM, with model-version change detection
- Incident playbooks that have been exercised at least once before you needed them
Where this connects
The AI RMF is deliberately compatible with the frameworks you are probably already carrying. We map once and reuse the evidence rather than running parallel programmes.
NIST publishes a crosswalk from the AI RMF to ISO/IEC 42001, which is where we start if you are already certified or heading there. Most organizations discover they have more coverage than they thought in GOVERN, and less than they thought in MEASURE.
See how we secure the AI stack itselfStart with where you actually are
Ten questions and three minutes gives you a rough position. A working session with us gives you the real one — bring one AI use case and we'll walk it through all four functions with you.