Building Auditable AI Systems for Energy Compliance: NERC CIP & FERC Guide

When a regional entity auditor examines an AI-assisted compliance process, the question is the same one FERC asks about every Critical Infrastructure Protection control: can you reconstruct what the system did and identify who approved it? Auditable AI is the discipline of building AI systems that answer that question with retained evidence rather than vendor assurances. This guide is for compliance leaders and IT/data directors at generation companies who need verifiable decision trails that hold up under NERC CIP, FERC, EU AI Act, and NIST AI RMF scrutiny.

What is Auditable AI?

An AI system is auditable when an independent reviewer can reconstruct any decision it made from retained evidence: the input data and its lineage, the model version that processed it, the output, the timestamp, and the human who reviewed or overrode the result. Reproducing a decision requires keeping both the algorithm and its source data available: “Auditability requires operational process repeatability, which means that the algorithm and the raw data that produce a specific AI outcome need to be accessible and available” (ISACA Journal, 2022).

Auditability is narrower than responsible AI and distinct from transparency. Responsible AI is the goal: safe and accountable systems governed by fairness controls. Transparency is openness about design and intended use, including training data. Auditability is the evidentiary test beneath both, whether a third party can verify after the fact that the system behaved as claimed. Trust depends on accountability, which in turn depends on transparency: “Trustworthy AI depends upon accountability. Accountability presupposes transparency” (NIST AI 100-1).

NERC CIP contains no AI carve-out, and no CIP standard defines an AI-specific asset category. The responsible entity must classify an AI system as a BES Cyber Asset under Critical Infrastructure Protection standard CIP-002-5.1a when misuse or degradation could adversely affect bulk electric system operation within 15 minutes, and the system inherits the full CIP evidence burden, model or not.

Why Auditable AI Matters for Energy Compliance?

FERC has already defined the evidentiary bar, and it disqualifies point-in-time demonstrations. The FERC compliance guidance sets the standard: “It is not sufficient to show that the appropriate ports and services are disabled at the time of audit or investigation. Rather, date-stamped electronic records or some other kind of evidentiary documentation is necessary to prove that the required action occurred at the proper time.” An AI system that produces correct outputs but cannot prove its history fails this test.

The enforcement record shows what control and documentation failures cost a generation portfolio. Duke Energy paid the largest publicly confirmed CIP penalty on record, $10 million for 127 security violations spanning 2015 to 2018, with reported root causes including “lack of managerial oversight, process deficiencies, inadequate training and lack of internal controls” (Utility Dive). A $2.7 million penalty later tied to PG&E stemmed from a vendor that copied sensitive cyber asset data, including live IP addresses, to its own network, where it sat publicly accessible for 70 days (National Law Review). In 2025, five CIP standards accounted for more than 800 reported noncompliances, the most-reported violation category that year (RTO Insider). Each facility inside the audit scope carries the same documentation obligation, so one missing evidence discipline repeats across every asset in the portfolio.

Two additional legal regimes layer on top of CIP for energy AI deployments:

• EU AI Act: Annex III, point 2 classifies as high-risk “AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or in the supply of water, gas, heating or electricity.” Following the Digital Omnibus (Regulation (EU) 2026/1744), those high-risk rules become enforceable on 2 December 2027, with penalties up to EUR 15,000,000 or 3% of worldwide annual turnover under Article 99.
• SOX: The statute is technology-neutral, so any AI system affecting financial reporting falls within ICFR scope. PCAOB standard AS 1105 requires auditors to test the accuracy and completeness of information produced by the entity, including AI-generated reports and estimates.

NIST AI RMF: Voluntary, but DHS incorporated all four of its functions into safety and security guidelines for all 16 critical infrastructure sectors, including “Logging and monitoring system access and use” (DHS guidelines, April 2024).

No AI-specific NERC CIP or FERC enforcement action exists in publicly posted records. The exposure comes from existing standards applied to AI assets, before any new rulemaking.

Core Controls of an Auditable AI System

Auditors examine the model and its operating environment, including the data that feeds it.

Data provenance and integrity

Provenance is the prerequisite. NIST AI 100-1 states that “maintaining the provenance of training data and supporting attribution of the AI system’s decisions to subsets of training data can assist with both transparency and accountability” (NIST AI 100-1). The GAO’s AI Accountability Framework makes documenting the sources and origins of training data an explicit auditor checkpoint (GAO-21-519SP).

