1. Introduction

Artificial intelligence is increasingly being incorporated into critical infrastructure, including electricity grids, energy-management systems, autonomous control systems, predictive-maintenance platforms, trading systems, industrial plants and smart-grid networks. These systems can make decisions at speeds and levels of complexity that exceed conventional human supervision. At the same time, an AI-caused failure can produce consequences extending far beyond the immediate malfunction—for example, grid instability, equipment damage, interruption of electricity supply, financial losses, environmental harm or personal injury.

The central legal problem is therefore allocation of liability: when an AI-controlled system causes a failure, who should bear the resulting loss—the AI developer, hardware manufacturer, system integrator, infrastructure operator, electricity utility, data provider, maintenance contractor, cybersecurity provider, or human decision-maker?

Traditional negligence and product-liability principles generally assume that a human can identify the relevant wrongful act or defective product. AI complicates this assumption because the system may learn after deployment, operate autonomously, depend upon third-party data and produce an outcome that was not expressly programmed by any individual.

The European Union's revised Product Liability Directive is particularly important because it expressly brings software, including AI systems, within the concept of products and addresses defects arising from software updates and machine-learning systems remaining under a manufacturer's control. EUR-Lex

2. Meaning of an AI-Caused System Failure

An AI-caused system failure occurs when an AI system's design, training, deployment, operation, updating or interaction with another system contributes materially to damage or disruption.

Examples include:

• an AI grid-management system incorrectly disconnecting transmission assets;
• predictive-maintenance AI failing to detect deterioration in a transformer;
• an AI trading system generating destabilising electricity-market transactions;
• an autonomous energy-management system incorrectly balancing supply and demand;
• defective training data causing unsafe operational decisions;
• an AI cybersecurity system incorrectly blocking legitimate grid-control communications;
• a software update causing an AI controller to behave unpredictably;
• an operator relying excessively on an AI recommendation despite warning signals.

The important legal point is that “AI made the decision” does not itself answer the liability question. Legal responsibility must normally be traced through the entire socio-technical system.

3. Why AI Creates a Special Liability Problem

A. Multiple actors

An AI-enabled energy system may involve:

1. AI developer;
2. software supplier;
3. hardware manufacturer;
4. data provider;
5. system integrator;
6. infrastructure owner;
7. electricity utility;
8. AI operator;
9. maintenance contractor;
10. cybersecurity provider; and
11. human supervisor.

A single failure can therefore involve concurrent causes.

B. The black-box problem

Complex machine-learning systems may make decisions that are difficult to reconstruct. This creates an evidentiary problem: the injured party may know that an AI-controlled system caused the failure but may not know precisely why the AI produced the relevant output.

The European Commission has expressly recognised that AI can make it difficult for injured persons to obtain the evidence necessary to establish defect and causation. EUR-Lex

C. Continuous learning

Traditional products generally have a relatively identifiable condition when placed on the market. AI systems may change through updates, retraining or machine learning.

The revised EU Product Liability Directive expressly addresses defects arising after deployment where they result from software, related services, updates, upgrades or machine-learning algorithms remaining under the manufacturer's control. EUR-Lex

D. Human-AI interaction

A failure may result from a combination of:

defective AI + inadequate supervision + poor maintenance + faulty infrastructure.

Consequently, imposing all liability on either the developer or operator may not reflect the actual causal structure.

4. Principal Bases of Liability

A. Negligence

Negligence remains one of the most important bases for AI liability.

The claimant generally has to establish:

1. a duty of care;
2. breach of that duty;
3. causation; and
4. legally recognised damage.

For an AI developer, negligence could arise from inadequate testing, inadequate risk assessment or failure to correct known defects.

For an electricity operator, negligence could involve deploying an AI system without adequate validation, failing to supervise it or failing to maintain appropriate fallback mechanisms.

AI-specific standard of care

The standard of care should generally be assessed according to the reasonably foreseeable risks associated with the particular AI application.

The standard should be particularly demanding where AI controls inherently dangerous infrastructure such as electricity transmission.

5. Strict Liability and Dangerous Electricity Systems

Electricity law provides an important conceptual foundation for AI-controlled infrastructure.

Indian courts have repeatedly recognised the hazardous character of electricity and imposed significant responsibility upon electricity authorities.

In Rajya Vidhyut Vitran Nigam Ltd. v. Ramwati Devi (2022), the court discussed Rylands v. Fletcher and held that electricity suppliers can face strict liability for harm associated with electricity infrastructure. Indian Kanoon

