Every utility has a safety committee, a reliability committee, and a compliance committee. The AI governance committee is none of those, but it must speak the language of all three. The utility that stood one up in 2022 as a technology steering group and forgot to put a NERC compliance lead in the room is the utility that discovered, in a 2024 rate case, that its AI system had never received a formal CIP-compliance clearance. This lesson builds the committee correctly from the first chair.

Why a Utility Needs a Dedicated AI Governance Committee

Governance structures in utilities are built around risk domains. The reliability committee exists because reliability risk is real, consequential, and regulated by NERC. The safety committee exists because worker safety is a legal and moral obligation with its own regulatory framework. The NERC compliance committee exists because compliance violations carry financial penalties and reputational consequences. Each committee has a defined risk domain, a defined accountability chain, and a defined regulatory interface.

AI does not fit cleanly into any of these existing domains, and that is exactly why it needs its own governance structure. An AI-assisted load forecast that drifts into inaccuracy creates reliability risk. An AI system that touches the OT environment creates CIP risk. An AI investment in the rate case creates regulatory risk. An AI tool that produces a discriminatory output in DER targeting creates equity and legal risk. These risks span all of the existing committees, but no single existing committee has the mandate, the technical vocabulary, or the cross-functional authority to govern AI comprehensively.

The alternative to a dedicated AI governance committee is informal governance: each team that deploys an AI tool manages its own risk, reports to its own leadership, and never forces a cross-functional conversation. Informal governance works fine until something goes wrong. When an AI-assisted switching recommendation is later identified as contributing to a reliability event, the question "who approved this AI system for operational use?" needs to have an answer. Without a governance committee, the answer is typically "nobody, formally," which is a very bad answer in a NERC investigation or a regulatory proceeding.

The AI governance committee is not another layer of bureaucracy. It is the accountability structure that allows a utility to deploy AI aggressively and defensibly. Done well, it accelerates deployment by clearing AI systems for operational use through a defined process rather than through ad hoc risk assessment by whoever happens to be in the room.

Who Must Be in the Room: The Mandatory Seats

The committee's composition is its most critical design decision. A committee that has technology representation but lacks reliability and regulatory seats will approve AI systems that cannot survive a NERC audit. A committee that has regulatory representation but lacks operational authority will create policies that the operations team ignores because no one with real operational accountability signed off.

The mandatory seats are five: reliability, NERC CIP and compliance, regulatory affairs, operations, and AI or data science leadership. Each seat carries a different accountability and a different veto right.

The Reliability Seat

The reliability representative brings the N-1 discipline: any AI system that touches grid operations must be evaluated against the question of what happens when the AI fails or produces a bad recommendation. This person is responsible for ensuring that every AI advisory system has an identified human fallback, that the human fallback is trained and capable of operating without the AI tool, and that the AI system's failure modes have been documented and reviewed. In practice, this is typically the VP of transmission or the system operations director, or their designated reliability engineer. The reliability seat has an effective veto on any AI deployment that touches real-time operations without meeting the fallback standard.

The NERC CIP and Compliance Seat

This is the seat that was missing from too many early utility AI governance structures. NERC CIP-003-9, enforceable as of April 1, 2026, specifically addresses vendor electronic remote access and supply-chain security for low-impact BES Cyber Systems, while CIP-012-2 (effective July 1, 2026, adding availability to the confidentiality and integrity protections of the prior CIP-012-1) governs real-time data between control centers. Together they create specific obligations for electronic security perimeters, vendor access controls, and data protection that AI tool deployments must satisfy. Any AI system that touches the EMS, ADMS, or any system within the electronic security perimeter of a bulk electric system cyber asset is subject to CIP compliance review before deployment. The NERC compliance lead must be in the room to answer the question: "Does this AI system require a CIP change or an access-management update, and have we completed that process?" Without this seat, the committee can approve AI systems that are technically in violation of CIP obligations the day they go live.

This seat also carries responsibility for the NERC audit trail. When NERC staff audits the utility's compliance with applicable standards, the AI governance committee's records are part of the compliance evidence. Meeting minutes, approval records, CIP-clearance documentation, and change-control records all belong in the compliance binder.

The Regulatory Affairs Seat

The regulatory affairs representative ensures that every AI deployment is evaluated through the lens of its rate-case implications and its interaction with applicable state and federal regulatory requirements. This person asks: has this AI system received appropriate cost accounting treatment? Is the evidence we are generating from this deployment in a form that will be useful in the next rate case? Does this deployment create any reporting obligations under state PUC orders or FERC requirements? Does this deployment interact with any active rate case proceedings in a way that creates a disclosure obligation?

In the FERC large-load rulemaking environment of 2026, the regulatory affairs seat is particularly important for AI systems related to interconnection processing. The regulatory landscape is changing rapidly, and AI systems deployed without regulatory review may be doing things that create compliance issues or rate-case exposure that the technical team did not anticipate.

The Operations Seat

