Where do NIST AI RMF reviews usually find gaps?

NIST does not certify anyone against the AI RMF, and we know of no public dataset of findings, so nobody can honestly rank the most common ones. A reviewer reads your records against the subcategories. These seven gaps are where they would look first. They are our reading, not measured frequencies.

The AI RMF is voluntary. NIST describes it as rights-preserving, non-sector-specific and use-case agnostic. A "finding" here means an internal review, a customer's due diligence questionnaire, or a third-party assessment that uses the framework as its yardstick. NIST's overview page also notes that AI RMF 1.0 is being revised, so check the current version.

Gap 1: No inventory of AI systems

GOVERN 1.6 asks for mechanisms to inventory AI systems, resourced according to risk priorities. A team may know about the flagship model and miss the embedded feature, the vendor tool with AI inside, and the internal prototype that quietly became production.

Fix: a single list with an owner, purpose, data used, model provider and status for every system. Review it quarterly.

Gap 2: Intended purpose not written down

MAP 1.1 asks that intended purposes, beneficial uses, context-specific laws, norms and expectations, and prospective settings are understood and documented, including assumptions and limitations. Without this, no one can say whether a use is out of scope.

Fix: a one page statement per system: who uses it, for what, in which settings, and what it must never be used for.

Gap 3: Testing exists but is not documented

MEASURE 2.1 asks that test sets, metrics and details about the tools used are documented. MEASURE 2.3 asks that performance criteria are measured and demonstrated for conditions similar to deployment. Engineers may test informally, and the results can live in a notebook no one else can find.

Fix: keep the test set, the metric, the result and the date in a repository, tied to a release.

Gap 4: Validity claimed, limits not stated

MEASURE 2.5 asks that the system is demonstrated to be valid and reliable and that limits on generalizability are documented. Reviewers look for the second half, which is the half most often missing.

Fix: add a "known limits" section to each system's documentation, updated whenever testing finds something new.

Gap 5: No production monitoring or incident path

MEASURE 2.4 asks that functionality and behavior are monitored in production. MANAGE 4.1 asks for post-deployment monitoring plans covering user input, appeal and override, decommissioning, incident response, recovery and change management. MANAGE 4.3 asks that incidents and errors are communicated to relevant AI actors and that processes exist to track and respond.

Fix: pick two or three signals per system, set thresholds, name who gets the alert, and run one tabletop on a bad-output incident.

Gap 6: Third-party risk is a contract, not a control

GOVERN 6.1 asks for policies that address AI risks associated with third parties, and GOVERN 6.2 asks for contingency processes for failures or incidents in third-party data or AI systems deemed high-risk. MAP 4.1 covers mapping risks of components, including third-party data or software.

Fix: for each external model, dataset or library, record the provider, the data you send, what happens if it changes or disappears, and the fallback. A software bill of materials for the application, extended to models and datasets where you can, helps with the component part.

Gap 7: Human oversight is assumed

MAP 3.5 asks that processes for human oversight are defined, assessed and documented. One risk is a reviewer who exists on paper and approves everything.

Fix: define what the reviewer checks, how many items they handle per hour, and how often they overrule the system. If the override rate is near zero, find out why.

How should you prepare?

Do a self-assessment using the subcategories above as a checklist. For each, ask one question: could a stranger find the evidence in under ten minutes? If not, the gap is documentation, not capability.

Automation can collect some of it. Safeguard's documentation lists NIST AI RMF in its framework library and says each framework page states which requirements a scan can decide and which need your evidence. That is a support for your records, and it does not make anyone compliant or certified.

What to do

1. Build the AI system inventory this week.
2. Write one page of intended purpose and limits for each system.
3. Move test sets and results into version control.
4. Define monitoring signals and an incident path, and rehearse it.
5. Record third-party dependencies and fallbacks.
6. Re-run the ten minute evidence test each quarter.

Quick check

Sources

• NIST, AI Risk Management Framework overview
• NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• Safeguard docs: All frameworks

Last reviewed: 18 October 2026.