Does every utility AI system require the same governance process?

No. The register should classify each system by intended use and consequence. An AI safety component used in operating electricity supply can fall within the EU AI Act's Annex III critical-infrastructure category. An internal assistant drafting a public procurement summary has a different risk path. Both need ownership and an approved purpose, while the depth of testing and monitoring, plus change control and escalation, should match the use. A shared intake form can collect the baseline facts without forcing one approval route onto every case.

Should operational technology traffic pass through an LLM gateway?

Only an architecture and safety review can approve that design. Traditional OT protocols and deterministic control commands sit outside an HTTP LLM policy gateway, along with local control logic. If an operational application makes an authenticated HTTP request to an LLM for advisory analysis, that model call can pass through a request policy point. The resulting recommendation still enters an operational process governed by engineering validation and safety interlocks, with operator authority and the site's change procedures.

What evidence should a utility retain for an LLM request?

Retain enough to reconstruct the decision under the organization's data and records rules. Common fields include the originating identity and calling application, followed by the approved purpose and prompt data classification. They also include the provider and model route, policy version and outcome, plus the timestamp and integrity information. Full prompt or response retention deserves a separate decision because it can create another store of sensitive operational or customer material. A reference or fingerprint may satisfy the evidence design for some uses.

How does NIST AI RMF apply to energy companies?

The framework supplies a voluntary structure for governing and managing AI risk. A utility can use Govern for accountability and policy, Map for the use case and operating context, Measure for testing and monitoring, and Manage for treatment and residual-risk decisions. NIST's 2026 critical-infrastructure profile project is intended to make that structure more specific for high-stakes infrastructure. Until NIST completes it, organizations should label the concept note accurately and avoid presenting draft work as a final standard.

Can request controls prove that a utility's AI is safe?

Request records prove a narrower event. They can show that a supplied identity sent classified content to a named model route under a specific policy and was allowed or received a block or redaction result. Safety also depends on system design and model evaluation, data quality and operational testing, protective controls and change management, plus qualified human decisions. An HTTP record supports investigation and governance review. It never certifies an operational system or replaces engineering assurance.

AI Governance for Energy and Utilities Starts with the Operating Boundary

A grid planning analyst sends a load forecast and substation notes alongside a proposed maintenance narrative to an LLM through an internal assistant. The governance decision happens before that HTTP request leaves the utility's application. AI governance for energy and utilities needs to identify the analyst, the approved purpose, the information in the prompt, and the model route. A green status light beside the chat box proves very little by itself. I would require separate approval for operational use and business assistance because the failure consequences and evidence needs differ sharply.

TL;DR

Separate safety-related operational AI from engineering and customer LLM use cases, as well as workforce LLM use cases. Each path needs its own owner and evidence.
Record the originating user or agent, purpose, data class, model route, policy version, and decision for every governed HTTP model call.
Apply NIST AI RMF practices across the lifecycle, then connect written controls to tests and executed records.
An HTTP policy gateway covers routed LLM traffic. OT control logic, native vendor AI, local models, IAM, and human approval remain separate controls.

The use-case register needs operational boundaries

The Department of Energy's October 2025 AI Compliance Plan describes an AI Governance Board that addresses research and development plus deployment and use across the department. It also gives trained and accountable officials responsibility to identify and assess risk, then mitigate and accept it at the lowest appropriate level. That is a useful pattern for a utility portfolio.

Begin with four distinct lanes. Operational AI can influence equipment or grid conditions. Engineering AI supports analysis without issuing control commands. Customer AI drafts or answers billing questions and service questions. Workforce assistants handle policy and procurement material, plus code and administrative material. Each register entry should name the business owner and technical owner, followed by the intended purpose and affected process. It should specify the data classes and model route, along with the approval authority. It should also identify the review cycle and the evidence repository.

A portfolio label such as "generative AI" hides too much. The register should show that a control-room advisory system and a customer correspondence assistant received different decisions for specific reasons. An AI governance operating model can define those decision rights across security and operations, with legal and business leadership.

Critical infrastructure use changes the review depth

The DOE assessment of AI for critical energy infrastructure identifies unintentional failure modes and adversarial attacks, along with hostile applications and software supply chain compromise, as broad risk categories. It also calls for risk-aware guidance that changes as the technology and sector experience develop. The assessment gives a utility governance board a practical reason to distinguish an LLM drafting outage communications from an AI component involved in grid operation.

