Private AI for Business: Deployment Options, Data Residency and Keys Explained

TL;DR

• Private AI for business means AI that runs where your security team says it runs, on data that never trains someone else's model, under keys and permissions you control. There are five deployment options, from public SaaS to air-gapped on-prem.
• The right option depends on your data, not on fashion. Most companies are well served by a business plan or a VPC deployment in their own cloud. Air-gapped on-prem is for data that legally cannot leave the building.
• Secure AI for business turns on four questions: where data is stored and processed, who holds the encryption keys, which models see it, and what agents may do inside your systems.
• Sentra deploys in the cloud, an isolated VPC or air-gapped on-prem, respects each source's permissions at query time, and requires a named person to approve before it acts.

What private AI for business means

Private AI for business is the use of AI models on company data inside a boundary the company controls, with contractual and technical guarantees that the data is not used to train shared models, is stored where the company chooses, and is visible only to people and systems allowed to see it. Secure AI for business adds the operating controls around it: identity, encryption keys, audit logs and limits on what AI agents can do.

Private does not have to mean self-hosted. A ChatGPT, Claude, Copilot or Gemini business plan is already private in the narrow sense, because each vendor states that business data is not used for training by default (openai.com, privacy.claude.com, learn.microsoft.com, cloud.google.com). The question for a CIO or CISO is how much further you need to go, and what each step costs.

The questions buyers actually ask

On calls with CIOs, CISOs and CEOs, the same questions come up in almost every order:

• Can it run in a VPC inside our own AWS account?
• Where exactly is our data hosted, and where is it processed?
• Can we bring our own encryption keys, or run the models on Amazon Bedrock?
• Will AI agents access our internal systems, and what stops them doing something we did not approve?

Each question maps to one design decision. The rest of this guide takes them in turn.

Five ways to deploy private AI

Public SaaS on a business plan

This is ChatGPT Business or Enterprise, Claude Team or Enterprise, Microsoft Copilot or Gemini Enterprise. The vendor runs everything. You get contractual data terms, SSO and admin controls. OpenAI, for example, encrypts business data with AES-256 at rest and TLS 1.2 or higher in transit, and lets qualifying organisations set retention periods (openai.com).

The trade-off is location and control. Your data sits in the vendor's environment, and you depend on the vendor's region options.

Single-tenant SaaS

The vendor runs a dedicated instance for you. You avoid sharing compute and storage with other customers, and the vendor still handles upgrades. It suits companies whose security reviews reject multi-tenancy but who do not want to operate software.

VPC deployment in your own cloud

The software runs inside your own cloud account, in a VPC you control. This is what most "can it run in our AWS account" questions are really asking for. Data stays in your account and region, network traffic can be kept off the public internet, and your existing cloud logging and security tools apply.

On AWS, the building blocks are documented. AWS recommends a VPC with an interface endpoint through AWS PrivateLink, so that data is not available over the internet (docs.aws.amazon.com). Bedrock supports encryption keys managed in AWS KMS and is in scope for ISO, SOC and CSA STAR Level 2, is HIPAA eligible, and is FedRAMP High authorised in AWS GovCloud (US-West) (aws.amazon.com).

On-prem and air-gapped

The software runs on your hardware with no connection to the outside. Nothing leaves. This is the strongest guarantee and the heaviest to operate: you own patching, capacity and model hosting. Choose it when regulation or contract requires it, not as a default.

Self-hosted open models

Self-hosted AI, often called an on-prem LLM when it runs in your own data centre, means you download open-weight models and run them on your own GPUs. You control the model, its version and its logs completely. You also own its quality, safety testing and cost. Many companies use self-hosted models for narrow, high-volume tasks and a managed frontier model for the rest.

Trade-offs: private LLM vs managed models

A private LLM, meaning a model you host yourself, gives you the most control. A managed model through a cloud provider gives you most of that control with far less work.

On Amazon Bedrock, model providers have no access to the accounts where their models run, so they cannot see customer prompts or completions (docs.aws.amazon.com). On Microsoft Foundry, prompts and completions are not available to OpenAI or other model providers and are not used to train foundation models (learn.microsoft.com). For most companies that is enough privacy without running GPUs.

Data residency: where data is stored and processed

Data residency has two parts that vendors often blur: where data is stored at rest, and where it is processed during inference. Ask about both.

• OpenAI. Eligible ChatGPT Enterprise and API customers can store content at rest in the US, Europe, the UK, Japan, Canada, South Korea, Singapore, Australia, India or the UAE, and can opt into in-region inference in the US or Europe (openai.com).
• Microsoft Copilot. EU traffic stays within the EU Data Boundary. Outside the EU, queries may be processed in the US, EU or other regions. Advanced Data Residency and Multi-Geo add commitments (learn.microsoft.com).
• Microsoft Foundry. Standard deployments process prompts in your chosen geography. Global and DataZone deployments may process them in other regions, while data at rest stays in your geography (learn.microsoft.com).
• Amazon Bedrock. Retention is configured per region. If cross-region inference is on, retained inputs and outputs are stored in the region where the request was processed (docs.aws.amazon.com).

