NIST AI 600-1 (Generative AI Profile): NIST AI 600-1 – Tutorial (about 60 minutes)

NIST AI 600-1, the Generative Artificial Intelligence Profile, is a free, voluntary companion to the NIST AI Risk Management Framework (AI RMF) that explains which risks are new or made worse by generative AI and suggests concrete actions to manage them. It is used by AI engineers, product owners, security and privacy teams, risk and compliance staff, procurement teams and executives in organisations that build, buy or deploy chatbots, copilots, image generators and other generative systems. After this tutorial you will be able to name and recognise its twelve risks, read its suggested-action tables, tailor them to your own role and use case, and explain how the profile fits next to ISO/IEC 42001, the EU AI Act and other AI guidance.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current and only edition is NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, published by the US National Institute of Standards and Technology (NIST) on 26 July 2024 after an initial public draft in April 2024. It was written under US Executive Order 14110 of October 2023; that order was revoked in January 2025, but the profile was not withdrawn and NIST still lists it as a published AI RMF resource. NIST has announced that the parent framework, AI RMF 1.0, is being revised following the White House AI Action Plan of July 2025, which asked NIST to remove references to misinformation, diversity, equity and inclusion, and climate change. NIST's publication page still lists the July 2024 profile as published, with no revision, withdrawal or replacement, and no revised Generative AI Profile has been released, so this course teaches the July 2024 text and flags where a future revision could change names or emphasis. Verified 2026-10-29.

Who this is for: engineers and architects who integrate large language models or other generative models into products; product managers deciding whether a generative feature is ready to ship; security, privacy and data-protection professionals asked to "assess the AI"; risk, audit and compliance staff who need a recognised reference for generative AI controls; and procurement or vendor-management teams buying AI services.

Prerequisites: none. You do not need to know how neural networks are trained. A general idea of risk management (likelihood, impact, controls) helps. If you have already studied the AI RMF you will recognise its four functions; if not, Lesson 1 and Lesson 2 give you the minimum you need.

By the end of this tutorial:

You will be able to explain why NIST produced a separate profile for generative AI and how it relates to the AI RMF.
You will be able to define the key vocabulary, including confabulation, human-AI configuration, content provenance, red-teaming and prompt injection.
You will be able to name the twelve generative AI risks and give a realistic example of each.
You will be able to read a suggested-action entry, decode its Action ID and tell which risks and AI actors it concerns.
You will be able to plan how an organisation applies the profile across the AI lifecycle, from governance to post-deployment monitoring and incident disclosure.
You will be able to explain how use of the profile is evidenced and why no certification against it exists.
You will be able to position the profile next to the AI RMF, ISO/IEC 42001, ISO/IEC 23894, the EU AI Act and the OWASP Top 10 for LLM Applications.

Lesson 1 – Origins, purpose and scope

Why generative AI needed its own guidance

Most of the AI that organisations used before 2022 was predictive or discriminative: a model looked at an input and produced a label, a score or a forecast. A fraud model said "suspicious" or "fine"; a demand model produced a number. These systems can be biased or wrong, but their outputs are narrow and their uses are usually decided in advance.

Generative AI changed three things at once. First, the output is open-ended: a model can write an email, a contract clause, computer code, a medical summary, a photograph or a voice recording, and nobody can list every output in advance. Second, the same underlying model is reused for thousands of different purposes by different organisations, so one model's weakness spreads widely. Third, the barrier to use collapsed: anyone with a browser can produce persuasive text or realistic images in seconds, including people with harmful intentions. Existing risk methods were not wrong, but they did not tell a team where to look first when the system under review is a chatbot built on a third-party foundation model.

How the profile came about

NIST released the AI Risk Management Framework (AI RMF 1.0, published as NIST AI 100-1) in January 2023. It is a voluntary, technology-neutral framework built around four functions: Govern, Map, Measure and Manage. Because it is deliberately general, the AI RMF expects organisations to create profiles that show how its functions apply to a particular setting.

In 2023 NIST set up the Generative AI Public Working Group (GAI PWG), an open online group where volunteers from industry, academia and civil society discussed how to manage generative AI risks. Later that year Executive Order 14110 directed NIST to produce a companion resource to the AI RMF for generative AI. NIST published a draft in April 2024, gathered public comments and released the final profile, NIST AI 600-1, in July 2024. The same week NIST also finalised a related secure-development profile for generative AI (SP 800-218A), described in Lesson 7.

