NIST AI RMF generative AI profile cost and readiness

What the NIST AI RMF generative AI profile asks of your organization

A customer questionnaire or contract clause that names NIST AI 600-1 usually asks whether you have addressed generative AI risks. The short answer is that the Generative AI Profile is voluntary and no certificate exists for it. NIST published AI 600-1 on July 26, 2024 as a cross-sectoral profile of AI RMF 1.0. It defines 12 generative AI risks and lists suggested actions tied to 49 of the framework's 72 subcategories, so no single action list covers the whole framework. Before you answer, confirm which of your AI systems are generative, since the profile is written for generative AI and its actions do not all apply to every AI actor.

Your organization owns its AI governance, risk decisions and controls. An implementation partner can prepare systems, documentation and evidence, such as an AI system inventory, risk registers, test records and incident procedures, and can map that evidence to the profile's suggested action IDs. Only an independent assessor or auditor issues any report or opinion on it, and a self-assessment is not a certification. Ask any firm offering a "NIST AI 600-1 certification" to show which body issued it and on what basis, because NIST does not validate or endorse individual organizations.

Cost and timeline depend on scope: how many generative AI systems you run or buy, how many of the 49 addressed subcategories apply to each, how much testing evidence already exists, and whether you need an independent review. Costs usually split into one-time work (scoping, gap assessment, documentation, testing and remediation) and recurring work (monitoring, re-testing after model or vendor changes, and periodic review). Do not assume figures from third parties. When you request a written quote, ask for the scope of systems and suggested actions, the deliverables, the evidence each deliverable produces, the assumptions behind the effort estimate, and which items are excluded, and confirm the independent assessor's fees separately.

Who is paid for what when you use the profile

This table separates the cost components of applying NIST AI 600-1 to a generative AI system: internal staff, an implementation partner, tooling and an independent assessor. Read each row for who is paid, whether the cost is one-time or recurring, and what moves it up or down. No fee or duration is stated because none is supplied for this profile, so use the quote checklist to compare offers.

Cost component	Who is paid	One-time or recurring	What drives it
Internal staff time	Your own employees, such as risk, legal, security, data science and product owners	Both: initial mapping of suggested actions is one-time, while evidence upkeep recurs	Number of generative AI systems in scope, how many of the 49 covered subcategories already have owners, and how often models or prompts change
Implementation partner	An outside firm such as DeployOpen, if you engage one, for systems, documentation and evidence preparation	Mostly one-time for the initial build, with optional recurring retainers for upkeep	Systems in scope, number of suggested actions covered, depth of logging and testing evidence required, and whether the partner builds or only reviews
Tooling and infrastructure	Software vendors, cloud or data center providers and open-source platforms you run in your own environment	Recurring for licenses, hosting and monitoring, with one-time setup for integration	Whether you reuse existing logging, ticketing and model registry tools, and how much pre-deployment test tooling you need
Pre-deployment and ongoing testing	Internal red team staff or an outside security testing provider	Recurring, because testing should repeat after material model or use changes	Number of risk categories tested, such as information security and confabulation, and release frequency
Independent assessor or auditor	A third-party assessor you choose, if you want external review of your evidence	One-time per engagement, repeated if you reassess on a schedule	Scope of the review, the evidence the assessor must sample, and whether the work is a readiness review or a formal attestation
Legal and policy review	Internal counsel or outside counsel	One-time for policy drafting, recurring for review of new laws and contracts	Jurisdictions where the system is used, such as Texas where a liability defense is tied to the profile, and contract terms with customers
Training and awareness	Internal training staff or an outside provider	Recurring, usually tied to onboarding and role changes	Headcount of AI builders and deployers, and the number of suggested actions assigned to each role

What makes using the generative AI profile cost more or less

The effort of applying NIST AI 600-1 depends less on the profile itself than on how much generative AI an organization runs, how it sources models, and what evidence it already has. Each driver below can be controlled, and each one is worth raising in a scope discussion before any quote is agreed.

Number of generative AI systems in scope

