SOC 2 Type II is the de-facto baseline for US B2B AI vendors and for enterprise IT functions providing AI services internally. Customer procurement increasingly treats SOC 2 evidence as table-stakes, not as a differentiator, but as a precondition for doing business.
The Trust Services Criteria (TSC) that drive SOC 2 audits cover Security, Availability, Processing Integrity, Confidentiality, and Privacy. They were originally designed for general service organizations, but they apply to AI workloads with specific operational implications. This article walks through what SOC 2 auditors actually examine when AI is part of the audit scope.
How SOC 2 scope applies to AI
SOC 2 scope is defined by the service being audited. If the service involves AI, generative AI, predictive models, AI-powered analytics, AI agents, the AI components are in scope. Auditors will examine the AI components against the relevant Trust Services Criteria.
Scoping decisions matter. An enterprise providing an AI-powered platform must scope the AI components in. An enterprise that uses AI internally to support a non-AI service may have a tighter scoping discussion. Either way, the scoping decision needs to be deliberate and documented, not avoided.
Security TSC applied to AI
Security is the foundational TSC and is in scope for every SOC 2 engagement. For AI workloads, auditors examine:
● Access controls for AI training data, model weights, deployment pipelines, and inference endpoints
● Authentication and authorization for users of AI systems, including API consumers
● Encryption of AI training data, prompts, and outputs in transit and at rest
● Vulnerability management covering AI-specific concerns, prompt injection defenses, model security, API protections
● Change management for AI systems, model updates, prompt changes, RAG knowledge base modifications
● Incident response covering AI-specific incidents, model failures, prompt injection events, data leakage through AI
Availability TSC applied to AI
Availability covers the operational uptime and reliability of the audited service. For AI workloads, this includes, foundation model vendor SLAs and contingencies if a vendor is unavailable, internal AI infrastructure availability (model serving, vector databases, RAG retrieval), capacity planning for AI workloads with bursty demand patterns, disaster recovery for AI systems including model artifacts and training data.
AI availability is operationally different from traditional service availability. Foundation model vendors have outages. Inference costs scale non-linearly. Capacity planning for AI is genuinely harder than for traditional services. SOC 2 auditors increasingly understand this and probe for evidence that the auditee does too.
Processing Integrity TSC applied to AI
Processing Integrity is where AI workloads create novel audit considerations. The TSC asks, does the service process data completely, accurately, validly, in a timely manner, and as authorized?
For AI workloads, this raises specific questions. Hallucination, when AI generates incorrect output, is the service still processing accurately? Bias, when AI produces systematically different outputs for different populations, is the processing valid? Model drift, when AI performance degrades over time, is processing integrity maintained? Auditors are developing methodology to evaluate these, and enterprises with mature AI workloads are getting ahead of the questions by building processing integrity controls (bias testing, hallucination monitoring, drift detection) into their AI operations.
Confidentiality TSC applied to AI
Confidentiality covers protection of information designated as confidential. For AI workloads, this matters specifically around, prompts that may contain confidential customer information, RAG knowledge bases that may contain proprietary content, model training data, and generated outputs that may contain or leak confidential information.
Common findings in this area include, prompts logged to vendor systems without confidentiality controls, RAG knowledge bases ingesting confidential data without classification, training data flowing to vendor environments without contractual confidentiality protection.
Privacy TSC applied to AI
Privacy covers the collection, use, retention, disclosure, and disposal of personal information. For AI workloads, this connects to, consent for AI training on personal data, data minimization in AI systems, retention policies for AI training data and inference logs, and individual rights (access, correction, deletion) over personal data in AI systems.
The intersection with federal sector privacy (HIPAA, GLBA, FERPA) and state privacy (CCPA, CPRA, Virginia, etc.) means that Privacy TSC evidence often serves multi-regime compliance simultaneously, well-designed privacy controls satisfy SOC 2, state privacy law, and federal sector privacy in one architecture.
Integration with NIST AI RMF
SOC 2 and NIST AI RMF are highly complementary. NIST AI RMF organizes risk management around Govern, Map, Measure, Manage. SOC 2 evaluates the operating effectiveness of controls. Enterprises that adopt NIST AI RMF as their operating spine generate, as a byproduct, much of the evidence base SOC 2 auditors need.
The right architecture treats SOC 2 and NIST AI RMF as one program, same AI inventory, same risk classification, same control framework, same governance committee, with SOC 2 providing the external audit overlay on top. This is operationally far simpler than running them as separate workstreams.
Common SOC 2 audit findings for AI workloads
● Vendor management gaps, foundation model contracts signed without security review, no contingency planning, no documented vendor risk assessment
● Incomplete AI inventory, auditor finds AI workloads in scope that the auditee did not know were in scope
● Prompt logging to vendor systems without classification of what's being logged
● No bias testing methodology, or testing performed once but not maintained
● Generative AI rolled out broadly without acceptable use policy enforcement
● Incident response runbooks that do not cover AI-specific incident types
The shift to make
Stop treating SOC 2 as an annual scramble where evidence is collected six weeks before the audit.
Start treating it as the ongoing operating discipline that the audit confirms after the fact. For AI workloads specifically, build SOC 2 readiness and NIST AI RMF maturity as one program, with continuous evidence generation and continuous control operation. The audit becomes a confirmation, not a panic.
Enterprises that operate this way pass SOC 2 audits without drama, ship new AI capabilities faster because the governance fabric is already in place, and use SOC 2 Type II evidence as a sales asset rather than a cost center.
