Key Takeaways

1. METI’s Guidance, finalized in April 2026, sets out how civil liability should be analyzed when AI is used in reliance/substitution mode. In this category, the AI user’s duty of care shifts to the proper design and operation of the business process that incorporates AI. AI developers and providers are expected to take reasonable design measures and to disclose material risk information to users.
2. The two-category framework (assistance/support vs. reliance/substitution) is a useful starting point, but it should not be applied mechanically. In practice, the two categories may be difficult to distinguish. In litigation, what matters is not the categorization itself but the specific content of the duty of care owed by each actor in light of the facts.
3. For physical AI, the manufacturer’s product liability and the user’s duty to ensure employee safety are assessed as of different points in time. The defect analysis of product liability is anchored to the time of delivery. The duty to ensure employee safety is assessed as of the time of the accident. When an AI’s behavior changes after delivery through a software update, the manufacturer may escape product liability while the user may not.
4. For non-physical AI such as AI agents, the user’s duty of care centers on business process design and operation. Where consumer interests are at stake, AI alone may not deliver sufficient accuracy. In those cases, the user needs to design a process that brings human operators or other safeguards into the loop.
5. AI risk management should be built into existing compliance frameworks. For physical AI, the risk assessment regime under the Industrial Safety and Health Act provides a starting point. For non-physical AI, existing quality management, internal control, and information security management (ISMS) systems can absorb AI-related risks. In litigation, documentation aligned with the AI Business Operator Guidelines may be considered favorably in a negligence analysis.

Background

The Guidance Has Been Finalized

The Ministry of Economy, Trade and Industry (“METI”) convened a study group to examine civil liability arising from AI use.[i] On April 9, 2026, METI published the Guidance on the Interpretation and Application of Civil Liability in AI Use [Version 1.0] (the “Guidance”).[ii] Part 1 of this series addressed the assistance/support category based on the draft of the Guidance. This article addresses the reliance/substitution category based on the finalized text.

Scope of This Article

The reliance/substitution category covers AI uses where AI is expected to make decisions or take action in place of humans. Compared to the assistance/support category, the central question is what liability the parties may face when a third party suffers harm as a result of relying on AI outputs. The Guidance identifies three hypothetical scenarios in this category: visual inspection AI (Scenario 5), autonomous mobile robots, or AMRs (Scenario 6), and AI agents (Scenario 7).[iii]

Real-World Deployment of Reliance/Substitution AI

Reliance/substitution AI is already moving into real-world business operations. Amazon announced that, as of July 2025, it had deployed its one millionth robot across more than 300 facilities worldwide. These robots include “Proteus,” an AMR that operates fully autonomously alongside human workers and carries carts of customer orders.[iv]

The Guidance on the Reliance/Substitution Category

The Guidance divides AI use into two categories based on whether a human decision or action is expected to intervene before the final outcome.[v] In the assistance/support category, AI serves only to assist human judgment. In the reliance/substitution category, AI is deployed on the premise that it will take the place of human judgment or action, and the user relies on AI outputs.

The Guidance also identifies two requirements for AI to fall within the reliance/substitution category.[vi] First, the AI must provide utility that cannot easily be achieved through human judgment or action (necessity). Second, the AI must meet a certain level of accuracy and safety (accuracy and safety).

AI User’s Duty of Care: A Shift to Process Design and Operation

In the reliance/substitution category, AI users are not required to verify every AI output to prevent harm. Instead, the Guidance treats the user’s duty of care as a duty to properly design and operate the business process that incorporates AI.

AI Developer/Provider’s Duty of Care: Design and Disclosure

For AI developers and providers, the Guidance identifies two types of measures. First, developers and providers should take reasonable design measures to achieve and maintain the level of safety needed to make reliance on AI reasonable. Second, they should analyze information material to risk control and disclose it to AI users.

Scope and Framework of This Article

This article addresses scenarios discussed under the reliance/substitution heading. As discussed in Section 5, the two-category framework has practical limits. Rather than focus on whether a given use falls into assistance/support or reliance/substitution, this article uses two substantive distinctions: whether the AI is subject to product liability, and whether it creates risks to life or physical safety. On that basis, this article divides the analysis between physical AI and non-physical AI.

Physical AI: Liability When AI Causes Physical Harm

Overview—Hypothetical Scenario 6 (AMRs)

In Hypothetical Scenario 6, the Guidance presents three cases involving AMRs operating in warehouses and factories.[vii] In Case (a), an AMR strikes and injures a worker. In Case (b), a software update introduces a bug that causes a collision. In Case (c), a self-diagnostic AI mounted on the AMR makes an erroneous diagnosis, causing a fire. The Guidance analyzes what liability the AMR manufacturer (M) and the user, a logistics operator (N), may face.

