The NIST AI Risk Management Framework: A Practical Guide

What the NIST AI RMF is

The NIST AI RMF — the NIST Artificial Intelligence Risk Management Framework — is a voluntary framework, published by the U.S. National Institute of Standards and Technology, for identifying, assessing, and managing the risks that come with designing, developing, deploying, and using AI systems. It has quickly become the reference point that boards, regulators, procurement teams, and engineering leaders use when they talk about responsible AI.

NIST released version 1.0 of the framework in January 2023, after a multi-year, open development process that drew on comments from industry, academia, civil society, and government. Its development was directed by Congress through the National Artificial Intelligence Initiative Act of 2020, and NIST built it to be consensus-driven and deliberately technology-neutral: it applies whether you are fine-tuning a large language model, deploying a computer-vision system, or embedding a third-party model into a product.

Two points shape everything else. First, the framework is voluntary. It is not a law, and there is no certificate you earn for "passing" it; its authority comes from adoption and reference, not enforcement. Second, it is risk-based and outcome-oriented. Rather than prescribing a rigid checklist, it asks organizations to reason about the specific harms an AI system could cause — to people, to organizations, and to society — and to manage those risks in proportion to their likelihood and severity, in the context in which the system is actually used.

The framework and its companion resources

The core framework document is organized in two parts. The first lays the foundation: it frames what AI risk is, how it differs from traditional software and information-security risk, who the affected parties are, and what makes AI trustworthy. The second presents the operational heart of the framework — the four functions, described below — and the concept of profiles, ways of applying the framework to a specific use case, sector, or technology.

NIST also maintains companion resources that make the framework usable in practice:

• The AI RMF Playbook — a practical companion that offers suggested actions, references, and documentation guidance for each subcategory of the core, so teams do not have to invent an implementation from scratch.
• The Generative AI Profile (published in July 2024 as NIST AI 600-1) — a cross-sectoral profile that applies the framework specifically to generative AI, cataloguing risks that are unique to or amplified by generative systems and suggesting actions to manage them.
• The Trustworthy and Responsible AI Resource Center, an online hub that hosts the framework, the Playbook, profiles, crosswalks to other standards, and related material.

Together these turn a conceptual framework into something a working team can pick up and use. When people say "we follow the NIST AI RMF," they usually mean they have adopted its vocabulary, mapped their program to its functions, and drawn on the Playbook and relevant profiles to guide day-to-day decisions.

The characteristics of trustworthy AI

Before it describes any process, the framework defines what "good" looks like. It sets out seven characteristics of trustworthy AI — properties that a system should exhibit if it is to be worthy of the trust placed in it. These characteristics are the yardstick against which risk is measured, and much of the operational work in the framework is ultimately in service of them.

A crucial idea runs through this section: these characteristics are not independent dials to be maxed out one at a time. They interact, and sometimes pull against one another — a change that improves explainability can affect security or privacy. The framework asks organizations to make these trade-offs deliberately, based on the system's context and the values of the people it affects, rather than treating any single property as absolute.

Valid and reliable

Validity and reliability are treated as foundational — the base on which the other characteristics rest. A valid system does what it is supposed to do, confirmed through evidence such as testing and ongoing monitoring. A reliable system performs consistently across the range of conditions and over the period of time in which it is used. Without them, the other properties matter little, because the system cannot be counted on to behave as intended in the first place.

Safe

A safe AI system should not, under defined conditions, lead to a state that endangers human life, health, property, or the environment. Safety draws on responsible design, clear information for deployers and users, and mechanisms to intervene — to halt, override, or fall back — when a system behaves in ways that could cause harm.

Secure and resilient

A secure and resilient system can withstand adversarial conditions and unexpected changes in its environment, and recover from disruption. This is where AI risk management meets cybersecurity: protection against attacks such as data poisoning, model evasion, and extraction, plus the ability to maintain function, or degrade gracefully, when something goes wrong. Resilience is bending without breaking; security is resisting deliberate compromise.

