News
Our thoughts on EASA’s proposed AI guidelines
In June 2026, EASA published Proposed Issue 03 of its concept paper on artificial intelligence in aviation. It runs to 239 pages, and it feeds directly into the rulemaking task that will turn guidance into binding regulation. The consultation window is open until August 12th.
We spent three weeks reading every page and submitted thirty comments. Some ask for regulatory relief. Six ask EASA to require more obligation on us as a vendor than the paper currently proposes.
Whatever assumptions this document carries into rulemaking are the assumptions our industry will work under for the next decade. Here is our argument, why we made it, and what it means for anyone building or buying AI in aviation.
Why we want AI regulation in aviation
Let’s start somewhere unfashionable for an AI startup: we genuinely support introducing AI regulation in aviation.
Aviation is a high-stakes, safety-critical environment. Agreeing on common safety and performance standards is a no-brainer—it’s how this industry has always operated. Most of what a sensible framework demands from vendors is good software practice anyway: dataset versioning, evaluation suites, defined operating domains, and strict change control.
There are two bigger reasons why regulation is vital right now:
"Vibe coding" doesn't survive contact with complex operations. The current tech narrative suggests everything can be prototyped over a weekend and shipped on Monday, bypassing traditional testing. In complex airline operations, this approach is deceptive. The Pareto principle applies brutally: getting a working prototype takes 20% of the effort, but making it production-grade in a safety-critical environment consumes the remaining 80%. We’ve watched multiple airlines try to shortcut this, only for the outsized cost of the final stretch to consume every initial efficiency gain.
Airlines shouldn't need internal AI governance boards. The standard consultancy advice—that every airline must build complex internal AI governance structures and ethics review boards—is impractical and places the burden on the wrong party. Airlines don't have the specialized manpower or the evaluation datasets required to benchmark frontier models. The vendor has the expertise; the vendor should carry that weight.
A clear regulatory framework gives airlines, airports, and operators the confidence to vet third-party tools quickly without building costly internal bureaucracies.
EASA deserves credit here. They went to extensive lengths to understand the technology, especially around testing, evaluation, and dataset management. In fact, we used several well-reasoned sections of the paper to refine our own internal procedures.
Where the paper stumbles, however, is in its core assumptions about how modern AI software is actually built and deployed.
What the paper changes for generative AI deployments in Airlines
If you sell, build, deploy or maintain AI for airlines, two elements in Issue 03 should catch your attention:
1. The hard ceiling
Language models are classified as hybrid AI and placed under "large off-the-shelf models." Table 2 limits them to the lowest working assurance tier. In operational terms, an LLM-based system may not contribute to a hazard worse than a slight reduction in safety margin or a slight increase in crew workload.
We agree with the ceiling itself. An advisory assistant has no business holding authority over an operational decision where a wrong answer could cause immediate harm. One of our co-founders spent a decade in aviation operations; the idea of an unvetted language model making automated operational calls isn't appealing from that side of the desk either. Our issue is not with the ceiling, but with the flawed rules used to enforce it.
2. The open door
The paper creates a clear route for AI used as an operational tool (separate from software embedded directly in aircraft hardware). It uses a simple two-question filter:
Is the tool used somewhere where a wrong output could increase safety risk?
Is there a process by which an error in the output can be independently detected and addressed?
Answer yes to the second question, and the airline simply adapts four existing areas: its processes, its Safety Management System (SMS), its training procedures, and end-user training. Answer no, and the airline adds four further organizational provisions and must trigger formal software qualification. Those two pages shape every AI procurement process running in airlines today.
Navigating the maze: Finding the sections that actually apply to you
Finding that clear two-page path took us far longer than it should have.
The framework contains 165 numbered objectives and eight organizational provisions. Ninety-three sit in the assurance chapter, and 67 of those cover "learning assurance" (data management, model training, internal weights).
If an airline deploys a third-party product, it holds no training data, no training environment, and no access to the model internals. All 67 of those objectives are completely unreachable. Working out what does apply required reading Chapter C, cross-referencing five levelling tables in Chapter D, checking Table 2, and tracing Figure 7. For an advisory assistant, the relevant subset comes down to fewer than 40 items out of 173.
When only a fifth of a regulatory document applies to a given tool, but you have to read all 239 pages to figure that out, every inspector and every applicant interprets it differently. Inconsistency is what damages a market. We asked EASA to extend their naming conventions across the entire document and provide a clear applicability matrix.
The three flawed assumptions around LLM-based systems
Underneath the specific rules sit three underlying assumptions of which, in our opinion, none reflect modern AI architecture.
Assumption 1: "You trained the model yourself"
Section 3.7 assumes AI models are built in-house for narrow, domain-specific tasks. Follow this through Table 2, and the regulatory incentive comes out completely backwards: an airline training a weak supervised model in-house gets assigned a higher assurance level simply because the training data is traceable, while a world-class model bought from a frontier lab (OpenAI, Anthropic, Google) is penalized.
No airline or aviation vendor can train a custom language model that competes with frontier laboratories. In our proprietary evaluation benchmark, AirlineOpsBench—which evaluates AI models against 20,000+ real operational interactions from pilots, cabin crew, and OCC staff—frontier models consistently outperform smaller, specialized models. As written, the framework prefers a weaker system you can document over a much stronger system you cannot.
Furthermore, the hard ceiling on LLMs stems from Objective RU-02, which requires an applicant to analyze a model’s "unused functions" and switch them off. For an open-ended general-purpose language model, "unused functions" is a meaningless concept. The paper admits this, acknowledges that parameter counts make RU-02 impossible, and concludes that general-purpose models are therefore only warranted at the lowest tier. To EASA’s credit, the same chapter adds that these limitations "will be revisited when experience with AI techniques has been gained".
The ceiling comes from an objective that cannot be applied, rather than from measuring how the deployed system actually behaves.
Assumption 2: "The knowledge lives inside the model"
The assurance chapters assume a model is evaluated on what it memorized during training. That’s why roughly three quarters of those objectives focus on training data, bias, and generalisation: by our count, 67 of the 93 in the assurance chapter.
Nobody builds safety-critical AI assistants this way anymore.
In modern operational systems, we do not rely on what a model learned during training. Live operational information is retrieved from a governed, versioned document corpus at the exact moment a question is asked. The model merely reasons over the provided passages and cites its sources. Manuals change every few weeks; training datasets do not.
Tellingly, across 239 pages, the phrase Retrieval-Augmented Generation (RAG) never appears. Neither does context window, system prompt, or Electronic Flight Bag (EFB). The word hallucination appears once.
When a model reasons strictly over retrieved material, almost everything that decides a correct answer becomes auditable and version-controlled, and what stays uncertain shrinks to whether the model reasoned properly over the passages it was handed. The document corpus, context rules, instructions, and permitted tools are all version-controlled configuration items. EASA can demand vastly stronger evidence across a much smaller surface area simply by recognizing RAG architectures.
For example, Objective K-LKB-03 already requires knowledge bases to be verified for consistency and completeness (no contradictory elements, no unmapped domains). Airline manuals contradict each other constantly. We asked EASA to extend K-LKB-03 to cover document corpora used in RAG systems. We willingly asked for more work on ourselves because we’ve already built tooling to audit airline documentation for contradictions—and it surfaces critical operational gaps that had gone unnoticed for years.
Assumption 3: "An interface can only do harm"
The human factors chapter is derived directly from cockpit design rules. Its sole focus is preventing user error: minimizing misinterpretation, checking outputs, and avoiding over-reliance.
Not a single objective in 239 pages treats an intuitive interface as a safety benefit. The words adoption and uptake never appear. Usability appears only in three senses: preventing errors on the flight deck, describing a good explanation, and justifying a second input modality.
The paper notes that fixed-syntax interfaces create heavy cognitive load, while natural language builds trust and removes friction. But it fails to connect the dots:
Weak interaction design frustrates users.
Frustrated users stop opening the tool.
A tool that sits unopened delivers zero safety benefit.
In real-world airline operations, the primary baseline isn't a pilot making a mistake because of AI; it’s information overload and app fatigue. In our user data, 63% of operational personnel report being unable to retrieve the information they need during time-critical decisions, or taking up to 30 minutes to find it in long PDF manuals.
Safety must be viewed through the classic "Swiss Cheese" model. An AI assistant that is opened dozens of times a day, citing authoritative source passages for every answer, dramatically reduces operational risk compared to a long manual that nobody reads under pressure. Scoring only the harm an interface might cause while ignoring the safety risk of unread information steers the industry toward clunky, unusable software that sits untouched in a menu.
The root cause: Written for a "single applicant" that doesn’t exist
Why do these gaps exist? Because the document addresses its objectives to a single "applicant" (a word used 59 times). In traditional aircraft manufacturing, one entity designs the part, builds it, and holds the certificate.
In modern AI software deployment, four distinct parties exist:
The AI lab (e.g., OpenAI, Anthropic): Holds model weights, training schedules, and base architecture.
The software vendor (Overwatch AI): Holds the retrieval pipeline, integrations, context engineering, system instructions, safety guardrails, and benchmarks.
The airline: Holds manual contents, operating procedures, SMS, and user training.
The end user (pilot, dispatcher, crew): Exercises final operational judgment.
Because the paper speaks to only one party, compliance obligations fall arbitrarily on whoever happens to be holding the document. The paper asks airlines to establish the availability of technical documentation that only an AI lab holds, and places organizational provisions on airlines whose supporting evidence only the vendor can produce.
EASA's own guidelines state that no responsibility should be assigned to a person who lacks the authority, information or means to fulfil it. That objective applies only from Level 2B, so it never reaches the advisory tools now entering service. The framework needs to explicitly separate vendor obligations from airline operator obligations.
What we proposed for the hard ceiling
To be completely clear, our position on the Table 2 ceiling has three parts:
We accept that general-purpose models should default to the lowest tier. Unconstrained language models should not hold autonomous operational authority.
We object to setting the cap based on impossible metrics (RU-02). The ceiling should be derived from demonstrated containment—proving the model operates strictly within a declared domain, behaves predictably on out-of-domain queries, and is monitored continuously in service.
We asked for the ceiling to be movable by ONE step if a safety benefit is proven. Currently, Section B.5.8 offers a "safety credit" (reducing assurance requirements by one step) for systems that measurably improve operational safety. However, Table 2 separately caps LLMs at the bottom tier, and the paper forbids any reduction below that tier. Language models therefore cannot use the credit at all, whatever their real-world performance.
Allowing a one-step relief mechanism under four strict conditions—safety benefit measured in the real operation, an independent process for catching errors, continuous monitoring with a rollback trigger, and the system staying out of the higher hazard classes—rewards vendors who build genuinely safer tools without opening up high-risk or catastrophic hazard classes to AI automation.
Summary: Our main suggestions for a more pragmatic framework
To turn these insights into constructive regulatory progress, we submitted detailed recommendations across 30 specific areas of the concept paper. Our primary proposals can be summarized in four high-level pillars:
1. Unbundle the ecosystem
EASA should explicitly define the roles of Foundation Model Providers, Application Vendors, Deploying Organisations, and End Users. Qualification of an application should be transferable: once a software vendor qualifies an AI tool’s technical stack, any approved airline should be able to deploy it by simply verifying its operational scope and establishing standard oversight procedures.
2. Recognize Retrieval-Augmented Generation (RAG) and context engineering
The framework should differentiate between models that answer from internal parameter memory and systems that operate via RAG. For RAG systems, regulatory focus should shift to corpus governance, document version control, retrieval accuracy, and explicit citation enforcement, rather than treating the general-purpose model as an unmodifiable black box.
3. Establish a "Net Safety Credit" mechanism
The regulation currently allows a safety credit that lowers required assurance levels for systems proven to make operations safer—yet Table 2 separately caps off-the-shelf LLMs at AL5, and the paper forbids any reduction below AL5. Language models therefore cannot use the credit at all. We propose allowing proven, real-world operational safety benefits to unlock a one-level credit for advisory tools (Level 1B), provided continuous monitoring, clear rollback triggers, and human oversight remain intact.
4. Provide clear transition arrangements and EFB integration
Airlines are already running operational AI aids today. The final rules must establish clear transition arrangements for existing deployments, stating explicitly how legacy operating data can be used as compliance evidence. Furthermore, the framework must explicitly address how ground-based operational aids and flight-deck Electronic Flight Bag (EFB) applications interface with these AI guidelines.
What about AI in use today?
As an industry, we need to be transparent: No formal approval yet exists for operational AI software under this framework. Issue 03 is still guidance.
When an airline adopts an AI tool today, the approval routes through that airline's existing operational authority and procedures. The airline's authority asks the questions; the airline provides the answers; the vendor supplies the technical evidence behind the scenes.
What a responsible vendor can honestly claim today is that their system is engineered against EASA’s applicable objectives, that risk classifications are documented, and that the airline has been given the material it needs for its own part of the work.
Looking ahead
EASA’s Concept Paper Issue 03 represents a big effort to bring structure and safety to one of the most transformative technologies of our era, all while considering the high-stakes nature of the aviation industry. This is not an easy gap to bridge and the team at EASA deserves immense credit for taking on such a complex challenge as the first regulator in the world.
However, for regulation to achieve its true purpose—enhancing safety without choking innovation—it must better reflect the operational realities of how modern AI software is built and used. Especially when considering the faced-paced developments in AI technology.
We believe that with some adjustments along the lines of our proposals, together with other industry input, EASA can build a regulatory framework that definitely sets a global gold standard for aviation AI safety.
The public consultation period remains open until August 12th and we encourage fellow technology providers, airlines, operational staff, and industry stakeholders to read the concept paper, engage in the dialogue, and submit their feedback. EASA has explicitly asked for industry input, and this consultation is our best opportunity to ensure regulations remain strict, realistic, and operationally viable.
On another note we’re always open for exchanges around AI in aviation, so please feel free to get in touch with our team if you want to chat.