A director at a mid-size investor-owned utility recently asked her team to tell her where they stood on AI readiness. She got back three confident answers that contradicted each other. The planning group said they were ready because they had a data warehouse. The operations team said they were blocked because no one had touched the OT/IT integration. The compliance lead said the governance policy didn't exist yet. All three were correct, and that is the readiness problem in miniature.

Why Readiness Matters Before the Roadmap

The utility sector has no shortage of AI enthusiasm. Vendors promise dramatic accuracy gains. Consultants arrive with slide decks full of 5-15% CAPEX deferral projections. But a utility that buys an advanced forecasting platform before it has reliable AMI data integration, or deploys a topology-optimization tool before its operators trust the advisory layer, is not accelerating its AI journey. It is accumulating expensive shelfware.

Readiness assessment is not a bureaucratic checkpoint. It is the difference between a pilot that validates real value and a pilot that fails because the foundation was not there. EPRI's work on utility AI maturity provides a useful framing: organizations move through stages from ad hoc (isolated experiments, no data standards) through repeatable (documented workflows, data pipelines tested) to optimizing (continuous model monitoring, governance embedded in operations). Most utilities in 2026 are between ad hoc and repeatable. The ones succeeding are not necessarily the largest or the most technology-forward. They are the ones that diagnosed their actual gaps before signing the contract.

This lesson gives you a structured readiness assessment across four domains: data, OT/IT integration, workforce, and governance. Each domain has observable indicators, not abstract scores. By the end, you will be able to walk into your own organization and produce a gap map that is honest enough to defend in a board conversation or a rate-case proceeding.

Domain One: Data Readiness

Every AI application in a utility depends on data that is accessible, labeled, and historically consistent. The specific data requirements vary by use case. A day-ahead load-forecasting model needs interval meter data, weather correlates, and historical load shapes going back at least three years, preferably five or more. A predictive maintenance model needs sensor readings from assets, maintenance records, and failure logs. A queue-study acceleration tool needs the interconnection application documents, system models, and historical study results. What unites them is that the data must be findable, trustable, and connected.

When assessing data readiness, start with three questions. First: where does the data live? Many utilities have operational data that was never designed to leave the system that created it. EMS (Energy Management System) historians, ADMS (Advanced Distribution Management System) logs, GIS (Geographic Information System) records, OMS (Outage Management System) event histories, and billing databases are often built and maintained by different teams, on different update cycles, with different identifier conventions for the same physical asset. Before any AI model can be trained, someone has to build and maintain the joins. That is not trivial work, and its cost is often invisible until the project is mid-stream.

Second: is the data labeled and historically consistent? Training data is only as good as its labels. If your outage database uses a dozen different codes for "equipment failure" depending on which dispatcher was on duty, a classification model trained on that data will inherit the inconsistency. If your load data has gaps during the 2022 AMI rollout that were never back-filled or flagged, a forecasting model will not know to treat those periods with suspicion. Data quality audits are not glamorous, but they are the single most underestimated cost in a utility AI implementation.

Third: has the utility recently acquired a large new load? This question matters because of what has happened to load curves since 2023. Utility-reported forecasts compiled by Grid Strategies (2025) project peak demand growth of roughly 166 GW over five years, with about 90 GW attributed to data centers. Independent analysts caution these figures may be overstated by up to roughly 40 percent due to double-counting of project announcements, so treat them as a forecast range rather than a settled fact. Regardless of where actual demand lands, a utility that added a 300 MW hyperscale campus in the last two years has data that looks nothing like its training history. Any AI model inherited or purchased without accounting for that step-load will produce forecasts that a planner cannot trust. This is not a model failure; it is a data-framing failure.

Data Maturity Indicators

A useful rule of thumb: if you can answer the following questions from a single system query without manually joining spreadsheets, your data maturity is at the repeatable level or above. Can you pull the last 12 months of interval load by feeder, weather-correlated and gap-annotated, in under an hour? Can you identify every asset where sensor data exists in both the EMS historian and the GIS asset record, with consistent identifiers? Can you produce a training dataset for a predictive maintenance model without a manual data-cleaning project? If any of these takes a week or more, you have a data infrastructure gap that will limit every AI project you attempt.

Domain Two: OT/IT Integration

The OT/IT boundary is where utility AI ambition most often collides with operational reality. OT, meaning Operational Technology, encompasses the systems that directly interface with physical grid equipment: the SCADA (Supervisory Control and Data Acquisition) system, the EMS, protection relay firmware, RTU (Remote Terminal Unit) firmware, and the communication networks that carry real-time telemetry. IT encompasses the enterprise systems: the data warehouse, the analytics platform, the cloud environment where the AI model may run. These two worlds were deliberately separated for safety and reliability reasons, and that separation has profound implications for any AI application that touches real-time operations.