Accountable and transparent

Transparency reflects the extent to which information about an AI system is available to those interacting with it — knowing they are engaging with AI, and having appropriate information about how the system was built and used. Accountability builds on that: clear lines of responsibility, so that when something goes wrong there are people and processes answerable for it. Transparency is a precondition for accountability, but does not guarantee it on its own.

Explainable and interpretable

Explainability concerns the mechanisms behind an AI system's operation — a representation of how it works. Interpretability concerns the meaning of a system's output in context — what a given result signifies for the person relying on it. The two are related but distinct: a system can be explainable at a technical level yet still leave a user unable to interpret what a specific output means for a decision. Both help people understand, appropriately trust, and, where necessary, contest an AI system's behavior.

Privacy-enhanced

Privacy refers to the norms and practices that safeguard human autonomy, identity, and dignity — values such as anonymity, confidentiality, and control over one's own information. Privacy-enhancing practices and technologies can support the design of AI systems that minimize the collection and exposure of personal data, though the framework is careful to note that privacy measures can interact with other characteristics, such as accuracy or fairness, and must be balanced accordingly.

Fair, with harmful bias managed

Fairness in the framework is concerned with equality and equity, and specifically with addressing harmful bias and discrimination. NIST is explicit that fairness is contextual and contested — standards differ across cultures and applications — and that bias is broader than the demographic sense in which it is often discussed. The framework identifies three categories: systemic bias, computational and statistical bias, and human-cognitive bias, all of which can be present without any intent to discriminate. The goal is not the impossible one of eliminating bias entirely, but managing harmful bias so that it does not produce unjust outcomes.

The four core functions

The operational core of the framework is a set of four functions: GOVERN, MAP, MEASURE, and MANAGE. Each is broken into categories and subcategories that describe outcomes an organization should achieve. The functions are not a strict waterfall run once from top to bottom; they are meant to be performed iteratively and continuously across the AI lifecycle, revisited as systems, data, and context change.

GOVERN — the culture and accountability that cut across everything

GOVERN is the cross-cutting function. Where the other three attach to specific systems and use cases, GOVERN establishes the organizational conditions in which risk management can actually happen: policies, processes, roles, and a culture that takes AI risk seriously. It is what makes the difference between a framework that lives in a document and one that lives in how an organization behaves.

GOVERN addresses questions such as: Are there policies for the entire AI lifecycle, and are they enforced? Are roles and lines of accountability clearly assigned? Does the workforce have the skills and training to identify and manage AI risk? Is the organization's risk tolerance defined, so teams know when a risk is acceptable? How are legal and regulatory requirements accounted for, and how are third-party and supply-chain risks governed? GOVERN also calls for mechanisms to engage affected communities and incorporate feedback. Because it is cross-cutting, it should be established first and then continuously informed by what MAP, MEASURE, and MANAGE surface.

NIST organizes GOVERN into six categories, and translating them into concrete actions is what turns intent into an operating system:

• Govern 1 — Policies, processes, procedures. Establish and document policies that reflect legal and regulatory requirements and that cover the full AI lifecycle, including where risk tolerances are defined and how they are approved, updated, and retired.
• Govern 2 — Accountability structures. Assign roles, responsibilities, and lines of authority so that the individuals accountable for managing AI risk are empowered, resourced, and trained to do so.
• Govern 3 — Workforce diversity and competency. Prioritize diversity, equity, inclusion, and accessibility in the teams building and overseeing AI, and invest in the skills needed to recognize AI-specific risk.
• Govern 4 — Culture and critical thinking. Cultivate a culture that surfaces concerns rather than suppressing them — safe channels to report problems, and practices that treat testing, documentation, and information sharing as normal engineering hygiene.
• Govern 5 — Engagement with affected parties. Build mechanisms to collect, consider, and act on feedback from the people and communities an AI system affects, including those outside the organization.
• Govern 6 — Third parties and the value chain. Establish policies and procedures to address the risks that arise from third-party software, data, models, and services — the part of the risk surface an organization does not build itself.

