AI Trustworthiness in MRO Software: EASA's 6 Design Imperatives

EASA's AI trustworthiness framework is redefining how AI-enabled Maintenance, Repair, and Overhaul (MRO) software must be designed, validated, and governed in aviation. AI systems used for predictive maintenance, fault detection, work-scope optimization, and maintenance decision support must include assurance by design, human oversight, explainability, data governance, and continuous risk monitoring.

How regulatory governance of artificial intelligence is reshaping the architecture and assurance requirements for maintenance, repair and overhaul software systems

The European Union Aviation Safety Agency (EASA) published its first Notice of Proposed Amendment (NPA) 2025-07 on AI trustworthiness. This regulatory proposal establishes a clear framework for deploying AI-based assistance and human-AI teaming within regulated aviation systems.

The scope of EASA's AI framework extends across three domains critical to MRO: continuing airworthiness, operational support systems, and decision support. The framework addresses two distinct levels of AI deployment: Level 1 (assistance systems that augment human decision-making) and Level 2 (true human-AI teaming where the system and human jointly manage critical processes). MRO software deploying AI in any of these domains, whether through machine learning-driven fault prediction, schedule optimization, or compliance monitoring, must now embed assurance, traceability, human-factors design, and ethics considerations into the system architecture from the outset.

MRO Software vendors and operators must classify AI systems by EASA's level framework and hazard model to determine assurance rigor. EASA defines six AI levels by automation degree and human authority: Level 1A (information augmentation - fault alerts); Level 1B (decision support - AI recommends, human decides); Level 2A (directed automation - human monitors every action); Level 2B (supervised automation - human monitors outcomes, not every action); Levels 3A and 3B (safeguarded and non-supervised advanced automation; 3B reserved).

1. AI Assurance and Validation Architecture for Maintenance-Critical Systems

MRO software systems deploying AI for fault prediction, life-management, or work-scope recommendation must establish a formal assurance case demonstrating AI model performance under real-world maintenance conditions, not laboratory test sets alone. This includes rigorous definition of the Operational Design Domain (ODD).

The regulatory framework requires that any AI system used to support maintenance decisions carry documentary evidence of its performance boundaries: accuracy metrics, false-positive and false-negative rates, confidence intervals, and documented edge cases where the system is known to perform poorly. A fault-prediction algorithm trained on CFM56 engine data may be accurate within narrow operating envelopes but degrade significantly when applied to mixed-fleet operations, seasonal anomalies, or installations with non-standard configurations.

Central to this assurance process is the definition of the Operational Design Domain (ODD), the specific set of operating conditions under which the AI model's performance is guaranteed. An MRO ODD for a fault prediction system might specify: applicable engine families (CFM56-5B1/2/3, variants only). The ODD defines the boundary within which the MRO System guarantees model performance; outside the ODD, the system must alert the operator and, if necessary, recommend fallback strategies.

MRO software systems must retain the full audit trail of AI recommendations: when they were issued, what input data informed them, what human action was taken, and why. This requires a data model and logging infrastructure purpose-built for traceability. An engineer who follows an AI-generated work-scope recommendation that later leads to an unscheduled shop visit must be able to prove that the system had disclosed its confidence bounds, the applicable ODD boundaries, and that the engineer had reviewed and understood them before acting. This audit trail becomes critical during accident investigations, regulatory audits, and liability assessments.

2. Human Factors and Meaningful Human Oversight in Decision Support

AI systems must be designed to support human technicians and planners, not to create a 'black box' where users blindly follow algorithmic recommendations because they lack the information or authority to question them.

In practice, this reshapes MRO software user experience. Confidence intervals, uncertainty bounds, and decision rationale must be surfaced alongside recommendations, not hidden in back-end logs. A system recommending a particular action should explain the confidence level, cite the data on which it was trained. A work-scope optimizer that recommends deferring a service bulletin should explain the cost trade-off and the residual risk. The software must enable humans to understand and contest the AI's reasoning, which means the AI model itself must be interpretable or paired with a decision-explanation layer.

3. Data Governance and Model Training Documentation