NERC CIP-003-9, which became enforceable April 1, 2026, specifically addresses vendor electronic remote access and supply-chain security for low-impact BES (Bulk Electric System) Cyber Systems. CIP-012-2 (effective July 1, 2026, adding availability to the confidentiality and integrity protections of the prior CIP-012-1) protects real-time data communications between control centers. These are not compliance checkboxes that a vendor can clear for you. They define the architecture of what data can move where, at what latency, under what controls. An AI model that trains on yesterday's data in a cloud analytics environment has a very different compliance footprint than an AI model that receives real-time EMS telemetry and returns switching recommendations on a 10-second cycle. The second case touches the OT boundary directly, and the CIP obligations follow.

In practice, most utility AI deployments in 2026 are deliberately kept in the advisory lane: the model sees data that has been one-step removed from the live control system, and its outputs are displayed to a human operator as a recommendation, not executed automatically. This is a sound architecture for the current maturity level, and it is consistent with the cardinal rule of this program: reliability accountability stays human. But even the advisory architecture requires a tested data pipeline from OT to IT, and that pipeline must be designed, monitored, and maintained as a reliability-critical system.

When assessing OT/IT integration readiness, ask: does a tested, documented, monitored data pathway exist from your EMS historian to the analytics environment where AI models run? Who owns that pathway and has authority to change it? What is the latency and what does the model need? Has a security review been completed for that pathway under the current CIP standards? The absence of a clear, documented answer to any of these is a gap.

Domain Three: Workforce Readiness

The technology conversation in utility AI tends to crowd out the workforce conversation, and that is a strategic error. The Great Crew Change is real: more than 25% of utility workers are retirement-eligible within the next few years, taking decades of grid expertise with them. EPRI projects 30% or more growth in digital and analytical roles through 2030. These two trends are happening simultaneously, which means the workforce challenge is not just about hiring AI specialists. It is about capturing what the outgoing generation knows and translating it into the structured knowledge that AI systems can use, while also building the human judgment capacity that AI systems cannot replace.

Workforce readiness has three dimensions. The first is AI literacy: can the people who will use AI outputs read them critically? A load forecaster who accepts an AI day-ahead forecast without checking the uncertainty band, the step-load blind spot, and the weather sensitivity is not using the tool correctly. An operator who trusts a topology-optimization recommendation without understanding what N-1 (the ability of the system to withstand the loss of a single element) contingency the model was optimizing for is creating a safety gap. AI literacy is not deep technical skill. It is the ability to interrogate an AI output as a smart, skeptical expert in the domain the output is about.

The second dimension is change readiness. Control rooms and planning departments that have worked the same way for twenty years do not change overnight, and they should not be asked to. Resistance to AI advisory tools is not a problem to overcome through mandate. It is a signal that the tool is not yet trusted, the workflow has not been designed carefully, or the people closest to the work have not been included in the design. Honest readiness assessment includes asking operators and planners: what would it take for you to trust this recommendation? What failure mode would cost you the most? The answers are design requirements, not objections to manage.

The third dimension is specialized capacity: does the utility have, or can it access, people who understand model validation, data pipeline architecture, and AI governance? These are not roles that need to exist in every team, but they need to exist somewhere in the organization, with clear scope and authority. The most common failure mode is a utility that hires an AI vendor, buys a platform, and then discovers no one internally understands what the model is doing or how to verify it. When the model starts drifting, no one notices until it produces an embarrassing or costly error.

Domain Four: Governance Readiness

Governance is the least visible readiness dimension and the one most likely to create a problem in a regulatory setting. A utility that deploys AI without clear policies for model validation, human override, documentation, and accountability is not just taking a technology risk. It is taking a regulatory risk. When a commission asks how the AI-assisted forecast was validated before it drove a capital investment, or what the human review process was for the switching recommendation that preceded an outage, the utility needs a documented answer. "We trusted the platform" is not an answer.

Governance readiness means: does a written policy exist that defines what categories of AI application require what level of human review before outputs are used in a decision? Does that policy specify who has the authority to approve a new AI application touching operations, compliance, or regulatory filings? Does it require model documentation, including training data provenance, validation metrics, and drift monitoring? Is there a clear incident response process for when an AI output is discovered to have been wrong in a consequential way?

In the absence of enterprise AI policy, individual teams fill the vacuum with their own practices, which creates inconsistency and audit risk. A planning team that has quietly built strong verification discipline can be sitting in the same utility as an operations team that has none. From a regulatory perspective, the inconsistency itself is a vulnerability.

