What AI-Specific Evidence Do Auditors Want for SOC 2 Type 2 in 2026?

Your SOC 2 Type 2 observation window is open. Vanta is collecting identity, infrastructure, and change-management evidence. Then the auditor asks for the model registry, prompt logs for the full period, LLM DPAs with zero-data-retention language, and proof that human review actually happened on high-stakes outputs.

That is the gap behind SOC 2 Type 2 for AI companies in 2026: the Trust Services Criteria have not been rewritten for AI, but AI-fluent auditors are interpreting existing criteria against model drift, vendor LLM passthrough, and output integrity. This guide is for founders, Heads of Engineering or Security, and first compliance owners at AI-first or AI-feature SaaS teams who need a practical evidence checklist-not a new framework theory.

Disclaimer: This article is informational only. It is not legal advice, audit advice, or an attestation. Only a licensed CPA firm issues a SOC 2 report. Confirm scope, criteria selection, and evidence expectations with your auditor.

There is still no AICPA 'AI module'

As of April 2026 reporting summarized by Knowlee, the AICPA has not released a dedicated AI module for SOC 2. The operative Trust Services Criteria remain the 2017 criteria (with later points-of-focus refreshes). SureCloud's 2026 SOC 2 guide makes the same core point: the written criteria are stable; what changed is how auditors apply them when AI sits in the product or the operating stack.

Practitioner coverage-from Knowlee, SureCloud, and InfoDefenders-converges on the same pattern. Auditors fold AI risk into existing areas such as risk assessment, logical access, system monitoring, change management, and vendor management. Procurement questionnaires add generative-AI sections even when the SOC 2 control catalog never named 'LLM.'

For your team, that means two practical consequences:

1. You will not find an official AICPA checklist labeled 'AI controls for SOC 2.'
2. You still need exportable AI evidence, because auditors and enterprise buyers are asking for it under the criteria you already scoped.

Why Type 2 observation matters more when the system can drift

Type 1 and Type 2 use the same Trust Services Criteria baskets. The difference is the observation window.

• Type 1 is point-in-time. The auditor opines on whether controls are suitably designed as of a date.
• Type 2 tests whether selected controls operated effectively over a period-commonly six to twelve months for enterprise-facing reports.

For traditional SaaS, Type 2 already matters in procurement. For AI systems, the observation window carries extra weight because the system under audit changes continuously. Models are promoted and rolled back. System prompts are edited. Vendor LLM endpoints version up. Evaluation thresholds move. A single-day Type 1 snapshot cannot show that prompt logging, model change control, and drift monitoring stayed on across those changes.

If a major model migration lands inside your Type 2 window, expect the auditor (and later, buyers reading the report) to care whether your AI evidence trail covers that migration-not only the steady state after it.

Trust Services Criteria, lightly mapped to AI evidence

Security is mandatory in every SOC 2. Availability, Processing Integrity, Confidentiality, and Privacy are elective based on your system description and buyer expectations. Below is a light map-criteria baskets only, no invented control IDs. Your auditor will map samples to their own testing approach.

Security

Expect questions about who can promote a model to production, how LLM API keys are stored and rotated, whether prompt and completion logs are access-controlled, and how third-party model providers are treated in vendor management. Shadow AI (unapproved tools processing customer or company data) increasingly shows up in access and risk conversations.

Availability

Beyond classic uptime and DR evidence, AI products draw questions about provider failover or graceful degradation when an LLM API is unavailable, inference latency monitoring where SLAs depend on model responses, and rate-limit handling so throttling does not silently break commitments.

Processing Integrity

This is where hallucination handling, output verification, and human-in-the-loop enforcement land. Auditors are not asking you to certify that the model is always correct. They are asking how you detect incorrect or unauthorized processing, what happens when thresholds are breached, and whether required human reviews actually occurred.

Confidentiality

Prompt and completion retention, tenant isolation around shared inference infrastructure, and contractual controls with LLM providers (including training-use restrictions) sit here. Marketing claims about 'we do not train on customer data' need contractual and technical backing in the evidence binder.

Privacy

Where personal data flows through prompts, embeddings, fine-tuning, or completions, expect lineage questions, data subject request handling for AI artifacts, and transfer documentation that extends through the LLM hop-not only your primary application database.

Most AI companies selling to enterprise still start with Security plus Confidentiality, then add Availability and Privacy when SLAs and personal data make those baskets hard to leave out. Confirm scoping with your CPA firm; do not invent a one-size scope from a blog post.

AI-specific evidence checklist auditors ask for in 2026

