A utility that operates bulk electric infrastructure cannot treat an AI policy the way a tech company does. When the system prompts a topology optimizer, initiates a switching recommendation, or drafts a compliance narrative, the downstream consequence is not a bad product recommendation or a misfiled ticket; it is potentially a N-1 contingency violation, a CIP audit finding, or an unserved load event. The enterprise AI policy for a reliability-critical organization is not a technology document. It is a reliability document that happens to govern technology.

Why a Single Policy Must Span Planning, Ops, Markets, and OT

Many utilities arrive at AI governance by department. The planning team writes its own rules about how forecasters may use generative AI. The control room issues a memo reminding operators that switching decisions require human confirmation. The market operations group quietly discovers that its day-ahead bidding support tool uses a model trained on a different utility's price curve. Each team is governing something, but the result is a patchwork that creates three categories of unacceptable risk.

The first is inconsistency across the reliability boundary. A policy that tells planning to "use AI as a starting point and verify outputs" but has no parallel rule for control-room advisories means the same model inference can flow, unverified, from a planning workstation into a display that an operator uses to make a real-time dispatch decision. The EMS (Energy Management System, the real-time system that tracks state estimation, automatic generation control, and contingency analysis) and the ADMS (Advanced Distribution Management System, the distribution-grid equivalent) both consume data that originates in planning and market workflows. A policy gap upstream becomes a reliability gap downstream.

The second risk is the regulatory surface problem. NERC compliance is not audited by department. When a compliance lead opens the evidence binder for a CIP audit or a reliability standard review, the question is whether the registered entity's practices held. If the OT team is governed by a strict CIP-compliant AI-use restriction and the planning team is not, the audit may find a gap between what the entity asserts and what it practices.

The third risk is vendor contract exposure. A utility that signs a contract with an AI vendor under the planning department's authority may discover that the vendor's data pipeline routes through infrastructure that sits inside the Electronic Security Perimeter (ESP) as defined under CIP-005 or handles real-time telemetry subject to CIP-012-2. Without a policy that governs AI procurement across OT and IT together, the entity creates an obligation it did not intend to create and may not catch until an audit.

The solution is a single enterprise AI policy structured as a tiered framework: universal principles that apply everywhere, functional-area rules that apply to specific domains (planning, operations, markets, OT), and a use-case register that records every deployed AI system against both layers.

The Five Universal Principles

Regardless of function, every AI system a utility deploys or uses should be evaluated against five non-negotiable principles. These principles are not aspirational; they are the minimum viable governance floor for a reliability-critical organization.

Reliability First

Any AI system that can influence, directly or indirectly, the operation of the bulk electric system must be designed and operated so that its failure mode does not create a reliability risk. "Advisory only" is the default classification for operational AI. A model that recommends a switching action is advisory; a model that executes a switching action is a different class of system requiring a different class of governance. No AI system moves from advisory to autonomous without a documented reliability review, a simulation-verified failure-mode analysis, and explicit senior leadership approval.

Human Accountability Stays Human

The operator who confirms a switching recommendation, the planner who signs the load forecast, the compliance lead who certifies the evidence narrative: these humans are accountable. The policy must make this explicit, because it is the single most important cultural statement the enterprise can make about AI. "The model recommended it" is not a defense in front of a NERC examiner, a state commission, or a federal court. Every AI-assisted decision that results in a material action must have a named, traceable human owner.

Source Verification Before Action

AI systems, including large language models, retrieval-augmented systems, and ML forecasting models, can produce outputs that are factually incorrect, selectively biased by training data, or confident about claims they cannot support. The policy must require that any AI output used to support a material decision (a procurement commitment, a rate-case filing, a compliance certification, a load-shedding sequence) be verified against an authoritative source before it drives action. The authoritative source is the tariff, the standard, the asset record in GIS, the SCADA telemetry, or the engineering model book. It is never the AI's own prior output.

Transparency and Auditability

Every material use of AI must be logged: which system, which version, which inputs, which outputs, which human reviewed it, and what action followed. This is not optional overhead; it is the audit trail that lets the utility answer a regulator's question, reconstruct an incident, and detect when a model has drifted from its validated performance. The logging requirement applies equally to a generative AI tool used to draft compliance narratives and to a ML model used to produce a day-ahead load forecast.

OT/IT Boundary Discipline

The IT network and the OT network are governed by different standards, different risk tolerances, and different failure consequences. An AI system that operates inside or adjacent to the OT environment, including any system that reads real-time telemetry from SCADA, EMS, or ADMS, is subject to CIP requirements. The policy must define where the OT boundary is, who owns the determination of whether a given AI system crosses it, and what the approval process looks like for any AI deployment that touches the OT side.

Functional-Area Rules: Planning, Operations, Markets, and OT

The universal principles set the floor. Functional-area rules provide the operational detail that makes the policy workable for the people who actually use these systems every day.

Planning

