AI Is Coming to Your DO-178C Program. Can You Show an Auditor What It Did?
Tool vendors are shipping AI that drafts requirements, tests and code for certified software. The rules for using it already exist. What's missing is the record that shows an AI-assisted change stayed inside what a person approved. Here's what that record needs, how to bring your team and your certification authority along, and where to start.
First published: 2026-10-31. Research current as of 2026-10-31.
The short answer
You can say yes to AI on a DO-178C program today, by putting it in the plans your certification authority already reviews. Three things make it defensible:
- AI output is verified like anyone else's work. Reviews, requirements-based tests and coverage analysis still earn the credit. That's ordinary DO-178C discipline.
- Every AI-made change stays inside a scope a person approved. The agent works from a plan, and anything outside the plan is blocked.
- Quality assurance can show it. The program keeps a record that lets QA confirm what was approved, what the AI did, and what it tried and was refused.
Most teams can do the first today. The second and third are the missing layer, and they're buildable now.
The decision in front of you
The tools are arriving whether a program plans for them or not. From a survey of vendor and regulator publications (AI-assisted, with every claim checked against its source), here's what is shipping or piloting:
- Vector's VectorCAST 2026 generates tests from requirements with an LLM (Reqs2x). Vector's own page says the AI output goes through the same review as hand-written tests.
- MathWorks R2026a added Copilots to Simulink and Polyspace.
- Ketryx offers AI agents that work across requirements, traceability and verification evidence, and supplies tool-qualification documentation for its platform. Visure has announced a server that lets AI agents work on that data.
- Startups such as Xcert AI are piloting AI that links requirements, standards and evidence.
I found no OEM or Tier-1 saying publicly that it uses generative AI on a certified program. Some may be using it internally; none has said so. On the vendor pages I read, none claims DO-330 tool qualification for an AI feature. And in the sources I could reach, I found no FAA or EASA guidance specific to AI used as a development tool.
The regulators are busy, but with a different problem. EASA's AI Concept Paper, its first AI rulemaking proposal (NPA 2025-07), and the SAE G-34 / EUROCAE WG-114 standard ARP6983 / ED-324 (now targeting December 31, 2026) are about machine learning in aviation products and operations. AI that helps your engineers build a conventional product falls under rules you already follow.
So the choice isn't whether to wait for guidance. It's whether AI enters your program with a plan and a record, or without one.
Where certification credit comes from
DO-178C has always been clear about this. Credit comes from verification: reviews, analyses, requirements-based tests, structural coverage analysis. A tool's output earns credit only if someone verifies it, or if the tool itself is qualified.
That makes the first rule for AI simple. Treat what it produces as unverified input, and verify it the way you'd verify a person's work. That's how Vector frames Reqs2x, and it's the right call.
The gap: showing the process held
Your compliance evidence stays what it's always been: change requests, reviews, baselines, and quality assurance audits done by people. An AI agent doesn't change that. It changes how hard those records are to stand behind.
An AI agent can touch twenty files in a minute. It can edit a test to match the code instead of the requirement. It can run a command nobody asked for. The reviewer then sees a clean final diff, with no view of what else happened along the way. Three parts of DO-178C feel that directly:
- Configuration management (Section 7). Every change has to trace to an approved problem report or change request. An agent that edits outside that scope has breached change control, even if the final diff looks clean.
- Quality assurance (Section 8). If your PSAC says AI is used only for certain work, QA needs a way to show it was used only for that work.
- Independence. At DAL A and B, some verification has to be done independently. If one agent writes both the code and its tests, that independence is in question, whoever reviews afterward.
Four questions follow for any AI-assisted change:
- What was the agent allowed to change, and who approved that?
- Did it stay inside that scope, including the attempts that failed?
- Did any test get bent to fit the code?
- Can quality assurance show all of this without taking anyone's word for it?
Reviewing the final diff answers part of the third question at best. The control layer below doesn't replace QA's own checks. It makes them targeted and believable.
What good looks like
The control layer needs to do these things, with rigor scaled to the software level:
- Scope before action. The agent works from a plan listing the files and commands it may use. Anything else is blocked, not just warned about.
- Approval of the exact plan. A person approves the plan, and editing it voids the approval.
- Independence where the level needs it. Mirroring DO-178C's independence objectives, at DAL A and B the approver isn't the author, and identity is authenticated.
- A record of everything. Every allowed and blocked action goes into a log, anchored somewhere the agent's machine can't rewrite. A log of only the refusals can't tell a working control from a switched-off one.
- Traceability. Each change points to its plan, the plan points to the problem report and requirements it serves, and the files a commit touches match the plan.
- Honest tests. A change to an existing test that rides along with a code change should be flagged and need a reason a person accepts.
- A data boundary. Export-controlled and proprietary data never reach a model or a repository they aren't cleared for.
- One setting for the level. DAL A runs every control with no unsupervised bypass. DAL D runs a lighter set.
Where to start
No program needs to do all of this at once. A sensible order:
- Ground rules. Decide where AI may run, given your export-control and proprietary data (on-premises or an approved enclave). Describe how AI will be used in the plans the authority reads: the PSAC and the development and verification plans. Assess each AI tool against DO-178C's tool-qualification criteria. Put process controls on every repository an agent can touch. And agree the approach with your certification authority early, at the PSAC review, before any AI output reaches a baseline.
- Low-risk help first. Requirements quality checks, review assistance, document drafts, test-plan drafts, triage of static-analysis results. The AI suggests; people decide; nothing it produces counts as evidence until someone verifies it.
- Verification help with a check behind it. Drafting requirements-based tests, and proposing an analysis for each structural coverage gap (missing requirement, dead code or deactivated code), always confirmed by a deterministic tool and an independent reviewer.
- Only then, if it pays off, qualify a narrow tool so the program can take credit for it. See the box below.
Pilot on one DAL C or D component with a willing team. Measure what you already track: review findings per change, rework, problem-report closure time, audit findings. Decide on expanding from that data, not from a vendor demo.
Steps 1 to 3 need no new regulation. They need a plan, controls, a record, and the authority in the loop.
Bringing the team with you
The controls are the easy part. The harder part is people.
- Engineers keep authorship. The person who commits a change owns it, whoever drafted it.
- QA owns the record from day one. They help design the audit trail rather than inherit it.
- Reviewers learn what AI gets wrong: tests bent to fit, plausible code with no requirement behind it, confident answers about coverage that don't hold up.
- The authority hears it first in the PSAC, not at the first Stage of Involvement audit.
One way to build the controls: StrictLock
StrictLock is my open-source reference implementation of these controls. The pattern matters more than the tool, and a program can build it on whatever its IT and export-control rules allow. It came out of running AI agents on a HIPAA compliance product, where an unapproved action has real compliance consequences. It runs as a Claude Code hook today and can be adapted to other agent tools. It hasn't been used on a certified program yet.
Here's what it gives QA, in audit terms:
| What an auditor asks | What StrictLock provides |
|---|---|
| What was the agent allowed to do? | A plan file listing the exact files and commands. Every file write and every command that isn't read-only is checked against it, and anything else is blocked once the gate is set to fail closed. It's paired with the operating system's sandbox, since the gate rules on the command, not on everything an approved command then does. |
| Who approved it? | With the decision log on, an approval tied to the plan's exact contents; change the plan and the approval is void. Approval is designed as a human step, and the gate blocks the direct ways an agent could approve, on a best-effort basis. |
| What did it do, and try? | With the decision log on, every allowed and blocked action in a hash-chained log, within the limits below. |
| Which change belongs to which plan? | Every functional commit must name a plan (optionally checked to exist), and an included CI job can repeat the check so it can't be skipped locally. |
| Were tests bent to fit? | Changes to existing test assertions made alongside code changes are flagged for review. |
| Could two agents collide? | One agent per file set, for agents sharing a repository on one machine. |
| Did secrets leak into commits? | Keys, tokens and machine paths blocked at commit and push. |
It isn't a qualified tool, it doesn't check whether code is correct, and it earns no certification credit on its own. Its limits, which its own docs state:
- The log is tamper-evident, not tamper-proof. The hash chain exposes casual or accidental edits, but someone with write access to the machine can cut the newest rows or rebuild the whole chain and it still verifies. Proving the record is intact takes an anchor off the machine.
- It records authorization, not a replay. Fields are length-capped, and prompts and tool outputs aren't captured.
- Identity is declared, not authenticated.
- There's an emergency bypass, so a broken gate can't lock its operators out. It's set in the harness settings, not the agent's shell, and it's logged when the decision log is on.
For a DAL A program, the next builds would close those gaps: an off-machine log anchor, authenticated approvers checked against authors, requirement and problem-report IDs in plans and commits, a check that each commit's files are inside its plan, the model and version recorded per change, and one DAL setting that removes the unsupervised bypass.
How I read the tool-qualification rules (your DER makes the call)
DO-178C §12.2.2 sorts tools by what their failure could do:
- Criteria 1: the output is part of the airborne software. An AI that writes flight code is a Criteria 1 tool; it needs no qualification only if its output is verified as if a person wrote it.
- Criteria 2: the tool automates verification, and its output is used to justify reducing other verification or development processes.
- Criteria 3: the tool automates verification and could miss an error, but nothing beyond its own job is reduced on its strength.
DO-330 sets the Tool Qualification Level from the criteria and the software level (DO-178C Table 12-1): TQL-1 for Criteria 1 at DAL A, TQL-4 for Criteria 2 at DAL A and B, TQL-5 for Criteria 3 at any level.
Process controls like these can be used two ways:
- As a safety net. Every change still gets full independent review; the controls add scope enforcement and an audit trail on top. A reasonable argument is that they eliminate, reduce or automate no DO-178C process, so they need no qualification. The argument holds best when quality assurance checks commits against plans itself and uses the log to aim those checks, not as proof.
- For credit. If a program drops a manual check because a gate enforces it, such as confirming each change stayed in scope, the gate is automating a check whose output isn't independently verified. Replacing that check alone most likely makes it Criteria 3, TQL-5. If its output were used to cut a different activity, say part of code review, it becomes Criteria 2: TQL-4 at DAL A and B.
Deterministic gates are realistic qualification candidates in a way AI isn't: one narrow job and fixed behavior, provided the host tool's version is pinned and the gate's operational requirements are written and tested against. Don't try to qualify the model. If you want credit, qualify the fence around it.
Why I care about this one
I've spent 25 years in software, 21 in regulated industries and 15 in avionics at Rockwell Collins and Collins Aerospace. On the AIM / IMS-3500 program I wrote one of Rockwell Collins' first Lean Software Development Plans, bringing Agile and test-driven practice into DO-178B work. As lead project engineer I built the delivery plan together with Rockwell Collins' FAA representatives and kept them and the team in step, and a phase estimated at 24 months went onto a customer's aircraft in 18. Later, on DAL B flight management software at Collins Aerospace, I helped turn a struggling team into one closing 2.5 times the problem reports of peer teams on the same backlog, and supported Stage of Involvement audits. Along the way I classified and handled export-controlled technical data under ITAR and EAR.
What I took from all of it is that certification is a partnership built on evidence. You make the process visible, you bring the authority in early, and the trust follows. AI doesn't change that. It raises the stakes on it.
What's next
This is the first piece in a series on bringing AI into the whole development-assurance stack: ARP4754B and ARP4761A at the system level, DO-178C for software, DO-254 for hardware, DO-160 for environmental qualification and AC 20-193 for multicore. Next: when an AI tool triggers DO-330, and what a tool-qualification assessment for one needs to cover.
If you're working out where AI fits your next PSAC, I'm glad to spend an hour with your software and certification leads on it: tim@tdmtechsolutions.com.