Short summary
Regulators are beginning to audit AI use in regulated businesses. When they do, they ask six categories of questions about each AI-assisted decision. This guide sets out those questions and shows how to build the evidence to answer them — before the audit begins.
- Why AI audits are an emerging regulatory priority
- The six questions regulators ask about AI-assisted decisions
- How to build and maintain the evidence trail for AI use
- What an AI audit pack should contain and how to generate it on demand
AI audits are no longer hypothetical. The EU AI Act creates mandatory audit rights for high-risk AI systems. National financial regulators have begun including AI governance in supervisory reviews. CSRD assurance providers are adding AI-assisted data processing to the scope of their engagements. And where AI is used in AML, credit, or employment decisions, regulatory investigations already demand evidence of how AI outputs were generated and reviewed.
Most organisations are not ready. They have the AI. They do not have the audit trail.
Why AI Audits Are Coming
Three regulatory trends are converging to make AI audits routine rather than exceptional.
First, the EU AI Act (Regulation 2024/1689) creates mandatory conformity assessments for high-risk AI systems, including ongoing obligations for operators to maintain technical documentation, implement logging, and cooperate with market surveillance authorities. From August 2026, these obligations apply to deployers, not just developers.
Second, sector regulators — FCA, EBA, FINRA, and equivalents — have observed that AI is now embedded in material regulated processes (AML monitoring, credit decisioning, insurance underwriting) and have signalled that AI governance will become part of standard supervisory review.
Third, CSRD assurance is extending to AI-assisted sustainability data processing. If AI was used to classify, calculate, or summarise material emissions data, assurance providers need to assess the reliability of that process — which requires understanding how the AI works and how its outputs were reviewed.
The Six Questions Regulators Ask
What did the AI do?
What was the specific task, what inputs were provided, what model or system was used, and what was the output? This requires a log of each AI action, not a general description of the system.
Who triggered it?
Which individual, with what role and authority, triggered the AI action? This establishes human responsibility for the AI's use — a named person, not "the system."
Who reviewed the output?
Which individual reviewed the AI output before it had effect? What was their role and authority? Did they accept, modify, or override the output?
What happened after?
What action was taken based on the AI output? Was the action consistent with the output, or did the reviewer override it? If overridden, why?
Is the system documented?
Does technical documentation exist for the AI system: what it does, what data it uses, what its known limitations are, how it was tested, and how errors are detected and corrected?
How are errors managed?
What process exists to detect AI errors? How are material errors escalated? What happened when an error was detected — was the affected decision reviewed and corrected?
Building the Evidence Before the Audit
The evidence for each of these questions does not appear spontaneously at audit time. It must be built into the AI workflow from the start.
For Q1 and Q2: Implement structured AI action logging. Every AI action generates a log entry with: timestamp, triggering user, model/system identifier, input summary (not the full input, but a structured summary), and output reference. This log is stored in the audit trail, not in a separate AI system.
For Q3 and Q4: Build the review step into the workflow. AI output does not go directly into the record of decision — it goes into a review queue. The reviewer's action (accept, modify, override) is logged with their identity and timestamp. If they override the AI, the reason is captured.
For Q5: Maintain a system card or model card for each AI system in use. This does not need to be a technical deep-dive; it needs to describe what the system does, what inputs it uses, what it is known to get wrong, and how you mitigate those errors in the workflow.
For Q6: Define an error management process. When an AI output is found to be materially wrong, the process should: document the error, assess the impact on decisions made using the output, correct those decisions where possible, and record the correction.
Common Evidence Gaps and How to Close Them
| Gap | Risk | Fix |
|---|---|---|
| AI actions logged separately from the main audit trail | Regulator cannot see AI use in context of the decision | Merge AI logs into the workflow audit trail |
| Review step is optional or not recorded | Cannot demonstrate human oversight | Make review a mandatory workflow gate with required logging |
| No system documentation | Cannot satisfy EU AI Act technical documentation requirement | Create a system card for each AI use case |
| Error management is informal | Cannot demonstrate that material errors were caught and corrected | Define a formal error management process with escalation and correction records |
The AI Audit Pack
An AI audit pack is a structured export of all the evidence for AI use in a specified scope: time period, business process, or decision type. It should contain: the AI action log for the scope, the review records for each action, the system documentation, and a summary of any errors and their resolution.
If generating this pack requires more than a few clicks, your audit trail is not structured enough. The pack should be available on demand, without manual assembly from multiple systems.
HubSecure's audit trail includes AI actions alongside all other workflow events. The AI audit pack is generated from the same export mechanism as any other audit pack — scope, filter, export, done.
Governed AI for Regulated Operations
Every HubAI action is logged in the main audit trail — not a separate AI log. The AI audit pack generates on demand, in seconds. Build the evidence before the audit, not during it.