Lineage must run unbroken from raw source (PI Historian, SCADA, DCS, ISO/RTO feeds) through training sets to each inference. Ofgem’s AI Reg Lab findings flag “absent data traceability” and require “clear identification and distinguishability between authoritative data and AI-generated inferences” (Ofgem, April 2026).

Training data becomes BES Cyber System Information only when it contains information about the BCS that could be used to gain unauthorized access or pose a security threat to the BCS, such as nonpublic network topology, credentials, or detailed control logic. Generic public datasets are not BCSI solely because a model trained on them.

Model transparency and explainability

These are two different evidence obligations, and auditors ask for both. System-level transparency covers the model’s documented design: intended purpose, architecture, training method, validation results, and known limits. NIST AI 100-1 scopes it across the full lifecycle, “from design decisions and training data to model training, the structure of the model, its intended use cases, and how and when deployment, post-deployment, or end user decisions were made and by whom.” Individual-decision explainability answers a narrower question: why did the model produce this specific output on this specific date? ISACA breaks that into simulatability and decomposability, supported by algorithmic transparency (ISACA Journal, 2022).

Bias detection belongs at defined lifecycle checkpoints, not at launch alone. COSO’s AI guidance warns that “even the best-intentioned algorithms are subject to bias” and that “continual monitoring and testing of algorithms is necessary especially as data used by algorithms and trends within the data change over time” (COSO). Set bias-test checkpoints at retraining and at every baseline configuration change.

Deployment and access controls

Where an AI system runs determines whether it can be defended at audit. ReliabilityFirst states that current CIP standards do not provide a defensible path for operating high- or medium-impact BES Cyber Systems in the cloud, apart from permitted BCSI storage and processing arrangements: “The use of cloud services will not be possible for high and medium impact BES Cyber Systems under the present CIP Standards because compliance risk will be increased beyond an acceptable level, except for BES Cyber System Information in the cloud.” AI model servers or inference gateways with routable connectivity to applicable BES Cyber Systems must sit inside a defined Electronic Security Perimeter under CIP-005-7, with all external routable connectivity through identified Electronic Access Points that deny all other access by default. PG&E’s November 2024 deployment of on-site generative AI at Diablo Canyon shows the on-premises pattern in commercial practice (PG&E).

When the AI application or supporting infrastructure is an applicable Cyber Asset, CIP-007-6 requires the responsible entity to retain applicable logs for at least the last 90 consecutive calendar days, review them at intervals no greater than 15 calendar days, and retain all CIP-007 evidence for three calendar years.

Building a verifiable audit trail

The trail must let a reviewer replay a decision end to end.

• Inputs and lineage: The trail records every data element the model consumed and traces it to its source system.
• Outputs: The record holds the model’s result, interpreted in context, along with any downstream action taken.
• State changes: Model version, weights, configuration, and dependency changes all get logged. Under CIP-010-4, the baseline configuration must capture OS, application software with versions, custom software (including model artifacts and inference configuration), logical ports, and applied patches, with baseline updates within 30 calendar days of a change and monitoring for unauthorized changes at least every 35 calendar days.
• Timestamps: Every event carries a date-stamped record, matching FERC’s evidentiary standard.
• Human actions: Review, approval, override, and escalation records tie to named individuals.

The EU AI Act writes the same requirement into law for high-risk systems. Article 12 requires that systems “technically allow for the automatic recording of events (logs) over the lifetime of the system,” and Article 19 requires providers to keep those logs at least six months. PwC’s guidance on AI-dependent controls adds model validation sign-offs, exception logs, output samples with human-review evidence, and drift-detection monitoring reports to the artifact list (PwC).

Tamper-evident storage is one design choice among several. ORNL’s Cyber Grid Guard uses a permissioned Hyperledger Fabric blockchain with SHA hashing to verify grid configuration data, and ORNL licensed it to GridForge Energy Solutions in June 2026 (ORNL). PNNL’s KISS project demonstrated keyless-signature integrity for utility historians with partners including Tennessee Valley Authority and Guardtime (DOE). Both remain lab demonstrations and licensing milestones rather than production utility deployments, and no FERC, NERC, or state PUC mandate for cryptographic AI decision provenance exists. Use conventional retained logging as the baseline until a regulator mandates cryptographic provenance.

