SOC 2 Meets AI Governance: What Changed in 2026 and Who's Ready

The AICPA published its supplemental AI Trust Services Criteria in early 2026, and the first thing experienced auditors noticed was how many existing SOC 2 programs had no evidence to offer. Not because the controls were unreasonable, but because most organizations had never formally acknowledged that their AI systems existed as auditable assets.

What the 2026 SOC 2 AI Criteria Actually Added

The original Common Criteria and Availability categories were designed for infrastructure and process controls. They assume a human made a decision; the system recorded it. The new AI-specific criteria introduce a fundamentally different assumption: the system is making decisions, and the organization must demonstrate it understands how, on what data, and with what outcomes.

Four control objectives define the new terrain. CC-AI-1 (model risk classification) requires a documented inventory of AI systems with risk tiers assigned. CC-AI-3 (training data integrity) demands lineage documentation from data source through preprocessing to the model version in production. CC-AI-5 (output monitoring and drift detection) requires ongoing performance tracking, not a point-in-time attestation. And threading through all of them is a requirement for explainability artifacts — documentation that a qualified auditor can inspect to understand why a model produces the outputs it does.

The overlap with pre-existing Common Criteria is real but incomplete. CC 7.2 (system monitoring) and CC 9.2 (vendor management) both touch AI systems, but they were written for infrastructure events and third-party contracts, not model behavior. Gap-mapping between the legacy CC controls and the new AI criteria is the mandatory first task for any organization preparing a 2026 SOC 2 Type II engagement that includes AI systems in scope.

Auditors are no longer accepting model governance policies as annexes. Bias-testing cadences, model cards, and explainability documentation are now expected as primary evidence artifacts, reviewed for operating effectiveness over the full audit period.

The Regulatory Stack: EU AI Act and DORA Don't Wait for SOC 2

EU AI Act Risk Tiers and What They Mean for Enterprise Software

The EU AI Act's Annex III high-risk classification covers AI systems used in credit scoring, employment decisions, critical infrastructure management, and several other categories common in enterprise software. Organizations with systems in those categories face conformity assessment obligations that partially overlap with SOC 2 AI criteria but diverge sharply on two dimensions: human-oversight documentation requirements and post-market monitoring cadence. The EU AI Act's Article 61 post-market monitoring obligation is continuous; SOC 2 operates on an annual audit window. These are structurally incompatible timelines.

DORA's ICT Risk Framework and AI System Dependencies

DORA's ICT third-party risk requirements have been enforceable since January 2025. Any financial-services firm or fintech using a third-party LLM API embedded in a production workflow already has a DORA exposure, and the 2026 SOC 2 AI criteria arrived into an environment where many of those firms were already overdue on DORA compliance documentation.

The compliance stack is additive, not substitutable. A SOC 2 Type II report with AI criteria does not satisfy EU AI Act conformity assessment. DORA's resilience testing requirements have no SOC 2 equivalent. Organizations operating across jurisdictions need a controls matrix that maps a single evidence artifact to multiple frameworks simultaneously. This is precisely where AI compliance tools either justify their cost or reveal their limitations.

Compliance teams should note: DORA's ICT third-party risk register and SOC 2's vendor management criteria overlap but are not identical. Financial-services firms need both populated, and a single evidence artifact may not satisfy both without supplemental documentation confirming it meets each framework's specific evidentiary standard.

Shadow AI: The Control Gap Most Platforms Ignore

Shadow AI is the most underestimated scope problem in a 2026 SOC 2 engagement. CC-AI-1 explicitly requires a model inventory that includes third-party AI features embedded in SaaS tools, not only internally developed models. That requirement immediately implicates a large portion of the average enterprise's SaaS stack.

Notion ships AI features enabled by default on new workspaces. ClickUp has embedded AI writing and summarization across its task and document surfaces. Neither product was designed with SOC 2 AI evidence generation in mind, and neither provides the model inventory metadata, training data provenance, or bias documentation that CC-AI-1 and CC-AI-3 require. The moment an employee enables these assistants on a workspace containing regulated data, the organization has an undocumented AI system in scope.

The problem is structurally harder with AI-native products. Rossum, which processes transactional documents using AI as its core function, and Alteryx, which supports ML workflow automation for business analysts, are not products where AI is an optional feature you can disable. The AI component is the product. Auditors expect those systems to appear in the model inventory with the same documentation rigor as internally developed models.