Governance readiness does not require a sophisticated AI ethics framework before you can start. It requires a minimum viable policy: a documented approval process, a documentation standard, a verification requirement, and a named responsible party. That minimum viable policy can be built in weeks, and it should exist before any AI application reaches production, no matter how small the pilot.

Building a Readiness Gap Map

A gap map is not a score. Scores give false precision and invite gaming. A gap map identifies specific, observable gaps in each domain and ranks them by their impact on the AI use cases the utility wants to pursue in the next 12 to 24 months.

The format that works in a board or executive conversation is a two-column table: gap, and what it blocks. A missing data integration pipeline between the EMS historian and the analytics platform blocks real-time advisory AI. A missing AI governance policy blocks any production deployment and creates regulatory exposure. A workforce with no AI literacy training blocks operators from using outputs correctly. A CIP-compliant data pathway that has not been security-reviewed blocks any use case that touches OT-sourced data.

Prioritize gaps that block the highest-value use cases and that create compliance or regulatory risk if unaddressed. Do not try to close all gaps before starting. The goal is to understand which gaps you can route around with careful pilot design and which ones must be closed before any deployment is responsible.

A readiness gap map is not a reason to delay. It is a sequencing tool. The utility that knows its gaps can work around them intelligently. The utility that does not know its gaps discovers them expensively, mid-project.

Worked Example: A Mid-Size IOU Runs the Assessment

Consider a mid-size investor-owned utility with roughly 800,000 customers, a service territory that recently received a 250 MW data center interconnection application, and a CEO who has publicly committed to deploying AI in operations within two years. The AI-readiness lead has been asked to produce a gap map in 30 days.

She starts with data. She asks the load forecasting team whether they can produce a five-year training dataset for the AI forecasting platform they are evaluating. The answer is: mostly yes, but the AMI data has a 14-month gap from 2022 and the data center's interim load profile before the new connection energizes is not in the system. She documents: "AMI gap 2022, data-center step-load profile not available. Blocks supervised forecasting model training. Mitigation: document and flag gap to vendor."

She turns to OT/IT integration. She discovers the EMS historian sends a daily export to the data warehouse, but the export was never designed for AI use: identifiers do not match GIS, some fields are truncated, and there is no monitoring to detect failures. She documents: "EMS historian export pipeline not validated for AI use. Blocks any real-time or near-real-time use case. Requires pipeline rebuild and CIP security review. 60-day effort."

On workforce, she surveys the operations and planning teams and finds that three planners have done informal AI experimentation and one has completed external training. The control room has had no AI exposure at all. She documents: "AI literacy gap in control room. Blocks operator acceptance of advisory tools. Mitigable with targeted training before pilot launch."

On governance, she finds no written AI policy. She documents: "No enterprise AI policy. Blocks production deployment. Creates regulatory exposure. Requires policy drafting and executive approval. 30-day effort with legal and compliance."

Her gap map shows four gaps, two of which (governance policy and pipeline rebuild) need work before a pilot launches and two of which (AMI gap documentation and AI literacy training) can be addressed in parallel with a carefully scoped pilot. The CEO gets an honest picture, a timeline, and a sequenced plan. That is the output of a readiness assessment done correctly.

Key Takeaways

• Readiness assessment across four domains, including data, OT/IT integration, workforce, and governance, prevents expensive mid-project failures and creates the foundation for defensible AI deployment in a regulated utility.
• Data readiness means reliable, historically consistent, accessible data pipelines, not just data that exists somewhere. The data-center step-load problem makes historical consistency a live issue for any utility that has added large new loads since 2022.
• OT/IT integration is where AI ambition meets physical-system reality. CIP-003-9 (vendor electronic remote access and supply-chain security for low-impact BES Cyber Systems) and CIP-012-2 (availability added to inter-control-center data protections) define the compliance boundary; every data pathway from OT to the analytics environment needs to be designed, documented, and security-reviewed against those standards.
• Workforce readiness is not about hiring data scientists. It is about building AI literacy in the people who will use AI outputs and capturing the domain expertise of the workforce that is retirement-eligible before it leaves.
• Governance readiness means a minimum viable policy: documented approval processes, verification requirements, documentation standards, and named accountability. It must exist before any AI application reaches production use.
• A gap map is a sequencing tool, not a delay mechanism. It identifies which gaps block which use cases and which can be mitigated while work proceeds, enabling an informed conversation with leadership and regulators.
• The EPRI maturity framing (ad hoc, repeatable, optimizing) provides a useful benchmark. Most utilities in 2026 are between ad hoc and repeatable. The goal is not to be optimizing before you start; it is to know which stage you are in for each domain and what the next step is.