Audit trails: keeping evidence of what happened and why

By the end, you can

• Define an audit trail and explain what evidence it must preserve for a project decision or approval to be genuinely reviewable later, rather than merely claimed (PM-5).
• Use AI to help assemble a first-pass audit trail from a project's existing records, and explain why a named reviewer must confirm it is complete before relying on it (PM-4, PM-5).
• Identify what is missing from an incomplete audit-trail entry — such as a missing approver or a missing link to the underlying record — and correct it (PM-5).

Before you start

This is Module 5, Lesson 2 of the AI-Powered Project Management course. It builds on Lesson 1's approval gates and review roles, and turns to the evidence that proves a gate was actually used as designed. It assumes you have completed Lesson 1 and have used at least one AI chat assistant for drafting text.

An audit trail is evidence, not a claim

A project can claim a decision was reviewed and approved properly. An audit trail is what lets someone who wasn't in the room check whether that claim is actually true. APM's project management glossary defines governance as "the framework of authority and accountability that defines and controls the outputs, outcomes and benefits from projects, programmes and portfolios" — the structure Lesson 1's gates and review roles exist inside. The same glossary defines an audit as "a means to provide assurance that enables the sponsor to have confidence that the governance is working and that the project is being managed as intended." An audit only works, though, if there is something concrete to check it against — a governance structure with no kept evidence is a set of rules nobody can verify were actually followed.

A usable audit-trail entry needs four things: what was decided or approved, who approved it, when, and what it was checked against — the brief, the budget line, the policy, or whatever the gate exists to protect. "The budget increase was approved" is a claim. "On 14 March, the trustee board approved a £600 increase to the software budget, checked against the charity's reserve policy, minuted in that meeting's record" is evidence. The difference is not length or formality; it's whether a reader who wasn't there can actually check it.

Why an AI-assembled audit trail still needs a reviewer's check

Given a project's existing records — meeting notes, decision records, action logs, correspondence — an AI assistant can do real, useful work pulling together a first-pass audit trail: scanning for anything that looks like an approval and laying it out chronologically with dates and named people attached. Assembling that by hand, across weeks of scattered notes, is exactly the kind of tedious cross-referencing an AI assistant is well suited to help with.

It is not the same as knowing whether the trail is actually complete. The Open Worldwide Application Security Project's (OWASP) guidance on misinformation warns that "overreliance occurs when users place excessive trust in LLM-generated content, failing to verify its accuracy" — and an audit trail is a document where a confident-looking gap is easy to miss, because a tidy, chronological list reads as thorough whether or not anything is actually missing from it. An AI assistant reading only the records it was given has no way to know about an approval that happened in a phone call nobody wrote down, or a decision the notes describe informally without ever using a word like "approved." The US National Institute of Standards and Technology's (NIST) AI Risk Management Framework's description of an AI system as something that "can, for a given set of objectives, generate outputs such as predictions, recommendations, or decisions" is exactly why a drafted audit trail is a first pass to check against what a named reviewer actually remembers happening, not a verified record on its own.

Confirming an audit trail is complete — and flagging any gate from Lesson 1 that has no matching evidence at all — is itself the kind of call the OWASP guidance on excessive agency has in mind when it recommends that a human "approve high-impact actions before they are taken." A trail that looks complete but silently omits an approval is arguably worse than an obviously incomplete one, because it invites false confidence; checking it belongs with a named reviewer, not with the draft that first assembled it.

A worked example: Riverside Food Bank's spend-increase evidence

Six weeks into the volunteer-scheduling rollout, Riverside Food Bank's trustee board asks the operations coordinator for evidence that a £600 overrun on the software budget — approved by the trustee board under the rule Lesson 1's worked example established, that any overrun on a board-approved budget comes back to the board — followed the charity's own rules. She asks an AI assistant to assemble an audit trail from her meeting notes, decision records and email correspondence.

The draft trail reads well: it lists the trustee board meeting date, quotes the minuted decision approving the £600, and links to the decision record from that meeting. Checking it against what she actually knows, the coordinator finds one real gap: the AI's draft has no entry for an earlier, smaller £150 top-up she and the director agreed by email before the board meeting, because the informal email exchange never used a word like "approved" that the assistant's scan could easily match. Adding the entry exposes a second, sharper problem the tidy draft alone would never have shown her: under the same any-overrun rule, the £150 was never hers and the director's to agree between themselves — it should have gone to the board too. She adds the entry with the email attached as the underlying evidence, and flags both gaps to the board honestly: a traceability gap (an agreement that nearly went unrecorded) and a governance gap (an approval made at the wrong level, which she now asks the board to ratify retrospectively and minute). An audit trail that surfaces an uncomfortable finding is doing exactly its job — quietly leaving the £150 out would have turned an honest process weakness into a concealed one. She also confirms the draft correctly excluded a routine confirmation-tier purchase — a replacement laptop charger from her task breakdown — since Lesson 1's review-path map never required that decision to be logged in the audit trail at all, only routine spend within the already-approved budget line.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. Project management glossary — APM (Association for Project Management). Defines governance as the framework of authority and accountability that controls a project's outputs, outcomes and benefits, and an audit as a means to provide assurance that the governance is working and the project is being managed as intended.
2. AI Risk Management Framework 1.0 — NIST AI Resource Center. Frames an AI system as an engineered system that generates outputs such as predictions, recommendations or decisions — not a self-directing decision-maker.
3. LLM09:2025 Misinformation — OWASP Gen AI Security Project. Defines overreliance as placing excessive trust in AI-generated content without verifying its accuracy.
4. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project. Recommends human-in-the-loop control requiring a person to approve high-impact actions before an LLM-connected system takes them.