Written and maintained by CASRAI Editorial Board
Last updated
On 16 April 2025, Governor Greg Gianforte signed Senate Bill 212, the Right to Compute Act, making Montana the first state to write a right to own and use computational resources into statute. It is now Chapter 150, Laws of 2025, codified at MCA Title 2, chapter 10, part 2 (sections 2-10-201 through 2-10-207), and it took effect on passage and approval. Almost every state AI law this site covers adds obligations; this one subtracts the government’s freedom to impose them. But the Act is not purely deregulatory, and the exception is the interesting part: a single safety duty for critical infrastructure run by AI, whose yardstick is the NIST AI Risk Management Framework and the ISO/IEC AI management standard. In NIKOLAI terms, the duty Montana kept is a risk-management policy; the duty it removed before enactment was a halt condition.
What the Act actually says
The operative right is in MCA 2-10-204, and it is one sentence:
Government actions that restrict the ability to privately own or make use of computational resources for lawful purposes, which infringes on citizens’ fundamental rights to property and free expression, must be limited to those demonstrably necessary and narrowly tailored to fulfill a compelling government interest.
The findings section (2-10-202) grounds that in two provisions of the Montana Constitution: the right to acquire, possess and protect property under Article II, section 3, and freedom of expression under Article II, section 7. The legislature’s theory is that those existing rights “also embody the notion of a fundamental right to own and make use of technological tools, including computational resources.”
Worth noting precisely, because secondary coverage is loose about it: the phrase strict scrutiny does not appear anywhere in the statute. What appears is the standard’s operative formula — “demonstrably necessary and narrowly tailored to fulfill a compelling government interest.” That is the substance of strict scrutiny, and describing it that way is fair, but the Act imposes the test by describing it rather than by naming it.
The definitions in 2-10-203 are deliberately expansive. “Computational resources” means “any tools, technologies, systems, or infrastructure, whether digital, analog, existing, or some other form, that facilitate any form of computation” — and then lists hardware, software, algorithms, sensors, networks, protocols, platforms, services, systems, cryptography, machine learning and quantum applications. “Government actions” reaches any “law, ordinance, regulation, rule, policy, condition, test, permit, or administrative practice,” and “government entity” reaches counties, cities and towns. The Act is aimed at local zoning and permitting at least as much as at the state legislature.
The compelling interests the legislature pre-approved
Rather than leave “compelling government interest” to the courts, the Act defines it — as “a government interest of the highest order in protecting the public that cannot be achieved through less restrictive means” — and then supplies a non-exhaustive list of four things that qualify:
- ensuring that a critical infrastructure facility controlled by an AI system develops a risk management policy;
- addressing conduct that deceives or defrauds the public;
- protecting individuals, especially minors, from harm by a person who distributes deepfakes and other harmful synthetic content with actual knowledge of the nature of that material; and
- taking actions that prevent or abate common law nuisances created by physical datacenter infrastructure.
The first item is the drafting move that makes the Act internally coherent. Section 2-10-205 imposes a duty; section 2-10-204 subjects government restrictions to strict scrutiny. By declaring in advance that the 2-10-205 duty is a compelling interest, the legislature immunised its own safety provision against its own standard of review. The third item does similar work for Montana’s deepfake statutes, and the fourth preserves nuisance actions against data centres.
The one safety obligation: MCA 2-10-205
Here is the whole of it:
When critical infrastructure facilities are controlled in whole or in part by a critical artificial intelligence system, the deployer shall develop a risk management policy after deploying the system that is reasonable and considers guidance and standards in the latest version of the artificial intelligence risk management framework from the national institute of standards and technology, the ISO/IEC 4200 artificial intelligence standard from the international organization for standardization, or another nationally or internationally recognized risk management framework for artificial intelligence systems. A plan prepared under federal requirements constitutes compliance with this section.
Five features of that sentence are worth separating out.
It points at voluntary frameworks. The most deregulatory AI statute in the country still reaches for NIST and ISO as its measure of reasonableness. This is the clearest recent example of a pattern that deserves more attention than it gets: consensus frameworks written as voluntary guidance acquire legal weight by being named in statute. Our comparison of the NIST AI RMF and ISO/IEC 42001 sets out how differently the two operate — one a free, self-assessed structure of Govern, Map, Measure and Manage; the other a certifiable management system audited by a third party. Montana’s statute treats them as interchangeable reference points.
The reference is dynamic. “The latest version” means the obligation moves when NIST does. NIST published AI RMF 1.0 in January 2023 and is revising it under the White House AI Action Plan; it also released a concept note on 7 April 2026 for an AI RMF profile on trustworthy AI in critical infrastructure. If that profile lands, the content of a Montana deployer’s duty changes without the legislature voting on anything.
The timing is backwards, and deliberately so. The policy is developed “after deploying the system.” This is not a pre-deployment assessment regime of the kind Colorado built. Nothing in the section sets a deadline, requires review or testing, or obliges the deployer to update the policy.
The ISO citation is wrong. There is no “ISO/IEC 4200” artificial intelligence standard. The AI management system standard is ISO/IEC 42001:2023. The error is in the enrolled bill and survived into the codified text at 2-10-205. In practice it is harmless — the NIST framework is named correctly and the catch-all clause covers any “nationally or internationally recognized risk management framework” — but anyone quoting the statute should quote it as written rather than silently correcting it.
A federal plan is a complete defence. “A plan prepared under federal requirements constitutes compliance with this section.” An operator already producing risk documentation under a federal regime has nothing further to do. Given how much US critical infrastructure is federally regulated, this safe harbour likely does more work than the duty itself.
Two undefined terms carrying the whole obligation
Section 2-10-203 defines eight terms. “Consequential decision” is not one of them — and it is the sole trigger for the entire safety provision.
The chain runs like this. The duty attaches only to a “critical artificial intelligence,” defined as “an artificial intelligence system that is designed and deployed to make, or is a substantial factor in making, a consequential decision.” Whether any given system is in scope therefore turns entirely on what a consequential decision is, and the Act never says. Colorado’s SB 24-205, from which the surrounding exclusion list is plainly borrowed, defines the term at length; Montana took the exclusions and left the definition behind. Readers following this cluster will recognise the shape from our work on capability thresholds and security levels: a load-bearing term that every document uses and none defines.
There is a second, smaller slip. The definition in 2-10-203(4)(a) defines “critical artificial intelligence.” The obligation in 2-10-205 applies to a “critical artificial intelligence system.” The two are almost certainly meant to be the same thing, but the defined term and the used term are not identical.
The exclusions themselves are broad. Out of scope are systems intended to perform a narrow procedural task, improve the result of a completed human activity, perform a preparatory task, or detect a decision-making pattern; a long list of ordinary software (antivirus, firewall, database, spreadsheet, spell-checking, web-hosting, search); and — notably — any technology that communicates in natural language to provide information, make referrals, answer questions or generate content, provided it is subject to an acceptable use policy prohibiting unlawful content. That last exclusion removes most general-purpose chatbots from the provision entirely.
“Critical infrastructure facility” is borrowed from a trespass statute
Rather than define the term, 2-10-203(5) adopts the meaning in MCA 82-1-601 — which sits in Title 82 (Minerals, Oil, and Gas) and exists to support a criminal trespass offence.
The list is what you would expect: refineries, electric generating and transmission facilities, chemical manufacturing, water treatment, natural gas compressor stations and terminals, telecommunications and broadband infrastructure, ports and rail, dams, pipelines, mining infrastructure, correctional facilities and military installations. Our guide to AI on the power grid and CISA’s operational-technology guidance covers what running AI in these environments actually involves.
The borrowing carries conditions written for a different purpose. Under 82-1-601, portions of pipelines and facilities qualify where they are completely enclosed by a fence “obviously designed to exclude intruders” or clearly marked with signs forbidding entry without authorisation. Those are sensible elements of a trespass offence. As a scoping test for an AI risk-management duty, fencing and signage are an odd thing for the answer to depend on.
What the introduced bill required, and what was cut
The bill that Senator Daniel Zolnikov (R-Billings) introduced on 24 January 2025 was materially stricter, and the amendment history is visible in the bill’s own title. The enrolled version reads “REQUIRING SHUTDOWN CAPABILITIES A RISK MANAGEMENT POLICY FOR CRITICAL INFRASTRUCTURE FACILITIES CONTROLLED BY AN ARTIFICIAL INTELLIGENCE SYSTEM.”
Four things did not survive to enactment:
- A disable-and-revert capability. The introduced text required the deployer to “ensure the capability to disable the artificial intelligence system’s control over the infrastructure and revert to human control within a reasonable amount of time.” Struck.
- Shutdown-impact analysis. A subsection requiring the deployer, when enacting a full shutdown, to consider disruptions that might result from it. Struck.
- Annual review and testing. The original duty was to “implement, annually review, and test” the risk management policy. The enacted duty is to “develop” one. No cadence remains.
- Fallback and redundancy planning. The policy originally had to include “a fallback mechanism and a redundancy and mitigation plan to ensure the deployer can continue operations and maintain control of the critical infrastructure facility without the use of the artificial intelligence system.” Struck.
A fifth change narrowed the trigger: the duty originally attached when a facility was controlled by “an artificial intelligence system,” and was amended to “a critical artificial intelligence system.”
This history is routinely misreported, and the reason is partly the Legislature’s own records: the bill’s official short title still reads “Creating the Right to Compute Act and requiring shutdowns of AI controlled critical infrastructure,” which describes a version that was never enacted. A 2026 Mackinac Center write-up surveying right-to-compute bills in other states still describes Montana’s law as requiring a shutdown mechanism allowing reversion to human control, plus annual risk reviews — neither of which is in the enacted text. If you are advising on this statute, read MCA 2-10-205, not a summary of SB 212.
The votes, incidentally, were not close: 50-0 in the Senate on both readings, and 61-38 on third reading in the House.
How the strict-scrutiny provision is working in practice
The contested application so far has been data centres, not AI safety. Montana Free Press reported in September 2026 that county officials are unsure how much zoning authority they retain: Yellowstone County Commission chair Mark Morse said “we don’t know what we have the power to do,” and the county sought a district court judgment in July 2026 on a citizen petition concerning data centre regulation, which the court invalidated on procedural grounds on 11 August 2026 without resolving the underlying question. Missoula County passed a one-year moratorium on data centre development through emergency interim zoning in March 2026. Zolnikov’s position is that “as long as regulation is done for public health and safety, I don’t see why there would be any issue.”
That uncertainty is the Act’s real early effect, and it is worth stating plainly: a statute drafted to protect computation from restriction is being litigated over where buildings can go.
Why the model matters beyond Montana
Every other state AI law in this cluster — Colorado’s AI Act, Texas TRAIGA, California SB 53, New York’s RAISE Act — starts from the premise that AI deployment creates duties. Montana starts from the premise that computation is a protected activity and restriction is the thing requiring justification. Treating that as merely obstructive misses what it is: a coherent constitutional theory that will be tested in court, and the organising idea of a growing state coalition.
As reported by the Mackinac Center in 2026, right-to-compute bills are moving in Ohio (HB 392, carried over from 2025 with four committee hearings), New Hampshire (HB 1124, with a separate effort to put the right into the state constitution) and South Carolina (introduced January 2026, reportedly modelled on Montana). Whether those bills copy 2-10-205 along with 2-10-204 is the detail to watch, because that clause is the template for how a deregulatory statute still imports NIST and ISO.
The deeper point connects to compute governance generally. Montana protects compute as property and expression at the state level; federal export controls restrict compute using entirely different levers, as our guide to compute governance, export controls and FLOP thresholds explains. Section 2-10-207 provides that nothing in the Act may be construed to preempt federal law, so the two regimes do not collide — they simply operate on different planes.
Where NIKOLAI fits
NIKOLAI is CASRAI’s own independent dictionary for frontier AI safety disclosure. It is unendorsed: no organisation named in a crosswalk has adopted it, and crosswalk rows are shadow mappings unless that organisation has filed a Mapping Declaration.
The provision Montana removed is a textbook instance of NIKOLAI element B9, Halt Condition (track N3, thresholds and checkpoints): a declared condition under which operation must stop, together with who may invoke it and what is required to resume. The introduced bill specified the trigger (AI control of a critical infrastructure facility) and the action (disable control, revert to human operation within a reasonable time), but never named the authority or the resumption criteria — the same two gaps NIKOLAI’s own survey finds across published frontier safety frameworks. The enacted statute drops the halt condition entirely and keeps only a documentation duty, which is a useful illustration of how the element distinguishes a commitment to stop from a commitment to write something down.
Frequently asked questions
Does the Right to Compute Act regulate AI developers?
No. It imposes no obligation on anyone who builds or trains an AI model. The single duty in MCA 2-10-205 falls on deployers — “an individual, company, or other organization that utilizes an artificial intelligence system” — and only where a critical infrastructure facility is controlled in whole or in part by a critical AI system.
Does the Act say “strict scrutiny”?
No. MCA 2-10-204 requires restrictions to be “demonstrably necessary and narrowly tailored to fulfill a compelling government interest.” That is the strict-scrutiny formula stated in substance, but the phrase itself is not in the statute.
What is the penalty for not developing a risk management policy?
The Act specifies none. There is no civil penalty provision, no enforcement authority named, and no private right of action in part 2. The obligation exists without a stated sanction — though failure to maintain a reasonable policy could be relevant to negligence in ordinary litigation.
Does the statute really cite ISO/IEC 4200?
Yes. Both the enrolled bill and the codified text at MCA 2-10-205 refer to “the ISO/IEC 4200 artificial intelligence standard.” No such AI standard exists; the intended reference is almost certainly ISO/IEC 42001:2023. The clause’s catch-all for any recognised AI risk management framework makes the error immaterial in practice.
Did Montana’s law require an AI kill switch?
The introduced bill did; the enacted law does not. The disable-and-revert-to-human-control requirement, the shutdown-impact analysis, the annual review and testing duty, and the fallback and redundancy plan were all removed by amendment before passage.
When did the Act take effect?
Immediately on passage and approval — 16 April 2025, the day Governor Gianforte signed it. It is Chapter 150, Laws of 2025, codified at MCA 2-10-201 through 2-10-207.
Does the Act prevent Montana from regulating data centres?
Not outright. It subjects restrictions to a demanding standard, and expressly lists abating common law nuisances created by physical datacenter infrastructure as a compelling government interest. How much local zoning authority survives is genuinely unsettled and is being worked out in county government and the courts.
Why This Matters for Research Administration
The honest scope here is narrow, and it is worth saying what the Act does not do first: it grants researchers no specific entitlement, creates no exemption for academic computing, and does not loosen any federal rule. Section 2-10-207 states that nothing in the Act may be construed to preempt federal law, so export controls and research-security requirements governing high-performance computing on campus are entirely untouched by it. A Montana university cannot read a state right to compute as relief from a federal compute restriction.
What does change is the regulatory risk profile for siting and procurement. Institutions planning HPC capacity, campus data centre expansion or co-location in a strict-scrutiny state face a different local-permitting environment than in Colorado or California — less restriction, but also, as Yellowstone and Missoula counties are demonstrating, less predictability while the boundaries of local authority are litigated. And research computing leaders should check the scope of 2-10-205 against their own estate rather than assuming it is irrelevant: a campus power plant, substation or water treatment facility can fall within the MCA 82-1-601 list, and if an AI system is a substantial factor in consequential decisions there, the deployer duty attaches to the institution like anyone else.