The operations representative is the person who will actually live with the AI system's outputs. For a forecasting AI, this is the load forecasting manager or the resource planning director. For an EMS advisory AI, this is the system operations director or a senior control-room supervisor. For a queue automation system, this is the interconnection engineering manager. The operations seat has practical authority that the other seats do not: this person can kill a deployment that is not working for the people who have to use it, regardless of what the governance committee approved in theory. Their presence in the room from the beginning ensures that the committee's approvals reflect operational reality, not just policy.

The AI and Data Science Seat

The AI and data science representative is responsible for explaining what the system actually does, what it does not do, and where it is likely to fail. This is not a cheerleader role. This person must be empowered and expected to tell the other committee members when an AI system has limitations that the other seats need to know about: the model has not been tested on holiday load shapes; the training data does not include any large industrial interconnections over 100 MW; the model will not generalize to weather patterns outside the historical range. The other seats cannot evaluate risk they do not know about.

Governance Mandate and Decision Rights

A governance committee without a clear mandate and defined decision rights is a discussion group. The AI governance committee needs four specific authorities, explicitly granted by the utility's senior leadership (typically the executive team or the board's relevant committee).

First: the authority to approve or deny deployment of AI systems for operational use. No AI system that touches grid operations, customer interactions, or regulatory-facing processes should go live without governance committee clearance. This is not a rubber stamp; the process should require a documented review of the reliability assessment, the CIP clearance, the regulatory implications, and the performance metrics baseline.

Second: the authority to require suspension of an operating AI system that is not meeting its performance commitments or that poses an unacceptable risk. This authority needs to be explicit and fast-acting. If the MAPE monitoring shows a system has been degrading for two months without corrective action, the committee has the authority to order the system suspended pending investigation and remediation.

Third: the authority to require changes to AI governance policies across functional areas, including the operations, compliance, and technology functions. Without this authority, the committee can recommend policy changes but cannot enforce them. The relevant VPs need to have committed in writing to the committee's policy authority when the committee was chartered.

Fourth: a reporting obligation to the board or the board's relevant committee (audit, risk, or technology). The governance committee's quarterly report to the board is what makes the board's AI risk oversight real rather than nominal. The report should cover: active AI systems and their current performance against pre-committed metrics, any systems that required suspension or remediation during the period, any emerging risks identified by the committee, and the deployment pipeline (systems under review for operational clearance).

The Approval Process for a New AI System

The committee's most important operational function is reviewing new AI systems before deployment. The process should have five stages that are non-negotiable, with a defined timeline for each.

Stage 1 is the technical submission. The AI team submits a standard package including: a description of what the system does and what data it uses, the model architecture and training methodology at a non-technical level, the intended user audience and interaction model, the anticipated integration points with existing systems (EMS, ADMS, OMS, GIS), and the failure modes that the team has identified. This package is due at least 30 days before the requested go-live date.

Stage 2 is the CIP clearance review. The NERC compliance lead and the IT security team assess whether the system touches any electronic security perimeter assets and, if so, what change-management and access-control steps are required. This review must be completed and documented before Stage 3 begins. For systems that require CIP change management, this stage adds timeline and the committee must communicate that early.

Stage 3 is the reliability assessment. The reliability representative reviews the AI system against the fallback-capability standard: what does the operator do when this system is unavailable or produces a recommendation they do not trust? Is the fallback documented? Is it trained? This assessment should result in a formal signed document confirming that the reliability standard has been met or identifying what gap remains.

Stage 4 is the regulatory and metrics review. The regulatory affairs representative confirms the cost-accounting treatment and any disclosure obligations. The metrics commitment is established: the pre-deployment baseline is documented, the post-deployment success metrics are defined, and the review schedule is set. This is where the metrics commitment document required by the previous lesson in this chapter gets its formal endorsement from the governance committee.

Stage 5 is committee vote and documentation. The committee convenes, all four critical stages are confirmed complete, any remaining issues are discussed, and a formal vote is recorded. The approval record includes the date, the committee members who voted, any conditions attached to approval, and the metrics commitment baseline. This record goes in the compliance binder and the rate-case file.

Ongoing Monitoring and the Annual Review

Governance does not end at deployment approval. The committee has an ongoing responsibility to monitor the performance of all operating AI systems and to review them formally on an annual basis.

Monthly monitoring uses the operational metrics dashboard described in the previous lessons: MAPE by circuit cluster, override rate, queue throughput. The AI and data science representative and the operations representative should be reviewing these monthly and bringing any alerts to the committee's attention before the monthly meeting. Alerts that require immediate attention (a significant MAPE degradation, an unusual override spike) should be escalated outside the normal meeting cycle.

The annual review is a formal re-evaluation of each active AI system. It covers: metric performance against the original commitment, any CIP or compliance status changes, any significant events (model updates, data-pipeline changes, system outages), operator feedback on usability and trust, and a forward assessment of whether the system's capabilities are still appropriate for the current operating environment. Systems that fail the annual review can be required to undergo remediation before continuing in service.

