Somewhere in your utility's footprint, an AI model is already touching a NERC obligation. It may be a machine learning forecast feeding the day-ahead energy schedule. It may be an anomaly detection algorithm that flags EMS sensor drift before a human operator sees it. It may be a language model drafting the narrative section of a self-certification. In each case, the obligation still belongs to the registered entity, the audit evidence still lands in your compliance binder, and the Regional Entity auditor still expects a human being to sign the attestation. Understanding exactly where AI intersects with NERC obligations, and what governance structure keeps that intersection compliant, is the core competency this lesson builds.

The NERC Compliance Framework: A Working Map

Before mapping AI to NERC obligations, you need a working map of the NERC compliance framework itself. NERC reliability standards are organized into families. The FAC family covers facilities design, engineering, and testing. The MOD family covers modeling and data. The PRC family covers protection and control. The TOP, IRO, and BAL families cover real-time operations. The TPL family covers transmission planning. And the CIP family covers critical infrastructure protection, which is the cybersecurity standard set most directly implicated by AI in the operational technology environment.

Each standard contains Requirements (labeled R1, R2, R3, and so on), Measures (the evidence that demonstrates compliance), and a Violation Risk Factor (VRF: High, Medium, or Low) plus a Violation Severity Level (VSL: ranging from Lower to Severe) for each requirement. Auditors assess compliance at the requirement level, not at the standard level. A utility that scores perfectly on R1 through R4 of a standard but has a gap in R5 has a potential violation on R5 regardless of its overall posture.

AI tools can affect compliance in two directions. They can make compliance easier by reducing manual effort, improving data quality, and catching inconsistencies. They can also create compliance risk by introducing unverifiable outputs, creating audit trail gaps, or touching Cyber Assets in ways that trigger CIP obligations. The governance question is: for each AI use case, which direction are you moving, and do you have the controls in place to protect against the negative direction?

The NERC compliance framework does not currently contain a standard specifically for AI governance. This is a critical point that every compliance lead must understand. There is no AI-specific standard to audit against, no requirement to disclose AI use, and no NERC guidance document that prescribes how AI must be governed in a compliance context. What exists instead is an obligation to comply with all applicable standards, using whatever processes the registered entity employs, as long as those processes produce compliant outcomes and defensible evidence. AI is a process choice, not a standard trigger. The compliance question is not "am I using AI correctly according to NERC?" but "does my AI-assisted process produce evidence that satisfies each applicable requirement?"

Where AI Actually Touches NERC Obligations

To govern AI inside reliability standards, you must first identify the specific obligation touchpoints. Here is a systematic inventory of the highest-stakes intersections, organized by standard family.

Load forecasting and the MOD and FAC families: AI forecasting models produce outputs that feed into planning studies required under MOD-032 (data for power system modeling) and TPL-001 (transmission planning). If the AI forecast feeds a planning study that feeds a regional transmission plan, the accuracy and defensibility of the AI output is now tied to MOD and TPL compliance. An auditor reviewing TPL-001 compliance will examine the adequacy of the data and models used in the planning studies. If those studies used AI forecasts with no documented validation, no holdout test results, and no human review record, the auditor has a legitimate question about whether the planning process met the standard's intent.

Operations and the TOP and IRO families: AI-assisted topology optimization and switching recommendations, when they are presented to a control room operator as decision support, are adjacent to TOP-001 (transmission operations) and IRO-001 (reliability coordinator operations). The operator who uses the AI recommendation to initiate a switching action is executing a TOP-001 action. The obligation to assess system conditions, maintain situational awareness, and take corrective actions belongs to the operator. If the AI recommendation was wrong and the operator followed it into a reliability event, the audit will examine whether the operator had adequate information to evaluate the recommendation and whether the AI tool had been tested and validated before deployment in an operational context.

Protection settings and the PRC family: some utilities are exploring AI for coordinating relay protection settings. PRC-019 and PRC-027 set requirements for coordination studies. If an AI tool generates relay coordination recommendations, the engineer responsible for those settings has a PRC obligation that does not transfer to the model. Every AI-generated coordination recommendation must be reviewed and approved by a qualified protection engineer, and that review must be documented in the evidence record.

Compliance documentation and all families: AI language models are increasingly used to draft self-certification narratives, evidence summaries, and audit response documents. This creates a specific governance risk: a well-written but factually incorrect document. If an AI drafts a self-certification that attests to compliance with a requirement based on its internal knowledge rather than on the actual evidence record, and a compliance officer signs that attestation without verifying it against the underlying evidence, the utility has a potential perjury analog in a regulatory context. The auditor may discover the disconnect between the attestation and the evidence. The governance rule here is absolute: AI drafts, humans verify against primary evidence, humans sign.

