SOC 2 for AI Systems: What Auditors Actually Test in 2026

If you've searched "does SOC 2 cover AI" expecting a clear answer, here's the honest one: there is no dedicated "SOC 2 for AI" standard. The AICPA hasn't published AI-specific Trust Services Criteria, and as of early 2026, its closest related guidance is a narrow document about AI use in forensic and valuation services, explicitly labeled "neither authoritative guidance nor standards," and unrelated to SOC 2 engagements at all.

And yet, if your company touches AI in any meaningful way, your next SOC 2 Type II audit almost certainly will not look like it did two years ago. Here's what's actually happening, and what auditors are asking for in practice.

The Short Version

SOC 2 audits still run against the same five AICPA Trust Services Criteria they always have: Security (the Common Criteria), Availability, Processing Integrity, Confidentiality, and Privacy. Nothing about that structure has changed. What's changed is how AI-fluent auditors interpret those existing criteria when your system includes models, training data, or autonomous agents, and increasingly, that interpretation asks for evidence traditional SaaS audits never required.

What Auditors Are Actually Asking For

Based on 2026 engagement patterns, AI-aware auditors are consistently requesting evidence in a few specific categories, mapped mostly onto the existing Security criterion (particularly CC6, CC7, and CC8):

• Model lineage. For a given deployed model, can you produce the exact training dataset, code, and approval chain behind it?

• A model registry. A system of record (MLflow, Weights & Biases, or a custom equivalent) tracking every model promoted to production: version, training run, evaluation metrics, approver, and deployment timestamp.

• Prompt and inference logs, with PII redaction already applied before logging, not redacted after the fact.

• Drift-monitoring output. Evidence that you're tracking when a model's outputs diverge from expected behavior over time, not just that the model was validated once at launch.

• Vendor risk assessments for every third-party LLM you call. If you integrate OpenAI, Anthropic, or any other model provider, auditors increasingly expect the same vendor due diligence you'd apply to any other subprocessor.

• Documented, tested rollback procedures. Not a runbook that's never been exercised, evidence of an actual rollback that was run.

• Tagging discipline connecting any production inference back to the exact model version that produced it.

Where This Shows Up in the Actual Criteria

None of the above is a new, separate control category. It's existing Trust Services Criteria language, reinterpreted:

A SOC 2 auditor still doesn't evaluate your algorithm's quality, that's never been in scope, and it isn't now. What they evaluate is whether your internal controls address AI-specific risk (training data poisoning, model theft, performance drift, prompt-injected data leakage) using the same control language they'd apply to any other system risk.

The Agentic AI Wrinkle: Accountability

If your product includes AI agents that take autonomous action, there's a specific issue auditors are flagging that's worth knowing before your next audit, not during it: SOC 2's Common Criteria expect privileged actions to be attributable to an accountable individual. An action initiated by an autonomous agent, with no human request behind it, doesn't naturally fit that expectation, and auditors are treating "no identifiable human accountable for this action" as a real accountability gap under CC6.1 and CC6.2, not a technicality to wave past.

Practical implication: if an agent in your system can take a privileged action (modifying data, calling a sensitive API, approving a transaction), you need a documented answer for who is accountable for that action, and it can't simply be "the agent."

Why the AICPA Hasn't Formalized This Yet

This isn't an oversight. The AICPA's Trust Services Criteria are deliberately written as principles rather than prescriptive technical checklists, which is exactly what's letting auditors extend them to AI risk without waiting for a formal rewrite. The tradeoff is that what counts as sufficient "AI evidence" currently varies by auditor and firm, since it's being assembled from practitioner consensus rather than a single published standard. Expect more formal guidance eventually, the same way SOC 2 guidance has evolved before, but treat what's in this article as current practitioner-driven expectation, not codified AICPA doctrine.

How This Relates to ISO 42001 and the EU AI Act

If you're already tracking AI governance requirements under ISO 42001 or the EU AI Act, there's real overlap worth knowing about: model lineage documentation, risk assessments, and human oversight requirements show up in some form across all three. Work you've done for one rarely needs to be duplicated from scratch for the others, though the specific evidence format each expects still differs.

How DSALTA Helps

DSALTA doesn't perform your SOC 2 audit, that's your AICPA-licensed CPA firm's role. What DSALTA helps with is exactly the gap this article describes: since AI-specific SOC 2 evidence isn't formally standardized, it's easy to walk into an audit unsure of what your specific auditor will ask for. DSALTA helps you maintain model registry evidence, vendor risk assessments for your LLM providers, and access control documentation continuously, so it's ready regardless of which specific AI evidence your auditor prioritizes.

Frequently Asked Questions

Is there an official "SOC 2 AI" certification? No. SOC 2 remains a single attestation against the five existing Trust Services Criteria. There's no separate AI-specific report type or certification track.

Do I need a SOC 2 report if my product is AI-native? The same standard applies as for any SaaS company: if enterprise buyers require SOC 2 before signing, you need it. AI-native products aren't exempt, and in practice, enterprise buyers evaluating AI vendors are often more cautious about security posture, not less.

What happens if my auditor doesn't ask for AI-specific evidence? Requirements currently vary by auditor, since there's no formal AICPA standard mandating it. That said, the trend is clearly toward more AI-fluent auditors requesting this evidence, and having it ready regardless of whether it's requested puts you ahead for your next audit cycle.

Does using third-party AI models (like OpenAI's API) change my SOC 2 scope? Yes, in practice. Auditors increasingly expect the same vendor risk assessment process you'd apply to any subprocessor, applied to your AI model providers specifically.

How is this different from getting AIUC-1 certified? SOC 2 is a general attestation across your whole organization's controls, with AI risk interpreted within existing criteria. AIUC-1 is a dedicated, AI-agent-specific certification built entirely around agent risk from the ground up. They're not substitutes for each other, some organizations pursue both.