In the planning domain (Integrated Resource Planning, transmission planning, interconnection studies, rate-case support), AI is principally used for forecast generation, document drafting, and study automation. The functional rule for planning is: every AI-generated number that flows into a filed document or a capital decision must carry a source citation and a human-verified sign-off. The planner's name goes on the forecast, not the model's name. When a planning AI produces a 10-year load forecast, the policy requires the responsible engineer to document the model version, the training data vintage, the holdout-test result, and the specific assumptions about load growth drivers (including any data-center interconnection assumed). If the forecast is filed in a rate case, that documentation becomes part of the discovery record.

Operations

In grid operations (EMS-side, control-room, ADMS-driven distribution automation), AI is used primarily as decision support. The functional rule for operations is: advisory AI systems must be visually and procedurally distinguished from authoritative SCADA displays and automatic control systems. The operator's confirmation step must be explicit, logged, and mandatory. No switching recommendation, no restoration sequence, and no load-shedding priority list produced by an AI system may be acted on without a named operator's documented confirmation. If the AI system is down, the operator works without it; the AI system is not in the critical path for grid reliability.

Markets

In market operations (day-ahead and real-time energy markets, capacity markets, ancillary services bidding), AI is used for price forecasting, portfolio optimization, and settlement support. The functional rule for markets is: any AI output that influences a market bid or a settlement claim must be reviewed by a qualified market professional before submission. The market rules under FERC jurisdiction require that bids reflect the entity's honest assessment of costs and capabilities; an AI-generated bid that misrepresents costs or capabilities creates both regulatory and financial exposure. The policy must specify that market-operations staff are trained to recognize AI output patterns that may reflect training-data artifacts rather than current market conditions.

OT (Operational Technology)

In the OT environment, AI is used for predictive maintenance, anomaly detection, cybersecurity monitoring, and increasingly for advisory optimization on distribution and transmission assets. The functional rule for OT is: no AI system may be deployed in or adjacent to the OT environment without a CIP-scoped review that addresses electronic security perimeter implications, supply chain risk (CIP-013), and real-time data protection obligations under CIP-012-2. The OT functional rule is the most restrictive because the consequences of a failure here are the most severe. An AI system that produces a wrong recommendation in a planning workbook costs rework time. An AI system that produces a wrong output in an OT context, or that provides an adversary a vector into the OT environment, can result in a controlled area violation with physical consequences.

The Use-Case Register: Governance in Practice

A policy is only as good as its implementation. The mechanism that connects the policy to day-to-day reality is the use-case register: a living document that records every AI system the utility deploys, evaluates, or accesses, mapped against the policy framework.

A well-structured use-case register contains, for each deployed system: the system name and vendor (or "internal"), the functional domain it serves, the data it accesses (including whether it touches real-time OT data), the tier of use (advisory, decision support, or autonomous), the reliability review status, the CIP review status, the human accountable for oversight, the version currently in production, the last validation date, and the next scheduled review date. This register is not a bureaucratic artifact. It is the primary tool the enterprise uses to answer the question "what AI systems are running, and who is accountable for each one?"

A key discipline of the use-case register is the sunset clause. Every AI system that is registered should have a defined review cycle. A forecasting model that was validated against 2023 load data should be re-validated when the data-center load surge produces a measurably different load shape. A generative AI tool that was approved for compliance narrative drafting should be reviewed when the underlying model version changes. Without a sunset clause, the register becomes a graveyard of approved-but-stale systems, and the policy's transparency requirement is hollow.

The AI system that disappears from the use-case register is the one that creates audit exposure. Every shadow AI deployment is a policy violation waiting to be discovered.

Policy Enforcement and the Governance Committee

An enterprise AI policy that lives in a shared drive without an enforcement mechanism is not a policy; it is a document. Enforcement requires an AI Governance Committee (as discussed elsewhere in this level) with explicit authority to approve, suspend, or require remediation of AI deployments. The committee's authority is most visible in two enforcement moments.

The first is the deployment gate. No new AI system enters production without committee approval. The committee's review includes the functional-area rules, the CIP review (for any system touching OT), and the reliability review (for any system touching operations). This gate is not optional for "small" or "low-risk" AI tools. A generative AI tool that seems low-risk in an administrative context can become a high-risk tool if a staff member routes real-time SCADA data through it as a "quick summary." The gate review forces the question of what data the tool can access.

The second enforcement moment is the incident response trigger. When an AI system produces an output that is materially incorrect and that output reaches a decision point, that is an AI incident. The policy should define the incident classification (similar to the way NERC events are classified by severity), the notification requirement, the investigation process, and the remediation pathway. An AI incident that produces a reliability event should trigger the same level of organizational response as any other reliability event.

Enforcement also requires a training requirement. Every employee who uses, supervises, or approves AI outputs in a material workflow must complete the training program that covers the policy, the use-case register, and the verification discipline. The training is not a one-time orientation; it recurs at a defined interval and is updated when the policy changes.

Worked Example: The Policy Failure That Becomes a CIP Finding