The working group chose to focus on four topics it called primary considerations: governance, content provenance, pre-deployment testing and incident disclosure. Those four themes run through the whole document and are described in its Appendix A.

What the profile is for

The profile has two jobs. It first gives organisations a shared list of risks that are either unique to generative AI or exacerbated by it, meaning the risk existed before but generative AI makes it larger, cheaper or faster. Then it offers more than 200 suggested actions, each attached to a part of the AI RMF, so that a team can move from "we are worried about X" to "here are practical steps others have found useful".

Scope and limits

Technology scope. The profile adopts the executive order's description of generative AI: models that learn the patterns of their input data and produce new, synthetic content such as text, images, audio, video or code. In practice it concentrates on large generative foundation models and the applications built on them.
Who it addresses. Any organisation that designs, develops, deploys, operates, buys or evaluates generative AI, in any sector and any country. Because generative models are used across industries, NIST classes it as a cross-sectoral profile.
Evidence threshold. It covers risks for which there was real-world evidence when it was written. Speculative risks that might arise only from much more advanced future systems are left out on purpose.
Voluntary and not exhaustive. Nothing in it is mandatory, it does not include every AI RMF subcategory, and NIST says future revisions may add risks and actions as evidence grows.
Not a replacement. The profile adds to the AI RMF and its Playbook; it does not replace them. Everything the AI RMF recommends for AI in general still applies to generative systems.

Figure 1 – The Generative AI Profile is a cross-sectoral profile of the AI RMF, and its suggested actions are filed under the RMF Core.

Lesson 2 – Key concepts and vocabulary

The profile reuses AI RMF vocabulary and adds terms specific to generative systems. The definitions below are paraphrased in plain English.

Generative AI (GAI) – AI models that produce new content (text, images, audio, video, code) resembling the data they were trained on, rather than only classifying or scoring inputs.
Foundation model – a large model trained on broad data, usually with self-supervision, that can be adapted to many tasks. A dual-use foundation model is one whose capabilities could serve both beneficial and seriously harmful purposes; the executive order defined it with a size and breadth threshold.
Profile – an implementation of the AI RMF's functions, categories and subcategories for a specific setting, application or technology, shaped by the user's requirements, risk tolerance and resources. The AI RMF describes use-case profiles, temporal profiles (a current and a target state) and cross-sectoral profiles.
Risk – in AI RMF terms, a combined measure of how likely an event is and how severe its consequences would be. Risks can be positive or negative, but the profile concentrates on negative impacts.
AI actor – any organisation or person that plays an active role in an AI system's lifecycle, such as developers, deployers, operators, testers, end users and affected communities. AI Actor Tasks are the AI RMF's named groups of activities (for example AI Development, AI Deployment, TEVV, Governance and Oversight, Operation and Monitoring) that the profile attaches to each set of actions.
Trustworthy AI characteristics – the seven qualities the AI RMF aims for: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed. Each GAI risk in the profile is linked to the characteristics it threatens.
Confabulation – the generation of content that is false or unsupported but presented with confidence, including invented citations or reasoning. It is often called "hallucination"; NIST prefers confabulation partly because "hallucination" makes the system sound human.
Human-AI configuration – how people and an AI system are arranged to work together, and the risks that arise from that arrangement, such as over-reliance, treating the system as if it were a person, or rejecting useful output out of distrust.
Automation bias – the tendency of people to defer too much to automated output and to check it less carefully than human work.
Content provenance – information about where a piece of content or data came from and how it changed over time. Digital content transparency covers the techniques that record or reveal provenance, such as metadata, watermarks and fingerprints, and that help detect synthetic content.
Synthetic content – text, images, audio or video created or substantially altered by AI. Highly realistic synthetic media of real people are commonly called deepfakes.
TEVV – test, evaluation, verification and validation: the activities that show whether a system works as intended and within acceptable risk.
AI red-teaming – structured attempts to make an AI system misbehave, in order to find flaws such as harmful, inaccurate or discriminatory output before attackers or users do.
Jailbreaking – crafting prompts that get around a model's output restrictions.
Prompt injection – manipulating the input a generative system receives so that it behaves in unintended ways. In a direct injection the attacker types the malicious instruction; in an indirect injection the instruction is hidden in data the system later retrieves, such as a web page, email or document.
Data poisoning – tampering with training or fine-tuning data so that the resulting model behaves the way an attacker wants.
Model collapse – loss of diversity and accuracy when models are trained too heavily on content produced by other models.
Algorithmic monoculture – many organisations relying on the same model, so that one flaw produces correlated failures across a whole sector.
AI incident – an event in which the development, use or malfunction of an AI system directly or indirectly contributes to harm, for example to people's health, critical infrastructure, rights, property or the environment.