Every generative AI system you run or buy is a separate set of risks to map, test and document against the profile's suggested actions. A single internal assistant with one model and one use case is far smaller than a portfolio of customer-facing chatbots, code tools and content generators. Ask for an inventory of generative AI systems first, then group them by shared model, shared data and shared users so that common evidence can be reused. Confirm the grouping rules with your implementation partner before work starts.

Build, fine-tune or buy the model

A team that trains or fine-tunes a model takes on data curation, training documentation, pre-deployment testing and model-level evaluation, which the profile's suggested actions cover in depth. A team that buys access to a hosted model inherits much of that work from the provider but still owns its prompts, data flows and deployment controls. Decide the model sourcing strategy per system, because the same organization may build one tool and buy another. Ask any partner to price each path separately.

Developer or deployer role

AI 600-1 notes that not every action applies to every AI actor, and that actions written for developers may not apply to deployers. An organization that both builds and deploys carries the full set of applicable actions, while a deployer may focus on use context, human oversight and monitoring. Record your role for each system in the AI inventory, since that record determines which actions are in scope. Confirm the role split in writing so that the scope is not inflated by default.

Relevant subcategories among the 49

The suggested actions cover 49 of the AI RMF's 72 subcategories, and not all of those will apply to every system. Map each system to the subcategories that match its risks, its users and its impact on people, then exclude the rest with a documented reason. A narrow internal tool may need a small subset, while a system that influences decisions about people may need most of the set. Ask for the subcategory list as a deliverable so that the scope is visible and auditable.

Maturity of existing evidence

Work is much smaller when testing records, incident logs, acceptable use policies and model cards already exist and are current. Gaps usually appear in pre-deployment testing records, content provenance practices and incident disclosure processes, which are the four primary considerations the Generative AI Public Working Group focused on. Review existing artifacts against the suggested actions before estimating effort, and treat any missing evidence as new work. Ask the partner to show which artifacts they will reuse and which they will create.

Reliance on third-party model providers

When a provider controls the model, you depend on its documentation, testing results, change notices and data handling terms to evidence several actions. Contracts that give you access to that evidence, and a process for reviewing provider updates, reduce the work of verifying claims yourself. Where a provider cannot supply the information you need, the gap becomes your problem to test or disclose around. Confirm what each provider commits to share, how often it changes its model, and how you will be notified before you scope the work.

How to work through the profile from scope to evidence

The sequence turns the generative AI suggested actions in NIST AI 600-1 into a scoped inventory, an applicability decision, a gap register and an evidence set that an independent reviewer can test. Timelines depend on scope, so ask for a phased plan before committing to dates.

Scope the generative AI systems in use
Start by listing every generative AI system the organization builds, fine-tunes, deploys, buys or exposes to customers, including embedded features in third-party products. Record the purpose, the model source, the data it touches, the user groups and the business owner for each system. The output is a generative AI inventory with a named owner per entry. The step is done when the inventory is signed off by the accountable executive and no system is known to be missing.
Determine your actor role for each system
AI 600-1 notes that not every suggested action applies to every AI actor, and that actions written for developers may not apply to deployers. For each inventoried system, record whether the organization acts as developer, deployer, or both, and whether it is a buyer of a third-party model. The output is an applicability list that marks each suggested action as applies, does not apply, or needs a documented reason. Ask legal and procurement to confirm role assignments where contracts are unclear.
Build the current and target profiles
Map the applicable suggested actions to their AI RMF subcategories, then record the current state of practice for each one as the Current Profile. Set the Target Profile based on the risk tolerance and the customer or regulatory expectations the organization has to meet. The output is a pair of profiles that show where each action is already in place and where it is not. Keep the Target Profile in writing so later reviewers can see what the organization chose to aim for.
Run the gap assessment into a gap register
Compare the Current Profile with the Target Profile action by action and record each shortfall in a gap register. Each entry names the suggested action ID, the risk tags it addresses, the gap, the accountable owner and the evidence that would close it. Independent reviewers and internal audit should test a sample of the assessment conclusions. The output is a gap register that lists every open item and marks the ones that block deployment or customer commitments.
Remediate gaps and document decisions
Assign each gap register entry to an owner and close it through a control change, a policy update, a technical test, a training record or a documented risk acceptance. Where a gap is accepted rather than closed, record who accepted it, the residual risk and the review date. Implementation partners can help prepare systems, configurations and documentation, but the organization owns the decisions and the controls. The step is done when every entry is closed or formally accepted by the named executive.
Collect evidence for each suggested action
For each applicable suggested action, collect the artifacts that show it is in place and operating, such as policy text, test results, provenance records, incident logs, monitoring output or approval records. Store them in a single evidence binder indexed by action ID, with the date, the system covered and the owner. The Playbook lists documentation prompts that help identify useful artifacts. The output is an evidence binder that a third party could follow without asking the team for context.
Decide whether to request an independent review
Review the binder and gap register against the question the reader must answer, such as a customer contract clause or a regulator's request. Decide whether an internal review is enough or whether an independent assessor should test the work. Only an independent auditor, assessor or certification body can issue reports or certificates, and no certificate exists for the NIST AI RMF. The output is a written review decision with its reasoning, the scope it covers and the party chosen to perform any external review.