Effective shadow-AI visibility requires network telemetry or API gateway logging. A policy attestation checkbox, which is the default control in most GRC platforms, does not satisfy operating-effectiveness evidence requirements. If your compliance platform cannot show an auditor a log of which AI endpoints were accessed during the audit period, the control is not operating effectively regardless of what the policy document says.

Vendor Evaluation Framework: Four Controls That Separate Ready from Not Ready

Before evaluating specific platforms, it helps to establish the four control dimensions that determine audit readiness for AI governance. These map directly to the new SOC 2 AI criteria and to EU AI Act technical documentation requirements.

• Model Inventory Completeness: Does the platform auto-discover AI endpoints across the tech stack, or does it require manual entry? Manual entry creates an attestation, not a discovery log. Auditors increasingly treat these differently.
• Bias and Fairness Evidence: Can the platform collect, store, and present algorithmic-bias test results as audit artifacts, including the methodology used and the acceptance thresholds applied? A test result without methodology documentation is not audit-grade evidence.
• Training Data Provenance: Does the platform support lineage tracking from data source through preprocessing to model version, or only capture a static attestation at a point in time? CC-AI-3 requires the former.
• Continuous Output Monitoring: Is there integration with model observability tooling — drift detection, performance degradation alerts — or only point-in-time assessment? CC-AI-5 is a continuous control, not an annual one.

Platform-by-Platform Assessment

Vanta: Broad Coverage, Shallow AI Depth

Vanta's core strength is automated evidence collection across cloud infrastructure. Its AI governance module, added in late 2025, covers model inventory through a manual questionnaire workflow and provides policy templates aligned to the new AI criteria. What it lacks is native integration with model observability infrastructure. Drift detection and continuous output monitoring require manual evidence uploads. For organizations with low-risk AI systems — scheduling suggestions, internal search ranking — Vanta's current module is adequate. For high-risk EU AI Act Annex III systems, it is not.

Credo AI: Purpose-Built for Model Risk, Narrow on GRC Breadth

Credo AI is the most technically rigorous option for bias testing and model card generation among the platforms reviewed. It provides structured support for NIST AI RMF profiles and includes EU AI Act technical documentation templates that align with Annex IV requirements. The weakness is GRC breadth: Credo AI does not replace a full SOC 2 compliance platform. Organizations using it will need to integrate it with a second tool for evidence collection across non-AI controls. That integration overhead is real and should be factored into implementation timelines.

Comp AI: Automation Speed vs. Evidence Quality

Comp AI accelerates control mapping through LLM-assisted policy generation, which creates an ironic audit risk. Using AI to generate compliance documentation for AI systems requires its own provenance trail. As of early 2026, Comp AI's own model usage is not disclosed in its SOC 2 report, which means organizations using it for AI governance documentation cannot fully satisfy CC-AI-3 for the documentation itself. Auditors at firms with mature AI compliance programs have flagged this gap. It is not disqualifying, but it requires a compensating control and explicit auditor agreement on how the generated documentation will be treated.

Delve: Promising Architecture, Immature Integrations

Delve positions itself as a unified AI governance and GRC platform, which is the right architectural ambition for the current regulatory environment. Its integration catalog is still growing, and financial-services firms will find gaps in DORA-specific control templates as of early 2026. The platform's model risk classification workflow is well-designed, but the absence of pre-built DORA ICT risk register templates means compliance teams will be building those mappings manually during what is already a compressed implementation window.

Compliance Coverage Matrix

Platform	SOC 2 AI Criteria	EU AI Act (High-Risk)	DORA ICT Risk	NIST AI RMF	Shadow AI Discovery	Bias Evidence Artifacts
Vanta	Partial	Manual	Manual	Partial	Not Supported	Manual
Credo AI	Partial	Native	Not Supported	Native	Not Supported	Native
Comp AI	Partial	Partial	Partial	Partial	Not Supported	Manual
Delve	Partial	Partial	Manual	Partial	Not Supported	Partial
Note: LogicGate and AuditBoard are GRC incumbents that have added AI governance modules but were not primary subjects of this review. AuditBoard's audit workflow capabilities are a meaningful advantage for organizations already embedded in that platform, particularly for evidence packaging and auditor collaboration. LogicGate's risk workflow engine handles control mapping well but its AI-specific templates remain limited as of this writing.

