Clarion Street

NIST's Critical Infrastructure AI Profile: When 'Voluntary' Meets Fail-Safe

·8 min read

On April 7, 2026, NIST published a concept note for a new profile of its AI Risk Management Framework, this one aimed at critical infrastructure. NIST puts out a lot of these, and most of them land as voluntary guidance nobody is forced to read. This one is worth reading anyway, because it speaks in the vocabulary of functional safety rather than the language of models and outputs.

I wrote earlier this year about NIST’s AI Agent Standards Initiative, and I argued that its “voluntary” label is probably temporary because NIST guidance hardens through procurement, sector regulators, and litigation. I am not going to re-make that argument here. What is new in the critical infrastructure profile is not the voluntary question. It is the collision the document names: AI, especially machine learning and large language models, is probabilistic, while operational technology and industrial control systems are engineered for the opposite. They are built to behave the same way every time, and to fail into a safe state when they cannot.

That collision is the point of the profile, and it is a different risk problem from agent identity and autonomy.

What the profile is

The concept note is short. Raymond Sheh and Martin Stanley of NIST’s Information Technology Laboratory wrote it, and it announces an AI RMF Profile on Trustworthy AI in Critical Infrastructure. A profile, in NIST’s vocabulary, is an implementation of the AI RMF’s functions for a particular setting. The Generative AI Profile from July 2024 did this for content-generating systems. The new one does it for critical infrastructure, and it says so across three domains in one breath: information technology, operational technology, and industrial control systems.

The stated purpose has two parts. First, guide critical infrastructure operators toward specific risk management practices for AI-enabled capabilities. Second, help them communicate their trustworthiness requirements to teams, developers, and other stakeholders across the AI and CI lifecycles and supply chains. That second part matters more than it looks. The document is not only telling an operator how to assess its own AI. It is telling the operator how to write requirements into procurement, so the safety question travels up the supply chain to whoever built the model or the component.

NIST has stood up a Community of Interest, a mailing list plus a Slack, to feed the profile’s development, and it says discussion drafts and requests for information will follow. No release date is stated. Everything about the final profile is still open.

The language NIST chose

The concept note lists eight example AI systems a critical infrastructure operator might run, each tied to a trustworthiness feature. Some are what you would expect. Autonomous cybersecurity incident-response agents with tested and validated guardrails. Plant monitoring hardened against adversarial input. Diagnostic assistants that carry an “AI bill of materials” so their reasoning can be traced. Then the profile stops talking like a software document and starts talking like a safety document.

Autonomous robots and vehicles get “redundant safety and deterministic fail-safe controllers.” AI optimization is expected to “degrade gracefully.” Physics-informed neuro-symbolic systems are asked for “verifiable performance guarantees.” Those are not the words the AI RMF led with when NIST wrote it in 2023. The original framework was written to apply across AI systems generally, the ones that generate predictions, recommendations, or decisions, and NIST framed it as universal rather than tied to any one application. The profile that narrowed in on content-generating systems came later, the Generative AI Profile from July 2024. The words in this concept note come from a different tradition: functional safety, the discipline behind standards like IEC 61508, where a system is judged by whether it fails into a safe state.

The planned focus areas make it explicit. One is to address what the note calls “stringent requirements” for deterministic behavior, explainability, graceful degradation, and fail-safe operation. Another is adversarial robustness at every stage of the lifecycle. Another is the testing, evaluation, validation, and verification work the AI community calls TEVV.

NIST did not invent this framing. CISA and eight international partners published joint guidance on securing AI in operational technology in December 2025, and that document named the concrete failure modes. OT process models drift over time. Safety processes get bypassed. When you put a model that answers probabilistically next to a control loop that assumes determinism, the question is not whether the AI is clever. It is whether the whole system still meets its safety argument.

Where this sits

The profile does not arrive into a vacuum. Three adjacent documents frame it.