Monitoring for drift over time

Even after the model owner validates a model at deployment, the model can degrade silently, and each failure mode requires different detection. Data drift (covariate shift) is a change in the distribution of input features while the underlying relationship holds. Concept drift, per Gama et al., is when “the relation between the input data and the target variable changes over time,” and real concept drift can occur while input distributions stay unchanged, which makes it invisible to feature-only monitoring. Performance drift is the outcome signal: measured deterioration in predictive quality.

Performance drift has a practical complication: ground-truth labels often arrive late. Evidently AI’s recommended pattern is “two monitoring loops: the real-time one that uses proxy metrics and the delayed one that runs once the labels are available” (Evidently AI).

Regulated-industry precedent points toward continuous logging over periodic checks. The Bank of England’s October 2025 roundtable found that “the current periodicity of ongoing monitoring for AI and ML models is not frequent enough,” and that six-month intervals may be insufficient for dynamic models (Bank of England).

In the energy sector, Ofgem’s May 2026 guidance states that “monitoring can also be used to help identify any drift in behaviour of the AI system or its operating environment” (Ofgem). NIST AI RMF names drift in data or the model, including concept drift, as triggers for corrective maintenance (NIST AI 100-1). Set the interval in writing and log continuously. Document every drift-triggered review.

Human-in-the-loop oversight and autonomous agent risks

Human review checkpoints carry a structural audit obligation. The NERC white paper from November 2024 on AI/ML in real-time operations states that “the operator should have the final input on the decision for AI/ML generated actions that are to be taken.” The EU AI Act’s Article 14 makes the same idea enforceable: assigned overseers must be able to disregard, override, or reverse system output and to interrupt the system through a stop button or similar safe-halt procedure, and Article 26(2) requires deployers to assign oversight to persons with “necessary competence, training and authority, as well as the necessary support.”

Assistive AI fits this model cleanly. A system that drafts a Generator Availability Data System (GADS) event classification or flags a compliance evidence gap, then routes the output to a named reviewer, produces exactly the decision record an auditor wants.

Autonomous agents and LLMs resist the same treatment for documented technical reasons. Research reaches the blunt conclusion that “no agent system can be accountable without auditability” (arXiv:2604.05485):

• Fragmented evidence: Static bills of materials and runtime logs “provide only fragmented evidence” of multi-step agent behavior (arXiv:2605.06812).
• Non-determinism: LLM inference is structurally non-reproducible due to floating-point non-associativity across hardware. One study found up to 9% accuracy variation and 9,000 tokens’ difference in response length solely from GPU configuration and evaluation batch size (arXiv:2506.09501).
• Prompt sensitivity: ICLR 2024 research found performance swings of up to 76 accuracy points for one open model in few-shot settings from subtle prompt formatting changes.
• Unfaithful reasoning traces: Anthropic reported that reasoning models verbalize hints they used “often less than 20% of the time” (arXiv:2505.05410), so a chain-of-thought log is not a decision record.

IOSCO summarized the supervisory view: “A key distinction for GenAI systems is that system behavior cannot be fully specified or anticipated in advance of deployment, unlike traditional software” (IOSCO). Require a named review checkpoint before autonomous output can drive an operational action.

Auditable AI frameworks and standards

The EU AI Act and NIST AI RMF anchor the regulatory layer; the frameworks below structure controls and internal assurance underneath them:

Two caveats limit these frameworks. The IIA concedes that “because AI is evolving rapidly and is complex in nature, internal audit likely will be able to provide only limited assurance,” and it advises obtaining vendors’ SOC reports plus SLAs “that contain the right to audit.” And no publicly documented CertifAIEd certification by an electric utility or grid operator turns up for 2024–2026, which makes it an emerging signal well short of a procurement filter.

Common mistakes

Four failure patterns recur across regulator lessons-learned documents and third-party readiness assessments.