Four dimensions for thinking about GAI risk

Before listing specific risks, the profile explains that generative AI risks vary along four dimensions. Using them helps a team avoid looking only at the model in the lab.

Stage of the lifecycle. A risk can appear during design, development, deployment, operation or decommissioning. Training-data problems start early; misuse by end users appears in operation.
Scope. A risk can sit at the level of a single model or system, at the level of a specific application or use case, or at the level of the wider ecosystem, beyond any one organisation. Algorithmic monoculture and effects on labour markets are ecosystem-level examples.
Source. A risk can come from the model's design, training or operation; from its inputs or its outputs; or from human behaviour, whether malicious misuse, careless repurposing or the way a person and the system interact.
Time scale. Some harms are immediate, such as a deepfake that causes distress the day it spreads; others build up slowly, such as gradual loss of public trust in online information.

The profile adds that where a risk falls on these dimensions depends on the system's characteristics: its architecture, training data, how widely its weights are available, and the context in which it is used. Mitigations that work at the model level (for example, safety fine-tuning) may be different from those needed at the use-case level (for example, human review of outputs) or the ecosystem level (for example, industry information sharing).

Figure 2 – The four dimensions along which the profile says generative AI risks vary.

Lesson 3 – Structure of the profile

NIST AI 600-1 is a relatively short document (about sixty pages, a large share of them tables). Its parts are:

Section 1 – Introduction. Purpose, the cross-sectoral nature of the profile, the working group and its four primary considerations.
Section 2 – Overview of risks unique to or exacerbated by GAI. The four risk dimensions and the twelve named risks, each with a short explanation and the trustworthy AI characteristics it affects.
Section 3 – Suggested actions to manage GAI risks. Tables of actions organised by AI RMF function and subcategory.
Appendix A – Primary GAI considerations. Longer discussion of governance (including third-party considerations), pre-deployment testing (including structured public feedback and red-teaming), content provenance and incident disclosure.
Appendix B – References. The research and reports behind the risk descriptions.

The twelve GAI risks

Each risk is named after its source, object or outcome. Some describe a risk to something (such as privacy), others a risk of or from something (such as confabulation). The table paraphrases each one.

Risk	What it means (paraphrased)	Typical example
CBRN Information or Capabilities	Easier access to, or synthesis of, information that could help someone create chemical, biological, radiological or nuclear weapons.	A model that walks a non-expert through steps that were previously hard to piece together.
Confabulation	Confidently stated false or unsupported content that may mislead users.	A legal research assistant citing court cases that do not exist.
Dangerous, Violent, or Hateful Content	Easier production of inciting, threatening or radicalising material, encouragement of self-harm or crime, and stereotyping content.	A jailbroken chatbot giving instructions for violence.
Data Privacy	Leakage, unauthorised use or inference of personal and sensitive information, including through memorised training data.	A model repeating a real person's phone number seen during training.
Environmental Impacts	The energy, carbon and resource footprint of training and running large models.	Choosing a far larger model than a task needs, multiplying inference energy.
Harmful Bias and Homogenization	Amplified societal bias, weaker performance for some groups or languages, and overly uniform outputs that skew decisions.	An image generator that almost never depicts women as engineers.
Human-AI Configuration	Problems from how people interact with the system: over-reliance, automation bias, anthropomorphism, emotional entanglement or unjustified aversion.	Staff approving AI-drafted letters without reading them.
Information Integrity	Lower cost of producing content that blurs fact and fiction, and of running large mis- and disinformation campaigns.	A realistic fake image of an explosion briefly moving financial markets.
Information Security	Lower barriers to offensive cyber activity, plus new attack surface on the GAI system itself.	Indirect prompt injection through a document the assistant is asked to summarise.
Intellectual Property	Easier unauthorised reproduction of copyrighted or trademarked material, exposure of trade secrets, or use of someone's likeness or voice.	Generated text reproducing long passages of a copyrighted book.
Obscene, Degrading, and/or Abusive Content	Easier creation of abusive imagery, including synthetic child sexual abuse material and non-consensual intimate images.	"Nudify" apps producing fake intimate images of real people.
Value Chain and Component Integration	Poorly traceable third-party data, models and components, weak supplier vetting and reduced accountability downstream.	Fine-tuning on a purchased dataset of unknown origin.