Cases (a) and (b) involve physical injury to workers on site, while Case (c) involves property damage to the user. In each case, the Guidance treats the manufacturer’s liability (primarily product liability) and the user’s liability (breach of the duty to ensure employee safety and general tort liability) as the principal issues.[viii]

The Manufacturer’s Perspective: Product Liability

Unlike non-physical AI, physical AI may fall within the scope of the Product Liability Act. Under that Act, a claim requires a “defect” in the product.[ix] A “defect” is defined as a lack of safety which a product should normally have.[x]

For AMRs and other physical AI, mechanical malfunctions and design failures raise the same kinds of issues as conventional products. AI raises an additional question: how to assess defects in software-driven behavior. AI-driven robots are designed to behave flexibly. That sets them apart from conventional robots, which follow fixed behavioral patterns. As a result, identifying which behaviors fall short of “the safety which a product should normally have” can be difficult.

On how to approach this issue, the Guidance, drawing on the discussion of autonomous vehicles, suggests a possible direction.[xi] In particular, the Guidance points to the existence of a reasonable alternative design—one that could have avoided the accident in light of the actual use environment and the AMR’s specific design—as a relevant factor. Where a planned specification or design fails to perform because of a serious bug or similar malfunction, the Guidance suggests that a design defect is more likely to be found. By contrast, where the accident stems from the use environment or the manner of use, a design defect is less likely. The Guidance reasons that the operational site is under the user’s control and that risk assessment is expected at that level.

Tort Liability of Manufacturers, Developers, and Providers

In addition to product liability, manufacturers, AI developers, and AI providers may face tort liability for breaches of design-related or disclosure-related duties of care. The specific content of these duties will depend on the AI’s functions and performance, the nature of the intended business use, and the foreseeable risks.

The Timing Gap Between Product Liability and User Duties

The defect analysis under the Product Liability Act is anchored, in principle, to the time when the manufacturer delivered the product.[xii] For products that incorporate AI, this raises the question of how to treat malfunctions that arise after delivery through software updates. The Guidance discusses both views: limiting the defect analysis to the time of delivery, and extending it to take into account the effects of updates up to the time of the latest update.[xiii] That said, the Product Liability Act defines a “product” as movable property. This creates a tension as a matter of statutory interpretation: the “time of delivery” refers to the delivery of movable property, but software—and thus a software update—is not movable property.

The fact that product liability is anchored to the time of delivery can create a timing gap relative to the AI user’s duty to ensure employee safety. Consider an AMR whose behavior changes after delivery through a software update, leading to a collision with a worker. The manufacturer’s product liability is assessed by reference to whether the product had a defect at the time of delivery. The user’s duty to ensure employee safety is assessed by reference to the workplace environment and the state of the AMR at the time of the accident. Where the accident results from a post-delivery update, the manufacturer may escape product liability while the user may still face liability.

AI users should not assume that product liability will cover them. They need to manage risk on a continuing basis after delivery.

The User’s Tort Liability to Third Parties

AI users may face tort liability when their use of AI causes harm to third parties in the course of business.[xiv] The Guidance treats the user’s duty of care in the reliance/substitution category as a duty to properly design and operate the business process that incorporates AI. In practice, the key questions are whether the user deployed an AI of the required accuracy and safety, whether the user built a process that incorporates human involvement where needed, and whether the user actually operated that process as designed.[xv]

The User’s Duty to Ensure Employee Safety

A business that introduces physical AI such as AMRs into the workplace owes a duty to ensure the safety of its own employees.[xvi] The specific content of that duty depends on the nature and scale of the business and the characteristics of the AI deployed.

For physical AI, existing safety frameworks provide a natural starting point. Compliance with existing safety frameworks is likely to be an important factor in assessing whether the duty to ensure employee safety has been breached—in particular, the risk assessment regime under the Industrial Safety and Health Act[xvii] and the measures for industrial robots under the Ordinance on Industrial Safety and Health[xviii].

Non-Physical AI: AI Agents and Customer-Facing Services

Overview—Hypothetical Scenario 7 (AI Agent)

In Hypothetical Scenario 7, the Guidance presents a case in which an online course operator uses an AI agent to automate customer support.[xix] Internal records indicated that a particular product was not eligible for government financial assistance. The AI agent, drawing on public internet information, responded to a customer that the product was eligible for such assistance and recommended its purchase. The customer enrolled in the course. Only after enrollment did it become clear that the product was not eligible.