• Treating auditability as a one-time check. Deloitte’s 2026 energy-sector AI report found “AI models have been deployed into production without formal oversight or monitoring processes” (Deloitte), and EY found only 8% of organizations have a well-defined AI lifecycle management process (EY, May 2025). Validation at go-live proves nothing about month nine.
• Fragmenting evidence across systems. When model documentation lives in SharePoint, logs in a historian, approvals in email, and lineage in a data team’s scripts, no single artifact reconstructs a decision. The same Deloitte report describes an AI leader who discovered “there wasn’t a clear inventory of all the AI tools and models currently active” because development happened without centralized tracking.
• Adopting general-purpose cloud AI that fails data sovereignty. FERC’s October 2025 audit lessons found entities using cloud SaaS “did not have a documented agreement to include roles, responsibilities, security controls and compliance requirements” for third-party providers (FERC).
• No assigned governance ownership. SERC’s 2024–2026 regional risk report formally names “Lack of Generative Artificial Intelligence Governance” as an emerging bulk-power-system risk (SERC). Grant Thornton found 78% of executives lack strong confidence they could pass an independent AI governance audit within 90 days (Grant Thornton, 2026). If no named person owns the model inventory and review cadence, the auditor’s first question has no answer.

The sector baseline is low: a Utility Dive/West Monroe survey of 35 utilities found just 30% had implemented AI governance frameworks.

Getting started

Making an existing AI system auditable is a sequencing problem. Work the steps in order; each produces the evidence the next depends on:

1. Inventory every AI system and its data lineage. Include third-party and embedded AI; catalog the data sources and model version for each system, with a named owner. NIST recommends the inventory hold system documentation, incident response plans, data dictionaries, and named contacts (NIST AI RMF Playbook).
2. Define audit trail requirements per system. Specify inputs, outputs, state changes, timestamps, and human actions, and set retention against the strictest applicable rule: 90-day logs and three-year evidence under CIP-007-6, or six-month log retention under EU AI Act Article 19 if EU operations apply.
3. Assign governance roles by name. NIST’s GOVERN 2.1 calls for documented role assignments and lines of communication for AI risk (NIST AI RMF Playbook). Someone with real authority should approve production deployment; ISACA notes “a peer approval following a code review would not suffice” (ISACA).
4. Set drift monitoring in writing. Define metrics and thresholds that trigger off-cycle review. Include both monitoring loops for delayed-label cases.
5. Place and document human review checkpoints. Every point where a model output can drive an operational or reported outcome needs a named reviewer and a recorded decision.

Where the system runs shapes how hard steps 1 through 5 are. Dota runs within your own cloud instance and keeps operational data air-gapped from the AI layer, satisfying the NERC CIP data sovereignty requirements that eliminate most general-purpose cloud AI tools from consideration. The Dota Start tier is free and covers up to 50 interactions, so your data team can pilot an auditable AI application against your own deployment constraints before any enterprise commitment.

FAQ

Compliance and IT leaders evaluating auditable AI tend to ask the same five questions.

How is auditable AI different from responsible AI?

Responsible AI is the objective: safe and accountable systems governed by fairness controls. Auditable AI is the proof mechanism: retained, verifiable evidence that lets a third party reconstruct what the system did. You can pursue responsible AI without auditability, but you cannot demonstrate it to a regulator.

What must an AI audit trail capture?

Inputs with full data lineage, outputs, model and configuration state changes, timestamps on every event, and records of human review and override tied to named people. Retention follows the strictest applicable rule for your footprint, from CIP evidence periods to the EU AI Act’s six-month log minimum.

Which regulations apply to AI in energy compliance?

NERC CIP applies today through function-based asset classification (CIP-002-5.1a, CIP-005-7, CIP-007-6, CIP-010-4, CIP-011-3). The EU AI Act’s high-risk rules for energy safety components become enforceable 2 December 2027 for organizations in scope. SOX covers any AI touching financial reporting at public companies, and NIST AI RMF is voluntary but embedded in DHS critical infrastructure guidance.

Why are autonomous agents and LLMs harder to audit than traditional models?

Their outputs are not reproducible across hardware and batch configurations, small prompt changes swing results by double-digit accuracy points, their reasoning traces do not reliably reflect internal computation, and multi-step agent behavior leaves fragmented logs. A traditional model with fixed weights and deterministic inference supports replay; an agent generally does not.

Where should human review checkpoints sit?

Before any model output drives an operational action, per NERC’s guidance that operators hold final input on AI-generated actions; at production deployment approval by someone with appropriate authority; at drift-triggered model reviews; and at every override or shutdown decision, each with a documented record.