Does SOC 2 Change for AI Products?

The Trust Services Criteria (TSC) have not been rewritten for AI. The AICPA's criteria last underwent a substantive revision in 2017, with a points-of-focus refresh in 2022 — before generative AI became mainstream in enterprise software. A Cloud Security Alliance research note published in August 2026 found that the TSC's principles-based design means existing criteria technically cover AI systems, but that auditors are applying them inconsistently because the criteria don't provide AI-specific guidance.

The short answer: SOC 2 applies to AI products in the same way it applies to any software product, but AI systems introduce new risk surfaces that map to existing criteria in non-obvious ways. This guide explains those mappings.

New Risk Surfaces AI Products Introduce

Training Data Access and Confidentiality

AI models trained on customer data inherit confidentiality obligations. If your model was trained on or fine-tuned with customer-specific data (purchase history, support tickets, user behavior logs), that data is in scope for CC6 (logical and physical access controls) and the Confidentiality Trust Service Category.

Questions auditors will ask:

• Who has access to training datasets, and through what controls?
• Is training data encrypted at rest and in transit?
• Are training datasets segregated from production data?
• Is there a data retention and deletion policy for training data?

Model Access and Authorization

The model itself is a system resource that requires access controls. CC6.1 requires that access to information assets is restricted to authorized individuals. This extends to:

• Who can invoke the model in production (application credentials, API keys)
• Who can view or modify model weights and configurations
• Who can access model outputs (in cases where outputs contain sensitive inferences)

Third-Party Foundation Models as Subprocessors

Most AI products don't train their own models from scratch. They use foundation models from OpenAI, Anthropic, Google, or Cohere via API, or fine-tuned versions of open models. When customer data is sent to a third-party model provider for inference, that provider is a subprocessor.

Under CC9.2 (vendor and business partner risk management), you're required to assess your subprocessors' security controls. For AI model providers, this means:

• Reviewing the model provider's SOC 2 report
• Understanding their data retention policy (does customer data sent for inference get used for future model training?)
• Including the AI provider in your [subprocessor management program](/blog/soc2-subprocessor-management-guide)

This is one of the most common audit findings for AI companies in 2026: the company didn't include their LLM API provider in their vendor risk management program because they viewed it as a commodity API rather than a subprocessor.

AI Model Changes as Change Management Events

CC8 (change management) requires that changes to systems are authorized, tested, and reviewed. Model updates — whether you're updating the model version you're calling via API, re-fine-tuning a model with new data, or switching model providers — are system changes under CC8.

Your change management process should include:

• Version control for model configurations and prompts
• Review and approval before model updates reach production
• Rollback capability if a model update degrades behavior
• Documentation of what changed and why

Output Integrity and Monitoring

CC7.2 requires monitoring for system anomalies. For AI products, this extends to monitoring model outputs:

• Anomaly detection for unusual output patterns (signs of prompt injection or model manipulation)
• Logging of AI decision inputs and outputs for audit trail purposes (especially if AI is used for access control decisions or financial recommendations)
• Testing model behavior after updates (regression testing on a defined eval set)

Mapping AI Risks to Trust Services Criteria

|---|---|---|

What Auditors Are Asking in 2026

Based on published guidance from auditing firms and the Cloud Security Alliance's 2026 research note on SOC 2 AI control gaps, auditors are increasingly asking AI companies the following questions:

Inventory: Can you identify every AI model your product uses, including third-party APIs?

Data flows: Can you document what customer data flows to each model?

Third-party contracts: Do your contracts with AI providers prohibit use of customer data for model training? Do they include breach notification obligations?

Change process: How do you control and test model updates before they reach production?

Incident response: What happens if a model produces outputs that violate customer confidentiality?

If you can't answer these questions clearly, that's a remediation priority before pursuing a Type II audit.

Practical First Steps for AI Companies

Step 1: Inventory your AI systems. List every model or AI service your product uses, whether first-party (you trained it) or third-party (you call it via API). Include the provider, the data sent, and the contractual terms.

Step 2: Review your AI provider contracts. Does your provider's data processing agreement prohibit use of your customers' data for model training? This is non-negotiable for enterprise sales. Major providers (OpenAI, Anthropic, Google Cloud) offer zero-data-retention and no-training-use provisions — confirm these are in your contract.

Step 3: Add AI providers to your vendor risk program. Collect their SOC 2 reports. Review their security documentation. Include them in your periodic vendor reviews. See [vendor risk management for SOC 2](/blog/soc2-vendor-risk-management-guide).

Step 4: Implement change control for models. If you call a model via an API, pin your API calls to a specific model version rather than calling the "latest" alias. Review what changes when you upgrade. Document the review.

Step 5: Add AI-specific monitoring. Log model inputs and outputs (appropriately redacted) for anomaly detection and incident investigation purposes.

The core SOC 2 program — access controls, encryption, incident management, vendor risk — applies fully to AI products. The additional work is ensuring AI-specific data flows and third-party models are included in that program's scope.