The NIST AI Risk Management Framework (AI RMF 1.0) gives organizations a structured way to identify, assess, and manage AI-related risks across the full AI lifecycle. Released by the National Institute of Standards and Technology in January 2023, it has quickly become the de facto baseline for AI governance in U.S. enterprise environments, and increasingly appears as an expectation in vendor security questionnaires and regulatory guidance alike.
This article breaks down exactly what the framework requires, how its four core functions map to real IT operations, and where device management and endpoint security fit into your AI governance program.
The NIST AI RMF is a voluntary framework, which means no federal law currently mandates adoption for most private-sector organizations. That distinction matters less than it used to. Enterprise procurement teams are embedding AI RMF alignment into supplier requirements. The EU AI Act references risk management standards that align closely with the NIST framework. And U.S. federal agencies operating under executive orders on AI have pointed to AI RMF as the baseline for responsible AI use.
For mid-market IT teams, "voluntary" often means "expected before you know it." Organizations that start now, while the framework is still maturing, build institutional knowledge that pays off when customers or regulators start asking questions.
The framework is deliberately technology-neutral and vendor-agnostic. It does not tell you which AI tools to buy or avoid. It tells you how to think about risk at every stage of an AI system's life, from design through decommissioning. That design choice makes it compatible with virtually any tech stack, which is also why it requires genuine organizational work to apply rather than a simple checkbox exercise.
Before getting into the four core functions, the AI RMF defines what it is actually working toward: AI systems that are trustworthy. NIST identifies seven characteristics that trustworthy AI should demonstrate:
These characteristics run through every section of the framework. When you are evaluating an AI system, you are essentially asking how well it demonstrates each of these properties.
The framework organizes AI risk management into four functions: Govern, Map, Measure, and Manage. These are not sequential phases. They operate in parallel and feed each other continuously.
GOVERN is the organizational layer that makes everything else possible. It covers policies, roles, accountability structures, and the risk culture your teams operate within.
Concrete GOVERN activities include:
GOVERN 6 deserves specific attention. Most enterprise software now includes AI features, often enabled by default. Your CRM may include AI-generated summaries. Your productivity suite likely includes a copilot or AI assistant. Each of these represents an AI system operating in your environment, even if your organization did not build or consciously procure it as an "AI product."
MAP is where you build and maintain your AI system inventory and assess the context-specific risks each system presents.
MAP activities include:
The device-level data question is particularly important and often overlooked. AI systems that process data locally on endpoints have a different risk profile than cloud-dependent systems. On-device processing may reduce data exfiltration risk but introduces questions about model integrity, update cadence, and whether device security controls adequately protect the AI pipeline. Hardware inventory management is a prerequisite for meaningful AI system mapping, you cannot inventory your AI systems if you do not know what devices are running in your environment.
MEASURE translates the risk categories identified in MAP into concrete assessments using metrics, testing, and evaluation.
MEASURE activities include:
For endpoint security teams, MEASURE connects directly to vulnerability assessment workflows. AI models, like software packages, can carry vulnerabilities. Prompt injection flaws in LLM-integrated applications, for example, are increasingly tracked as CVEs. Your existing vulnerability management process should extend to cover AI components.
MANAGE is where risk findings from MAP and MEASURE get converted into action. It covers both proactive risk treatment and incident response.
MANAGE activities include:
MANAGE is where your endpoint security stack becomes directly relevant. Configuration profiles that restrict which AI applications can run on managed devices, data loss prevention controls that govern what data AI tools can access, and application allowlists that block unsanctioned AI tools are all MANAGE-layer controls.
In July 2024, NIST published NIST AI 600-1, the Generative AI Profile. This companion document addresses risks specific to large language models, image generators, and other generative AI systems. It is the most practically relevant addition to the AI RMF for IT teams dealing with enterprise copilots and AI assistants.
NIST AI 600-1 identifies 12 risk categories specific to generative AI:
1. CBRN Information or Capabilities (enabling creation of hazardous materials)
2. Confabulation (hallucinated outputs presented as fact)
3. Data Privacy (training data leakage, PII exposure)
4. Data Provenance (inability to verify training data sources)
5. Harmful Bias and Homogenization (reinforcing societal biases at scale)
6. Human-AI Configuration (inappropriate over-reliance on AI outputs)
7. Information Integrity (generating disinformation or misleading content)
8. Information Security (using AI to accelerate cyberattacks)
9. Intellectual Property (reproducing copyrighted material)
10. Obscene, Degrading, and Abusive Content (generating harmful content)
11. Operational and Safety Risk (AI failures in critical processes)
12. Value Chain and Component Integration (risks inherited from third-party AI components)
For most enterprise IT teams, risks 3, 7, 8, and 12 are the most immediately actionable. If your organization has deployed Microsoft Copilot, Google Gemini, or any AI assistant that accesses internal data, the Data Privacy and Information Security categories require specific controls around what organizational data those tools can access and how outputs are governed.
The framework itself is intentionally high-level. NIST published several companion resources that provide more prescriptive guidance:
The Crosswalks document is underused. Organizations already running SOC 2 compliance or ISO 27001 programs have significant coverage overlap with AI RMF requirements. Mapping your existing controls to the AI RMF before building net-new processes will save substantial effort.
These two frameworks address AI governance from different angles and carry very different legal weight.
| Dimension | NIST AI RMF | EU AI Act |
|---|---|---|
| Legal status | Voluntary | Mandatory (for EU market access) |
| Geographic scope | U.S.-origin, globally adopted | EU jurisdiction, extraterritorial reach |
| Risk classification | Continuous spectrum | Four-tier categorical (Unacceptable, High, Limited, Minimal) |
| Focus | Risk management process | Prohibited uses and conformity requirements |
| Primary audience | Developers and deployers | Developers, deployers, and importers |
| Enforcement | None (voluntary) | Fines up to 35 million EUR or 7% global turnover |
For U.S.-based mid-market companies selling into EU markets or processing EU resident data, the two frameworks are complementary rather than competing. An AI RMF-aligned governance program covers much of the documentation and risk management process the EU AI Act requires for high-risk systems. NIST has published crosswalk documentation mapping AI RMF to EU AI Act requirements.
For organizations subject to both, ISO 42001 provides a certifiable AI management system standard that bridges NIST AI RMF and EU AI Act requirements more directly than either framework does alone.
Most published implementation guidance targets large enterprises with dedicated AI governance teams. Here is a realistic timeline for a mid-market organization with an IT team of 5 to 15 people:
Months 1 to 2: Foundation (GOVERN)
Months 3 to 4: Discovery and Classification (MAP)
Months 5 to 6: Assessment (MEASURE)
Months 7 to 9: Controls and Monitoring (MANAGE)
Ongoing: Continuous Improvement
Most AI governance frameworks focus on the organizational and algorithmic layers. Almost none address the device layer, where AI data processing actually happens for a growing share of enterprise workloads.
Apple Intelligence, introduced in iOS 18 and macOS Sequoia, brings on-device AI processing to every managed iPhone, iPad, and Mac in your fleet. Private Cloud Compute extends this with cloud-based processing that Apple describes as providing verifiable privacy guarantees. On-device ML models power features across Photos, Mail, Notes, and third-party apps through Core ML.
For AI RMF purposes, these capabilities raise specific questions:
MDM configuration profiles can control many of these settings at the device level. Restrictions payloads can disable specific AI features on supervised devices. App management controls determine which AI-enabled third-party apps can install. These are MANAGE-function controls operating at the endpoint layer, and they belong in your AI RMF implementation alongside the organizational policies.
Understanding how device management works at a technical level is a prerequisite for implementing these controls consistently across a fleet.
Iru manages Apple device fleets for mid-market and enterprise IT teams, which puts the platform at the intersection of device management and AI governance in a way that most compliance tools do not address.
The MAP function requires an accurate, continuously updated inventory of AI systems in your environment. For Apple-centric organizations, that starts with knowing exactly which devices are in your fleet, what OS versions they are running (and therefore which Apple Intelligence features are available), and which apps are installed. Iru's device inventory and app catalog capabilities give IT teams that visibility without manual spreadsheet maintenance.
For the MANAGE function, Iru's configuration profile management lets administrators push restrictions that govern AI feature availability at the device level. If your AI use policy prohibits employees from using AI email summarization tools on corporate email, that policy can be enforced through MDM restrictions rather than relying on user compliance alone.
Iru Compliance maps device security controls to SOC 2, ISO 27001, and HIPAA requirements. The AI RMF Crosswalks show how those same controls address AI RMF requirements. Organizations using Iru Compliance can extend their existing control framework to cover AI RMF alignment without building a parallel documentation structure from scratch.
Shadow AI discovery is another area where endpoint visibility matters. When employees install AI tools outside the approved software catalog, those tools show up in Iru's app reporting before they become a governance problem. That aligns directly with the MAP function's requirement to maintain a comprehensive AI system inventory, including systems the organization did not intentionally deploy.
An AI governance program that lives only in policy documents does not reduce risk. The organizations that get the most value from NIST AI RMF implementation are the ones that close the loop between policy and technical enforcement.
For IT teams, that means treating AI governance as an extension of existing security operations rather than a separate compliance project. Your endpoint hardening baseline should include AI-specific configurations. Your software procurement process should include AI risk assessment as a standard step. Your incident response runbooks should cover AI-related failures alongside traditional security incidents.
The framework is designed to be iterative. You do not need to achieve full maturity across all four functions before you start seeing risk reduction. A realistic first-year goal for most mid-market organizations is to complete the AI system inventory, establish governance ownership, and implement controls for the three to five highest-risk AI systems in production. That baseline is more defensible in a customer security review than a comprehensive policy document with no implementation behind it.
If your organization already has an IT compliance program, you have more of the AI RMF foundation in place than you think. Use the compliance automation tools and frameworks you already operate to extend into AI governance rather than starting from scratch.
To see how Iru can support your AI governance program at the device and endpoint layer, Book a demo.