DHS released a Roles and Responsibilities Framework for AI in critical infrastructure in November 2024, assigning voluntary responsibilities to five roles across five areas, from cloud providers to civil society. CISA’s joint OT guidance came a year later. And in July 2025, the White House’s America’s AI Action Plan directed NIST to revise the AI RMF itself, and directed DHS to stand up an AI Information Sharing and Analysis Center for AI security threat intelligence.

None of these are regulation. There is no U.S. rule today that requires AI risk management in critical infrastructure. The European Union’s AI Act does classify AI used as a safety component in critical infrastructure as high-risk, and it attaches binding obligations. That contrast is worth keeping in mind. In the United States, all of this is guidance.

What is notable about the critical infrastructure profile is how directly it names its own procurement channel. Most NIST artifacts leave the “this will end up in your contracts” step implicit. This one says its job is to help operators “communicate their trustworthiness requirements” to the teams and developers across the supply chain. The procurement channel is written into the document rather than left as an implication.

The foundation is moving

There is a wrinkle worth naming, because it affects how seriously you can take the profile today. The AI RMF 1.0 is itself being revised. The same AI Action Plan that set up the AI-ISAC also told NIST to strip the framework of references to misinformation, diversity and inclusion, and climate change. The Biden-era executive order that produced the Generative AI Profile and the DHS framework, EO 14110, was rescinded.

So an operator is being asked to align to a profile layered on a framework that is being rewritten, under an administration that changed the ideological wrapper around the whole thing. The technical substance, determinism and fail-safe and TEVV, has been in the OT safety vocabulary for decades, and it is not going anywhere. The surrounding language and the enforcement posture are less stable.

What I take from it

My honest read is narrower than the way this will get written up.

The profile is a concept note, not a standard. Its subcategories do not exist yet, and neither does a timeline. It is voluntary. And there is real doubt about whether the organizations it targets can adopt even voluntary guidance. CSET’s October 2024 work found wide disparities between critical infrastructure providers within and across sectors, and many smaller OT operators lack the talent, funding, and data to operationalize a profile like this. It also found that AI-risk ownership inside organizations is often unclear, the “hot potato” problem where nobody is sure whether safety or security owns the model.

None of that means the profile is empty. It means the useful part is not the framework mechanics. It is the question the profile forces, and you can ask it today without waiting for the final document.

If you operate OT or ICS and someone wants to put an AI component into a loop, ask whether that component can state its behavior deterministically, fail into a safe state, and degrade in a way you can predict. Ask the vendor for the safety argument, the same way you would for a controller or a valve. If the answer is that the model is a black box and its behavior is probabilistic, that is not automatically a reason to reject it. It is a reason to treat it as a probabilistic component, which means the system around it, the interlocks, the trip settings, the human oversight, has to carry the safety burden the model cannot.

The profile is NIST saying out loud what the OT community has been saying for a while: you cannot bolt a probabilistic system onto a deterministic control loop and pretend the safety question looks the same as it does for a system whose worst failure is a wrong answer. The collision itself is old. The new part is that a framework document now names deterministic behavior, graceful degradation, and fail-safe operation as the terms a critical infrastructure profile should address. Operators who ask the determinism question now will have the answer in hand whether or not the final profile ever lands.

Sources

  1. AI Risk Management Framework — NIST
  2. Concept Note: AI RMF Profile on Trustworthy AI in Critical Infrastructure — NIST
  3. Concept Note (PDF): AI RMF Trustworthy AI in Critical Infrastructure Profile — NIST
  4. NIST AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0) — NIST
  5. NIST AI 600-1: Generative AI Profile (July 2024) — NIST
  6. Principles for the Secure Integration of AI in OT — CISA et al. (December 3, 2025)
  7. Roles and Responsibilities Framework for AI in Critical Infrastructure — DHS (November 14, 2024)
  8. Outlook on DHS Framework for AI in Critical Infrastructure — Morrison Foerster (January 9, 2025)
  9. Securing Critical Infrastructure in the Age of AI — CSET (October 2024)
  10. America’s AI Action Plan — The White House (July 23, 2025)