If you are going through a SOC 2 Type II audit in 2026 and your company uses AI tools — which it does — expect AI to come up. Not in a corner of the questionnaire. In the main controls narrative.
Auditors are approaching AI in one of two ways depending on the firm. The more progressive approach is to treat AI tool usage as a new category within existing trust services criteria — specifically, logical access controls, change management, and risk management. The more cautious approach is to flag ungoverned AI use as a finding under the CC6 series (logical and physical access controls) or CC9 (risk management), depending on how the auditor interprets the scope.
Either way, the question is the same: does your organization have documented, enforced controls over how AI tools are used, what data enters them, and who has access to them?
This post explains what auditors are looking for, what evidence satisfies the question, and the most common gaps that create findings.
Why AI is now in SOC 2 scope
SOC 2 audits against AICPA’s Trust Services Criteria. The criteria themselves have not been revised to include specific AI controls, but the existing criteria are broad enough to capture AI tool usage:
- CC6.1 (Logical access): The organization limits logical access to information assets. AI tools are information assets. If employees are using AI tools with unrestricted access to sensitive data, CC6 applies.
- CC6.6 (Boundary protection): The organization prevents unauthorized access from external sources. AI model providers are external — they receive whatever data employees submit. The question is whether that transmission is controlled.
- CC9.2 (Risk assessment): The organization assesses risks from the use of vendor and business partner technology. AI providers are vendors. An AI provider that receives customer data without a documented risk assessment is a CC9 gap.
- A1.2 (Availability — for AI-dependent systems): If production systems depend on AI, availability and resilience of that AI dependency become scope.
The AICPA issued guidance in 2023 acknowledging AI as an emerging risk area. Audit firms, particularly the larger ones, have developed internal practice standards for how to evaluate AI controls. The practical effect is that companies going through SOC 2 in 2026 should expect AI questions in the risk assessment phase and AI evidence requests during fieldwork.
The three areas auditors examine
1. AI tool inventory and access management
What they ask: What AI tools does your organization use? Who has access to them? Are they approved through your vendor management process?
The auditor is testing CC6.1 (logical access) and CC9.2 (vendor management). An organization that cannot produce a current inventory of AI tools in use — with the same rigor as its SaaS vendor inventory — has a documentation gap.
What satisfies the question:
- A maintained AI tool inventory that lists approved tools, their data classification, their risk rating, and their access scope (who uses them, for what purposes)
- Evidence that unapproved tools are restricted or monitored (access control configurations, network logs, or a usage monitoring report)
- Signed Data Processing Agreements (DPAs) or equivalent contractual data handling commitments from AI providers who process customer data
- Evidence of a vendor risk assessment for each AI provider classified as a sub-processor or high-risk vendor
The inventory should be treated with the same discipline as your SaaS tool inventory. If your SOC 2 preparation already includes a vendor registry with risk tiers, AI tools belong on it.
Common finding: The inventory exists for corporate IT tools but AI tools were added ad hoc without going through the vendor assessment process. The auditor finds that several AI providers have access to customer data but are not in the vendor registry.
2. Data handling controls: what goes into AI tools
What they ask: What categories of data can employees submit to AI tools? Are there controls that prevent customer data from being submitted to external AI models?
This question tests CC6.6 (boundary protection) and may also touch on Availability or Confidentiality criteria depending on the trust services category in scope.
The crux is: if customer data can reach an AI model provider, that provider is a sub-processor of your customers’ data. Unless you have customer consent (typically through your DPA/terms of service) and contractual protections with the AI provider, that transmission is a potential finding.
What satisfies the question:
- A documented policy that defines which data categories may and may not be submitted to AI tools (e.g., internal drafts and non-sensitive research = permitted; customer PII, transaction data, and confidential business information = restricted)
- Technical controls that enforce the policy: prompt inspection or content filtering that detects and blocks or redacts sensitive data before it reaches the model
- Evidence that the controls are operating — typically, a sample of the AI activity log showing policy enforcement actions over the audit period
- If customer data does enter AI tools: evidence that customers are informed (DPA clause or terms of service disclosure) and that the AI provider has signed a DPA with equivalent protections
Common finding: The policy exists in the employee handbook but there is no technical enforcement. The auditor asks for evidence that the policy is operating as designed and there is none — because the only enforcement mechanism was training. A policy without a control is a gap.
3. Audit trail and monitoring
What they ask: How do you monitor AI tool usage? Can you detect policy violations? Do you have an audit trail for AI activity?
This tests CC7.2 (system monitoring) and CC7.3 (anomaly detection and response). The auditor is looking for evidence that you would know if something went wrong — and that you have records to investigate it if it did.
What satisfies the question:
- An AI activity log that captures: user identity, tool or model used, timestamp, policy decision applied, and any sensitive content detection events
- Evidence that the log is reviewed — either by automated alerting on policy violations or by a periodic human review process documented in your security operations procedures
- Retention of AI activity logs for the duration required by your retention policy (typically 12 months to align with audit periods)
- Evidence that the monitoring process would detect a policy violation — for example, a sample showing a detected and responded-to event, or documentation that automated alerting is configured and tested
Common finding: The organization uses the AI provider’s native logs (e.g., OpenAI usage logs) as its monitoring evidence. Auditors typically flag this because provider-side logs do not capture the full picture: they do not show what policy was in place at the time, whether the submission was authorized under that policy, or what happened downstream. An independent audit trail — one your organization controls — is the stronger evidence.
Building the evidence trail before fieldwork
The best time to build AI governance documentation for SOC 2 is six months before the audit starts. The second-best time is now.
The documentation required maps directly to the three areas above:
For inventory and vendor management:
- Add AI tools to your vendor registry; assign risk tiers
- Complete a vendor risk assessment for each AI provider processing customer data
- Obtain DPAs from AI providers where required; document where DPAs are pending
- Define access scope per tool in the inventory
For data handling controls:
- Write an AI data handling addendum to your existing data classification policy
- Define permitted and restricted data categories per AI tool tier
- Deploy technical enforcement (AI gateway, prompt inspection, or equivalent)
- Document the technical control in your controls inventory with an operating effectiveness test
For monitoring and audit trail:
- Configure AI activity logging in your governance layer (not just provider logs)
- Define the monitoring cadence: automated alerts, human review, or both
- Document the review process in your security operations runbook
- Retain logs for the full audit period before fieldwork begins
What auditors accept as evidence of AI controls
The practical question is what formats auditors accept. Based on patterns from SOC 2 preparation cycles in 2025 and 2026, the following evidence types consistently satisfy AI control questions:
| Area | Evidence type | Strength |
|---|---|---|
| Tool inventory | AI tool registry with risk ratings and access scope, dated and current | Strong |
| Vendor management | Signed DPAs from AI providers; vendor risk assessment documentation | Strong |
| Data classification | Written AI data handling policy, version-controlled | Moderate |
| Technical enforcement | Configuration screenshot + policy definition from AI gateway or DLP tool | Strong |
| Monitoring | Sample AI activity log extract (redacted) showing policy decisions | Strong |
| Monitoring | Automated alert configuration evidence + documented review history | Strong |
| Log retention | Retention policy document + confirmation that logs are available for audit period | Moderate |
| Provider-side logs only | OpenAI usage dashboard, Anthropic activity log, Microsoft Copilot audit log | Weak — supplementary only |
“Moderate” evidence satisfies the question when combined with other evidence. “Weak” evidence (provider logs alone) typically prompts a follow-up request for independent controls evidence and may result in a management recommendation if it is the only evidence available.
The AI governance layer as a SOC 2 control
If you are building this from scratch for an upcoming audit, the fastest path to satisfying all three areas is deploying a dedicated AI governance layer:
- Inventory and access become a byproduct of the gateway configuration — every approved tool is in the policy, and anything outside the policy is blocked or flagged.
- Data handling enforcement is built in — the gateway inspects prompts and enforces data classification rules in real time.
- Audit trail is the gateway’s native output — a structured, tamper-evident log of every AI interaction that you control and retain.
This is also the evidence format that auditors find most compelling, because it is infrastructure-level evidence rather than documentation evidence. A gateway log is a control operating effectiveness test. A policy document is a policy.
For a US scale-up going through SOC 2 Type II with a 12-month observation period, the audit window is the period during which you need evidence that your controls were operating consistently — not just that they were documented at the time of the audit.
Qadar AI Shield is designed for teams going through SOC 2 with AI in scope: built-in AI activity logging, policy enforcement across browser, desktop, and API access, and a tamper-evident audit trail that satisfies SOC 2 fieldwork evidence requests. See how it works.