Similarly, Indian decisions have emphasised that electricity distributors have a heightened obligation to prevent foreseeable harm because electricity constitutes an inherently dangerous activity. Indian Kanoon

This principle becomes significant where AI controls the electricity system.

For example:

AI controller → erroneous command → substation failure → live-wire accident

The utility might argue that the AI independently generated the command. That argument does not necessarily eliminate the utility's responsibility for operating a dangerous electricity network.

The legal question may instead be whether the utility had adequately controlled, tested, monitored and safeguarded the AI system.

6. Product Liability

Product liability becomes particularly important where an AI-enabled device or software component is defective.

The revised EU Product Liability Directive expressly treats software, including AI systems, as products within its framework. It also addresses AI systems that continue to learn under the manufacturer's control. EUR-Lex

Potential defects may include:

• design defects;
• manufacturing defects;
• inadequate safety instructions;
• defective software;
• inadequate cybersecurity;
• defective updates;
• defective AI training;
• insufficient safeguards.

The EU framework also recognises liability of manufacturers of defective components and, in appropriate circumstances, other economic operators such as importers and authorised representatives. EUR-Lex

This is particularly relevant to complex energy infrastructure because an AI controller can function as a component of a larger physical product or system.

7. Contractual Liability

AI systems are frequently supplied through contracts.

An energy company might contract with:

• an AI vendor;
• cloud provider;
• software developer;
• equipment manufacturer;
• maintenance company.

Contracts may allocate responsibility through:

• warranties;
• indemnities;
• service-level agreements;
• limitation-of-liability clauses;
• performance guarantees;
• cybersecurity obligations;
• maintenance obligations;
• insurance requirements.

However, contractual allocation does not necessarily determine liability toward third parties who were not parties to the contract.

Thus, an AI developer might contractually indemnify a utility, while an injured third party could still pursue the utility under applicable tort, statutory or public-law principles.

8. Liability of the AI Developer

The developer may bear responsibility where the failure results from:

• defective architecture;
• inadequate testing;
• flawed training;
• unsafe algorithms;
• known software vulnerabilities;
• failure to provide necessary safety instructions;
• defective updates;
• foreseeable misuse that was not adequately addressed.

The EU's revised Product Liability Directive is important because it recognises that software-related defects can arise after the product has entered the market when the manufacturer retains control over relevant software changes. EUR-Lex

However, the developer should not automatically be responsible for every operational failure. Liability should depend upon the relationship between the developer's conduct or product defect and the damage.

9. Liability of the Infrastructure Operator

For critical infrastructure, the operator often occupies a central position.

An electricity utility normally determines:

• whether an AI system is suitable;
• where it is deployed;
• what authority it receives;
• how it is monitored;
• what human oversight exists;
• what emergency controls exist;
• whether the system remains operationally safe.

Consequently, an operator may be liable where it:

• deploys an inadequately tested system;
• ignores known warnings;
• fails to maintain the system;
• fails to update software;
• removes human safeguards;
• gives AI excessive operational authority;
• fails to maintain manual fallback systems.

Indian electricity cases support the broader proposition that electricity authorities have substantial duties regarding the safety and maintenance of electricity infrastructure. For example, Renu Bala v. State emphasised the duty of those involved in supplying high-voltage electricity to take appropriate precautions. Indian Kanoon

10. Liability of the System Integrator

The integrator occupies an especially important position in AI-enabled infrastructure.

Suppose:

Developer A → supplies AI software
Manufacturer B → supplies transformer
Integrator C → combines them
Utility D → operates the system.

If the AI itself is safe in isolation but becomes dangerous because the integrator incorrectly connects it to the transformer-control system, liability may shift toward C.

The integrator's responsibilities can include:

• compatibility testing;
• cybersecurity testing;
• interface validation;
• system-level safety testing;
• configuration;
• documentation;
• fail-safe design.

Therefore, liability should not focus exclusively on the original AI developer.

11. Liability for Data Failures

AI decisions depend heavily on data.

A failure may originate from:

• inaccurate sensor data;
• incomplete historical data;
• corrupted data;
• biased datasets;
• delayed information;
• manipulated data;
• cybersecurity attacks.

Consider:

faulty sensor → incorrect AI prediction → incorrect grid decision → blackout.

Potential liability could involve both the AI developer and the operator depending upon who was responsible for data validation.

