The NERC compliance examiner opened the binder and asked one question: "Show me the record that your operators were acting on verified output when they executed those switching steps, not on the raw AI summary." The utility's legal team spent the next four hours looking for a document that did not exist.

Why Documentation Is the Audit Product

In a regulated, reliability-critical environment, the work is not complete when the switching step is executed, the forecast is submitted, or the compliance narrative is filed. The work is complete when there is a record that shows the qualified person who did the work, what information they relied on, what they verified, what they decided, and when. That record is the audit product. And for AI-assisted grid work, the record must go one step further: it must show where the AI ended and where the human judgment began.

NERC reliability standards do not yet have an AI-specific documentation standard, but they have a clear framework: every reliability action must be taken by a qualified operator under an approved procedure, and the procedure and the action must be documented. When AI is in the workflow, the documentation must show that the procedure included AI use in an approved, defined role, and that the human operator confirmed the AI's input before acting. Without that documentation, the AI's involvement is invisible in the record, and the utility cannot demonstrate that the operator was accountable rather than passive.

State commissions have an additional documentation interest. When a utility files AI-assisted work products, such as a load forecast, a resource planning narrative, or a rate case exhibit, the commission needs to be able to assess whether the work product is reliable enough to base regulatory decisions on. This means the commission will ask about the methodology, the verification steps, and the human accountability chain. A utility that can answer those questions with a complete, organized documentation record will get through the process faster and with fewer data requests.

Documentation for AI-assisted work is not bureaucracy added on top of the real work. It is the evidence that the real work was done correctly by an accountable human. Without it, the work and the risk cannot be separated.

The Five Core Documentation Elements for AI-Assisted Grid Work

A complete documentation record for any AI-assisted grid work task should contain five elements. Each element serves a specific audit or regulatory purpose.

Element 1: The AI tool identifier and version. Document which AI tool was used and what version. This matters because AI model performance changes with version updates; the reliability of the tool in use at the time of the action is determined by the version, not the product name. If a reliability event is investigated months after the action, the investigation needs to know which model version was in use. The version record also supports CIP-010 change management: the tool in the compliance documentation must match the tool version in the IT asset inventory.

Element 2: The input data provenance. Document what data the AI used as input, where that data came from, and when it was current as of. This is especially important for real-time operations: an AI summary based on SCADA data from two hours ago is a fundamentally different product from one based on data from two minutes ago. The provenance record tells the reader what the AI knew, not just what it said.

Element 3: The AI output as received. Retain the actual AI output, including the full text or structured data of the summary, recommendation, or draft. Do not summarize or paraphrase the AI output in the record; the actual output is the artifact. This matters because if a discrepancy arises later between what the AI said and what the operator claims the AI said, the original output record is the authoritative reference. It also enables quality review: if AI outputs are being retained, a periodic audit of those outputs can assess accuracy trends and identify systematic biases that require model adjustment.

Element 4: The human verification record. Document what the qualified human professional verified before acting on or approving the AI's output. This is the most important element for regulatory purposes. The verification record should specify: which specific claims in the AI output were checked, against which authoritative source, and what the check found. A verification record that says "operator verified" is insufficient; it must say "operator confirmed equipment IDs T-47C and T-48B against model book on [date], confirmed SCADA status for both as de-energized on EMS display at [timestamp]." This specificity is what makes the record a usable audit artifact rather than a checkbox.

Element 5: The human decision and its rationale. Document what the qualified human decided based on the AI output plus the verification, and why. For a switching action, this is the switching authorization and the operator's confirmation that the action was consistent with the switching procedure. For a forecast submission, this is the forecaster's sign-off and any overrides or adjustments made to the AI's output with the reasoning. For a compliance document, this is the compliance professional's certification and the verification summary. The decision record creates the accountability chain: a named human made this decision on this date based on this verified information.

NERC Documentation Requirements Applied to AI-Assisted Work

NERC reliability standards create specific documentation requirements for utility operations and planning functions. Most of these requirements were written before AI was in the workflow, but they apply regardless. Understanding how they apply to AI-assisted work is the compliance professional's job.

