Montana Right to Compute Act and NIST AI RMF

Does the Montana Right to Compute Act require the NIST AI RMF?

Montana Code 2-10-205 requires the deployer of a critical artificial intelligence system that controls critical infrastructure facilities, in whole or in part, to develop a reasonable risk management policy after deployment. The policy must consider the latest NIST AI Risk Management Framework, the ISO/IEC standard written in the statute as "ISO/IEC 4200", or another recognized AI risk management framework. The statute does not name the NIST AI RMF as mandatory. It names it as one of several frameworks an organization may weigh, and the AI RMF is voluntary everywhere else, so the question for a Montana-connected operator is which framework it will consider and how it documents that choice.

The NIST AI RMF is not a certification, and no certificate, badge or third-party report satisfies this section by itself. NIST does not validate or endorse any organization's use of the framework. What the statute asks for is a policy that exists, was developed after deployment, and reflects a reasonable approach to the risks of the system. Operators should confirm with counsel what "reasonable" will mean for their facilities, and should keep a record showing which frameworks were considered, why the chosen one fits, and how the policy was approved and reviewed. An assessor or regulator will look for that record, not for a logo.

The answer differs by organization. The first thing to establish is whether each AI system is a critical artificial intelligence system under the statute and whether it controls critical infrastructure facilities in whole or in part. The second is whether a plan prepared under federal requirements applies, because Montana Code 2-10-205 treats such a plan as compliance with the risk management policy requirement. Confirm both points against the current statute text and any federal plan that covers your systems before committing budget. If no federal plan applies, a NIST-aligned program gives you a documented policy structure, and the Map, Measure and Manage functions give you the evidence trail to show the policy is in use.

How a NIST-aligned program supports the policy

The sequence below turns the Montana post-deployment risk management policy into a working program: it starts with the inventory of critical AI systems, sets context and risk tolerance, builds monitoring and incident handling, and ends with a documented policy under a review cadence. Each phase produces a named artifact that an assessor or the state can inspect.

Scope which AI systems control critical infrastructure
Start by listing every AI system deployed at your facilities and identifying which ones control critical infrastructure facilities in whole or in part. Legal, operations and OT engineering should confirm the list together, because the statute applies to systems that control facilities, not to every AI tool in the building. The output is a scoped inventory that names each critical AI system, its owner, the facilities it controls and the vendor components it depends on. Confirm the definition of critical infrastructure facility with counsel before the list is final.
Map context and set risk tolerance under MAP 1
For each system in scope, document its intended purpose, the teams that operate it, the mission it supports and the system requirements. MAP 1 is where the organization records the context that later decisions depend on. AI 100-1 states that the framework can prioritize risk but does not set risk tolerance, so the team should check whether sector rules define risk criteria. Where none exist, leadership defines a reasonable tolerance in a written risk tolerance statement that the risk owner signs.
Define post-deployment measurement under MEASURE 3
Build a monitoring plan that tracks the risks identified in mapping after the system goes live. MEASURE 3 covers existing and emergent risks, risks that current methods cannot measure, and end user problem reporting and appeals. The plan should name the metrics, the data sources, the people who review results and the thresholds that trigger escalation. The output is a monitoring plan with an owner for each metric. Confirm with the operators that the plan can run against the OT and control-system data the facility actually produces.
Set incident handling and response under MANAGE 4
Define how the organization responds when monitoring shows a problem. MANAGE 4 covers monitoring plans, continual improvement and communication of incidents and errors to relevant AI actors. Write the escalation path, the authority to pause or roll back a system, the notification contacts inside and outside the company, and the steps for recording lessons learned. The output is an incident handling procedure tied to the monitoring thresholds from the previous step, tested at least once through a tabletop exercise.
Address third-party components under GOVERN 6 and MANAGE 3
Many critical AI systems rely on vendor models, data and software. Review the contracts and support arrangements for each third-party component, confirm what telemetry and change notices the vendor provides, and record which monitoring duties stay with the vendor and which stay with the organization. The output is a third-party AI register linked to the inventory, with a contingency plan for failure of any high-risk vendor component. Ask each vendor in writing what it will share after a model update.
Document the post-deployment policy under GOVERN 1
Consolidate the inventory, context records, risk tolerance statement, monitoring plan and incident procedure into one written risk management policy for the critical AI systems. GOVERN 1 covers the policy base layer, including legal requirements, documentation, periodic review and decommissioning. The policy should state which frameworks it considers, including the latest NIST AI RMF and the other recognized frameworks the statute names, and it should explain how a federal plan would be treated if one applies. Approval by an accountable executive closes this step.
Set the review cadence and keep the record
Fix a review schedule for the policy and each supporting artifact, and state what triggers an unscheduled review, such as a material system change, a new incident or a revised framework. Track the version of the NIST AI RMF the policy cites, because a planned revision of AI RMF 1.0 is under way and laws that cite the latest version make that change relevant. The output is a version-controlled policy with a change log and dated approvals. Ask counsel to confirm whether the statute sets any review interval for your sector.

