The pre-launch checklist utilities can't skip, MBA Training, MBA Training
4/4+150 XP
The pre-launch checklist utilities can't skip
# The pre-launch checklist utilities can't skip
At 2:14 AM on a winter night, an AI-driven load-forecasting model at a mid-size US utility underestimates demand by 8%. Grid operators have four minutes to decide: trust the model's revised forecast, or override it and dispatch reserve generation manually. This is not a hypothetical. It is the exact scenario that pre-launch governance is built to survive. If the override path is unclear, undocumented, or slower than the crisis itself, the checklist failed before the model ever went live.
This lesson gives you that checklist: the concrete, non-skippable steps before any AI system touches grid operations, dispatch, or customer billing decisions.
Why utilities can't treat this like a normal software launch
Energy AI systems sit closer to physical safety and critical infrastructure than most enterprise software. A recommendation engine suggesting the wrong movie is low stakes. A model mispricing demand response signals or misjudging transformertransformerA Transformer is a neural network architecture that uses self-attention to process sequences in parallel, powering most modern language and generative AI models.Voir la définition complète → load is not.
Regulators agree. In the US, the Federal Energy Regulatory Commission (FERC) and the North American Electric Reliability Corporation (NERC) enforce reliability standards (like the CIP, Critical Infrastructure Protection, series) that already assume any automated control system can fail and must have a human fallback. In the EU, the AI Act (entered into force 2024, phased obligations through 2026-2027) classifies AI used in critical infrastructure, including energy, as "high-risk," triggering mandatory risk management, logging, and human oversight requirements before deployment. See the
Translation: for grid-touching AI, governance isn't a nice-to-have. It's a legal precondition in the EU and a de facto reliability obligation in the US.
The four pillars of a go-live checklist
1. Human-in-the-loop override
Every AI system that can change grid state or customer outcomes needs a defined human checkpoint, before deployment, not improvised during an incident.
Concrete requirements:
A named role, not "the ops team," who has authority to override the model. At many transmission operators this is the shift supervisor or NERC-certified reliability coordinator.
A maximum override latency. If the model recommends a dispatch action, how many seconds does the human have to intervene before it auto-executes? For fast-acting systems (frequency regulation, automatic generation control) this can be sub-second, which means the override has to be a pre-set circuit breaker, not a person reading a screen.
A clear interface signal. The system must visibly flag when it's operating in "AI-recommended" versus "AI-autonomous" mode. Operators at Southern California Edison and other utilities piloting AI-based wildfire risk models require this mode indicator as standard practice.
2. Fallback protocols
Fallback is what happens when the model is wrong, unavailable, or the data feed breaks.
Checklist items:
A validated non-AI baseline. Before go-live, confirm the legacy method (rule-based load forecasting, manual meter estimates) still works and staff are still trained on it. Do not let the AI system become the only institutional knowledge.
Degradation thresholds. Define in advance: if model confidence drops below X%, or input data is stale by more than Y minutes, the system auto-reverts to the fallback. Write the number down. "Revert when it looks wrong" is not a threshold.
Tested failover, not theoretical failover. Run a live drill where the AI system is switched off mid-operation and the fallback takes over, before the real launch.
3. Audit trails
An audit trail is the recorded history of what the model saw, predicted, and recommended, and what a human did next. Without it, you cannot investigate an incident, defend a regulatory inquiry, or improve the model.
Minimum viable audit trail for an energy AI system:
This should be immutable (write-once) and retained per your regulator's data retention rules. FERC-regulated entities typically retain grid operational records for several years; check current NERC retention standards before setting your policy, as they are periodically updated.
Audit trails also support model drift detection: comparing today's prediction accuracy against launch-time accuracy. If a demand forecasting model's error rate creeps from 3% to 9% over eight months, the audit trail is how you catch it, not customer complaints.
4. Incident response
This is your pre-written plan for when something goes wrong, tested before launch, not drafted after.
A real incident response plan for AI in energy operations includes:
Severity tiers. Tier 1: model gives a slightly stale price signal to a demand-response customer app. Tier 3: model contributes to an unplanned load shed. Each tier has a different response team and notification obligation.
Regulatory notification triggers. In the US, certain grid disturbances must be reported to NERC/FERC within defined windows. In the EU, the AI Act requires providers of high-risk AI systems to report serious incidents to national authorities. Know your trigger conditions before go-live, not during the incident.
Customer communication templates, pre-approved by legal and comms, for cases where AI-driven billing or disconnection decisions affected customers incorrectly. This matters especially for AI-assisted disconnection risk scoring, an area consumer advocates and state utility commissions increasingly scrutinize.
Post-incident model rollback capability. You must be able to revert to the previous model version within a known, tested time window.
The main AI risks this checklist is defending against
Model risk: the model is confidently wrong (e.g., a solar generation forecast miscalibrated after a rare weather pattern).
Data drift: the world changed (new EV charging patterns, new smart meter rollout) and the model trained on old patterns no longer fits.
Automation bias: operators start trusting the AI recommendation reflexively, eroding the value of the human-in-the-loop check.
Opaque decision-making: for customer-facing decisions (credit scoring for energy plans, disconnection risk), inability to explain "why" creates regulatory and fairness exposure under emerging AI Act transparency obligations and, in the US, state-level consumer protection rules.
Vérification des acquis
1. In the load-forecasting scenario described, what is the actual failure point if grid operators can't act in time?
2. Why does the lesson argue that AI governance for utilities is different from a 'normal software launch'?
3. How do US reliability standards (FERC/NERC CIP) and the EU AI Act converge on the same underlying requirement for grid-touching AI?
CHOIX MULTIPLES
4. Select ALL correct answers about why 'human-in-the-loop override' is treated as a non-skippable pillar for utility AI launches.
Sélectionnez toutes les réponses correctes.
CHOIX MULTIPLES
5. Select ALL correct answers about how the EU AI Act treats AI systems used in critical infrastructure like energy.
Sélectionnez toutes les réponses correctes.
A minimal pre-launch sign-off table
Before go-live, require sign-off across these lines, each owned by a named function:
| Checklist item | Owner | Evidence required |
|---|---|---|
| Human override role defined and trained | Operations | Signed training log |
| Fallback tested live | Engineering | Drill report with timestamp |
| Audit trail schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Voir la définition complète → implemented | IT/Data | Sample log extract |
| Model drift monitoring live | Data Science | Dashboard screenshot |
If any row is blank, the system is not ready, regardless of how good the model's accuracy metrics look in testing.
🎬 [VIDEO: "How the Texas Grid Failure Happened" - youtube.com/results?search_query=texas+grid+failure+explained - a useful primer on how cascading operational failures unfold in grid systems, relevant context for why fallback and override design matters even without AI in the loop]
Key Takeaways
Human-in-the-loop overrides need a named role, a maximum response latency, and a visible mode indicator, defined before launch, not during a crisis.
Fallback protocols require a working non-AI baseline and pre-set numeric thresholds for when the system reverts, tested live before go-live.
Audit trails must capture inputs, predictions, confidence, human decisions, and outcomes in immutable logs, both for incident investigation and drift detection.
Incident response plans need severity tiers, regulator notification triggers (FERC/NERC in the US, AI Act incident reporting in the EU), and pre-approved customer communication.
None of this is optional for high-risk energy AI: the EU AI Act mandates it for critical infrastructure, and US reliability standards assume it implicitly. Treat the checklist as a regulatory floor, not a best practice ceiling.