AI Risk Classification: NIST AI RMF and EU AI Act

The Translation Problem

Most AI governance work produces policy without architecture. Organizations create AI use guidelines and risk classification schemes but struggle to connect those documents to the technical controls that make policy enforceable.

NIST AI RMF (2023) structures AI risk management across four functions: Govern (organizational accountability and oversight), Map (contextual understanding and risk identification), Measure (analysis, assessment, benchmarking, and evaluation), and Manage (allocation of resources and treatment of risks). The GOVERN function is listed first — NIST explicitly states that AI risk management requires organizational commitment and accountability before technical controls can be effective.

The EU AI Act (Regulation 2024/1689), Article 6, classifies AI systems as high-risk when they are used in one of eight sectors listed in Annex III — including biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration, and administration of justice. High-risk AI systems face obligations including conformity assessment (Article 43), technical documentation (Article 11), human oversight measures (Article 14), and cybersecurity requirements (Article 15).

Regulatory frameworks describe outcomes; security programs must design controls that produce those outcomes. The pivot is classification. Once an AI system is classified, that classification is not a filing label — it is the switch that sets, for each control lane, who owns the control, what control must exist, what evidence proves it operates, and what re-fires when the classification changes. This article translates the frameworks into that operating model: the crosswalk below is the map, and the operating-model table that follows is what a practitioner actually runs from.

NIST AI RMF Four Functions

The NIST AI Risk Management Framework organizes security controls around four operational functions. Each function maps to specific control points in AI security architecture:

GOVERN requires organizational accountability and oversight structures. This maps to AI governance program design in the GOV lane — specifically the AI system approval process, classification tiers, and accountability assignment. Security teams must build governance controls that track AI system inventory, assign ownership, and enforce approval workflows for new AI deployments.

MAP requires contextual understanding and risk identification for each AI system. This translates to AI system classification controls that feed governance approval workflows. The MAP function demands that security programs classify AI systems by risk level, intended use, and environmental context before those systems enter production. Without classification, governance controls cannot differentiate between low-risk automation and high-impact decision systems.

MEASURE requires analysis, assessment, benchmarking, and evaluation of AI system performance. This maps directly to AI security testing capabilities in the APPSEC lane — red teaming, adversarial evaluation, output validation testing. MEASURE is not software testing; it is behavioral testing of AI decision systems under adversarial conditions.

MANAGE requires allocation of resources and treatment of identified risks. This connects to incident response for AI systems — behavioral anomaly detection, decision authority revocation, and containment procedures when AI systems produce unexpected outputs. MANAGE requires ongoing monitoring that can detect when AI systems deviate from expected behavior patterns.

EU AI Act Risk Tiers

The EU AI Act establishes a four-tier risk classification: prohibited AI practices (Article 5), high-risk AI systems (Article 6 and the Chapter III obligations), limited-risk AI systems subject to transparency obligations (Article 50), and minimal-risk AI systems (no specific obligations). Security programs must focus on high-risk tier requirements — that is where technical control obligations attach.

High-risk AI systems face five security-relevant requirements. Conformity assessment (Article 43) requires organizations to demonstrate that AI systems meet technical standards before deployment — this maps to governance approval workflows with technical validation checkpoints. Technical documentation (Article 11) requires detailed system specifications and risk assessments — this maps to AI system inventory and classification controls that track system capabilities, data sources, and decision boundaries.

Human oversight measures (Article 14) require meaningful human control over high-risk AI decisions. This translates to authority controls in the AGENT lane — specifically human approval requirements for high-impact decisions and the ability to override AI recommendations when humans identify problems.

The EU AI Act's Article 15 requires high-risk AI systems to be designed and developed to achieve an appropriate level of accuracy, robustness, and cybersecurity throughout their lifecycle — and to be resilient against attempts by unauthorized third parties to alter the system's use, outputs, or performance by exploiting system vulnerabilities. This explicitly frames adversarial input resistance (prompt injection defense, output manipulation prevention) as a regulatory requirement for high-risk AI deployers.

Cybersecurity requirements demand adversarial resistance controls — prompt injection defense, output validation, and input sanitization that prevent unauthorized manipulation of AI system behavior. This maps to input/prompt security controls and output validation testing in the APPSEC lane.

Where Frameworks Map To Control Points

Crosswalk: NIST AI RMF × EU AI Act, by Control Lane

The table above is framework-first. Read the other way — by control lane — it becomes a crosswalk for a team accountable to both frameworks at once: each lane shows what NIST AI RMF and the EU AI Act each demand, and the last column places the "must add" capabilities (detailed below) where they belong.

Read a row to answer "for this control lane, what does each framework require, and what do I have to build?" The right-hand column is exactly the three capability gaps in "What Security Programs Must Add" below, placed in the lane that owns each.

From Crosswalk to Operating Model: What Classification Changes

The crosswalk answers "what does each framework demand per lane." The operating question is sharper: once you classify an AI system, what actually changes in the security program? Classification drives four things in each lane — who owns the control, what control must exist, what evidence proves it operates, and what re-fires when the risk classification moves.

Read this way, classification stops being a compliance label an auditor files and becomes the operating trigger: it assigns ownership, mandates a control, demands evidence, and re-fires when risk moves. A practitioner who classifies an AI system should be able to name, for each lane, the owner, the required control, the evidence that proves it, and what changes when the tier moves — that is what this article should leave them able to do.

What Security Programs Must Add

Current security programs typically lack three capabilities when they attempt to satisfy these frameworks. Governance programs often produce AI use policies and classification schemes but not the control architectures that make those policies enforceable. A classification policy without supporting technical controls creates compliance documentation, not security controls. The GOV lane addresses this gap by connecting policy to control point architecture.

Security testing programs can evaluate traditional software but struggle with AI application behavior testing. NIST AI RMF MEASURE and EU AI Act cybersecurity requirements demand adversarial testing — red teaming that attempts prompt injection, output manipulation, and decision boundary exploitation. The APPSEC lane provides the testing architecture that regulatory frameworks assume exists.

Identity and access programs govern human access but lack frameworks for AI agent authority. EU AI Act human oversight requirements and NIST AI RMF MANAGE both assume that organizations can control AI system decision authority — grant permissions, revoke access, and enforce approval workflows for AI-driven actions. The AGENT lane builds the authority control architecture that regulatory compliance requires.

CISA's "Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems" (April 2024, co-authored with partner agencies) provides implementation guidance for organizations deploying AI systems in operational contexts. The guidance addresses supply chain risk, model hardening, inference infrastructure security, and monitoring — mapping organizational AI security controls to NIST AI RMF and sector-specific regulatory requirements.

A security program that satisfies NIST AI RMF GOVERN without the supporting control architecture produces a policy document, not a security control. Regulatory frameworks describe what must be achieved; the lane-based control architecture describes how to achieve it. The translation from regulatory requirement to operational control is where most AI governance efforts fail — and where security practitioners must focus their design work.

Sources