Which four focus areas the profile's actions concentrate on

NIST AI 600-1 says the Generative AI Public Working Group focused on four primary considerations, so most of its suggested actions address them. Each area below shows what it means in practice and which of the 12 generative AI risks it touches most, while the profile still covers risks outside these four, such as confabulation, information security and intellectual property.

Governance

Governance is the first consideration, and it sets who owns generative AI risk decisions. The profile's GOVERN actions carry the AI RMF governance expectations into generative AI, covering policies, accountability and how deployment decisions are made for models and tools the organization builds or buys. The risks this touches most are harmful bias or homogenization and human-AI configuration, because owners must define human roles and oversight. Check that each generative AI use case has a named owner and a documented go or no-go decision.

Content provenance

Content provenance means being able to show where generated content came from and whether it was synthetic. In practice this covers tracking and labeling AI-generated outputs and documenting the data and sources behind them. It touches information integrity most, since the profile describes that risk to include large-scale disinformation and misinformation campaigns, and it also bears on intellectual property. Check whether outputs carry provenance signals and whether the team can trace a published output back to the system and inputs that produced it.

Pre-deployment testing

Pre-deployment testing means evaluating a generative AI system before users reach it. The profile's MEASURE actions point to testing that reflects real use, covering the risks that have an existing empirical evidence base. It touches CBRN information or capabilities, dangerous, violent or hateful content, and confabulation most. Check that test results are recorded, that the test scope matches the intended use, and that a deployer can show its own testing when it relies on a developer's model.

Incident disclosure

Incident disclosure covers how problems with generative AI are reported to the people who need to know. The profile's MANAGE actions address communicating incidents and errors to relevant AI actors, including affected communities. It touches obscene, degrading or abusive content and data privacy most, because those failures often reach users and regulators quickly. Check whether there is a written process that defines what counts as an incident, who is notified, and how the organization records corrective action.

Risks outside the four areas

Confabulation, information security and intellectual property sit outside the four considerations but still need suggested actions. Confabulation is the risk of plausible but false output, information security covers attacks on generative AI systems, and intellectual property covers training data and generated content. The profile addresses them through the same AI RMF subcategories, so a program cannot treat the four focus areas as the whole profile. Check the risk-tagged action list for each of these three and confirm which ones your use case triggers.

Which suggested actions apply if you build, buy or deploy generative AI

Organizations that train, fine-tune or substantially modify a generative model carry the most upstream responsibility. AI 600-1 ties many of its suggested actions to model construction, so developers usually have the strongest claim to the actions on pre-deployment testing, content provenance and the data and training decisions that drive risks such as harmful bias, data privacy and intellectual property. The profile's risk tags help here because they show which actions bear on risks like confabulation or information security.