Cybersecurity and the CIP family: this is the highest-stakes intersection and deserves a dedicated section.

AI and NERC CIP: The Highest-Stakes Intersection

NERC CIP standards apply to Bulk Electric System (BES) Cyber Assets, defined as Cyber Assets that, if rendered unavailable, degraded, or misused, would adversely impact the reliable operation of the BES within fifteen minutes. The CIP framework is not about protecting data privacy or general IT security; it is specifically about protecting the Cyber Assets that control the bulk electric system.

CIP-003-9, which became enforceable April 1, 2026, specifically addresses vendor electronic remote access and supply-chain security for low-impact BES Cyber Systems, while also obligating utilities to maintain cyber security plans covering electronic access controls, physical security, and incident response for those systems. CIP-012-2 (effective July 1, 2026, adding availability to the confidentiality and integrity protections established by the prior CIP-012-1) protects real-time operational data transmitted between control centers. Together, these standards define the perimeter within which Cyber Assets operate and the rules for protecting them.

An AI model becomes a CIP question when it crosses into this perimeter. Consider three scenarios. In the first scenario, an AI forecasting model runs on an IT server in the corporate data analytics environment and its outputs are imported manually by a planner into a planning tool. This model almost certainly does not interact with any BES Cyber Asset and has no CIP implications. In the second scenario, an AI anomaly detection model runs on a server in the utility's operational technology (OT) network, receives real-time SCADA telemetry, and pushes alerts directly to the EMS operator console. This model may be, or may communicate with, a BES Cyber Asset. The CIP question is whether the model server is within an Electronic Security Perimeter (ESP) and whether its communication with the EMS constitutes a CIP-relevant data exchange. In the third scenario, an AI recommendation engine is integrated directly into the EMS and can initiate automated setpoint changes. This model is almost certainly inside the CIP perimeter and is subject to the full CIP control set including change management, access control, monitoring, and incident response.

The governance principle for AI in the CIP context is: establish the AI model's CIP classification before deployment. If the model communicates with or operates within an ESP, it is a Cyber Asset subject to CIP obligations. It must be inventoried in the BES Cyber Asset register, covered by the access control program, subject to the change management process (including change approval, testing, and rollback capability), monitored for anomalous behavior, and included in the incident response plan. Deploying an AI model inside the CIP perimeter without completing this classification process creates a potential CIP violation for failing to protect a BES Cyber Asset.

Every AI model that touches a BES Cyber System must be classified, inventoried, and governed before it touches production data. The classification question is not optional.

The Governance Structure That Keeps AI Compliant

A utility that deploys AI tools across multiple compliance-relevant workflows needs a governance structure that is institutionalized, not ad hoc. Here is the framework that holds up under a Regional Entity audit.

The first element is an AI use case registry. Every AI tool used in a process with NERC compliance implications must be registered in a central inventory. Each registry entry captures: the tool's name and version, the specific workflow it supports, the NERC standards whose evidence the tool's output may affect, the CIP classification (in or out of the ESP), the human reviewer role and sign-off requirement, and the validation status (has the tool been tested and accepted for this use case?). The registry is a living document that the compliance team reviews annually and updates whenever a new tool is deployed or an existing tool is updated.

The second element is a human-sign-off protocol tied to each standard's requirement. For every NERC standard that applies to the utility, the compliance team should identify which requirements involve AI-assisted processes and define the human sign-off checkpoint for each. For example: TPL-001 R4 requires a transmission planning assessment. If the planning assessment uses AI-generated forecasts, the sign-off protocol specifies that the responsible planning engineer must review the AI forecast against the utility's validated forecast accuracy criteria before accepting it as a study input, and that review must be documented with the date, reviewer name, and a statement of the validation check performed. This evidence becomes part of the TPL-001 R4 audit file.

The third element is a model change management process that mirrors the CIP change management framework for operational tools and extends it to all compliance-relevant AI tools. When an AI model is updated (new training data, new hyperparameters, new version), the change must be assessed for compliance impact, tested against the prior version, approved by the compliance-relevant subject matter expert, and documented. The auditor who asks "what version of this model was running during the audit period" must receive a precise answer, not "I think it was the version from late 2025."

The fourth element is a documentation architecture that makes AI use transparent to auditors without requiring auditors to understand AI. The audit evidence file for each NERC standard requirement should include, where AI was used: a reference to the AI use case registry entry for the tool, a brief description of the AI's role in the process (for example, "AI generated the initial load forecast; the planning engineer validated it against the backcast accuracy threshold before accepting it as the TPL-001 study input"), and the human reviewer's sign-off. The auditor does not need to understand the machine learning algorithm; the auditor needs to confirm that a qualified human took responsibility for the output. Your documentation must enable that confirmation.