No single platform currently passes all four control dimensions at audit-grade depth for a high-risk AI system classification. The realistic architecture for most regulated enterprises is a primary GRC platform for SOC 2 evidence collection paired with a purpose-built AI governance layer for model risk, bias testing, and EU AI Act technical documentation.

What Auditors Are Actually Asking For in 2026

Based on published AICPA guidance and Big Four audit practice notes circulating in early 2026, the specific evidence requests arriving in fieldwork packages include: a dated model inventory with version history covering the full audit period; bias test results with methodology documentation and defined acceptance thresholds; data processing agreements that cover training data sources; and evidence of human-in-the-loop controls for consequential automated outputs.

The policy-exists attestation that satisfied many CC controls for years is insufficient for AI criteria. Auditors are requesting operating-effectiveness evidence: logs, test results, and incident records generated during the audit period, not policy documents written before it.

Organizations using inference APIs from providers like Groq face a specific documentation challenge. The model weights are not under their control, which means they cannot produce training data provenance or internal bias test results for the underlying model. Third-party assurance documentation — the provider's own SOC 2 Type II report or EU AI Act conformity assessment — must be obtained and incorporated into the audit package as compensating evidence.

Audit finding risk: If your AI vendor cannot provide a current SOC 2 Type II report or EU AI Act technical file, that gap is now a finding in your own audit, not merely a vendor management note. Treat AI vendor assurance documentation with the same renewal discipline you apply to TLS certificates.

Implementation Guidance: Building an Audit-Ready AI Governance Program

The sequence matters as much as the tools. Organizations that select a compliance platform before completing a model inventory consistently find the platform's discovery capabilities insufficient for their actual scope.

1. Complete a model inventory first. You cannot automate discovery of what you haven't acknowledged exists. Include third-party AI features in SaaS tools, inference API dependencies, and embedded ML components in data pipelines.
2. Classify each model against EU AI Act risk tiers and SOC 2 AI criteria applicability. Spell-check and scheduling suggestions carry different evidence requirements than credit-scoring or fraud-detection models. The classification drives the evidence burden.
3. Select a primary GRC platform for SOC 2 evidence collection and a purpose-built AI governance layer for high-risk systems. The two-platform architecture is the realistic path for regulated enterprises as of 2026.
4. Establish a bias-testing cadence before the audit window opens. Retrospective bias testing on a production model that has been running for 18 months without documented testing is an audit conversation that rarely ends well.
5. Obtain and renew third-party assurance documents on a defined schedule. Every AI vendor in your stack needs a current SOC 2 Type II report or equivalent. Treat this as a recurring operational task, not a one-time procurement step.

Teams using workflow orchestration tools like Kestra or Mage for ML pipelines should instrument those pipelines for audit-trail output as part of Step 4. Both tools support custom logging and metadata emission; the configuration effort to produce audit-grade output records is modest compared to the alternative of reconstructing pipeline behavior after the fact during fieldwork.

The Residual Risk No Platform Solves Yet

Model drift between audit periods is the most structurally difficult problem in AI compliance. A model that passed bias testing at the start of a 12-month SOC 2 audit window may have drifted significantly by month 11. No current GRC platform provides continuous bias monitoring at the frequency auditors are beginning to expect for high-risk systems. This is an MLOps problem being handed to a GRC tool category that was not designed to solve it.

The EU AI Act's Article 61 post-market monitoring obligation makes this gap a legal exposure, not just an audit finding risk. Satisfying that obligation requires integration between compliance platforms and model observability infrastructure. Organizations that treat AI governance as a documentation exercise rather than an engineering instrumentation problem will find themselves unable to produce the continuous evidence Article 61 demands.

Algorithmic-bias evaluation for generative AI outputs remains methodologically contested. There is no consensus standard for what constitutes a passing bias test on an LLM-based system. Audit findings in this area will be highly auditor-dependent through at least 2027, which means the acceptance criteria need to be negotiated explicitly before the audit period begins. Document your chosen evaluation methodology, present it to your auditor during planning, and get written agreement on the acceptance thresholds. That conversation is significantly easier before fieldwork than during it.

The most actionable step for any organization entering a 2026 SOC 2 engagement with AI systems in scope: schedule a pre-audit planning session specifically to agree on bias evaluation methodology and acceptance criteria. The frameworks are new, the auditor guidance is still developing, and the organizations that define those terms proactively will spend far less time in findings remediation.