What Does SOC 2 Actually Require When You're Building With AI?

You’re building with AI, you’re heading toward SOC 2, and you’ve quietly convinced yourself the two don’t really intersect. SOC 2 was written before the current AI wave, there’s no “AI control” in the framework, so surely your model usage just rides along under your existing controls. Right?

That assumption is exactly how teams walk into avoidable findings. SOC 2 doesn’t have an AI clause, and that’s the point: the Trust Services Criteria, the control criteria established by the AICPA’s Assurance Services Executive Committee, apply to your AI systems with no carve-out and no special treatment. The framework is principles-based. It asks whether you have controls over the five criteria: security, availability, processing integrity, confidentiality, and privacy. The moment AI touches customer data, every one of those questions now includes your AI stack, whether or not you’ve thought about it that way.

The good news is that none of this is exotic. SOC 2 for AI is the same discipline you already owe for any system, pointed at a data flow most teams simply forgot to map. Here’s what your auditor will actually expect.

SOC 2 Is Principles-Based, Which Means AI Is Already In Scope

SOC 2 evaluates your controls against the Trust Services Criteria, with Security (the Common Criteria) mandatory and Availability, Confidentiality, Processing Integrity, and Privacy added based on what you commit to. Crucially, scope is defined by your system, the people, processes, data, and technology that deliver your service. If an LLM is in that system and customer data flows through it, it’s in scope. Full stop.

This catches teams off guard because there’s no checklist item that says “configure your AI.” Instead, the existing criteria apply with full force. An auditor doesn’t need an AI-specific rule to flag your AI risk; they apply the same controls you’d expect for any vendor that processes your data, and discover you never applied them to your model provider. A Type I report assesses whether your controls are designed well at a single point in time, while a Type II report, the one enterprise buyers actually want, tests whether those controls operated effectively over an observation period that typically runs 3 to 12 months. That observation window is why bolting controls on at the last minute doesn’t work: you need evidence of the control running over time.

Your LLM Provider Is a Subprocessor. Treat It Like One.

This is the single most overlooked requirement. When you send customer data to an external model API, that provider is now a subprocessor handling data you’re responsible for. SOC 2’s vendor management criteria apply directly, and auditors are increasingly specific about it.

What you need in place:

• A vendor inventory that includes your AI providers. If your model API isn’t on the same list as your cloud host and your payment processor, that’s a gap. List every AI service in the data path.
• Due diligence on each provider. Review their security posture, ideally their own SOC 2 report or equivalent. You’re inheriting their controls; you need evidence they have them.
• A data processing agreement (DPA). A contract governing how the subprocessor handles your data, including data residency and breach notification.
• Training and retention configuration, documented. Most enterprise AI APIs offer a setting to exclude your data from model training and to control retention. Confirm it’s enabled, and keep evidence that it is. “We assumed they don’t train on it” is not a control.
• Subprocessor disclosure to your customers. If your own commitments require it, your AI providers belong on the subprocessor list you publish.

The principle: you can outsource the processing, but you cannot outsource the accountability. Your auditor will ask who touches customer data, and “an AI vendor we never formally assessed” is a finding waiting to happen.

Data Handling: Know Exactly What You Send and Where It Goes

Confidentiality and Privacy criteria turn on how data moves through your system, and AI adds a flow most data maps never captured: the prompt path. Every prompt you send to a model may contain customer data, and every completion you store is data you now hold.

Map it explicitly:

• What data enters prompts. Are you sending PII, confidential business data, or regulated records to the model? If so, that path needs the same encryption-in-transit, access control, and minimization you apply everywhere else.
• Data minimization at the prompt boundary. Send the model only what the task requires. Redact or tokenize sensitive fields where you can. The less sensitive data crosses into the AI provider, the smaller your confidentiality exposure.
• Where outputs land. Model completions stored in logs, databases, or vector stores are customer data subject to the same retention and access controls as any other store. A vector database full of embedded customer documents is in scope.
• Tenancy and leakage. If you use retrieval or shared memory, prove that one customer’s data can’t surface in another’s session. Cross-tenant leakage is a confidentiality failure regardless of how it happens.

