EU AI Act vs NIST AI 600-1: Generative AI Deployer Controls Mapped

Legal force and scope: where the two instruments differ

Regulation (EU) 2024/1689, the AI Act, was adopted on 13 June 2024. The Commission describes it as setting risk-based rules for AI developers and deployers regarding specific uses of AI. As of November 2026, no reviewed material reports a delay, repeal or amendment of the deployer provisions. The Commission states that the rules on general-purpose AI became effective in August 2025.

Scope is the second difference. The deployer duties discussed here attach to high-risk AI systems. They do not apply to every generative AI use in an organization. A deployer therefore starts by inventorying its generative AI systems and deciding which are high-risk, and which fall under transparency or general-purpose AI rules only. Recital 91 adds that general-purpose AI systems usable directly by deployers for at least one high-risk purpose are subject to market surveillance cooperation with the AI Office, which matters when scoping generative AI deployments.

NIST AI 600-1 works differently. It is a profile that applies the NIST AI RMF functions (Govern, Map, Measure and Manage) to generative AI. A regulated enterprise adopts it by choice, so it carries no legal force and no deployer-versus-provider classification test. Where the AI Act says what a deployer must do for in-scope systems, the profile offers a structured way to identify generative AI risks and select actions against them. Evidence produced under the profile is useful, but it does not by itself satisfy a legal duty.

Deployer control domains mapped

The table pairs each AI Act deployer duty with the NIST function where a deployer would normally place the corresponding control. The NIST alignment is a working crosswalk. Teams should confirm each pairing against the specific suggested actions in the profile.

• Human oversight: AI Act: assign oversight to natural persons with the necessary competence, training and authority, and support. NIST working alignment: Govern (roles, accountability) and Manage (response). Runtime: escalation for human approval can route a specific action to a reviewer. Assignment, training and authority stay organizational.
• Use per instructions: AI Act: take appropriate technical and organisational measures to use the system in accordance with the instructions for use. NIST working alignment: Map (context and intended use). Runtime: policy can allow or block interactions that fall outside the documented use. Collecting and interpreting the instructions is organizational.
• Input data governance: AI Act: to the extent the deployer controls input data, ensure it is relevant and sufficiently representative for the intended purpose. NIST working alignment: Map and Measure. Runtime: redact or block inputs that violate defined rules. Representativeness assessment is an organizational data process.
• Monitoring: AI Act: monitor operation on the basis of the instructions for use and, where relevant, inform providers under Article 72. NIST working alignment: Measure and Manage. Runtime: enforcement decisions are observable per interaction. Defining what to monitor and informing providers are organizational.
• Record-keeping: AI Act: Recital 91 refers to record-keeping, as appropriate. NIST working alignment: Govern (documentation) and Measure. Runtime: each enforced decision can produce a durable record. Retention periods and format should follow the final article text for the system in scope.
• Transparency and incidents: AI Act: transparency obligations for providers and deployers of certain AI systems; serious incidents and malfunctioning are reported by providers and deployers. NIST working alignment: Govern and Manage. Runtime: limited to enforcing disclosure or labelling rules where they apply to outputs. Incident classification and reporting are organizational.

Runtime controls versus organizational processes

The AI Act requires technical and organisational measures. A useful crosswalk splits each duty along that line. Controls applied per interaction or per tool call can be enforced in the execution path: allow, redact, block, rate limit, or escalate for human approval. Controls about people, authority, documentation and judgment cannot.

Human oversight shows the boundary clearly. The Act requires that the persons assigned to oversight have competence, training and authority, and Recital 91 specifically mentions an adequate level of AI literacy. Those are properties of people and of the organization. An escalation-for-approval step can put a consequential action in front of a reviewer before it executes, but it supports the oversight duty only if the reviewer actually has that competence and authority. The routing mechanism does not replace the assignment.

Monitoring follows the same pattern. The duty is tied to the provider's instructions for use, so those instructions define what is monitored. A runtime policy can enforce the parts of that definition that are expressible per interaction. The deployer still decides what the instructions require, reviews the results, and informs providers where relevant. The Act also leaves deployers free to organize their own resources to implement the provider's oversight measures, and it does not displace other Union or national law, so the control set should be checked against sector rules as well.

Transparency, incidents and the voluntary tools in the AI Act ecosystem

Not everything near the AI Act is binding. For transparency, the Commission lists Guidelines on transparency obligations for providers and deployers of certain AI systems, which clarify scope, definitions, obligations and exceptions. It also lists a voluntary Code of Practice on Marking and Labelling of AI-generated Content, intended to guide providers and deployers of generative AI systems. A deployer can treat both as reference material for transparency controls, while keeping in mind that the Code is voluntary and the legal obligation is not.

For incidents, the Commission states that providers and deployers will report serious incidents and malfunctioning. The deployer-side control set needs a defined path from detection to classification to reporting. Runtime enforcement contributes the detection signal and the record of what was attempted and what policy decided. Deciding whether an event is a serious incident, and reporting it, is a human and legal process.

The practical consequence is to keep two registers: one marked binding, tied to the AI Act duties for in-scope systems, and one marked voluntary, tied to NIST AI 600-1 and any labelling code the organization adopts. A single control can satisfy entries in both, but the register should show which one is the reason it exists.

Building the deployer control set

Start with the AI Act side, because it determines which systems carry binding duties. Then layer the NIST profile onto the same controls rather than building a parallel program.

• Inventory and classify: List deployed generative AI systems and decide which are high-risk. Duties for high-risk systems do not extend automatically to all generative AI use.
• Collect instructions for use: Obtain each provider's instructions, since use, oversight and monitoring duties are defined by reference to them.
• Assign and document oversight: Record who holds oversight, their competence and training, including AI literacy, and their authority to intervene.
• Locate input control: Identify where the deployer actually controls input data and set relevance and representativeness checks there.
• Tag each control: Mark every control as runtime-enforceable or organizational, and as binding or voluntary.
• Define evidence per control: State what record each control should produce, and confirm retention and format against the applicable article text.

Evaluating runtime enforcement and the evidence it produces

When assessing any runtime enforcement approach, ask which duties it acts on per interaction or tool call, and which it leaves to your processes. A credible answer will be narrower than the full list of deployer duties. No runtime tool delivers compliance on its own, because assignment of oversight, training, monitoring against instructions for use and incident reporting remain deployer responsibilities.

Also ask what evidence each enforced control produces. For an auditor or regulator, useful evidence shows the policy that applied, the action taken (allow, redact, block or escalate), who approved an escalated action, and when. That evidence should be durable and exportable against the control register, and its retention and data residency should be configurable to your obligations.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Enforcement generates audit-ready evidence mapped to the EU AI Act and NIST. This covers the runtime column of the crosswalk above. It does not cover model provenance, dataset provenance or end-to-end tracing of agentic workflows, and it does not replace the organizational processes described here.