Training data and model documentation: Actions that record data sources, licensing, personal data handling and known limitations usually land with the team that selected the data.
Pre-deployment testing: Red teaming, evaluation against the risks tagged for the model and documented test results are typically developer-owned actions.
Content provenance: Watermarking, metadata or other provenance methods, where the developer can implement them, belong to the build stage.
Information security of the model: Protection of model weights, training pipelines and evaluation environments should be mapped to the information security risk.
Incident disclosure inputs: Developers hold the technical facts needed to describe model failures to downstream deployers.

Confirm applicability action by action with your risk owners, and record why each action applies or does not, especially where a deployer later assumes the same obligation.

Does the Texas HB 149 liability defense depend on the generative AI profile?

Yes, in part. Texas HB 149, the Texas Responsible Artificial Intelligence Governance Act, effective January 1, 2026, adds Business and Commerce Code Section 552.105(e). It shields a defendant from liability when it discovers a violation through an internal review process while substantially complying with the most recent NIST Generative AI Profile or another nationally or internationally recognized AI risk management framework. The defense turns on two things: the internal review that surfaces the violation, and substantial compliance with a named framework. The NIST Generative AI Profile is the specific framework the statute names, but the same language also accepts other recognized frameworks, so the profile is a route to the defense rather than the only one.

The defense is not a certification. No body issues a Texas safe harbor certificate, and NIST does not validate any organization's use of the AI RMF or its profiles. Your organization has to show, in its own records, that its internal review found the violation and that its program substantially followed the framework version in force when the violation was discovered. Confirm which version of the Generative AI Profile is the most recent at the time of review, because the statute refers to the most recent version. Keep dated records of the review, the suggested actions your program adopted from AI 600-1 and the evidence behind each one.

Separately, Section 552.104 bars an attorney general action until 60 days after notice and lets the person cure the violation first. Ask counsel to map how the cure period interacts with the internal review timeline, and to define what "substantial compliance" means for your system, your deployment context and the risks you identified. Those interpretive questions belong to a Texas attorney, not to a compliance vendor or an implementation partner, and the answers should be documented before an incident occurs.

Choosing between self-assessment, independent review and partner support

This table compares three ways to test readiness against the Generative AI Profile: internal self-assessment, independent review, and implementation partner support. Read each row across to see what the option fits, what the organization still owns, and what it does not provide.

Option	When it fits	What the organization still owns	What it does not provide
Internal self-assessment	Early mapping of GAI suggested actions to existing controls, or internal due diligence before a customer conversation	Scope, method, conclusions, remediation decisions and any statement made to customers or regulators	An independent opinion, a report or a certificate; no outside party validates the result
Independent review by an assessor or auditor	A customer, contract or regulator asks for outside assurance, or the organization wants a third party to test its evidence	Agreeing scope and report type in advance, providing access and evidence, and acting on findings	Design of controls or evidence; the assessor tests and reports but does not build the program
Implementation partner support	Systems, logging, testing pipelines or documentation are missing and need engineering before any review	Control ownership, risk decisions, accountability for the AI system and final sign-off on evidence	Audit reports, attestations or certifications; the partner prepares systems and evidence only
Who issues a report	Only the independent assessor or auditor issues a report or statement of conformity	Publishing any self-description accurately and without implying third-party validation	Any report from an internal team or implementation partner is a work product, not an assessment
Guaranteed outcome	Applies to all three options	Results depend on the actual AI system, its evidence and the organization's decisions	No option guarantees a result, a pass, a liability defense or acceptance by a customer or court

Who owns controls, who prepares evidence and who issues anything

Your organization owns the AI risk program and every decision it contains. Under AI 600-1, the activities in AI RMF 1.0 and the Playbook still apply to generative AI, and the profile's suggested actions only become meaningful once someone accountable has decided which ones fit each system and each role in the value chain. Ownership cannot be handed to a vendor, because the people who decide risk tolerance, accept residual risk and approve deployment must be inside the organization.

Decisions and accountability: Named owners set risk tolerance, approve go or no-go decisions and accept residual generative AI risks.
Scoping the profile: Staff decide which of the 49 subcategories covered by suggested actions apply to each generative AI system, and whether the organization acts as developer, deployer or both.
Policies and documentation: Internal policies, system inventories and records of testing results are authored and kept current by the organization.
Operating the controls: Monitoring, incident response and user feedback run inside your own teams after deployment.
Independent review: Internal reviewers or a separate function should check whether controls work, since NIST's Measure function calls for involving independent assessors.

