Where your data actually goes when you send it to a commercial AI API

Series: 10 reasons to own your AI infrastructure, Post 3: Data sovereignty for sensitive workloads

In April 2023, Samsung Electronics became one of the first major enterprises to recognize a problem other enterprises would spend the next two years catching up to: cloud AI services and confidential corporate data are architecturally incompatible. Within weeks of identifying internal exposure incidents in its semiconductor division, Samsung banned generative AI tools on company devices, restricted prompt sizes for any approved exceptions, and started building its own.

By November 2023, Samsung unveiled Gauss, a family of three internal models for language, code, and image work. Gauss runs on Samsung's own infrastructure. The data does not leave the perimeter. As of 2025, Samsung's DX division operates entirely on Gauss for generative AI work, with ChatGPT permitted only under executive approval in specific divisions.

Samsung was early. They were also right. What's still happening at companies that haven't drawn the same conclusion is the more pressing problem: they assume their commercial API contract protects them. It does not, exactly. The only way to keep confidential data confidential is to not send it to someone else's servers.

Your enterprise tier contract has three exposures your legal team may not have caught

The major commercial providers all have enterprise tiers with privacy commitments. ChatGPT Enterprise says it does not train on your data. Claude API offers zero data retention to qualifying customers. Gemini for Workspace guarantees data stays confidential. All of these claims are contractually enforceable; the provider can be held to them under contract.

They are also narrower than they sound, in three specific ways:

Default retention is not zero. OpenAI's standard API has a 30-day retention window. Zero-retention requires abuse-monitoring exemptions not every customer qualifies for. Claude API's zero retention is "subject to Anthropic approval." If you are not on the qualifying enterprise contract, your prompts are sitting in a database for 30 days regardless of what your privacy policy promises your customers.

"No training by default" has non-default scenarios. ChatGPT Enterprise's training opt-out is the default state, but the contract describes circumstances where data may still be used: abuse review, safety classifier improvement, security investigation. These are categories that can expand under future policy revisions, and you do not control when those revisions happen.

Metadata still leaves your perimeter. Even when prompt content is contractually protected, request timing, frequency, prompt length, and access patterns are not. For some workloads, metadata alone is enough to violate confidentiality requirements: a law firm's API call frequency on a specific case, a healthcare provider's query volume on a specific drug, a financial institution's prompt patterns around a specific ticker.

None of these is a contract violation. All of them are reasons that "we use the enterprise tier" does not satisfy the regulatory and confidentiality requirements that enterprises in regulated industries actually have to meet.

Your enterprise tier contract satisfies your vendor. It does not satisfy your regulator.

For sensitive workloads, the regulatory floor is some combination of: data residency in a specified jurisdiction, isolation from other tenants, access auditability the regulated entity can produce on demand, subprocessor control, and right of refusal on changes. GDPR functionally requires all of these for EU personal data. HIPAA's business associate framework requires similar guarantees for protected health information. FedRAMP High, CMMC Level 2 and 3, and EU AI Act high-risk system obligations all add layered requirements on top.

A commercial AI API can satisfy some of these requirements through contract. It cannot, by architecture, satisfy all of them, because the regulated entity does not control the substrate.

Regulated workloads need more than a contract commitment. RLC Pro Hardened is Enterprise Linux purpose-built for the regulated environments your commercial AI contract cannot satisfy. Read the RLC Pro Hardened solution brief

How sovereign architecture makes data control structural rather than contractual

When you control the model, the inference stack, the data path, and the update cadence, you can make data residency, isolation, auditability, and subprocessor control architectural rather than contractual. The data does not leave a perimeter you control because there is no commercial endpoint to send it to. The audit trail is yours because you generated it. The subprocessor chain is whatever you decided it is.

Sovereign deployment does: eliminate the third-party-API exposure surface for the workloads that run on it; give you direct control over data residency without depending on a vendor's regional commitments; produce audit trails that are first-party rather than extracted from a vendor system; and let you satisfy regulatory frameworks that explicitly disqualify multi-tenant SaaS architectures.

Sovereign deployment does not: make the data magically more secure (misconfigured sovereign deployments leak the same way misconfigured commercial APIs do), eliminate insider risk (your engineers can still paste source code somewhere they shouldn't), or solve the shadow AI problem. If 45% of your employees are actively using AI tools and 67% of those are using them through personal non-corporate accounts (LayerX's 2025 Enterprise AI and SaaS Data Security Report), your sovereign deployment of an internal model does not stop them. Sovereign AI plus a sanctioned AI policy plus actual enforcement is the answer.

Sovereignty turns data control from a contractual question into an architectural one. Contracts can be renegotiated, breached, or interpreted differently in court. Architecture is what it is.

What to do this quarter

1. Map every place your enterprise data reaches an LLM. Sanctioned API calls. Embedded AI features in SaaS tools you already use. Employee browser-based access through personal accounts. The LayerX 2025 data suggests 67% of generative AI use in enterprises is through non-corporate accounts. If you have not measured, your map is a guess.

2. Classify data by what regulatory framework applies. Not every workload requires sovereign architecture. Most marketing copy does not. Customer support transcripts containing PII do. Legal work product, healthcare records, financial transaction data, and source code with embedded credentials need a different decision than a brainstorming chatbot.

3. For the regulated workloads, audit your current vendor commitments against the actual regulatory floor. "Enterprise tier" is a contractual commitment. Compliance is a legal obligation your vendor does not satisfy on your behalf. Read the data processing addendum, the subprocessor list, the retention policy, and the operational access provisions. If any of them does not match what the regulator requires, you have a compliance exposure that contract negotiation may not be able to close.

Samsung's path is now common. Amazon, Apple, JPMorgan, Bank of America, Citigroup, Verizon, and Deutsche Bank have all implemented restrictions on employee use of external generative AI for similar reasons. Most have since evolved from outright bans to structured use policies, with sensitive workload handling driving the internal build decisions. The logic is the same: identify the workloads where the perimeter is the legal requirement, and stop sending the data outside it.

The architectural answer for those workloads is sovereign AI.

Run your sensitive AI workloads on infrastructure you own entirely. Fuzzball orchestrates AI workflows on-prem, bare metal, or private cloud, with audit trails that belong to you, not your vendor. Read the Fuzzball solution brief