For transmission operations (TOP standards), operators must operate within their System Operating Limits (SOLs) and document the actions they take during real-time operations. When an AI tool recommends an action to manage a constraint, the documentation requirement is for the action taken by the operator, including the operator's confirmation that the recommended action was within the applicable procedure. The AI's recommendation is context; the operator's authorized action is the compliance artifact. The log entry should show the AI recommendation received and the operator's analysis before action, not just the action taken.

For transmission planning (FAC standards), planning studies must be performed under defined methodologies, and the study results must be documented. When AI tools assist with study setup, sensitivity analysis, or narrative drafting, the documentation must show that the study methodology was followed, the AI-generated inputs were reviewed for accuracy, and the study outputs were verified against the power flow model by qualified engineers. The AI's contribution to the study process should be disclosed in the study report so that readers can assess its scope and any limitations.

For reliability coordinator operations (IRO standards), real-time situational awareness and inter-entity communications are subject to documentation requirements. If AI tools are used to synthesize situational information from multiple sources, the documentation must show that the synthesized output was verified before it was used to make operational decisions or communicated to other entities.

CIP-003-9 and CIP-010 create documentation requirements for any AI system that is a BCS or that touches BCS data. As covered in the OT boundary lesson, the change management record for the AI tool, the access control log, and the training records for operators are all required documentation elements. These documentation requirements apply independently of whether a specific action was taken; they are baseline compliance records that must exist for the tool itself, not just for individual uses of it.

State Commission Documentation Standards for AI-Assisted Filings

When a utility files an AI-assisted work product with a state commission (a load forecast, an IRP, a rate case exhibit, a DER program filing), the commission's data request process will examine the underlying documentation of that work product. State commissions have become significantly more sophisticated about AI involvement in utility work since 2024, and their data requests now commonly include questions about whether AI was used and what oversight was applied.

The documentation a utility needs to answer commission data requests for AI-assisted filings has three components. First, the disclosure: a statement in the filing itself (or a supplemental disclosure if required by commission order) that AI tools were used in preparing specific portions of the work product, identifying which portions and in what role. This disclosure is now an expectation in multiple state PUC proceedings, not just a courtesy. Second, the methodology description: a description of how the AI tool was used, what data it received, and what oversight was applied, sufficient to allow the commission's staff to assess the reliability of the AI-assisted work product. Third, the verification summary: a summary of the verification steps applied to AI-generated content before it was included in the filing, including the sources checked and the human reviewer's qualifications. This summary demonstrates that the AI was a drafting tool under qualified human oversight, not an autonomous data generator.

The specific language needed in a commission filing may vary by jurisdiction, but a general pattern serves most contexts: "Certain sections of this filing were prepared with the assistance of [AI tool type, not brand name]. All AI-generated content was reviewed and verified by [qualified professional title] against [specific authoritative sources] before inclusion. The conclusions and recommendations in this filing represent the professional judgment of [name, credentials] and are not statements of the AI system."

Building the Audit Trail That Survives an Investigation

The documentation that looks sufficient in normal operations is often insufficient under investigation. The difference is specificity: a post-event investigation asks precise questions that a general record cannot answer. Building documentation to survive an investigation means building it to answer those precise questions at the time of the work, not after the fact.

Three questions that a NERC compliance investigation will ask for any AI-assisted operational action: Who specifically was the operator, what were their qualifications, and can you show me their training record that covers this specific AI tool? What specific data did the AI receive as input at the time of the action, and was that data current? What specifically did the operator verify before executing the switching step, and can you show me that verification in the contemporaneous record, not in a post-event reconstruction?

Three questions that a state commission investigation will ask for any AI-assisted filing: Which specific sections were AI-generated or AI-assisted? What was the qualification and oversight responsibility of the reviewer? Can you show me the specific regulatory or factual claim that the reviewer personally confirmed against an authoritative source, not a general statement that "the document was reviewed"?

The documentation that survives these questions is the documentation that was built with these questions in mind. This means: operator training records that specifically name the AI tools the operator was trained on; input data timestamps that show when the AI received its information; verification records with named sources and specific findings; and decision records that explicitly connect the human's analysis to the AI's input.

A documentation template designed for AI-assisted grid work, embedded in the standard operating procedure and required as a completion condition before any AI-assisted action is executed or filed, converts these requirements from individual discipline to systemic practice. The template is the audit product; the specific work fills in the template.

Worked Example: A Documentation Failure and Its Cost