Confirm internally which roles can sign off on risk decisions before any outside party is engaged.

What usually delays the profile project or inflates its cost

Most delays in a generative AI profile project come from how the work is framed, not from the technical effort. The cards below cover the decisions that expand scope, repeat work or leave gaps an assessor will find, and each one comes with a check to run before the project starts.

Treating the profile as a checklist

Teams often copy the 212 suggested actions into a tracker and mark them complete one by one. NIST AI 100-1 says the AI RMF is not an ordered set of steps, and AI 600-1 says not every action applies to every AI actor. Before work starts, agree which actions fit the organization's role and which subcategories the program will address, and record the reason for each exclusion. Ask the implementation partner to show how the scoping decision is documented.

Scoping every system instead of generative AI

Applying the profile to the entire AI inventory multiplies documentation and testing without adding risk coverage for the systems that generate content. Start with an inventory that tags which systems use generative models, which are built in-house, and which are bought. The profile's risks, such as confabulation and information integrity, apply most directly to those systems. Confirm the inclusion rule in writing before the team estimates effort.

Missing the developer and deployer split

AI 600-1 notes that actions written for developers may not apply to deployers. An organization that builds a model and one that only configures a vendor's model face different obligations, yet many projects produce one set of controls for both. Mark each in-scope system with its role in the value chain, then assign owners for developer actions and deployer actions separately. This split also clarifies which evidence must come from a vendor and which must come from the organization itself.

Capturing evidence after the fact

Test results, approval records and incident logs are hard to reconstruct once a system is live. Projects that defer evidence capture usually spend their final weeks chasing screenshots, emails and test runs that were never saved. Set up evidence collection during testing, with fixed locations, version labels and named owners for each suggested action that the program addresses. Ask whether the monitoring and logging design can produce the records an independent reviewer would request.

Assuming vendor marketing covers obligations

A model provider's safety claims or system card describe that provider's work, not the organization's governance, deployment settings or incident handling. Treating a vendor document as proof of compliance leaves the buyer's own actions unaddressed. Request the vendor's documentation, identify which gaps it leaves, and assign those gaps to internal owners. Keep a short register of vendor claims and the internal tests that verify them.

Questions buyers ask before they commission NIST AI 600-1 work

Is NIST AI 600-1 mandatory, and can an organization be certified against it?

No. NIST AI 600-1 is a voluntary profile of the AI RMF, and there is no certification, accreditation or conformity assessment program for it. NIST does not validate or endorse any organization's use of the framework. A customer or regulator may still ask for evidence of alignment, and some state laws refer to the profile as a practical reference point. What an organization can show is how its program addresses the profile's suggested actions, backed by its own records. Confirm with the requesting customer or regulator exactly what evidence they expect, and whether they mean alignment or a third-party attestation, since the two are different requests.

How much effort does a generative AI profile assessment take, and what drives it?

Effort depends mainly on how many generative AI systems are in scope, how many of the 212 suggested actions apply to each system's role, and how much documentation already exists. AI 600-1 notes that not every action applies to every AI actor, so a deployer and a developer will work through different sets. The largest effort usually sits in pre-deployment testing, content provenance and incident disclosure, the four primary considerations the profile emphasizes. Organizations with an AI inventory and an existing AI RMF Core program start from a stronger position. Ask any provider to break its quote down by system, by role and by suggested action group, and to state which evidence it expects the client to produce.

How long does the work take, and what sets the timeline?

The timeline is set by scope, not by the profile itself. The main drivers are the number of generative AI systems, the state of current governance records, whether testing infrastructure exists, and how many third-party models or components the system depends on. Work that needs new testing capability, such as red teaming or evaluation pipelines, takes longer than documentation work on a system that already has them. Any engagement should begin with a written scope and a dated plan agreed before work starts. DeployOpen's engagements are typically fixed-scope, so the timeline is set in writing with the scope, and the reader should confirm the exact schedule in that document rather than rely on general estimates.