A footnote in the profile offers an optional grouping, partly borrowed from the UK-led international scientific report on advanced AI safety: technical or model risks (malfunctions such as confabulation), misuse by humans (such as CBRN or abusive content) and ecosystem or societal risks (such as environmental impact and intellectual property). Some risks, notably data privacy, appear in more than one group. You may group the risks however suits your organisation; the twelve names are a lens, not a mandatory taxonomy.

How a suggested-action entry is built

Section 3 is a long sequence of tables. Each table starts with one AI RMF subcategory (the outcome statement from the AI RMF Core, for example "GOVERN 1.6", which concerns keeping an inventory of AI systems). Under it come the suggested actions, each with three columns:

Action ID – a code in the pattern XX-n.n-nnn. The two letters give the function (GV Govern, MP Map, MS Measure, MG Manage), the middle number is the subcategory, and the last three digits number the action within that subcategory. GV-1.6-001 is therefore the first suggested action under Govern 1.6.
Suggested Action – what an organisation or AI actor could do, written as a short instruction.
GAI Risks – tags naming which of the twelve risks the action helps with.

A line of AI Actor Tasks at the end of each table says which groups of actors the actions are most relevant to. Not every task applies to every action: some actions suit model developers, others suit deployers or operators.

Three structural facts matter in practice. First, only a subset of the AI RMF's 72 subcategories is covered: actions appear under roughly two thirds of them, because the working group concentrated on its four primary considerations. Second, the Measure function carries the largest number of actions, reflecting how much of generative AI risk work is testing and evaluation. Third, the actions are suggestions, not requirements; NIST says applicability depends on the organisation, the actor and the use.

Figure 3 – Anatomy of a suggested-action entry: each Action ID points to one AI RMF function and subcategory and carries risk tags.

The four primary considerations (Appendix A)

Governance. Adapting existing governance to generative AI: acceptable use policies, risk tiers, oversight levels, documentation, training, and third-party considerations such as procurement due diligence, software bills of materials (SBOMs), service level agreements (SLAs) and independent attestation reports.
Pre-deployment testing. Why current tests are often not enough (benchmarks and human exams do not prove real-world validity) and how structured public feedback helps: participatory engagement, field testing and AI red-teaming.
Content provenance. Recording the origin and history of training data and generated content, using watermarks, metadata, fingerprints and similar techniques, and understanding their trade-offs.
Incident disclosure. Defining AI incidents, noting that formal reporting channels did not yet exist, and encouraging logging, documentation and information sharing so that harms can be traced and prevented.

Lesson 4 – How it works in practice

NIST does not prescribe a fixed procedure, but the profile follows the AI RMF's logic: Govern is a cross-cutting foundation, and Map, Measure and Manage repeat throughout the lifecycle. The steps below show a practical way to put it to work.

Step 1 – Set up governance and know what you have

Start with the Govern function. Typical suggested actions include aligning generative AI use with applicable laws on privacy and intellectual property, writing an acceptable use policy, deciding how risk tiers apply to generative systems, and setting minimum performance and assurance thresholds that a system must meet before a go/no-go decision. The profile also suggests having a plan to halt development or deployment if a system turns out to pose unacceptable risk.

A crucial early task is the inventory. Many organisations do not know where generative AI is already used, because it arrives inside office suites, customer-service platforms and developer tools. The profile suggests adding generative systems to the AI inventory and recording useful details such as data provenance, known issues from incident databases and the human oversight roles involved. Any decision to exempt embedded generative features from the inventory should be written into policy rather than assumed.

Step 2 – Map the context

The Map function asks what the system is for, who will use it, who could be affected, what it must not do and which third-party components it depends on. For generative AI this includes documenting the system's knowledge limits, how outputs will be checked by people, which foundation model and datasets are used, and the legal risks of those components. It also includes estimating the likelihood and magnitude of each identified impact, both harmful and beneficial.

Step 3 – Choose the relevant risks and actions

