1. Introduction

AI-driven systems increasingly make or influence decisions in electricity grids, energy trading, autonomous vehicles, industrial control systems, medical devices, financial platforms and other critical infrastructure. Unlike conventional machines, an AI system may learn from data, modify its behaviour through updates, interact with other systems and produce outputs that were not specifically programmed by any individual.

This creates a central legal question: when an AI-driven system causes harm, who should bear the legal responsibility—the developer, manufacturer, deployer, operator, data provider, system integrator, owner, or user?

Traditional liability law generally attributes responsibility to human or corporate actors through negligence, product liability, strict liability, vicarious liability, contractual obligations and statutory duties. AI does not itself ordinarily become the legal person responsible for the damage. Instead, the challenge is to determine which human or corporate actor exercised sufficient control over the relevant risk.

The European Parliament has previously articulated this principle: responsibility should generally attach to persons who create, maintain, control or interfere with the AI-related risk. EUR-Lex

For energy law, the issue is particularly important because an AI failure in a grid-management, dispatch, protection or trading system can produce cascading consequences: equipment damage, blackouts, market losses, safety incidents and environmental harm.

2. Meaning of an AI-Driven System Failure

An AI-driven system failure occurs when an AI-enabled system produces an unsafe, unlawful or materially defective outcome resulting in damage.

Examples include:

• an AI grid-management system incorrectly disconnecting transmission infrastructure;
• an AI forecasting system substantially underestimating electricity demand;
• an autonomous trading system creating abnormal market positions;
• an AI-controlled battery system overheating;
• predictive-maintenance software failing to identify an impending transformer failure;
• an autonomous vehicle making an unsafe decision;
• an industrial AI system sending an incorrect command to machinery;
• an AI cybersecurity system failing to detect an attack.

The legal difficulty is that the immediate physical cause may be an algorithmic decision, while the underlying causes may include defective software, poor training data, inadequate testing, insufficient human supervision, inappropriate deployment or failure to update the system.

3. The Fundamental Principle: Liability Should Follow Control Over Risk

A useful framework is:

The greater the actor's control over the relevant AI risk, the stronger the justification for allocating liability to that actor.

This does not necessarily mean that one participant bears all liability.

For example:

The European Union's modern product-liability framework expressly recognises this multi-actor structure. The EU Product Liability Directive 2024/2853 treats software, including AI systems, as products and provides for liability involving manufacturers, defective component manufacturers and certain other economic operators. EUR-Lex

4. Negligence-Based Liability

The first traditional basis is negligence.

Under negligence law, the claimant generally needs to establish:

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

The Supreme Court of India explained these basic elements in Jacob Mathew v. State of Punjab, (2005) 6 SCC 1, although the case concerned medical negligence rather than AI. The Court identified duty, breach and resulting damage as the fundamental components of actionable negligence. Indian Kanoon

Application to AI

An AI developer could potentially be negligent where it:

• failed to test foreseeable failure modes;
• deployed inadequately validated software;
• ignored known system vulnerabilities;
• failed to implement appropriate safeguards;
• failed to provide adequate warnings;
• used obviously unsuitable training data;
• failed to correct a known dangerous defect.

Similarly, a utility deploying an AI grid-management system could potentially be negligent if it:

• failed to conduct appropriate testing;
• deployed the system outside its validated operating conditions;
• ignored repeated abnormal outputs;
• failed to maintain human oversight;
• failed to implement emergency override mechanisms.

The difficult question is what constitutes reasonable care when the system is probabilistic and its exact output cannot always be predicted?

Courts will likely focus on the precautions that were reasonably available rather than requiring perfect prediction of every AI decision.

5. Product Liability

Product liability may be particularly important for AI because it can avoid some of the difficulties associated with proving individual negligence.

The EU's Directive 2024/2853 is especially significant. It expressly includes software and AI systems within the concept of products for no-fault product liability. It also covers software supplied through networks, cloud technologies and software-as-a-service models. EUR-Lex

Under this model, the claimant principally needs to establish:

defect → damage → causal relationship.

The claimant does not necessarily have to prove that the manufacturer was personally negligent.

AI-specific importance

The Directive recognises that AI products may continue changing after deployment. It therefore addresses:

• software updates;
• upgrades;
• cybersecurity vulnerabilities;
• continuous learning;
• related digital services;
• substantial modifications.

A manufacturer can remain responsible for defects arising through software or machine-learning algorithms under its control. EUR-Lex

This is highly relevant to AI systems because a system that was safe on day one may behave differently after:

