EASA's Issue 03 OOS Mandate: A Second Certification Programme Inside Every Level 3 AI Project

On 3 June 2026, EASA released Proposed Issue 03 of its Concept Paper on Artificial Intelligence, open for consultation for 10 weeks [2]. The feedback deadline is 12 August 2026. This is the final Concept Paper deliverable foreseen under the EASA Artificial Intelligence Roadmap 2.0.

Most commentary will focus on the assurance level provisions or the new treatment of reinforcement learning. This article focuses on something that received far less attention in the initial trade coverage, and that will hit early-stage founders far harder than any assurance level table: the mandatory Operational Oversight System (OOS). The independence requirement for the OOS effectively creates a second certification programme nested inside the first.

What the Document Actually Says

Proposed Issue 03 builds on Issue 02, which explored Level 1 and Level 2 AI. Issue 03 completes the technical scope foreseen in the EASA AI Roadmap 2.0 by addressing additional AI techniques, including reinforcement learning and symbolic AI, and explores Level 3 AI applications corresponding to advanced automation [1]. These applications open the way to novel types of operations in which the human end user may be either remotely present or not present during the operation. That classification is the trigger for the OOS requirement.

The document provides a set of actionable objectives but does not yet constitute definitive or detailed guidance [1]. It serves as a reference for Phase II of the EASA AI Roadmap 2.0, when formal regulatory development arrives via RMT.0742. That matters for how to read the OOS requirement: it is not yet binding law, but it is the clearest signal yet of where binding law is headed.

So what is the OOS, and why does it exist? Article 14 of Regulation (EU) 2024/1689 (the EU AI Act) requires that high-risk AI systems be provided to the deployer in such a way that natural persons assigned to human oversight are enabled, as appropriate and proportionate, to exercise effective control [5]. For Level 3A AI, which involves operations with end user involvement only on alerting, and Level 3B AI, which involves operations without end user involvement [1], a conventional human-in-the-loop cannot satisfy that requirement in real time. EASA's solution is to delegate oversight to a machine.

The concept paper is explicit on what this requires. The document explains there is a need for setting allowable boundaries of a delegated oversight to systems at operational time, when the end user is not directly involved. This additional and independent (functionally and technologically) system is called an operational oversight system [1].

Section C.4.8 of the document specifies what the OOS must perform at minimum: monitoring the behaviour of the AI-based system in operation; checking that behaviour against safety envelopes and operational design domain ranges; constraining the AI-based system's decisions and actions when necessary; driving the system to a safe state when necessary; and alerting the end user, since in some cases an end user may retain the ability to override the system, not as a function of continual oversight, but only upon alerting from the AI-based system or from the OOS [1].

Then comes the independence objective, and this is where the cost clock starts ticking. The OOS must be independent, functionally and technologically, from the AI-based system it monitors [1]. The anticipated means of compliance makes the implications concrete: this independence must apply to the AI-based system's design, implementation, and, where necessary, sensing and communication paths. Evidence must include architectural considerations, analysis of common-cause failures, and verification that the OOS works correctly under identified failure conditions [1].

In other words: a separate system, verified separately, using different sensing paths, with its own situation representation, its own monitoring logic, its own override capability, its own verification record. A second development programme nested inside the first.

The Engineering Case and Its Limits

The argument for the OOS requirement is not frivolous. If you are deploying an AI that makes decisions without a human watching, you have already accepted the premise that no single system can be fully trusted to self-certify its own boundaries. The OOS is the engineering formalisation of an insight that any honest AI practitioner already holds: you need an independent check on a system that has been trained, not programmed.

There is also a precedent argument. Avionics systems have required architectural independence between primary and monitoring functions for decades. DO-178C and DO-254 embed watchdog channels and dissimilar redundancy architectures as standard practice. The OOS is a logical extension of that tradition into the AI domain.

Both points are correct on the engineering merits. But the analogy is imperfect in one critical dimension: scope.

A classical dissimilar monitor is typically a simpler, lower-criticality function that checks a bounded set of outputs from a primary system. What EASA is describing is functionally more ambitious. The anticipated means of compliance for the OOS situation-representation objective requires the OOS to build an independent picture of operational context that does not share inputs with the primary AI [1]. The override objective requires the OOS's intervention capability to be designed with integrity, reliability, and timeliness commensurate with the safety risk of the primary AI's decisions and actions [1].

This is not a watchdog timer. It is an independent cognitive system. And it must be assessed and verified to whatever assurance level the safety assessment assigns it, under the same Level 3 regime that made the primary system expensive in the first place.

The cost implication is not marginal. For a well-resourced prime building an autonomous air taxi or cargo system, the OOS becomes a third or fourth work package alongside the primary AI, the airframe integration, and the ground infrastructure. For an early-stage startup building an autonomous remote tower AI or an unmanned cargo aircraft autonomy stack, the OOS requirement can double the engineering programme and extend the certification timeline by years.