MAP — building the context to understand risk

MAP establishes the context needed to frame risks for a specific AI system. Risks are difficult to manage if they are not understood, and they are difficult to understand without context: many AI risks emerge from the interplay between a system, its data, the people who build it, and the setting in which it is deployed. MAP is the function that gathers that understanding before, not after, a system is fielded.

In the MAP function, teams articulate the intended purpose, setting of use, and expected benefits and costs of the system; identify the affected individuals, groups, and communities; document the system's capabilities, the data it relies on, and its dependencies; and enumerate the ways it could cause harm — including impacts that fall on people other than the direct user. The output is a well-scoped picture of a system in context, detailed enough for the organization to decide whether and how to proceed, and comprehensive enough to feed the measurement work that follows.

MAP's categories move from broad context to specific harms, and each suggests concrete artifacts a team should produce:

• Map 1 — Establish context. Document intended purposes, potential positive and negative uses, the operating environment, norms and expectations, and the organization's mission — the frame within which every later judgment is made.
• Map 2 — Categorize the AI system. Record what the system does, how it is built, the tasks it performs, the methods it uses, and the level of human oversight it involves, so that its nature is unambiguous.
• Map 3 — Understand capabilities and benefits. Examine the AI's capabilities, targeted usage, goals, and expected benefits and costs against realistic baselines rather than vendor claims.
• Map 4 — Map risks and benefits across components. Identify risks and benefits for every component, including third-party models and data, and document internal and external assumptions and dependencies.
• Map 5 — Characterize impacts. Assess the likelihood and magnitude of impacts to individuals, groups, communities, organizations, and society, and record how affected parties can contest or seek redress for harmful outcomes.

MEASURE — analyzing, tracking, and assessing risk

MEASURE uses quantitative, qualitative, or mixed methods to analyze, assess, benchmark, and monitor the risks that MAP identified. This is where the trustworthiness characteristics become testable: teams select appropriate metrics, evaluate the system for validity, reliability, safety, security, bias, explainability, privacy, and the rest, and track how those measures hold up over time and under stress.

Good measurement is rigorous and honest about its own limits. The framework encourages independent review where appropriate, testing under conditions that resemble deployment, and attention to the fact that some risks — particularly emergent or societal ones — are hard to quantify and may require qualitative assessment or expert judgment. It also includes gathering feedback about the effectiveness of the measurement itself. Crucially, measurement is not a one-time gate: models drift, data shifts, and adversaries adapt, so the function is designed to run continuously.

MEASURE's four categories describe a full evaluation discipline, not a single test:

• Measure 1 — Methods and metrics. Identify and apply appropriate methods and metrics for the risks that MAP surfaced, and be explicit about which risks cannot be measured well and why.
• Measure 2 — Evaluate trustworthiness. Assess the system against the trustworthiness characteristics — validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy, and fairness with harmful bias managed — using techniques such as test, evaluation, verification, and validation (TEVV) and adversarial red-teaming.
• Measure 3 — Track risk over time. Put mechanisms in place to monitor identified risks, detect emergent ones, and watch for performance drift once the system is live.
• Measure 4 — Gather feedback on efficacy. Collect input from operators, users, and independent reviewers on whether the measurements themselves are working, and adjust the approach accordingly.

MANAGE — prioritizing, acting, and responding

MANAGE is where the organization acts. Drawing on the context from MAP and the assessments from MEASURE, teams prioritize risks, decide how to treat them, and allocate resources accordingly. Treatment can mean mitigating a risk, transferring it, avoiding it by not deploying, or accepting it within the organization's stated risk tolerance — and documenting that decision so it is defensible later.

MANAGE also covers the life of a deployed system: plans for responding to, recovering from, and communicating about incidents; ongoing monitoring; and the treatment of third-party and supply-chain risks. When MEASURE reveals a control is no longer effective, or MAP surfaces a new use that changes the risk picture, MANAGE turns those findings into action. Together with GOVERN it closes the loop: governance sets the rules, mapping and measurement produce the evidence, and management makes decisions that feed back into governance.

