AI security review for energy & utilities

Energy and utilities AI is not a standard enterprise deployment. AI systems in this sector operate within — or adjacent to — operational technology that controls physical infrastructure: power generation, transmission grids, gas distribution, water treatment. The failure mode is not data breach or compliance fine — it is physical safety, grid instability, or loss of supply to millions.

Three factors make energy AI uniquely difficult to clear:

• IT/OT convergence. AI systems trained on IT-side data increasingly feed decisions into OT-side control systems. A predictive maintenance model that recommends turbine shutdowns, or a demand-response AI that adjusts grid parameters, crosses the IT/OT boundary — and inherits the safety-critical posture of the OT environment it influences.
• Federated delivery across business units. Large energy companies operate generation, transmission, distribution, and retail as separate legal entities or regulated divisions. Each AI deployment may cross regulatory perimeters, data sovereignty boundaries, and separate OT security zones — making a single “enterprise AI policy” insufficient.
• Safety-critical reliability requirements. Grid management AI cannot afford the tolerance for hallucination or non-determinism that enterprise chatbots accept. When an AI recommendation influences load balancing or protection relay settings, the acceptable failure rate is measured in N-1/N-2 contingency standards, not SLA percentiles.

General-purpose AI threat models miss the attack surfaces that matter in energy:

• Prompt injection in grid management AI. An AI assistant used by control room operators to query SCADA historian data or recommend operational adjustments is a high-value target. Prompt injection here does not just leak data — it can influence operational decisions on systems with physical consequences.
• Agentic AI with SCADA/DCS tool access. AI agents that can read from — or worse, write to — SCADA systems, distributed control systems, or energy management systems require approval boundaries that no standard enterprise AI governance framework considers. The blast radius of an unconstrained agent action is not a database corruption — it is a protection system override.
• RAG over operational data with sovereignty constraints. A retrieval-augmented generation system indexing operational procedures, incident reports, and engineering specifications must respect data sovereignty across regulated entities. Embedding a transmission operator's protection settings alongside retail customer data violates regulatory separation — and standard RAG architectures do not enforce document-level access controls at the retrieval boundary.
• Multi-cloud AI across generation, retail, and grid. Energy companies often run different AI workloads across multiple cloud providers and on-premises infrastructure (generation analytics on-prem near plants, customer AI on hyperscaler, grid AI in a sovereign cloud). Each deployment topology has different trust boundaries, different data residency obligations, and different attack surfaces — a single architecture diagram misses the boundary complexity.
• Supply chain AI poisoning. AI models trained on vendor-supplied data (turbine performance curves, grid simulation models) inherit supply chain risk. A compromised training dataset for a predictive maintenance model could mask equipment degradation or create false maintenance urgency — both with physical safety implications.

Drel maps every assessment to the frameworks most relevant to energy critical infrastructure:

• EU AI Act — critical infrastructure provisions — AI systems managing critical infrastructure (energy, water, transport) are classified high-risk under Annex III; Article 9 risk management obligations apply
• NIS2 Directive — essential entity obligations for cybersecurity risk management; AI systems are part of the ICT supply chain and network/information systems that NIS2 governs
• IEC 62443 — industrial automation and control systems security; the standard that governs the OT zones your AI may influence or operate within
• ISO/IEC 42001 — AI management system evidence for clauses 6 (planning) and 8 (operation), mapped to energy-specific risk context
• NIST AI RMF — govern, map, measure, and manage AI risk — with critical infrastructure profile considerations from NIST CSF
• OWASP LLM Top 10 & Agentic Top 10 — controls for LLM and agentic AI risks mapped to the energy-specific threat scenarios above

Energy organisations already have mature OT security governance — IEC 62443 zone/conduit models, ISA-95 level segmentation, and operational change management processes. Drel does not replace these. It produces the AI-specific risk assessment that feeds into them.

The structured output — threat model, control plan, evidence gaps, disposition, and re-assessment triggers — maps directly to the inputs your OT security team needs to evaluate whether an AI system is safe to deploy within or adjacent to an IEC 62443 security zone. The control plan identifies which controls are before_pilot(must be verified before any OT-adjacent testing) and which are ongoing(continuous monitoring once deployed).

Re-assessment triggers are configured for energy-relevant changes: model version updates, new tool access grants (especially SCADA read/write), data source changes that cross entity boundaries, autonomy increases beyond current approval boundaries, and vendor changes in the AI supply chain. When any trigger fires, the original clearance record flags for re-review — your OT governance process knows immediately when an AI system's risk profile has changed.