The AI Audit Trail Illusion: The Exception Nobody Configured

Audit trail review is one of the oldest control activities in a computerised GxP quality system, and one of the least glamorous.

The system preserves relevant record activity: who touched which field, what the value was before, what it became, and when the change happened. A reviewer examines that history directly, or through a validated exception report, and asks a narrow question: does anything here need a closer look.

FDA's data integrity guidance, MHRA's GxP data integrity guidance, and EU GMP Annex 11 use different formulations and carry different regulatory weight. They nevertheless support a familiar operating model: retain attributable records of GxP-relevant creation, modification, deletion, and abnormal system activity, preserve what came before, and review that history at a prescribed or risk-based frequency.

None of them assumes the underlying data was necessarily typed by a person. Instrument-generated and system-generated records sit squarely within their scope.

The model works particularly well when the event worth finding produces a visible change. A value is overwritten. A record is deleted. A critical field changes outside the expected workflow. This is the kind of event audit trail review is particularly good at surfacing.

AI-assisted authorship introduces a different condition. Machine-generated content can acquire the authority of a human-owned GMP record without producing an abnormal change for the review process to detect. Record mutation and record legitimisation are different events, and conventional audit trails were built to track only the first one.

Four dispositions cover what happens to a machine draft. A reviewer can accept it unchanged, accept it with modification, reject it outright, or request regeneration before deciding anything. I use adoption for the first two: generated content enters the GMP record and the reviewer accepts responsibility for it, edited or not.

Unchanged adoption is the clearest test of the gap, because it leaves no editing history at all. Adoption with modification can leave much of the same gap open, wherever the machine draft and the reviewer's disposition aren't retained separately. Rejection and regeneration are dispositions, but they aren't adoption; nothing generated has become the record yet.

The point where machine output becomes a human record

Picture an AI drafting tool inside a document-heavy Quality workflow. Whatever the integration pattern, the event that matters is the same: the system proposes content that may become the record before that record exists to be altered. A person reviews the draft, edits it or doesn't, and saves the result.

In a common implementation pattern, the final field history identifies the person who saved the content and the time of the transaction. Those are core audit-trail attributes, but on their own they don't establish which tool drafted the text, what evidence it used, or how the final version relates to what the tool first produced. Whether that relationship is even reconstructable depends on how the save happened, which the next section works through properly rather than assuming the worst case.

This is the boundary I examine in AI governance and validation work: whether a control designed around one kind of behaviour still functions when the behaviour underneath it changes, even where the system passed every test written for its original use.

Consider an impact assessment for a manufacturing change, a revised mixing time, or a new gasket material. The change owner asks an assistant to draft the assessment. The assistant retrieves what it can find, analyses the available material, and writes a competent, well-organised response. The change owner reads it, agrees with the reasoning, and accepts it unchanged.

The assistant's retrieval never reached the cleaning validation protocol the change actually affects. Wrong equipment train, an older document version, a filename that didn't match the search terms. The assessment is fluent, plausible, and wrong by omission.

That missing protocol belongs to the AI provenance record and to the reviewer's own verification task. A conventional audit trail was never going to identify it. The audit trail review failure sits one level further along: the saved assessment produces no classified event showing that machine-generated content was adopted, whether the provenance record was linked, whether the defined evidence checks were recorded, or whether the required provenance record exists at all. Review-by-exception has no reason to surface the transaction, even though its authorship and evidence path differ materially from an ordinary human-authored assessment.

I separate three controls here because they're doing different work. The AI provenance record answers what the system generated and which controlled evidence it used, in practice usually a backend log the ordinary audit trail never surfaces: the prompt or instruction given to the model, the source passages it retrieved, the model and version that ran, and the exact output returned. The human disposition record answers whether the person adopted the content unchanged, adopted it with modification, rejected it, or requested regeneration, and what they checked before deciding. The audit trail review control answers which of those events and patterns are surfaced for independent review. A system can have excellent provenance capture and still fail the third control completely. That's the specific gap this article addresses.

The save pattern decides what's reconstructable

