The Data Residency Question
Public LLM APIs present an enterprise data governance challenge that most organizations have not fully resolved. When a user sends a prompt containing proprietary business information to an external LLM API, that data traverses the internet, is processed on the provider's infrastructure, and — depending on the provider's terms of service and the API product tier — may be used for model training. For consumer use cases, this tradeoff is generally acceptable. For enterprise use cases involving client data, financial information, intellectual property, or personally identifiable information, the tradeoff is not acceptable and may not be legally permissible.
Regulatory frameworks that govern enterprise data handling — GDPR, HIPAA, financial services regulations, government contracting requirements — impose specific requirements on where data can be processed, how it must be protected, and what consent is required for its use. Organizations that deploy public LLM APIs without understanding how their data handling intersects with these requirements are accumulating regulatory risk with every user query.
Architecture Options for Private Inferencing
Private inferencing — LLM deployment architectures that ensure enterprise data does not leave the organization's controlled environment — can be implemented at multiple points in the infrastructure stack. The most secure option is self-hosted open-source models (Llama, Mistral, or similar) running on the organization's own compute infrastructure: data never leaves the organization's network. The tradeoff is that self-hosted models require significant infrastructure investment and typically underperform the best commercial models on complex reasoning tasks.
A middle-ground option, suitable for most enterprise use cases, is using commercial LLM providers via private API endpoints with data processing agreements that prohibit training use. Amazon Bedrock, Azure OpenAI, and Google Vertex AI all offer enterprise tiers with contractual data non-use commitments and data processing configurations that keep data within the organization's cloud account. This approach combines commercial model quality with contractual data protection — a reasonable tradeoff for most enterprise risk profiles.
Access Control Within the LLM Context
Beyond data residency, enterprise LLM deployments must implement data access controls at the inference layer. A retrieval-augmented generation system that can access all company documents must ensure that the documents surfaced for a given user's query are limited to documents that user has permission to access. Without this control, the LLM becomes an access control bypass: a user without direct access to a sensitive document can use the LLM to extract information from it.
Implementing access control in the LLM context requires integrating the retrieval layer with the organization's identity and access management system: user identity is passed to the retrieval layer, which filters candidate documents against the user's access entitlements before including them in the LLM context. This integration is non-trivial but essential — it is the difference between an enterprise LLM deployment and a security liability.