NIST AI RMF for critical infrastructure operators

Enterprise IT is where most critical infrastructure operators first encounter AI: email triage, document processing, security analytics, helpdesk assistants and forecasting tools running on corporate networks and cloud accounts. These systems look like ordinary software, so teams often skip the governance steps the AI RMF expects. Govern and Map carry the most weight here, because the first task is deciding which tools count as AI, who owns them and what data they touch. Measure then follows the usual IT pattern of testing and monitoring, adjusted for model drift and output quality. Manage covers decommissioning and vendor changes.

• Inventory first: Many AI features arrive inside existing SaaS products, so the AI inventory required under GOVERN 1 must be built from procurement and identity records, not only from project lists.
• Data flows: MAP 4 asks teams to map third-party data, models and software, which is where IT systems often reach into operational data.
• Measure in production: Monitoring for performance shifts and misuse belongs in existing security operations tooling where possible.
• Third-party change control: MANAGE 3 expects monitoring of vendor controls and pre-trained models, including when a vendor silently updates a model.
• Bridge to OT: Any IT system that feeds an operational decision must be mapped as a dependency, since its failures can reach industrial processes.

Confirm which AI features your IT vendors enable by default and whether your contracts give you notice of model changes.

In operational technology and industrial control systems, AI typically supports process optimization, anomaly detection, predictive maintenance or operator decision support close to physical equipment. The consequences of error are physical, and availability often outranks every other characteristic. Govern and Map come first because operators must define the safety boundary, the human role in control decisions and which functions the AI may influence. Measure has to be designed around constraints that IT rarely faces: testing cannot disturb live processes, and evaluation data may be sparse or drawn from abnormal conditions. Manage must define fallback behavior and the ability to deactivate the AI without disrupting control.

• Defined authority: MAP 3 requires documenting human oversight processes, which in OT means stating exactly when an operator can override or ignore an AI output.
• Test outside the live loop: Deployment-like testing often needs a non-production replica or a staged environment, which may be costly to maintain.
• Availability trade-offs: Monitoring agents and logging must not add latency or create new attack paths into control networks.
• Safe fallback: MANAGE 2 expects the ability to supersede or deactivate a system, which must be tested before it is needed.
• Rare-event evidence: Failure modes may appear only a few times a year, so Measure should combine historical incidents, simulation and expert validation.

Confirm with your engineering and safety teams which control loops an AI output can affect before defining any Measure metrics.

Some AI arrives embedded in equipment, such as protective relays, drives, sensors or vision systems, supplied by manufacturers. The operator usually cannot inspect training data, retrain the model or see its full internal behavior. The AI RMF still applies, but Govern 6 and Manage 3 carry more weight than usual because the operator depends on the supplier's testing and update practices. Map focuses on what the operator can know: the intended use, known limitations and the integration points. Measure is mostly external, relying on acceptance testing, operating data and vendor documentation, and Manage must plan for updates the operator did not request.

• Supplier evidence: Ask for documented test results, known limitations, and the vendor's own risk management practices for the embedded AI.
• Update control: Firmware or model updates may change behavior, so MANAGE 3 monitoring must cover version changes and rollback options.
• Contingency plans: GOVERN 6 calls for plans for failures in high-risk third-party AI, which may mean retaining a manual or legacy control path.
• Acceptance testing: Commission tests on site can serve as the operator's own MEASURE evidence where the vendor cannot provide it.
• Contract terms: Notice periods, disclosure of model changes and audit rights should be negotiated before procurement.

Confirm whether the vendor will disclose the AI's presence, version and update history in writing before the equipment is purchased.

The operator is the organization that runs the critical infrastructure and deploys the AI-enabled capability. Under Montana Code 2-10-205, the deployer of a critical artificial intelligence system that controls critical infrastructure facilities must develop a reasonable risk management policy after deployment, and that accountability cannot be handed to a vendor or consultant. The operator decides risk tolerance, approves go or no-go decisions, owns the operating controls for IT, OT and industrial control systems, and signs off on residual risk.

• Policy and risk tolerance: Approving the AI risk management policy, the risk tolerance and the criteria for deactivating a system.
• Accountable roles: Naming owners for each AI system across operations, engineering, security and safety teams.
• Operating controls: Running monitoring, change approval, incident response and human oversight on the live plant or network.
• Third-party oversight: Keeping authority over vendor AI, data and model updates in its own supply chain.
• Record ownership: Holding the inventory, decision records and approvals that a regulator or assessor will ask to see.

Before engaging anyone, confirm which risk decisions your board or executive team must approve and which records must remain under your own document control.

An implementation partner such as DeployOpen prepares the systems, documentation and evidence that support the operator's program, then hands them over. Under a fixed-scope engagement, the partner's work is defined in writing before it starts. The partner does not own the policy, does not accept residual risk and does not decide whether a system goes live. Its output is a set of prepared artifacts the operator reviews and adopts.

• System preparation: Configuring and hardening self-hosted platforms in the operator's own environment, including logging, access controls and segregation between IT and OT networks.
• Documentation drafts: Preparing system descriptions, data flow records, test plans and monitoring procedures for the operator to review.
• Testing: Running security and AI-focused tests, such as adversarial input testing, where scoped, and reporting findings to the operator.
• Handover: Delivering runbooks, configuration baselines and evidence collection steps that the operator's own staff can maintain.
• Limits of role: The partner does not issue reports, attestations or certificates.

Ask any partner to state in its scope which artifacts it prepares and which decisions remain with you.

An independent assessor or auditor tests the program against the criteria the operator chooses and reports its findings. The NIST AI RMF is voluntary and has no certification, so no assessor can issue a NIST AI RMF certificate. A commissioned audit or review against a different framework, such as ISO/IEC 42001, produces its own report under that framework's rules. Where a regulator or customer asks for an independent view, the assessor's scope and independence determine what its report can support.

• Scope agreement: Defining in writing which NIST AI RMF categories, subcategories or internal policy requirements are tested.
• Independence: Confirming the assessor did not design the controls it tests, which is a common reason an implementation partner and an assessor are kept separate.
• Testing method: Sampling records, inspecting configurations and observing live operation, then documenting results.
• Reporting: Issuing its own findings under its own terms, which the operator cannot rewrite.
• Cost drivers: Scope size, the number of systems and sites, and the depth of OT testing.

Confirm with any assessor what it will and will not certify, and who receives its report.