A sophisticated liability framework therefore needs to distinguish algorithmic defects from data defects.

12. Cybersecurity and Third-Party Interference

AI-controlled infrastructure is particularly vulnerable to cyberattacks.

Suppose:

hacker modifies AI input → AI makes unsafe decision → electricity infrastructure fails.

The causal chain might involve:

attacker → cybersecurity vulnerability → AI system → infrastructure failure → damage.

The existence of a third-party attacker does not necessarily eliminate the responsibility of the infrastructure operator.

The relevant questions include:

• Was the attack foreseeable?
• Were reasonable cybersecurity measures implemented?
• Was the vulnerability known?
• Were security updates installed?
• Did the operator follow industry standards?

The revised EU Product Liability Directive specifically recognises the continuing importance of software-related defects and digital technologies in determining product liability. EUR-Lex

13. Human Oversight and Supervisory Liability

AI systems are increasingly designed on the assumption that humans remain capable of intervention.

If an AI system provides an incorrect recommendation but a trained operator could reasonably have detected and prevented the resulting harm, responsibility may potentially be allocated to the operator.

Conversely, if the AI system was presented as autonomous and the operator was given inadequate information to intervene, the developer or integrator may bear greater responsibility.

The legal significance of human oversight therefore depends upon:

• the operator's training;
• available warnings;
• system explainability;
• time available for intervention;
• contractual responsibilities;
• industry standards;
• the severity of foreseeable harm.

14. Multiple Causes and Apportionment

AI failures frequently involve concurrent causation.

For example:

A modern liability framework should therefore permit proportionate allocation according to each actor's contribution.

An older European Parliament proposal concerning AI liability illustrates this approach: it contemplated contributory negligence and joint-and-several liability where multiple operators were involved. Importantly, this was a legislative proposal rather than the current operative EU liability regime. EUR-Lex

15. Joint and Several Liability

Joint and several liability can be particularly valuable where the injured person cannot determine precisely which actor caused the failure.

Suppose three companies jointly operated an AI-controlled grid system and a blackout caused major losses. If all three contributed to the failure, requiring the victim to identify the exact percentage of causation before obtaining compensation could make access to justice difficult.

Joint liability can therefore shift some of the complexity of internal allocation from the victim to the responsible participants.

The participants can subsequently resolve contribution between themselves according to:

• contractual terms;
• degree of fault;
• causal contribution;
• insurance;
• statutory rules.

16. Evidentiary Problems

One of the most difficult questions is:

Who has access to the evidence explaining what the AI actually did?

The operator or developer may possess:

• source code;
• logs;
• training records;
• model versions;
• telemetry;
• update histories;
• incident reports;
• system alerts.

The victim may possess none of these.

The EU has expressly recognised this information asymmetry as a problem in AI liability. EUR-Lex

Accordingly, legal systems may need:

1. disclosure obligations;
2. preservation of AI logs;
3. audit trails;
4. algorithmic documentation;
5. incident-reporting requirements;
6. technical expert evidence;
7. rebuttable presumptions in appropriate cases.

Without such mechanisms, conventional burden-of-proof rules can make AI liability disproportionately difficult to establish.

17. Relevant Case Law

1. Rylands v. Fletcher (1868)

This foundational English case established the classic strict-liability principle for dangerous things accumulated on land that escape and cause damage.

Its importance for AI-controlled electricity systems is conceptual: technological complexity does not necessarily eliminate responsibility for inherently dangerous activities.

Indian courts continue to refer to this doctrine in electricity cases. Indian Kanoon

2. M.C. Mehta v. Union of India (Oleum Gas Leak Case)

The Indian Supreme Court developed the doctrine of absolute liability for enterprises engaged in hazardous or inherently dangerous activities.

Its broader relevance to AI-controlled energy infrastructure is significant. Where an AI system operates as part of an inherently dangerous industrial activity, the enterprise may not necessarily avoid responsibility simply because the immediate operational decision was generated by an autonomous technological system.

The case therefore provides an important theoretical foundation for allocating responsibility to enterprises operating hazardous technologies.

3. Rajya Vidhyut Vitran Nigam Ltd. v. Ramwati Devi (2022)

The Rajasthan High Court discussed strict liability in relation to electricity and relied upon the hazardous nature of electrical energy. It recognised substantial responsibility for electricity authorities where inadequate maintenance contributes to electrocution. Indian Kanoon

