A prospect sends you their vendor's SOC 2 Type 2, you log it in the diligence folder, and the AI question feels handled. It usually isn't. A SOC 2 report is one of the more dependable signals in vendor risk — but its assurance stops exactly at the boundary the vendor drew, and that boundary was almost never drawn around the model.
This matters more every quarter. The feature your stakeholders are nervous about — the copilot, the document summarizer, the agent that touches customer data — is frequently the newest thing the vendor shipped and the least likely to be inside an audit that closed months ago. The fix isn't to distrust SOC 2. It's to read it for what it is and run AI as its own diligence track.
- A SOC 2 report's assurance is bounded by the system description and the criteria selected. If the AI feature isn't in that boundary, it isn't covered — regardless of how good the report looks.
- "We're SOC 2 Type 2" is not the same statement as "our AI is governed, tested, and monitored."
- Model providers usually appear as carve-out subservice organizations — explicitly excluded from the report you're holding.
- Add a short, AI-specific question set to diligence and map the answers to the NIST AI RMF or ISO/IEC 42001.
01 / The gapThe assumption that quietly creates risk
The assumption is reasonable on its face: a vendor passed a rigorous, independent audit, so their systems — all of them — must be controlled. But a SOC 2 examination doesn't audit "the company." It audits a defined system against a set of criteria, over a defined window, within a boundary that the vendor's own management drew and the auditor tested against.
That boundary is the whole game. Two vendors can both hold a clean SOC 2 Type 2 and have completely different things inside the fence. When an AI feature lives outside it, the report is silent — and silence reads like assurance to a busy reviewer.
02 / The mechanicsWhat a SOC 2 report actually attests to
A SOC 2 is an attestation performed by a licensed CPA firm under the AICPA's standards, reporting on controls relevant to the Trust Services Criteria: Security (always included), and optionally Availability, Processing Integrity, Confidentiality, and Privacy. A Type 1 opines on whether controls were suitably designed at a point in time; a Type 2 opines on whether they operated effectively across a period — typically three to twelve months.
Three parts of the report decide whether the AI is covered, and none of them is the logo on the front:
- The system description — the vendor's own account of the boundaries: which products, environments, and components are in scope. Read this first.
- Subservice organizations — the third parties the vendor depends on, and how their controls are treated (more on this below).
- Complementary user entity controls (CUECs) — the controls the report assumes you are operating. They're the report's fine print, and they're often where the real obligations sit.
The cover tells you a vendor was audited. The system description tells you what was actually in the room.
03 / The blind spotWhere AI tends to slip out of scope
AI features fall outside SOC 2 scope through four ordinary, undramatic paths. None of them implies a vendor is hiding anything — they're a function of how audits and product timelines collide.
The feature shipped after the window closed
SOC 2 Type 2 reports look backward over a fixed period. A GenAI capability launched last month simply wasn't in the environment the auditor observed. The report is accurate and current — and silent on the thing you care about.
The AI runs on a third-party model
If the vendor calls a foundation-model API, that provider is a subservice organization. Under the common carve-out treatment, the provider's controls are deliberately excluded from the report you're reading. The vendor's SOC 2 says nothing about how the model host handles your prompts, outputs, or retention.
The AI pipeline is a separate environment
Training data stores, fine-tuning jobs, vector databases, and prompt-orchestration layers are frequently a distinct environment that the system description never folds in. The production app is audited; the machinery behind the AI feature is not.
The criteria selected don't reach AI behavior
A report scoped to Security and Availability says nothing about output integrity, data confidentiality in prompts, or whether AI-assisted decisions are reviewed. The behaviors that make AI risky — hallucinated outputs, prompt injection, data leakage through context — don't map neatly onto a Security-only scope.
"Our platform is SOC 2 Type 2 certified, including AI" deserves a follow-up, not a checkmark. Ask which report period the AI feature falls in, and whether the model provider is carved out. The honest answer is often "the core platform is in scope; the new AI module will be added next cycle" — which is fine to hear, as long as you actually hear it.
04 / The chainCarve-out vs. inclusive: your model provider matters
When a vendor relies on a subservice organization — a cloud host, a model provider — the report handles it one of two ways. The difference decides whether you've actually seen the controls that protect your data.
| Treatment | What the report does | What it means for you |
|---|---|---|
| Carve-out method | The subservice organization's controls are excluded from the description and from the auditor's testing. | You must obtain and read the model provider's own report to gain any assurance over them. The vendor's SOC 2 covers only how the vendor manages the relationship. |
| Inclusive method | The subservice organization's relevant controls are folded into the description and tested. | Rarer in practice, but it means the report you hold actually reaches the provider's controls. Confirm which model provider and which controls. |
In most real reports, the model host is carved out. So the practical takeaway is blunt: a vendor's SOC 2 almost never gives you assurance over the company running the model. If that model touches regulated or sensitive data, you need the provider's report too — and you need to know what the vendor does at the seam between them.
05 / The fixThe questions to add to vendor due diligence
You don't need a data-science team to close this gap — you need a short, specific question set that turns a vague "is the AI safe" into answerable items. Send these alongside the SOC 2 request, not after it.
- Is the AI feature inside the SOC 2 system description, and in which report period was it added?
- Which subservice organizations power the AI (model provider, hosting), and are they carved out or inclusive?
- How are prompts, outputs, and uploaded content handled, retained, and — critically — is any of it used to train or improve models?
- What change management governs model versions, system prompts, and guardrails when the provider updates the model?
- Is AI behavior logged and monitored, and can you produce evidence of human oversight or override for consequential decisions?
- Is there an AI-specific incident response path for prompt injection, data poisoning, output-integrity failures, and deepfake-enabled social engineering?
- Is the program aligned to the NIST AI RMF or working toward ISO/IEC 42001, and can they show adversarial testing mapped to MITRE ATLAS?
06 / The judgmentHow to weight what comes back
The goal isn't a perfect answer to every question — it's a clear picture and a defensible decision. A vendor that says "the AI module isn't in this year's SOC 2, but here's our NIST AI RMF mapping, our data-handling terms, and our model provider's report" is in good shape. A vendor that can't tell you where the AI sits relative to the audit, or who runs the model, is telling you something too.
Where AI touches regulated data, treat it as its own assurance layer rather than a footnote to the SOC 2. The cleanest path is to pair the vendor's attestation with an AI governance answer — and to hold your own AI vendors to the same standard you'd want a regulator to find you holding.
07 / Bottom lineSOC 2 is a floor, not a ceiling
A SOC 2 report is worth having and worth trusting — inside its scope. The mistake is letting the report's authority spill over a boundary it never claimed to cover. Read the system description, find the subservice organizations, check the CUECs, and put AI on its own track. Done that way, "they have a SOC 2" becomes the start of the conversation about their AI, not the end of it.