How to Certify AI for Aviation: A Step-by-Step Guide

AI is moving into flight decks, air traffic management systems, and predictive maintenance platforms. Aviation is one of the most regulated industries in the world.

Before any AI system goes operational, it must meet strict safety standards. Understanding what those standards require, and how the certification process works, is essential for any team building or buying aviation AI.

The range of AI solutions for aviation spans decision-support tools, predictive analytics, and autonomous systems. Where a system sits on that spectrum determines how rigorously it must be certified.

This guide breaks the process down step by step, from initial scoping through final regulatory approval.

What aviation AI certification actually means

Certification in aviation means a system has been formally shown to meet defined safety requirements. It is not a single test or a vendor checklist.

It is a structured process, overseen by civil aviation authorities, that produces documented evidence of safety compliance. Applicable standards depend on where the AI operates within the aircraft or air traffic system.

For software, the primary standard is DO-178C (Software Considerations in Airborne Systems and Equipment Certification). For hardware, it is DO-254. Both are published by RTCA and adopted by the FAA and most international regulators.

Certification is not a post-development activity. It must be planned and designed into the system from the first line of architecture.

When certification is required vs. advisory

Not every AI system in aviation requires full certification. The distinction matters.

Certification is required when:

• The system affects flight safety, navigation, or flight control
• Output from the AI influences pilot decisions in real time
• The system is part of certified avionics architecture

Certification may be advisory when:

• The AI is used only for ground operations or back-office analytics
• The system is a decision-support tool with no direct operational role
• The AI runs entirely offline and does not feed into certified systems

Understanding this boundary early prevents wasted effort and misaligned expectations with regulators.

The applicable standards at a glance

The FAA and EASA regulations that govern AI go beyond these documents, but these standards form the technical backbone of most certification plans.

The stages of a certification process

Stage 1: Determine the Design Assurance Level (DAL)

The first step is identifying the system’s DAL under DO-178C. There are five levels (A through E), based on the severity of a failure.

• DAL A: Catastrophic failure condition. Highest rigor required.
• DAL B: Hazardous failure. Significant documentation and testing required.
• DAL C: Major failure. Moderate assurance requirements.
• DAL D: Minor failure. Low assurance requirements.
• DAL E: No safety effect. Minimal requirements.

Most AI systems involved in flight-critical operations are DAL B or DAL A. Support tools may qualify for DAL C or D.

Stage 2: Define the certification basis

The certification basis is the set of requirements the system must satisfy. This is agreed upon with the certifying authority, usually the FAA in the US or EASA in Europe.

It typically includes applicable airworthiness regulations, any special conditions for novel technology, and agreed means of compliance.

For AI, this is where things get complex. Traditional DO-178C assumes deterministic software. Machine learning models are probabilistic. Regulators are still developing specific guidance to address this gap.

Stage 3: Build the Plan for Software Aspects of Certification (PSAC)

The PSAC is a foundational document. It describes:

• The software architecture
• The development environment
• Verification and validation methods
• How compliance will be demonstrated

It must be submitted to and accepted by the certifying authority before development proceeds in earnest.

Stage 4: Develop with traceability

Every requirement must trace through to design, code, test case, and test result. This traceability matrix is one of the most labor-intensive parts of certification.

For AI systems, this means documenting not just the model architecture but also the training data, preprocessing steps, model evaluation methodology, and post-deployment monitoring plan.

Domain-specific models built for aviation carry an advantage here. They are designed with traceability in mind from the start, rather than adapted from general-purpose tools.

Stage 5: Conduct verification and validation (V&V)

V&V includes:

• Reviews: Checking that requirements are complete and correct
• Analysis: Evaluating the design against requirements
• Testing: Demonstrating that the software performs as required under normal and abnormal conditions

For AI, testing must cover edge cases, out-of-distribution inputs, and adversarial conditions. Coverage metrics used in traditional software testing may need to be adapted or supplemented for probabilistic systems.

Stage 6: Produce and submit compliance artifacts

The final submission to the certifying authority includes a complete artifact package. This typically contains:

1. Software Accomplishment Summary (SAS)
2. Software Configuration Index (SCI)
3. Problem Reports (open and closed)
4. Traceability matrix
5. Test results and analysis reports
6. Tool Qualification Data Package (if applicable)

Regulators will review these artifacts in detail. Gaps or inconsistencies in documentation are the single most common cause of certification delays.

Stage 7: Participate in the certification review

The certifying authority may conduct a formal review, examining artifacts, asking questions, and requesting additional evidence. This stage can take weeks to months depending on system complexity and regulatory workload.