The annual review also serves a succession-planning function. As personnel rotate through the committee seats, the annual review ensures that new committee members understand the existing deployed AI systems and their risk profiles, rather than inheriting a set of approved systems they have never formally reviewed.

The Governance Committee in a NERC Audit or Rate Case

One of the most practical tests of an AI governance committee is how it performs when an external party asks the hard questions. NERC staff arriving for a CIP audit will ask whether any AI systems touch BES cyber assets and what change-management process was followed. The governance committee's CIP clearance records are the answer. A committee that was doing its job has a file for each deployed AI system showing the CIP-clearance review, the access-control documentation, and the change-management record.

A commission staff attorney in a rate case will ask whether the AI systems were independently reviewed for reliability and compliance before deployment. The governance committee's approval records are the answer. A committee that was doing its job has a dated approval record for each system showing that reliability, compliance, and regulatory representatives signed off before deployment.

The governance committee also provides a critical function in the event of an AI-related incident: the committee meeting records show what the utility knew, when it knew it, and what it did about it. If a model degradation alert was generated in the operational metrics system and the committee addressed it within the required response window, that documentation is evidence of responsible governance. If the committee's records show the alert was raised and ignored for three months before an event occurred, that is a different story. Governance committee records are discovery material, and they tell a story whether you intend them to or not.

Worked Example: Standing Up from Scratch at a Mid-Sized IOU

A mid-sized investor-owned utility has been deploying AI tools informally for two years: a forecasting tool approved by the VP of resource planning, an interconnection-screening tool approved by the manager of transmission planning, and a storm-prediction dashboard deployed by the operations team. None of these has a CIP clearance on file. None has a formal reliability assessment. None has a pre-committed metrics baseline. A new chief operating officer decides this needs to be fixed.

Month 1: The COO charters the governance committee with five seats (reliability, NERC compliance, regulatory affairs, operations, AI/data science) and appoints the VP of reliability as chair. The committee's mandate and decision rights are documented in a governance charter signed by the COO and the CFO. The first agenda item is a retrospective review of the three existing AI systems.

Month 2: The NERC compliance lead conducts a CIP boundary assessment on each of the three existing systems. The forecasting tool has no EMS integration and clears the boundary assessment without changes. The interconnection-screening tool accesses data from a system adjacent to the EMS; a change-management record is opened and completed. The storm-prediction dashboard queries weather APIs and ADMS data; a CIP-access review is completed and documented.

Month 3: The reliability assessment is conducted for each system. The forecasting tool has a documented fallback (the prior ARIMA model remains configured and can be activated within minutes). The interconnection-screening tool's fallback is manual review, which the interconnection team confirms is practiced and capable. The storm-prediction dashboard's fallback is the standard storm-call process that predates the tool.

Month 4: Metrics baselines are established retrospectively using historical operational data. This is imperfect compared to a pre-deployment baseline, but it is documented in the governance records with an honest acknowledgment of the limitation and a commitment to prospective measurement from this point forward.

Month 5: The committee holds its first formal quarterly meeting, reviews the current performance of all three systems against the new metrics baselines, and documents the results. The committee sends its first quarterly report to the board's audit committee.

The cost of this exercise: approximately three months of elapsed calendar time, with four weeks of staff work spread across compliance, reliability, regulatory, and technology teams. The result: three AI systems that now have defensible governance records, a committee structure that can review future deployments properly from day one, and a compliance binder that can answer a NERC auditor's questions. The COO's investment is modest relative to the regulatory and operational risk it removed.

Key Takeaways

• An AI governance committee is the accountability structure that allows a utility to deploy AI aggressively and defensibly. Without it, "who approved this system?" has no answer in a NERC investigation or a rate case.
• The five mandatory seats are: reliability (N-1 fallback discipline), NERC CIP and compliance (electronic security perimeter clearance), regulatory affairs (rate-case and disclosure implications), operations (the people who live with the outputs), and AI/data science (honest technical limitation reporting).
• The committee needs four specific authorities: approve or deny deployment, require suspension of underperforming systems, require cross-functional policy changes, and report to the board.
• The deployment approval process has five non-negotiable stages: technical submission, CIP clearance, reliability assessment, regulatory and metrics review, and committee vote with documented record.
• CIP-003-9 (vendor electronic remote access and supply-chain security for low-impact BES Cyber Systems, enforceable April 1, 2026) and CIP-012-2 (confidentiality, integrity, and availability of inter-control-center real-time data, effective July 1, 2026) are both active in 2026 and apply to AI systems that touch BES cyber assets. The CIP clearance stage of governance is not optional, and missing it is a compliance violation, not just a procedural gap.
• Governance committee records are discovery material in both NERC audits and rate-case proceedings. They tell a story whether you intend them to or not, so make sure the story they tell is one of responsible, proactive oversight.
• Retrospective governance is possible but imperfect. Utilities that have deployed AI systems without formal governance should prioritize a retroactive CIP boundary assessment, reliability assessment, and metrics baseline as the foundation for a committee standing up mid-program.