Generative AI Profile
NIST AI 600-1, published in July 2024, is a cross-sectoral companion Profile for generative artificial intelligence. It helps organisations identify generative-AI risks and select actions that fit their goals and priorities.
When to use it
Section titled “When to use it”Use the Profile when the system generates or materially transforms:
- Text.
- Images.
- Audio.
- Video.
- Code.
- Synthetic data.
- Multimodal content.
It is also relevant to applications built on foundation models, chatbots, copilots and other generative services.
Relationship to the Core
Section titled “Relationship to the Core”The Generative AI Profile:
- Supplements the AI RMF Core.
- Does not replace GOVERN, MAP, MEASURE or MANAGE.
- Does not create NIST certification.
- Should be tailored to the selected system.
- Should be revisited as models, data, suppliers and capabilities change.
The 12 GAI risk families
Section titled “The 12 GAI risk families”Gamut highlights the risk families identified in NIST AI 600-1:
| Risk family | Assessment questions |
|---|---|
| CBRN information or capabilities | Could the system meaningfully facilitate harmful chemical, biological, radiological or nuclear knowledge or capability? |
| Confabulation | Can plausible but false output cause decisions, harm or loss of trust? |
| Dangerous, violent or hateful content | Can the system generate, amplify or enable harmful content? |
| Data privacy | Can training, prompts, retrieval, memory or outputs expose or infer personal information? |
| Environmental impacts | Are training, inference and infrastructure impacts understood and managed? |
| Harmful bias and homogenisation | Can outputs disadvantage groups, erase variation or reinforce harmful patterns? |
| Human-AI configuration | Are reliance, automation bias, anthropomorphism and human roles appropriately managed? |
| Information integrity | Can the system create or amplify misleading, manipulated or unverifiable information? |
| Information security | Can prompts, models, tools, data, outputs or integrations be attacked or misused? |
| Intellectual property | Are rights, licences, provenance and output-use risks understood? |
| Obscene, degrading or abusive content | Can the system generate or facilitate abusive or exploitative material? |
| Value chain and component integration | Are model, data, platform, tool and downstream responsibilities and dependencies controlled? |
Assessing a GAI risk family
Section titled “Assessing a GAI risk family”For each relevant family:
- Define the credible scenario.
- Identify affected people, assets and decisions.
- Identify model, data, prompt, retrieval, tool and supplier contributors.
- Review preventive and detective controls.
- Select evaluation methods.
- Define pass criteria and limitations.
- Record incidents, near misses and external evidence.
- Determine treatment and monitoring.
- Map the work back to relevant Core outcomes.
Common generative-AI evidence
Section titled “Common generative-AI evidence”- Model and system cards.
- Supplier documentation and change notices.
- Data provenance and rights records.
- Prompt and retrieval architecture.
- Red-team and misuse testing.
- Hallucination or factuality evaluation.
- Safety-filter and policy testing.
- Privacy testing.
- Bias and representation evaluation.
- Security testing.
- Human-oversight procedures.
- Content labelling and provenance mechanisms.
- Incident, complaint and takedown records.
- Monitoring by use case, user group and model version.
Important evaluation dimensions
Section titled “Important evaluation dimensions”Context
Section titled “Context”Evaluate the actual use case. The same model may have very different risk when used for creative drafting, medical support, recruitment or autonomous tool use.
Capability
Section titled “Capability”Consider what the system can do with:
- Long context.
- Retrieval.
- Tools.
- Code execution.
- Memory.
- Multimodal input.
- Fine-tuning.
- External data.
Access
Section titled “Access”Consider who can use it, which information it can reach and whether outputs can trigger action.
Consider volume, speed, user reach, automation and the ability to replicate harmful output.
Change
Section titled “Change”Model updates, system prompts, retrieval sources, safety settings and suppliers can change risk without changing the product name.
Confabulation example
Section titled “Confabulation example”For a customer-support assistant:
- MAP identifies high-impact topics, escalation rules and knowledge limits.
- MEASURE evaluates factuality using representative enquiries and current source material.
- MANAGE requires abstention, source presentation, human escalation and incident response.
- GOVERN assigns ownership and review cadence.
An acceptable average accuracy does not excuse a dangerous error class. Evaluate the severity and distribution of errors, not only the mean.
Supplier responsibility
Section titled “Supplier responsibility”Using a third-party model does not transfer all responsibility. Record:
- Supplier responsibilities.
- Application-provider responsibilities.
- Deploying-organisation responsibilities.
- Customer or user responsibilities.
- Evidence dependencies.
- Escalation and contingency arrangements.
Monitoring triggers
Section titled “Monitoring triggers”Reassess after:
- New foundation model or model version.
- Fine-tuning or prompt change.
- New retrieval source.
- New tool or action permission.
- New user population.
- New high-impact use.
- Safety-control change.
- Material incident or misuse.
- New external research on capability or risk.
Critical-infrastructure note
Section titled “Critical-infrastructure note”NIST announced a critical-infrastructure Profile concept note in April 2026. A concept note should not be described as a final Profile. Check the official AI RMF page for current status.