Not all twelve risks matter equally to every system. An internal code assistant has little CBRN exposure but real information security and intellectual property exposure; a public image generator has heavy abusive-content and information-integrity exposure. Use the Map results to rank the risks, then pick the suggested actions whose tags and actor tasks match your role. A company that only deploys a vendor's model will skip actions aimed at pre-training and focus on procurement, configuration, testing in context, monitoring and incident handling. Recording the selected outcomes as a target profile, and today's position as a current profile, turns the gap into a work plan.

Step 4 – Measure before deployment

Measure is where the profile is most detailed. Suggested actions cover choosing metrics for the risks identified in Map, involving reviewers who did not build the system, evaluating validity and reliability, safety, security, privacy, fairness, environmental impact and transparency, and checking that the evaluation methods themselves work. Two warnings recur:

Do not generalise from narrow or anecdotal tests. A model that passes a professional licensing exam or survives a handful of jailbreak attempts has not been shown to be reliable in your setting.
Test under conditions close to real use. Laboratory benchmarks often miss prompt sensitivity, real user behaviour and the variety of contexts in which a system will operate.

The profile describes three kinds of structured public feedback. Participatory engagement (focus groups, small user studies, surveys) is informal and suits early design. Field testing runs structured experiments that simulate deployment, which can estimate how often harms occur. AI red-teaming deliberately probes for failures. Red teams can be drawn from the general public, from domain experts, from a combination of both, or can mix humans with generative AI tools that generate attack prompts at scale. The profile stresses that a red team's quality depends on its expertise and diversity, that results need analysis before they drive decisions, and that human-subject protections such as informed consent apply when real people take part.

Step 5 – Manage in operation

The Manage function covers deciding how to treat each risk, deploying with controls, monitoring third-party resources, and continual improvement. Suggested actions include post-deployment monitoring focused on confabulation, security and other priority risks; collecting user feedback; tracking changes to datasets for provenance; reviewing pre-trained models as part of regular monitoring; and setting clear criteria and responsibilities for disengaging or deactivating a system whose outcomes stray from its intended use.

Step 6 – Handle incidents and feed back

Incidents are inevitable. The profile encourages organisations to define what counts as a generative AI incident, to log and document incidents, to run after-action reviews, to communicate incidents to relevant AI actors (including affected communities where appropriate) and to learn from public incident collections. Lessons then flow back into governance, risk tiers and tests.

Figure 4 – A practical lifecycle for applying the profile, with a go/no-go gate and a feedback loop from incidents back to governance.

Roles across the value chain

Generative AI usually involves several organisations: a model developer, perhaps a fine-tuner or platform provider, a deployer that builds the application, and end users. The profile repeatedly reminds readers that suggested actions relevant to developers may not apply to deployers and vice versa. A deployer cannot inspect a vendor's training data, but it can ask for documentation, write provenance and security expectations into contracts and SLAs, assess vendors against incident and vulnerability databases, include vendors in incident response plans, and keep fallbacks in case a third-party model fails or changes.

Content provenance in practice

Provenance techniques include visible disclosures ("this image was AI-generated"), metadata attached to files, invisible watermarks embedded in content, and fingerprints that let content be matched later. Each has trade-offs: the profile notes, for example, that choosing a watermarking method for robustness (how well the mark survives editing) also changes the computing resources it needs, and metadata can simply be stripped. The profile therefore suggests documenting provenance limitations, testing how well detection works, and studying how people react to disclosures. NIST's separate report NIST AI 100-4 covers these techniques in depth.

Lesson 5 – Assessment, certification and compliance

No certification exists

There is no certification, accreditation scheme or conformity mark for NIST AI 600-1. NIST does not audit organisations against it, does not keep a register of "compliant" companies and does not authorise anyone to issue certificates for it. Like the AI RMF itself, the profile is voluntary guidance with suggested actions, not "shall" requirements. A claim such as "NIST AI 600-1 certified" should therefore be treated with suspicion.

How use of the profile is shown

Organisations show they use the profile through evidence, not badges. Useful evidence includes:

An AI inventory that includes generative systems and records owners, models, data sources and known issues.
A risk register or profile that shows which of the twelve risks apply to each system, why, and which suggested actions were selected or deliberately not selected.
Policies: acceptable use, risk tiering, go/no-go thresholds, deactivation criteria and incident response.
Test plans and results, red-team reports and records of how findings were fixed.
Vendor due-diligence files, contracts and SLAs with security, provenance and incident clauses.
Monitoring dashboards, incident logs and after-action reviews showing that the cycle runs continuously.