This is directly relevant to AI-controlled electricity infrastructure because the AI layer does not remove the underlying hazardous nature of the electrical system.

4. Renu Bala v. State (2023)

The Jammu & Kashmir and Ladakh High Court emphasised the duty of entities involved in supplying high-voltage electricity to take adequate precautions to prevent uncontrolled discharge of electricity. Indian Kanoon

The case illustrates an important principle:

responsibility for safe electricity delivery can remain with the infrastructure operator even where the immediate cause of an accident involves a technological or operational failure.

5. Ajmer Vidyut Vitran Nigam Ltd. v. Sohani (2022)

The Rajasthan High Court discussed strict liability and the hazardous nature of electricity, relying on the principle that electricity suppliers must take appropriate precautions against foreseeable harm. Indian Kanoon

This provides a useful analogy for AI-controlled grids: the utility cannot necessarily treat the AI as a legal shield separating it from its statutory safety responsibilities.

6. Raj Kumar v. BSES Yamuna Power Ltd. (2026)

A Delhi court considered allegations involving poor maintenance of electricity wires and discussed strict liability, absolute liability and res ipsa loquitur in the context of an electrocution claim. Indian Kanoon

The case is useful in demonstrating the continuing relevance of traditional liability doctrines to technologically complex electricity systems.

18. A Proposed Liability Matrix for AI Energy Systems

A useful regulatory model can allocate responsibility according to the location of the failure:

This approach avoids the simplistic assumption that the AI itself should be treated as the liable actor.

19. AI Should Not Automatically Become a Separate Legal Person

A particularly important legal issue is whether an AI system itself should be treated as a legal person capable of bearing liability.

For present purposes, the stronger legal approach is generally to locate responsibility among the human and corporate actors who:

• design;
• manufacture;
• deploy;
• control;
• maintain;
• supervise; and
• profit from the AI system.

Giving AI independent legal personality would not necessarily solve the compensation problem because an AI system normally lacks independent assets, insurance and meaningful capacity to satisfy judgments.

Consequently, the more practical approach is human/corporate accountability combined with technical evidence and risk-based allocation.

20. Insurance as a Liability Mechanism

AI-related energy risks also require insurance reform.

Policies could address:

• AI malfunction;
• software defects;
• cyber incidents;
• business interruption;
• equipment damage;
• third-party injury;
• professional negligence;
• data corruption.

Insurance can provide compensation even where the precise allocation between developer and operator remains contested.

Contracts may then establish subrogation and contribution mechanisms between the participating companies.

21. Regulatory Implications

A comprehensive AI-energy liability framework should require:

1. Traceability

Every significant AI decision should generate an auditable record.

2. Version control

The system should identify the precise model/software version responsible for an operational decision.

3. Human oversight

Critical infrastructure should retain appropriate human intervention mechanisms.

4. Fail-safe mechanisms

AI failure should not automatically become physical infrastructure failure.

5. Incident reporting

Serious AI-related infrastructure failures should be documented and investigated.

6. Clear contractual allocation

Contracts should expressly address AI-specific risks.

7. Mandatory insurance

High-risk AI applications may justify minimum insurance or financial-security requirements.

8. Evidence preservation

Logs and relevant technical information should be preserved after major incidents.

22. Conclusion

Liability for AI-caused system failures cannot be resolved simply by asking “Who programmed the AI?” AI-enabled infrastructure operates through a chain of actors and technologies.

A legally sophisticated allocation model should examine:

design → data → integration → deployment → supervision → maintenance → cybersecurity → operation → damage.

Traditional doctrines such as negligence, strict liability, absolute liability, product liability and contractual liability remain relevant, but they must be adapted to AI's distinctive characteristics.

The electricity cases are particularly instructive. Indian courts have repeatedly treated electricity as a hazardous activity and imposed substantial safety responsibilities upon electricity authorities. Indian Kanoon

At the same time, the EU's revised Product Liability Directive represents an important development by expressly addressing software and AI, including defects arising from updates and machine-learning systems remaining under manufacturer control. EUR-Lex

The emerging principle can therefore be expressed as:

AI autonomy should not become an accountability gap.

Where AI controls critical infrastructure, liability should follow control, risk, causation and the capacity to prevent harm, rather than merely the location of the algorithm. This approach permits courts and regulators to distribute responsibility among developers, manufacturers, integrators, operators and other participants while preserving effective compensation for persons harmed by AI-enabled system failures.