AI in aerospace is mostly a document story today. For manufacturers, suppliers and MRO organisations, language models and agents help engineers search requirements and draft certification evidence under DO-178C and DO-254, help technicians use maintenance manuals, work cards and defect history, and help quality teams with AS9100 and AS9145 records, non-conformance reports and FOD investigations. The constraint is control of the data: ITAR and EAR technical data, controlled unclassified information under CMMC and NIST SP 800-171, and certification records all push this work onto infrastructure the company runs itself.
AI in the aerospace and defense industry: where the work is
Aerospace runs on controlled documents. A single aircraft program carries requirements, design data, safety assessments, certification plans, test reports, configuration records, supplier quality packages and, once in service, maintenance data and records for decades. Engineers and technicians spend much of their time finding the right revision and writing evidence that someone else will audit.
| Area | Document work that suits language models and agents | Work that stays with other tools and people |
|---|---|---|
| Engineering and certification | Requirement search, trace gap reports, first drafts of compliance evidence | Design, analysis, verification, certification authority decisions |
| Manufacturing quality | Non-conformance report drafts, past disposition search, AS9145 package checks | Inspection, measurement, material review board decisions |
| MRO | Manual and service bulletin search, work card drafts, defect history summaries | Inspection, repair, release to service |
| Supply chain | Supplier quality clause review, flow-down checks, certificate of conformity checks | Supplier approval and audits |
| Proposals and contracts | Compliance matrices, past performance search, clause comparison | Pricing, legal review, signature |
The sections below go through each area, then the export control and cybersecurity rules that decide where the models may run. Those rules are what separate AI for aerospace and defense from AI in most other manufacturing sectors: the same engineering drawing can be a quality record, a certification artefact and export-controlled technical data at once.
Engineering and certification documentation
DO-178C, DO-254 and the evidence they demand
Airborne software and complex electronic hardware are developed against RTCA DO-178C and DO-254, which the FAA recognises through advisory circulars AC 20-115D and AC 20-152. Both standards expect planned processes, traceability from requirements to code or hardware design and tests, reviews, and a large body of life cycle data that the applicant shows to the certification authority.
AI in aerospace engineering helps most with the bookkeeping around that evidence:
- Trace gap reports. Read requirement, design and test exports and list requirements with no test or tests with no parent requirement, for the engineer to confirm.
- First drafts of review records and summaries. Draft a software accomplishment summary section or a review checklist from the project’s own data, with each statement linked to its source.
- Requirement quality checks. Flag ambiguous, compound or untestable requirements against the project’s writing rules before a formal review.
Human authority and tool qualification
The person who signs the evidence remains responsible for it. There is also a technical trap to avoid: AC 20-115D recognises DO-330, the tool qualification document. If a project lets an AI tool’s output replace a verification activity, rather than having an engineer check that output, the tool may need qualification, which is impractical for a general language model. The safe pattern is assistance: the model drafts and points to sources, and the engineer performs and records the verification.
What the FAA and EASA roadmaps say
The FAA’s Roadmap for Artificial Intelligence Safety Assurance, Version I, signed in July 2024, sets guiding principles. Two matter directly for document assistants. “Avoid personification” asks the industry to treat AI as an algorithm or computer, not as a human, because blurring that line obscures who is responsible. “Differentiate between learned and learning AI” separates models that are fixed in operation from models that keep learning, which need a different safety argument. The roadmap also recommends an incremental approach that starts with lower-risk applications.
EASA’s Artificial Intelligence Roadmap 2.0 is dated 10 May 2023 and described as a living document. On 10 November 2025 EASA published NPA 2025-07, its first regulatory proposal on AI, giving guidance on AI trustworthiness for high-risk systems under the EU AI Act and covering AI-based assistance and human-AI teaming. EASA said a second proposal would apply the framework to each aviation domain’s rules, and it released a further issue of its AI concept paper for comment in June 2026. The EU’s Digital Omnibus on AI, in force since 27 July 2026, also amended the EASA Basic Regulation so that future delegated and implementing acts on AI safety components must take the AI Act’s high-risk requirements into account.
Neither roadmap is aimed at office assistants that draft documents, but their principles carry over: keep the human accountable, log what the tool did and start with low-risk uses.
AI in aerospace manufacturing: quality, non-conformance and FOD
AS9100D is the quality management standard most aerospace manufacturers are certified to. The IAQG is preparing its next revision, which, according to a NASA safety and mission assurance notice, will be renumbered IA9100 under the group’s new document prefix. Alongside it sit standards such as AS9145, issued in November 2016, which sets requirements for advanced product quality planning and the production part approval process, and AS9146, issued in 2017, which sets requirements for a foreign object damage prevention program.
Language models help in three places:
- Non-conformance reports. Draft the report from the inspector’s findings and photos, search past dispositions of similar defects on the same part family, and propose wording for the material review board. The board decides use-as-is, rework, repair or scrap.
- AS9145 packages. Check a supplier’s APQP and PPAP deliverables against the customer’s requirements and the previous submission, and list what is missing or inconsistent.
- FOD investigations. Group FOD incident reports by area, shift and object type, and draft the investigation summary and corrective action record for the FOD focal point to review.
The same pattern applies to AI in aircraft manufacturing at every tier, from airframe assembly lines to machine shops making single brackets, since every part number carries its own inspection and approval records. The manufacturing AI use case hub collects the related workflows. The quality and defect analysis use case shows how an agent cites every inspection record and past disposition it used, and the use case on searching engineering and R&D archives covers search across design and test archives with per-program access.
MRO: maintenance manuals, work cards and defect history
Maintenance organisations work from manufacturers’ maintenance manuals, illustrated parts catalogues, service bulletins, airworthiness directives and their own task cards, and they produce records that regulators inspect.
In the United States, a repair station certificated under 14 CFR Part 145 must keep a quality control manual under 145.211, which covers keeping technical data current, and must retain records demonstrating compliance with Part 43 for at least two years under 145.219. Under 43.9, each maintenance record entry carries a description of the work, the completion date and, for satisfactory work, the signature, certificate number and kind of certificate of the person approving it. In Europe, Part-145 is Annex II to Regulation (EU) No 1321/2014; amendments made by Regulation (EU) 2021/1963 applied from 2 December 2022 and required maintenance organisations to implement a safety management system.
Within those rules, AI helps with:
- Manual and bulletin search. A technician asks a question and gets the answer with the manual reference, restricted to the revision the organisation has incorporated.
- Work card drafts. An agent drafts a task card from the manual task and the operator’s requirements, for the planning engineer to check and release.
- Defect history and repeat faults. Summarise a tail number’s defect history, find repeat write-ups across the fleet and draft the reliability report narrative.
- Shift handovers. Turn open work, deferred defects and parts status into a structured handover note.
Signing for work and releasing an aircraft or component to service remain the job of certifying staff. A model never signs a record.
Supply chain documents, proposals and contracts
Aerospace purchase orders carry long lists of quality clauses and flow-down requirements, from source inspection and first article inspection to counterfeit parts prevention, export control markings and cybersecurity clauses for defense work. Suppliers must check each order, and primes must check that suppliers have flowed requirements down further. A retrieval assistant answers “which open orders require first article inspection to the latest revision” across the order book, and an agent can compare a supplier’s quality manual against the clause set.
Proposal teams reuse past performance narratives, technical approaches and compliance matrices. An assistant can build a first compliance matrix from a solicitation, find the best past write-up for each requirement and flag clauses that differ from the company’s standard positions. Pricing, legal review and signature stay with the people accountable for them. The defense document classification playbook shows how documents can be labelled before they enter such a corpus, so that controlled material only reaches people and models cleared for it.
Export control: ITAR and EAR technical data
Much aerospace engineering data is export-controlled. Under 22 CFR 120.33, ITAR technical data covers information required to design, develop, produce, operate, repair, test, maintain or modify defense articles, including drawings, plans, instructions and documentation. A release includes using access information to enable a foreign person to access, view or possess unencrypted technical data, under 22 CFR 120.56, and releasing technical data to a foreign person inside the United States is itself an export, a deemed export under 120.50.
Both export regimes carve out encrypted data in limited circumstances. The EAR rule published in June 2016 and effective on 1 September 2016 added 15 CFR 734.18(a)(5): sending, taking or storing unclassified technology or software secured with end-to-end encryption and FIPS 140-2 compliant cryptography, and not intentionally stored in a Country Group D:5 country, is not an export. The EAR defines end-to-end encryption as protection where the data is never unencrypted between originator and recipient and the means of decryption are not given to any third party. The ITAR followed with an interim final rule effective on 25 March 2020, now 22 CFR 120.54(a)(5), with similar conditions and a bar on sending data to or storing it in a country proscribed in 126.1.
State this carefully to internal stakeholders: those carve-outs cover storage and transmission. A hosted language model has to decrypt the text to process it, and whoever operates the model environment could then have access. Unless the provider’s environment is restricted to U.S. persons and the design has been reviewed by export compliance, inference on ITAR technical data in a general cloud service is hard to defend. Keeping the model on servers the company controls, inside the boundary it already manages for export compliance, avoids most of the question.
Export rules also move. In August 2026 the State Department amended the ITAR, effective 13 October 2026, to remove from the U.S. Munitions List certain civil aircraft modified to incorporate aircraft survivability equipment. Classification decisions remain with the export compliance team, not with a model.
CMMC and NIST SP 800-171 for defense suppliers
Defense suppliers that handle controlled unclassified information must protect it under DFARS 252.204-7012 and NIST SP 800-171, and demonstrate that through the Cybersecurity Maturity Model Certification program, often still called CMMC 2.0. The program rule, 32 CFR Part 170, took effect on 16 December 2024. The DFARS acquisition rule took effect on 10 November 2025, starting Phase 1, in which contracts can require Level 1 or Level 2 self-assessments.
On 13 July 2026 the Department of War suspended Phase 2, the move to third-party Level 2 assessments planned for 10 November 2026, and held later milestones in abeyance while a task force reviewed the program. As of 25 October 2026 no new Phase 2 date had been published, and the underlying obligations, including DFARS 252.204-7012 and the NIST SP 800-171 Revision 2 requirements, continued to apply. NIST published Revision 3 in May 2024, but CMMC assessments still reference Revision 2.
Any AI tool that receives CUI falls inside the assessed boundary and belongs in the system security plan. For a detailed comparison of ChatGPT, Microsoft Copilot in government clouds and self-hosted models against these rules, see our analysis of AI tools for defense contractors handling CUI under CMMC.
A governed architecture for aerospace companies
| Layer | What sits there | AI design rule |
|---|---|---|
| Classified and air-gapped programs | Isolated networks | Separate deployment with offline model transfer, or no AI |
| CUI and export-controlled enclave | Engineering data, technical publications, defense contracts | Local models only, U.S.-person administration where required, full audit |
| Corporate environment | Quality system, MRO records, supplier documents, proposals | Local models by default; approved external models only for public data |
| Engineering and MRO systems | PLM, requirements tools, MRO software, document control | Read access first; write-back after approval |
The guide to air-gapped AI deployments covers how to move models and updates into isolated networks.
How VDF AI fits aerospace manufacturers, suppliers and MROs
VDF AI runs on infrastructure an aerospace company already controls: inside a CUI enclave, in a corporate data centre, in a private cloud or on an air-gapped program network. Set to local models only, it keeps prompts, technical data, retrieval indexes, chat history and audit logs within that boundary, so export-controlled and CUI material stays inside the environment the company has already scoped for ITAR, EAR and CMMC. VDF AI has no FedRAMP authorisation, CMMC certification or export licence of its own; it is one more application inside the customer’s assessed boundary and export compliance program.
The document work in this guide becomes governed agents and multi-agent workflows. A non-conformance agent drafts the report and stops at an approval step for the quality engineer; an MRO agent drafts the work card and waits for the planning engineer. Each role receives only the tools it needs, retrieval enforces per-collection access so that one program’s data stays with that program’s team, and the audit trail records who asked, which model answered, which sources it drew on and which tools it called. VDF AI Router registers local open-weight models behind Ollama, vLLM or other OpenAI-compatible endpoints; approved cloud models can be added under policy for public work, with routing, budgets and per-call audit, or left out entirely.
Identity on-premises uses Microsoft Entra ID single sign-on natively, with Okta, Keycloak and other SAML or OIDC providers connecting through an SSO-aware reverse proxy, and role-based access control is standard on every plan. Seat bundles can each start with a three-month platform trial, which suits a pilot on one MRO line or one engineering program.
Related reading: the private AI page for government and defense teams and the manufacturing solution. Before choosing a first program, score data, infrastructure and governance readiness with the free AI readiness assessment.
This overview of export control and certification rules is for planning and is not legal or export compliance advice.
Sources
Verified 25 October 2026.
- FAA, Software and Airborne Electronic Hardware guidance (AC 20-115D, AC 20-152)
- FAA AC 20-115D, Airborne Software Development Assurance (PDF)
- FAA, Roadmap for Artificial Intelligence Safety Assurance, Version I (PDF)
- EASA, Artificial Intelligence domain page and AI Roadmap 2.0
- EASA, first regulatory proposal on AI for aviation, NPA 2025-07 (10 November 2025)
- Digital Omnibus on AI, Regulation (EU) 2026/1744, Official Journal text
- NASA SMA, status of the development of IA9100 (April 2024)
- SAE AS9145, APQP and PPAP requirements
- SAE AS9146, FOD prevention program requirements
- 14 CFR 145.211, quality control system
- 14 CFR 145.219, recordkeeping
- 14 CFR 43.9, maintenance record entries
- EASA guide for compliance with Part-145 as amended by Regulation (EU) 2021/1963
- 22 CFR 120.54, activities that are not exports
- 22 CFR 120.56, release
- 15 CFR 734.18, activities that are not exports under the EAR
- BIS final rule, Revisions to Definitions in the EAR, 81 FR 35586 (June 2016)
- State Department interim final rule creating 22 CFR 120.54 (December 2019, effective March 2020)
- ITAR amendment on civil aircraft with aircraft survivability equipment (August 2026)
- CMMC program rule, 32 CFR Part 170 (effective 16 December 2024)
- DFARS Case 2019-D041 final rule (effective 10 November 2025)
- Department of War release suspending CMMC Phase II (13 July 2026)
- NIST SP 800-171 Revision 3 (May 2024)