SOC 2 auditors have been asking about AI for about eighteen months. The questions started vague — "do you use any AI tools in your development process?" — and have gotten progressively more specific. If your Type II audit is coming up in the next six months, you should assume the auditor knows what a context window is and has a prepared list of controls to look for.
Here's what they're asking, what a good answer looks like, and where most teams fall short.
"What AI providers do you use, and what data do you send them?"
This is the baseline question. It sounds easy. It usually isn't.
Most organizations have multiple AI integrations — some managed by engineering, some licensed through SaaS tools (Copilot, Cursor, AgentForce), some purchased by individual teams without central procurement visibility. An accurate answer requires a vendor inventory that not every organization maintains.
What auditors are looking for: a documented list of AI vendors, what data each receives, whether that data includes personal information, and what your data processing agreements (DPAs) look like with each vendor.
What they find instead: "We use OpenAI" — plus, when pressed, Anthropic, Azure OpenAI, GitHub Copilot, Cursor, and several other tools that various teams have been using independently. No unified vendor list. DPAs for some providers, not all.
The gap matters because CC 6.7 (logical access over protected information) requires you to identify what systems handle sensitive data. "AI providers" are now in scope for that question.
"How do you prevent personal data from entering AI context windows?"
This is the question that separates organizations with real controls from organizations with guidelines.
A guideline: "We have a policy that engineers should not include PII in AI prompts." An auditor won't count this as a control. There's no evidence it's enforced, no mechanism that prevents violations, and no audit trail showing it worked.
A control: "All AI API traffic routes through our gateway. The gateway runs a PII detection engine before every request. Detections are logged to an append-only audit table. Here's the log from the last 90 days showing the controls operated as designed."
The second answer is what CC 8.1 (change management and data processing controls) looks like for AI. The auditor can test it. They can ask to see a detection event. They can verify the log isn't editable.
"What's your audit trail for AI activity?"
For SOC 2, the audit trail question is about two things: completeness and integrity.
Completeness: does the trail cover all AI activity, or just some of it? If your gateway only handles Anthropic traffic and your Copilot spend isn't logged anywhere, the trail is incomplete. The auditor will ask.
Integrity: can the records be modified? An audit log that lives in a standard database table — where an application with write access could theoretically UPDATE or DELETE rows — is not the same as an append-only log. Auditors who know what they're looking for will ask how the integrity is guaranteed. "We have a column called deleted_at that we check" is not the answer they want.
What they want to see: database-level enforcement. The application role has UPDATE and DELETE revoked on the audit tables. A deploy-time check verifies this on every rollout. The auditor can run \dp in Postgres and confirm it themselves.
This is one of those controls that's either there or it isn't. You can't approximate it.
"How do you govern AI agent behavior?"
This is the newest question and the one most teams are least prepared for.
An AI agent is a system that calls AI models autonomously to accomplish goals. It might call the model dozens of times for a single task. It has a named identity, a set of authorized actions, and in most implementations, no hard budget limit.
The auditor's question is essentially: how do you know what your agents did? And how do you stop them from doing something they shouldn't?
What they're looking for:
- Agent registry — a list of all named agents in your environment, what systems they have access to, and who authorized their deployment
- Spending controls — evidence that agents can't spend without limit; what stops a runaway agent from generating unlimited API costs?
- Status auditability — if you revoke an agent's access, is that recorded? Can you show the event log of when agent X was active, when it was paused, when it was revoked?
Most organizations don't have any of this. They have agents, but the agents aren't registered anywhere. There's no lifecycle log. There's no hard spending limit. The auditor notes this as a finding.
The SOC 2 control mapping for AI
For reference, the Trust Services Criteria that most commonly touch AI governance:
| Criteria | What it requires | AI implication | |----------|-----------------|---------------| | CC 6.1 | Identify assets that handle sensitive information | AI providers are now assets | | CC 6.7 | Restrict logical access to sensitive information | PII reaching AI providers is in scope | | CC 7.2 | Monitor system components for anomalies | AI cost spikes, model swaps, unusual patterns | | CC 8.1 | Evaluate data processing controls | PII detection, prompt auditing | | A1.1 | Capacity management | AI spend controls prevent runaway costs |
None of these require specific AI tooling by name. But all of them have implications for AI systems that your auditor is now aware of.
What "ready for the AI questions" actually looks like
You don't need a custom AI governance program to answer these questions well. You need four things:
1. A vendor inventory. A document listing every AI provider your organization uses, what data each receives, and whether a DPA is in place. Takes one afternoon. Update it quarterly.
2. A technical control for PII. Not a policy — a gateway that detects PII before requests leave your network, with an append-only log of every detection event. This is the control that answers CC 6.7 and CC 8.1.
3. An append-only audit trail. Database-level enforcement, not application-level. The auditor should be able to verify it with a database permission check, not just your word.
4. An agent registry. If you're running AI agents: a list of what they're called, what they can do, who authorized them, and what spending limits apply. The lifecycle log — when each agent was activated, paused, or revoked — stored in the same append-only table as your other audit events.
None of this is exotic. All of it can be in place before your next audit window opens.
The question auditors haven't started asking yet (but will)
The next wave is training data and model provenance. "Do any of your AI integrations fine-tune models on customer data?" "Can you show that customer data never flows into the training pipeline of a provider's model?" "What's your policy if a provider updates their terms of service to allow training on your API traffic?"
These questions are coming. The organizations that are already thinking about data provenance and model governance will be ready. The ones that aren't will spend the next audit cycle scrambling.
For now: get the four things above in place. That gets you through the current audit. Then start thinking about what the next audit will look like.
Visionality ships with append-only SQL enforcement, a PII detection gateway, and an agent registry — all on by default. See the SOC 2 mapping →