For personal data of EU residents, GDPR Chapter V governs transfers to third countries, through adequacy decisions or appropriate safeguards (gdpr-info.eu). Map your data classes to regions first, then choose the deployment that satisfies the strictest class.

Model and key choices: bring your own key and Amazon Bedrock

Bring your own key, or customer-managed keys, means your organisation creates and controls the encryption keys that protect stored data. Revoke the key and the vendor can no longer read it.

• OpenAI offers Enterprise Key Management for customers who want to control their own keys (openai.com).
• Amazon Bedrock lets you create, manage and control keys in AWS KMS (aws.amazon.com).
• Microsoft Foundry encrypts stored data with AES-256 by default, with an option for a customer-managed key (learn.microsoft.com).
• Gemini Enterprise Standard and Plus support customer-managed encryption keys and VPC Service Controls (cloud.google.com).

Running models on Amazon Bedrock keeps inference inside AWS. Bedrock now lets you set data retention per region at the account or project level, including a zero-retention mode, and enforce it with service control policies across the organisation. Some newer models require AWS human review as a condition of access, retained in the AWS boundary for up to 30 days and not shared with the model provider (docs.aws.amazon.com). Check that requirement for each model you plan to use.

Will AI agents access our internal systems?

Agents are where private AI becomes a security question rather than a hosting question. An assistant that reads is one risk. An agent that writes to your ERP or sends email is another.

OWASP lists excessive agency, meaning an AI system with more permissions or autonomy than it needs, among the top ten risks for LLM applications (genai.owasp.org). Its prompt injection guidance recommends least-privilege access, handling privileged functions in code rather than through the model, and human approval for high-risk actions (genai.owasp.org).

In practice, require four controls before any agent touches an internal system:

1. Permissions inherited from the source. The agent sees only what the person it acts for can see, checked at the moment of the request.

2. Fail closed. If a permission check fails or times out, the answer is no access.

3. Named approval for actions. A specific person approves before anything is sent or changed.

4. A full record. Every action is logged with who approved it and on what evidence.

Our guide to AI agent permissions goes deeper, and shadow AI covers what happens when employees route around slow approvals.

Where Sentra fits in a private AI deployment

Most private AI projects secure the model and forget the context. The model may run in your VPC, but the company knowledge it needs is scattered across email, chat, meetings, ERP, CRM and HRIS, and each tool you add builds its own copy.

Sentra is the company intelligence and memory that sits inside your boundary. It deploys in the cloud, in an isolated VPC, or air-gapped on-prem. It reads email, chat, meetings, documents, ERP, CRM, HRIS and BI, works out what is true now and what changed, and knows when each fact became true and when it stopped being true.

The controls match the four agent requirements above. Every answer and action respects each source's existing permissions, through query-time checks and synced access lists, and a failed check counts as no access. A named person approves before Sentra acts or sends anything. Sentra holds SOC 2 Type II and ISO 27001.

Because Sentra serves its memory over REST and MCP, the assistant or model you choose, ChatGPT, Claude, Copilot, Gemini or an internal agent, uses the same permissioned context. You decide the model; the memory stays in your deployment. More on the architecture is in our enterprise AI memory guide.

To review deployment options against your security requirements, book a demo.

What to ask AI vendors about privacy

Send these before the first demo. Vague answers are a signal.

1. Which deployment options do you support: multi-tenant, single-tenant, VPC in our cloud, on-prem, air-gapped?

2. In which regions is data stored at rest, and in which regions is it processed during inference?

3. Is any of our data, including prompts, outputs and feedback, used to train models? Show the contract clause.

4. Can we use customer-managed keys, and what happens to our data if we revoke them?

5. Which model providers and subprocessors see our data, and under what terms?

6. How long are prompts, outputs and logs retained, and can we set retention to zero?

7. How are source-system permissions enforced: synced, checked at query time, or both? What happens when a check fails?

8. What can agents do without a human approving it?

9. Which certifications cover the exact product and deployment we are buying?

10. Can we export everything, including the context the product has built, if we leave?

How to start

1. Classify your data. Mark which classes may go to a business-plan SaaS, which must stay in your cloud, and which must stay on-prem.

2. Pick the deployment per class. Do not force everything into the strictest option.

3. Fix the model route. Decide whether models run through the vendor, Amazon Bedrock, Microsoft Foundry or Google Cloud, and set retention and keys there.

4. Set agent rules before agents. Write down permission inheritance, fail-closed behaviour and approval rules first.

5. Pilot on real data in the target deployment. A pilot on a vendor's shared cloud tells you little about how the VPC version behaves.

FAQ