EASA's Responsibility Scheme for AI Could Become a Liability Map in Court

EASA released Proposed Issue 03 of its Concept Paper on Artificial Intelligence on 3 June 2026, opening a 10-week consultation that closes on 12 August 2026 [2]. It is the final Concept Paper deliverable foreseen under the EASA Artificial Intelligence Roadmap 2.0 [1].

Most of the founder conversation since publication has focused, reasonably, on what the document demands technically: learning assurance, the W-shape process, the OOS mandate for Level 3, DAL ceilings. Those are real burdens.

What has not been discussed is the regulatory mechanism sitting in the responsibility scheme section of Proposed Issue 03 [1]. This is among the most underestimated commercial risks in the entire document.

What the Responsibility Scheme Actually Requires

Proposed Issue 03 provides specific Level 2B and Level 3 guidance on the impact of a transfer of authority to an AI-based system with respect to the responsibility scheme. For Level 0, 1, and Level 2A AI, the responsibility scheme is considered unaffected compared to current practices [1].

Building on Issue 02, Proposed Issue 03 completes the technical scope foreseen in the EASA AI Roadmap 2.0, broadening the framework to address reinforcement learning, symbolic AI, and Level 3 AI applications corresponding to advanced automation, including novel types of operations in which the human end user may be remotely present or absent [1] [13].

At Level 2B, the document foresees a partial release of authority to the AI-based system, with a mandatory assessment of the responsibility scheme required to define clear responsibility boundaries. Although responsibility still formally rests with the end user, the user's practical authority is limited and partial [1].

Under the responsibility scheme objectives, applicants must produce a formal assessment with specific mandatory content. You must identify every organisation involved, sorted into three roles: provider, deployer, and end user. Then, for every high-level task and every operational scenario, responsibility must be explicitly assigned to one of those organisations and to a named responsible person [1]. Three hard conditions apply:

No responsibility may be assigned to the AI-based system itself, which remains a tool.
No gaps are permitted: no combination of task and scenario can be left unassigned.
No "responsibility dumping" is permitted: responsibility cannot be assigned to a person who lacks the authority, information, or means to discharge it.

A second objective then requires that each responsibility identified be enabled: the named person must be demonstrably given the authority, access, and capability to discharge it [1].

The document adds a sentence that every lawyer reading this will recognise as a careful legal firewall: the responsibility scheme assessment clarifies the allocation of operational responsibilities for each scenario; it does not alter, limit, or override any applicable liability regimes, whether international, EU, or national, including those relating to product liability [1].

Read that twice. EASA is telling you explicitly that the safety governance document you produce does not substitute for, or limit, tort or product liability exposure. This is correct, responsible drafting. It is also the source of the risk I want to describe.

The Counterargument I Take Seriously

The straightforward response is this: certification documentation has always existed, has always been discoverable in litigation, and the industry has survived. An FMEA, a safety assessment, a software development plan all establish what the designer knew and when. Courts have applied aviation safety standards as evidence of the applicable standard of care for decades. Nothing about the responsibility scheme objectives is categorically new.

I accept that as partially correct. The industry has a mature practice of producing evidentiary records at certification, and experienced legal teams know how to manage them.

But that argument misses two compounding factors specific to Level 2B and Level 3 AI systems and to the regulatory moment we are now entering.

Why This Moment Is Different

The first factor is the granularity of what the responsibility scheme objectives demand. Prior safety documentation established what the system was designed to do and what failure modes were anticipated. The responsibility scheme goes further: it requires a named person to be designated as responsible for every high-level task in every operational scenario, and it explicitly prohibits assigning that responsibility to someone who lacks the authority or information to discharge it [1].

That constraint is there to protect the end user, and it is right. But it creates a precise factual record: here is who we said was responsible; here is what authority we said they had; here is the operational scenario in which the incident occurred. An accident investigator, and by extension a plaintiff's counsel, does not need to reconstruct a theory of liability from fragmented documents. You have provided the map.

The second factor is the new EU Product Liability Directive. European Directive (EU) 2024/2853 was adopted on 23 October 2024 and entered into force on 8 December 2024 [17] [10]. Member States must transpose it into national law by 9 December 2026, and it will apply to products placed on the market or put into service after that date [7].

The Directive expands the definition of "product" to include software, AI, and digital services, and imposes compliance obligations on a broader set of economic operators [5] [6]. Its procedural instruments are highly claimant-friendly: by broadening the scope of potential defendants, introducing presumptions of damage and causation, and imposing a formal obligation to disclose evidence, the new regime will increase both the number and complexity of product liability claims [4].

