An organization's SOC 2 program doesn't need an entirely separate AI control framework. AI systems fit inside the existing trust service criteria, security, availability, processing integrity, confidentiality, privacy, the same way any other significant system does. What's changed is that auditors increasingly expect specific, AI-relevant evidence within each of these existing categories, rather than accepting a generic response that never addresses how AI systems are actually controlled.
Security criteria need AI-specific access control evidence
Within the security criteria, auditors reviewing an organization with significant AI systems increasingly ask about access control specific to those systems: who can modify a system prompt or agent configuration in production, what authorization exists for tool calls with real-world effect, and how these controls actually get evidenced rather than just described. Preparing evidence here means having audit records showing these AI-specific access controls actually operating, not just general access control evidence for the surrounding infrastructure.
Availability criteria extend to AI-specific failure modes
Availability evidence traditionally focuses on infrastructure uptime and disaster recovery. For AI systems, that extends to questions about fail-safe behavior during degraded conditions, covered elsewhere in this content series: does the system fail toward denying sensitive actions when a policy or approval dependency goes down, and is that behavior actually tested rather than assumed to work. Evidence here should show both conventional availability metrics and this AI-specific fail-safe testing.
Processing integrity criteria connect to output validation
Processing integrity, whether a system processes data completely, accurately, and as intended, connects directly to the output validation covered throughout this content series for AI systems specifically: whether generated output gets checked against expected format and business rules before it takes effect. Auditors examining processing integrity for an organization with AI-driven decision-making increasingly want to see evidence of this specific validation, not just general data processing controls that predate the organization's AI features.
Confidentiality criteria need AI-specific data flow evidence
Confidentiality evidence for AI systems needs to address the specific data flow questions covered throughout RAG and data security guidance: what data enters model prompts, how retrieval respects existing access boundaries, what happens to sensitive content in logs and traces. Generic confidentiality evidence describing conventional database access control doesn't address any of these AI-specific data flow questions, and auditors increasingly probe for this specific detail rather than accepting general assurances.
Privacy criteria require attention to AI-specific data subject rights
For organizations including privacy in their SOC 2 scope, evidence needs to address the AI-specific data subject request challenges covered elsewhere: whether deletion requests actually reach embeddings and derived data stores, and whether the organization has mapped where personal data might exist across its AI pipeline, not just its primary application database.
Build a mapping between AI-specific controls and each trust service criteria
Rather than treating AI-specific evidence as an afterthought bolted onto an existing SOC 2 evidence package, build an explicit mapping showing which AI-specific controls and evidence correspond to which trust service criteria, reviewed alongside the organization's existing SOC 2 evidence mapping. This exercise surfaces gaps early, evidence an auditor is likely to ask for that the organization hasn't yet built a way to produce, while there's still time to close it before the actual audit period starts.
Coordinate with whoever owns the SOC 2 program directly
AI governance and security teams should coordinate directly with whoever owns the organization's SOC 2 program and auditor relationship, rather than building AI-specific evidence in isolation and hoping it lines up with what the audit actually requires. This coordination makes sure AI-specific evidence gets framed and organized in the format the audit process expects, instead of being technically sufficient but presented in a way that creates extra translation work during the actual audit.
Where TELEON fits
TELEON's audit trail and policy enforcement, applied through the gateway or supported middleware, produce evidence directly relevant to the security, availability, and confidentiality criteria discussed above: access authorization records, fail-safe behavior evidence, and data flow visibility for agent and tool activity.
Mapping this evidence explicitly to the organization's specific SOC 2 scope, and coordinating with the audit process owner, remains organizational compliance work that has to be done directly by the team managing the SOC 2 program.
A short checklist
- Prepare AI-specific access control evidence for the security criteria.
- Test and document fail-safe behavior under degraded conditions for
availability criteria.
- Prepare output validation evidence for processing integrity criteria.
- Document AI-specific data flow controls for confidentiality criteria.
- Address AI-specific data subject request handling for privacy criteria,
where in scope.
- Build an explicit mapping between AI-specific controls and each trust
service criteria.
- Coordinate directly with the SOC 2 program owner rather than building
evidence in isolation.
AI systems fit within existing SOC 2 trust service criteria, but auditors increasingly expect specific evidence addressing how those criteria apply to AI-specific risks, and preparing that evidence proactively, mapped explicitly to each criteria, avoids scrambling to produce it for the first time during an actual audit period.