Artificial intelligence is beginning to move from research prototypes into safety-related airborne and aviation operations. For safety teams, airborne AI assurance creates a real challenge. For decades, airborne systems certification has relied on software whose behaviour is explicitly specified, implemented, reviewed, and verified. Machine-learning-based functions do not fit that pattern cleanly because part of their behaviour is learned from data, model architecture, and training processes.
Airborne AI assurance therefore has to connect two worlds that have often been treated separately: AI engineering and aviation safety engineering. The question is not only whether a model performs well on a validation dataset. The question is whether its behaviour, limits, data assumptions, failure modes, and mitigations can be turned into certification-relevant evidence.
Airborne AI Assurance: The Regulatory Picture Is Moving
EUROCAE ED-324 / SAE ARP6983 is intended to provide a harmonised recommended practice for the assurance of AI applications in aviation while remaining compatible with the existing certification ecosystem. Its first scope is deliberately narrow: non-adaptive, offline-trained machine learning using supervised-learning methods in airborne and ATM/ANS domains.
That limited scope is important. Topics such as online learning, reinforcement learning, generative AI, ethics, cybersecurity, and human factors are not solved by ED-324 / ARP6983 alone. They sit either outside the first issue or in complementary guidance from EASA and EUROCAE.
EASA’s AI Roadmap and AI Concept Paper have also taken a conservative position on safety contribution and assurance level allocation. Issue 2 of the EASA AI Concept Paper, published in 2024, focused on Level 1 and Level 2 machine-learning applications. On June 3, 2026, EASA released Proposed Issue 3 for comment, broadening the discussion toward additional AI techniques such as reinforcement learning and symbolic AI, as well as Level 3 applications. That is an important evolution, but it does not remove the need for cautious allocation of safety responsibility.
For supervised learning, the initial EASA position limits accepted applications to AI/ML constituents that do not include the highest assurance levels, such as IDAL A or B, SWAL 1 or 2, or AL 1 to 3. For unsupervised learning, the initial limit is lower, around IDAL D, SWAL 4, or AL 5. AI may still be used within systems associated with high-level hazards, but the architecture, requirement allocation, monitoring, and independent mitigations must prevent the AI/ML constituent itself from carrying an unsupported high-criticality assurance burden.
The AI/ML Constituent as an Assurance Boundary
A central concept in ED-324 / ARP6983 is the AI/ML constituent. This is a bounded container that includes at least one ML model and any associated pre-processing or post-processing. The concept introduces an intermediate assurance layer between system development assurance and item-level software or hardware implementation assurance.
That layer complements existing standards. It does not replace ARP4754B/ED-79B, DO-178C/ED-12C, DO-254/ED-80, or ARP4761A. From a lifecycle perspective, this means that data management, model design, training, verification, and performance evidence must be synchronised with conventional system reviews such as SRR, PDR, and CDR.
It also means that derived requirements and model limitations must flow back into the safety assessment process. A limitation discovered during data analysis or robustness testing is not just an AI engineering note. It may become a safety assumption, an operational domain constraint, a monitoring requirement, or a mitigation requirement.
Anzen has discussed this connection before in the context of Model Based Safety Analysis in ARP4761A, where safety evidence is connected to system models rather than handled as a disconnected document set. The same principle applies to AI: the model, the data argument, and the system safety argument have to stay linked.
Why Traditional Safety Techniques Need Adaptation
Conventional safety techniques such as Functional Hazard Assessment (FHA), Failure Modes and Effects Analysis (FMEA), and Fault Tree Analysis (FTA) remain essential. They define hazards, failure conditions, causal paths, effects, and mitigations. However, they do not naturally capture how ML models fail.
ML failure behaviour is statistical and data-dependent. A model may perform correctly under the conditions represented in its training and validation data, then degrade when operational inputs move away from those conditions. This can appear as false negatives, false positives, confidence miscalibration, poor generalisation, distribution-shift sensitivity, or robustness limitations.
For example, an obstacle detection model may report high confidence for a wrong classification, perform well on the validation dataset but poorly on a new airport layout, degrade in snow or glare conditions that were under-represented during training, or become unreliable when sensor noise, image compression, or calibration errors affect the input.
This is why the safety assessment cannot ask only whether the function has “failed” or “not failed”. It must describe the model’s relevant error modes and connect them to system-level consequences.
Quantitative Safety Assessment Has a Hard Limit
The quantitative question is especially difficult. Any statistical estimate of ML error is meaningful only with respect to a defined operational domain, an exposure model, a dataset representativeness argument, a confidence bound, and the monitoring or mitigation architecture around the AI/ML constituent.
Today, there is no accepted method to credibly translate ML performance metrics directly into a failure rate per flight hour. This is consistent with the historical treatment of software assurance: confidence is built through development assurance objectives, verification evidence, reviews, and process control, rather than through direct probabilistic failure-rate allocation.
Hardware hosting the ML function still remains subject to conventional quantitative safety targets. The ML model itself needs a dedicated assurance argument. That argument should explain where the performance evidence is valid, what assumptions it depends on, what operational cases are not covered, and which architectural mitigations protect the aircraft or operation if the model behaves outside expectations.
Example: Obstacle Detection and Confusion Matrix Thinking
Consider an ML-based obstacle detection function. A binary “failed/not failed” view is too shallow because the safety meaning depends on the type of classification outcome:
- False negative: a real obstacle is missed. This is usually the primary safety concern.
- False positive: an obstacle is reported where none relevant to the function exists. This may not be immediately hazardous, but frequent false alarms can erode crew or operator trust.
- True positive: a real obstacle is correctly detected.
- True negative: no obstacle exists and none is detected.
The required ML performance should be driven by the hazard classification and the function’s operational role. For a Major detection function, metrics such as recall, precision, residual error rate, confidence thresholds, and robustness limits become safety-relevant requirements.
High overall accuracy can still be unsafe if recall is poor and the model misses rare but safety-critical events. A dataset dominated by easy negative cases may produce an attractive headline metric while hiding the very cases that drive the safety argument.
What Certification-Relevant AI Evidence Should Contain
The practical challenge is to connect AI engineering, safety engineering, and certification strategy into one assurance process. Organisations that treat AI as a standalone software innovation will struggle when certification questions arrive. Organisations that integrate AI behaviour, data evidence, operational domain definition, failure modes, and system mitigations from the beginning will be better positioned.
For an airborne AI function, certification-relevant evidence should normally address:
- the boundary and interfaces of the AI/ML constituent;
- the operational design domain and exposure assumptions;
- dataset representativeness, coverage, provenance, and configuration control;
- model performance metrics tied to safety-relevant outcomes, not only aggregate accuracy;
- known limitations, distribution-shift sensitivities, and robustness evidence;
- derived requirements, monitoring assumptions, and mitigation strategies;
- traceability between hazards, requirements, data, model verification, and system-level safety arguments.
This evidence should be planned early enough to influence architecture. If the AI/ML constituent cannot support a high-criticality requirement by itself, the system design has to allocate that responsibility elsewhere through independent monitoring, procedural mitigations, redundancy, restriction of the operational domain, or fallback modes.
How Anzen Can Help
At Anzen, we help organisations use AI in safety-related and mission-critical systems. In this context, AI should not be introduced first and justified later. It should be part of a structured safety and certification strategy from the beginning.
Our work focuses on connecting AI engineering with the processes already expected in aerospace development. This includes defining the operational domain of the function, identifying safety-relevant failure modes, allocating requirements at the correct level, and ensuring that data, model performance, KPIs, and monitoring assumptions are captured as certification-relevant engineering evidence.
For companies exploring airborne AI integration, Anzen can support the assurance preparation process through:
- definition of AI constituent boundaries and interfaces;
- alignment with ARP4754B, ARP4761A, and the emerging ED-324 / ARP6983 framework;
- safety assessment of AI-related failure modes, including false positives, false negatives, confidence miscalibration, robustness limitations, and distribution shift;
- translation of model performance metrics into safety requirements and verification objectives;
- definition of monitoring and mitigation strategies;
- preparation of structured assurance arguments to support certification discussions.
AI integration in airborne systems is moving from research toward industrial environments. The organisations that prepare now with the right safety architecture, lifecycle interfaces, and assurance evidence will be the ones best placed to deploy AI applications with confidence.
About the authors
Antonio Fernández Ameneiro is a Senior Safety & Reliability Engineer, also managing ANZEN Program Management Office (PMO).
He supports aerospace and defence programmes in system safety, systems engineering and the certification of critical systems, working across civil and defence frameworks. He also acted as a panelist on ED-324 at the EUROCAE Symposium 2026 in Dublin.
Daniel Villafañe is an aerospace engineer with expertise in avionics, systems engineering and model-based design and analysis.
At Anzen, Daniel’s work is focused on ATICA, our model-based tool for safety analysis. Daniel is in charge of building system models and applying systems engineering processes while using ATICA to improve results on safety and reliability analyses for aerospace avionics projects.
