The US and EU Are Converging on the Same Requirements for AI Agents in Critical Infrastructure

On 7 April 2026, NIST released a concept note for a new profile of its AI Risk Management Framework: Trustworthy AI in Critical Infrastructure. It is not yet a finished standard. It is a signal — and the signal is precise.

Read the document's list of what trustworthy AI in critical infrastructure requires: tested and verified guardrails for autonomous AI agents. Traceable, auditable rationales for every recommendation. Hardened systems monitored against adversarial input. Deterministic fail-safe controllers. Graceful degradation with alerts to human supervisors.

Now read the EU AI Act's requirements for high-risk AI systems in critical infrastructure: automatic logging of every event, causal reconstructability for human oversight, tamper-evident records retained for a minimum of six months.

Now read NIS-2's requirements for essential entities: forensic evidence for 72-hour incident reporting, independent audit trails for third-party ICT providers, operational resilience demonstrated under stress.

Three frameworks. Three jurisdictions. One converging set of requirements.

The global regulatory baseline for AI agents in critical infrastructure is forming — faster than most enterprises have noticed.

What NIST is actually building

The AI RMF Critical Infrastructure Profile is not a new framework from scratch. It is an application of the existing NIST AI RMF — with its four functions of Govern, Map, Measure, and Manage — specifically to the operational realities of critical infrastructure: IT systems, Operational Technology, Industrial Control Systems, and the interfaces between them.

The concept note is explicit about what makes critical infrastructure different from other AI deployments. Deterministic behavior requirements. Explainability under stress. Graceful degradation. Fail-safe operation. Adversarial robustness across the entire lifecycle. And supply chain visibility — because in critical infrastructure, the AI system is rarely the only moving part.

These requirements are not aspirational. They reflect the operational reality of deploying AI agents in environments where a failure is not a user experience problem. It is a grid outage, a hospital system failure, a water treatment disruption.

The concept note names specific examples of AI systems that will fall under this profile: autonomous cybersecurity incident response agents with verified guardrails. AI-enhanced diagnostic assistants with traceable, auditable rationales. AI optimization systems that degrade gracefully and alert human supervisors when they do.

Every one of these examples requires the same underlying infrastructure: a governance layer that captures every action, traces every decision, and produces a verifiable record that predates any incident requiring investigation.

Why the convergence matters

The EU AI Act classifies AI systems in critical infrastructure as high-risk under Annex III. That classification triggers the full suite of Article 12 and 14 obligations: automatic logging, human oversight enabling, causal context capture, six-month minimum retention, tamper-evident records.

NIS-2 — already in force across the EU — requires essential entities operating critical infrastructure to maintain independent audit trails for third-party ICT providers, and to produce forensic evidence within 72 hours of a significant incident. For critical infrastructure operators using LLM-based AI agents, every LLM provider is a third-party ICT provider under DORA and NIS-2's definitions. The independent audit trail requirement is not optional.

NIST's emerging Critical Infrastructure Profile adds the US dimension to the same requirements: traceable rationales, auditable decision chains, verified guardrails, deterministic behavior where it matters most.

These frameworks were developed independently, in different jurisdictions, by different bodies, over different timelines. They are converging on the same answer because the problem is the same: AI agents acting autonomously in critical systems need to be traceable, auditable, and governable — at a level of rigor that no software-layer logging or provider-native console can provide.

This is not regulatory overlap. It is regulatory signal.

The specific challenge of critical infrastructure

Critical infrastructure AI governance is harder than enterprise AI governance for a structural reason: the systems involved are not monolithic.

A grid operator's AI agents operate across IT networks, OT systems managing physical assets, ICS components controlling industrial processes, and external APIs connecting to weather services, market data, and grid neighbors. An agent that optimizes load balancing reads from sensors, writes to control systems, communicates with trading platforms, and logs to enterprise systems — often simultaneously, often at machine speed.

Each of these systems has its own access controls, its own logging format, its own latency tolerance, and its own regulatory obligation. The IT layer may be governed under NIS-2. The OT layer may fall under sector-specific KRITIS regulation. The ICS components may be subject to safety standards that predate AI by decades.

None of these systems were designed to produce a unified, tamper-evident record of AI agent actions across all of them.

This is the critical infrastructure governance gap. It is not a gap any single system vendor can close — because no single system vendor owns the full stack. It requires a governance layer that sits outside all of them, in the data path between agents and the systems they act on, capturing every action before it reaches any individual system's logging infrastructure.

What the NIST document implies for vendors and operators

The concept note is addressed to critical infrastructure operators — but its implications run up the supply chain. NIST explicitly calls for guidance on AI and CI supply chains, and asks vendors to demonstrate trustworthiness requirements in an actionable way.

That means the governance infrastructure that satisfies a CI operator's NIST AI RMF obligations needs to be provable — not asserted. A vendor that claims its AI agents are governed cannot simply point to its own dashboard. The CI operator needs a record that is independent of the vendor, cryptographically verifiable, and available for inspection without the vendor's cooperation.

This is the same independence requirement that the EU AI Act imposes, that DORA imposes, that NIS-2 imposes. The governance record must be architecturally separate from the system being governed.

For AI agents in critical infrastructure, that requirement is not negotiable. The consequences of an unverifiable record are not a compliance fine. They are a failed forensic investigation during an operational incident — with regulators, courts, and potentially national security implications.

The window before this becomes mandatory

NIST's Critical Infrastructure Profile is in development. The EU AI Act's enforcement for critical infrastructure high-risk systems is August 2026. NIS-2 is already in force. The gap between what regulators expect and what most critical infrastructure AI deployments currently have is significant.

Critical infrastructure operators that treat AI governance as an infrastructure decision — not a compliance checkbox — are building the forensic capability before they need it. The ones waiting for the NIST profile to finalize, or for the EU AI Act enforcement deadline to force action, are building it under pressure.

The regulatory requirements are converging. The technical answer they are converging toward is already clear: traceable identity, causal context capture, deterministic policy enforcement, tamper-evident records — in a governance layer that is independent of the agents it governs and the systems they act on.

That infrastructure needs to exist before the incident that requires it. In critical infrastructure, that is not a recommendation. It is the point.