Why your SOC 2 won’t protect you from AI risk
SOC 2 and HITRUST weren’t designed for AI. That leaves a gap between traditional compliance and AI-specific risk.
The dangerous assumption: “We have SOC 2 Type II and HITRUST certification. Our AI systems are compliant.” I hear this constantly from healthcare vendors. It reflects a misunderstanding of what these frameworks actually cover, and of what they leave untouched.
What SOC 2 and HITRUST actually cover
SOC 2 and HITRUST are strong frameworks for IT security, and an auditor working through either one will look hard at the same set of things:
- Access controls and identity management
- Network security and encryption
- Change management and deployment processes
- Incident response and business continuity
- Physical security and data center controls
Those controls matter, and every healthcare organization should require them from vendors. But the frameworks were written for traditional IT systems: databases, web applications, infrastructure. They were not written for AI, and the difference shows up the moment a system starts generating its own answers.
The AI-specific risks they miss
AI systems carry risks that traditional IT compliance frameworks were never built to address. The table below sets the coverage side by side.
| Risk Category | SOC 2 / HITRUST | AI-Specific Need |
|---|---|---|
| Model Hallucinations | Not AI-specific | Guardrail invocation, outcome, and coverage evidence |
| Prompt Injection | Not AI-specific | Input validation attestation |
| Training Data Bias | Not AI-specific | Bias testing documentation |
| Model Drift | Not AI-specific | Performance monitoring |
| Decision-context records | Not AI-specific | Selected fields for covered outputs |
| Data Encryption | Covered | Covered |
| Access Controls | Covered | Covered |
| Incident Response | Covered | AI-specific extension needed |
The specific gaps
1. No inference-level accountability
SOC 2 requires logging around the scoped control environment, such as system access and administrative actions. By itself, it is not a per-inference AI traceability framework. When an AI makes a clinical recommendation, a standard SOC 2 report does not automatically require a record of every prompt, output, and model-specific decision path.
2. No guardrail verification
You might have guardrails, and a SOC 2 report may cover whether related controls exist and are operated within scope. What it is not designed to be is a per-inference event record. “We have a content filter” is a different statement from “here is a signed record of what the configured filter reported for this covered request,” and only the second one survives a question about a particular patient on a particular day.
3. No model behavior documentation
SOC 2 audits your change-management and control environment. Unless the engagement is scoped unusually broadly, it is not an assessment of model behavior, drift, or reproducibility for a specific input.
4. No third-party verifiability
A SOC 2 examination produces an auditor’s report on controls relevant to the selected Trust Services Criteria and stated period or date. That report can be important evidence about the control environment, but normally does not provide a portable record of what a configured AI control path reported for one specific action.
The bottom line: SOC 2 tells you something meaningful about a vendor’s IT control environment. It is not, by itself, a guarantee about model safety, hallucination rates, prompt-handling behavior, or clinical suitability.
What healthcare organizations actually need
For AI specifically, healthcare organizations need evidence that speaks to the risks of machine learning systems rather than to the racks the systems run on:
- Guardrail decision records: scoped records of what configured controls reported for covered inferences
- Model version claims: signed, covered fields identifying the reported model version for a request
- Decision-context records: selected fields for covered outputs; these records do not expose internal model reasoning or guarantee complete reconstruction
- Bias and fairness documentation: evidence of testing across demographic groups
- Independently checkable operational records: supported signatures and covered fields another party can verify, with scope and limitations stated
The framework convergence
New frameworks are arriving to cover AI-specific risks:
- NIST AI RMF: the emerging standard for AI risk management
- ISO 42001: AI management system certification
- EU AI Act: regulatory requirements for high-risk AI (including healthcare)
All of them ask for evidence that many organizations still struggle to produce. Inference-level capture, retention, and verification remain immature in a large share of deployments, which is why a vendor can hold a certificate and still have nothing to hand a reviewer who asks about one request.
What to ask your vendors
When evaluating AI vendors, don’t stop at “Are you SOC 2 certified?” Ask:
- Can you show which guardrails the configured path reports invoking for a specific inference, and corroborate execution and coverage?
- What evidence supports the model version reported for historical requests?
- Can a third party verify covered records without treating your internal logs or a signature as complete system truth?
- What’s your mapping to NIST AI RMF controls?
- How are you preparing for EU AI Act Article 12 requirements?
The strongest vendors will be able to answer both sets of questions: the traditional security questions and the newer ones about how specific AI behavior is recorded and reviewed.
The complementary approach
None of this makes SOC 2 and HITRUST optional. They remain essential and you should require them, because for any vendor handling sensitive data they are table stakes.
For AI systems, though, they are where the work starts rather than where it ends. Healthcare organizations need traditional IT compliance and AI-specific evidence together, and the vendors who understand that distinction are the ones worth talking to.
For the complete framework on what to demand from AI vendors, read our white paper.
Primary sources
Beyond SOC 2
Our white paper “The Proof Gap in Healthcare AI” details exactly what AI-specific evidence looks like, and the four pillars every healthcare organization should demand.
Read the White Paper