If your AI system may face EASA approval, you need certification-ready controls from day one. The article’s main point is simple: I should treat EASA alignment as a build-stage requirement, not an end-stage document task.
Here’s the short version:
- Classify the AI by its role in the workflow, not by model type
- Set the system boundary early, including inputs, outputs, limits, fallback states, and human authority
- Map requirements before model work starts so hazards, tests, and evidence stay linked
- Use runtime guards and fallback logic outside the model to keep behavior inside approved limits
- Build evidence for data quality, test independence, ODD coverage, explainability, and retraining stability
- Check supplier data, models, and tools before they enter the certification package
- Run a formal release review for ODD fit, training, logging, cybersecurity, and named approvals
- Keep in-service monitoring inside the SMS, especially since EASA SMS rules now apply across key organizations as of 12/02/2024 and 03/07/2025
A few dates drive the timing here: May 2023 for AI Roadmap 2.0, March 2024 for Concept Paper Issue 2, and 2025 for NPA 2025-07 under RMT.0742. The article also points out one hard recordkeeping fact: under the EU AI Act, some high-risk AI records must be kept for 10 years after market placement.
If I had to reduce the whole article to one line, it would be this: define the AI’s job, bind its limits, prove those limits with traceable evidence, and keep that proof intact through suppliers, release, and service life.
That’s the frame the rest of the article builds on.
EASA AI Certification Lifecycle: 7-Stage Compliance Roadmap
Day 2 - EASA Artificial Intelligence Days 2025
1. Start With EASA’s AI Trustworthiness Framework
EASA’s trustworthiness framework sets the bar for evidence, oversight, and control for each AI function. Use that classification to define scope, human oversight, and how much evidence you need.
EASA AI Levels and Application Boundaries
EASA classifies AI based on operational authority in the workflow, not model type. Level 0 supports low-risk tasks. Level 1 helps a human. Level 2 shares tasks with the human. Level 3 automates work with limited or no override. The point isn’t to label the model. The point is to define the certification scope.
EASA’s most developed guidance covers Level 1 and Level 2 applications. So if your use case lands there, you have the strongest reference material to work from. For example, a machine learning model that ranks maintenance fault candidates for an engineer is a Level 1 function. Put that same model inside a system that shapes a maintenance decision without human review, and it starts moving toward Level 2 or higher. The rule of thumb is simple: classify the system by what the AI actually does in the workflow, not by the vendor label.
Set the application boundary with care. Define the intended use, operating phase, allowed inputs and outputs, degraded modes, and the assumptions behind the human role, aircraft state, data quality, and connectivity. Also separate the AI model from the surrounding logic, such as alerting, fallback, and supervision layers. If the boundary is fuzzy, requirements, hazards, and verification scope get fuzzy too. That boundary becomes the starting point for requirements mapping and hazard analysis.
The Four Building Blocks of Trustworthy AI
EASA groups trustworthiness work into four connected building blocks. Each one should lead to specific program artifacts.
Trustworthiness Analysis (TA) is the entry point to the other three blocks. It maps the AI’s risks, ethical considerations, and high-level objectives to aviation-specific requirements. The output is a documented argument for why the AI is acceptable in its intended context, along with its assumptions and limits.
AI Assurance (Learning Assurance) provides evidence that the model, data, and architecture perform as intended across relevant conditions. That includes training documentation, validation results, data representativeness analysis, and performance metrics by operating condition.
Explainability makes sure AI behavior can be understood well enough for safety, oversight, and accountability, even when the model itself is hard to inspect.
Safety Risk Mitigation (SRM) covers runtime constraints, fallback paths, human-in-the-loop design, and continuous monitoring logic for failure cases.
Each block needs traceable artifacts that connect requirements, design, and test results. A requirement for bounded operation should turn into architecture rules for confidence thresholds and fallback transitions. A requirement for transparency should turn into interface and logging specs. In short, each block should map to a named requirement, control, or verification artifact.
How EASA Guidance Connects to the EU AI Act
Many aviation AI systems fall into the EU AI Act’s high-risk category. That triggers duties around risk management, data governance, documentation, logging, human oversight, and post-market monitoring. Article 108 folds those duties into EASA’s certification framework, which means one documentation set can support both review paths. That can save a lot of pain later by avoiding separate evidence tracks.
2. Plan the Program and Map Requirements Early
Planning is where many aerospace AI programs either get on solid ground or drift toward expensive rework. The job at this stage is straightforward: turn EASA concepts into a certifiable delivery structure before model development begins. Use the AI level and application boundary from the trustworthiness framework to set the program baseline.
Classify the Use Case, Safety Criticality, and Assurance Context
Start with three plain questions about the AI function: What does it do in the workflow? What happens if it fails? Which certification framework applies to the system around it?
An advisory model that shows maintenance fault candidates to a technician lives in a very different assurance context than a cockpit decision aid that influences crew action during a critical flight phase. Map the function to its certification baseline - ARP4754A, ARP4761, and DO-178C/ED-12C where software assurance applies - before any model work starts. That mapping sets the bar for requirements, verification, and documentation. It also shows what evidence a regulator will expect before approval.
One useful output here is a classification memo. It should state:
- the intended function
- failure consequences
- development assumptions
- the evidence needed before model work begins
This helps teams avoid building too much for low-risk tools and too little for safety-relevant ones.
Define ConOps, Human Roles, and Trustworthiness Objectives
Next, turn that classification into operating assumptions, human roles, and decision limits. The ConOps takes mission intent and converts it into certifiable requirements. It should describe the real operating setting in enough detail for engineers, safety assessors, and regulators to judge whether the AI fits the intended mission.
That means documenting mission phase, platform context, operating limits, degraded modes, and human roles. For example, a taxiing advisory system should spell out runway visibility assumptions, sensor confidence thresholds, when the pilot must override a recommendation, and what the system does when confidence drops below that threshold. Assign decision authority, monitoring responsibility, and override authority in clear terms. Avoid vague phrases like “human oversight.” Trustworthiness risks and misuse cases - such as overreliance on AI outputs or use outside the validated envelope - should be planned outputs, not casual assumptions.
Build an Audit-Ready Requirements Map
An audit-ready requirements map ties each AI requirement to a business need, safety objective, design constraint, and verification method. It should trace from high-level operational goals down to model behavior requirements, data assumptions, performance thresholds, explainability needs, and acceptance criteria.
Take a requirement like: “the model shall flag anomalous sensor combinations with no more than X% false negatives under specified conditions”. That requirement should connect to the hazard it addresses, the dataset used to support the threshold, and the test procedure used to verify it. The map should also record data provenance assumptions, class imbalance limits, and model operating boundaries. For example, it may state that the model is not valid below a given confidence level, or that only approved sensor set versions may be used.
Version control, requirement ownership, and change approval paths should live in the same map. That gives auditors one source of truth and cuts the risk of critical evidence being buried across slide decks or vendor emails.
Use this requirements map as the direct input for architecture controls, test planning, and certification evidence. The traceability should carry straight into architecture controls and verification artifacts.
3. Design Architecture Controls That Support Certification
Once your requirements map is ready, the next step is to turn it into architecture controls that regulators can actually inspect. In plain terms, you need to set clear limits for the model, watch those limits in operation, record how decisions happen, and switch to a safer mode when confidence drops. That’s how planning turns into runtime control.
Use Safety Architectures With Runtime Limits and Fallback Paths
Runtime limits should sit in the control logic around the AI component, not inside the model itself. Start by defining the ODD, then enforce it with an independent monitor or safety channel. That monitor should reject out-of-bounds outputs and move the system to a conservative fallback when inputs drift outside the validated domain. Runtime monitoring must block out-of-domain inputs before they reach the operator [1].
One of the most practical patterns here is diverse redundancy. Pair the AI function with a deterministic check. If the two disagree, trigger alarms or voting logic. That helps cut down common-mode failures and gives the safety case hard evidence to point to.
Once the AI is bounded, the next step is simple: decide who supervises it and who has the power to override it.
Control Human-AI Teaming, Interfaces, and Cybersecurity
Use the ConOps-defined role - human-in-the-loop, human-on-the-loop, or human-in-control - to set authority, override paths, and continuous status display. For human-on-the-loop cases, where the AI acts within set bounds without per-action approval, workload analysis matters. You need proof that operators can supervise the AI without getting overloaded.
Alert design should spell out what failed, why it matters, and what to do next. Standardized alert hierarchies - warnings, cautions, and advisories - should line up with current cockpit or maintenance conventions. Then test them with operational crews through simulation and human factors evaluations.
Poisoning, adversarial inputs, and model tampering should be treated as airworthiness threats. Common controls include:
- integrity checks
- provenance tracking
- signed models
- runtime integrity monitoring
For connected or cloud-assisted AI services, document how encryption, latency, and availability limits interact with safety requirements. Those controls belong in the safety case itself, not in some separate IT checklist.
Those actions should feed into the same audit trail used for certification review.
Set Governance Rules for Observability and Decision Records
Log inputs, outputs, ODD state, confidence, and human interventions in append-only, tamper-evident records tied to model and dataset versions. Those records support traceability from runtime behavior back to verification evidence.
Governance rules should state which events must be logged, such as:
- out-of-domain detections
- safety envelope violations
- AI disengagements
They should also define retention periods and access controls. Model change approvals, configuration management, and incident reporting procedures need to exist as documented policies, not hallway agreements or unwritten habits.
For tighter governance control, Ryshe Quanta can centralize policy enforcement, observability, and append-only audit records tied to validation, approvals, and rollback.
4. Build Learning Assurance and Certification Evidence
Once runtime controls are in place, you still need proof that the model stays inside those limits. That’s what learning assurance does. It links the design intent to the evidence a reviewer can inspect.
Prove Data Quality, Representativeness, and Independence
Auditors need to rebuild the story of the model from end to end: how it was built, how it was tested, and where its limits sit. This is where many certification packages start to crack. A model can look strong on internal benchmarks and still fail review if no one can trace the data source, labeling process, or test-set independence.
Your data package should include:
- formal quality criteria
- automated quality reports for each dataset
- a dataset bill of materials listing every source system, acquisition period, and responsible organization
Each dataset also needs traceability back to source data and every intermediate transformation. If an auditor wants to replay the pipeline, they should be able to do it.
Training, validation, and test sets should be split by independent units such as tail number, route, or time window. Don’t random-shuffle records and call it done. If any overlap exists, explain it in the safety case.
You also need documented coverage against the ODD. In plain terms, show where the model has support and where it doesn’t. That means distribution plots for key variables like altitude in feet, airspeed, weather conditions, and airport configurations. Those plots should use thresholds that separate adequate coverage from out-of-scope conditions. Any uncovered or thinly represented regime should be flagged directly.
Apply a Learning Assurance Lifecycle With Structured V&V
After data integrity is set, verification and validation need to follow the model through the full learning cycle. EASA treats learning assurance as iterative V&V across the lifecycle, so checks don’t happen at one point and stop there. They happen again and again as the system moves forward.
Each stage needs its own documented V&V work:
- requirements
- data preparation
- training
- evaluation
- implementation
- integration
- operational validation
Performance thresholds should come from safety objectives, not from convenience. If an ML-assisted function supports a safety-critical decision and that decision has a maximum acceptable failure probability, part of that failure budget must be assigned to ML misclassification. From there, allowable false positive and false negative rates are calculated inside the ODD.
Robustness requirements should be written in physical units. That keeps the work aligned with aerospace engineering practice. For example, performance may need to stay acceptable when altitude inputs shift by up to ±200 ft or temperature readings shift by ±3 °F.
Explainability evidence should tie model behavior back to safety objectives. Feature attribution methods, such as SHAP, can help show which inputs drive predictions and whether those inputs match domain knowledge. For every safety-critical decision, logs should record the main contributing factors and confidence levels so investigators and regulators can review ML behavior after an incident.
Stability matters too. Key safety metrics should vary by no more than a defined percentage across multiple retraining runs. And if distribution shift moves beyond control limits, revalidation should kick in.
Structure the Certification Package for Review
The certification package needs to gather all reviewable evidence in one place. Every artifact, including requirements, datasets, model versions, test results, limitations, and operational assumptions, should map to a specific trustworthiness objective.
The EU AI Act requires providers of high-risk AI systems to retain technical documentation and compliance records for 10 years after the system is placed on the market, so configuration management and archive controls are not optional. [2]
The table below links core evidence types to EASA trustworthiness objectives and shows what each item is meant to prove during review.
| Evidence Type | EASA Trustworthiness Objective | Review Purpose |
|---|---|---|
| Data Assurance Report (lineage, quality, split independence) | Learning Assurance | Prove data origin, integrity, and independence across training, validation, and test sets |
| ODD Coverage and Bias Analysis | Learning Assurance / Safety Risk Mitigation | Show model support across all intended operational conditions |
| Safety-Linked ML Requirements Specification | AI Safety Risk Mitigation | Map each safety objective to ML metrics, test regimes, and acceptance criteria |
| Training Reproducibility and Stability Records | Learning Assurance | Confirm consistent model behavior across retraining runs and data resamples |
| Edge-Case and Robustness Test Reports | Technical Robustness | Demonstrate safe behavior under rare events, sensor degradation, and distribution shifts |
| Explainability Logs and Feature Attribution | AI Explainability | Show that safety-critical decisions rely on physically sensible inputs |
| Integration and HIL/SIL Test Results | Learning Assurance / Integration Verification | Verify required model behavior is preserved after integration into the target system |
| Configuration Management Records | Accountability / Traceability | Ensure the approved model version can be reconstructed and re-audited |
These artifacts then serve as the baseline for supplier qualification and deployment review.
5. Review Supplier Inputs, Deployment Readiness, and In-Service Controls
Once the evidence package is put together, the next step is to check the outside inputs and release controls that make the package believable.
Qualify Supplier Data, Models, and Assurance Inputs
Section 4’s certification package is only as strong as the supplier inputs behind it. Third-party data, pre-trained models, and tool outputs can still introduce risk long after contract award.
Review supplier artifacts for:
- completeness
- traceability
- technical fit
- IP clarity
- assurance maturity
The biggest problem is usually technical fit. Data needs to match your ODD, include edge cases, and meet quality bars that fit the safety classification of the function. For models, that means recorded performance in safety-relevant scenarios and resistance to distribution shifts. EASA guidance also says that when data comes from outside providers, contracts must define the restricted origin stage - the point in the pipeline treated as the source - and explain how that source was managed up to that point [3].
Ask for a detailed artifact list, audit rights for supplier processes and source data, and advance notice of any dataset change, retraining, or architecture update. At each milestone, use a Supplier Assurance Plan annex to track those duties.
For tools like AutoML, labeling, and simulation, ask for DO-330 / ED-215 qualification packages, including TQL classification and downstream verification evidence.
Run a Deployment Review Before Release
After supplier inputs pass review, treat deployment as the last certification gate. A deployment review is a structured check that confirms the system is safe to operate. Before sign-off, the review should cover seven areas:
| Review Area | What to Confirm |
|---|---|
| ODD alignment | Documented operational conditions match certification assumptions and actual deployment plans |
| Fallback behavior | Fallback states are implemented, tested, and triggered correctly when confidence drops below threshold |
| Operator training | Crews and ground staff have completed training on AI capabilities, failure modes, and intervention procedures |
| Monitoring hooks | Telemetry, decision logs, confidence scores, and anomaly flags are recording with sufficient granularity |
| Cybersecurity controls | Interfaces are hardened, access is controlled, and deployment configurations are locked |
| Change control | No artifact can be modified outside a documented change request with safety impact analysis |
| Named approvers | Named technical, safety, cybersecurity, and operational approvers have formally released the system |
Run adversarial input testing before release. That kind of scanning belongs in the deployment review, not after launch.
Conclusion: A Practical EASA Alignment Checklist
Use this checklist to spot gaps before certification.
| Lifecycle Stage | Key Question |
|---|---|
| Use case classification | Have AI functions been formally classified by safety criticality and assurance context? |
| Trustworthiness objectives | Are ConOps, human roles, and trustworthiness objectives documented and approved? |
| Architecture controls | Do runtime limits, fallback paths, and human-AI teaming interfaces meet safety requirements? |
| Learning assurance | Is there documented evidence of data quality, ODD coverage, and structured V&V across the full lifecycle? |
| Supplier qualification | Have supplier data, models, and tools cleared defined acceptance gates with contractual evidence obligations? |
| Deployment review | Have ODD alignment, fallback behavior, operator training, monitoring, cybersecurity, and sign-offs been confirmed? |
| In-service governance | Are drift monitoring, occurrence reporting, change control, and feedback loops active and documented in the SMS? |
EASA’s SMS requirements are now mandatory for Part 21 design and production organizations, ETSOA holders, and APU designers as of March 7, 2025, and for Part 145 maintenance organizations as of December 2, 2024 [4][5]. In plain terms, AI assurance and in-service monitoring need to sit inside your organization’s management system. They can’t live off to the side as a separate technical function run only by the AI team.
Ryshe’s senior-led delivery and Quanta can support governance, observability, and evidence capture.
FAQs
How do I determine the right EASA AI level for my system?
Start with a readiness check for your data and governance. Look at data accuracy, completeness, consistency, timeliness, accessibility, ownership, policies, quality monitoring, access control, and lineage.
Then get clear on the use case, success metrics, and kill criteria. After that, test your deployment assumptions around infrastructure, integration, monitoring, operations, and security/audit trail so the AI’s risk posture lines up with its certification needs.
What evidence should we start collecting before model development begins?
Before model development, document your compliance workflows, including approval chains and regulatory requirements. Start with the rules of the road. Who needs to sign off? Which policies apply? What has to be recorded for audit or review? If this work is fuzzy at the start, it usually turns into delays later.
Next, inventory your data systems to confirm governance, access, and quality controls. This step sounds boring, but it saves a lot of pain. You need to know where data lives, who can use it, how it’s monitored, and whether it’s clean enough for the job. It also helps to resolve conflicting term definitions early, so teams aren’t building around different meanings of the same metric or label.
You should also define your security architecture before anything moves forward. Spell out how data will be stored, moved, protected, and monitored. At the same time, identify high-value use cases instead of trying to tackle everything at once. Pick the work that connects to a clear business need, not just the most flashy idea.
Then set clear success criteria and risk thresholds. Be specific. Decide what good performance looks like, which risks are acceptable, and where the line is. Finally, assign one accountable owner tied to a specific, measurable business metric. One person should own the outcome, and that outcome should connect directly to a number the business already cares about.
How should AI monitoring and change control fit into our SMS?
Treat AI monitoring and change control as part of your SMS or quality system’s continuous monitoring loop. Measure model and system performance, track changes in rules and standards, and check the AI at set intervals against your established manual process.
Keep a full, time-stamped audit trail for every input set, output, and model or configuration version. Include user attribution and traceability, so you can see who did what and when. Then connect deployments and updates to controlled change workflows to support compliance readiness.