MANAGE's categories turn assessment into disposition:

• Manage 1 — Prioritize and respond. Rank risks based on the assessments from MAP and MEASURE, and determine responses — mitigate, transfer, avoid, or accept — against the organization's risk tolerance.
• Manage 2 — Maximize benefit, minimize harm. Implement strategies and resources to sustain the AI's intended benefits while reducing negative impacts, including plans to sunset or deactivate systems that no longer meet the bar.
• Manage 3 — Manage third-party risk. Apply the responses above to risks introduced by third-party models, data, and services, not just to components built in house.
• Manage 4 — Document, monitor, and respond to incidents. Record risk-treatment decisions and their rationale, monitor deployed systems, and maintain the ability to respond to, recover from, and communicate about incidents when they occur.

Operationalizing the framework in an enterprise

Understanding the framework is one thing; running an organization by it is another. Its non-prescriptive design is a strength — it adapts to context — but it means each organization has to design its own implementation. The following steps describe a pragmatic path that keeps the effort proportionate and produces evidence you can show a regulator, a customer, or a board.

1. Stand up governance first. Start with GOVERN. Define who owns AI risk, write the policies that apply across the AI lifecycle, and set an explicit risk tolerance so teams know where the lines are. Establish a cross-functional body — security, legal, data science, product, privacy — that can make and record decisions. Without it, later steps produce findings no one is accountable for acting on.
2. Inventory your AI systems. You cannot govern what you cannot see. Maintain a register of AI systems and use cases — including third-party models embedded in products and tools adopted by individual teams — noting each system's purpose, data, owner, and risk classification.
3. Run MAP on each meaningful use case. For systems that matter, document intended purpose, context of use, affected parties, dependencies, and the ways the system could cause harm. Prioritize: the framework expects you to focus effort where potential impact is greatest.
4. Choose metrics and MEASURE. Select methods tied to the trustworthiness characteristics that matter for each system — accuracy and reliability testing, security and adversarial testing (including red-teaming for generative systems), bias assessments, privacy reviews, and drift monitoring. Record results and their limitations.
5. Prioritize and MANAGE. Rank risks by likelihood and impact, decide how to treat each, and document the decision and its rationale — including risks you knowingly accept. Put incident-response and monitoring plans in place before deployment, not after an incident.
6. Draw on the Playbook and profiles. Use the AI RMF Playbook for suggested actions against each subcategory, and apply the Generative AI Profile for generative systems, so you are not reinventing controls NIST has already articulated.
7. Create a current and target profile. Capture where your program stands today and where you intend it to be. The gap between them becomes your roadmap, and the profiles become artifacts you can share with stakeholders.
8. Iterate continuously. Treat the four functions as a loop, not a project with an end date. Re-map when a use changes, re-measure on a schedule and after significant changes, and feed everything back into governance so policy keeps pace with reality.

Two habits make this durable. The first is documentation: the framework's value in an audit or a sales cycle comes largely from the evidence trail — decisions made, controls implemented, tests run, risks accepted. The second is proportionality: spend where the risk is. A low-stakes internal tool does not need the scrutiny a customer-facing, high-impact decision system does, and the framework is explicit that risk management should be commensurate with the level of risk.

A worked example: a customer-support assistant

Consider a bank deploying a generative AI assistant that answers customer questions and can look up account details through internal tools. Walking it through the functions makes the abstract concrete. Under MAP, the team documents the intended purpose (deflecting routine support tickets), the affected parties (customers, support agents, and people mentioned in account records), the data the assistant can reach, and the harms it could cause — leaking one customer's data to another, giving incorrect financial guidance, or being manipulated by a hostile prompt. Under MEASURE, they test the assistant for accuracy against a labelled question set, red-team it for prompt injection and data exfiltration, run bias checks across customer segments, and instrument it to monitor drift once live. Under MANAGE, they decide the residual risk of unsupervised financial advice is above tolerance, so they scope the assistant to informational answers only, route anything transactional to a human, and stand up an incident runbook before launch. Under GOVERN, all of this is bound by a policy that names an owner, sets the risk tolerance the team measured against, and requires the evidence to be retained. None of these steps is exotic; the framework's value is in making sure none of them is skipped.

