Can AI Draft Aviation Audit Findings Safely?

An auditor comes back from a site visit with a notebook like this:

"Tool control poor in stores."

"Training matrix not updated."

"Procedure not followed."

"CAP evidence missing."

Each line is a useful memory aid. None is ready to issue. They do not say what was checked, which procedure applied, which records were sampled, whether the issue was isolated or repeated, or what still needs confirmation.

Turning those notes into findings is slow, careful desk work, which is exactly why AI looks attractive here. It can help. But a finding is a formal record with consequences, and a tool that smooths language can just as easily inflate it. AI can draft aviation audit findings. It should not approve them, classify them alone, invent evidence or replace the auditor's judgement. Five guardrails keep it on the right side of that line.

A finding is a structured case, not a paragraph

A weak finding often reads as one confident sentence: a process was not followed, a record was missing, a requirement was not met. The structure behind it may be thin.

A finding someone else can act on carries these parts, each kept separate:

• the audit scope;
• the requirement or criterion, with its source;
• the objective evidence sampled;
• what was observed;
• the gap between requirement and evidence;
• any uncertainty still open;
• the finding statement;
• the classification, decided by the reviewer;
• the correction or corrective action request;
• the follow-up and verification needed.

If evidence and interpretation blend into one sentence, the finding is harder to defend. If the requirement is missing, the auditee cannot see the basis. If classification is guessed, the process becomes inconsistent. If the corrective action is written before the cause is understood, it treats the symptom.

A quality manager who was not on the audit should be able to read the finding and see why it was raised. The auditee should know what to answer. That is the standard the drafting has to meet, whoever does it.

Guardrail 1: source control

An AI assistant should not draft a finding against a requirement it cannot identify.

If the auditor supplies a regulation reference, an exposition paragraph or an internal procedure clause, the assistant can work with it. If the source is missing, it should say so and ask, not fill the gap. It should not invent a paragraph number, cite an AMC because it sounds close, or build a finding on general aviation language.

Authority matters too. A regulation, an AMC or GM passage, a company procedure, a customer requirement and an internal checklist are not interchangeable, and a long-standing local practice is not automatically a requirement. A professional tool should show the source type, quote the source text where it has it, show the amendment it used, and keep source text apart from its own explanation. That gives the auditor something to verify. The reasoning is set out in why aviation AI must cite approved sources.

The same boundary applies to records. Audit evidence, safety reports and proprietary procedures stay in the organisation's controlled systems unless the organisation has authorised something else.

A finding without a source is not ready for issue. At most it is a draft observation.

Guardrail 2: evidence separation

AI is very good at smoothing language, and that is the danger. Audit notes are rough because they reflect what was actually seen, sampled, missing or said. The assistant should make them clearer, never stronger than the evidence supports.

"Training record not available for sampled staff member A" is not the same as "training records are not controlled". The first is evidence from a sample. The second is a system conclusion. It may be true, but it needs more support.

A useful draft keeps apart:

• what was sampled;
• what was found;
• what was not found;
• what the auditor thinks it may mean;
• what still needs confirmation.

That protects the auditor from overstatement and the organisation from vague or inflated findings. The full method, with worked wording, is in objective evidence vs opinion in aviation findings.

Worked example: from shorthand to review-ready wording

Take the note "training matrix not updated". A weak finding might say:

Training records were not properly maintained.

It sounds formal but tells the reader almost nothing, and it may be broader than the evidence.

A review-ready draft is closer to this:

During the sample of five maintenance department training records, two personnel files contained course completion certificates that had not been reflected in the current training matrix. The applicable training control procedure requires completed recurrent training to be entered in the training matrix. This indicates a gap between completed training evidence and the record used to monitor training status. Auditor review is required to confirm the procedure reference and finding classification.

The second version is still a draft. It leaves the procedure reference and the classification with the reviewer. But it gives the reviewer something usable: the sample, the evidence, the requirement, the gap and the open decision.

The same applies to evidence phrasing in general. "Records were poor" is not evidence. "Three of eight sampled authorisation files did not include the required continuation training entry" is.

Guardrail 3: classification discipline