• retraining;
• model updates;
• changes in data;
• software patches;
• integration with another system.

6. The Boston Scientific Case and AI

An important product-liability analogy is the CJEU decision in Boston Scientific Medizintechnik GmbH v AOK Sachsen-Anhalt, Joined Cases C-503/13 and C-504/13 (2015).

The Court held, in the context of medical devices, that where products belonging to the same model or production series have a potential defect, the entire group may be regarded as presenting an abnormal safety risk. curia

The principle is potentially relevant to AI.

Suppose an AI-controlled industrial controller has a design vulnerability affecting every system using the same model. It may be difficult to identify which individual system will fail. Product-liability reasoning can nevertheless focus on the systemic safety defect, rather than waiting until every individual system causes damage.

7. Liability for Continuous Learning

One of the most difficult problems is post-deployment learning.

Traditional product liability often assumes:

manufacturer → product → consumer.

AI may instead operate as:

developer → deployment → data → learning → modified behaviour → damage.

This creates a question of continuing responsibility.

The EU Product Liability Directive expressly recognises this problem. Where the manufacturer retains control over software or machine-learning functionality, defects resulting from continuing learning may remain relevant to liability. EUR-Lex

Thus, liability could potentially remain with the developer where:

• continuous learning was deliberately incorporated into the product;
• the developer retained control over the learning architecture;
• safeguards were inadequate;
• the resulting behaviour was a foreseeable consequence of the system design.

Conversely, responsibility may shift toward the deployer where the deployer independently retrains, modifies or substantially alters the system.

8. Liability of the AI Developer

The developer occupies an important position because it determines many of the system's fundamental characteristics.

Potential grounds of responsibility include:

A. Design defect

The architecture itself may create an unreasonable safety risk.

B. Training-data defect

The system may be trained using materially incomplete, inaccurate or inappropriate data.

C. Testing failure

The developer may have failed to test foreseeable edge cases.

D. Security failure

An AI system may be vulnerable to manipulation or adversarial attacks.

E. Inadequate warnings

Users may not be adequately informed about system limitations.

F. Failure to update

The developer may fail to issue a safety-critical software update.

The new EU regime specifically recognises software updates, cybersecurity vulnerabilities and AI learning as relevant to continuing product safety. EUR-Lex

9. Liability of the Deployer or Operator

The deployer decides how the AI system is actually used.

For example, an AI model may be reasonably safe when used for demand forecasting but unsafe when allowed to automatically control grid-switching decisions.

The deploying organisation may therefore be responsible where it:

• uses the system outside its intended purpose;
• ignores manufacturer warnings;
• fails to provide human supervision;
• uses unsuitable data;
• disables safety controls;
• fails to investigate abnormal outputs;
• allows the system to control critical infrastructure without adequate safeguards.

An earlier European Parliament proposal concerning AI civil liability explicitly connected operator responsibility with control over the risk generated by the system. EUR-Lex

That proposed framework is useful conceptually, but it should not be confused with the law currently in force.

10. Multiple Actors and Joint Liability

AI failures frequently involve several contributing actors.

Consider an AI electricity-management system:

Developer creates the model →
Vendor supplies the software →
Integrator connects it to the grid →
Utility deploys it →
Operator supervises it →
Cyber attacker interferes with it.

If the system fails, assigning 100% responsibility to one participant may be inappropriate.

Modern product-liability law increasingly recognises this problem. The EU Product Liability Directive provides for joint and several liability where two or more economic operators are liable for the same damage, while allowing recourse between responsible parties under national law. EUR-Lex

This creates a two-stage structure:

Stage 1: compensate the injured person.

Stage 2: determine contribution between responsible actors.

This approach can prevent victims from having to reconstruct the entire technical chain before obtaining compensation.

11. Contributory Negligence

Liability may also be reduced where the injured party contributed to the damage.

For example:

• a utility ignores repeated AI warnings;
• an operator disables an automatic safety mechanism;
• a consumer deliberately uses a system contrary to safety instructions;
• an infrastructure owner refuses necessary software updates.

The EU product-liability framework allows reduction where the damage was caused partly by the fault of the injured person. However, liability is not automatically eliminated merely because a third party contributed to the damage. EUR-Lex

This distinction is important for AI because many failures are socio-technical, involving both machine behaviour and human decisions.

12. Indian Law: Absolute Liability

Indian jurisprudence provides a particularly important framework for AI-driven failures in hazardous industries.