The same walk-through scales down. A team using AI to draft internal marketing copy would document far less and test far more lightly, because the potential impact is low — which is exactly what proportionality demands.

The Generative AI Profile (NIST AI 600-1)

Generative AI raised risks that the core framework anticipated in principle but did not treat in depth. In response — and in fulfilment of a tasking under U.S. Executive Order 14110 — NIST published the AI RMF Generative AI Profile in July 2024 as NIST AI 600-1. A profile is a way of applying the framework to a particular context; this one is cross-sectoral, meaning it is not tied to a single industry, and it is meant to be used alongside the core rather than in place of it.

The profile does two things. First, it identifies a set of risks that are unique to, or amplified by, generative AI. Second, for each of the four functions it lays out several hundred suggested actions an organization can take to manage those risks, so teams working with large language models and other generative systems have a concrete starting point. The risks it catalogues include:

• Confabulation — confidently stated but false or fabricated output, commonly called hallucination, which is especially dangerous when users treat fluent text as authoritative.
• Information integrity — the amplification of mis- and disinformation, including at a scale and quality that makes it hard to detect.
• Information security — expanded attack surfaces such as prompt injection, insecure plug-ins and tool use, and the leakage or extraction of training data.
• Data privacy — the exposure of personal or sensitive information present in training data or supplied at inference time.
• Harmful bias and homogenization — the reproduction of harmful bias, and a tendency toward sameness that can narrow representation and outputs.
• Dangerous, violent, or hateful content, and obscene or abusive content — the generation of material that is unsafe or degrading, including non-consensual imagery.
• CBRN information or capabilities — lowered barriers to information about chemical, biological, radiological, or nuclear weapons.
• Intellectual property — infringement or misappropriation of protected works through training or generation.
• Human–AI configuration — risks from how people interact with the system, including over-reliance, automation bias, and unclear disclosure that a user is dealing with AI.
• Value-chain and component integration — risks inherited from third-party models, data, and services assembled into a generative application.
• Environmental impacts — the resource and energy costs of training and operating large models.

For an enterprise adopting generative AI, the profile is the most practical companion NIST offers. It maps directly onto the GOVERN / MAP / MEASURE / MANAGE structure, so the risks above become items to map, tests to run, and controls to manage — with red-teaming, content provenance, disclosure, and human oversight recurring throughout its suggested actions.

How the NIST AI RMF relates to other regimes

The NIST AI RMF does not exist in isolation, and one of its practical strengths is that it plays well with the other regimes an enterprise has to satisfy. Understanding how it maps to them prevents duplicated effort and helps you build one control set that serves several masters. A comprehensive treatment lives on our compliance overview, but the essentials are worth stating here.

The EU AI Act

The EU AI Act is binding law: a risk-tiered regulation that imposes real obligations on providers and deployers, with the heaviest requirements on high-risk use cases and outright prohibitions on certain practices. The NIST AI RMF is voluntary guidance, and the two are complementary rather than interchangeable — you cannot substitute the framework for legal compliance with the Act. But its structure maps naturally onto many of the Act's expectations around risk management, data governance, transparency, human oversight, and robustness, so an organization that has genuinely implemented the AI RMF will find much of the groundwork for EU AI Act readiness already laid.

ISO/IEC 42001

ISO/IEC 42001 is the international management-system standard for artificial intelligence. Unlike the AI RMF, it is certifiable: an accredited body can audit an organization's AI management system and issue a certificate. Where the AI RMF gives you a risk model and a vocabulary, 42001 gives you the management-system scaffolding — the plan-do-check-act discipline familiar from ISO/IEC 27001. Many organizations use them together: the AI RMF to reason about AI-specific risk and trustworthiness, and 42001 to structure the governance system around it in a certifiable form.

