Trust Services Criteria for AI Providers
The one-paragraph answer
SOC 2 AI compliance is how service organizations providing AI services demonstrate control effectiveness to customers. SOC 2 is an AICPA reporting framework covering five Trust Services Criteria: security, availability, confidentiality, processing integrity, and privacy. AI service providers routinely need SOC 2 reports to sell to enterprise customers. AI customers use SOC 2 reports as vendor diligence evidence. But SOC 2 does not address AI-specific risks, so it is necessary but not sufficient.
AI service providers face SOC 2 demands from every enterprise buyer. AI customers face vendor risk questions about their AI providers' SOC 2 reports. Companies on both sides need to understand what SOC 2 covers, what it does not cover, and how it interacts with AI-specific governance.
Protection against unauthorized access. Includes access controls, encryption, monitoring, incident response. Applies to AI systems handling customer data.
Systems operate as committed. Applies to AI service uptime and business continuity.
Information designated as confidential is protected. Applies to customer data used in AI training or inference.
System processing is complete, valid, accurate, timely, and authorized. AI processing integrity is nuanced: outputs may be probabilistic rather than deterministic.
Personal information is handled per commitments and privacy principles. Applies to AI processing personal data.
Algorithmic bias, model interpretability, training data provenance, and AI ethics are not directly addressed by the standard Trust Services Criteria. Some AI providers add supplemental criteria or issue separate AI attestation reports to address these.
Enterprise procurement demands SOC 2. AI providers who cannot produce one lose deals. AI customers who accept AI vendors without SOC 2 assume unmitigated risk. Both sides need the framework.
The academic literature on SOC 2 AI is ahead of most corporate practice, and it is unusually blunt. Two findings are worth putting in front of any executive who thinks this is a compliance formality.
“it remains challenging for practitioners to identify the harmful repercussions of their own systems prior to deployment”
That is the gap between having AI and governing it. The second finding is the one that tends to change the room.
“Only 3.6% of approvals reported race/ethnicity, 99.1% provided no socioeconomic data.”
Neither of these is a fringe position. Both come from peer-reviewed work, and both describe the condition most organisations are actually in when the question about SOC 2 AI arrives from the board, the buyer, or the regulator.
This is the sequence that works, and it is not the sequence most organisations choose. They start with the framework and work backwards toward reality. Start with reality.
Done in this order, SOC 2 AI becomes tractable. Done out of order, it becomes a document nobody uses and a control nobody exercises.
Type II is expected for mature providers. Type II covers control operation over a period (typically 6-12 months).
No. SOC 2 covers information security and privacy. ISO/IEC 42001 adds AI-specific management. Enterprise buyers increasingly ask for both.
The AI Vendor Risk Inventory™ from Volume III of The Operating Discipline for AI Library™ incorporates SOC 2 evaluation as part of AI vendor diligence.
A Type II report tells a buyer that an independent auditor tested the provider's controls over a period and found them operating effectively. For an AI vendor, that is genuinely valuable: it means customer data is access-controlled, encrypted, monitored, and handled under a real incident process. What it does not tell the buyer is anything about the model. SOC 2 AI reports are silent on bias, silent on drift, silent on training data provenance, and silent on whether the AI does what the vendor claims.
Of the five Trust Services Criteria, processing integrity is the awkward one for AI. It asks whether processing is complete, valid, accurate, timely, and authorised. A deterministic system either computes correctly or it does not. A probabilistic system produces a distribution, and "accurate" becomes a question of tolerance rather than correctness. Vendors and auditors are still working out what evidence satisfies this criterion for a model, and buyers should read that section of the report carefully rather than assuming it means what it would mean for a payments platform.
If you are buying AI, a SOC 2 AI report is necessary and not sufficient. Ask additionally for model documentation, bias evaluation results, a description of training data sources, a statement of known limitations, and the vendor's incident history specific to model behaviour. A vendor who has a clean SOC 2 and cannot answer those questions has proven their security, not their AI.
The authoritative texts and agency pages behind this summary. We keep this page current, but where a compliance decision turns on exact wording, read the source. Anything concerning SOC 2 AI that carries legal consequence should be confirmed against the enrolled text or the issuing body, not against a secondary summary, including this one.
The AI Business Enablement Audit™ measures your organization against every framework in this library, including SOC 2 and AI, and delivers a defensible governance dossier. Start or finish your audit below.
Start or finish your AI Audit →