NIST is developing an AI Risk Management Framework profile for critical infrastructure. The April 2026 concept note covers AI used across IT and operational technology, including industrial control systems, with safety and security plus reliability, capacity, and efficiency in scope. The profile remains under development, so utilities should describe it as current NIST work rather than a finished control catalog.

In the European Union, Annex III of the AI Act classifies AI used as a safety component in managing or operating critical digital infrastructure and road traffic, as well as supplies of water, gas, heating, or electricity, as high-risk. That classification turns on intended use. A meeting-summary assistant at the same utility sits outside that specific critical-infrastructure category.

Request policy connects purpose to data and destination

A utility's approved-use matrix should become executable policy wherever an application controls the LLM route. Consider an engineering assistant that summarizes equipment inspection notes. Its request can carry asset identifiers and location details, along with maintenance findings and operator comments. The application should supply the authenticated analyst or agent identity plus a purpose, with work context. The policy point can then evaluate the model destination and detected data class before forwarding the request.

A useful decision record names the originating principal and calling application, then the declared purpose and prompt classification. It records the provider and model route, policy version, outcome, and timestamp. Keep the retained content proportional to the evidence need and the organization's records policy. Fingerprints or references may be preferable when full prompt retention would create another sensitive repository.

This design makes a test concrete. An engineer with permission to summarize approved maintenance notes can receive an allow decision on the sanctioned route. The same identity sending credentials or restricted facility details to an unapproved endpoint can trigger a block or redaction. HTTP-layer AI policy enforcement explains the mechanics of evaluating the request that actually crosses the boundary.

Governance evidence should show control operation

The NIST AI Risk Management Framework organizes work through Govern, Map, Measure, and Manage. For an energy company, those functions should produce connected artifacts rather than four slide headings. Govern supplies accountable roles and policy. Map captures intended use and operating environment, along with affected people, infrastructure, and dependencies. Measure holds testing and monitoring results. Manage records treatment decisions and accepted residual risk.

I would ask for a compact evidence packet for each material use case:

Approval record: owner and intended purpose, with prohibited uses, data classes, and permitted model routes.
Route test: allowed and denied requests executed with named test identities under the effective policy version.
Change review: evaluation of a new model and connector, or a prompt template, data source, and operational dependency.
Monitoring sample: selected request decisions reconciled to the application inventory and incident process.
Exception record: scope and approving official, with compensating controls, expiration date, and closure result.

The packet should fit on a few screens and link to underlying evidence. A polished policy with no executed tests leaves the board unable to show that a rule operated. The AI governance audit framework covers that distinction in detail.

The control boundary must stay explicit

An external HTTP policy point can inspect authenticated user or agent traffic deliberately routed to an LLM. It can apply destination and content rules using identity and context supplied upstream. It can also record its own decision independently of the calling application.

Several energy-system controls sit elsewhere. Native AI embedded in energy management and asset management software, plus customer and productivity software, may use vendor-managed inference paths that a utility cannot redirect. Local model execution and offline analytics never cross an external HTTP gateway. Operational technology commands and protective relays, along with safety interlocks and industrial control logic, require sector-specific engineering and security controls. IAM establishes identities and entitlements before the request arrives. Human operators retain approval duties and operational accountability.

Put those exclusions on the architecture diagram. A dashed box around "AI governance platform" invites inflated claims. Named control points show which team owns each event. The HTTP gateway governs model traffic on its routed path. It supplies evidence to the wider program and leaves plant safety and model validation, vendor assurance and incident command, plus human review with their assigned owners.

DeepInspect

DeepInspect supports the routed HTTP portion of this program. It is a stateless proxy between authenticated users or agents and HTTP-based LLM endpoints. The calling application supplies identity and purpose context. DeepInspect evaluates that context with the prompt classification and destination, along with the role and versioned policy, before an allowed request reaches the model.

Each routed decision produces a signed, tamper-evident record for the request-control file. Native embedded AI and local execution, OT commands and IAM, plus model validation and human operational review remain outside that boundary. DeepInspect gives the governance team an enforceable decision point and independent evidence for the traffic it actually sees. Book a demo today.