SOC 2

SOC 2 is an attestation report, based on the AICPA Trust Services Criteria, that enterprise buyers rely on to evaluate a vendor's security and related controls. It was not designed for AI specifically, and it does not cover AI-specific harms such as harmful bias or model explainability. But it overlaps meaningfully with the AI RMF's security and resilience concerns, and the two are frequently pursued in parallel: SOC 2 to satisfy procurement's baseline security expectations, and the AI RMF to demonstrate that the AI itself is governed responsibly.

Building one crosswalk instead of four programs

The practical way to exploit these overlaps is a crosswalk: a single control library in which each control is tagged with the AI RMF subcategories it satisfies and the corresponding clauses of the EU AI Act, ISO/IEC 42001, and SOC 2. NIST itself publishes crosswalks to some standards through its resource center, and building your own means a single test or piece of evidence can be reused across regimes instead of being regenerated for each. A record of an adversarial red-team exercise, for example, can serve MEASURE 2 in the AI RMF, the robustness and accuracy expectations of the EU AI Act's high-risk requirements, an ISO/IEC 42001 control, and a SOC 2 security criterion at once. The AI RMF's function-and-category vocabulary is what makes that mapping tractable, because it gives every other regime a common set of hooks to attach to.

Roles, responsibilities, and a sample RACI

A framework does not implement itself, and the most common reason a program stalls is that no one is unambiguously responsible for any given part of it. The AI RMF's GOVERN function insists on clear accountability structures; the most direct way to satisfy that is to name the roles involved in AI risk management and to agree, in advance, who is Responsible, Accountable, Consulted, and Informed — a RACI — for each function.

The roles below are illustrative rather than prescriptive; NIST does not mandate a particular structure, and small organizations will collapse several of these onto one person. What matters is that each responsibility has an owner.

• Board and senior executives — set the organization's risk appetite, approve AI policy, and hold ultimate accountability for AI risk. In RACI terms they are typically Accountable for GOVERN and Informed on the rest.
• AI governance lead or AI risk officer — owns the program day to day, maintains the policy and the system inventory, and convenes the review body. Usually Responsible for GOVERN and Accountable for MAP, MEASURE, and MANAGE at the portfolio level.
• Product and system owners — accountable for the risk of the specific systems they field. Responsible for MAP and for the MANAGE decisions on their systems, and Consulted throughout.
• Data scientists and ML engineers — build, test, and document the systems. Responsible for much of MEASURE and for implementing mitigations decided under MANAGE.
• Security and privacy teams — own the secure-and-resilient and privacy characteristics, run adversarial testing, and assess data handling. Responsible for security-related MEASURE and Consulted on MAP and MANAGE.
• Legal, compliance, and risk — map obligations from the EU AI Act, sector regulation, and contracts into requirements, and steward the audit trail. Consulted on GOVERN and MAP, and Responsible for the compliance mapping.
• Internal audit and independent reviewers — provide the challenge function, testing whether controls actually work. Consulted or Informed, deliberately separate from the teams they review to preserve independence.
• Affected-community and user representatives — the voice of the people a system affects, feeding the GOVERN 5 and MAP 5 expectations. Consulted during mapping and after incidents.

Written down and agreed, a RACI resolves the two failure modes that quietly kill governance: work that everyone assumes someone else is doing, and decisions that no one has the authority to make. It also produces exactly the kind of artifact an auditor or an enterprise customer asks for when they want proof that AI risk is actually owned rather than merely acknowledged.

Common pitfalls

Organizations that struggle with the framework tend to fail in a handful of recognizable ways. Knowing them in advance is the cheapest way to avoid them.

Treating it as a checklist

The framework is risk-based by design; converting it into a static checklist strips out the reasoning that gives it value. A team that mechanically ticks subcategories without asking "what could this system actually do to real people?" ends up with documentation that satisfies no one and protects nothing. The framework rewards judgment, not box-ticking.

