Why airlines are unusually well placed — and unusually exposed
Few industries generate transaction data as rich as an airline’s: every coupon, waiver, refund, fuel uplift, purchase order, crew pairing and component removal exists as a structured record somewhere. That makes airline internal audit an ideal candidate for full-population testing — the classic 25-item sample is a strange discipline to defend when the entire refund population can be tested in minutes.
The same richness creates the exposure. Data is fragmented across the PSS, revenue accounting, ERP, maintenance and departure-control systems, each with its own keys and conventions. An audit function that layers AI tooling on top of unreconciled data does not become more effective; it becomes confidently wrong at scale. Sequencing therefore matters more than tool selection.
Build the data foundation before the intelligence
The unglamorous first phase decides everything after it. It has three components. First, negotiated, repeatable access to the core systems — direct extracts or API feeds under a data-sharing agreement with IT, not ad-hoc requests that take three weeks per audit. Second, a small library of cleaned, documented base tables — sales, refunds, payables, journals, removals — refreshed on a schedule, so every audit starts from the same trusted data rather than rebuilding extracts from scratch. Third, version-controlled scripts: an analytic whose logic lives in one auditor’s spreadsheet is not a capability, it is a dependency.
Functions that skip this phase end up with impressive pilots and no production capability. Functions that complete it find the later phases surprisingly fast, because every new analytic reuses the same plumbing.
From annual audits to continuous monitoring
Once base tables exist, the highest-value move is converting known audit tests into scheduled exception monitoring. The candidates in an airline pick themselves: refunds and waivers against policy, duplicate and split invoices, credit-note patterns, fuel uplift against flight plans, agency incentive payments against contract terms, dormant-account activity in the loyalty programme. Each test that runs monthly instead of triennially changes the economics of assurance — and changes behaviour in the business, because the interval between an exception occurring and someone asking about it collapses.
Two disciplines keep monitoring honest. Every alert needs a defined owner and a disposition workflow, or the exception queue becomes wallpaper within a quarter. And thresholds need periodic recalibration against outcomes, or the function drowns in false positives and quietly stops looking.
AI does not raise the standard of audit judgement. It raises the volume of material on which judgement must be exercised — which makes the judgement more valuable, not less.
Where AI genuinely helps the audit itself
With foundations and monitoring in place, AI assistance earns its keep in specific, bounded roles:
- Anomaly detection across full populations — surfacing outliers in proration results, maintenance billing or station expenses that rule-based tests were never written to catch.
- Document work at scale — extracting obligations from ground-handling and support contracts, comparing invoiced terms to contracted terms, summarising policy changes between versions.
- Drafting acceleration — first-pass working papers, test summaries and finding write-ups, produced for the auditor to correct rather than compose.
- Risk-assessment support — synthesising incident logs, board papers and prior findings when building the audit universe and annual plan.
Note what is absent from that list: forming the audit opinion, rating findings, and deciding what matters enough to escalate. Those remain human acts, and pretending otherwise is how functions lose the confidence of their audit committee.
Govern it like you would audit it
An audit function that would criticise the business for ungoverned AI must hold itself to the standard it enforces. That means a documented inventory of models and analytics in use; validation and periodic re-testing of anything whose output influences an audit conclusion; explicit rules on what data may be passed to which tools, especially passenger data subject to privacy regimes; human review recorded for AI-drafted material; and honesty in reporting — the audit committee should know which conclusions rest on full-population analytics and which on judgement, and should never discover after the fact that a machine screened out what a human should have seen. Skills close the loop: pairing career auditors with data engineers works better than expecting either to become the other, but every auditor needs enough fluency to challenge an analytic’s logic rather than accept its output.
One further governance point is easy to miss: independence. Where the business runs its own monitoring — revenue assurance dashboards, procurement analytics — internal audit should assure those controls, not duplicate them. The assurance map needs redrawing as analytics spread, or the second and third lines end up running the same tests while nobody tests the tests.
Where to start
Pick one recurring, data-rich audit — refunds, payables or fuel are the usual candidates — and rebuild it as a full-population, scripted analytic with a monthly exception feed. One production capability teaches the function more about data access, tooling, governance and workflow than any strategy paper, and gives the audit committee something concrete against which to judge the investment case for the rest.