Board brief — the decision in two minutes
A remote operator is not an effective safeguard merely because a console displays an alert or accepts an override. The board must establish whether the protective action can be completed before the consequence—and what protects the operation if it cannot. This affects the architecture you buy, staffing you fund, safety claims you approve and representations you make to insurers. EASA’s June 2026 consultation explores these issues. ODA3 Institute adds an auditable argument connecting the claim, intervention time, actual authority, observed effect and versioned evidence. Require a bounded demonstration for the highest-consequence in-scope scenario before relying on remote intervention.
Five questions for management:
- Which abnormal conditions actually depend on remote human intervention rather than an independently effective safeguard?
- What tests show the entire path from alert to achieved protective effect within the available time?
- What happens when communications fail, information is stale or the operator is occupied?
- Do contracts, procedures and responsibility allocations match the intervention authority implemented in the system?
- Which tested limits and remaining unknowns will be disclosed to authorities and insurers, and what changes would force reassessment?
The board decision is whether the safety case depends on an unproven rescue
Aviation organisations considering AI-enabled advanced automation may assign a remote person responsibility for intervening when the automated system approaches a limit. The capital-allocation and operational decision is not simply whether to employ a human supervisor. It is whether the system design, staffing and communication arrangements can substantiate the protection on which the investment case and safety argument rely. If intervention is assumed but cannot be completed in time, the programme may need a different architecture, staffing model or operational boundary; any resulting financial exposure and liability require separate assessment.
An override control in an interface is a design feature. Effective intervention is an operational outcome. Between the two lie alert generation, communications, information quality, operator workload, authority, command execution and physical response. Any one may narrow or defeat the intervention opportunity.
For aviation leaders and insurers considering whether to rely on a remotely supervised safety claim, the relevant question is whether the intervention path has been demonstrated and its limits disclosed. ODA3 Institute’s analysis is that leaders should require a bounded time-and-authority argument before relying on remote oversight as a safety control: one specified condition, one configuration, an identified operator role, an explicit intervention window and a demonstrated fallback. That argument supports scrutiny of the design. It does not itself constitute regulatory approval or a newly recognised means of compliance.
ODA3 Institute’s specific contribution is the examination structure: link a declared safety claim to intervention milestones, observed effects, fallback behaviour and versioned evidence another competent examiner can inspect. The method is an analytical proposal, neither a completed ODA3 aviation examination nor a regulator-approved means of compliance.
EASA’s proposal makes the oversight problem more concrete
On 3 June 2026, the European Union Aviation Safety Agency (EASA) published Proposed Issue 03 of its Concept Paper: Guidance for safety-related artificial intelligence applications for consultation, with comments due 12 August 2026. The proposal extends the technical discussion to Level 3 advanced automation, including operations in which a human end user may be remotely present or absent. It is a proposal, not a statement that those provisions have become binding certification requirements. [1][2]
The paper’s scope matters: the proposed guidance covers Level 0–3 AI applications but explicitly does not cover “autonomy” or “autonomous systems”; it also does not accept systems presenting risks directly contributing to potential fatalities or multiple life-threatening injuries, within the scope described in section C.1. These are limits of this proposed concept paper, not a statement that aviation generally prohibits such operations. EASA positions the document as exploratory guidance under the EU aviation framework (including Regulation (EU) 2018/1139, often called the Basic Regulation); the applicable project certification basis must be separately established. [2, section C.1] In ODA3 Institute’s analysis, the intervention and authority questions may transfer to other jurisdictions, but EASA’s proposed objectives do not automatically do so as regulatory requirements.
The distinction between EASA’s proposed Level 3A and Level 3B cases matters. Level 3A concerns safeguarded advanced automation in which an end user can exercise a limited intervention role upon alerting, within the proposed allocation of authority. Level 3B considers operations without an end user participating in the operation; it raises a different question about delegated, system-based oversight. Treating both as a generic ‘human in the loop’ arrangement obscures where authority actually resides. [2, sections B.5.6–5.7 and C.4.8–5.2]
For procurement, a buyer should require the supplier to specify whether the contracted operational concept actually depends on a remote end user, what intervention authority exists after an alert, and which protection is intended to act without that person. A contract that promises intervention authority the design cannot deliver should trigger a supplier acceptance and safety review. That mismatch alone does not establish a different EASA classification. The procurement team should obtain the proposed authority allocation, interface and link assumptions, and evidence acceptance criteria before committing to an operational architecture.
The proposal sets out directly relevant remote-oversight objectives. Proposed RO-01 addresses information transfer that supports the end user’s situation awareness; proposed RO-02 addresses sufficient time to intervene and take over control after alerting; and proposed RO-03 addresses alerting that remains active until the end user acknowledges it. Its discussion of RO-02 explicitly rejects a single fixed response time as adequate for every task, because an operator must perceive, interpret, decide and act in context. These are proposed objectives and anticipated means of compliance, not universal operational thresholds. [2, section C.4.8]
The proposal separately cautions that a mismatch between the stated AI classification and the human user’s actual authority can result in over-attributing responsibility to the end user. This reinforces the need to verify who can do what, rather than assigning responsibility through a supervisory label alone. [2, section C.2.1.3]
This creates a useful distinction for decision-makers: human availability describes staffing or connectivity; human authority describes what the person is permitted and technically able to command; human effectiveness asks whether the relevant action can be completed in the available circumstances. None is established by the other two.
The intervention window must be measured end to end
A credible intervention argument begins at a defined abnormal event, not at the moment an operator notices a warning. The timeline must include the system’s detection and alerting delay; transmission and display delay; the operator’s attention, comprehension and choice; the authority check and command path; and the time for the aircraft or associated system to produce the required physical effect.
For a given scenario, the available time before an unacceptable consequence must be compared with the time needed to complete the required protective action. Both values are conditional on operating environment, configuration and human performance. An average completion time cannot, without further analysis, establish performance in demanding or degraded conditions. This is an ODA3 analytical test, not a numerical threshold prescribed by EASA.
Timing is only one dimension. The operator also needs a sufficiently accurate picture of the state of the aircraft or operation. A timely but ambiguous alert can still lead to the wrong choice. A correct command may arrive but fail to execute, be superseded by another control, or take effect too late. For one abnormal condition, ODA3 Institute recommends a traceable sequence: (1) condition detected and alert delivered → (2) alert acknowledged and information understood → (3) intervention selected and authorised → (4) command transmitted and accepted → (5) protective physical effect observed within the available window. Acknowledgement is not proof of comprehension, command acceptance is not proof of physical effect, and a physical effect observed too late is not a successful timely intervention. Logging one milestone does not prove the next.
This matters particularly when one remote operator supervises several automated operations or has other duties. Staffing models, simultaneous alerts, task switching and degraded communications can change the time needed to respond. A design validated for one trained operator under one workload cannot automatically justify a wider operating model.
Seven questions turn oversight into examinable evidence
| Executive or assurance question | Evidence to examine | What examination may establish | What remains uncertain |
|---|---|---|---|
| Does the system detect and correctly raise the alert? | Event-condition definition, detection tests, alarm generation logs | Whether specified triggers and alerts operated in tested cases | Conditions not represented in detection tests |
| Will the person receive and understand the alert? | Alert specification, interface configuration, representative human-factors trials, message and event logs | Whether specified participants recognised and interpreted defined alerts in tested conditions | Untested workload, impairment and unfamiliar abnormal events |
| Can authorised intervention finish in time? | Scenario hazard analysis, time budgets, authority matrix, end-to-end trials and synchronised traces | Whether the required action completed within a defined test window | Conditions outside the tested performance envelope |
| Did intervention change the actual system outcome? | Command provenance, acceptance records, actuator or system-state telemetry and verification observations | Whether a particular command was accepted and the target state observed | Durability of the result and unobserved downstream effects |
| What happens without intervention? | Communications-failure tests, fallback requirements, oversight-system architecture, common-cause analysis | Whether specified local safeguards operated in observed failure cases | Unexamined compound failures and wider operational coverage |
| Does responsibility correspond to actual authority? | Task and role allocations, authorisation logs, operator procedures and responsibility assessment | Whether documented human roles correspond to tested command permissions | Liability attribution under specific facts and law |
| Does the evidence still match deployment? | Software and model versions, sensor and communications configuration, operator training, change records | Whether tested and deployed configurations correspond at the declared boundary | Changes after examination or evidence outside the review period |
The table is a proposed examination structure. It does not represent a regulator-approved evidence checklist. It also does not imply that every listed record exists in a particular aviation programme.
When the operator cannot act, the architecture must carry the safety argument
A remote-intervention model is incomplete if its response to operator unavailability is simply to keep waiting. The safety argument should specify what the system does when the alert is not received, acknowledged or acted upon, when communication is impaired, when situation information is stale, or when the requested intervention is no longer feasible.
EASA’s proposal discusses an operational oversight system that independently monitors an AI-based system and can constrain behaviour or drive it towards a safe state. In its proposed objectives DHO-01 and DHO-02, independence of the oversight system is a design concern, including potential common-cause failures and, when necessary, distinct sensing or communications paths. The concept is more precise than assuming that a remote human is always the final safeguard. [2, section C.5.2]
Installing a separate monitor does not automatically create a safe fallback. Independence needs architectural justification and examination of failure conditions. A fallback must also be feasible for the specific flight phase and operating context; a generic ‘safe state’ is not a universal aircraft manoeuvre. The applicable aviation safety assessment and certification basis remain controlling.
Illustrative scenario — synthetic, not based on an examined system
Consider a remotely supervised aircraft operating within a defined operational design domain—the conditions in which its automated function is intended to operate. During a flight, the automation detects that an environmental condition is approaching an operational limit and alerts the remote operator.
A superficial test records the alert, an operator acknowledgement and an override command. A stronger examination asks whether the operator saw the relevant state before selecting the action, whether the command was valid for the present phase of flight, whether communications delays affected its arrival and whether the aircraft achieved the required response while enough time remained. It then repeats the relevant examination under a defined degraded-communications condition and observes the local protective behaviour if the operator does not intervene.
This synthetic example does not establish a particular aircraft’s safety, the adequacy of its fallback or the probability of a harmful outcome. Its purpose is to distinguish what the safety case claims from what the recorded observations actually establish.
Independent examination can test the claim without replacing certification
Management and the relevant aviation duty holders own the operational concept, controls, safety assessments and supporting records. A suitably competent independent team can examine whether those records and representative tests substantiate specified claims. It might review timing assumptions, reproduce selected scenarios, inspect authority enforcement, reconcile event traces with observed system behaviour and test configuration correspondence.
The outcome must be bounded by system version, operating conditions, tested abnormal events, participating human population, communications assumptions, observation period and known exceptions. The examination record should identify who performed each test, which instruments or logs supplied observations, and how the evidence was retained and linked to the tested configuration. A successful trial under one set of conditions is not evidence of universal safety. An unexamined condition is Unknown, not affirmative evidence of a Gap. A finding of non-conformance needs an applicable criterion and affirmative evidence of a deviation. No such finding is made about any deployed system here.
Integration with existing enterprise evidence. The time-and-authority trace should be linked to the operator’s established hazard and system-safety assessments, human-factors validation plans, software and system verification records, supplier acceptance criteria and configuration/change-control decisions. In projects using standards or guidance such as ARP4754A or DO-178C, the relevant engineering and assurance owners should decide how the observations can be referenced within their established processes. This article does not claim that the proposed trace satisfies, replaces or earns verification credit under either standard. A scoped examination would first identify the applicable approval basis, evidence owners and existing records, then list missing observations and estimate the effort required to obtain them; no project-independent cost or duration can be responsibly quoted.
The approach is analytically transferable outside the European Union, but EASA’s proposed objectives are not requirements in other jurisdictions; local aviation law, approval routes and certification bases govern. For procurement and certification discussions, this evidence can improve the precision of the questions asked. Certification and operational approval still depend on the applicable aviation requirements and competent authorities, not on the existence of a private examination record.
A bounded evidence pack can make underwriting discussions more precise
A scoped independent examination can provide a traceable account of what the operator and system actually did under specified conditions. That account may inform an underwriter’s questions about the declared exposure; it cannot determine how that insurer will price or accept the risk.
Underwriting an organisation’s AI-related operational exposures is different from an insurer using AI to automate its own underwriting. The former is relevant here. An aviation insurer or broker considering a defined exposure may wish to understand whether the organisation relies on remote intervention, which operational limits matter, and whether examination supports the claimed controls.
A specific underwriting question is whether a safety claim depends on human intervention that is demonstrably timely, and whether the responsibility attributed to that person corresponds to their actual authority. EASA’s proposed classification warning gives an operational reason to examine that allocation; it is not a finding of legal liability or a statement of any insurer’s requirements. An insurer may instead consider competent-authority approvals or separately verified system-level safeguards more pertinent to the particular risk. Independent examination is one potential input, not a universal underwriting prerequisite.
The practical underwriting question is: which claimed protection changes the exposure being presented, what evidence supports that protection, and what uncertainty remains for the underwriter to evaluate? The exchange runs in both directions. Insurer to organisation: identify the relevant exposure and request the operational concept, hazard assumptions, authority boundaries, tested intervention and fallback performance, and changes since testing. Organisation to insurer: provide a versioned evidence pack tying the safety claim to conditions, synchronised event records, observed physical effects, exceptions and untested operating states—not just a generic ‘human oversight’ answer. The immediate procedural value is a common list of what has been demonstrated, what remains to be examined and who owns the unanswered questions. In a particular underwriting or reinsurance discussion, that may make evidence requests more specific and reduce ambiguity; a shorter process is not established. Whether it reduces transaction time, changes terms or is accepted by any insurer remains unestablished; those are empirical commercial outcomes, not benefits demonstrated by this article.
A technical failure does not by itself establish financial loss; financial loss does not by itself establish legal liability; and liability does not automatically establish an insurer’s obligation to pay. Coverage depends on the specific policy wording, incident facts and applicable law; contested interpretations may be adjudicated. Independent technical evidence may inform those decisions but cannot substitute for them. Neither premium reductions nor underwriting acceptance are claimed.
Boards should sequence decisions across design, procurement and risk transfer
| Decision horizon | Accountable owner | Evidence or decision required | Reassess when |
|---|---|---|---|
| Before design freeze — approve reliance | Board Risk Committee / accountable aviation executive | Identify the highest-consequence in-scope condition that depends on a remote person; approve reliance only within a declared, testable operating boundary | Independent protection demonstrably replaces the human dependency, or the hazard and operating conditions change |
| Before supplier acceptance — test intervention | Engineering, safety and human-factors leads | Obtain timed alert-to-effect traces, authority tests and representative workload results tied to the delivered configuration | Operator staffing, mission, interface, alert logic or response-time assumptions change |
| Before operation — verify degraded protection | System safety and architecture leads | Demonstrate the declared response to unavailable operators, stale data and failed links; identify common-cause limits | Software, sensing, communications or fallback architecture changes |
| Before the investment and programme gate — resource evidence | CFO / CRO with programme director | Require supplier and operator estimates for trial scope, people, test facilities, schedule, data access and independent review, with assumptions and exclusions | Scope or resource assumptions change materially, or test feasibility is not established |
| Before external reliance and after material change — preserve and disclose | Quality/assurance lead; General Counsel and risk-transfer lead | Reconcile the tested version to the deployed system and disclose supported claims, exceptions and Unknowns to the relevant decision-maker | Deployment, policy wording, obligations or evidentiary validity change |
The sequence is a proposed governance arrangement, not a universal allocation of duties. Every programme should assign responsibility through its own approved operating and certification arrangements.
A related question extends beyond aviation
ODA3 Institute analysis. The same type of evidence question can arise in industrial process control, automated logistics or critical infrastructure operations when an organisation describes a human as its fallback. The decision-maker should establish whether the person sees the right information, has authority and sufficient time to act, and can cause the intended system response. Aviation’s hazards, timing constraints and regulatory framework are not interchangeable with those sectors. The comparison is methodological, not a claim that aviation approval requirements apply to other sectors or that their hazards are comparable.
The decision
A board can now ask a more useful question than whether the system has a human supervisor: which protective action has been demonstrated, by whom or by what system, within which time and operating boundary? For procurement, design approval and risk transfer, the relevant decision is whether the documented intervention and independent protections justify the reliance being placed on them. Where evidence is unavailable, the particular claim remains unestablished; that does not automatically prove the control failed or that every operation must stop. A useful next question for operators, risk committees and underwriters is which evidence of intervention and fallback would actually change an underwriting question or a safety-reliance decision?
References
[1] European Union Aviation Safety Agency. “EASA releases latest issue of its Concept Paper on Artificial Intelligence for comment.” EASA, 3 June 2026. https://www.easa.europa.eu/en/newsroom-and-events/news/easa-releases-latest-issue-its-concept-paper-artificial-intelligence (accessed 22 October 2026).
[2] European Union Aviation Safety Agency. EASA Concept Paper: Guidance for safety-related Artificial Intelligence applications — Proposed Issue 03. EASA, June 2026. Sections B.5.6–5.7, C.4.8, C.5.2. https://www.easa.europa.eu/sites/default/files/dfu/easa_concept_paper_guidance_for_artificial_intelligence_applications_proposed_issue_03.pdf (accessed 22 October 2026).
[3] European Union Aviation Safety Agency. “EASA Artificial Intelligence Concept Paper — Proposed Issue 3.” EASA, publication date not established from catalogue listing. https://www.easa.europa.eu/en/document-library/general-publications/easa-artificial-intelligence-concept-paper-proposed-issue-3 (accessed 22 October 2026).
Methodology note
Claim → intervention milestones → authority → observed physical effect → fallback → versioned evidence → bounded finding. Proposed examination structure, not regulatory approval.
Notably Absent
The EASA catalogue and newsroom checked on 22 October 2026 [1][3] do not establish that Proposed Issue 03 has been adopted as binding certification guidance; the EASA publication records checked continue to describe it as proposed. No aircraft, remote operations centre, supplier or deployed operational oversight system was examined for this article. No representative human-factors dataset, communications reliability distribution, particular hazard assessment, or system-specific timing threshold was supplied. No aviation authority approval, insurer underwriting decision, policy interpretation, premium differential or paid claim was examined. No authorised operator case, named specialist endorsement, primary insurer comment or validated cost/time range was available for inclusion. This article does not establish any FAA or other non-EU equivalence to EASA’s proposed Level 3 objectives. These limits mean the article supports a method for asking and testing better assurance questions, not a conclusion that a particular operation is safe, compliant or insurable.