The following categories appear repeatedly in AI-aware SOC 2 Type 2 preparation guidance (notably Knowlee's April 2026 synthesis) and in how buyer questionnaires now probe AI tools. Treat this as a working checklist your auditor may sample against existing TSC-not as AICPA-published AI criteria.

1. Model registry and rollback

Maintain a registry (platform-native, MLflow, Weights & Biases, or equivalent) for every model promoted to production: version, training or fine-tune reference, evaluation summary, approver, and deployment timestamp. Document a rollback procedure and keep at least one tested rollback example. Tie production inferences back to the exact model version that produced them.

2. Prompt and completion audit trail

This is often the most requested AI-specific artifact. Aim for per-call logging that can show timestamp, calling user or service, model name and version, input and output (or a privacy-preserving reference when raw content cannot leave a restricted store), and retention settings that match policy. Append-only or otherwise tamper-evident storage helps you attest that logs were not rewritten after the fact. Retention should be documented and enforced-not only described in a wiki.

3. LLM DPAs, zero-data-retention (ZDR), and the sub-processor chain

For each production LLM provider, keep the signed DPA, explicit contract language on training use or ZDR where you claim it, a current sub-processor list with a change-notification path, and vendor assurance artifacts (for example, the provider's own SOC 2 or ISO certificates) as part of vendor management. InfoDefenders' coverage of generative-AI questionnaire sections underlines the same weak spot: embedded AI features inside SaaS vendors create Nth-party LLM sub-processors that never appear on an outdated vendor list.

4. Hallucination and incorrect-output handling

Document how you classify model errors, what triggers an incident versus a product bug, what output filters or schema checks run before delivery, and how users report bad outputs. Trend views over the observation period (reports up or down, remediations closed) are more useful than a policy that never fired.

5. AI literacy training (EU AI Act Article 4 crossover)

Article 4 of the EU AI Act requires providers and deployers to ensure sufficient AI literacy among relevant staff. Even US-domiciled teams see this asked in SOC 2 and enterprise questionnaires because European buyers and AI-fluent auditors treat personnel competency as in-scope for Common Criteria-style personnel expectations. Keep a role-appropriate curriculum, completion records with timestamps, and retention that covers the audit period. For Act-specific obligations beyond literacy, see Workstreet's EU AI Act compliance guide for US SaaS.

6. Human-in-the-loop enforcement

Where policy says a human must review before release, produce per-decision evidence: reviewer identity, timestamp, and ideally the delta between model draft and published output. The same logs often support AI Act human-oversight expectations for higher-risk uses-build once, map twice.

7. Model performance and drift monitoring

Run continuous or regularly scheduled evaluation against a held-out or shadow set. Alert on accuracy, latency, refusal rate, or other drift metrics that matter to your product. Keep a runbook for triage (rollback, retrain, accept with rationale) and retain examples of alerts and resolutions from inside the Type 2 window.

If you only have time to harden three areas before fieldwork, prioritize the model registry, the prompt/completion trail, and LLM vendor contracts. Those three fail closed in both audits and security questionnaires.

Same evidence, different purpose: SOC 2, ISO 42001, and the EU AI Act

In 2026, serious AI vendors rarely run SOC 2 in isolation. The frameworks that compose with it serve different jobs:

• SOC 2 Type 2 is a CPA attestation against Trust Services Criteria-still the common US enterprise procurement gate.
• ISO/IEC 42001 is a certifiable AI management system. It structures AI policy, impact assessment, lifecycle controls, and continual improvement. It does not replace SOC 2.
• EU AI Act is law for in-scope providers and deployers. It imposes risk-tiered legal obligations; it is not a voluntary attestation.

You do not need to re-litigate whether every AI company must certify to ISO 42001 tomorrow. Many deals still close on SOC 2 plus strong questionnaire answers. When buyers do ask for formal AI governance, the efficient move is reuse: model versioning, audit logs, literacy records, and human oversight evidence can support SOC 2 testing, AIMS documentation, and Act-related technical files-if you design the evidence layer once.

For the buy-side decision on when 42001 is worth pursuing versus questionnaire coverage, use Workstreet's comparison: Do you need ISO 42001 if you already have SOC 2 (or ISO 27001)?. For the broader governance framing, see What is AI governance?. For startup sequencing across SOC 2 and AI frameworks, see Compliance for startups.

Where Vanta ends and the AI evidence layer begins

Compliance automation platforms such as Vanta are strong at the classic SOC 2 surface: identity and access, cloud configuration, endpoint posture, policy acknowledgment, and many vendor and people workflows. That layer still matters. Enterprise buyers will not waive it because you have an impressive model card.

What those platforms often do not fully automate-especially for AI-native products-is the AI-specific evidence listed above: prompt and completion trails suitable for audit export, model registry events tied to production promotions, AI literacy curricula mapped to roles, hallucination incident trends, and LLM ZDR/DPA packets kept current as providers change terms.

The workable pattern is composition, not replacement:

1. Keep Vanta (or your GRC platform) healthy for infra, identity, and standard TSC evidence.
2. Add an AI evidence layer owned by eng/security/compliance together-logging, registry, vendor AI packets, literacy, HITL records.
3. Map that layer into the same audit binder and Trust Center narrative so sales is not inventing answers under deadline.

Workstreet supports SOC 2 programs on Vanta and has expanded the same operating model into AI management work, including ISO 42001 support with Vanta. That pairing closes the ownership gap: continuous classic controls plus an AI evidence program your auditor and buyers can sample. It does not mean any single platform alone ships complete prompt-log evidence out of the box-plan the AI logging and registry work explicitly.

A practical prep sequence before the observation window hardens

1. Lock scope with your CPA firm - systems in description, TSC baskets, and whether AI features and LLM subservice providers are named clearly.
2. Inventory AI systems and vendors - product features, internal tools, and embedded AI inside SaaS you already buy.
3. Stand up or harden the seven evidence categories above, with named owners and retention that covers the full Type 2 period.
4. Dry-run exports - can you produce a month of prompt-trail samples, a registry extract, and DPA/ZDR packets without a fire drill?
5. Align questionnaires and the audit story - the answers you give procurement should match what the auditor will sample.
6. Resist mid-window control rewrites without documenting the change; Type 2 cares about operating effectiveness across time.

Soft next step

If your classic SOC 2 evidence is already moving in Vanta but nobody owns model registry exports, prompt-trail retention, or LLM contract packets, that is the gap to close before fieldwork-not after a buyer stalls a renewal. Workstreet helps AI and SaaS teams run SOC 2 on Vanta while building the AI evidence and governance layer that auditors and enterprise questionnaires now sample. Talk with the team when you want that layer designed once and reused across SOC 2, AI questionnaires, and ISO 42001 readiness-without treating the blog checklist as a substitute for your CPA's engagement letter.