The Audit Playbook: What Auditors Actually Ask About Your AI Agents

By the Ingenious AI team · Last updated: October 13, 2026 · 8 min read

Compliance context: the regulations cited below are real and verifiable (EU AI Act, Regulation (EU) 2024/1689; SOC 2 Trust Services Criteria). The audit scenario is illustrative — no real company's audit is depicted. This post is operational guidance, not legal advice.

The auditor's first question about your AI agent is never technical. It's this: "Show me the record of what this system did to customer data on March 14th."

What happens next separates teams that pass from teams that get findings. One team opens a ledger, filters to the date, and exports a chain-verified timeline in four minutes. The other opens a Slack thread, a shared doc, and a database they haven't queried since deployment. The audit outcome is usually decided in that first hour, and it's decided by whether the records exist, not by how good the agent is.

This post is the playbook for the first kind of team. Not theory — the actual questions, the actual artifacts, and the three mistakes that turn a clean audit into a finding.

The five questions every auditor asks

Audits differ — SOC 2 Type II, an enterprise security review, an EU AI Act conformity check — but the questions converge. Here are the five we hear described most often, in the order they usually arrive:

1. "What did the system do, and when?" This is the baseline. The auditor names a window — a day, a week, an incident — and wants a complete ordered record of the agent's actions: tool calls, decisions, outcomes. Not a summary. The sequence.

2. "Who authorized this action?" Agents act with delegated authority, and auditors want the delegation chain. Which system prompt, which policy version, which human approval — for every action that moved money, touched customer data, or changed something outside the model. "The agent decided" is not an answer.

3. "Can you prove these records weren't altered?" This is where ordinary logging dies. A Postgres table of events is a claim. A hash-chained, append-only ledger with independent verification is evidence. Auditors don't need to understand SHA-256; they need to see the verification run and pass, preferably with their own tooling.

4. "Show me the failure." Nobody audits the happy path. They ask for the worst incident of the period: the loop, the bad refund, the wrong data write. They want the timeline, the root cause, the remediation, and the proof that the remediation was actually deployed. Teams that can't find their own incidents don't survive this question.

5. "How long do you keep this, and who can see it?" Retention policy and access control, together. The EU AI Act sets a six-month minimum retention floor for logs of high-risk AI systems (Articles 19 and 26(6) of Regulation (EU) 2024/1689). SOC 2's Trust Services Criteria expect retention that's appropriate to commitments you make to customers. "We keep everything forever and everyone on the team can read it" is a privacy finding wearing a trench coat.

The EU AI Act angle, precisely

Article 12 of the EU AI Act requires high-risk AI systems to technically allow for the automatic recording of events — logs — over the lifetime of the system. The logging has to support risk identification, post-market monitoring, and operational oversight. That's the verified core of it.

Three things teams get wrong. First, scope: Article 12 applies to high-risk AI systems only. A marketing copy agent is not automatically in scope, and panicking every chatbot vendor into Article 12 compliance is wrong. Second, content: the Act does not require storing full prompts and outputs — recommending that indiscriminately creates GDPR data-minimization exposure. Purpose-driven event logging is the standard: who, did what, when, why, with enough detail to reconstruct the functioning. Third, automaticity: the logging must be technically automatic. A policy that says "engineers should write a summary after incidents" is not Article 12 logging.

Our recommendation for teams near the high-risk boundary: build the event-level ledger now, whether or not you've finished classifying your system. The records are useful for every other audit on this list, and the marginal cost of keeping them is a rounding error next to the cost of reconstructing six months of history after a regulator asks.

The audit packet: what to hand over

When the audit starts, don't give the auditor a database login and a wish. Give them a packet. Here's what goes in it:

A chain-verification report. The full verification run over the audit window, timestamped, with the result. Pass means the records are intact and in order. This answers question 3 before it's asked.
Exported timelines for the window. Ordered action records with tool calls, arguments summaries, outcomes, and decision reasoning. Masked where PII rules require it — the auditor needs the shape of the actions, not customer account numbers.
The policy-and-approval map. Which system prompt and guardrail versions were live during the window, which actions required human approval, and the approval records themselves. This answers question 2.
The incident file. Your worst incident of the period, with the timeline, root cause, remediation, and the deployment record proving the fix shipped. Volunteering this is strong. Hiding it and having the auditor find it anyway is a finding plus a trust problem.
Retention and access documentation. The written retention policy (with the six-month AI Act floor if applicable), who can read and write the ledger, and when access was last reviewed. This answers question 5.

Assemble this packet once, as a repeatable export from your ledger. The second audit takes an afternoon. The first one, without the ledger, takes a quarter.

The three mistakes that become findings

Mistake 1: The logs exist but nobody can query them. Events in a vendor's black-box dashboard with a 30-day retention window are not audit records. If you can't export the full window, ordered, with integrity proof, you don't have logs — you have a demo.

Mistake 2: The records show actions but not decisions. "Agent called issue_refund at 2:47 AM" answers the what. It doesn't answer why the agent chose to do it, which is what distinguishes a bug from a misalignment — and what the auditor needs to assess whether your controls actually control anything. Log the stated reasoning with each consequential action.

Mistake 3: The integrity story is "trust us." Append-only as a documented policy is good. Append-only plus hash-chaining plus independent verification is evidence. The auditor's job is to not take your word for things; handing them the verification tool removes the question entirely.

FAQ

Does the EU AI Act require me to log my AI agent?

Article 12 of Regulation (EU) 2024/1689 requires high-risk AI systems to technically allow automatic recording of events over the system's lifetime, with logs supporting risk identification, post-market monitoring, and operational oversight. It applies to high-risk systems only — not every chatbot. Articles 19 and 26(6) set a six-month minimum retention floor. If your system is anywhere near the high-risk boundary, keep event-level logs regardless; they serve every other audit too.

What do SOC 2 auditors want to see for AI systems?

Under the Trust Services Criteria, auditors want evidence of the system operating as described: ordered records of what the agent did to customer data, who authorized consequential actions, how long records are retained, and who can access them. The winning move is exporting a verified timeline for the audit window instead of granting exploratory database access.

Can an auditor verify a hash-chained ledger independently?

Yes. Verification recomputes each record's SHA-256 hash from its data and the previous record's hash, and checks every link — no keys, certificates, or proprietary software required. The auditor can run their own script against an exported ledger. Independence of the verifier from the writer is the whole point.

Start logging your agents free → One export gives you the chain-verification report, the ordered timeline, and the incident file: the audit packet, generated, not assembled.