Who assesses

Assessment is usually done by internal audit or second-line risk functions, by independent reviewers inside the organisation who did not build the system (an idea the profile itself supports), or by external consultancies and auditors engaged for an assurance review. Customers may ask suppliers to describe their alignment in security questionnaires. Where an organisation needs a certificate, it typically pursues ISO/IEC 42001 certification for its AI management system and uses the GAI Profile as a source of generative-specific controls and tests within that system.

Legal and regulatory relevance

The profile is not law. However, laws and policies can refer to it. For example, the Texas Responsible Artificial Intelligence Governance Act (HB 149), in force since 1 January 2026, says a defendant may not be found liable for a violation it discovers through an internal review process if it substantially complies with the most recent version of the NIST Generative AI Profile or another nationally or internationally recognised AI risk management framework. Other jurisdictions and contracts may refer to the AI RMF more generally. US federal policy on AI has shifted since 2025, so organisations should check current requirements rather than assume that the profile is mandated for any particular purpose. Outside the United States, the profile is often used as practical input for meeting obligations that come from other sources, such as the EU AI Act.

No maturity levels

Unlike the NIST Cybersecurity Framework and Privacy Framework, the AI RMF and this profile define no implementation tiers or maturity levels. If you want to show progress, compare a current profile with a target profile, track how many priority risks have tested controls, and measure monitoring and incident-response performance over time.

Lesson 6 – Worked example

Scenario. Harbourline Insurance (a fictional mid-sized insurer) wants to launch "Ask Harbour", a customer-facing assistant on its website that answers questions about policies and claims. The assistant uses a commercial foundation model through a vendor's API and retrieval-augmented generation (RAG): it searches Harbourline's policy documents and knowledge base and passes the relevant passages to the model. Customers may upload claim photos and documents. Harbourline does not train its own models. The chief risk officer asks the AI governance lead to use NIST AI 600-1 to decide whether, and how, to launch.

Step 1 – Govern

The governance lead first updates the AI inventory. Besides Ask Harbour, the inventory exercise discovers a generative writing feature already switched on in the company's office software and an AI code assistant used by developers; both are added, following the profile's suggestion to enumerate generative systems (GV-1.6-001) and to record provenance and known issues for each entry (GV-1.6-003). The board's AI committee confirms that customer-facing generative systems belong in the highest internal risk tier, approves an acceptable use policy, and asks for written go/no-go thresholds (GV-1.3-002) and a documented plan to halt the service if it causes unacceptable harm (GV-1.3-007).

Step 2 – Map

A cross-functional team (product, claims experts, legal, privacy, security, customer service and accessibility) maps the context. Intended use: general policy questions and claim status. Out of scope: coverage decisions, which stay with human claims handlers. Affected people: customers, including vulnerable customers and those writing in other languages. Third parties: the model vendor, the cloud host and the vector database. The team documents the model's knowledge limits and decides that the assistant must cite the policy passage it relies on.

Step 3 – Prioritise the twelve risks

The team scores each risk for likelihood and impact in this specific use. They record a short reason for every risk, including those judged low, so that reviewers can see the analysis was done.

Figure 5 – How the insurer ranked selected GAI risks by likelihood and impact to decide where to act first.

Risk	Why it matters here	Selected actions and controls	Evidence kept
Confabulation	A wrong answer about coverage could cause financial harm and complaints.	Answers grounded in retrieved passages with citations; sources and citations verified in testing and monitoring (`MS-2.5-003`); no generalising from demo results (`MS-2.5-001`).	Test set of 600 real questions with expected answers; accuracy and citation-validity results.
Data Privacy	Customers share personal and health details in chats and uploads.	Vendor contract forbids training on Harbourline data; masking of identifiers in logs; retention limits.	Data-flow map, contract clauses, privacy impact assessment.
Information Security	Uploaded documents could carry hidden instructions (indirect prompt injection).	Uploaded content treated as untrusted data; assistant cannot call tools that change records; security red-team exercise.	Red-team report and fix log.
Human-AI Configuration	Customers and agents may trust fluent answers too much.	Clear disclosure that the assistant is AI; easy hand-off to a human; guidance for staff reviewing escalations.	Usability study results; escalation rates.
Harmful Bias and Homogenization	Quality may drop for non-native speakers.	Evaluation broken down by language and reading level.	Disaggregated test results.
Value Chain and Component Integration	The vendor can update the model without notice.	Contract and SLA clauses on quality standards, security and provenance (`GV-6.1-004`), plus change notice and incident sharing; regression tests on each model version.	Vendor assessment file; regression results.
Environmental Impacts	Moderate: inference volume will be high.	Smallest model that meets the accuracy threshold; usage reporting.	Model-selection record.
CBRN, Abusive, Dangerous Content, IP, Information Integrity	Low for a narrow insurance assistant, but not zero.	Vendor content filters kept on; topic restrictions; monitoring of refused and flagged prompts.	Filter configuration; monitoring report.