Transposition is progressing unevenly. In Germany, the Bundestag held its first reading of the Draft Act on the Modernisation of Product Liability Law on 4 March 2026 [15]. The draft was referred to the Legal Affairs Committee, which holds lead responsibility; substantive deliberations must take place there before the Bundestag votes in its second and third readings [15] [16]. Given the transposition deadline of 9 December 2026, a swift conclusion of the legislative process is expected. Neither France nor Italy has yet transposed the new Directive, and significant delays are possible in France specifically, given that the 1985 PLD took over a decade to transpose into French law [11]. Founders should verify transposition status in each jurisdiction where they place products on the market.

The regulatory connection to EASA's framework runs directly through the EU AI Act. Article 108 of the AI Act introduces a significant amendment to Regulation (EU) 2018/1139, the Basic Regulation underpinning the EU's civil aviation framework [9]. When delegated acts adopted under that Regulation relate to AI systems qualifying as safety components under the AI Act, those acts must incorporate the high-risk AI requirements laid down in Chapter III, Section 2 of the AI Act [9]. NPA 2025-07, published 10 November 2025, proposes detailed specifications on AI trustworthiness for aviation in direct response to those AI Act requirements [8] [14].

Put simply: the responsibility scheme assessment tells a court exactly who was responsible for what. The new PLD creates presumptions triggered by non-compliance with mandatory safety requirements and by failure to disclose evidence when ordered [4] [5]. The combination is legally significant in a way that neither document alone would be.

The third factor is the authority-mapping that the responsibility scheme forces for Level 2B systems. When the document prohibits responsibility dumping onto a person without authority, and simultaneously records that the end user's practical authority is limited and partial, you have formally documented a system in which someone bears responsibility not commensurate with their control [1]. Consider a Level 2B urban air mobility application in which a remote operator is assigned responsibility for a contingency decision but has access only to a downlinked video feed and a high-latency command channel. The responsibility scheme document will name that person, describe that scenario, and record the authority boundaries assigned to them. That is precisely the fact pattern a plaintiff's expert will identify as a design defect: the human in the loop was assigned accountability for an outcome they could not fully prevent.

The prohibition on responsibility dumping is a serious attempt to close exactly that gap. But closing it requires affirmative design choices, not just completing a form.

What This Is Not

This is not an argument against building Level 2B or Level 3 AI systems, and it is not an argument against the responsibility scheme as a safety governance tool. That work is necessary and the framework is, on the whole, serious.

It is also not an argument to leave the responsibility scheme document vague or incomplete in the hope of limiting exposure. Incompleteness does not reduce risk. It adds regulatory non-compliance risk on top of litigation risk, and under Germany's draft transposing law, non-compliance with a court order to produce information can trigger a presumption of defectiveness [15] [16].

For Founders: What to Do Before 12 August 2026

The consultation closes 12 August 2026 [2]. That window is the lever available to you right now.

First, if your product is Level 2B or higher, treat the responsibility scheme as a product design artefact, not a certification paperwork exercise. The document should be drafted with your legal team in the room, not handed to them after certification closes. Every assignment of responsibility to a deployer or end user should be stress-tested against one question: does this person actually have the authority and information to discharge this responsibility in the specific scenario you have described? A purely formal allocation is not sufficient if, in practice, the user cannot effectively supervise or override the system [1].

Second, map your responsibility scheme structure against the new PLD regime now, jurisdiction by jurisdiction. The new Directive applies only to products placed on the EU market or put into service after 9 December 2026; products already on the market before that date remain under the 1985 regime [7] [17]. The distinction matters for long-lifecycle products and for businesses keeping older models on sale alongside new ones. Your product liability insurance review and your responsibility scheme drafting should happen in the same meeting, not in different quarters.

Third, use the consultation with a specific comment angle. NPA 2025-07 is the first step of Rulemaking Task 0742, to be followed by a second NPA in 2026 that will deploy the generic framework to domain-specific regulations covering airworthiness, ATM, and operations [8] [14]. As of the date of this publication, that second NPA has not yet appeared. The question worth submitting a comment on now: should the responsibility scheme methodology include explicit guidance on how the responsibility record interacts with the EU PLD's presumption of defectiveness, and should demonstrably well-constructed schemes be explicitly shielded from triggering those presumptions by non-compliance alone? That is a specific, bounded question the rulemaking group can engage with.

Fourth, do not assume that because the responsibility scheme document states it does not alter applicable liability regimes, it has no liability consequences. That statement is accurate. It is not protective. The document exists independently of the liability regime and will be discoverable independently of it.

The founders building the most capable aerospace AI systems in Europe are doing important work. But the responsibility scheme process is a moment where legal and engineering judgment must be brought together earlier than most early-stage teams currently plan for. The consultation closes 12 August 2026. That is enough time to read the responsibility scheme section of Proposed Issue 03 carefully, engage a lawyer who understands both product liability and aviation regulation, and submit a substantive comment.