AI Audit Evidence: What SOC 2 and ISO 27001 Auditors Actually Want

AI audit evidence is the system-generated proof — access logs, audit trails, vendor records, and impact assessments — that demonstrates your AI usage meets a control framework like SOC 2, ISO 27001, the EU AI Act, or the DSGVO. The gap most organizations hit is not having a policy; it is producing the evidence when an auditor asks. The single demand that trips teams up: show me which employee sent what data to which model, when. A policy PDF does not answer that. A log does — if you have one.

Three myths make this harder than it needs to be, and we will clear them up front: there is no "SOC 2 for AI," the famous "90-day log retention" rule is not a SOC 2 requirement, and most everyday workplace AI assistants are not "high-risk" under the EU AI Act. Once those are out of the way, the real work is narrow and concrete: produce the specific artifacts each framework actually accepts. This guide maps them — and explains why personal AI accounts produce none of them and even enterprise tiers often fragment the evidence.

There is no separate SOC 2 framework for AI. When an AI assistant processes customer or personal data, it is audited against the existing AICPA Trust Services Criteria — the same logical-access, monitoring, change-management, and vendor criteria that cover any system. The AI-specific standard is different: ISO/IEC 42001, published in December 2023, is the first certifiable AI management system (AIMS) standard, and it is the one auditors increasingly point to for AI governance specifically. It extends an ISO 27001 information-security management system rather than replacing it.

The practical takeaway: you do not need a mythical "AI certification" to pass an audit with AI in scope. You need to satisfy the criteria you are already audited against, applied to the AI, plus — if you want a credentialed AI-specific signal — ISO 42001. Treating AI as exotic leads teams to buy point tools instead of producing the evidence the frameworks they already hold actually require. For the deployment mechanics behind the evidence, see our AI agent RBAC and audit-trail guide.

SOC 2 evidence for AI clusters around four Common Criteria areas. Logical access (CC6): encryption of data to and from the model API, provisioning and access reviews, and role-based least-privilege over who — and which service accounts — can invoke the model or read the underlying data. Monitoring (CC7, especially CC7.2): continuous audit logging of inferences (model version, redacted prompt and tool calls, outcome) plus alerting and incident response. Change management (CC8.1): an approved change policy with sampled change logs and segregation of duties. Vendor management (CC9): the LLM provider is a subprocessor, so you need a documented vendor risk assessment, the provider's own SOC 2 Type 2 or ISO report, proof of a no-training or zero-data-retention configuration, and a signed DPA.

Two details decide pass or fail. First, auditors strongly prefer system-generated, timestamped, tamper-resistant logs over screenshots — and for a Type II report the logs must span the full observation window, proving the control operated over time, not just on the day you looked. Second, a uniquely AI-flavored failure: logging raw, un-redacted prompts and completions that contain personal data turns your audit-trail control into a data-leakage finding. Redact before you write the log.

Under the EU AI Act, automatic logging is a legal duty — but only for high-risk systems. Article 12 requires high-risk AI to automatically record events over its lifetime; Article 26(6) requires the deployer to keep those logs for at least six months. The crucial nuance most coverage gets wrong: high-risk status is driven by the use case, not the technology. A general workplace assistant is high-risk only if it materially influences an Annex III decision — for example employment decisions like recruitment, promotion, termination, or worker monitoring. Ordinary drafting and search support usually is not high-risk, though the Article 50 transparency duty (disclosing that a user is interacting with AI) can still apply. As of 2026 the Annex III high-risk obligations apply from 2 August 2026; a proposed deferral to December 2027 (the "Digital Omnibus") was under discussion but not yet adopted, so treat 2 August 2026 as the live date and re-check before you rely on it. See our breakdown of AI Act Annex III for HR.

The DSGVO applies regardless of high-risk status whenever personal data flows to an AI. Article 30 requires the LLM provider to appear in your records of processing as a recipient or processor, with transfer safeguards if it sits outside the EEA. Article 5(2) accountability means you must be able to demonstrate compliance, not merely assert it — which in practice means access-control records and audit logs. Article 28 requires a DPA with audit rights, and Article 35 makes a data protection impact assessment likely, though case by case, for higher-risk AI processing. Our DSGVO and EU AI Act checklist and DPIA template cover these in depth.

The demand auditors converge on is a per-interaction record: which user sent what input to which model, when — and, increasingly as a best-practice expectation, at what data classification. For high-risk AI that is anchored in Article 12; for everything else it is the practical shape of SOC 2 and ISO 42001 evidence. The problem is structural. Most workplace AI use happens through personal or free accounts that produce no admin log, no retention control, and no export at all — so the evidence simply does not exist. This is the same shadow AI problem from the audit side, and it is why a permission and access foundation matters.

Even enterprise tiers fragment the evidence. ChatGPT Enterprise's compliance export retains only about 30 days, so you must export continuously or lose the trail. Microsoft 365 Copilot's audit record captures message IDs and a prompt-and-response flag, but not the text — the content lives elsewhere and must be pulled via eDiscovery. Google's Vault retention covers the standalone Gemini app but not Gemini embedded in Gmail and Docs. None of these reach AI used on personal accounts at all. So even well-resourced teams find that, when the auditor asks the simple question, the answer is scattered across three consoles and a 30-day window — or missing entirely.

Teamo is a multi-LLM enterprise platform (OpenAI, Anthropic, Google, Mistral, Aleph Alpha) built so the audit evidence is a standard feature, not an enterprise add-on. Every interaction is attributable to a real user through a seven-layer permission model, and three independent audit logs record access, tool actions, and activity — so the who-sent-what-to-which-model-when question has a single, exportable answer rather than three fragmented consoles. It is EU-hosted with retention you control, DSGVO and KI-Verordnung-ready, and there is no enterprise seat minimum, so a 25-person company gets the same audit-grade evidence as a 2,500-person one. If your blocker is producing the evidence rather than writing the policy, that is the gap it closes. Compare the governance posture in Teamo vs Microsoft Copilot.

AI audits fail on evidence, not policy. Skip the myths — there is no SOC 2 for AI, no fixed 90-day log rule, and most assistants are not high-risk — and focus on the artifacts each applicable framework actually accepts: attributable, redacted, reviewed logs with a risk-based retention policy, plus subprocessor evidence and, where it applies, an AI impact assessment. The teams that pass are the ones that can answer who sent what to which model, when, in a single export. If your tooling cannot, that is the gap to close before the auditor arrives.