In M.C. Mehta v. Union of India (Oleum Gas Leak Case), AIR 1987 SC 1086, the Supreme Court developed the principle of absolute liability for enterprises engaged in hazardous or inherently dangerous activities. The Court held that such an enterprise owes an absolute and non-delegable duty to ensure that harm does not result from the hazardous activity. Indian Kanoon

Importantly, the Court stated that reasonable care would not itself be a defence where the principle applies.

Relevance to AI and energy

Suppose an AI system controls:

• a nuclear facility;
• a hazardous chemical plant;
• a major electricity infrastructure;
• an energy-storage installation;
• an industrial gas facility.

If the AI system causes a hazardous accident, the enterprise operating the dangerous activity may face a significantly stronger liability position than an ordinary software user.

The key principle is not that AI automatically creates absolute liability. Rather, where an AI system operates within an activity already subject to a special strict or absolute-liability regime, the AI failure does not necessarily displace that underlying liability regime.

13. Electricity-Sector Application

AI liability becomes especially important in electricity law because modern grids are becoming increasingly automated.

Consider an AI-based system responsible for:

• load forecasting;
• generation dispatch;
• demand response;
• voltage control;
• frequency management;
• outage prediction;
• transmission optimisation;
• battery management;
• electricity trading.

Suppose an AI-controlled dispatch system incorrectly forecasts demand, resulting in inadequate generation and a cascading blackout.

Possible responsibility could be analysed as follows:

The critical legal question becomes causal attribution.

14. Causation and the AI "Black Box"

Causation is perhaps the most difficult part of AI liability.

Traditional reasoning asks:

What did the defendant do that caused the injury?

With AI, the chain may be:

training data → model → software update → user input → sensor data → algorithmic inference → automated decision → physical action → damage.

Several actors may have contributed to different stages.

The EU's comparative research on AI liability identifies opacity, autonomy, complexity, connectivity and data dependency as important challenges for existing liability systems. Publications Office of the EU

This creates the possibility of an evidentiary gap: the injured party may know that an AI system caused the harmful event but may not possess enough technical information to identify precisely which actor caused the defect.

Consequently, modern legal frameworks increasingly emphasise:

• logging;
• documentation;
• traceability;
• access to technical information;
• safety records;
• system monitoring.

15. Res Ipsa Loquitur

Traditional evidentiary principles such as res ipsa loquitur may sometimes become relevant.

The doctrine essentially allows an inference of negligence in appropriate circumstances where the accident itself provides evidence that negligence probably occurred.

However, AI creates difficulties because an unexpected output does not necessarily prove negligence.

An AI system may produce an unusual output despite appropriate design and reasonable precautions.

Therefore:

AI failure should not automatically equal negligence.

The claimant still needs a legally sufficient basis for liability, unless a strict or absolute-liability regime applies.

The Supreme Court's reasoning in Jacob Mathew is useful in distinguishing civil negligence from more demanding criminal negligence standards. Indian Kanoon

16. Strict Liability Versus Fault-Based Liability

There are two principal approaches.

Fault-based approach

The claimant proves:

duty + breach + causation + damage.

Advantages:

• encourages careful behaviour;
• avoids imposing liability for unavoidable accidents;
• accommodates complex technologies.

Disadvantages:

• difficult for victims to prove;
• AI decision-making can be opaque;
• developers may possess most relevant evidence.

Strict liability approach

The claimant generally focuses on:

defect + damage + causation.

Advantages:

• easier access to compensation;
• places risk on entities better positioned to insure and manage it;
• avoids demanding technical proof of individual negligence.

Disadvantages:

• can increase costs for innovation;
• difficult questions remain concerning causation and the definition of defect.

The EU's 2024 Product Liability Directive adopts a no-fault product-liability framework for defective products, explicitly extending it to software and AI systems. EUR-Lex

17. Contractual Allocation of AI Risk

Commercial contracts can also distribute responsibility.

AI deployment contracts may include:

• indemnity clauses;
• warranties;
• service-level agreements;
• cybersecurity obligations;
• audit rights;
• data-quality requirements;
• performance guarantees;
• insurance requirements;
• limitation-of-liability provisions;
• incident-reporting duties.

However, contractual allocation does not necessarily eliminate statutory liability toward injured third parties.

Under the EU Product Liability Directive, contractual provisions cannot exclude or limit liability toward the injured person under the Directive. EUR-Lex

Contracts therefore primarily become important for recourse and risk allocation between commercial participants.

18. Regulatory Compliance as Evidence

Compliance with AI regulation may become relevant evidence in litigation.

For example, if an AI developer complied with applicable:

• risk-management requirements;
• testing requirements;
• documentation requirements;
• cybersecurity requirements;
• human-oversight requirements;

that compliance may be relevant when assessing whether reasonable precautions were taken.

However:

Regulatory compliance does not necessarily guarantee immunity from civil liability.

A system can comply with regulatory requirements and still cause compensable damage under an applicable product-liability or tort regime.

Conversely, serious regulatory non-compliance could provide evidence supporting a negligence or defect argument.

19. Case-Law Principles Relevant to AI Liability

Because AI-specific reported case law remains relatively limited, courts will initially rely heavily on established liability principles.

1. M.C. Mehta v. Union of India, AIR 1987 SC 1086

Principle: absolute liability for hazardous or inherently dangerous activities in India.

AI relevance: potentially significant where AI controls hazardous industrial or energy activities. Indian Kanoon

2. Jacob Mathew v. State of Punjab, (2005) 6 SCC 1

Principle: negligence involves duty, breach and resulting damage; criminal negligence requires a substantially higher degree of culpability.

AI relevance: helps distinguish ordinary system-development negligence from criminal responsibility. Indian Kanoon

3. Boston Scientific Medizintechnik GmbH v AOK, Joined Cases C-503/13 and C-504/13

Principle: a potential safety defect affecting products of the same model can have product-liability consequences.

AI relevance: systemic AI design defects may raise liability beyond a single malfunctioning device. curia

4. Rylands v Fletcher, LR 3 HL 330 (1868)

Principle: traditional strict liability for certain dangerous uses of land.

AI relevance: provides historical foundations for risk-based liability, although India's M.C. Mehta doctrine subsequently developed a stronger absolute-liability principle for hazardous industries. Indian Kanoon

5. Indian Council for Enviro-Legal Action v Union of India, (1996) 3 SCC 212

The Supreme Court applied the hazardous-activity liability approach and recognised responsibility for harm caused by hazardous activity. The principle has particular relevance to technology-intensive industries with significant environmental consequences. Indian Kanoon

20. A Proposed Liability Matrix for AI-Driven Energy Systems

A practical legal framework can be structured around control + defect + causation + risk:

This approach avoids treating "AI" as a single legal cause.

21. The Emerging Legal Model

The emerging model is therefore not:

AI made the decision → AI is liable.

Instead, it is:

Identify the risk → identify who controlled it → identify the defect or breach → establish causation → allocate primary compensation → determine contribution among responsible actors.

This is consistent with the direction of modern European product-liability law. The 2024 Directive specifically recognises that software and AI systems can be products, that manufacturers can remain responsible for certain post-market software behaviour, and that multiple economic operators can share liability. EUR-Lex

22. Conclusion

Liability allocation for AI-driven system failures requires a shift from simple actor-based responsibility to risk-and-control-based responsibility.

AI does not eliminate traditional legal principles. Instead, it complicates their application because decision-making is distributed across developers, data suppliers, manufacturers, integrators, deployers, operators and users.

The principal legal mechanisms are:

1. negligence for failures in design, testing, supervision or operation;
2. product liability for defective AI software and AI-enabled products;
3. strict or absolute liability for particularly hazardous activities;
4. vicarious liability where organisations are responsible for acts performed through their systems;
5. contractual allocation and indemnification between commercial participants;
6. joint and several liability where multiple actors contribute to the same damage;
7. contributory negligence where the injured party contributed to the harm; and
8. regulatory duties and documentation that can improve traceability and evidentiary accountability.

For energy law, the issue is especially important because AI is increasingly embedded in electricity networks and other critical infrastructure. Where an AI-driven system causes a grid failure, the proper legal inquiry should therefore examine not merely who wrote the algorithm, but who designed the system, who integrated it, who controlled its deployment, who had access to warnings and updates, who controlled the relevant operational risk, and whether the underlying activity is subject to a special liability regime.

The most important jurisprudential lesson from M.C. Mehta is that where society permits enterprises to undertake inherently dangerous activities for economic benefit, the enterprise may be required to internalise the costs of the risks it creates. Indian Kanoon In the AI-enabled energy sector, that principle provides a strong conceptual foundation for designing liability rules that protect victims without treating every unpredictable AI output as automatically negligent.

Current-law note: The EU Product Liability Directive 2024/2853 applies to products placed on the market or put into service after 9 December 2026, and expressly brings software and AI systems within its product-liability framework. EUR-Lex India, by contrast, does not presently have a single comprehensive AI-specific civil-liability statute; AI failures are therefore principally analysed through existing tort, product, contractual, sectoral and statutory principles, depending on the facts.