AI for Grid Operations & Utilities: Deploying Under NERC CIP
How utilities deploy AI for grid operations within NERC CIP: outage prediction, DER orchestration, BES cyber asset boundaries, and cleared-adjacent talent.
Utilities can deploy AI for grid operations under NERC CIP by keeping models outside the Electronic Security Perimeter — feeding them through read-only historian mirrors, returning advisory outputs that operators act on, and never letting AI write to a BES Cyber System — which preserves nearly all of the value of outage prediction, vegetation analytics, and DER orchestration while avoiding the compliance burden of classifying the AI stack itself as a BES Cyber Asset.
That single architectural decision — advisory AI outside the perimeter, humans inside it — separates the utilities shipping AI to production from the ones stuck in eighteen-month compliance reviews. This article maps AI use cases to CIP impact ratings, shows the architectures that work, and covers the supply-chain and audit obligations that follow.
NERC CIP Essentials for AI Teams: What Gets Classified and Why It Matters
NERC's Critical Infrastructure Protection standards don't mention artificial intelligence anywhere. They regulate systems — and the first question any regional entity auditor will ask about your AI deployment is whether it created, touched, or became a BES Cyber System.
The classification chain works like this:
- CIP-002 requires entities to identify and categorize every BES Cyber System as high, medium, or low impact using bright-line criteria: control center function, facility size, and reliability impact. High impact applies to systems at control centers performing real-time Bulk Electric System functions; anything not high or medium defaults to low. Categorization must be reviewed and approved by the CIP Senior Manager at least every 15 calendar months.
- CIP-005 defines the Electronic Security Perimeter (ESP) — the network boundary around BES Cyber Systems — and controls every Electronic Access Point through it, including vendor remote access sessions, which must be identifiable and terminable.
- CIP-007 imposes systems security management on everything inside: patch evaluation cadences, ports-and-services baselines, malware prevention, and security event logging.
- CIP-011 protects BES Cyber System Information (BCSI) — network diagrams, security configurations, ESP details — wherever it lives, including in the training data or context window of a model.
The implication for AI is blunt. A model server placed inside the ESP that can affect a BES Cyber System within 15 minutes becomes a BES Cyber Asset itself — inheriting patch-management timelines that no PyTorch dependency tree can meet, configuration baselines hostile to iterative ML development, and change-control processes that turn a model refresh into a governance event. A GPU inference stack is close to unmanageable under a CIP-007 baseline regime, and no reliability benefit justifies attempting it for advisory analytics.
The good news is equally blunt: an AI system that only reads replicated data and only produces recommendations for humans is not performing a real-time BES function, and with correct architecture it stays outside CIP's most demanding scope entirely. The 2024 revisions to CIP-004-7 and CIP-011-3 even opened the door to storing BCSI in cloud environments with documented access provisioning and risk assessment — a meaningful shift for utilities weighing on-prem versus cloud AI deployment for their analytics stack.
Safe Deployment Patterns: Advisory AI Outside the ESP, Operators Inside the Loop
Three patterns recur in every successful CIP-compatible AI architecture we see utilities deploy.
1. Read-only historian mirrors. SCADA and EMS data flows one direction: from the operational historian inside the ESP, through a controlled replication path (a DMZ historian replica, or a unidirectional gateway/data diode for higher-assurance environments), into a corporate-network analytics zone. The AI stack — feature pipelines, model training, inference — lives entirely in that analytics zone. Nothing in the AI environment holds credentials to anything inside the perimeter. When an auditor asks "can this system affect the BES?", the answer is a network diagram, not an argument.
2. Advisory outputs, never control outputs. The model predicts feeder-level outage probability, ranks vegetation spans by strike risk, or forecasts DER output — and delivers those predictions to dashboards, work-management systems, and storm-room briefings. It does not write setpoints, issue switching orders, or command breakers. If a prediction should change grid state, an operator makes that change through the existing, already-certified EMS/ADMS tooling. This is human-in-the-loop design applied not as a UX preference but as the compliance boundary itself.
3. Operator-in-the-loop with recorded rationale. Mature programs log which advisories operators accepted, overrode, or ignored. That record does double duty: it's the feedback loop that improves the model, and it's the evidence that demonstrates to a regional entity that AI informs — rather than performs — real-time operations.
The compliance question is never "is the model accurate?" It's "what can this system touch, and what happens in the worst 15 minutes if it's compromised?" Architect so that the honest answer is "nothing and nothing," and the path to production gets dramatically shorter.
Utilities extending into agentic workflows — LLM-driven assistants that summarize alarms, draft switching plans for review, or triage outage tickets — should treat the agent layer with the same rigor. Our guide to agentic AI security covers the tool-permission and prompt-injection risks that matter most when an agent sits anywhere near operational data.
High-Value AI Use Cases for Grid Operations That Clear the Compliance Bar
The use cases below share a property: they consume mirrored operational data and act through people or through distribution-level systems outside CIP scope. That's why they reach production.
Storm outage prediction. Models that fuse weather forecasts, historical outage records, GIS, and asset-condition data can forecast outage likelihood and severity 24-72 hours ahead of a storm, letting utilities pre-stage crews and materials where damage will concentrate. EY reports that its outage-prediction work with Eversource Energy — integrating weather patterns, SCADA, GIS, and vegetation insights — helped avoid roughly 40,000 customer outages in a two-month span. The same EY survey research found that while 73% of utility executives and employees report using AI, only 18% say it has met expectations — a gap that in our experience traces to pilots built without a path through compliance.
Vegetation management from imagery. Tree contact remains a leading cause of outages and a wildfire-ignition risk. Computer-vision models over LiDAR, satellite, and drone imagery score span-level encroachment and growth risk, converting cycle-based trimming into risk-based targeting. National Grid's data-driven vegetation program has been credited with a roughly 30% reduction in tree-related events and 38% fewer customer interruptions. Imagery pipelines have the cleanest CIP posture of any grid AI use case — the input data isn't BCSI and the output is a work plan.
DER and VPP orchestration. Forecasting and dispatching distributed energy resources — rooftop solar, batteries, managed EV charging — is where AI moves closest to actual control. The saving grace: DER management systems and virtual power plant platforms generally operate at the distribution level, outside the Bulk Electric System definition, though utilities should watch aggregation thresholds as FERC Order 2222 participation scales. AI-driven DER forecasting also feeds directly into the net-load problem we cover in depth in AI load forecasting for utilities.
CIP-013 Supply Chain Risk Applied to AI Vendors and Model Providers
CIP-013 requires a documented supply chain cyber security risk management plan for procurements associated with high and medium impact BES Cyber Systems — vendor risk identification, procurement-stage security requirements, controlled and revocable remote access, and incident notification obligations. Applied to AI vendors, the plan should interrogate questions most ML companies have never been asked:
- Software integrity and provenance. Can the vendor verify the integrity and authenticity of what they ship — including model weights? Where were models trained, on what data, and who had access to the training pipeline?
- Update and retraining cadence. Model updates are software updates. How are they signed, tested, and disclosed? Can the utility pin versions and validate before promotion?
- Remote access. Does the vendor's platform require persistent connectivity into utility environments? Sessions must be identifiable, monitored, and terminable — "the model phones home for telemetry" is a finding waiting to happen.
- Fourth-party exposure. Which foundation-model APIs, hosting providers, and data subprocessors sit behind the vendor's product?
Strictly, an advisory AI stack kept fully outside the BES Cyber System boundary may fall outside CIP-013's mandatory scope. In practice, prudent utilities apply the same diligence to any vendor touching operational data — because the audit conversation is easier when the answer is "we assessed them under our plan anyway."
Evidence and Audit Posture: Documenting AI Systems for Regional Entity Audits
CIP compliance is an evidence regime. When your regional entity audits, the AI program should be able to produce, without scrambling:
- A scoping memo stating why the AI system is not a BES Cyber Asset — data flows, network placement, and the absence of any 15-minute-impact pathway — reviewed on the same cadence as your CIP-002 categorization.
- Architecture diagrams showing the replication path, the analytics zone, and every boundary between the AI stack and the ESP.
- A BCSI handling assessment covering training data, prompts, retrieval corpora, and logs under CIP-011 — including any cloud storage justification.
- Vendor risk assessments for AI suppliers under the CIP-013 plan, with procurement-stage security language.
- Operational records: model versions, change history, advisory logs, and operator accept/override decisions. Utilities that treat this as operational observability rather than paperwork get the model-improvement flywheel for free.
Auditors don't penalize utilities for using AI. They penalize utilities that can't explain what a system touches, who approved it, and where the evidence lives. A well-documented advisory AI program is an easier audit conversation than a poorly documented spreadsheet macro.
Why Utilities Staff These Builds with Vetted Contract Engineers
The talent profile this work demands barely exists on the open market: engineers fluent in ML pipelines and OT data (PI historians, CIM models, GIS) and the compliance instincts to architect around an ESP rather than through it. Utilities that post a requisition for that profile wait months and compete with tech-sector compensation they can't match — for a build phase that ends.
The economics favor a different model. The intensive work — historian mirror, feature store, models, operator tooling, audit evidence package — is a 6-18 month spike. What remains afterward is operation and retraining, which existing teams can own if they've been trained alongside the build. That's why utilities increasingly staff these programs with senior contract engineers on C2C arrangements rather than multi-year hires, a trade-off we break down in AI staff augmentation vs. hiring.
This is the model Gain America runs. We maintain a bench of vetted, senior AI engineers who have delivered in regulated, critical-infrastructure environments — engineers who embed with grid operations and compliance teams as forward-deployed engineers, architect for the audit from day one, and transfer ownership on the way out. For the broader energy-sector picture — from load forecasting to trading analytics to field operations — see our pillar guide to AI consulting for energy and utilities.
The utilities winning with AI under NERC CIP aren't the ones that found a loophole. They're the ones that took the boundary seriously, architected advisory systems that respect it, and brought in people who had done it before.
Frequently asked questions
Can AI models run inside a NERC CIP Electronic Security Perimeter?
Technically yes, but almost no utility should start there. Any system inside the ESP that meets BES Cyber Asset criteria inherits the full weight of CIP-005, CIP-007, and CIP-010 controls — patching cadences, ports-and-services baselines, and change management that most ML stacks cannot satisfy. The proven pattern is to keep AI outside the ESP, feed it through one-way replicated historian data, and return advisory outputs that an operator acts on through existing EMS/ADMS tools.
Does using a cloud LLM or ML platform violate NERC CIP?
Not inherently. CIP obligations attach to BES Cyber Systems and to BES Cyber System Information (BCSI), not to AI as a category. The 2024 revisions to CIP-004-7 and CIP-011-3 explicitly accommodate BCSI in cloud environments when access is provisioned and risk-assessed correctly. The compliance question is what data leaves your environment: de-identified weather, imagery, and asset-condition data are usually fine; one-line diagrams, ESP network details, or security configurations are BCSI and require documented protection.
Does CIP-013 apply to AI vendors and foundation model providers?
If the AI product or service will be associated with high or medium impact BES Cyber Systems, yes — your supply chain cyber security risk management plan must cover it in procurement. That means assessing the vendor's software integrity and authenticity controls, remote access practices, incident notification commitments, and increasingly the provenance of model weights and training pipelines. Advisory AI that stays fully outside the BES Cyber System boundary may fall outside strict CIP-013 scope, but most utilities apply the same diligence anyway because auditors ask.
What AI use cases deliver value for utilities without touching the BES?
Storm outage prediction, vegetation management from LiDAR and satellite imagery, load and DER forecasting, work-order and outage-ticket intelligence, and DER/VPP orchestration at the distribution edge. These consume operational data through read-only mirrors and act through humans or through distribution systems that sit outside CIP scope, which is why they routinely reach production while control-room automation projects stall in compliance review.
Why do utilities staff CIP-adjacent AI builds with contract engineers instead of hiring?
Because the build is a spike, not a steady state. Standing up the historian mirror, the ML pipeline, the operator-facing advisory tooling, and the audit evidence package is 6-18 months of specialized work that combines ML engineering with OT and compliance fluency — a profile utilities struggle to hire and rarely need permanently. Vetted contract engineers who have shipped in regulated critical-infrastructure environments deliver the build, train internal staff, and roll off, leaving the utility to operate what it owns.
Build it with Gain America
Gain America staffs and deploys the engineers behind enterprise AI — from data center teams to forward deployed engineers.
Talk to our team