Arizona’s AI Docket Previews What Utilities Will Need To Prove

On March 24, 2026, the Arizona Corporation Commission opened Docket AU-00000A-26-0060, directing the state's regulated electric, gas, and Class A and B water utilities to detail how they're using artificial intelligence in planning, forecasting, storm response, and equipment procurement. A commission workshop later this year will bring in stakeholders and subject-matter experts to work through what's been filed. It's the first state-level inquiry of its kind, and it won't be the last.

What makes this docket different from the AI policy conversations utilities have been having for the past two years is that it isn't really a policy conversation. Rate recovery, cybersecurity, and algorithmic transparency are the headline categories, but underneath each one is an engineering question: What can a utility actually show a commission about how its AI systems work? Not what the system is supposed to do, but what it does, how that's logged, and who's accountable when it doesn't.

AI use in grid planning, forecasting, and operations.

There's no federal rulebook to fall back on here. FERC and NERC move at the speed of consensus, and consensus on operational AI is years away. State commissions move faster, and in utility regulation, the first framework written tends to become the template everyone else adopts.

That makes Arizona's docket less a compliance exercise than an open invitation: the record is empty, and whoever engages first has a hand in defining what “reasonable” looks like on rate recovery, cybersecurity, and transparency. Utilities that wait will be implementing rules written without their input.

What Counts as ‘Operational AI’

Part of what regulators will have to sort through is that “AI in utility operations” isn't one thing. Load forecasting and demand response models, predictive maintenance and asset-health algorithms (the kind used to flag a failing transformer before it fails), outage detection and restoration optimization, DERMS and grid-balancing algorithms, and cybersecurity anomaly detection are all “operational AI” in the loosest sense, and regulators will be right to scrutinize them differently.

Each pulls from different data inputs, fails in different ways, and needs a different audit trail. A load forecasting model that drifts leads to a bad procurement decision. A grid-balancing algorithm that drifts can produce a bad control action in real time. Any framework that treats those as the same risk category isn't going to hold up.

Cybersecurity Architecture: What Governance Means at the Systems Level

“AI governance” is an abstraction until you get to the systems level, where it means a handful of concrete things: access controls and network segmentation between AI systems and OT/SCADA environments; the attack surface introduced by the real-time data pipelines feeding those models; logging and rollback requirements for when a model output triggers a bad control action; and vendor risk, since most utilities are licensing these models rather than building them in-house.

Watching the network.

If a regulator asked me to name the single governance safeguard worth writing into a rule, it's this: mandatory human authority over any action that changes the state of the grid, backed by a complete, tamper-proof audit trail.

AI should operate freely at machine speed to monitor, detect, and recommend. But anything that actually changes grid state needs to trace back to a human decision or a human-approved protocol, and every step the system took needs to be logged and reviewable after the fact. That one requirement addresses the two failure modes that matter most: an AI system acting outside its authority, and nobody being able to reconstruct what happened afterward. You can't secure what you can't audit, and most of the other safeguards regulators will want to follow from that one.

Algorithmic Transparency Without Disclosing the Model Itself

This is where utilities tend to get nervous, and understandably so. Nobody wants to hand a roadmap to their model architecture or training data to a bad actor or to a competitor. But the transparency regulators actually don't require that.

There's a real middle ground here, and it looks a lot like practices grid engineers already follow. Explainability layers and decision logs (what inputs drove a given output) are different from disclosing full model architecture or training data, and only the former is necessary for accountability. Version control and change logs for retrained models are just model governance extended from the same change-management discipline utilities already apply to protection relay settings and SCADA logic changes. And third-party validation with a documented audit trail is the AI-era equivalent of the review processes already built into grid control system changes.

The line, in practice: regulators need to know what a system does, what decision authority it has, its performance record, and its audit trail. They don't need to know how it's built. NERC CIP already draws exactly this line for other categories of sensitive infrastructure detail—confidential filings and cleared review where warranted, full accountability for outcomes regardless.

Apply the same model here. “Proprietary” should never become the reason a utility can't answer for how a decision got made, but disclosure obligations shouldn't extend past what accountability actually requires, either.

Rate Recovery Mechanics: Capitalize or Expense?

This is the question with the least obvious answer, because AI doesn't fit either of the categories ratemaking was built around. Forcing it into one creates a bad incentive: ratemaking rewards capital investment, which pushes utilities toward on-premise, depreciable systems even when a cloud-based system would serve customers better.

The more useful frame is functional, not structural: AI performing an infrastructure role deserves infrastructure treatment, regardless of how it's delivered. Deployment can be capitalized. Retraining and ongoing monitoring are better treated as recurring costs, or the AI equivalent of maintenance on any other asset and not a software subscription line item. Recovery should follow the function a system performs, not the form factor in which it ships. How a utility classifies this early shapes both the rate case and the audit trail a commission will eventually want to see.

The human factor.

A Practical Framework: What to Build Before Your State Opens a Docket

Arizona won't be the only state doing this, and the utilities that will be in the best position when their own state opens a docket are the ones that didn't wait. Five things are worth having in place now:

1. Data provenance documentation: a clear record of what data trains and feeds each model, and where it came from.
2. Model validation and testing protocols: evidence that a system was tested before deployment and is being monitored after.
3. Network segmentation between AI systems and control systems: the architectural safeguard, not just the policy statement.
4. Change-log and versioning discipline: every retrain and update logged the same way a protection relay setting change would be.
5. A rate-recovery classification decision: made in advance rather than improvised during a rate case.

There's a sixth item that belongs on this list even though it's less technical: an actual inventory of every AI-enabled system in your operations. Most utilities are running more AI than their leadership realizes, embedded in vendor platforms, analytics tools, and control systems, often with no single owner accountable for what it touches. Building that inventory and standing up a governance policy around decision authority, auditability, and oversight is the fastest way to walk into a future docket with a working framework rather than scrambling to describe systems nobody has fully mapped.

One caution as more states inevitably follow Arizona's lead: a rule built around one state's grid, utilities, and market structure won't necessarily travel well to a state with rural cooperatives, a different resource mix, or a restructured market.

Prescriptive rules also age badly—AI capability shifts in months, rulemakings take years, and a rule that hardcodes today's technology becomes tomorrow's compliance theater. The rules worth adopting elsewhere will be the ones written as principles with human authority, auditability, accountability for outcomes, and not as a technical prescription.

The Real Question

Arizona's docket will run its course over the next several months, and its outcome matters less than what utilities do in the meantime. The question isn't whether to wait and see what Arizona decides. It's whether your AI systems are already documented and auditable to a standard a commission is eventually going to require—because that standard is coming, in Arizona or wherever your state's docket opens first.

All images used courtesy of Delta Energy & Communications.