Being responsive, organized, and consistent in this phase is critical.

Documentation: what you actually need to produce

Certification documentation is extensive. Below is a representative list for a DO-178C DAL B system.

Planning documents:

• Plan for Software Aspects of Certification (PSAC)
• Software Development Plan (SDP)
• Software Verification Plan (SVP)
• Software Configuration Management Plan (SCMP)
• Software Quality Assurance Plan (SQAP)

Development documents:

• Software Requirements Data (SRD)
• Software Design Description (SDD)
• Source code

Verification documents:

• Software Verification Cases and Procedures (SVCP)
• Software Verification Results (SVR)
• Traceability matrices (requirements to design to test)

Lifecycle data:

• Software Accomplishment Summary (SAS)
• Software Configuration Index (SCI)
• Problem Reports

For AI-specific additions, expect to also document model selection rationale, dataset curation methodology, training and retraining procedures, and operational performance envelopes.

How to work with regulators effectively

Regulatory relationships in aviation certification are not adversarial. Authorities want safe systems. Approaching them as partners rather than obstacles produces better outcomes.

Practical guidance:

• Engage early. Request a pre-application meeting before finalizing the PSAC.
• Be transparent about where the AI deviates from traditional deterministic software assumptions.
• Propose means of compliance rather than waiting for regulators to specify them.
• Respond to questions promptly and completely. Partial answers create uncertainty and delay.
• Document every interaction. Verbal agreements are not sufficient.

“The authority’s job is to approve systems that are safe. Your job is to show them the system is safe. Treat the process as a collaborative technical exercise.”

Regulators are also learning. AI presents genuinely new challenges for their frameworks. Teams that bring well-reasoned proposals often shape the guidance that follows.

Common bottlenecks and how to avoid them

Most certification delays trace back to predictable problems.

1. Scope creep after the PSAC is agreed. Changes to requirements or architecture mid-development can invalidate large portions of existing documentation. Lock scope before production begins.

2. Insufficient traceability infrastructure. Teams that rely on spreadsheets often hit walls when audited. Use purpose-built requirements management tools from the start.

3. Testing gaps on edge cases. Aviation AI operates in high-variance environments. Test plans must include failure modes and abnormal inputs, not just nominal performance scenarios.

4. Tool qualification delays. Any tool that produces outputs used in certification artifacts may require formal qualification under DO-330. Identify these tools early and plan accordingly.

5. Underestimating documentation burden. The paperwork for a DAL B system can run to hundreds of documents. Budget time and staff accordingly before the first line of code is written.

What to look for in an AI vendor

Choosing a vendor whose system is certifiable is as important as the technical performance of the model itself.

Ask every prospective vendor these questions:

• Has your system been certified under DO-178C or equivalent? At what DAL level?
• Can you provide a complete artifact package from a prior certification engagement?
• How do you handle traceability from training data through to deployment?
• What is your process for model updates and retraining within a certified architecture?
• Who on your team has direct experience working with FAA or EASA?

A qualified AI consulting partner can help evaluate vendor claims and validate whether a proposed architecture is actually certifiable before a contract is signed.

Avoid vendors who treat certification as a box to check after the system is built. Certifiability must be designed in from the beginning.

The path forward for aviation AI certification

Certification frameworks are still catching up to AI. EASA’s AI Roadmap and the FAA’s AI in Aviation framework are both active and evolving.

Teams certifying AI systems today are, in many cases, working alongside regulators to establish precedent. That is a challenge. It is also an opportunity.

Organizations that invest in getting this right early will hold a significant advantage as the standards mature and as AI becomes a prerequisite for competitive aviation operations.

Build your aviation AI certification process from the ground up

Certifying an AI system for aviation is one of the most demanding technical and regulatory undertakings in the industry. The foundations you set now determine how smoothly the entire process runs.

AI certification in aviation is not fundamentally different from software certification; it requires evidence, traceability, and a documented process for handling errors.

Path one: identify your AI system’s decision role before starting certification planning. Determine whether the AI output directly influences an airworthiness or safety-critical decision. If yes, the certification scope and documentation requirements are substantially higher. Start with that classification before investing in any certification pathway.

Path two: bring in a partner. Phos AI Labs designs AI implementations for aviation organisations; aviation AI certification pathway design, compliance integration, and the private AI environment your team will actually use. We have run 400+ AI engagements. Clients include Zapier, Coca-Cola, Medtronic, Dataiku, and American Express. Thirty minutes, no deck. Start here.