EASA's Net Safety Benefit Credit for AI Certification: What the Proposed Issue 03 Actually Changes

On 3 June 2026, EASA published Proposed Issue 03 of its Concept Paper on Artificial Intelligence, now open for consultation [1]. Stakeholders are invited to send feedback to ai@easa.europa.eu no later than August 12, 2026 [2]. This is the final Concept Paper deliverable foreseen under the EASA Artificial Intelligence Roadmap 2.0. The regulatory skeleton that will govern AI certification in European aviation for the next decade is, in draft form, largely visible right now. Founders who ignore this window are making a strategic mistake.

The provision that deserves the most attention is not the Level 3 advanced automation guidance, consequential as that will be for autonomous operations. It is a quieter clause on the "net safety benefit" concept, and specifically the proposal to reduce an AI constituent's assurance level by one step when net safety benefit is demonstrated. If that credit survives the consultation intact, it is a structural change to the economics of aerospace AI certification. And if it is not designed well, it could become a compliance burden that only incumbent OEMs can afford to manage.

What the Document Actually Says

The mechanism works by introducing credits for systems or equipment that provide operational safety benefits in the determination of the Development Assurance Level [1]. The intent is to facilitate the introduction of new, safety-enhancing technologies that have been shown to provide operational safety benefits to improve the overall safety performance of the operation.

This is not a novel concept in European aviation generally. EASA's CM-SA-001 established an approach to the demonstration of compliance with certain CS-23 and CS-27 specifications, adapted to the installation of systems or equipment that provide operational safety benefit [3]. What Proposed Issue 03 does is extend that logic explicitly to AI constituents across the full EASA domain scope.

The credit works as follows. If the AI-based system can be demonstrated to provide a net safety benefit, with no degradation on applicable safety and operational requirements, and if no other assurance level reduction is already being taken from architectural considerations, the assurance level can be proposed for reduction by one step [1]. Design Assurance Levels range from DAL A, the most rigorous and associated with the highest criticality, to DAL E, which has no safety impact. Moving one step down that ladder, from a more stringent to a less stringent level, say from DAL C to DAL D, compresses a substantial fraction of the verification burden and therefore the cost and calendar time to certification.

There is a hard floor. The document makes clear that allocation of DAL D or equivalent to an AI constituent involved in catastrophic failure conditions will not be accepted, and reduction below DAL D is also not acceptable [1]. The credit is real but bounded, which is sensible.

The part that matters most for founders, and carries the most governance risk, is the mechanism by which the benefit is assessed. Since these assessments have proven to be qualitative in nature, the assessment will be performed by a governance and decision board that EASA plans to establish for this purpose [1]. A qualitative assessment reviewed by an institutional board. That is where the debate lives.

The Case For: A Genuine Commercial Lever

Let me state the optimistic case as clearly as I can. Proposed Issue 03 builds on Issue 02, which explored Level 1 and Level 2 AI, and further broadens the framework by addressing additional AI techniques, including reinforcement learning and symbolic AI. It also explores Level 3 AI applications, corresponding to advanced automation, opening the way to novel types of operations in which the human end user may be either remotely present or not present during the operation [1].

The friction this expansion addresses is not theoretical. AI assurance differs from traditional development assurance because the system's intended function is driven by data, making full requirements-design-implementation traceability infeasible [1]. Traditional certification standards such as DO-178C were developed for deterministic rule-based software, emphasising strong traceability from requirements to code, and ML systems operate differently [7]. The main limitation of existing guidelines is that they do not entirely cover the challenges of AI-enabled systems, which led EASA to work on defining equivalent methods for the safe use of machine learning approaches [12].

That is why so few safety-related AI products have shipped in European civil aviation to date.

The net safety benefit credit is a proportionality mechanism. It recognises that a Level 1 AI workload-reduction tool used by a pilot, or an automated defect-detection system in maintenance, may generate more safety margin than it consumes in residual risk, even with a lighter assurance regime. Proportionality is central to the EASA framework: not all innovations require the full AI trustworthiness framework, as risk and safety benefit will determine the level of regulation, and demonstrated safety benefits may allow for flexibility in assurance requirements [9]. The regulator is therefore not theorising: the mechanism is designed to meet a practical demand from applicants already in discussion with EASA.

For a founder with a real, demonstrable safety case, the credit makes a DAL C programme into a DAL D programme: fewer required independence checks, fewer formal review stages, fewer specialist certification consultant day-rates billed over a longer calendar. As Design Assurance Levels increase from DAL E toward DAL A, verification rigour and independence requirements escalate significantly, and trust in automated tools correspondingly decreases [4]. That asymmetry matters far more to a twelve-person team than to a prime. A large OEM running a DAL B certification programme does not experience DAL C as prohibitive; they have the infrastructure regardless. The credit, if usable, directly expands the addressable early-stage market.

The Case Against: Qualitative Assessment Is a Governance Risk