Step 4 – Measure

Testing is done by a group that did not build the assistant. It combines claims experts, who know when an answer is subtly wrong, with a group of ordinary customers recruited with informed consent, and a small security team that tries injection and jailbreak techniques. Early results show 9 % of answers citing the wrong policy section and two successful injections through uploaded PDFs. The go/no-go thresholds set in Step 1 (for example, at most 2 % materially incorrect answers on the test set and no known unmitigated injection paths) are not met, so the decision is "no-go".

The team improves retrieval, adds a rule that the assistant must decline when no supporting passage is found, and isolates uploaded content so that it can never be read as instructions. A second round meets the thresholds. The committee approves a limited launch to 10 % of website visitors with monitoring.

Step 5 – Manage

Post-deployment monitoring focuses on confabulation and security (MG-4.1-002): a sample of conversations is reviewed weekly by claims experts, customers can flag answers, and unusual prompt patterns raise alerts. The team writes down the criteria that would trigger switching the assistant off, and who has authority to do it (MG-2.4-004).

Step 6 – An incident

Two months after launch, the vendor releases a new model version. Within a day, monitoring shows a jump in answers that quote outdated policy wording. Because the deactivation criteria were agreed in advance, the operations manager rolls back to the previous model version within an hour. An after-action review (GV-1.5-002) finds that the regression suite did not include questions about recently changed policies. The suite is extended, the vendor contract is updated to require advance notice of model changes, and the incident is recorded in the inventory entry. The governance lead updates Harbourline's current profile and sets the next target: extending the assistant to claims status updates only after new tests on privacy and identity verification.

What the example shows

The profile did not tell Harbourline what to do; it gave a structured list of risks and suggested actions from which the team selected those that fit a deployer's role.
Governance decisions made early (thresholds, halt plan, deactivation criteria) made later decisions fast and defensible.
Testing in realistic conditions with mixed red teams found problems a demo never would have.
Evidence was produced as a normal by-product of the work, which is what an auditor or customer would later ask to see.

Lesson 7 – Relationship to other standards and frameworks

NIST AI 600-1 sits in a crowded landscape. It is most useful when combined with documents that do different jobs: a management system for structure, a law for obligations, and security catalogues for technical detail.

Document	What it is	Nature	Relationship to NIST AI 600-1
NIST AI RMF 1.0 (NIST AI 100-1) and Playbook	General AI risk management framework with Govern, Map, Measure, Manage	Voluntary; revision announced	The parent. The profile's actions are filed under the RMF subcategories and add to, not replace, the Playbook.
ISO/IEC 42001:2023	Requirements for an AI management system	Certifiable international standard	Provides the management-system shell (policy, roles, audits, improvement); the profile can feed its risk assessment and controls for generative systems.
ISO/IEC 23894:2023	Guidance on AI risk management based on ISO 31000	Guidance, not certifiable	Similar purpose to the AI RMF at a general level; the profile adds generative-specific risks and actions.
EU AI Act (Regulation (EU) 2024/1689)	EU law on AI, including obligations for general-purpose AI model providers	Binding law in the EU	Sets legal duties; the profile offers practical techniques (testing, provenance, incident handling) that can help meet some of them, but alignment with the profile does not equal legal compliance.
OWASP Top 10 for LLM Applications	Community list of the most critical security weaknesses in LLM apps	Voluntary, security-focused	Deeper on technical attacks such as prompt injection; maps mainly to the profile's Information Security and Value Chain risks.
NIST SP 800-218A	Secure software development practices for generative AI and dual-use foundation models	Voluntary community profile of the SSDF	Covers how models and systems are built securely; complements the profile's risk-level view.
NIST AI 100-4	Overview of technical approaches to digital content transparency	Voluntary technical report	Expands the profile's content provenance consideration (watermarking, metadata, detection).