The Guidance suggests that AI agents like the one in Scenario 7 can fall within either the assistance/support category or the reliance/substitution category, depending on the type of agent and how it is used.[xx]

AI User’s Duty: Business Process Design and Operation

Unlike physical AI, non-physical AI is generally not subject to the Product Liability Act. The analysis therefore centers on tort liability.

AI users in the non-physical AI context owe a duty of care to properly design and operate the business process that incorporates the AI. For users in the reliance/substitution category, the Guidance takes the position that the overall business process—including measures such as interposing human judgment for high-risk inquiries or complex responses—needs to meet or exceed the standard of an ordinary person engaged in the same line of work in terms of quality and accuracy.[xxi] Where consumer interests are at stake, courts are more likely to impose a heightened duty of care, reflecting consumer protection concerns. Where AI alone cannot deliver sufficient accuracy, the design of the business process—for example, routing certain inquiries to human operators—becomes the central issue.[xxii]

In practice, AI users need to map out which parts of the workflow they can delegate to AI and which parts require human judgment. That allocation should reflect the nature of the work, the risks involved, and the need for consumer protection.

AI Developer/Provider’s Duty: Design and Disclosure

AI developers and providers need to take reasonable design measures to achieve and maintain the safety that makes reliance on AI reasonable. They also need to provide AI users with information material to risk control.

AI agents raise particular issues because they use external information and tools autonomously and in chains. The key questions are whether developers and providers took appropriate design measures and provided clear explanations in light of these characteristics and risks.[xxiii] The required standard varies depending on whether the AI is offered in reliance/substitution mode or assistance/support mode.

A Closer Look at the Two-Category Framework

Practical Difficulty of Drawing the Line

The Guidance presents the two categories as a way to classify AI uses by mode of deployment. In practice, however, drawing the line between the two categories can be difficult.

Consider a manufacturing line in which several AI systems work together: an inspection AI for incoming materials and parts, an inspection AI built into the assembly process, an AMR moving products between stages, and a visual inspection AI at the final stage. If a defective product reaches the customer, the liability analysis raises several questions. Should each process be classified separately as assistance/support or reliance/substitution? If so, can the source of the failure be traced to a specific process? And if the failure has multiple causes, how should the categorization apply? The two-category framework does not always map cleanly onto these facts.

What Actually Matters in Litigation

When the categorization itself is in dispute, the questions are typically whether the AI use falls into the assistance/support or the reliance/substitution category, and whether choosing the “wrong” category amounts to a breach of the duty of care.

As Part 1 noted, however, choosing how to use AI is a holistic judgment. It takes into account the AI’s functions and performance, the nature of the business, and the information available at the time. If the user conducted a reasonable analysis at the time, the choice is not a breach of the duty of care simply because it later proves inadequate. It may also be difficult to show that the choice of category itself caused the harm—the same harm might have occurred under the “correct” category.

What matters in litigation, then, is not the categorization itself. It is what duty of care each actor owed in light of the actual operational arrangements, and whether that duty was met.

How to Use the Framework

That said, the Guidance’s framework is a valuable starting point for analyzing liability. Its core insights—that the AI user’s duty of care shifts toward the proper design and operation of the business process, and that AI developers and providers face design-related and disclosure-related duties—are useful in working out the specific duty of care in litigation.

The two-category framework, then, should not be applied mechanically. It is better used as one lens for thinking about where AI sits within a business process and how human judgment fits in.

Practical Steps for Managing Liability Risk

The Importance of an Ex Ante Perspective

As Part 1 noted, courts assess negligence based on what the defendant should have done at the relevant point in time. AI developers, providers, and users therefore benefit from preparing in advance: working out their analysis, documenting their decisions, and building a record they can later explain. The same approach applies in the reliance/substitution category.

For reliance/substitution AI specifically, the analysis should focus on the specific duty of care that flows from the AI’s role in the business process and the nature of human involvement. As Section 5 discussed, fixating on whether the use falls into assistance/support or reliance/substitution is less useful than working out what duty of care actually applies given the real-world use.

AI User Perspective

AI users should integrate AI-related risk management into existing compliance frameworks.

For physical AI, as Section 3 noted, the risk assessment regime under the Industrial Safety and Health Act provides a starting point for safety management. AI users also need to manage risk on a continuing basis after delivery, given that product liability may not cover them. Practical measures include monitoring how the AI behaves after software updates, running periodic risk assessments, and setting up incident response protocols.

