How to map an AI feature onto the NIST AI RMF and the EU AI Act

Two questions decide what one AI feature owes: which role you hold for it under the EU AI Act, provider or deployer, and what decision its output feeds. Answer those and the obligation set is short. The work left is pointing each obligation at an artifact your team already produces, and keeping that pointer accurate as the feature changes.

Why the frameworks feel unusable at feature scale

Governance material is written for programmes. The NIST AI Risk Management Framework describes an organizational function with roles, policies and a risk culture. The EU AI Act addresses providers and deployers placing systems on a market. A team of six shipping one assistant reads both and finds no instruction that begins with "for your feature".

The gap is scope rather than difficulty. At feature scale the frameworks reduce to two kinds of output: decisions recorded once (what this is for, who owns it, which tier it sits in) and evidence produced continuously (test results, execution records, approval records). Background on both frameworks, the four risk tiers and the staged application dates sits on the AI governance hub. What follows is the mapping exercise.

What do I actually have to do to comply for an AI feature

Three questions, answered per feature and in order. Each narrows the obligation set. Answering them out of order produces the common mistake of treating an internal tool and a shipped product as the same system.

1. Fix your role, and expect it to be two roles

The provider is the party that develops a system, or has it developed, and places it on the market or puts it into service under its own name or trademark. The deployer uses a system under its own authority, outside a personal non-professional activity. Building an assistant on a hosted model makes you the provider of the system you shipped, while the model vendor carries the separate Chapter V obligations that attach to general-purpose models. You are simultaneously a deployer whenever your own staff use the feature.

Being a provider to customers who are themselves deployers has two practical effects. Your customers can only meet their own duties with material you hand them, so instructions for use and access to their own records become product surface rather than paperwork. And under Article 25 a customer who puts their own name on the system, substantially modifies it, or changes its intended purpose so that it becomes high-risk takes on the provider's obligations, which is a contract question before it is an engineering one.

2. Take the tier from the decision the output feeds

Write one sentence in this shape: "The output of this feature [verb] for [whom]." Then read the verb. If it informs a person who then acts, the feature is doing what most assistants do. If it ranks, scores or filters people so that a human decision follows the ranking, it is doing something the Act treats more seriously. If it decides automatically, the tier follows the domain of the decision.

Then check the domain against the eight Annex III areas: biometrics, critical infrastructure, education and vocational training, employment and worker management, essential public and private services (the area that covers creditworthiness and life or health insurance pricing), law enforcement, migration and border control, and administration of justice and democratic processes. A support assistant that answers billing questions is outside that list. The same assistant, wired to approve or decline a credit limit change, is inside it. Article 6(3) pulls a listed system back out where it poses no significant risk of harm and only performs a narrow procedural or preparatory task, though a system that profiles natural persons stays high-risk.

3. Check the two triggers that fire at any tier

Direct interaction with a person triggers a disclosure duty: the person is informed they are dealing with an AI system unless that is obvious from the context. Generating or manipulating synthetic image, audio, video or text triggers a machine-readable marking duty, which does not bite where the system assists standard editing or leaves the input data and its meaning substantially unchanged. Both attach to the interaction rather than to the system, so they are per surface. A feature reachable through a web widget, Slack and an SMS number has three places to satisfy them, and a customer embedding your widget must not be able to remove the notice.

The rule for re-running this

The tier is a property of use, and use drifts without a code change. Re-run the three questions when any of these happen: a tool with a write effect is added to the agent; a customer asks for the output to feed an automated decision; the feature is offered to a new population, such as job applicants or loan customers; or the intended-purpose sentence in your own documentation stops matching what the feature does. Put that list in the pull-request template for the agent's configuration, where it will actually be read.

From requirement to a control you can configure

Each row below is one requirement, the control that satisfies it in a running feature, and the artifact an auditor or a customer's security team can be shown. The Chapter III articles cited bind high-risk systems, and Regulation (EU) 2026/1744 moved their application to 2 December 2027 for Annex III systems; the rows still describe the shape of the evidence a limited-risk feature is asked for.

Two rows are worth reading twice. The oversight row fails quietly more often than any other: an approval gate whose timeout auto-approves, or whose approver reads only the agent's own stated reason, satisfies a diagram and nothing else. That reason is text the model produced, and under prompt injection it is text an attacker produced, so it belongs on the screen as context and never in the decision logic. The record-keeping row is the one that turns into a privacy problem if the logs keep everything the model saw.

Four artifacts carry most of the weight

Most of the overlap sits in four places. The execution record answers the RMF Measure function, the Act's record-keeping duty, your own incident review and a customer's "show me what happened on Tuesday" question. The eval suite answers Measure, the accuracy and robustness duty, and the regression question a model upgrade raises. The version history answers Govern, the documentation duty and the change-control question in every security questionnaire, while the tool inventory answers Map, the risk management duty and the scoping rule above, because it is what changes when the tier drifts.

Keep an index that points at the live source of each, rather than copies that go stale:

{
  "feature": "billing-assistant",
  "owner": "platform-team@example.com",
  "role": { "eu_ai_act": "provider", "also_deployer_for": "internal staff use" },
  "tier": { "value": "limited", "basis": "interacts with people; no Annex III use", "reviewed": "2026-09-01" },
  "evidence": [
    { "requirement": "record-keeping", "source": "traces", "query": "execution_id", "retention_days": 180 },
    { "requirement": "accuracy", "source": "eval-suite/billing-regression", "threshold": 0.9 },
    { "requirement": "oversight", "source": "approval-log", "gated_tools": ["issue_refund", "change_plan"] },
    { "requirement": "transparency", "source": "screenshots/disclosure", "surfaces": ["web", "slack", "sms"] },
    { "requirement": "documentation", "source": "version-history", "granularity": "published version" }
  ],
  "rerun_scope_check_on": ["new write tool", "new customer use case", "new user population"]
}

The index is short by design. Anything longer becomes a document someone maintains separately from the system, which is the failure mode the frameworks are least able to detect and auditors are quickest to find.

Where this gets easier

The decision half of this stays yours: the role, the tier, the intended purpose and the owner are judgement calls no tool makes for you. The evidence half falls out of running the feature somewhere that keeps it. Runtype records an execution trace per run with per-step input and output, every tool call with its arguments and results, and the tenant and end user the run happened under; approval gates are enforced per tool with a timeout, and the approver sees the agent's stated reason as a claim that never drives the decision; eval suites re-run against a prompt or model change with cases promoted from recorded executions; PII redaction and logging verbosity are policies set per product, surface or agent and resolved at dispatch; and draft and published versions make "which prompt was live on that date" a lookup rather than an archaeology exercise. None of that is a certification or a compliance opinion, the obligations stay with you, and what changes is how much of the right-hand column of the table above already exists on the day someone asks for it.