The fifth element is an annual governance review. The compliance team, working with the operations, planning, and IT/OT security teams, conducts an annual review of all AI tools in the registry. The review examines: any new AI deployments in the prior year that need to be added to the registry, any model updates that triggered change management records, any compliance incidents or near-misses attributable to AI-generated outputs, and any changes in applicable NERC standards that affect the human sign-off requirements. The output of this review is an updated registry and any corrective actions assigned.

Worked Example: A Compliance Binder Under Audit

A Regional Entity auditor arrives for a three-year compliance audit of a transmission owner and reliability coordinator. Among the standards in scope is MOD-032, which requires the entity to provide accurate data for use in power system models used by planning coordinators. The entity has been using an AI load forecasting tool to generate the load data submitted under MOD-032.

The auditor's request: provide evidence of compliance with MOD-032 R1 for the audit period, including the data submitted and the process used to prepare it.

The compliance lead pulls the MOD-032 evidence file. What the auditor finds, in a utility with strong AI governance, is the following package: the AI use case registry entry for the load forecasting tool, showing it was classified as non-CIP (operating in the IT environment, no ESP connection), validated against a backcast accuracy threshold of 2.5% MAPE over a rolling twelve-month window, and approved for use as a MOD-032 data source by the Chief Planning Engineer on a specified date. The evidence file also includes the model change management log for the tool, showing two version updates during the audit period, each with a testing record and a revised approval. It includes the monthly data quality review records showing that the AI forecast met the MAPE threshold in ten of twelve months, with two months where the threshold was exceeded and the human override was documented with the revised data and the engineer's rationale. Finally, it includes the human sign-off record for each annual MOD-032 data submission, with the reviewer's name and attestation that the data was reviewed against the validation criteria before submission.

The auditor's findings: no violations. The entity used AI in its compliance process and was able to demonstrate that a qualified human took responsibility for the output at each submission, that the tool was properly classified and validated, and that exceptions were handled through a documented override process. The AI use was transparent, governed, and defensible.

Now consider the same audit at a utility without AI governance. The auditor asks the same question. The compliance lead provides the data submissions but cannot explain which version of the forecasting model generated the data, whether the model was tested before use, or whether any human reviewed the AI output before submission. The auditor identifies a potential violation of MOD-032 R1: the entity cannot demonstrate that the data it submitted was accurate and reliable because it cannot demonstrate that its data preparation process was controlled and validated. The AI use was not illegal, but it was undocumented and ungoverned, and that gap is the violation.

Key Takeaways

• NERC does not currently have an AI-specific standard. AI governance in a reliability standards context is about ensuring that AI-assisted processes produce compliant outcomes and defensible evidence for existing standard requirements, not about complying with a separate AI rule.
• AI touches NERC obligations in at least four standard families: MOD and TPL (forecasting and planning data), TOP and IRO (real-time operations), PRC (protection settings), and the drafting of compliance documentation across all families. Each intersection requires a defined human review and sign-off checkpoint.
• NERC CIP is the highest-stakes intersection. Any AI model that communicates with or operates within an Electronic Security Perimeter must be classified as a Cyber Asset, inventoried, and governed under the full CIP change management, access control, monitoring, and incident response framework before deployment in production.
• The five elements of a compliant AI governance structure are: an AI use case registry, a human sign-off protocol tied to each standard's requirements, a model change management process, a documentation architecture that makes AI use transparent to auditors, and an annual governance review.
• The decisive test in a Regional Entity audit is not whether AI was used but whether a qualified human took documented responsibility for the AI's output at each compliance evidence touchpoint. Governance transforms AI from an audit risk into an audit-ready capability.
• CIP-003-9 (enforceable April 1, 2026, specifically addressing vendor electronic remote access and supply-chain security for low-impact BES Cyber Systems) and CIP-012-2 (effective July 1, 2026, adding availability to the prior CIP-012-1 confidentiality and integrity protections for inter-control-center data) together define the security boundary within which any AI model in the OT environment must be governed. Deploying an AI tool inside the Electronic Security Perimeter without completing the CIP classification process is a potential CIP violation, independent of whether the model functioned correctly.
• Model change management is not optional for compliance-relevant AI. When a model is updated, the change must be assessed for compliance impact, tested, approved by the compliance-relevant subject matter expert, and documented so that an auditor can determine exactly which model version was running during any point in the audit period.