Artificial intelligence is moving from business software into power, water, transportation, manufacturing, buildings, healthcare, and other environments where digital decisions can affect physical operations. NIST’s 2026 work does not introduce a finalized “AI RMF 2.0.” Instead, it begins development of a critical-infrastructure profile for the existing NIST AI Risk Management Framework (AI RMF), while the broader framework remains under revision. [1] [1]
What NIST actually released in 2026
On April 7, 2026, NIST released a concept note for an “AI RMF Profile on Trustworthy AI in Critical Infrastructure.” The proposed profile is intended to help infrastructure operators identify practical risk-management measures for AI-enabled capabilities and communicate expectations to developers, vendors, and supply-chain partners. [1] [2]
This distinction is important:
- AI RMF 1.0 remains the current framework. NIST released it on January 26, 2023.
- The critical-infrastructure profile is still being developed. It is not a final standard, regulation, certification, or mandatory checklist.
- The broader AI RMF is intended for voluntary use.
- NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan. [1] [1]
Accordingly, organizations should treat the 2026 concept note as a strong signal of NIST’s direction—not as proof that new controls have already become legally compulsory.
Why critical infrastructure requires a different AI risk lens
Traditional IT failures may cause downtime, inaccurate information, or data loss. Operational technology (OT) failures can also affect physical processes, public safety, the environment, and essential services.
NIST describes OT as programmable systems and devices that monitor or directly control the physical environment. Examples include industrial control systems, building automation, transportation systems, water and wastewater systems, and industrial Internet of Things equipment. [2] [3]
Critical infrastructure is also highly interconnected. NIST characterizes it as a “system of systems” in which sectors and business partners depend on one another. A disruption in one infrastructure can therefore create cascading effects elsewhere. [2] [3]
That changes the central AI governance question. It is not enough to ask whether a model is accurate in a laboratory. Operators must also ask:
- What physical process can the system influence?
- What happens if its inputs are manipulated?
- Can an operator understand and reject its recommendation?
- What happens if the model, cloud service, vendor connection, or communications link fails?
- Can the affected process continue safely without the AI system?
The four AI RMF functions still provide the foundation
The proposed profile is built around the existing AI RMF’s lifecycle approach:
Govern
Organizations establish accountability, policies, risk tolerance, and decision rights. For critical infrastructure, governance should clearly identify who can approve AI use in safety-sensitive or time-critical environments.
It should also define responsibilities among asset owners, control-room operators, cybersecurity teams, safety engineers, AI developers, vendors, and incident responders.
Map
Teams document the AI system’s purpose, operating context, dependencies, affected stakeholders, potential harms, and limitations.
For infrastructure operators, mapping should extend beyond the model. It should include sensors, data pipelines, communications links, cloud services, control interfaces, human workflows, legacy equipment, and downstream physical processes.
Measure
Organizations test and evaluate whether the AI system performs reliably and securely in its intended environment. NIST’s concept note emphasizes rigorous testing, evaluation, validation, and verification—often abbreviated as TEVV—throughout the lifecycle. [1] [2]
Testing should include degraded sensors, unusual operating conditions, distribution shifts, adversarial inputs, connectivity loss, model changes, and operator disagreement. A successful demonstration under normal conditions is not evidence that a system is safe during an emergency.
Manage
Organizations prioritize risks, implement safeguards, monitor performance, respond to incidents, and update or retire systems as conditions change.
For critical infrastructure, management should include explicit stop conditions. Operators need to know when to suspend AI recommendations, revert to an earlier model, switch to manual operation, or isolate a compromised component.
What trustworthy infrastructure AI could look like
NIST’s concept note provides examples of possible systems and trustworthiness features. These examples are proposed areas for consideration, not requirements already imposed by NIST. [1] [2]
They include:
- Cybersecurity agents with tested and verified guardrails for autonomous incident response.
- Facility and plant monitoring systems hardened against adversarial inputs and monitored for conditions outside validated operating regions.
- Diagnostic assistants that provide traceable, auditable rationales and maintain an AI bill of materials.
- AI systems that use physics-informed or otherwise verifiable methods to help predict and maintain system stability.
- Autonomous robots and vehicles using multiple sensors, redundant safety systems, and deterministic fail-safe controllers.
- Digital twins used to support distributed facilities during emergencies.
- Optimization systems that degrade gracefully and transparently while alerting human supervisors.
- Explainable compliance and risk-monitoring systems that retain human oversight.
The common theme is bounded autonomy. AI may assist or automate selected tasks, but the surrounding system must define its authority, verify its behavior, and provide a safe response when confidence or operating assumptions break down.
Determinism, explainability, and graceful degradation
NIST identifies several needs that are particularly demanding in critical infrastructure:
- Deterministic behavior: systems should behave predictably within defined operating conditions.
- Explainability: operators and engineers should be able to understand the basis and limits of recommendations.
- Graceful degradation: loss of an AI capability should reduce functionality without causing an unsafe collapse.
- Fail-safe operation: faults should move the process toward a safe condition.
- Adversarial robustness: systems should withstand or detect manipulation of data, sensors, inputs, or interfaces. [1] [2]
These requirements align with NIST’s separate OT guidance. The OT guidance says safety, protection, and time-critical control functions should generally remain capable of local operation, with documented fallback, fail-safe behavior, and tested recovery procedures. [2] [3]
In practice, graceful degradation may mean moving from full automation to supervised automation, then to increasingly manual modes. NIST’s OT guidance treats this as a core resilience principle because momentary downtime in a physical process may be unacceptable. [2] [3]
The practical implications for infrastructure operators
1. Inventory AI beyond standalone models
An AI inventory should include embedded vendor features, optimization tools, computer-vision systems, predictive-maintenance applications, agentic software, digital twins, and AI components inside control or monitoring platforms.
The inventory should record:
- System owner and vendor
- Purpose and operational location
- Data and sensor inputs
- Outputs and connected systems
- Level of automation and authority
- Human approval points
- Model and software versions
- Cloud, communications, and supply-chain dependencies
- Failure modes and fallback procedures
2. Separate advice from authority
A diagnostic assistant that recommends an inspection is not equivalent to an agent that can alter a process. Risk assessments should distinguish between systems that inform people, systems that initiate approved actions, and systems that can directly affect physical operations.
The greater the system’s authority and the more severe the consequences of failure, the stronger the requirements should be for authorization, redundancy, monitoring, testing, and human intervention.
3. Test the whole operational system
Model-level accuracy metrics are insufficient. Testing should cover the model, data sources, sensors, interfaces, permissions, network dependencies, operator displays, escalation procedures, and recovery mechanisms.
Relevant scenarios include:
- Corrupted or manipulated sensor data
- Loss of cloud or vendor connectivity
- Communications outages
- Model updates that change recommendations
- Adversarial inputs
- Unexpected environmental conditions
- Conflicting signals from redundant systems
- Human rejection of an AI recommendation
- Transfer to manual or local control
4. Require evidence from suppliers
Vendors should be able to explain what their systems do, where they were tested, what assumptions they make, how changes are managed, and how customers can disable or constrain automated actions.
Contracts and procurement reviews should address model updates, incident notification, logging, access control, data use, vulnerability disclosure, support during outages, and responsibilities for shared supply-chain risks.
5. Preserve local and manual recovery paths
NIST’s OT guidance recommends considering local operation, documented fallback, fail-safe behavior, tested recovery, redundancy, analog backups where appropriate, and out-of-band management. [2] [3]
These measures are particularly relevant when AI depends on external cloud services, remote vendors, wireless networks, or centralized data pipelines. An AI system should not become an invisible single point of failure for a safety-critical process.
What the 2026 work does not mean
The concept note does not establish a new binding federal regulation. It also does not mean that every critical-infrastructure operator must immediately deploy the specific examples listed by NIST.
The final profile may change after input from infrastructure operators, vendors, regulators, researchers, and other stakeholders. NIST is seeking practical information about use cases, OT and ICS governance challenges, legacy systems, supply-chain issues, and gaps in existing guidance. [1] [2]
The uncertainty is therefore material: the direction is clear, but the final scope, terminology, implementation details, and relationship to sector-specific requirements are not yet settled.
A sensible 2026 preparation plan
Organizations do not need to wait for the final profile to improve their controls. A practical starting sequence is:
- Identify every AI capability connected to operational, safety, security, or business-critical systems.
- Classify systems by consequence, authority, connectivity, and ability to affect physical processes.
- Document operating boundaries, including validated conditions, prohibited actions, and stop criteria.
- Establish human-oversight points with named personnel and realistic response times.
- Test fallback and manual procedures under representative conditions.
- Evaluate suppliers and dependencies, including cloud, communications, data, and model providers.
- Create AI-specific incident scenarios for exercises and recovery planning.
- Track model, software, configuration, and data changes throughout the system lifecycle.
- Monitor NIST’s profile development and update internal requirements when a draft or final version is published.
Bottom line
NIST’s 2026 initiative is best understood as a move toward infrastructure-specific AI risk management—not as the release of a completed new framework. The proposed profile applies the AI RMF’s lifecycle structure to environments where reliability, safety, physical consequences, legacy technology, and cascading failures matter.
For critical-infrastructure organizations, the key lesson is straightforward: trustworthy AI must remain bounded, observable, testable, explainable, and recoverable. An AI deployment is not ready merely because its predictions are accurate. It is ready when operators can show what the system may do, detect when its assumptions fail, intervene when necessary, and keep essential operations safe without it.