Consider a regional transmission organization where the interconnection study team adopts a generative AI drafting tool to speed up the production of study reports. The tool is approved by the planning manager under the informal "low-risk, advisory use" standard. The tool is connected to a shared drive that contains, among other things, a folder of operational switching procedures that include real-time status tags from the EMS historian.

A compliance auditor reviewing the tool's data access permissions discovers that the shared drive includes files from the control-room systems folder. The tool has not executed any switching actions; it has only read files. But the data it read included real-time control system data that the entity's CIP program categorizes as protected. The tool's vendor contract does not include the CIP-013 supply chain security provisions that the entity's OT security plan requires for systems that access protected data.

The result is a potential CIP-013 finding and a broader question about whether the entity's AI governance program is adequate. The actual harm is minimal: the tool was advisory, no operational decisions were compromised, and no data was exfiltrated. But the finding is real because the policy gap is real. There was no deployment gate, no CIP review, and no use-case registration for a tool that the planning team characterized as "just a writing assistant."

The lesson is not that AI writing assistants are dangerous. The lesson is that the classification decision is the governance decision. A policy that requires every AI system to be registered and every system touching potentially protected data to receive a CIP review would have caught this before deployment. The policy gap, not the tool, created the finding.

Connecting Policy to the Standards Clock

The enterprise AI policy does not exist in a static regulatory environment. The 2026 standards clock creates specific pressure points that a well-governed utility should embed directly into its policy review cycle.

NERC CIP-003-9, enforceable as of April 1, 2026, extends baseline cyber security management controls to low-impact BES Cyber Systems, including transient devices and remote access management. The policy implication is direct: any AI system that accesses, stores, or transmits data from low-impact BES Cyber Systems must now be evaluated against CIP-003-9 requirements. Many utilities have treated low-impact assets with lighter governance than high-impact assets. The CIP-003-9 enforcement date is the moment when that distinction disappears for the purposes of AI deployment review.

CIP-012-2, the version effective July 1, 2026, protects the real-time monitoring and control data transmitted between control centers and adds explicit availability requirements for those communication links. This standard is critical for AI deployments that use real-time operational data as inputs, because the standard's obligations apply to the communications infrastructure over which that data travels, regardless of whether an AI system is reading the data at the endpoint. A utility that deploys an AI anomaly-detection system at a control center boundary must work through its CIP-012-2 compliance team to confirm that the new data flow does not create an obligation gap.

The Computational Load Entity (CLE) registry, committed for December 31, 2026, creates a new category of registered grid actor for large compute loads. For the AI governance policy, the CLE registry means that the utility's large data-center customers may soon carry NERC reliability obligations of their own. The planning team's AI-assisted load forecasting models will need to account for the dispatch flexibility and reliability obligations that CLE-registered loads bring. The policy should include a provision that the use-case register for planning AI tools is reviewed against NERC registration changes at least annually.

The FERC large-load rulemaking on loads over 20 MW is reshaping interconnection procedures, tariff provisions, and the nature of the planning studies that utilities must complete for new large-load customers. DOE requested that FERC act by April 30, 2026; FERC issued an Order on April 16, 2026 (Docket RM26-4-000) committing to finalize the rule by the end of June 2026. The AI tools that utility engineers use to support interconnection studies will need to be validated against the new study requirements that the FERC rule introduces once finalized. A policy that does not connect its use-case revalidation cycle to regulatory change events will leave the utility running AI tools against obsolete procedures.

Connecting the policy to the standards clock requires a simple but often missing discipline: the AI Governance Committee's review calendar must include a regulatory-monitoring feed. When a new standard becomes enforceable, or when a significant FERC order changes interconnection procedures, the committee should trigger a targeted review of the affected use-case register entries. This is not a full policy rewrite; it is a targeted audit of the specific deployments that the regulatory change touches.

Key Takeaways

• An enterprise AI policy for a reliability-critical utility must span all four functional domains (planning, operations, markets, OT) under a single, consistent framework; departmental policies create audit gaps and reliability inconsistencies.
• The five universal principles (reliability first, human accountability, source verification, transparency, and OT/IT boundary discipline) are the non-negotiable floor; functional-area rules provide the domain-specific detail.
• The use-case register is the primary implementation mechanism: every deployed AI system must be registered with a named human owner, a CIP review status, and a validation review date; unregistered deployments are a policy violation.
• The deployment gate, requiring committee approval before any AI system enters production, catches the "just a writing assistant" classification error before it becomes a CIP finding.
• Enforcement requires an AI Governance Committee with real authority, a defined AI incident classification and response process, and a recurring training requirement for all users of material AI workflows.
• "The model recommended it" is never a defense in a control room, a rate case, or a NERC audit; every AI-assisted decision that results in a material action must have a named, traceable human owner.
• Policy sunset clauses and revalidation cycles are not bureaucratic overhead; they are the mechanism that catches model drift before a stale forecast drives a capital decision or a compliance failure.