Classification is not a writing-style choice. It depends on the organisation's audit procedure, the applicable requirements, safety impact, recurrence, whether the issue is systemic, and sometimes the competent authority's accepted approach.

AI should not classify by tone. It should not call a finding major or minor because the wording sounds serious, and it should not escalate or downgrade one without the classification criteria in front of it.

The safe pattern:

• ask for the organisation's classification procedure;
• map the draft against those criteria;
• list the factors that may influence the level: repeat occurrence, potential operational effect, missing containment, weak traceability;
• show uncertainty;
• hand a recommendation to the reviewer.

The auditor, quality manager or other authorised reviewer decides the classification and the issue status. AI can support consistency. It should not become the authority. What level 1 and level 2 mean when the competent authority raises a finding, and why an internal grade is a different thing, is in the findings guide.

Guardrail 4: keep the corrective action separate

A finding describes the gap. The corrective action responds to it and, where required, to its root cause. A vague prompt blurs the two: the tool drafts a finding and immediately proposes a neat action that sounds good and misses the cause.

Keep the stages apart:

1. draft the finding statement;
2. identify missing evidence or source issues;
3. draft a correction request if needed;
4. support root cause thinking;
5. draft possible corrective action wording;
6. leave approval and verification to the human process.

There is a direct link between the two records. A finding that says "records not maintained" invites the reply "staff reminded", which may close the paperwork and leave the process unchanged. A precise finding shows whether the problem is record entry, supervision, procedure design, unclear responsibility or an isolated error, and what closure evidence would be relevant. The auditee still writes the root cause and the organisation still accepts the plan. The CAP side is covered in how to write an aviation corrective action plan, and a worked root cause analysis in Root Cause Analysis and CAPs for EASA Audit Findings.

Guardrail 5: review before issue

AI-drafted finding text is draft material, and the workflow should make that impossible to miss. The output is labelled as a draft, shows the source used, lists assumptions, flags missing evidence and marks where wording, classification and the corrective action request need checking.

A draft finding should never quietly become an issued one. Before it goes out, the reviewer should be able to run down a short list:

• Is the issue within audit scope?
• Is the requirement correct?
• Is the evidence specific and objective?
• Is the sample described?
• Is the gap linked to the requirement?
• Is the wording neutral?
• Is uncertainty visible?
• Is classification left for the authorised reviewer?
• Is the official system still the system of record?

A tool can pre-check the draft against that list and show where it fails. That makes it a preparation gate, not an approval gate. The professional still decides whether to issue, amend, downgrade, upgrade, or keep it as an observation. Where the gate sits for other kinds of work is covered in the human review gate.

What to ask before drafting

If the input is only "procedure not followed", a good assistant does not produce a confident nonconformity. It asks:

• Which requirement or procedure section is being assessed?
• What audit scope applies?
• What records or activity were sampled?
• What exactly was observed or not found?
• Was it a record, a visual observation or an interview comment?
• Is there an accepted deviation, concession or alternative process?
• Is this a draft observation or an intended finding?
• Which procedure defines classification?
• Who must review before issue?

Then it produces a structured draft: requirement, evidence, observation, gap, draft finding statement, classification inputs, assumptions, missing information and the next review step. These questions feel slower than a one-click rewrite. They are what stop weak notes becoming strong claims. A good aviation assistant should be comfortable saying: this is not ready as a finding yet.

How Avioverse handles finding drafts

Avioverse is a personal aviation workbench for professionals working in an EASA environment. Its Audits module carries checklists, the audit report and findings, and findings can be worked during fieldwork. A team audit records an accountable finding handler and an independent reviewer. Metis, the assistant, can help turn rough notes into a structured draft, and the Find sources mode shows attributed regulation passages with the version and date details available, so the requirement can be checked rather than assumed.

The workflow follows the order argued for above. The finding is developed first: the cited paragraph checked, a repeat in the same organisation told apart from a lesson learned elsewhere, root cause and contributing factors worked through, the corrective action plan finalised. Only then comes the risk decision. Accepting an auditee's actions does not close a finding. The auditor closes it explicitly, with the action evidence in place and an explicit risk decision recorded.

Avioverse prepares the draft. The auditor owns the conclusion, the organisation owns the corrective action, and the approved process owns issue and closure.