Now for the counterargument, and it deserves to be engaged seriously rather than waved away.

The credit mechanism rests on a qualitative determination. The Concept Paper is honest that assessments in this area have proven to be qualitative in nature, and EASA plans to establish a dedicated governance and decision board to make these calls [1]. That honesty is welcome. The structural problem remains.

Qualitative assessments under institutional review reward applicants who are fluent in the regulator's language, who have accumulated relationship capital with the authority, and who can invest in pre-application engagement. Those characteristics describe large Tier 1 suppliers, established ATM system integrators, and OEM subsidiaries. They do not describe a Series A aerospace AI startup with seven engineers and a prototype. The risk is not that EASA acts in bad faith; it is that any qualitative gate systematically advantages experienced navigators over technical merit.

There is also a gaming risk running in the other direction. A creative but weak safety benefit argument, dressed up in the right framing, could secure a DAL reduction for a system that does not genuinely earn it. A governance board working through early-stage AI applications and building precedent from scratch may lack the tools to distinguish a compelling quantified case from an optimistic one. Both failure modes, incumbents succeeding through institutional fluency and weak arguments slipping through, would undermine the framework's credibility.

This document provides a set of actionable objectives but does not constitute at this stage definitive or detailed guidance, and serves as a reference for the EASA AI Roadmap 2.0 Phase II when formal regulatory development comes into force via RMT.0742 [1]. Getting the governance design right here is especially consequential because RMT.0742 will be followed by a second NPA to deploy this generic framework to the regulations of the relevant aviation domains [10], meaning the governance board model is likely to propagate directly into binding rules. A mechanism that shapes only the Concept Paper matters; one that becomes the template for formal European AI certification rules matters far more.

How to Think About This as a Founder

The credit is not a paper promise. But it is not a self-service discount either. Here is how to frame it for early-stage companies.

First, the credit is an argument you have to win, not a benefit you automatically receive. That means your safety case needs to be engineered from day one with net benefit demonstration in mind. Quantitative operational data, even from shadow operations or limited service experience, will be far more persuasive than qualitative assertions. The Concept Paper explicitly opens the possibility for applicants to deploy applications in shadow operations in their target environment, to collect data and use those to ease compliance with challenging requirements [1]. Start collecting structured flight hours and event data now, under documented conditions.

Second, the mechanism is proposed, not finalised. This document does not constitute at this stage definitive or detailed guidance, and serves as a reference for the EASA AI Roadmap 2.0 Phase II when formal regulatory development comes into force via RMT.0742 [1]. If founders do not engage the consultation, the final text will be shaped entirely by parties who did. That is an unforced error. Submit feedback to ai@easa.europa.eu no later than August 12, 2026 [2].

Third, understand the full scope of what Issue 03 covers before assuming your architecture is in scope. The paper builds on Issue 02, further broadens the framework by addressing reinforcement learning and symbolic AI, and explores Level 3 applications corresponding to advanced automation [1]. Design choices made in month three of development can determine certification eligibility three years later. Map your architecture against the AI constituent concept and the four automation levels before you begin serious certification preparation, not after.

Fourth, the W-shape development process described in the EASA AI guidance is not optional reading. AI assurance differs from traditional development assurance because full requirements-design-implementation traceability is infeasible. To address this, the W-shape process adapts the classical V-shape development assurance process [1]. An additional architectural element, the AI constituent, is introduced between the classical system and item layers, ensuring proper handling of AI-specific considerations such as the Operational Design Domain, iterative design and verification, before integrating the AI constituent into the broader AI-based system architecture [1]. Your technical architecture, documentation strategy, and data management regime all need to be compatible with this structure before you enter the certification corridor. Independent peer-reviewed research confirms this W-shape framing originates in and is required by the EASA guidance, not merely recommended by external literature [6].

For Founders: What to Do Now

Stakeholders are invited to provide their comments using the dedicated comment-response document and to send feedback to ai@easa.europa.eu no later than August 12, 2026 [2]. That deadline is the most actionable near-term item on this topic. Read the net safety benefit provisions carefully, map them against your specific use case, and submit a comment. EASA's process does respond to technically grounded submissions. A well-argued point from a startup that has operational data and a clear safety benefit thesis is not dismissed because it comes from a small company. If it were, that would itself be informative about whether the mechanism is actually accessible to founders.

More tactically: if the net safety benefit credit is central to your certification strategy, engage a certification consultant who has navigated CM-SA-001 in CS-23 or CS-27 work [3][4]. That memo's approach to demonstrating compliance for systems that provide operational safety benefit, achieved by introducing credits in the determination of the DAL, is the closest existing precedent. The qualitative governance board EASA plans to establish will develop its methodological habits from the first cases it reviews. Being an early applicant with a strong, well-structured case means you help set the precedent rather than navigate one set by others.

The credit is real, the commercial logic is sound, and the mechanism is a genuine regulatory innovation. The window is open until August 12, 2026.