Most compliance teams I talk to have read the headline of NIST AI 600-1 and stopped there. They know it exists, they know it's "the generative AI one," and they know someone eventually needs to map their AI program against it. Few have actually sat down with the twelve risk categories and asked the harder question: if an auditor asked me to prove I'd addressed each one, what would I hand them? That auditor could be an internal team, a client's vendor-risk team, or a lead auditor doing an ISO/IEC 42001 gap assessment.
That's the gap this article closes. NIST AI 600-1, the Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, was released in July 2024 as a companion to the original NIST AI RMF 1.0 (published January 2023). It names twelve categories of risk that are new to, or significantly worsened by, generative AI, and it organizes suggested actions under the RMF's four functions: Govern, Map, Measure, and Manage. It is voluntary guidance, not a regulation, and there is no accredited body that issues a certificate against it — which means the "evidence" an auditor expects is evidence of a documented process, not a passed exam.
That distinction matters more than it sounds like it should. A lot of organizations treat NIST AI 600-1 like a checklist to satisfy once and file away. Auditors — the good ones, anyway — treat it like a set of questions they'll ask again next year, and they expect your answers to have gotten more specific, not just repeated.
What NIST AI 600-1 Actually Is
The original AI RMF gave organizations a general risk-management vocabulary: Govern (set policy and accountability), Map (understand context and identify risks), Measure (test and analyze), Manage (respond and monitor). It was written to apply to any AI system. NIST AI 600-1 takes that same four-function structure and asks a narrower question: what does generative AI do differently, and where does the general framework need sharper teeth?
The answer NIST landed on is twelve risks. Some of them — data privacy, information security — existed before generative AI and are simply harder to manage now. Others, like confabulation (NIST's clinical term for hallucination) and value chain and component integration risk, are close to unique to how large models are built and deployed: on top of someone else's foundation model, trained on someone else's data, fine-tuned with a process nobody can fully audit after the fact.
The 12 Risk Categories and the Evidence Each One Requires
The table below is the fast version. The sections after it go deeper on where organizations typically fall short.
| Risk Category | What It Covers | Evidence an Auditor Expects |
|---|---|---|
| CBRN Information or Capabilities | Model outputs that lower the barrier to chemical, biological, radiological, or nuclear harm | Documented red-team test plans targeting uplift scenarios, refusal-rate results, access-tier controls, escalation log to a safety or security owner |
| Confabulation | Plausible but false or unsupported outputs presented with confidence | Groundedness/accuracy benchmarks, human-review sampling logs, user-facing disclosure language, citation-coverage metrics for RAG systems |
| Dangerous, Violent, or Hateful Content | Outputs that incite violence, self-harm, or hatred | Content policy document, guardrail/classifier test results, red-team transcripts, retest log after each model or prompt-template update |
| Data Privacy | Exposure or inference of personal data through training, fine-tuning, or inference | Data inventory covering every pipeline stage, retention and minimization records, memorization/regurgitation test results, data processing agreements with model vendors |
| Environmental Impact | Energy and resource consumption of training and inference | Documented compute/energy estimate for material training or fine-tuning runs, vendor sustainability disclosures, a written rationale for model-size selection |
| Human-AI Configuration | Over-reliance, automation bias, and unclear human oversight | UX documentation showing AI disclosure to users, defined human checkpoints for consequential decisions, staff training records, override/escalation path |
| Information Integrity | Erosion of the information ecosystem through synthetic content at scale | Content provenance or watermarking approach, synthetic-media labeling practice, monitoring for coordinated misuse, incident log |
| Information Security | New attack surfaces: prompt injection, data poisoning, model extraction | Adversarial/jailbreak test results, access and logging controls, vendor security attestation (e.g., SOC 2), an incident response plan naming AI-specific attack vectors |
| Intellectual Property | Infringement in training data or in generated output | Training-data provenance and licensing records, output-similarity screening, vendor indemnification terms, employee-use policy for IP-sensitive work product |
| Obscene, Degrading, and/or Abusive Content | Generation of sexual, exploitative, or abusive material, including CSAM | Category-specific guardrail test results, filtering logs, a mandatory-reporting procedure aligned to legal duties, access controls where relevant |
| Harmful Bias and Homogenization | Disparate treatment of protected groups and narrowing of outputs across users | Bias testing results by protected class, evaluation-dataset composition record, remediation log, independent bias-audit results where legally required |
| Value Chain and Component Integration | Risk inherited from third-party models, data, and plugins built into the system | Full component inventory, contractual risk-allocation terms, an internal risk assessment covering components the organization did not build, monitoring for upstream model changes |
Content and Safety Risks: CBRN, Dangerous Content, and Obscene Content
These three sit together because auditors test them the same way: adversarially. If your only evidence is a written policy that says the model "will not generate harmful content," that's a statement of intent, not evidence. What an auditor wants is proof you tried to break it — a red-team engagement with a defined scope, documented prompts, the model's actual responses, and what changed afterward. For CBRN specifically, NIST's companion document, SP 800-218A on secure development practices for generative AI and dual-use foundation models, is worth pairing with your evidence file, since it describes the kind of pre-release testing NIST expects from model developers themselves. For obscene and abusive content, the bar is higher still, because in the United States some of it triggers mandatory reporting obligations regardless of your AI governance maturity. An auditor checking this category is really checking whether your legal and trust-and-safety teams have talked to each other.
Confabulation and Information Integrity
Confabulation is the risk category that non-technical stakeholders understand fastest, because everyone has seen a chatbot state something false with total confidence. The evidence gap here is usually measurement: teams know their model hallucinates sometimes, but they haven't sampled outputs at any regular cadence to say how often, in what contexts, or whether it's getting better or worse after a model update. A defensible answer looks like a sampling protocol — even a modest one, reviewed monthly — with a log of what was checked and what was corrected.
Information integrity is the category most often confused with confabulation, but it's really about scale and intent: synthetic content flooding an information ecosystem, not a single wrong answer. If your organization generates external-facing content with AI at any volume, an auditor will ask how you label it and whether you can distinguish AI-generated from human-authored material in your own systems.
Data Privacy, Information Security, and Intellectual Property
I group these three because they're the risks most regulated organizations already have some infrastructure for — and the ones auditors are quickest to find gaps in, because that existing infrastructure was built for a pre-generative-AI world. A privacy program built around structured databases doesn't automatically account for a model that memorizes and can regurgitate fragments of training data. A security program built around network perimeters doesn't automatically account for prompt injection through a document a user uploads. An IP program built around your own authored content doesn't automatically account for a model trained on data whose licensing terms you never reviewed.
The evidence that satisfies an auditor here is specific:
- A data inventory that actually traces personal data through the fine-tuning or retrieval pipeline, not just the production database.
- Adversarial testing results that name prompt injection and model extraction as tested attack types, not generic penetration test language.
- A documented review of training-data provenance for any model you fine-tuned or licensed for internal use.
Harmful Bias and Homogenization
This is the category with the clearest legal teeth already attached, because several U.S. jurisdictions have turned "test for bias" into a statutory requirement rather than a best practice. New York City's Local Law 144 requires an independent bias audit for automated employment decision tools before use. Colorado's AI Act originally imposed impact-assessment duties on developers and deployers of high-risk AI systems, but SB 189 (signed May 14, 2026) narrowed the law significantly — eliminating the deployer risk-management and impact-assessment obligations — and pushed the effective date to January 1, 2027, so confirm the current scope before relying on the original framework. If your generative AI system touches hiring, lending, insurance, or another consequential decision, the evidence an auditor expects isn't just internal fairness testing — it's proof the testing meets whatever your applicable jurisdiction's bar actually is, with dated results, not a policy promising to test "as needed."
Value Chain and Component Integration
Of the twelve categories, this is the one most compliance teams miss first, because it requires treating a licensed foundation model's weaknesses as the deploying organization's own risk to document. It's tempting to think that if OpenAI, Anthropic, or Google built the model, the model's risk is their problem. NIST AI 600-1 doesn't let you make that move. If you deploy it, you own the risk assessment for it — including for the plugins, retrieval connectors, and third-party datasets wired into your particular implementation. The evidence here is threefold:
- A real component inventory (most organizations don't have one when I ask).
- Contractual terms that actually allocate risk rather than disclaiming it entirely.
- A process for finding out when an upstream vendor changes the underlying model — a silent model swap can quietly invalidate every other piece of evidence in this list.
Human-AI Configuration and Environmental Impact
These two get the least attention and, in my experience, are the easiest to close once someone actually looks at them. Human-AI configuration risk is about over-reliance: does a human actually review a consequential AI-generated decision, or does the "human in the loop" step exist on a diagram but not in practice? The evidence is procedural — a defined checkpoint, a record of overrides, training records showing staff know when not to trust the output.
Environmental impact is the category where I tell clients not to overbuild. Few organizations outside frontier model developers can produce an audited carbon figure, and NIST doesn't expect one. What it expects is a documented rationale: why did you choose this model size for this task, and did resource consumption factor into that decision at all? A one-page memo beats silence.
How Auditors Actually Use This Document
Here's the part worth being honest about: nobody is failed against NIST AI 600-1 the way they'd be failed against an ISO standard. There's no certificate, no accredited registrar, no pass/fail letter. What actually happens is one of three things. An internal audit team uses it as a checklist to structure a governance review. A client's vendor-risk questionnaire quietly borrows its twelve categories, sometimes without naming the source. Or an ISO/IEC 42001 lead auditor uses it as a cross-reference during a Clause 6.1.2 risk assessment review, checking whether your organization's own risk register covers ground NIST flagged as generative-AI-specific.
That last use case is becoming the most common one I see, because ISO 42001 tells you to run a risk assessment but doesn't hand you a risk taxonomy — NIST AI 600-1 does. Pairing the two is arguably the most efficient path to a defensible AI governance program: ISO 42001 for the management system structure and audit certification, NIST AI 600-1 for the generative-AI-specific risk content that fills it in. I've written before about how ISO 42001 and the NIST AI RMF complement rather than compete with each other, and this is the clearest example of why: the RMF's Govern function alone — covered in more depth here — maps almost directly onto ISO 42001's leadership and accountability clauses.
It's also worth naming the political context, since this is a live document in a shifting environment. The original NIST AI RMF and its generative AI profile trace back to a 2023 executive order that was rescinded in early 2025 and replaced with a different federal AI policy direction. The publications themselves remain live, unwithdrawn, and in active use by industry and by state regulators building their own frameworks — but they no longer carry the presidential mandate that prompted their creation. In practice, that changes nothing about what evidence an auditor will ask you for. It changes the argument for why you should have it: not "the federal government requires this," but "this is still the most detailed, freely available risk taxonomy for generative AI, and your customers' vendor-risk teams already know it."
Building the Evidence File Before You're Asked For It
The pattern I see most often is an organization that has real controls in place — a red-team process, a bias-testing cadence, a vendor security review — but no single place where that evidence is organized against the twelve categories. When an auditor or a client's procurement team asks, the answer takes three weeks to assemble instead of three minutes, and the delay itself reads as a governance gap even when the underlying controls are sound.
The fix isn't more controls. It's a single evidence map: twelve rows, one per category, each pointing to the artifact that proves the work happened — a test report, a policy document, a training log, a contract clause — dated and owned by a named person. Build that once, update it when you retest or redeploy, and the next audit stops being a scramble.
If you're building a generative AI risk assessment from scratch and want a structured starting point rather than a blank page, our AI risk assessment service walks through exactly this mapping exercise against your actual systems.
FAQ
Is NIST AI 600-1 legally required? No. It's voluntary guidance published by NIST, not a regulation. No U.S. federal law mandates compliance with it directly — the 2023 executive order that prompted its creation was rescinded in early 2025 without a replacement mandate taking its place. Some state laws, such as Colorado's AI Act (narrowed and delayed to January 1, 2027 by SB 189, signed May 2026) and New York City's Local Law 144, impose their own binding requirements that overlap with several of its risk categories.
How does NIST AI 600-1 differ from the base NIST AI RMF? The base AI RMF (published January 2023) applies to any AI system and defines four functions: Govern, Map, Measure, Manage. NIST AI 600-1 is a profile that applies that same structure specifically to generative AI, adding twelve named risk categories and suggested actions unique to how large models are built and deployed.
Do we need a NIST AI 600-1 certificate to work with regulated clients? No such certificate exists. There is no accredited body issuing certification against NIST AI 600-1. What regulated clients typically want is evidence — documented risk assessments, test results, and governance records — mapped against its categories, often as part of a vendor-risk questionnaire or an ISO/IEC 42001 audit.
Which of the 12 risk categories do organizations usually address last? Value chain and component integration risk is the most commonly missed, because it requires assessing risk in third-party foundation models, plugins, and datasets rather than only in systems the organization built itself. Environmental impact and human-AI configuration also tend to get less attention until an audit specifically asks about them.
Can ISO/IEC 42001 certification substitute for NIST AI 600-1 alignment? They serve different purposes and work best together. ISO 42001 is a certifiable management system standard that requires a risk assessment process (clause 6.1.2) but doesn't specify a generative AI risk taxonomy. NIST AI 600-1 supplies that taxonomy. Many organizations use NIST AI 600-1's twelve categories to populate the risk register that ISO 42001 requires them to maintain.
Last updated: 2026-08-24
Jared Clark
AI Governance Consultant, Regulated AI Consulting
Jared Clark is the founder of Regulated AI Consulting, advising organizations on AI governance frameworks, ISO 42001 compliance, and responsible AI deployment in regulated industries.