Trustworthy AI requirements for critical infrastructure mapped to SWT3 procedures and industry profiles. Covering all 16 CI sectors.
Who this is for: Critical infrastructure operators, CISOs, AI risk managers, NIST AI RMF practitioners, and sector-specific regulators. Applicable to Energy, Water, Healthcare, Financial Services, Telecom, Defense, and Transportation sectors.
On April 7, 2026, NIST released a concept note for an AI RMF Profile on Trustworthy AI in Critical Infrastructure. This profile moves the AI Risk Management Framework from broad guidance toward sector-specific, implementation-ready requirements for operators of critical infrastructure.
The profile focuses on managing risks where AI-enabled decisions have physical-world safety consequences. Key focus areas include:
The profile initially targets Energy, Water, Healthcare, and Financial Services, but applies to all 16 critical infrastructure sectors identified in Presidential Policy Directive 21 (PPD-21).
Each NIST CI profile requirement maps to SWT3 procedures that generate cryptographic witness anchors as compliance evidence.
| NIST CI Requirement | SWT3 Procedures | What Is Witnessed | AI RMF Function |
|---|---|---|---|
| Deterministic behavior | AI-PERF.1 + AI-ROBUST.1 | Performance metrics against declared accuracy; robustness under perturbation | MEASURE 2.5, 2.6 |
| Explainability | AI-EXPL.1 + AI-EXPL.2 | Feature attribution explanations; calibrated confidence scores | MEASURE 2.5 |
| Graceful degradation | AI-SAFE.1 | Safe state transition with trigger code, actions suspended, recovery status | MANAGE 4.1 |
| Fail-safe operation | AI-SAFE.1 + AI-INCIDENT.1 | Emergency stop capability; incident classification and notification | MANAGE 3.2, 4.1 |
| Adversarial robustness | AI-ROBUST.1 + AI-SEC.1 + AI-REDTEAM.1 | Perturbation survival; adversarial threat detection; red team campaign results | MEASURE 2.6 |
| Model lineage | AI-MDL.1 + AI-MDL.5 + AI-SBOM.1 | Model weight integrity; file hash verification; component inventory | MANAGE 1.3, GOVERN 1.5 |
| Supply chain risk | AI-SUPPLY.1 + AI-ENV.2 | Supplier compliance assessment; dependency manifest with vulnerability count | MEASURE 3.1 |
| Continuous monitoring | AI-DRIFT.1 + AI-PMM.1 | Model drift detection; post-market monitoring attestation | MEASURE 2.6, MANAGE 4.1 |
| Human oversight | AI-HITL.1 + AI-HITL.2 | Human review completion; override event with reason and outcome | MANAGE 2.2 |
| TEVV | AI-PERF.1 + AI-ROBUST.1 + AI-REDTEAM.1 | Performance benchmarks; robustness testing; adversarial campaigns | MEASURE 2.5, 2.6 |
| Inference provenance | AI-INF.1 | Prompt/response hash capture with model identifier | GOVERN 1.7 |
| Audit traceability | AI-AUDIT.1 | Tamper-evident audit log integrity verification | GOVERN 1.7 |
| Cybersecurity posture | AI-CYBER.1 | Security assessment against recognized frameworks (NIST CSF, ISO 27001) | MANAGE 2.2 |
| Hardware attestation | AI-HW.1 + AI-ENV.1 | GPU/accelerator inventory; runtime environment hash | MANAGE 1.3, GOVERN 1.2 |
NIST CI requires: AI systems in critical infrastructure must support graceful degradation and fail-safe operation. When AI components fail or produce unreliable outputs, the system must transition to a safe state without catastrophic consequences.
How SWT3 addresses it: witnessSafeState() records the trigger (manual, threshold, chain break, policy, external), the number of actions suspended, and whether a recovery mechanism is available. This creates an auditable record of every safe state transition across the infrastructure.
AI-SAFE.1 anchors prove stop/interrupt mechanisms exist and have been exercised. The trigger_code field shows whether transitions were proactive (threshold) or reactive (chain_break). Recovery_available confirms the system can resume operations after safe state.
NIST CI requires: Heightened adversarial robustness in all lifecycle stages. Critical infrastructure AI must withstand noise, corruption, missing data, out-of-distribution inputs, and targeted adversarial attacks.
How SWT3 addresses it: Three procedures create a layered defense evidence chain. witnessRobustness() records perturbation testing results. witnessSecurityScan() detects adversarial inputs at runtime. witnessRedTeam() documents structured adversarial test campaigns. Together they prove robustness is tested proactively, detected at runtime, and validated through red team exercises.
AI-ROBUST.1 anchors show perturbation types tested and survival rates. AI-SEC.1 anchors show runtime threat detection is active. AI-REDTEAM.1 anchors show adversarial campaigns were conducted with documented scope and findings.
NIST CI requires: Tracking the origin and training data of AI models. Organizations must map AI dependencies and model lineage across the supply chain.
How SWT3 addresses it: witnessModelIntegrity() verifies the deployed model hash matches the approved registry. witnessModelWeights() captures the SHA-256 hash of weight files. witnessSbom() documents all model components, data sources, and dependencies. The result is a complete provenance chain from training data to deployed weights.
AI-MDL.1 anchors prove model identity is verified at deployment. AI-MDL.5 anchors prove weight file integrity. AI-SBOM.1 anchors provide the complete component inventory. Cross-reference with AI-SUPPLY.1 for third-party supplier compliance status.
SWT3 provides pre-built industry profiles that implement the NIST CI requirements for each sector. Each profile pre-selects the relevant procedures, clearing level, and trust mesh configuration.
Profile: autonomous-systems (CL2, 16 procedures, strict trust mesh)
Key: AI-SAFE.1 for grid failover, AI-PERF.1 for load forecast accuracy, AI-DRIFT.1 for seasonal model decay
swt3 init --profile autonomous-systems --tenant YOUR_UTILITY
Profile: autonomous-systems (CL2, 16 procedures, strict trust mesh)
Key: AI-SAFE.1 for treatment failover, AI-INCIDENT.1 for contamination alerts, AI-ENV.1 for sensor attestation
swt3 init --profile autonomous-systems --tenant YOUR_UTILITY
Profile: healthcare-clinical (CL3, 15 procedures, strict trust mesh)
Key: AI-EXPL.1/2 for clinical explainability, AI-HITL.1/2 for clinician oversight, AI-FAIR.1/3 for diagnostic equity
swt3 init --profile healthcare-clinical --tenant YOUR_HEALTH_SYSTEM
Profile: fintech-model-risk (CL2, 16 procedures, strict trust mesh)
Key: AI-AUTO.1 for automated credit decisions, AI-FAIR.1/3 for fair lending, AI-DRIFT.1 for model decay
swt3 init --profile fintech-model-risk --tenant YOUR_INSTITUTION
Profile: telecom-compliance (CL2, 19 procedures, strict trust mesh)
Key: AI-TRANS.1 for FCC transparency, AI-PERF.1 for network model accuracy, AI-SAFE.1 for network failover
swt3 init --profile telecom-compliance --tenant YOUR_CARRIER
Profile: defense-govcon (CL3, 16 procedures, hardware attestation required)
Key: AI-HW.1/3 for hardware attestation, AI-SBOM.1 for supply chain, AI-REDTEAM.1 for adversarial testing
swt3 init --profile defense-govcon --tenant YOUR_PROGRAM
The NIST CI profile emphasizes rigorous TEVV as a continuous process, not a one-time gate. Three SWT3 procedures map directly to TEVV activities:
| TEVV Phase | SWT3 Procedure | What Is Witnessed | Cadence |
|---|---|---|---|
| Testing | AI-REDTEAM.1 | Adversarial test campaign scope, findings, severity | Quarterly or pre-deployment |
| Evaluation | AI-PERF.1 | Performance metrics against declared benchmarks | Weekly or per-batch |
| Validation | AI-ROBUST.1 | Robustness under perturbation, edge cases, noise | Monthly or post-update |
| Verification | AI-MDL.1 + AI-MDL.5 | Model identity and weight file hash match approved registry | Every deployment |
Each TEVV activity produces a SWT3 Witness Anchor with a cryptographic fingerprint. The anchors are independently verifiable and create a continuous evidence chain that auditors can query by time range, procedure, or model.
NIST is creating a Trustworthy AI in Critical Infrastructure Profile Community of Interest and welcomes participation from across the critical infrastructure ecosystem, including operators, developers, researchers, and standards bodies.
The SWT3 protocol's UCT Registry (191 procedures across infrastructure and AI governance) provides a structured vocabulary for Community of Interest participants to reference when discussing trustworthiness requirements.
Registry: sovereign.tenova.io/registry
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup