SOC 2, with the Trust Services Criteria mapped onto your AI.
The five Trust Services Criteria don't change because your system runs on LLMs. The controls you need to defend each one do. We translate each TSC into AI-specific controls during the Discovery Sprint, before any auditor sees the system.
Same criteria. New controls underneath.
SOC 2 has always been about how the controls map to the system, not the labels on the controls. When AI enters a SOC 2 system, the auditor expects you to defend the same five criteria against the new realities: model upgrades, prompt handling, output filtering, vendor sub-processor management, drift, and evaluation. The criteria don't change; the controls do.
The most common gap we see in pre-Agrus SOC 2 packages is change-management: model upgrades treated like routine library upgrades, with no eval-suite re-run, no rollback plan, no auditor-readable evidence. Fixing this in a mature codebase is painful; designing it in from the start is straightforward.
Each Trust Services Criterion translated into AI-specific controls.
Security
Access controls, change management, vulnerability management, monitoring, incident response. AI-specific: model-update change management, prompt-injection threat modeling, agent action authorization.
Availability
Performance monitoring, capacity planning, environmental protections, disaster recovery. AI-specific: model fallback chains, inference timeout policies, GPU capacity reservation, multi-region failover for high-availability workloads.
Processing Integrity
System processing is complete, valid, accurate, timely, and authorized. AI-specific: model drift detection, eval-suite execution cadence, output verification on consequential decisions, human-in-the-loop where stakes warrant.
Confidentiality
Information designated confidential is protected. AI-specific: prompt and output handling, conversation retention policies, multi-tenant carve-out architecture, training-data prohibitions enforced through contract and architecture.
Privacy
Personal information is collected, used, retained, disclosed, and destroyed per the entity's privacy notice. AI-specific: explicit consent for AI processing of personal data, right-to-deletion enforcement across vector stores and logs, transparency about model decision-making.
The control most teams under-build.
Model upgrades are the silent SOC 2 risk in AI systems. The upstream model gets retired or upgraded; your inference layer quietly starts producing slightly different outputs; behavior drifts; auditors can't trace the change because it's not in your release log.
The fix: treat model-version pinning as part of change management. Every model change goes through:
- Pre-promotion eval against the same suite that validated the original
- Drift report comparing key metrics
- Risk classification (low / moderate / high) gated on metric movement
- Sign-off proportional to risk — auto-promote on no-change, human review on moderate, full release-management cycle on high
- Rollback path tested and documented
- Auditor-readable evidence: model version, eval results, sign-off chain, deployment timestamp
This is one of the deliverables of the Managed SLA tier. For customers operating themselves, we leave the eval suite and the change-management runbook as part of the build.
An audit should be evidence retrieval, not evidence production.
The Agrus default: every SOC 2 control has its evidence destination defined during the Discovery Sprint. As the system runs, evidence accumulates in the right place automatically — log streams to the SIEM, change-management entries in the release system, eval results in the artifact store, attestation snapshots on schedule.
When the auditor asks for evidence of control X, the answer is a query, not a project. Customers who run SOC 2 with us tell us the audit phase is the easiest one — the hard work happened during the build.
Frequently asked questions
Is SOC 2 required for AI deployments?
Not by regulators — SOC 2 is a voluntary attestation. But it's increasingly demanded by enterprise customers as part of vendor-onboarding, by sophisticated LPs of PE firms, by health-system buyers of healthcare SaaS, and by regulated industries as a baseline for any vendor relationship. In 2026, most B2B AI vendors need SOC 2 Type II to win mid-market and enterprise deals.
What's new about SOC 2 when AI is involved?
The Trust Services Criteria are unchanged. What's new is the set of design decisions you have to defend for each criterion. Change management has to cover model upgrades, not just code releases. Confidentiality has to cover prompt and output handling, not just database access. Processing Integrity has to cover model drift, not just transaction integrity. We translate each criterion into AI-specific controls during the Discovery Sprint.
Do you produce the SOC 2 report?
No — we don't issue SOC 2 reports. That's the audit firm's job. We design the controls, produce the evidence, walk through the audit with your team. We have referral relationships with audit firms that understand AI systems specifically; we'll introduce you.
How long does it take to get SOC 2 Type II ready for an AI deployment?
Type I (point in time) is achievable in roughly 8-12 weeks of dedicated work after the architecture is set. Type II requires a continuous-evidence window — typically 3-6 months minimum. Plan accordingly: most customers run Type II observation in parallel with the production deployment so the report is ready when sales asks for it.
Get a SOC 2 control map for your AI deployment.
Discovery Sprint produces the map and pre-stages the evidence. $15-30K fixed.