SOC 2 for an AI Product
5 min read · updated August 3, 2026
SOC 2 is not a certification, not a pass mark, and not a property of a product. It is an auditor’s report on whether the controls you described were suitably designed and, in a Type II, operating over a period. Adding a model provider to your architecture does not change the framework; it changes your system boundary and the evidence you have to produce about it.
Engineering guidance rather than legal or assurance advice — an auditor scopes an engagement, and nothing here substitutes for that conversation. What follows is the part you can prepare before it.
What a SOC 2 report is, precisely
The report is against the Trust Services Criteria. Security is the common set; availability, processing integrity, confidentiality and privacy are added by choice depending on what you commit to customers. A Type I looks at design at a point in time; a Type II looks at operating effectiveness across a window, and it is the one buyers usually mean.
Two consequences follow and both are worth stating internally before anyone starts. The report describes your system and your controls, so a vendor’s report is never evidence about you. And because you write the system description, scope is a decision — an unhelpfully narrow scope produces a report customers will not accept, and an over-broad one produces an audit you cannot pass.
The system boundary, with a model in it
The interesting question for an AI product is how the model provider appears in the description. It is not part of your system, but your service depends on it, which is the classic sub-service organisation situation. There are two established ways to handle that, and the choice has real consequences:
| Approach | Description |
|---|---|
| Carve-out | The sub-service organisation's controls are excluded from your description, and you disclose the dependency. You must still show you monitor the vendor — which is why vendor review evidence matters even under a carve-out. |
| Inclusive | The sub-service organisation's relevant controls are brought inside the scope of your report. Rare for a large model vendor, because it requires their cooperation with your audit. |
| Complementary controls | Controls the report assumes somebody else operates. Read your vendors' reports for these — they are the assumptions that quietly become your responsibility. |
In practice most AI products carve out their model providers and lean on vendor management as the control. That makes the vendor review process — the DPA, the sub-processor list, the annual re-check — into audit evidence rather than paperwork, which is a good reason to run it properly whatever your assurance plans are.
Evidence an AI system has to produce
Nothing in the criteria is AI-specific. What is AI-specific is which of your controls become hard to evidence once a model is in the path:
- Data flow documentation. You need a current description of what leaves your system, to whom, and under what terms. Every other page in this cluster is about building that; here it is simply an artefact somebody will ask to see.
- Confidentiality of prompt content. If you commit to confidentiality, the commitment covers text you forward to a third party. The evidence is the contractual position plus the technical controls — redaction, log exclusion, access restriction — actually operating.
- Access to production conversations. Who at your company can read customer prompts, through which tool, and what record exists of them doing so. Debugging access to a conversation store is the control most often missing in an AI product, because it grew organically out of a support workflow.
- Vendor monitoring. Evidence that you re-review your model providers on a defined cadence and act on changes. A dated sub-processor diff and a ticket beat an assertion.
- Availability of a dependency you do not control. If you include availability, expect to explain what happens when a provider degrades — fallback routing, timeouts, degraded modes — because “we depend on them” is a risk, not a control.
Prompts and models are changes
The most common gap in an AI product’s control set is change management, because two things that materially alter system behaviour usually sit outside it. A system prompt edited in a dashboard changes what the product does to every customer with no review, no diff and no rollback. A model version or routing rule changed by configuration does the same.
Both should be in version control, both should be reviewed like code, both should be releasable and revertible, and each release should be identifiable in your logs so that a change can be tied to the behaviour it caused. This is worth doing on its engineering merits alone; that it also happens to be the evidence somebody asks for is a bonus rather than the reason.
When a customer asks you for one
If you do not have a report, say so plainly and say what you do have: the controls that exist, the documentation, the DPA, the sub-processor list, and the timeline if there is one. Buyers deal with pre-audit vendors constantly and a clear negative answer costs far less than a vague one.
What costs a great deal is implying an audit that has not happened — a badge, a status page phrase, a certificate number in a sales deck. It is the single easiest claim in this entire field for a customer to verify and the hardest to recover from being caught on. If you are asked for something you do not have, the answer is the date you expect to have it.