Most engineering teams that have been through a SOC 2 Type II audit understand the process for traditional SaaS systems: define your controls, operate them consistently for the observation period, and produce evidence that they worked. Access management, change management, incident response, availability monitoring — the categories are familiar, the evidence is well-understood, and the auditor's sampling methodology follows predictable patterns.
Then the team ships an AI feature that makes decisions affecting customers — pricing adjustments, risk scoring, account actions, content moderation — and the next SOC 2 audit becomes a different conversation. The auditor asks questions that the existing control framework was not designed to answer: "How do you control changes to the logic that governs this AI system's decisions?" "Can you show me the authorization controls for what the AI agent is permitted to do?" "If this system made an incorrect decision on March 14th, can you reconstruct exactly why?"
This article explains what SOC 2 Type II means specifically for AI systems. It covers which Trust Services Criteria apply and how, what evidence auditors collect for AI decision-making systems, where the most common AI-specific control gaps appear, and how teams that have built deterministic decision infrastructure navigate the audit cleanly.
SOC 2 Type II: What the Audit Actually Requires
A SOC 2 Type II engagement evaluates whether an organization's controls related to security, availability, processing integrity, confidentiality, and privacy operated effectively over a defined period — typically six to twelve months. Unlike a Type I report, which evaluates control design at a point in time, a Type II report requires evidence that the controls were consistently applied throughout the observation window. An auditor is not checking that you have policies. They are checking that those policies were enforced, every day, for the entire period.
The AICPA Trust Services Criteria define five categories, each containing specific criteria that map to control objectives. Not every engagement includes all five categories — the organization selects which are in scope based on their service commitments. For AI systems, the category selection matters significantly because AI decision-making creates obligations across multiple categories that traditional application logic does not.
Which Trust Services Criteria Apply to AI Systems
Every SOC 2 engagement includes the Common Criteria (CC), which cover security. The remaining four categories — Availability (A), Confidentiality (C), Processing Integrity (PI), and Privacy (P) — are optional and selected based on the service description. For AI systems that make consequential decisions, the category selection should look different from a standard SaaS application.
Common Criteria (CC): Always in Scope
The Common Criteria cover the foundational security controls: access management, change management, risk assessment, monitoring, and incident response. For AI systems, the Common Criteria create three specific areas of focus that go beyond traditional application controls.
CC6 — Logical and Physical Access Controls: For a traditional web application, access controls mean who can log in, who can access production databases, and who can deploy code. For an AI system, access controls extend to the decision logic itself. Who can modify the rules that govern AI decisions? Who can change model configurations, prompt templates, or scoring thresholds? If an AI system can autonomously take actions — sending emails, modifying account status, adjusting pricing — does the system itself have access controls governing what actions it is authorized to take? Auditors examining AI systems under CC6 are looking for evidence that the AI's operational permissions are explicitly defined and enforced, not just that human users have appropriate access to the system's code.
CC7 — System Operations and Monitoring: Traditional monitoring controls focus on uptime, error rates, and performance. For AI systems, CC7 extends to monitoring the AI's decision behavior. Is the system producing decisions within expected parameters? Are there anomaly detection mechanisms for decision output distribution shifts? If the model begins producing significantly different decisions than its historical baseline — due to model drift, data distribution changes, or configuration errors — is that detected and flagged?
CC8 — Change Management: This is where most AI-specific audit findings originate. Traditional change management controls govern code deployments: code review, testing, approval gates, and deployment procedures. AI systems introduce at least three additional change vectors that CC8 controls must cover: changes to the underlying model (retraining, fine-tuning, model swaps), changes to the decision rules or policy logic governing the model's outputs, and changes to the data inputs or feature pipelines that feed the model. Each of these change vectors can alter the system's decision behavior. If any of them can change without documented approval and testing, the change management controls have a gap.
Processing Integrity (PI): The Critical Category for AI Decisions
Processing Integrity is the Trust Services Category most directly relevant to AI decision systems, and it is the one most frequently excluded from SOC 2 scope for traditional SaaS products. That exclusion becomes problematic when the system starts making consequential automated decisions.
PI criteria require that system processing be complete, valid, accurate, timely, and authorized. For an AI decision system, each of these terms maps to a specific technical requirement:
| PI Attribute | Traditional SaaS Meaning | AI Decision System Meaning |
|---|---|---|
| Complete | All transactions are processed | Every decision-triggering event generates a decision record; no silent decisions |
| Valid | Input validation, data integrity checks | Decision inputs are typed, validated, and within expected ranges before evaluation |
| Accurate | Calculations produce correct results | Decision logic produces the outcome specified by the governing rules for the given inputs |
| Timely | Processing completes within SLA | Decisions are made within the temporal window where they are valid and actionable |
| Authorized | Users have permissions for their actions | The AI agent has explicit authorization for the actions it takes; authority boundaries are enforced |
ISACA's guidance on SOC 2 for AI systems recommends that any organization operating AI systems that make or substantially influence decisions affecting customers, data, or financial outcomes should include Processing Integrity in their SOC 2 scope. Excluding it leaves the most audit-relevant category of AI behavior outside the report's coverage.
Availability (A): Relevant When Decisions Are Time-Sensitive
If the AI system's decisions are time-sensitive — fraud detection that must evaluate transactions in real time, pricing decisions that must be computed within a response window, risk assessments that gate customer-facing workflows — then Availability criteria apply not just to the application's uptime but to the decision system's responsiveness. A system that is "up" but whose decision layer is degraded or timing out is not meeting its availability commitments for the purposes of the decisions it is supposed to make.
Confidentiality (C) and Privacy (P): AI-Specific Data Considerations
AI systems often process, aggregate, and make inferences from data in ways that traditional application logic does not. Confidentiality controls need to account for the data flowing through decision pipelines, including model training data, feature stores, and decision trace records. Privacy controls need to address whether the AI system's decision inputs include personal data, whether decision outputs constitute personal data processing, and whether decision traces create additional personal data stores that must be governed under applicable privacy frameworks.
What Auditors Actually Collect as Evidence for AI Systems
SOC 2 Type II auditors work by sampling. They select a sample of events during the observation period and request evidence that the stated controls operated for those events. For AI systems, the auditor's evidence requests fall into four categories that map to the Trust Services Criteria.
Evidence Category 1: Change Management Records
The auditor will ask for the change history of the AI system during the observation period. This includes code deployments, model updates, rule changes, configuration modifications, and any other changes that could alter the system's decision behavior. For each change, they expect to see: a documented change request, evidence of review and approval, testing results prior to deployment, and a deployment record with timestamp and responsible party.
For AI systems, this evidence request extends beyond code changes. If the team modified a scoring threshold, updated a prompt template, changed a model version, or adjusted a decision rule during the observation period, the auditor expects to see the same level of change documentation. The most common finding here is that teams have rigorous change management for code deployments but no documented change process for model configurations, decision rules, or prompt changes — all of which can alter the system's decision behavior as significantly as a code change.
Evidence Category 2: Access Control Logs
The auditor samples access control events: who accessed production systems, who modified configurations, who deployed changes. For AI systems, the access control scope must include access to the decision logic layer — the rules, policies, or configurations that govern what the AI system is authorized to decide and do. If the AI system itself operates with service accounts or API credentials that grant it access to external systems (sending emails, modifying databases, calling third-party APIs), the auditor expects to see that those credentials are scoped to the minimum necessary permissions and that changes to those permissions are documented.
Evidence Category 3: Monitoring and Alerting Records
The auditor reviews whether monitoring and alerting operated during the observation period. For AI systems, this includes evidence that the team monitors not just system health metrics (uptime, latency, error rates) but also decision behavior metrics: decision volume trends, outcome distribution, rule evaluation patterns, and anomaly detection for unexpected shifts in decision outputs. If the monitoring detected anomalies during the observation period, the auditor expects to see incident records showing how the team responded.
Evidence Category 4: Decision Records (The AI-Specific Gap)
This is where AI systems most commonly fail to satisfy auditor expectations. The auditor selects specific decisions from the observation period and asks the team to demonstrate that the decision was produced by the documented control process. For a traditional application, this is straightforward: the code that processes the transaction is in version control, the deployment record shows which version was running, and the application log shows the transaction was processed.
For an AI system, the equivalent evidence chain is more complex: the auditor needs to see which decision rules were active at the time, which version of the model produced the recommendation, what inputs were evaluated, and how the decision outcome followed from those rules and inputs. If the team cannot produce this evidence chain — because the decision logic was embedded in a prompt that was not version-controlled, or because the system did not capture the inputs evaluated at decision time — the auditor documents a control gap.
The "AI Black Box" Objection and How Decision Traces Resolve It
The most consequential audit conversation for AI systems centers on what auditors informally call the "black box problem." The auditor asks: "Can you explain how this specific decision was made?" The team points to the model and says: "The model evaluated the inputs and produced this recommendation." The auditor responds: "That is not an explanation. That is a description of a black box."
This objection is not about model interpretability in the machine learning sense — auditors are not asking for SHAP values or attention weights. They are asking a process question: is the decision-making process documented, controlled, and reproducible? A system where the decision authority resides inside a model that cannot produce a deterministic explanation for a specific decision is, from an audit perspective, a process without adequate controls.
The resolution is architectural, not explanatory. Instead of trying to explain the model's reasoning, the team demonstrates that the model's output is not the decision — it is input to a decision. The decision is made by explicit, versioned rules that evaluate the model's recommendation alongside other facts, and the entire evaluation is captured in an immutable decision trace. The auditor can then examine the trace: the inputs were X, the rules (at version Y) evaluated those inputs, and the outcome Z followed deterministically from that evaluation.
This transforms the audit from "explain how the model works" to "show me the decision record." The former is an open-ended question with no satisfactory answer for probabilistic systems. The latter is a bounded evidence request with a concrete artifact. As described in Decision Traces: The Audit Log Pattern That Makes AI Systems Defensible, a decision trace that captures input atoms, versioned rules evaluated, and the committed outcome provides exactly the evidence chain that satisfies the auditor's requirement.
Five Common AI-Specific Control Gaps
Based on the patterns observed across SOC 2 engagements involving AI systems, five control gaps appear consistently. Each represents a point where existing controls, designed for traditional application logic, do not cover the additional change vectors and decision paths that AI systems introduce.
Gap 1: Undocumented Decision Logic Changes
The team has change management controls for code deployments but not for decision rule changes, prompt modifications, or model configuration updates. The auditor discovers that scoring thresholds were adjusted, prompt instructions were modified, or model versions were swapped during the observation period without corresponding change records. The fix is to bring all change vectors that affect decision behavior under the same change management framework — or under a purpose-built decision rule versioning system that produces equivalent documentation.
Gap 2: No Authority Boundaries for AI Agent Actions
The AI system has access credentials that allow it to take actions (modify accounts, send communications, adjust pricing) but there is no documented control defining the boundary of what the AI is authorized to do. The system's operational permissions are implicit in its code rather than explicit in a governed policy. The auditor asks "what prevents this AI from taking action X?" and the answer is "the code does not tell it to do X" — which is not a control.
Gap 3: Model Changes Without Impact Assessment
The team updated the underlying model (new model version, retrained weights, changed provider) during the observation period. The model change altered the system's decision behavior. But there is no documented assessment of the impact of that change on decision outcomes, and no evidence that the change was tested against the existing decision rule set before deployment. The NIST Cybersecurity Framework 2.0 provides risk assessment guidance that applies directly to this scenario — model changes should be treated as configuration changes that require impact assessment before deployment.
Gap 4: Monitoring Blind Spots for Decision Behavior
The team monitors system health (uptime, latency, error rates) but does not monitor decision behavior (outcome distribution, rule evaluation patterns, anomaly detection on decision outputs). The auditor asks "how would you know if the AI system began making significantly different decisions than expected?" and the answer is "our customers would tell us" — which is not a monitoring control.
Gap 5: Incomplete Decision Records
The system logs model inputs and outputs but does not capture the full decision evaluation chain: which rules were active, what version of each rule was evaluated, what the rule-level outcomes were, and how the final decision followed from those evaluations. The auditor samples a specific decision and asks the team to reconstruct the decision path. The team can show what the model produced but cannot show what rules governed the outcome. The evidence is incomplete.
Gartner's AI Governance Maturity Model identifies this pattern as the most significant barrier to AI audit readiness: organizations that have invested in model observability but not in decision-layer governance find themselves unable to satisfy the evidence requirements that auditors apply to consequential automated processes.
Mapping AI Controls to Trust Services Criteria
For teams preparing for a SOC 2 Type II audit that includes AI systems, the following mapping shows which AI-specific controls map to which Trust Services Criteria. This is not exhaustive — it covers the controls most commonly examined and most commonly found to have gaps.
| AI-Specific Control | Trust Services Criteria | Evidence Required |
|---|---|---|
| Decision rule versioning and change management | CC8 (Change Management) | Version history, change requests, approval records, deployment logs |
| AI agent authority boundaries | CC6 (Access Controls), PI1 (Authorization) | Documented permission policies, enforcement evidence, access logs |
| Model change impact assessment | CC8 (Change Management), CC3 (Risk Assessment) | Impact analysis documents, pre-deployment test results, rollback procedures |
| Decision behavior monitoring | CC7 (Monitoring), PI1 (Completeness) | Monitoring dashboards, alert configurations, incident response records |
| Immutable decision traces | PI1 (Processing Integrity), CC7 (Monitoring) | Trace records for sampled decisions, immutability evidence, completeness metrics |
| Decision input validation | PI1 (Validity) | Input schema definitions, validation rules, rejection logs for invalid inputs |
| AI data pipeline confidentiality | C1 (Confidentiality) | Encryption records, access logs for training data and feature stores, DLP evidence |
A Practical Audit Preparation Timeline
For teams that have not previously included AI systems in their SOC 2 scope, preparation typically requires three to six months of work before the observation period begins. The observation period itself is typically six to twelve months. This means that a team beginning preparation now is positioned for a Type II report covering an observation period starting in six months.
Months 1-2: Gap Assessment. Map existing controls to the Trust Services Criteria relevant to AI systems. Identify which of the five common gaps apply. Determine whether Processing Integrity should be added to the SOC 2 scope. Review the AI system's change vectors (model changes, rule changes, configuration changes, data pipeline changes) and assess which are covered by existing change management and which are not.
Months 2-4: Control Design and Implementation. Implement the missing controls: decision rule versioning, authority boundary enforcement, model change assessment procedures, decision behavior monitoring, and decision trace infrastructure. The decision trace infrastructure is the most significant engineering investment — it requires instrumenting the decision layer to produce immutable, complete records for every evaluation.
Months 4-6: Control Validation. Operate the new controls for a two-month validation period before the formal observation window opens. Use this period to verify that controls produce the evidence artifacts the auditor will require. Test the team's ability to produce a complete decision trace for a sampled decision within the time frame the auditor will expect. Identify and fix any evidence gaps before they become audit findings.
Months 6-18: Observation Period. Operate the controls consistently. Maintain decision traces, change records, monitoring logs, and access records. Conduct periodic self-assessments to verify that controls are operating as designed.
The Underlying Principle: Audit Readiness Is an Architecture Problem
The teams that navigate SOC 2 Type II audits cleanly for AI systems share a common trait: they treated audit readiness as an architectural decision, not a compliance exercise. They designed their AI systems so that decision logic is explicit and versioned, authority boundaries are enforced by the system rather than documented in a policy, decision records are generated automatically rather than assembled manually, and change management extends to every vector that can alter decision behavior.
This architectural approach produces a system that is auditable by design — not auditable because the team assembled evidence after the fact. When the auditor samples a decision from March 14th, the team does not spend three days reconstructing what happened. They query the decision trace store and produce a complete record in minutes: the inputs evaluated, the rules applied (with version identifiers), and the outcome that followed.
For the architectural patterns that enable this, see The Agent Governance Stack: Four Layers Every Enterprise Needs Before Going to Production and The Authorization Model for AI Agents. For the specific decision trace schema that satisfies auditor evidence requirements, see Decision Traces: The Audit Log Pattern That Makes AI Systems Defensible.