What must the organization provide before an implementation partner can start?

The organization must supply the facts about its own systems and decisions, because an implementation partner can prepare systems and evidence but cannot make governance decisions on the client's behalf. The usual inputs are:

A list of generative AI systems, their intended purposes and their deployment context
Current policies, risk tolerances and records of existing AI risk decisions
Access to model configurations, logs, test results and third-party contracts
Named owners for accountability, incident response and human oversight
A decision on which of the four primary considerations, governance, content provenance, pre-deployment testing and incident disclosure, the program must address first

The organization owns its controls and its risk acceptance. Confirm these inputs in the written scope so that both sides know which gaps belong to whom.

Can we do the NIST AI 600-1 work in-house?

Yes, an organization can do the work itself, because the profile is voluntary and NIST does not require an outside party. In-house work makes sense when the team already understands the AI RMF, has security testing skills and can keep the documentation current. Outside help is most often used for the technical testing and evidence preparation that is hard to build quickly, and for an independent view before a customer or regulator review. Any outside partner should be scoped in writing, and it prepares systems and evidence rather than issuing a conclusion. Ask any prospective partner which parts it would hand back to the client, and which parts require an independent assessor.

What will an independent assessor issue, and what will it not issue?

An independent auditor, assessor or certification body can give an opinion or report on the evidence it examines, but it cannot issue a NIST AI 600-1 certificate because none exists. It will not validate the framework itself or certify that a system is compliant with NIST. A provider that offers a NIST AI 600-1 certificate is making a claim that NIST does not recognize, and a buyer should treat that as a red flag. Ask any assessor to define in writing what it will examine, what report it will produce and how it will describe its scope and limits. The organization owns its controls and its statements about them.

Does the 2025 Executive Order revocation change how we can use the profile?

Not for the organization's own use. NIST developed AI 600-1 under Section 4.1(a)(i)(A) of Executive Order 14110, and Executive Order 14148, signed January 20, 2025, revoked EO 14110. NIST still lists AI 600-1 on its AI RMF page as of October 2026, and the profile remains a published, voluntary document. The revocation matters more for any federal rule or contract clause that was tied to EO 14110. The July 2025 America's AI Action Plan also recommends revising the AI RMF, so the profile may change later. Confirm the current version and status on NIST's publication page before writing it into a contract or policy, and keep track of any state law that cites it.

How DeployOpen works on this

DeployOpen is a Chainscore Labs company that deploys self-hosted open-source platforms inside a client's own infrastructure and runs security testing alongside them. For the generative AI profile, DeployOpen prepares systems, controls and evidence against the suggested actions an organization selects, while the organization owns its controls and an independent assessor issues any report.

How we scope

Agree in writing which generative AI systems, deployments and business units fall inside the profile work.
Record which of the 12 generative AI risks and which suggested actions the organization has chosen to address.
Confirm which actions apply to the organization as developer, deployer or both, since not every action applies to every AI actor.
Set deliverables, timelines and responsibilities before work starts, because most engagements are fixed-scope.

How we build

Deploy and configure the chosen open-source platforms in the client's cloud account, data center or air-gapped network.
Integrate logging, access control and monitoring so that the evidence for each selected action is generated as the system runs.
Run pre-deployment security and behavior testing on generative AI components, covering the risks the scope selected.
Document configuration, test results and open risks in a form the organization's own reviewers and assessors can read.

How we hand over

Deliver a mapping of each selected suggested action to its AI RMF subcategory, the system component it covers and the evidence location.
Provide written records of test methods, results, residual risks and the owner accountable for each one.
Transfer administrative access, runbooks and documentation so the organization can operate and audit the systems itself.
Confirm with the organization's independent assessor which evidence they need, since DeployOpen does not issue reports or certificates.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work is complete.
Update evidence and documentation when the platform is upgraded or when the Playbook or AI 600-1 changes.
Review the profile's suggested actions again when the revised AI RMF is published, and adjust scope in writing.
Ask for a quote based on the written scope, since DeployOpen does not publish a price list.