For non-physical AI, existing systems for quality management, internal control, and information security management (such as ISMS) can absorb AI-related risks. For customer-facing operations, the allocation between AI and human judgment should be worked out at the process design stage and documented.

AI Developer/Provider Perspective

AI developers and providers need to take design measures to achieve and maintain the safety that makes reliance on AI reasonable, and to disclose risk-related information to AI users.

AI agents use external information and tools autonomously and in chains. For these AI agents, AI developers and providers should pay particular attention to design-related risk controls and clear disclosure to AI users—both of which carry significant weight in any negligence analysis. Developers and providers who have analyzed risks and built compliance structures in line with the AI Business Operator Guidelines[xxiv] may have those measures considered favorably.[xxv] As an ex ante measure, developers and providers benefit from organizing and documenting their risk management based on existing frameworks, with reference to the AI Business Operator Guidelines.

Looking Ahead

This article has examined civil liability in the reliance/substitution category in light of the Guidance.

The Guidance’s two-category framework is a valuable starting point. In practice, however, the categories can be difficult to separate, and the framework should not be applied mechanically.

This article analyzed the liability structure for reliance/substitution scenarios using two substantive distinctions: whether the AI is subject to product liability, and whether it creates risks to life or physical safety. In both physical AI and non-physical AI cases, what matters is whether each actor can later explain the reasonableness of its decisions and responses at each point in time. Building risk management on existing frameworks and documenting that work is a sound ex ante approach.

For physical AI, the timing gap between the manufacturer’s product liability (assessed as of the time of delivery) and the AI user’s duty to ensure employee safety (assessed as of the time of the accident) deserves particular attention. AI users should not assume that product liability will cover them, and they need to manage risk on a continuing basis after delivery.

Part 1 and this article together have surveyed the framework that the Guidance sets out for the assistance/support and reliance/substitution categories. As case law develops and AI technology continues to evolve, the analysis of civil liability will become more concrete.

---

[i] METI, Study Group on Civil Liability in AI Use, https://www.meti.go.jp/shingikai/mono_info_service/ai_utilization_civil/index.html (last visited Apr. 23, 2026).

[ii] METI, Guidance on the Interpretation and Application of Civil Liability in AI Use [Version 1.0] (Apr. 2026), https://www.meti.go.jp/shingikai/mono_info_service/ai_utilization_civil/20260409_report.html (last visited Apr. 23, 2026). The “Draft Guidance” addressed in Part 1 was subsequently finalized as the Guidance.

[iii] Supra note 2, at 48–73.

[iv] Scott Dresser, Amazon launches a new AI foundation model to power its robotic fleet and deploys its 1 millionth robot, About Amazon (July 1, 2025), https://www.aboutamazon.com/news/operations/amazon-million-robots-ai-foundation-model (last visited Apr. 23, 2026).

[v] Supra note 2, at 17–18.

[vi] Id. at 14–15.

[vii] Id. at 53–54.

[viii] Id. at 54.

[ix] Product Liability Act (Seizōbutsu Sekinin Hō), art. 3.

[x] Id. art. 2, para. 2.

[xi] Supra note 2, at 58–59, 61.

[xii] Product Liability Act, art. 2, para. 2.

[xiii] Supra note 2, at 65–66. In the EU, the revised Product Liability Directive (Directive (EU) 2024/2853) clarified in 2024 that software is included in the definition of “product.”

[xiv] Civil Code (Minpō), art. 709.

[xv] Supra note 2, at 57 and elsewhere.

[xvi] The employer’s duty to ensure employee safety is established under Japanese case law.

[xvii] Industrial Safety and Health Act, art. 28-2.

[xviii] Ordinance on Industrial Safety and Health, arts. 150-3 through 150-5.

[xix] Supra note 2, at 70.

[xx] Id. at 70–71. A comparable case outside Japan is Moffatt v. Air Canada, in which a Canadian tribunal held Air Canada liable when its customer-support chatbot gave a response inconsistent with the airline’s policy. British Columbia Civil Resolution Tribunal, 2024 BCCRT 149. Whether the chatbot used generative AI is not clear from the decision.

[xxi] Supra note 2, at 71.

[xxii] Id.

[xxiii] Id. at 72–73.

[xxiv] Ministry of Internal Affairs and Communications & METI, AI Business Operator Guidelines (Version 1.1) (Mar. 28, 2025), https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20250328_report.html (last visited Apr. 23, 2026). The AI Business Operator Guidelines are voluntary guidelines issued by the Japanese government setting out expected conduct for AI developers, providers, and users.

[xxv] Supra note 2, at 9.