How to Deploy AI in a SOC 2 Environment

SOC 2 compliance is table stakes for enterprise software vendors. But for AI systems—especially those accessing sensitive enterprise data—SOC 2 requirements create specific challenges that many AI vendors haven't addressed.

This guide covers what SOC 2 actually requires for AI deployment and where to probe during vendor evaluation.

SOC 2 Basics for AI Systems

SOC 2 is a framework for demonstrating security controls. It covers five Trust Service Criteria:

Security: Protection against unauthorized access
Availability: System accessible as agreed
Processing Integrity: Processing is complete, accurate, timely
Confidentiality: Information designated as confidential is protected
Privacy: Personal information is handled appropriately

For AI systems, Processing Integrity and Confidentiality create the most specific requirements.

What SOC 2 Requires for AI

Data Flow Documentation

Auditors want to understand where data goes. For AI systems:

Where is training data stored?
Where is inference data processed?
What third parties have access?
How is data transmitted between components?

[SCENARIO: An AI vendor claims SOC 2 compliance. During audit, it's discovered that user queries are sent to a third-party LLM provider that isn't covered by the vendor's SOC 2 scope. The audit fails. The customer discovers this after signing a contract.]

What to ask vendors: "Show me a data flow diagram that's included in your SOC 2 scope. Does it include all third-party model providers?"

Access Control Evidence

SOC 2 requires documented access controls. For AI systems:

Who can access the AI system?
How are permissions managed?
Are user actions logged?
How is administrative access controlled?

What to ask vendors: "How do you inherit permissions from our source systems? Show me how access control works for someone who should see Sales data but not Finance data."

Encryption Verification

Data must be encrypted at rest and in transit:

What encryption is used for stored data?
What encryption is used during transmission?
Who manages encryption keys?
Are keys rotated appropriately?

What to ask vendors: "Is data encrypted during AI processing, or only at rest? Who holds the encryption keys?"

Incident Response Procedures

SOC 2 requires incident response documentation:

How are security incidents detected?
What is the notification timeline?
What is the remediation process?
How are incidents documented?

What to ask vendors: "What's your incident notification timeline? Walk me through your last security incident and how it was handled."

Where Most AI Vendors Have Gaps

Gap 1: Third-Party Model Providers

Many AI vendors use third-party LLM providers (OpenAI, Anthropic, etc.) but don't clearly scope this in their SOC 2:

The problem: Vendor's SOC 2 covers their application layer but not the actual AI processing

What this means: Your data leaves the vendor's SOC 2-covered environment

What to verify: "Is your LLM provider covered under your SOC 2? Can I see documentation of their security controls?"

Gap 2: Training Data Handling

If the AI is trained or fine-tuned on customer data:

The problem: Training processes often have different security controls than production

What this means: Your data might be handled less securely during model training

What to verify: "Where is training data stored? Is the training environment covered under SOC 2? How is training data isolated between customers?"

Gap 3: Audit Logging Completeness

AI systems should log all data access, but many don't:

The problem: Basic query logs exist, but detailed data access isn't captured

What this means: You can't demonstrate to your auditors exactly what data the AI accessed

What to verify: "For any AI response, can you show me exactly what source data was accessed? How long are logs retained?"

Gap 4: Processing Integrity for AI Outputs

SOC 2's Processing Integrity criterion is particularly challenging for AI:

The problem: AI outputs are probabilistic, not deterministic; "accuracy" is difficult to guarantee

What this means: Traditional processing integrity controls don't map well to AI

What to verify: "How do you demonstrate processing integrity for AI-generated outputs? What accuracy guarantees do you provide?"

SOC 2 Type I vs. Type II

Type I: Point-in-time assessment of control design Type II: Assessment of control effectiveness over a period (usually 12 months)

For AI vendors:

Type I is a minimum baseline: Shows they've thought about controls
Type II is what you want: Shows controls actually work over time
No SOC 2 is a red flag: Either very early stage or not taking security seriously

What to ask: "Do you have SOC 2 Type II? When was your last audit? Can I see the report (or the summary)?"

Integration with Your SOC 2 Program

When you deploy a third-party AI system, it becomes part of your SOC 2 scope:

Your Responsibilities

Document the AI system in your system description
Implement complementary user entity controls
Monitor vendor compliance
Include in your vendor management program

Vendor's Responsibilities

Maintain their SOC 2 compliance
Provide documentation you need for your audits
Notify you of material changes or incidents
Support your audit requests

Shared Responsibilities

Clarify:

Who is responsible for access control configuration?
Who monitors for security events?
Who handles incident response?
Who maintains audit logs?

Get this in writing. Ambiguity here causes audit problems.

On-Prem Deployment and SOC 2

On-premises AI deployment simplifies SOC 2 scope:

Instead of: Your application → Your network → Vendor's network → Vendor's application → Third-party LLM → responses flowing back

You have: Your application → Your network → AI running in your infrastructure

Benefits:

AI falls under your existing SOC 2 controls
No vendor data flows to document
No third-party LLM provider in scope
Full control over audit logging and access control

This is why many enterprises with mature SOC 2 programs prefer on-prem AI.

Checklist for SOC 2-Compatible AI Deployment

Vendor Evaluation

Vendor has SOC 2 Type II report
Report scope includes AI processing (not just application layer)
Third-party providers (LLMs) are addressed in scope or carve-out
Data flow documentation exists and is complete

Technical Controls

Access control integrates with your identity provider
User permissions inherited from source systems
Encryption at rest and in transit verified
Audit logging captures all data access

Your Documentation

AI system documented in your system description
Complementary user entity controls implemented
Vendor management procedures updated
Data flow diagrams updated to include AI

Ongoing Operations

Annual vendor SOC 2 review scheduled
Incident notification process documented
Audit log review procedures established
Access recertification includes AI system

Getting Started

For SOC 2-covered enterprises, evaluate AI vendors with security rigor matching your other enterprise software. Request SOC 2 Type II reports, verify scope includes actual AI processing, and understand exactly where your data goes.

See how Phyvant approaches enterprise security → Book a call