Does a federal plan replace the Montana policy?

Montana Code 2-10-205 says a plan prepared under federal requirements constitutes compliance with the risk management policy requirement. That provision is useful, but it only helps if the federal plan covers the same system, the same facilities and the same post-deployment period. The cards below are the questions to settle, in writing, before treating a federal plan as the Montana policy.

Does the plan cover this system?

Start by matching the federal plan's scope to the critical artificial intelligence system that controls the critical infrastructure facility. A plan written for a different model, a different deployment or a different facility does not cover the system in question. Ask whether the plan names the system, its deployment context and the facilities it controls. Write down any gap, such as a system added later or a facility outside the plan's boundary, and close it before relying on the exemption.

Does it govern after deployment?

The Montana requirement is specifically a policy developed after deployment. A federal plan written only for pre-deployment testing or approval may not address live monitoring, incident response or retirement of the system. Check whether the plan contains ongoing monitoring, periodic review and a process for responding to newly identified risks. If it does not, the organization still needs a post-deployment policy that the federal plan can be mapped onto.

Who determines that the plan applies?

The statute does not say who decides whether a federal plan meets the requirement, so the answer has to come from the organization's counsel and the state's enforcement posture. Confirm with counsel whether the deployer alone can make that determination or whether the Montana Attorney General or another state office would need to accept it. Record the conclusion and the reasoning, because a regulator is likely to ask how the organization reached it.

Which federal requirements apply?

The exemption depends on a plan prepared under federal requirements, so the organization must identify exactly which federal rules produced the plan. Confirm the authority, the agency and the version of any requirement the plan follows. Note that the NIST AI RMF is a voluntary framework, so a plan that relies only on it may not qualify as a federal requirement without further confirmation. Ask counsel to confirm this point in writing.

Can the plan be produced on request?

A plan that exists but cannot be shown quickly will not help during an inquiry. Maintain a current copy of the federal plan, its approval or acceptance records, the date of its last review and a crosswalk showing where the post-deployment elements appear. Keep evidence of operation as well, such as monitoring records, incident logs and review minutes. Ask who on the team owns the packet and how often it is refreshed.

Where does the NIST AI RMF still apply?

If the federal plan does not fully cover the system, the Montana policy must still consider the latest NIST AI Risk Management Framework, ISO/IEC 42001 or another recognized framework. A NIST-aligned program can fill those gaps by mapping risks, measuring them over time and managing responses. Use the Govern, Map, Measure and Manage functions to identify which federal plan elements are missing and which parts of the program need their own documentation.

Who owns the policy, who prepares the evidence and who assesses it

The deployer of a critical artificial intelligence system that controls critical infrastructure facilities is the party Montana Code 2-10-205 addresses. That organization must develop the reasonable risk management policy after deployment and decide what it says. The policy is the operator's document, approved and owned by its leadership, and it is the place where the operator states its risk tolerance, its decision rights and the frameworks it considered. AI 100-1 notes that the AI RMF can prioritize risk but does not prescribe risk tolerance, so the operator must follow any existing sector rules for risk criteria and, where none exist, define a reasonable tolerance itself.

Policy approval: Executive or board-level sign-off on the policy, with named owners for each review.
Risk tolerance: The operator sets thresholds for acceptable harm to critical infrastructure and documents the reasoning.
Go or no-go decisions: Deployment, continued operation and deactivation decisions stay with the operator.
Framework selection: The operator records which frameworks it considered, including the latest NIST AI RMF version.
Accountability records: Named roles, escalation paths and training records that show who answers for AI risk.

Confirm with counsel and your sector regulator whether any existing rules already set risk criteria for your facilities before drafting tolerances of your own.",

What to have in place before relying on the policy

Montana's requirement is a risk management policy developed after deployment, so the policy is only as credible as the records behind it. The cards below cover the items an assessor or Montana regulator would expect to see behind that policy, and how your own team can check each one before it is cited.

Current inventory of critical AI systems

