SOC 2 for AI Systems: The Controls Your Auditor Is Already Asking About

SOC 2 has not been rewritten for AI. The Trust Services Criteria — security, availability, processing integrity, confidentiality, privacy — are the same ones they have been for years. What has changed is the questions auditors are asking under those criteria when an AI system is in scope.

The questions are not new. The answers most organizations have prepared do not address them.

Processing integrity, suddenly interesting

Processing integrity has historically been one of the quieter criteria. For most audits it reduced to "input validation is in place, transformations produce the expected output, errors are handled." Calendar logic, currency conversions, report generation. Important but not a site of active scrutiny.

AI systems have made processing integrity loud.

When an AI system is part of the processing path, "produces the expected output" becomes a much harder claim to support. The output is nondeterministic by design. The system can generate content that is plausible but incorrect. The auditor's natural question — "how do you know the output is right?" — has a much more complex answer than for a deterministic pipeline, and your existing evidence probably does not address it.

What tends to satisfy the question: output validation specific to the AI stage (not just the surrounding code), evaluation metrics captured over time, human-in-the-loop checkpoints for outputs above a risk threshold, and documented criteria for when the system is allowed to act on its own output versus when a review is required. Without these, "processing integrity" for the AI component reduces to "we trust the model," which does not survive scrutiny.

Confidentiality and the prompt

Confidentiality is where the AI-specific questions get sharpest. Where does the prompt go? Where does the output go? What is retained at the provider? What is sent as part of the prompt that would otherwise never leave our boundary? Who at the provider can access it?

Most organizations have not traced the data flow of a single AI interaction end-to-end. The prompt assembly happens in application code, pulls from a database, includes user input, gets decorated with context, and is shipped to an external API. Each of those steps is an opportunity for data to appear in the prompt that confidentiality controls would not have allowed to leave the boundary otherwise.

The auditor's question is "show me a data flow diagram for a representative AI interaction." The answer exists — it has to, because the system works — but it is rarely written down. Writing it down is the work. Once written, the controls that need to be attached to it become obvious.

Security at the agent boundary

For agentic systems, security audit scope expands to cover the agent's authority envelope. The auditor will ask: what can this agent do, what credentials does it hold, how is it authorized to act, how is its activity logged, how would you detect misuse.

Answers that work for a human user — "they log in, their actions are logged, we review the logs" — do not translate cleanly. The agent is usually not "logging in" in any meaningful sense. Its credentials are usually long-lived. Its action logs are usually mixed in with application logs. Misuse detection is usually aspirational.

Closing this gap is not theoretical work. It is a concrete list: per-session credentials for agents, structured action logs keyed by session, scope boundaries enforced at the API layer not in the prompt, a review surface that distinguishes agent-originated actions from human-originated ones. The list is not long, but it is almost never complete in AI deployments that were built before the team internalized it as a requirement.

What this adds up to

SOC 2 for AI systems is not a new framework. It is the existing framework applied rigorously to a new technology class, by auditors who are no longer accepting "it's AI, it's different" as a reason for missing evidence.

The work is recognizable. The teams that treat their AI systems as ordinary software — with ordinary controls, ordinary data-flow documentation, ordinary logging and review — will pass. The teams that have deployed AI as a black-boxed capability outside their standard control framework will fail, or will scramble to pass, and their remediation work will be substantial.

The smart move is to do the work before the audit makes you. It is the same work either way.