Utility data isn't uniform. A protection-scheme setting and a monthly reliability summary can share the same spreadsheet columns and carry none of the same compliance weight. The rules draw lines around data. The tools are downstream of that.
Blocking AI is riskier than governing it. Governance requires knowing what the regulations actually say (about CEII, about NERC CIP, about BESS) and how AI coding assistants handle data at each tier.
§ 01CEII: Critical Energy Infrastructure Information
Governed by FERC under 18 CFR §388.113. Once data is designated CEII, withholding is mandatory; the FAST Act (16 USC §824o-1(d)) extends that protection to comparable state, tribal, and local disclosure laws. Recipients must sign NDAs, and information must carry FERC's standard CEII marking referencing 18 CFR §388.113.
The scope includes grid topology, substation configurations, protection scheme settings, and vulnerability assessments. Any transmission of CEII-designated data to an external AI platform, even one with enterprise data protections, could constitute an unauthorized disclosure unless that platform operates entirely within your network boundary.
That last sentence is the one that matters for AI architecture. It doesn't say "never use AI." It says the platform must operate within your boundary. That's an architecture problem.
§ 02NERC CIP: what applies, what's changing
Several existing NERC CIP standards directly govern how AI tools can operate in utility environments.
- CIP-013-2 (Supply Chain Risk Management). AI tool vendors are part of your supply chain. They must be assessed, documented, and monitored like any other vendor with electronic access to BES environments.
- CIP-005-7 (Electronic Security Perimeters). Network segmentation and access control. The boundary between AI-enabled development environments and OT networks must be explicitly defined and enforced.
- CIP-007 (System Security Management). AI interaction logs must feed into system event monitoring. Every query, every file read, every code generation, logged and auditable.
- CIP-010-4 (Configuration Change Management). AI-assisted configuration changes require the same change management controls as manual ones.
Two standards are new or expanding in 2025-2026.
- CIP-003-9 (effective April 2026): expanded governance requirements for low-impact BES Cyber Systems, including vendor electronic remote access controls. This is the standard that will require your AI acceptable use policy to be formalized.
- CIP-015-1 (FERC-approved June 2025): Internal Network Security Monitoring within Electronic Security Perimeters for high- and medium-impact BES Cyber Systems. Phased compliance runs through 2028–2031; confirm current dates against NERC's implementation plan posting before relying on them for audit planning.
None of these standards say "don't use AI." They say "protect specific categories of data and maintain auditable controls." Segmentation gets you CIP-005, and helps scope CIP-002. The rest needs orthogonal controls: CIP-013 requires vendor assessment of the AI provider itself, CIP-010 requires baseline and review of any AI-influenced configuration change, CIP-004 requires personnel authorization, and CIP-011 governs how CEII-adjacent information flows through prompts and retrieval systems. Part 03 maps each standard to a specific control surface.
§ 03BESS: the new compliance frontier
Standalone BESS at 20 MVA or above connected at 60 kV or higher now fall under NERC registration as Category 2 inverter-based resources (FERC Order 901, phased through 2026–2027). CIP applicability follows separately from CIP-002 impact classification; not every registered BESS lands in the high- or medium-impact tier. The IEEE 1547 revision currently in development is expected to add mandatory cybersecurity requirements at DER interfaces, building on the voluntary guidance in IEEE 1547.3-2023 and the limited cybersecurity provisions in the 2018 standard.
BESS data sensitivity isn't uniform. BMS firmware, charge/discharge control algorithms, and thermal management logic are safety-critical OT; compromise of a BMS can cause thermal runaway. That data stays air-gapped. Performance analytics, degradation tracking, and reporting dashboards are application code that can live in a far less restrictive zone.
§ 04How AI coding assistants handle your data
The data flow determines the architecture. Here's how it actually works.
An AI coding assistant reads files from your local machine, sends them to a cloud API for model inference, returns the result. Your code leaves your machine. That's the baseline. What varies, significantly, is what happens on the other end.
| Tier | What happens to your data |
|---|---|
| Consumer-tier | ChatGPT Free/Plus, Claude Free/Pro. Data may be retained for extended periods (up to five years for Anthropic's consumer tier with training opt-in; indefinitely for most OpenAI consumer and non-ZDR API products under the SDNY preservation order, which excludes Enterprise, Edu, and ZDR API) and used for model training by default. Not acceptable for any utility work involving sensitive data. |
| Enterprise API w/ ZDR | Zero Data Retention. The model processes your data for inference and discards it. Claude's API offers configurable ZDR. GitHub Copilot Enterprise provides similar protections. Minimum acceptable tier for general utility development. |
| Cloud-tenancy hosted | AI model inference runs entirely within your cloud tenancy. AWS Bedrock deploys Claude within your VPC. Azure AI Foundry provides tenant-level isolation. Google Cloud Vertex AI keeps inference within your GCP project boundary. Residual risk to account for: provider admin access, cross-tenant logging, subpoena exposure, and FedRAMP-scope gaps on specific model endpoints. |
| Self-hosted / air-gapped | Open-weights inference running on hardware you own, inside your existing security perimeter. vLLM, Ollama, llama.cpp, or Hugging Face TGI serving Llama, Qwen, or Mistral-class models. The required tier for CEII-adjacent code, BMS firmware work, and any data your compliance officer won't clear for any cloud provider's terms of service. |
Tiers 3 and 4 are what change the compliance calculus. When model inference happens inside your VPC, tenant boundary, or on hardware you own, the data flow stays within infrastructure you already monitor and audit. The AI becomes another compute workload inside your existing security perimeter.
Claude Code is one example of this architecture. It's a CLI tool that can point to Anthropic's direct API, AWS Bedrock, Azure AI Foundry, or GCP Vertex AI; it supports configurable deny rules as a best-effort filter against sensitive file patterns; it provides OS-level sandboxing through Linux bubblewrap and macOS seatbelt; and it logs interactions locally. Piped to a SIEM, those logs become the evidence base your internal audit team needs when an AI-assisted change triggers CIP-010 review. Other tools cover similar ground with different trade-offs: GitHub Copilot Enterprise, Cursor with self-hosted mode, and open tools like Continue or Cline pointed at on-prem models are all candidates for the corresponding tier.
Data flow is only half the problem. Inference introduces risks code review doesn't catch: prompt injection exfiltrating context, RAG sources poisoning outputs, hallucinated protection-relay settings that look plausible, confident citations of CIP clauses that don't exist. These are output-layer problems, not data-flow problems, and Part 04 gets into the review gates that catch bad output before it ships.
§ 05Next in the series
The regulatory lines are clear. The data tiers are clear. Part 03 lays out the architecture that maps one to the other: a three-zone reference design with network diagram, data classification matrix, and explicit NERC CIP compliance mapping.
— Adam · adam@sgridworks.com · Feb 2026