List every AI system that controls critical infrastructure facilities in whole or in part, and tie each entry to the specific facility, operational technology zone and vendor component it touches. This is the scope boundary for the policy, so a system missing from the inventory is a system the policy does not cover. Check that the inventory is reviewed on a set schedule and that a deployment cannot go live without an entry. Confirm the inventory matches what operations staff actually run, not only what IT registered.

Documented roles under GOVERN 2

Name the people accountable for each critical AI system, including the owner of the facility, the model or vendor relationship, and the decision to suspend or roll back the system. GOVERN 2 covers documented roles, lines of communication and executive responsibility for AI risk decisions. Check that each named role has written duties, that escalation paths reach an executive, and that the people named have been trained on them. Ask whether a plant operator can halt an AI-controlled process without waiting for approval.

Written risk tolerance or sector rule reference

AI 100-1 says the framework prioritizes risk but does not set risk tolerance, so the organization must either follow existing sector rules for risk criteria or define a reasonable tolerance itself. Write down which sector rules apply to your facilities and, where none exist, record the tolerance your leadership approved. Check that the policy states the threshold for going live, for pausing and for escalating, and that the tolerance is traceable to a decision by a named approver.

Monitoring evidence from MEASURE 2

MEASURE 2 covers testing and evaluation of trustworthy characteristics, including monitoring after the system reaches production. For an AI system that affects physical processes, keep test records, acceptance criteria and results from deployment-like conditions, alongside logs from live operation. Check that the monitoring covers the characteristics your facility cares about most, such as safety and resilience, and that results are compared against the acceptance criteria rather than reviewed informally.

Tracking records from MEASURE 3

MEASURE 3 addresses tracking risks over time, including risks that current methods cannot measure and reports from end users. Maintain a register of known and emerging risks for each critical system, with an owner and a date for each entry, and a channel for operators to report problems. Check that unmeasurable risks are listed rather than omitted, and that reports from operators lead to recorded decisions.

Dated review and revision record

The policy is developed after deployment, so it must show when it was written, who approved it, what it considers and when it was last reviewed. Keep a version history that records each change and the reason for it, and link each review to the latest NIST AI RMF version in force at the time. The NIST AI RMF 1.0 revision is in progress, so record which version your policy cites. Check that the review date is set and that someone is responsible for updating the policy when the framework changes.

How the pending NIST revision and critical infrastructure profile affect the policy

The statute ties the policy to the *latest* NIST AI Risk Management Framework, so the version your policy cites matters. NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan and has not published a revised version as of 17 October 2026. The July 2025 Action Plan recommends removing references to misinformation, diversity, equity and inclusion, and climate change, and NIST's versioning scheme means a revision would most likely appear as a new minor or major version. Your policy should name the version it relies on, for example "AI RMF 1.0 (NIST AI 100-1, January 2023)", and state that the reference will be re-checked when NIST publishes a revision. Confirm the current status on NIST's pages before each review, because the revision timing is not fixed.

A second, separate project may matter more for a critical infrastructure operator. On April 7, 2026 NIST released a concept note for an *AI RMF Profile on Trustworthy AI in Critical Infrastructure*, which NIST lists as ongoing as of October 2026. The project describes guidance on risk management practices for AI-enabled capabilities across IT, operational technology and industrial control systems. NIST says the profile is meant to help operators communicate trustworthiness requirements to teams, developers and suppliers across the AI lifecycle and supply chain. Since the profile is still in development, treat it as an input to watch rather than a settled benchmark, and confirm its status on the NIST project page before you cite it.

Record the decisions this creates in a version log attached to the policy: the NIST documents referenced, their version or publication date, the date you last checked for revisions, the person who checked, and any change made in response. Note which parts of the policy depend on the Core, which depend on the Generative AI Profile, and which would need updating if the critical infrastructure profile is finalized. A reviewer should be able to see, for any date, which framework text the organization relied on. Ask your counsel whether Montana or any other rule you operate under requires a specific version or review cadence, since the statute's wording alone does not set one.

Questions operators ask about the Montana requirement

Is the NIST AI RMF mandatory under Montana's Right to Compute Act?

The statute does not require you to adopt the NIST AI RMF, but it does require the deployer of a critical artificial intelligence system that controls critical infrastructure facilities to develop a reasonable risk management policy that considers the latest NIST AI Risk Management Framework, the ISO/IEC 4200 standard named in the statute, or another recognized AI risk management framework. The framework itself is voluntary. NIST states that neither private nor public sector organizations are required to use it. Your obligation is to consider it, document that consideration and build a policy around the choice you make. Confirm with counsel how the Montana Attorney General or any other enforcing body would read the word "considers" in your situation.

