Skip to content

AI Audit Guide: Evidence Beats Checklists [Hands-On]

AI audit done right starts with evidence logs and inventory, not paper checklists. Practical beginner steps, pitfalls, and when to skip it entirely.

8 min readBeginner

Two ways to run an AI audit – only one actually works

Most teams start an AI audit the same way they start a policy review: download a long checklist, tick boxes for “we have a model card” and “bias was considered,” then file the PDF. Feels fast. Produces almost nothing you can hand a customer – or a regulator – when something breaks.

The better path treats the audit like a small investigation. Living inventory of every AI touchpoint (including the unofficial ones). Immutable logs of prompts and actions. A few concrete tests. Artifacts someone else can replay. Slower the first week. The version that still makes sense after an incident.

Think of the checklist path as photographing the fire extinguisher sign. The evidence path is checking the tank pressure, the date tag, and whether anyone on the floor can actually pull the pin. Same “safety” label on paper. Very different Tuesday afternoon.

Frameworks help you organize risk work; they do not replace records. The NIST AI Risk Management Framework (Govern-Map-Measure-Manage; AI RMF 1.0 dated 26 January 2023, Generative AI Profile NIST AI 600-1 on 26 July 2024, and still being revised) is voluntary structure. ISO/IEC 42001:2023 (published December 2023) is the certifiable AI management-system standard – useful later, not a substitute for logs now. Checklists without trails fold in the first real review. Evidence work maps onto those frameworks when you need a third party or a certificate.

Quick context: what you are actually examining

IBM puts it simply in their AI audit overview: a structured, evidence-based look at design, training, and deployment – data, model, live decisions, plus governance. Separate topic from “we used an LLM to speed a financial audit.”

Regulators already care. As of the EU AI Act’s 2024 application timeline, high-risk systems face conformity duties; many Annex III cases run on internal control, while some biometric uses need a notified body. Article 12 expects automatic event logging over the system’s life. Internal audit teams often lean on the IIA’s AI auditing framework (updated materials with stronger genAI/LLM coverage) for governance and control questions. None of that helps if your inventory is fiction and your prompts vanish.

Hands-on AI audit tutorial for beginners

No Big Four required. No six-figure GRC suite on day one. This sequence fits an internal pass over company genAI, a vendor chatbot, or a home-grown LLM assistant. Match depth to blast radius.

1. Freeze scope and build the real inventory

One sentence on paper: “We are checking every AI system that touches customer or employee data in [department] for data leakage, unauthorized actions, and missing human oversight.” Then list systems. Official models are easy. Shadow ones are not.

  • Approved SaaS with AI features (CRM summarizers, HR screeners, support bots)
  • Internal fine-tunes or RAG apps
  • Browser extensions, personal ChatGPT/Claude accounts used for work, Slack/Teams plugins
  • Vendor models that process your data

Scan expense reports, SSO logs, and browser traffic for AI domains. Interview five people who “just use AI for drafts.” Those chats run long; people get defensive about personal accounts. Write down owner, data categories, intended purpose, and last model version anyway. Leadership almost always under-counts once you look – that gap is the audit, not a footnote.

2. Map the data and decision path

For the three highest-impact systems, one page each: source data → preprocessing → model/API → output → human review (if any) → downstream action. Mark where personal data enters and whether retention or deletion rules exist. Stale or unlabeled training data is a common bias source; flag it while the diagram is still simple.

3. Stand up minimal prompt and agent logging

Checklists love model cards. They rarely force this. For anything you control, log at least:

timestamp | user_id_or_service | model_name_version | prompt_hash_or_redacted | tools_called | output_hash | data_sources_accessed | human_override (y/n)

Append-only storage – S3 Object Lock, an immutable table, or a signed append log. Redact PII at write if you must; keep enough to reconstruct. Third-party tool? Demand an audit-log export or pick a vendor that has one.