One further gap is worth naming. Article 14 of the EU AI Act requires that high-risk AI systems be designed so they can be effectively overseen by natural persons during the period in which they are in use [5]. That principle is present in the framework. What is less clear from the current proposed text is whether it produces a formal tiering mechanism that allows an applicant to argue for a structurally simpler OOS at lower safety criticality. The independence requirement does not appear to carry an explicit scaling ladder for lower-criticality Level 3A applications [1]. That gap is exactly what founders should raise in the consultation.

Two Readings: Burden or Product

If you read the OOS solely as a certification burden, you are probably right that Level 3B autonomous operations become unviable for very early-stage companies pursuing first-mover positions with thin engineering teams. Two certified AI-adjacent programmes rather than one is a real barrier, particularly when compounded by the assurance level constraints that currently limit applications at higher criticality tiers.

But if you read the OOS as a product category, the logic reverses.

Following the consolidation phase of Issue 03, EASA will continue to work with stakeholders in support of the AI strategy for aviation [2]. On the rulemaking side, NPA 2025-07, the first RMT.0742 rulemaking step, is to be followed by a second NPA in 2026 to deploy this generic framework to the regulations of the relevant aviation domains [6]. As of this writing, that second NPA has not been published. When it arrives, it will deploy the AI trustworthiness framework into domain-specific regulations covering aircraft certification, ATM, and drone operations.

The objectives of RMT.0742 are intended to be achieved through three subtasks: a proposal for an AI trustworthiness aviation regulatory framework in response to the EU AI Act; development of associated generic acceptable means of compliance and guidance material; and development of necessary adaptations to domain-specific regulatory material for aviation domains identified in EU AI Act Article 108 [4].

Every company building a Level 3 AI platform for UAM, remote tower operations, or autonomous cargo will face the same OOS requirement. None of them wants to build it twice. A specialist OOS provider offering a qualified, functionally independent, technically diverse monitoring and override layer as a platform component would address a real and validated need for the entire advanced automation sector in Europe.

The requirements are already specifiable from the proposed text: the OOS must monitor, constrain, drive to safe state, and alert [1]. Its architecture must be independent at the technology and sensing layer. Its situation representation must be independently derived. Its override capability must meet integrity and timeliness standards commensurate with primary system safety risk [1]. These are buildable and certifiable as a standalone product.

Because the OOS does not itself implement the primary mission AI, it is architecturally decoupled from any particular application domain. One certified OOS platform, adapted via configuration and operational design domain parameterisation, could serve multiple Level 3 customers across UAM, cargo, and ATM sectors simultaneously.

For Founders: What to Do Now

EASA's consultation period on Proposed Issue 03 closes 12 August 2026 [2]. If you are building anything that will eventually touch Level 3 AI classification, that deadline is a first-order priority. The consultation period is where the proportionality provisions get shaped. If you believe a tiered OOS standard is warranted for lower-criticality Level 3A applications, you need to say so in writing before 12 August. The current proposed text does not yet provide that scaling mechanism explicitly. Silence from founders during this window is a vote for the current draft to stand unchanged.

Beyond the consultation, three decisions every early-stage European aerospace or defence AI founder should make now:

Classify your product against the Level 0 to 3B scale with legal precision, not marketing optimism. Level 3A AI involves operations with end user involvement only on alerting; Level 3B involves operations without end user involvement [1]. If your autonomous system operates with override-on-alert only, you are already in Level 3A territory regardless of what your pitch deck says. Know your level before your certification basis does.

If you are building a Level 3 application, scope the OOS from day one as a separate architectural element, separately budgeted and separately resourced. Do not treat it as a feature to be added in Phase 2. The independence requirement means late integration will force architectural rework. Sensing paths, communication channels, and situation representation logic must be decided early, not retrofitted.

If you are considering the OOS as a product opportunity, move quickly. The second NPA under RMT.0742 is planned for 2026 to deploy the generic AI trustworthiness framework into domain-specific regulations [6]. By the time binding rules are in place, the OOS product category will already be contested. The first qualified platform to reach the market will set the reference architecture that everyone else certifies against.

Proposed Issue 03 provides actionable objectives and does not constitute at this stage definitive or detailed guidance [1], but the direction it points is clear. The OOS requirement is a second certification problem. For founders willing to read the regulatory signal correctly and move before the rulemaking settles, it is also, for the right team, a first business.

EASA's Issue 03 OOS Mandate: A Second Certification Programme Inside Every Level 3 AI Project

What the Document Actually Says

The Engineering Case and Its Limits

Two Readings: Burden or Product

For Founders: What to Do Now

Sources

Recommended