AI grid management can help a power team forecast conditions, identify abnormal behavior and evaluate operating choices. The buying decision becomes more consequential when software can change equipment settings or initiate an action. At that point, the specification must explain what the system may do, what evidence supports it and how the plant operates when it fails.
For a data center considering on-site generation, this is an integration question spanning the utility interface, campus controls and individual machines. A useful proposal describes those boundaries. A general claim that a product is “AI powered” does not establish its suitability for a particular plant.
This guide sets out SecondWatt's recommended procurement checks. Regulatory references were reviewed on September 25, 2026; the recommendations below are an editorial framework, not a new regulatory standard.
Key Takeaways
- Separate advisory analytics from software authorized to change operating conditions.
- Distinguish rules about large computational loads from guidance about using AI in grid operations.
- Require evidence for the proposed operating envelope, including degraded-data and fallback behavior.
- Specify equipment interfaces and acceptance tests before buying a control-system upgrade.
- Compare measured benefits against an agreed baseline; do not assume software creates firm electrical capacity.
Start with the decision the software will make#
The Department of Energy's 2024 AI for Energy overview identifies potential applications across planning, permitting, operations and resilience. That is a description of opportunities, not certification of a vendor or a guarantee of performance.
In an equipment request, replace broad capability labels with a specific task. Examples include predicting next-day campus demand, identifying a sensor anomaly, recommending a maintenance inspection or proposing how to distribute load among available generators. Each task needs different inputs and different acceptance criteria.
Ask the supplier to distinguish a recommendation from a command. An operator dashboard may display an inefficient dispatch pattern without changing anything. A controller with write access may adjust a setpoint. An independent protection system may act on a much faster timescale. Those functions should not be combined under a single approval statement.
| Proposed function | Evidence to request | Decision boundary to document |
|---|---|---|
| Demand forecasting | Error results over representative operating periods | Who uses the forecast and for which commitment |
| Condition monitoring | Confirmed events, false alarms and missed events | Who authorizes an inspection or outage |
| Dispatch advice | Comparison against the existing dispatch method | Which recommendations need operator acceptance |
| Automated optimization | Tested operating limits and failure responses | Which settings the software can change |
| Documentation assistance | Traceable source records and review workflow | Who verifies the output before it is relied upon |
This classification also makes bids more comparable. A low-cost analytics license and a fully integrated plant controller should not be evaluated as if they provide the same service.
Keep AI governance and large-load regulation separate#
NERC's white paper on AI and machine learning in real-time system operations discusses operational use, human factors and associated risks. Its November 2024 revision provides guidance; it does not establish that every system marketed as AI meets a reliability requirement.
By contrast, FERC's July 2026 computational-load directive concerns new or modified reliability standards and related registration criteria. NERC's submissions are due December 31, 2026. That filing deadline should not be described as a universal deadline to install AI controls or register every data center.
FERC's June 2026 large-load actions address regional tariff treatment, including study and service arrangements. They do not certify a campus optimization platform.
For procurement, maintain separate records for software assurance, equipment performance and applicable obligations. Ask the project advisers to identify actual requirements for the entity and facility. Do not let a supplier substitute a reference to an active proceeding for a demonstration that its product satisfies the relevant specification.
Require a usable data specification#
A model's claimed accuracy means little without a description of the data on which it was tested. Ask for the measurement points, sampling intervals, timestamp handling, units and data-quality checks. Identify whether training and validation included conditions similar to the proposed site.
Then ask what happens when reality differs. A new tenant, revised cooling arrangement, generator replacement or changed utility import limit can alter the operating environment. The system should have a documented process for detecting that change and deciding whether its previous validation remains adequate.
A practical data schedule should identify:
- The owner of each measurement and the system of record.
- Which values are measured, estimated or manually entered.
- How missing, delayed and contradictory readings are identified.
- Who may correct records and how corrections are logged.
- How long raw inputs, recommendations and actions are retained.
Define access to these records before signing the contract. The owner should be able to investigate an event without depending entirely on a vendor's summary of what occurred. If a service uses a remote platform, specify what remains available during a communications outage and how local operators obtain the information they need.
Test the system outside the favorable demonstration case#
A demonstration should answer a buying question. If the claimed benefit is lower fuel use, agree on the operating conditions, measurement boundary and comparison method. If the claimed benefit is earlier detection of a fault, define what constitutes a useful warning and how false alarms will be assessed.
Our recommended acceptance sequence starts with historical replay or simulation, proceeds to supervised observation and introduces operational authority only after the applicable engineering review. The sequence and duration should reflect the risk of the function, rather than a universal number of trial days.
Include representative load changes, unavailable equipment, communications loss and bad sensor data. Evaluate how the system returns to normal operation after the disturbance. Record which cases were simulated and which were demonstrated on the installed system; they provide different kinds of evidence.
NIST's AI Risk Management Framework is voluntary guidance for managing AI risk. It can help structure the review, but a statement that a product “follows NIST” should be supported by actual procedures, responsibilities and test records.
The output of acceptance testing should be a defined operating envelope and a list of exceptions. A pass on one configuration should not silently authorize different equipment, larger loads or a more autonomous operating mode.
Preserve the engineered protection and fallback arrangement#
Human oversight needs a precise meaning. Operators should understand the system's authority, alarms and fallback state. That does not mean every protective action should wait for human confirmation; the protection engineer must preserve the response required by the electrical design.
Ask the integrator to document interactions between optimization logic, generator controls, relays, synchronizing systems and utility requirements. Identify which function takes priority when two commands conflict. Confirm that a software update cannot silently change those priorities.
NIST's Guide to Operational Technology Security, Revision 3 addresses security alongside OT performance, reliability and safety. Use that context to examine remote access, account permissions, network boundaries, update procedures and incident recovery. A general enterprise-software security questionnaire is not a complete plant-control review.
For a campus with gas turbines, specify the exact package and controls configuration. A model family name does not identify the installed controller, communications options or authorized operating modes. SecondWatt's gas turbine RFQ checklist helps organize the equipment documents that should accompany that discussion.
Compare benefits without inventing additional capacity#
Software may help a team use equipment more effectively, but any claim of additional usable megawatts needs a clear basis. Ask whether the number represents modeled potential, a tested operating point, a temporary condition or an approved change to a limit.
The distinction matters commercially. An improvement in forecast accuracy does not itself change a utility service agreement. A dispatch recommendation does not establish the net output of a turbine at a hot site. Use a separate engineering assessment for site conditions and gas turbine derating.
For economic comparisons, request a baseline that both parties can reproduce. Record fuel prices, load, ambient conditions, outages and other changes that may affect results. Report observed improvements with their measurement period and limitations. Avoid translating a short trial into guaranteed annual savings without an agreed method and sufficient evidence.
Include integration engineering, instrumentation, cybersecurity work, software subscriptions, training and support in the comparison. A license price alone does not describe the installed cost or the operational commitment.
Put accountability into the purchase agreement#
Assign an owner for the model, the operational decision and the equipment interface. These may be different organizations. The contract should specify who investigates an incorrect recommendation, who can disable the function and who approves its return to service.
Ask how updates are tested, how previous versions can be restored and what happens if the vendor stops supporting the platform. Preserve access to configuration files, event logs and essential documentation in a usable format. Include the costs and responsibilities for a future equipment change.
Before release, assemble a concise acceptance record: intended use, authority limits, supported configuration, test results, unresolved exceptions, recovery procedure and named operational owner. This is more useful to the next shift than a promotional description of the algorithm.
If the project also needs generation or electrical equipment, send SecondWatt the equipment requirement with the operating mode, site conditions and interface requirements. Equipment sourcing and control-system acceptance should remain coordinated workstreams with explicit responsibilities.
Frequently asked questions#
Is all automated grid control AI?#
No. Ask the supplier to identify the actual method and the function it performs. Established automation, measurement equipment and protective logic should not automatically be labeled AI.
Does AI optimization replace a utility interconnection study?#
Do not assume that it does. Obtain the applicable service provider's requirements and confirm whether the proposed controls affect the study assumptions or operating limits.
Should AI directly control a gas turbine?#
That decision requires a package-specific engineering and operational review. Define authority, independent protections, test evidence and fallback behavior before enabling a control function.
What is the most useful evidence of a vendor's claimed savings?#
An agreed comparison using representative operating data, a stated measurement boundary and disclosed assumptions. The report should distinguish measured results from estimates and identify other changes during the trial.