SOC 2 and EU AI Act Article 12 are both audit regimes. They share vocabulary — controls, evidence, periods, attestations — but they audit different layers. SOC 2 audits your organisation; Article 12 audits the runtime behaviour of your AI systems. A clean SOC 2 report is necessary for many enterprise sales and entirely silent on Article 12. Here is what each one actually requires and why one is not a substitute for the other.
What SOC 2 audits.
SOC 2 is an AICPA attestation framework. Your auditor — a CPA firm — examines whether your organisation operates the controls it claims against the AICPA Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality and Privacy. The Type I report describes the controls at a point in time; Type II describes their operating effectiveness over a period, typically six or twelve months.
The evidence SOC 2 examines is mostly static. Policies. Procedures. Tickets. Change-management records. Quarterly access reviews. Screenshots of MFA being enforced. Vendor due-diligence questionnaires. The auditor reads what you have written down and checks whether you do it.
What SOC 2 explicitly does not audit: the moment-to-moment behaviour of the systems themselves. The Trust Services Criteria do not require you to record what every workload did at runtime — only that you have appropriate logging in principle, that the logging supports investigation, and that access to logs is controlled.
What Article 12 audits.
Article 12 of the EU AI Act (Regulation (EU) 2024/1689) requires that high-risk AI systems technically allow for the automatic recording of events over the lifetime of the system. Recording, here, is not "we have a logging policy". It is a runtime property of the system — captured at the moment of the action, complete enough to support reconstruction of operational behaviour by an authority.
The evidence Article 12 demands is dynamic. Every decision the agent took. Every tool it called. Every data class it touched. Every sub-agent it spawned. The supervising authority needs to be able to ask: between these dates, this agent processed data for this customer — what did it actually do? And get a complete, integrity-protected answer, in a format their analysts can independently verify. We published a fuller breakdown in the Article 12 explainer and won't repeat it here.
The side-by-side.
| Dimension | SOC 2 | EU AI Act Article 12 |
|---|---|---|
| Who issued it | AICPA (US accounting standards body) | European Parliament and Council (Regulation (EU) 2024/1689) |
| Legal force | Voluntary, market-driven | Statutory; directly applicable in EU member states |
| What it audits | Organisational controls — how the organisation operates | Runtime behaviour — what the AI system actually did |
| Evidence type | Predominantly static — policies, screenshots, tickets, attestations | Predominantly runtime — event-level records produced by the system itself |
| Examiner | CPA firm of your choosing | National market surveillance authority (in the UK, the relevant sector regulator) |
| Cadence | Annual report; continuous monitoring optional | Records kept "over the lifetime of the system", minimum 6 months unless other law requires longer |
| Penalty for non-compliance | None directly — failure to obtain or maintain costs you customers | Up to €15M or 3% of global annual turnover (Article 99, breach of Article 12) |
| Public artefact | Audit report shared under NDA with customers | Logs disclosed to authorities on request; not generally public |
| Useful for an AI agent incident | Demonstrates you had a logging policy | Lets you (and the regulator) reconstruct what the agent actually did |
Why SOC 2 evidence does not satisfy Article 12.
Three structural reasons.
One. SOC 2 evidence describes the system; Article 12 evidence is the system's record of itself. A SOC 2 auditor accepts a screenshot of your Datadog dashboard as evidence that logging exists. An Article 12 examination requires the underlying event-level records of what each agent did, with integrity protection that survives an adversarial inspection.
Two. SOC 2 audits the policy; Article 12 audits the execution. A SOC 2 control statement might read: the company has a documented AI governance policy and reviews high-risk AI systems quarterly. An Article 12 inspection asks: show me every decision your loan-screening agent made about this individual in Q2 2026, and prove the records haven't been altered.
Three. SOC 2 is non-statutory. Article 12 is statutory. SOC 2 reports are useful in B2B sales because customers ask for them. Article 12 is required by law for high-risk systems in scope. The penalty regime in Article 99 (up to €15M or 3% of global turnover for Article 12 breaches) makes that distinction material.
Where they overlap — usefully.
They are not duplicative everywhere. Two areas of overlap are worth treating jointly:
- Access control to the audit log itself. SOC 2 requires controlled access to log stores. Article 12 implicitly requires that records cannot be altered retrospectively. A hash-chained audit log with role-segregated access satisfies both — one engineering investment, two compliance regimes.
- Retention. SOC 2 expects you to retain logs in line with your documented retention policy. Article 12 sets a minimum of six months and a likely operational floor of seven years for regulated financial firms. Match the longest applicable retention to the most generous storage and you are covered for both.
- Data classification. SOC 2 cares that sensitive data is identified and protected. Article 12 evidence is more useful when each receipt carries data-class tags (PII, PCI, PHI, financial). The same classification system feeds both.
What "in scope" looks like in practice.
A mid-market UK fintech we spoke to during the validation phase of Agent Audit had the following posture, which is representative:
- SOC 2 Type II — yes, renewed annually. Drata-managed evidence, Big-Four auditor.
- UK GDPR / ICO — yes, registered controller and processor where relevant; DPIAs for AI use cases.
- FCA SYSC — yes, operational resilience baseline in place.
- EU AI Act Article 12 — nothing yet. AI agents in customer service and claims triage have been running for eighteen months with the application's normal LLM-call logs, captured in Datadog. No cryptographic integrity. No per-agent receipt. No machine-readable format an EU authority would accept as Article 12 evidence.
The SOC 2 work was load-bearing for B2B sales. It did not contribute, in a substantive way, to Article 12 readiness. The compliance officer's working assumption — that buying Drata had covered "the AI thing" — did not survive a thirty-minute conversation with their auditor.
The pragmatic position.
If you are running production AI systems likely to fall in Annex III and you sell to EU enterprise customers, you need both. SOC 2 unblocks enterprise sales today. Article 12 readiness avoids an enforcement conversation tomorrow. The two compliance budgets sit with the same person (CISO or DPO) but the work is genuinely different, and pretending otherwise costs time in procurement and risk in supervision.
The shape of the right answer:
- Inventory which of your AI systems are in scope for Annex III. If any of them touch credit, employment, education, essential services, law enforcement, migration or justice, you should assume in-scope and confirm with counsel.
- Continue the SOC 2 programme unchanged. It is not displaced.
- Add runtime agent logging that produces an Article-12-shaped record per system, retained for the longer of (your SOC 2 retention, Article 12 minimum, sectoral floor). Hash-chained, integrity-verifiable, in a format your supervising authority's analyst will accept.
- Put the runtime logging artefacts in the SOC 2 evidence vault too. They demonstrate the same controls SOC 2 was asking for, with more substance.
Where Agent Audit fits.
The reason we built Agent Audit is that nothing in the SOC 2 or observability tool universe ships an Article-12-shaped record by default. Datadog and Splunk capture HTTP-level events but don't capture agent-internal state. Drata and Vanta automate static controls but don't touch runtime. Langfuse and Helicone are dev observability for model performance — not regulator evidence.
Agent Audit is the runtime layer. SDK adapters for the major agent frameworks emit a hash-chained receipt for every action; the backend turns those receipts into machine-readable Article 12 packs; the verification CLI lets your auditor and the supervising authority re-run the integrity proof independently. SOC 2 keeps its place; the AI Act gets the runtime layer it needs.