A regional transmission organization used AI to assist operators in drafting real-time operating instructions during a high-load summer day with multiple line outages. The operators followed the AI recommendations, which appeared to be accurate and consistent with their operating experience. The situation resolved without a reliability event.

Three months later, NERC opened a compliance review of the utility's real-time operations that day after reviewing post-event data. The review asked for documentation of the operating decisions made during the high-load period. The compliance team pulled the operator logs. The logs showed the actions taken but not the basis for those actions: no reference to the AI tool's recommendations, no record of what the AI received as input, no record of what the operators verified before acting. The AI's involvement was completely invisible in the documentation.

The compliance review then asked whether the operators had received training on the AI tool they used. The training records did not specifically name the AI tool; they referenced a general "digital tools" training module. The CIP compliance team could not produce documentation showing that the AI tool was in the CIP asset inventory or that it had gone through change management review.

No reliability event occurred. The operators probably made good decisions. But the utility could not document that the decisions were made correctly, by qualified operators, under approved procedures that specifically covered AI-assisted operations. The result was a compliance finding for documentation deficiencies that required remediation, a revised training program, and a system-level documentation overhaul. The cost of the remediation exceeded the cost of building the documentation correctly from the start by a significant margin.

The lesson is not that the AI tool was a problem. The lesson is that deploying an AI tool without the documentation infrastructure to make its use visible and auditable creates compliance risk that materializes even when the operations themselves are sound.

Documentation Templates in Practice: What Good Looks Like

Knowing the five documentation elements is necessary but not sufficient; the way those elements are embedded in daily operational and compliance workflows determines whether they are consistently captured. Two practical template patterns cover the most common AI-assisted grid work scenarios.

For operational decisions (switching actions, restoration steps, real-time advice): the log entry or digital record should follow a standard four-line pattern. Line 1: "AI tool used: [generic tool type, version ID]. Input data source: [historian snapshot timestamp or EMS real-time, time as of]." Line 2: "AI output summary: [brief description of what the AI recommended, with specific equipment IDs listed]." Line 3: "Verification performed: [which equipment IDs confirmed against model book, which system state claims confirmed against EMS, specific discrepancies found if any]." Line 4: "Decision: [what the operator authorized and on what basis, any deviation from AI recommendation and why]." A four-line record takes 90 seconds to complete. It creates a complete audit artifact.

For compliance and planning documents: the document itself should include a standard header section titled "AI Assistance Disclosure." This section states: which sections used AI assistance; the AI tool type and version; the data sources the AI received; the name and qualifications of the reviewer who verified each section; and the specific sources checked for regulatory citations. This header is attached to every AI-assisted compliance document before it routes for signature. A reviewer who cannot complete the header has not performed the verification that the documentation requires.

These templates are not one-size-fits-all; they should be adapted to the specific workflows of each operational context. But the principle is consistent: the documentation must be a completion condition, not an afterthought. When filling in the template is how a document is finished or how a log entry is closed, the documentation happens. When it is treated as optional good practice, it does not.

Key Takeaways

• Documentation for AI-assisted grid work must contain five elements: the AI tool identifier and version, the input data provenance, the AI output as received, the human verification record with specific sources and findings, and the human decision with its rationale.
• NERC reliability standards apply to AI-assisted operations regardless of whether they explicitly mention AI: the operator's authorized action must be documented, the procedure must specify the AI's role, and the training record must cover the specific tools the operator used.
• CIP-003-9 and CIP-010 create documentation requirements for AI systems touching BCS data: the change management record for the tool, the access control log, and the training records are baseline compliance records that must exist for the tool regardless of whether a specific action was taken.
• State commission documentation for AI-assisted filings requires three components: disclosure that AI was used and in what role, a methodology description sufficient for staff to assess reliability, and a verification summary showing what was checked and by whom.
• Documentation that survives an investigation is documentation built to answer the specific questions an investigation will ask: who was qualified and trained, what data was current, what was specifically verified, and by whom.
• A documentation template embedded in the standard operating procedure and required as a completion condition before any AI-assisted action is executed or filed converts the documentation requirement from individual discipline to systemic practice.
• The cost of a documentation failure, in remediation effort and compliance findings, typically exceeds the cost of building documentation correctly from the start; the documentation infrastructure is not overhead, it is the protection that makes AI deployment defensible.