Two patterns matter here, worth naming plainly before going further. A synchronous save is where the AI's draft and the human's edit happen in one transaction: both live only in the browser until the person clicks save, and the system never records the AI's version as a state of its own. An asynchronous save is where the AI writes its draft to the database first, as its own persisted record, and the human reviews and edits that saved version afterwards, in a separate transaction.

In the synchronous case, the field history has no “before” value representing the AI's proposal at all. Whatever the field held prior to that save, often nothing, becomes the old value. The human's approved text becomes the new value. The AI's contribution was never a state the system held, so there's nothing to reconstruct even in principle.

In the asynchronous case, a real diff exists: old value is the AI's draft, new value is whatever the human did with it. That's a genuinely better architecture, and it survives an objection worth taking seriously, that ordinary field history already captures machine-to-human edits and this piece overstates the invisibility of the gap. For that specific pattern, the objection is fair.

The diff is there.

It isn't sufficient by itself, though, because reconstructing a diff and classifying its origin are different jobs. If that asynchronous save happens under the same account the human uses, a common shortcut for implementation simplicity, the diff exists but nothing marks the earlier value as machine-authored rather than an earlier, abandoned human draft. Reconstructability and origin classification only both hold when the AI's output is persisted as its own event, attributed to a distinguishable actor, before the human sees it.

Most implementations sit somewhere between the worst and best versions of this. At one end, someone copies a response out of an external tool and pastes it in; nothing about that text was ever persisted as AI output, and after the paste it's indistinguishable from anything the person typed themselves. At the other end, a governed workflow persists the AI's output under its own identity, tags it as machine-generated, and requires a recorded disposition before it can become part of the GMP record. Where an organisation sits on that spectrum, closer to synchronous or closer to a fully governed asynchronous pattern, is a choice made by whoever configured the integration, and it's the single most effective place to intervene, because moving toward the governed end closes most of this gap without waiting for a regulator to require it.

The exception rules were never asked about this

Risk-based, exception-driven review develops a blind spot here rather than failing outright. It performs exactly as configured, surfacing only the events and patterns someone has defined for it. Exception-reporting tools work by identifying predetermined patterns: repeated overrides by the same user, activity outside expected hours, deletions, or edits to critical fields without a documented reason. Most established rule sets focus on visible human or system changes; they contain no category for machine-generated content that a person accepts without changing.

The rule set may predate AI-assisted drafting, or the same gap can arise where a new AI use case is introduced without reassessing the audit trail review design.

Validation can demonstrate this control only where the requirements define the adoption event, the records to be retained, and the expected exception behaviour. A legacy validation package may prove that ordinary user actions are logged accurately while saying little about whether audit trail review can detect AI adoption, because adoption was never included in the specification. The same gap can therefore exist in both the system configuration and the review procedure without either one failing its own approved requirements.

This isn't unique to GxP. NIST's March 2026 report on post-deployment AI monitoring found that practitioners raise human-AI interaction and feedback-loop questions far more often than the published literature addresses, which it reads as a sign the area remains genuinely underexplored across industries generally. GxP audit trail review inherits that same gap through a stricter door, though: a regulated environment needs a defined, validated answer rather than an evolving research agenda to point to.

The gap crosses five handovers

Quality owns the audit trail review procedure and the risk assessment that sets its scope. Digital owns the system architecture and the AI drafting capability. The implementation partner configures how the two intersect. Validation demonstrates whether adoption is captured, classified, and surfaced as intended. Operations inherits the review process and responds to the resulting exceptions.

A gap at any handover can remain invisible to the functions downstream, because each receives only the records and controls created by the one before it.

The FDA and EMA's January 2026 Guiding Principles of Good AI Practice in Drug Development call for proportionate human oversight and detailed, traceable documentation of data provenance, processing steps, and analytical decisions. They do not specify how routine GMP audit trail review should classify a person's adoption of machine-generated content.