AI systems deployed in MRO must maintain an auditable record of the data used to train, validate, and continuously update the underlying models, including any known biases, data quality issues, or distributions where model performance has not been validated.

An engine fault-prediction model trained exclusively on a major carrier's fleet data may not generalize to smaller airlines, regional operators, or mixed configurations. A component inventory-optimization algorithm trained on stable supply-chain patterns will perform poorly in the current volatility. The EASA framework requires MRO Software vendors to document these data lineages and limitations explicitly.

For MRO software, this creates two design imperatives. First, systems must capture and version the training datasets, model parameters, and validation results in a way that can be audited by regulators or certification authorities. Second, MRO operators must understand what data their AI system relies on and have mechanisms to flag or exclude data that is no longer representative of their fleet, configuration, or operating environment. This is especially critical for continuous-learning systems that retrain models on incoming operational data.

4. Explainability and Regulatory Transparency

MRO software vendors and operators must be able to articulate to regulators how AI-generated recommendations reached their conclusions. When a system recommends a component replacement or delays a shop visit, can a technician or compliance officer understand why? EASA's framework does not forbid complex models, but it does require that the system, or the supporting documentation, explain the decision path in terms relevant to maintenance operations. However, it requires intentional design and testing.

The implication for software design is significant. Models must be chosen and tuned not only for accuracy but also for interpretability. A slightly less accurate but fully explainable model may be preferable to a higher-accuracy black box if the application is high-risk and operates in a regulated environment.

5. Continuous Monitoring and Model Drift Detection

MRO software systems must monitor AI model performance in production and detect when real-world data drifts from the training distribution or when model accuracy degrades below accepted thresholds. Systems must alert operators and trigger revalidation.

A model may perform excellently in its initial validation testing, only to degrade over months as the underlying data distribution shifts. For MRO, this drift can arise from fleet configuration changes, introduction of new engine variants, changes in operator maintenance practices, or undetected shifts in component quality or supplier configuration. EASA's framework requires that MRO systems include built-in safeguards: performance monitoring, statistical tests for data drift, and alerting mechanisms that flag degradation before it cascades into poor maintenance decisions.

Technically, this means MRO software must capture metrics on how often AI recommendations align with actual outcomes, compare the distribution of incoming data to the training distribution, and maintain fallback strategies when models degrade. A predictive maintenance system might fall back to rule-based alerts. A scheduling optimizer might revert to human planning. The system must remain safe and compliant even when its AI components are not in use or are operating in a degraded mode.

The economic pressure to automate maintenance decisions is real, and it is tempting to deploy AI systems that require minimal human intervention. MRO Software providers and operators must accept that human oversight is not an inefficiency to be engineered away; it is a safety requirement to be engineered into the system from the start.

6. Continuous Risk Assessment

AI systems in MRO must be designed with means for in-service monitoring and recording to support continuous risk assessment, including metrics, thresholds, and corrective action triggers.

Continuous risk assessment requires rigorous in-service monitoring. MRO systems must record the following data to support ongoing assessment: (1) inputs to the AI system: verify they remain within the ODD; (2) AI outputs: confidence scores, recommendations, predicted outcomes; (3) human actions: which recommendations were accepted, which rejected, and why; (4) actual outcomes: did the component fail as predicted? This data feeds continuous monitoring loops. Specific metrics and thresholds must be defined in advance.

Regulatory approval of AI-enabled MRO systems is not a one-time event. It is a continuous governance challenge. The MRO Software provider must commit to ongoing monitoring, the operator must commit to active oversight, and the regulator must commit to periodic review as the system learns from new data and the operating environment shifts.

Conclusion:

The Path Forward: EASA's AI Framework as a Competitive Advantage

MRO software vendors and operators that embrace EASA's AI trustworthiness framework early will gain a structural advantage. Systems designed from the outset to classify AI levels, define operational design domains, maintain assurance documentation, and manage continuous risk assessment will be easier to certify, more resilient in production, and ultimately more trusted by operators and regulators. The framework is not a constraint on innovation; it is a foundation for responsible, deployable innovation.