Enterprise AI Security: Beyond SOC 2

SOC 2 Type II is now the minimum viable compliance story for enterprise software. Any vendor without it faces an uphill procurement conversation. For AI platforms that index your internal knowledge — contracts, clinical data, financial models, unreleased product roadmaps — SOC 2 is a starting point, and not much more. The audit covers a set of operational controls that were designed for a pre-AI threat model. The risks that actually matter for enterprise AI security are almost entirely outside its scope.

What SOC 2 Actually Audits (and What It Misses)

SOC 2 audits operational controls across five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. In practice, most enterprise software vendors pursue the security and availability criteria. The audit verifies things like: are access permissions managed and reviewed? Is there a change management process? Is there an incident response plan? Are encryption controls in place for data at rest and in transit?

These are legitimate controls. They matter. They are also not remotely sufficient for evaluating an AI platform's data handling.

SOC 2 does not address: where your data goes during model inference. Whether your documents or query logs are used to improve the provider's models. Whether your indexed embeddings are isolated from other customers' data or commingled in a shared vector store. What happens to your data — including embeddings, which encode the semantic content of your documents — if you terminate your contract. How long query logs are retained and who has access to them internally at the provider.

A vendor can be fully SOC 2 Type II compliant and still send every document you index through a shared inference cluster, log every query indefinitely, and use your data to fine-tune their next model release. None of that violates the SOC 2 criteria. The audit simply does not reach those questions.

The AI-Specific Threat Surface

Enterprise AI introduces three threat vectors that traditional security frameworks were not designed to address.

Inference leakage. When you send a query to a cloud AI provider, your query — and the document context retrieved to answer it — traverses an external network and is processed on infrastructure you don't control. For most queries, this is low risk. For queries that touch privileged legal communications, unreleased financial data, or protected health information, this is a data egress event. The fact that it happens through an encrypted API call doesn't change the underlying reality: sensitive information left your environment.

Training contamination. Until 2023, several major AI providers trained on customer interactions by default. Enterprise agreements have tightened considerably since then, and most now include explicit training exclusions. But contractual exclusions and architectural reality are different things. If your queries and documents reach a provider's infrastructure, you are relying on their internal controls — not your own — to enforce that exclusion. Enforcement is opaque. Verification is impossible. The risk is not theoretical: at least two major AI providers have faced regulatory scrutiny over how customer data was used in model development.

Data remanence. When you close your account with an AI platform, what happens to your indexed knowledge? Most vendors commit to data deletion within a defined period. Embeddings are the non-obvious risk here. Your documents are encoded as dense vectors that capture their semantic content. Embeddings are not the original text, but they are not meaningless either — with sufficient reconstruction effort, embeddings can reveal the approximate content of the documents they were generated from. Whether vendor deletion procedures extend to embedding stores, backup systems, and derived model weights is rarely specified in standard enterprise agreements.

The Compliance Framework Gap

HIPAA, GDPR, FINRA, and SOC 2 were written for a world where data stays within defined boundaries. The compliance model assumes you know where your data is, who can access it, and what it is being used for. AI inference breaks all three assumptions.

HIPAA's Business Associate Agreement framework requires that covered entities enter BAAs with any vendor that handles protected health information. Most enterprise AI vendors will sign a BAA. But the BAA governs the vendor's obligations — it does not change where inference happens or whether the data is processed securely during that inference. A signed BAA with a cloud AI vendor that runs inference on shared infrastructure is a contractual instrument, not an architectural guarantee.

GDPR's data residency and purpose limitation requirements are similarly strained by cloud AI. Article 5's requirement that personal data be "collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes" creates real ambiguity when queries containing personal data are sent to a cloud AI provider for inference. Is inference a compatible purpose? Is it processing under GDPR at all? Legal teams interpret this differently. The ambiguity itself is a compliance risk.

FINRA's communication supervision requirements demand that firms maintain complete records of communications with customers. If AI assists in drafting those communications, the audit trail needs to capture what information the AI used and where it came from. Cloud AI providers don't generate audit logs in the format FINRA examiners expect. Compliance teams end up building manual logging systems as a workaround — which is fragile, expensive, and incomplete.

The risk-averse choice is increasingly architectural rather than contractual. Contracts bind vendors to obligations. Architecture eliminates the exposure entirely.

12 Questions to Ask Your AI Vendor

Before signing an enterprise AI agreement, get written answers to these questions. Vague responses are informative.

1. Where does inference happen? Specifically: which cloud regions, which infrastructure providers, and can you guarantee data residency within a specific geography?

2. Are my documents or queries used for model training? Ask for the specific contractual clause, not a verbal assurance. Ask whether this applies to fine-tuning as well as pre-training.

3. Are my embeddings isolated from other customers? Shared embedding infrastructure is more common than vendors advertise.

4. What is your data deletion policy? What is deleted, when, and how? Does deletion extend to embeddings, backups, and derived model artifacts?

5. Can I audit what data was sent during inference? What logs exist? Who can access them? In what format are they available for export?

6. Can you support VPC deployment or on-premise inference? If yes, what does the architecture look like? What external dependencies remain?

7. Do you have a BAA for HIPAA-covered workloads? If yes, does it cover AI inference specifically?

8. What happens to my data if I terminate the contract? Timeline, process, and verification mechanism.

9. Who at your company has access to my indexed documents? Support engineers? ML researchers? Is access logged?

10. Do you conduct third-party penetration testing? How recent? Can you share the executive summary?

11. How do you handle a data breach that involves customer knowledge bases? Specifically: notification timelines, scope of investigation, and remediation obligations.

12. Are there subprocessors involved in inference? Many AI platforms use third-party infrastructure — GPU cloud providers, embedding API services — that introduce additional data exposure points. Who are they and what are their obligations?

The Architectural Answer

Air-gap deployment eliminates these questions because the AI never calls home. On-premise inference means the entire processing pipeline — embedding generation, vector search, reranking, model inference — runs within your infrastructure. There is no external API call during query execution. There is no outbound data transfer. The threat surface is your own infrastructure, which your security team controls and audits.

This is not a trade-off for highly regulated industries — it is the only architecture that fully resolves the compliance framework gap. Contractual protections are valuable. Architectural guarantees are more valuable. When the model runs on your hardware, the answer to "where did my data go during inference?" is: nowhere. It stayed here. You can verify that. Your auditors can verify it. Your customers can verify it.

For a detailed look at how to evaluate your current or prospective AI vendor's enterprise AI security posture, see the companion questions above as a starting framework.