Your SOC 2 Auditor Is About to Ask About AI. Are You Ready?

Your engineering team shipped an AI feature six months ago. A chatbot, a summarization tool, a recommendation engine, something that calls a large language model API and returns output to your customers. Nobody flagged it as a security concern because it felt like a feature, not infrastructure. Now your SOC 2 auditor is asking how you control access to the model, what data gets sent to third-party AI services, and whether you can explain how the model produces its outputs.

Half the room doesn't know the answer. The other half doesn't know the question is coming.

This is the new reality. SOC 2 reports are evolving to address AI controls, and auditors are catching up to what's already deployed in production. If your product has AI features and your compliance program hasn't accounted for them, you have a gap. It's better to find it now than during fieldwork.

Why auditors are asking about AI

SOC 2 is built on the Trust Services Criteria. Security is mandatory. Availability, Confidentiality, Processing Integrity, and Privacy are optional but frequently scoped. AI features touch all five.

When your product sends customer data to a third-party model API, that's a confidentiality and privacy concern. When an AI feature makes decisions that affect users, that's processing integrity. When the model service goes down and your feature breaks, that's availability. The Trust Services Criteria were written before AI features were common in SaaS products, but the criteria are broad enough to cover them. Auditors are now applying existing criteria to AI-specific risks instead of treating AI as a black box that doesn't fit the framework.

This isn't a new framework. It's the same SOC 2 you're already doing, applied to something your team built without thinking about it from a controls perspective. (SOC 2 is not a certification, it's an attestation covers the Trust Services Criteria and how scoping works.)

The questions that are starting to show up in audits

Access controls for AI services. Who has credentials for your model API? Are they stored in a secrets manager or hardcoded in a config file? Is access logged and reviewed? If a developer leaves, is that API key rotated? These are the same access control questions auditors ask about every other system. AI services are not special. They just haven't been on the inventory long enough for anyone to have treated them like the rest of the stack.

Data flow to third-party models. What customer data gets sent to external AI services? Is it logged? Do you have a data processing agreement with the model provider? Can you guarantee customer data isn't used to train models? Your customers are starting to ask this in security questionnaires. Your auditor will too.

Model output governance. Can you explain how the AI feature produces its output? Is there a process for reviewing model responses before they reach customers? What happens when the model produces something wrong or harmful? Processing Integrity criteria ask whether your system processes data completely, accurately, and timely. AI outputs are now part of that conversation.

Vendor risk for AI providers. The company providing your model API is a subprocessor. Do you have a vendor risk assessment for them? Are they listed in your subprocessor disclosure? Have you reviewed their security posture? Most companies added AI APIs to their stack as a developer decision, not a vendor management decision. That's the gap.

What to fix before your next audit

Inventory your AI usage. List every place your product or internal tools use AI. Model APIs, hosted inference services, embedded AI features in third-party tools. If you can't produce this list in ten minutes, you don't have visibility into the problem yet. This is step one. Everything else depends on knowing what you're actually running.

Map the data flows. For each AI service, document what data goes in, where it goes, and what comes back. If customer data is being sent to a third-party model, that needs to be in your data flow documentation and your subprocessor list. If it's not there, your auditor will find the gap before you do.

Apply existing controls to AI services. You already have access control policies, vendor risk procedures, and incident response plans. Extend them to cover AI services instead of writing new ones from scratch. The controls are the same. The technology is different. Your access review process should include API keys for model services. Your vendor risk assessment should cover your AI providers. Your incident response plan should account for AI-specific scenarios like model outputs causing customer harm.

Document your AI governance process. This doesn't need to be a fifty-page policy. It needs to answer four questions: who approves new AI usage, how is risk assessed before deployment, how is ongoing usage monitored, and what happens when something goes wrong. A one-page document that answers those questions is more useful than a comprehensive policy nobody reads.

The questionnaire angle

Your customers are already asking about AI. Security questionnaires from enterprise buyers now include questions about AI usage, data training, model providers, and AI governance. If your answer is "we don't have a formal AI policy," that's a red flag for a sophisticated reviewer. If your answer is "here's our AI usage inventory and our data handling controls for model APIs," you've turned a potential objection into a trust signal. (The security questionnaire has 340 questions, here's how we handle it covers the broader questionnaire response process.)

This is the pattern we see across compliance: the companies that document what they're already doing pass audits and questionnaires without drama. The companies that don't document it spend the audit explaining why they can't answer basic questions about their own systems.

Don't wait for the framework to tell you

The AICPA hasn't published AI-specific Trust Services Criteria. There's no "AI SOC 2" yet. But the existing criteria already apply, and auditors are already applying them. Waiting for formal guidance before you govern your AI usage is the same as waiting for a breach before you implement access controls. The risk exists now. The controls are obvious. The only question is whether you implement them proactively or under audit pressure.

If your product uses AI and your compliance program hasn't caught up, our SOC 2 and ISO 27001 readiness service covers AI controls as part of the gap assessment. We also handle vendor risk assessments for AI providers and security questionnaire responses that include AI governance questions.