The catch is “complete-looking” logs that still fail a defensible-trail test: admins can edit history, model version is missing, user attribution is a shared service account, no record of data access or tool calls. Forcepoint’s auditability write-up and similar guidance hammer immutability plus who/what-model/what-data. EU AI Act Art. 12 points the same direction for high-risk systems. Editable admin logs will not survive a serious review.

Pro tip: Instrument the single highest-risk agent first. Perfect fleet coverage later beats zero coverage everywhere.

4. Run three concrete tests

Cheap. Repeatable. Written down.

  1. Data leakage probe – Unique canary string or synthetic PII in a prompt. Search later outputs and vendor training claims.
  2. Simple fairness slice – Ranking or decision system? Split a small held-out set by a relevant attribute when lawful and available; compare error rates. No protected attribute? Short vs long inputs, or two languages, as a robustness proxy.
  3. Oversight and fail-safe check – Kill the model path or force an error. Who gets notified? Can it still take an irreversible action with no second pair of eyes?

Exact test set, date, model version, raw results. That packet is Measure-function evidence in NIST language – not a vibes slide.

5. Package findings and set the next review date

Short report: inventory snapshot, top risks, missing controls, owners, due dates. Attach log schema and sample results. Re-check high-change systems in about 90 days; stable low-risk can wait longer. If ISO 42001 or an EU conformity package shows up later, you already have a starter evidence file instead of a scavenger hunt.

Common pitfalls

Inventory as a one-time spreadsheet. Plugins change weekly. You end up auditing yesterday.

Accuracy scores cosplaying as audit evidence. A shiny F1 says nothing about an agent emailing a customer file with no authorization path.

Same admins editing the logs they run under. Immutability is the whole joke; without it the trail is theater.

LLM-as-judge as the only control. Hallucinated citations and missed context have already bitten real consulting write-ups. Humans or deterministic checks for anything that matters.

What good looks like

After one serious pass you should answer four questions in a few minutes: Which AI systems exist? What data can each reach? Who authorized the last real change? Can we replay the last 50 high-impact decisions from logs?

Teams that get there usually spend less time scrambling on customer security questionnaires. Not magic – just fewer “we will have to check” loops. Turns out the boring inventory-and-log gap is still the bottleneck; the arXiv paper on AI accountability infrastructure (2402.17861) mapped a crowded eval-tool scene that still underserves harms discovery, independent data access, and post-evaluation advocacy. Closing trail gaps does more than buying another score dashboard.

Focused first pass on 5-10 systems: often a few person-days once logging exists (field estimate, not a lab benchmark). Recurring cost drops after the pipe is real.

When NOT to run a full AI audit

Pure internal productivity toys that never leave your network, touch no personal data, and cannot trigger external actions – local code completion for two engineers, for example. Skip the ceremony.

Zero production AI? Do readiness and inventory first. Formal third-party or conformity work can wait until high-risk systems or contracts demand it. Over-auditing harmless tools burns patience you will need when a system can actually hurt people or the business.

You can collect perfect logs and still miss the point if nobody is allowed to say “turn it off.” Process without authority is cosplay.

FAQ

Is an AI audit the same as ISO 42001 certification?

No. Audits examine systems and controls. ISO/IEC 42001 certifies the management system. Run internal evidence passes long before you chase a certificate.

Do I need a data scientist on the audit team?

Nice to have, not required for pass one. You need someone who reads logs, traces data touchpoints, and checks that human oversight is real. Save specialist bias or red-team help for the highest-risk models. Plenty of internal audit groups start from the IIA framework materials and grow skill on live systems.

How often should we re-audit?

“Annually” is a calendar story, not a control. A customer-facing agent that gains new tools every week wants continuous monitoring and a formal look each quarter. A quiet internal classifier may wait a year. If the model or connected tools changed last month, last year’s binder is trivia. Tie frequency to the change log.

Pick one production AI system this week. Write its inventory row. Turn on basic prompt logging. That beats another unread framework PDF.