The EU's draft Annex 22 does not close the gap either. I've covered its current relationship with Annex 11 elsewhere: it remains in consultation, isn't yet enforceable, and excludes generative and probabilistic models from its critical-application provisions. Where such systems are used in non-critical applications, the draft places responsibility for output suitability on appropriately qualified personnel, without defining which adoption evidence those personnel should create or which adoption events routine audit trail review should examine. The draft therefore doesn't currently address the event at the centre of this article: what evidence should record a person's adoption of generative output, and when that event should be surfaced for review. Organisations need to make that architecture and procedural decision themselves unless later guidance addresses it.

Closing the gap means treating disposition as its own event

Where you have influence over the implementation, and not every organisation does with every AI tool already in use, the single most effective fix is architectural: persist the AI's output as its own attributable event, tied to a distinguishable actor, before a human ever edits it. That one decision does more to close this gap than any procedural control layered on top of a system that never separated the two events to begin with. Where you don't have that influence, because the tool is fixed, vendor-controlled, or already embedded, the procedural controls below still matter. They just can't fully substitute for the architecture.

I'd capture the human disposition as its own attributable event, separate from the save action: which controlled tool produced the draft, whether the person adopted it unchanged, adopted it with modification, rejected it, or requested regeneration, and what defined checks they completed before deciding.

I've addressed the wider monitoring issue in How to OQ/PQ a Hallucination: a reviewer who never disagrees with an AI system is worth examining, because repeated agreement can mean review has become procedural rather than analytical. The same logic belongs in audit trail review, with one qualification worth keeping in view.

A genuinely excellent draft can look identical in the record to a rubber stamp. Treating edit count alone as the test would reward cosmetic editing rather than substantive review.

None of what follows proves inadequate review by itself. Each identifies a record where content criticality, reviewer behaviour, or system history may justify a closer look, the same way a single field override does now: unchanged adoption of a high-criticality record, repeated unchanged adoption by the same reviewer, a review interval inconsistent with the length or complexity of the draft, regeneration after formal review has begun, a source becoming superseded or changing materially between generation and approval, missing or inaccessible provenance evidence, generated content overwriting human-edited text, an adopted record with no link back to a generation record at all, an AI contribution with no disposition recorded, or regeneration and material editing after approval without renewed assessment. These are review triggers, not findings.

I'd revalidate the exception-report logic so it includes adoption patterns, not only the modification behaviour the existing rules were written for. I'd also name the role accountable for confirming that adoption of AI-drafted content received the required substantive review, and put that accountability in the procedure rather than leave it implicit.

What I'd test

Generate a draft impact assessment for a controlled change inside a test environment. Accept it unchanged, and confirm three things: the generated version is retained rather than overwritten by the final record, the disposition is correctly classified as accepted unchanged, and the event is linked to the accountable reviewer and timestamp. Run this against however the system actually saves the draft, synchronous or asynchronous, since whether that first condition can even be satisfied depends on which. For a test case configured to meet a defined review trigger, unchanged adoption of a high-criticality assessment, for example, confirm that the event reaches the validated exception report rather than remaining logged but unsurfaced.

Then repeat the test three more times: the reviewer materially edits and adopts the draft, the reviewer rejects the draft, and the reviewer requests regeneration before making a decision. Confirm the disposition is classified correctly each time.

Confirm that regeneration or material editing of already-approved content triggers the defined re-review control. Separately, confirm that the provenance record retains the source versions applicable when the draft was generated and approved, even after those sources are superseded, so a historical decision stays tied to the evidence that was applicable when it was made. Four test cases and a modest test script are the difference between a validation package that tested logging and one that tested the control itself.

These are recommendations, drawn from how audit trail review and its supporting validation are currently scoped rather than from any published mandate. They don't need to become a mandate before organisations act on them.

I'd start with one AI-assisted GMP record and reconstruct three things from controlled evidence alone: what the system generated, what the reviewer adopted, and why that adoption event was or wasn't surfaced for audit trail review.

Where the first two exist but the third control can't see them, the organisation hasn't lost its audit trail. It has left the audit-trail review procedure looking for the wrong event.

For more on where Quality-owned controls stop matching Digital-owned systems, see the Navata Insights archive.