Standing up GOVERN on paper only

Governance that exists only as a policy document, with no owner empowered to enforce it and no risk tolerance anyone actually respects, is the most common failure mode. GOVERN has to be real: named accountability, a cross-functional forum that meets, and consequences when policy is ignored.

Measuring once and declaring victory

AI systems drift, data distributions shift, and adversaries adapt. A model that was fair, accurate, and secure at launch can degrade quietly. Treating MEASURE as a one-time pre-deployment gate rather than a continuous activity is a recipe for being blindsided by a risk that developed after go-live.

Ignoring the supply chain

Much enterprise AI is assembled from third-party models, datasets, and libraries. Risk that enters through a vendor — a poisoned dataset, a model with hidden behavior, an unvetted dependency — is still your risk. The framework's attention to supply-chain risk exists precisely because this is so easy to overlook.

Confusing the framework with a certification

There is no accredited "NIST AI RMF certification," and claiming one erodes credibility. The right claim is that you have adopted the framework and can show your work. If you need a certifiable standard, that is what ISO/IEC 42001 is for.

Scope that is either too narrow or too broad

Applying the full weight of the framework to every trivial internal tool exhausts a team; applying it to nothing until a crisis forces the issue leaves you exposed. Proportionality — matching the depth of risk management to the level of risk — is the discipline that keeps the program sustainable.

How Deflected helps

Deflected supports enterprises that are adopting the NIST AI RMF and preparing for the broader landscape of AI governance and compliance. Our role is to help you build a defensible, evidence-backed program — the controls, the testing, and the documentation that turn framework language into something you can stand behind in front of an auditor, a regulator, or an enterprise buyer.

To be clear about what that means: Deflected is not an accredited auditor or a certification body. We do not issue SOC 2 reports, ISO/IEC 42001 certificates, or conformity assessments. What we provide is readiness — mapping your program to the framework, implementing and testing controls, and producing the evidence that an independent auditor or assessor will ultimately evaluate.

Our AI Governance & Compliance engagement maps policy, controls, and evidence to the NIST AI Risk Management Framework, the EU AI Act, and SOC 2, so your AI program is audit-ready rather than merely secure. It slots into the operational steps above: standing up GOVERN, running MAP and MEASURE against your real systems, and organizing the artifacts into current and target profiles you can act on. For a fuller picture of how these mappings fit together across regimes, see our compliance overview.

Several trustworthiness characteristics also connect directly to Deflected's always-on capabilities. The secure and resilient characteristic is where AI risk management meets cybersecurity — exactly where our platform operates, inspecting prompts and responses, testing models adversarially, and protecting the AI layer against the attacks the framework asks you to withstand. Everything that flows through Deflected is protected with post-quantum cryptography by default: ML-KEM-1024 (FIPS 203) for key encapsulation, hybrid X25519 + ML-KEM key exchange so you stay protected even if either scheme is weakened, and AES-256 for symmetric encryption at rest and in transit. Read the full architecture on the Deflected platform page.

Frequently asked questions

The takeaway

The NIST AI RMF endures because it is honest about the nature of AI risk: it is contextual, it evolves, and it cannot be eliminated — only understood and managed. The framework gives an organization a shared language for that work through seven characteristics of trustworthy AI, and a repeatable engine for it through the GOVERN, MAP, MEASURE, and MANAGE functions. It asks for judgment over box-ticking, evidence over assertion, and continuous attention over a one-time sign-off.

For an enterprise, the payoff is threefold. Internally, you reduce the chance of an AI failure harming your customers or your business. Externally, you gain the vocabulary and evidence to satisfy regulators, auditors, and enterprise buyers — on a foundation that maps cleanly onto the EU AI Act, ISO/IEC 42001, and SOC 2. And strategically, you can move faster with AI, because you see and manage the risks rather than hope they do not materialize. Adopt the framework, do the work behind it, and keep the evidence — that is what turns "we take AI risk seriously" from a claim into something you can prove.