Two more neighbours are worth knowing. MITRE ATLAS catalogues real adversary tactics against AI systems and is useful for planning red-team exercises. NIST has also published a preliminary draft Cybersecurity Framework profile for AI (the "Cyber AI Profile", NIST IR 8596), which looks at AI through the lens of the Cybersecurity Framework rather than the AI RMF. Teams already using the CSF can use it for security outcomes and the GAI Profile for broader generative AI risks.

A practical combination for many organisations is: ISO/IEC 42001 (or an internal equivalent) as the management system, NIST AI RMF as the risk method, the GAI Profile for generative-specific risks and actions, OWASP and MITRE ATLAS for technical security testing, and the relevant laws as the list of non-negotiable obligations.

Common pitfalls and best practices

Pitfalls

Treating the action list as a checklist. Trying to implement all suggested actions wastes effort on actions meant for other roles; ticking them without evidence creates false comfort.
Marking risks "not applicable" without analysis. A one-word dismissal of CBRN or abusive content gives reviewers no basis to trust the assessment; record a short reason.
Missing embedded generative AI. Features switched on inside software-as-a-service products escape the inventory unless someone looks for them.
Over-trusting benchmarks and demos. Good scores on public benchmarks or human exams do not show that a system is reliable for your users, language or domain.
Assuming the vendor has handled it. A foundation model provider's safety testing does not cover your prompts, data, integrations or users.
Claiming certification. Advertising "NIST AI 600-1 certification" misrepresents a voluntary guidance document and damages credibility.
Testing once. Model updates, new data and new user behaviour change risk; a one-off pre-launch test soon becomes outdated.

Best practices

Tailor by role and use case. Filter actions by AI Actor Tasks and risk tags, and record why actions were chosen or set aside.
Set gates early. Agree measurable go/no-go thresholds, deactivation criteria and a halt plan before testing starts, so results lead to decisions instead of debates.
Test in context with diverse testers. Combine domain experts, ordinary users and security specialists; use field tests where possible; follow human-subject protections.
Manage the value chain contractually. Put security, provenance, change-notice and incident-sharing expectations into contracts and SLAs, and keep fallbacks.
Monitor continuously. Sample outputs, collect user feedback, run regression tests on every model or data change, and track incidents.
Make provenance and disclosure deliberate. Decide where AI-generated content must be labelled or traceable, and test whether those techniques work.
Integrate, don't duplicate. Run the profile inside your existing risk, security, privacy and management-system processes rather than as a separate programme.

Summary and key takeaways

NIST AI 600-1 is a voluntary, cross-sectoral profile of the AI RMF for generative AI, published in July 2024; it remains the current edition while NIST revises the parent framework.
It describes risks that are unique to or exacerbated by generative AI, along four dimensions: lifecycle stage, scope, source and time scale.
Its twelve named risks range from confabulation and data privacy to value chain integration and environmental impacts.
More than 200 suggested actions are filed under AI RMF subcategories, with IDs such as GV-1.6-001, risk tags and AI Actor Tasks; only a subset of subcategories is covered.
Four primary considerations shape the document: governance, pre-deployment testing, content provenance and incident disclosure.
Organisations must tailor the actions to their role (developer, deployer, operator) and use case; it is not a checklist.
There is no certification; use is demonstrated through inventories, risk decisions, test results, contracts, monitoring and incident records, often inside an ISO/IEC 42001 management system.
The profile complements, rather than replaces, laws such as the EU AI Act and technical references such as the OWASP Top 10 for LLM Applications.

Reflection questions

List the generative AI features already used in your organisation, including those embedded in purchased software. Which of them are missing from any inventory today?
Choose one generative system you know. Which three of the twelve risks are most important for it, and where does each fall on the four risk dimensions?
If your organisation only deploys a vendor's model, which suggested-action areas would you prioritise, and which would you set aside? How would you record that decision?
Draft two measurable go/no-go thresholds and one deactivation criterion for a generative feature you are familiar with. Who should have authority to apply them?
A customer asks how you "comply with NIST AI 600-1". What evidence would you show, and how would you explain the absence of a certificate?