The data flow diagram you build for SOC 2 must show the AI path. If your current diagram stops at “calls external API” without specifying what data crosses that line, you haven’t finished the work.

Change Management Now Covers Models and Prompts

SOC 2’s change management criteria exist so that changes to your production system are authorized, tested, and traceable. With AI, the things that change your system’s behavior expand beyond code, and most teams haven’t extended their change control to cover them.

These are change-management events even though no application code moved:

• Switching or upgrading the underlying model. A new model version can change outputs, costs, and risk profile. It should go through review, not get swapped silently.
• Modifying system prompts. Your system prompt is effectively configuration that governs behavior and safety. Changes to it belong under version control and review, with a record of who changed what and why.
• Updating RAG sources, tools, or agent permissions. Changing what data the model can retrieve or what actions an agent can take materially alters your security posture.

Treat prompts, model selections, and tool configurations as version-controlled, reviewed artifacts. If a single edit to an untracked prompt can change what your production system does, your change management is incomplete, and an auditor sampling your changes will find the gap.

Logging, Monitoring, and Evidence

SOC 2 is, in practice, an evidence exercise. You don’t just need controls; you need to prove they ran over the observation period. AI systems demand a specific logging discipline that many teams skip.

Log what you’ll be asked to produce:

• Access to AI systems. Who can invoke the model, change prompts, or view stored completions, and an audit trail of that access.
• AI interactions for sensitive operations. Where the model drives a consequential decision or action, log the inputs, the outputs, and the action taken, enough to reconstruct what happened and why.
• Anomalies and abuse. Monitoring for unusual usage, potential prompt-injection attempts, and cost or rate spikes that signal misuse.

For Processing Integrity, if your AI produces outputs customers rely on, you need evidence those outputs are handled correctly, with appropriate human review and error handling where the stakes warrant it. The throughline across every criterion is the same: collect the evidence continuously, because a Type II auditor samples across the whole window and you can’t manufacture history retroactively.

Timeline, Cost, and Where to Start

Set realistic expectations. From a reasonably mature starting point, a first SOC 2 Type II generally takes a few months to readiness plus the observation window, which itself runs 3 to 12 months. Total cost depends heavily on your starting maturity and the scope you commit to; budget for a compliance automation platform, readiness work, and the auditor’s fee, and get quotes rather than relying on a rule-of-thumb number. If you’re starting from scratch on controls, or retrofitting them onto an AI system you shipped without them, expect the longer end on both time and money.

Practical sequence:

1. Add your AI providers to your vendor inventory and confirm DPAs and no-training settings are in place with documented evidence.
2. Draw the real data flow, including exactly what customer data crosses into prompts and where outputs are stored.
3. Bring prompts, model choices, and agent permissions under change management and version control.
4. Stand up AI access logging and monitoring now, so you accumulate the evidence the observation window requires.
5. Scope deliberately with your auditor, and only commit to the Trust Services Criteria you can actually support.

At Particle41, when we build AI systems for teams heading toward SOC 2, we treat these controls as part of the architecture from the first sprint, AI providers in the vendor process, prompts under version control, the data path mapped, and logging wired in, so readiness is something you grow into rather than scramble for. SOC 2 with AI isn’t a new rulebook. It’s the discipline you already owe, applied to the one data flow you almost forgot to map. Map it early, and the audit becomes a formality instead of a fire drill.

Sources

1. 2017 Trust Services Criteria (With Revised Points of Focus – 2022) — AICPA & CIMA (the five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy)
2. SOC 2 Type 1 vs. Type 2: Timeline, Cost, and Key Differences — Drata (Type 1 point-in-time vs. Type 2 operating effectiveness over a 3-12 month observation period)