Does holding an AI RMF certificate prove compliance in Montana?

No. There is no AI RMF certification, accreditation or conformity assessment program. NIST does not validate or endorse any organization's use of the framework, so no certificate can serve as proof. Evidence that you considered the framework is a documented policy, a record of which Core categories and subcategories you chose and why, and the artifacts that show the policy is operating, such as risk assessments, test results and incident records. Any firm that offers an "AI RMF certified" label is making a claim that NIST does not recognize. Ask any assessor exactly what they will examine and what they will issue.

Who writes the post-deployment risk management policy?

The deployer owns the policy, and the deployer's leadership is accountable for approving it. Legal and compliance teams interpret the statute, while security, AI engineering and operations teams supply the system facts the policy depends on. An implementation partner can draft the policy structure, map the chosen framework categories to your existing controls and prepare the evidence templates, but it cannot make risk tolerance decisions or sign off on the policy for you. Independent auditors and certification bodies issue reports and certificates. They do not write your policy. Ask any partner to show which decisions remain with your staff.

What drives the effort of meeting this requirement?

Effort depends on how many critical infrastructure facilities the AI system controls, how many AI systems are in scope, how mature your existing risk management program is and how much of the system's behavior you can observe after deployment. The AI RMF itself is not prescriptive about risk tolerance. AI 100-1 says organizations should follow existing sector rules for risk criteria and tolerance and, where none exist, define a reasonable tolerance themselves, which takes time for governance teams. Ask any quote to break down the work by inventory, risk analysis, policy drafting, measurement design, evidence collection and staff training, and to state which parts are one-time and which recur.

Does the federal-plan provision exempt us from the requirement?

The statute says that a plan prepared under federal requirements constitutes compliance with the risk management policy requirement. Whether a specific federal plan qualifies depends on which federal requirement it was prepared under and whether it covers the critical AI system and facilities in Montana. Do not assume the provision applies because you already file federal plans. Document the federal requirement, confirm the plan's scope against the Montana definitions and get counsel's written view before you rely on it. A NIST-aligned program can still serve as your Montana policy evidence even if a federal plan is also in place.

What changes if NIST revises AI RMF 1.0?

The statute refers to the latest NIST AI Risk Management Framework, so a revision matters. NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan and has not yet published a revised version as of October 2026. The July 2025 AI Action Plan recommends removing references to misinformation, diversity, equity and inclusion, and climate change. Your policy should name the framework version it considers, record the date of that review and include a step to re-check it when NIST publishes a revision. Confirm with counsel whether a policy that cites version 1.0 must be updated once a revision is released.

Can a partner take this requirement on for us?

A partner can take on defined parts of the work under a written, fixed scope. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and prepares systems, controls and evidence for assessments. Typical deliverables include an AI system inventory, a control and evidence map to the chosen framework, monitoring and logging configuration and runbooks. DeployOpen does not issue audit reports, attestations or certifications, and it does not own your risk tolerance or legal interpretation. Ask for a written scope that lists which decisions stay with your team.

How DeployOpen works on this

DeployOpen helps critical infrastructure operators put a NIST-aligned AI risk management program in place inside their own infrastructure. We prepare the systems, documentation and evidence that a post-deployment risk management policy relies on, while the organization keeps ownership of its policy, its risk tolerance and every decision about its critical infrastructure facilities.

How we scope

We agree a written scope that names the critical AI systems, facilities and OT or IT boundaries covered by the policy.
We confirm which AI RMF categories and subcategories the policy will reference, starting from Govern and the current Map work.
We document which frameworks are considered, including the latest NIST AI RMF version and any sector rules that set risk criteria.

How we build

We set up the governance records, AI system inventory and role assignments the policy depends on for each in-scope system.
We prepare measurement and monitoring procedures for post-deployment performance, using open-source tooling inside your environment.
We map the Playbook suggested actions to your own systems and document where your controls differ from them and why.

How we hand over

We deliver the written risk management policy draft, supporting procedures and a mapping of evidence to each in-scope requirement.
We walk your teams through the evidence trail so they can explain each control to operators, regulators and assessors.
We document open items and the decisions your leadership still needs to make, such as risk tolerance and go or no-go criteria.

How we support

Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, which covers updates when NIST revises the framework.
Confirm with us, in the written scope, who maintains the policy after handover and how changes to the latest NIST version are handled.

Montana Right to Compute Act and the NIST AI RMF