Private AI for Business: Keeping Company Data Yours

A security lead signs off on an AI vendor because the sales deck says "your data stays private." Nine months later, during a customer's own vendor review, she is asked a specific question: does the model provider retain prompt content, and for how long? She goes looking for the answer and finds that the AI platform she bought is a thin layer over a model API, that provider's default terms allow retaining request payloads for a stated window for abuse monitoring, and nothing in the contract she signed says otherwise. Nobody lied to her. The phrase private AI simply meant something different to the vendor than it did to her.

This is the central problem with buying private AI for business use. The term is not a standard, it is a marketing category covering at least four genuinely different architectures, each solving a different threat. A buyer who cares about one of them and buys a vendor delivering a different one has not bought protection, they have bought a sentence in a deck. The four are worth separating precisely, because they carry different costs, different failure modes, and different contract language.

Private AI is four different promises wearing one name

Here is the map. Every vendor claiming privacy is delivering one or more of these, and almost never all four.

Most procurement failures come from a mismatch, not a lie. The buyer wants tenant isolation and hears "private AI platform," which the vendor uses to mean a no-training term with their upstream model provider. Both parties leave the call satisfied and the risk stays exactly where it was.

There is also an ordering people get backwards. Self-hosting is the loudest of the four and the least commonly necessary. Tenant isolation is the quietest and the most load-bearing, because it guards the failure mode that would be a genuine incident: your data appearing in someone else's session.

Promise one: the model runs on infrastructure you control

Self-hosting is the strongest form of private AI and the one most companies talk themselves into before checking the price. You take open-weight models, run them on GPUs in your own cloud account or on physical hardware, and no prompt leaves your network perimeter. For a defense contractor, a company under a residency mandate, or a team whose entire product is a proprietary corpus, this is sometimes the only acceptable answer.

The costs are real and they are not primarily the GPUs.

Capability gap. Open-weight models have improved enormously, but the frontier is still where the frontier is. If your use case is summarizing support tickets, the gap will not bother you. If it is multi-step reasoning across messy business data, you will feel it, and your users will compare the output to whatever consumer assistant they use at home.

Operational load. Somebody has to own inference serving, upgrades, evaluation after each upgrade, and capacity planning. That is a role, not a task. Small teams underestimate it because the first deployment is genuinely easy and the twelfth month is not.

Utilization economics. A dedicated GPU costs the same whether it serves ten thousand requests a day or four. Metered API pricing looks expensive on a spreadsheet and cheap in practice for spiky internal workloads, which is most business AI. OpenAI API Pricing for Teams: How Token Billing Works covers the mechanics that make the self-host versus API math swing.

The honest rule: self-host when a regulator, a contract, or a national boundary requires it, not because it feels safer. Feeling safer is not a control, and a badly operated private cluster with stale access rules is worse than a well-configured API relationship.

Promise two: your data is not used for training

This is the promise most buyers actually care about, and the one that is cheapest for a vendor to make and cheapest for a buyer to verify.

The question is not "do you train on customer data." Every vendor says no now. The questions that matter are narrower:

• Does the commitment bind the vendor, the upstream model provider, or both? A platform can promise it does not train on your data while passing prompts to a provider whose default terms allow exactly that.
• What is the retention window for prompt and response content, and what is it for? Abuse monitoring retention is common and often reasonable, but you need the number in the contract, not in a help center article that can change.
• Does human review ever occur, and under what trigger? Safety pipelines sometimes route flagged content to reviewers. That is defensible. Discovering it after the fact is not.
• Are embeddings and derived artifacts covered? Your raw documents may be protected while the vector representations of them are not.
• On termination, what is deleted, and in what timeframe across backups?

The failure pattern here is subtle. A company adopts a paid tier with a strong no-training term, then twenty employees paste customer lists into whatever free tool solves their afternoon. The contract is fine, the exposure happened anyway. Free AI Data Analysis Tools: Where They Help and Stop is a fair look at what those tools do and do not commit to with the data you hand them.

Promise three: tenant isolation, and what "logically separated" means

Tenant isolation is the promise that your company's data cannot surface in another company's session. It is the one that would generate an actual breach notification if it failed, and the hardest to evaluate from outside. The phrase to interrogate is "logically separated," which usually means one of three architectures.

Then there is the layer specific to AI products, and where isolation most often actually breaks: retrieval. An assistant answers by pulling context from an index. If the index is shared and filtering happens after retrieval rather than inside it, a well-phrased question can surface content the asker should never see. This applies within a company too: the finance team's documents and the intern's documents can sit in the same index, and permission enforcement at retrieval time is what keeps salary data out of a general question about headcount.

So ask two questions rather than one. Is my company isolated from other customers, and inside my company, does the assistant respect the permissions my source systems already enforce? A vendor that answers the first crisply and gets vague on the second has told you something important.

Also ask who at the vendor can read your data during support. The good answer is: access is time-bounded, requires approval, is logged, and the logs are available to you. The bad answer is a reassuring adjective.

Promise four: bring your own key

BYOK is the least discussed of the four and the most structurally interesting, because it changes who the model provider's customer is.

Under the normal arrangement, a platform buys inference capacity and resells it inside a subscription. Your prompts travel under the platform's commercial contract, you inherit whatever terms they negotiated, and the margin on inference is invisible to you.

Under BYOK, you hold the account with the model provider. You supply your API key, the platform calls the model with it, and the relationship between your data and the provider is governed by your agreement with them, including any enterprise terms, zero-retention arrangements, or regional endpoints you negotiated. Three consequences follow:

Contractual clarity. There is one fewer party between your data and the model. When a customer asks who processes your prompts, the answer is a provider you contracted with directly, on terms you can produce.

Cost transparency. You see actual consumption in your own provider dashboard rather than a bundled seat price with unknown inference margin, which matters to anyone evaluating a private LLM for companies at scale.

Portability. Switching models is a key swap rather than a vendor migration, which quietly reduces lock-in.

BYOK is not a security control by itself. It does nothing about tenant isolation, it does nothing about retrieval permissions, and it does not stop an employee from pasting a customer list somewhere else. What it does is remove one intermediary from the chain of custody and put your usage under terms you control. That is a narrower claim than "secure private AI," and it is a true one.

The contract questions that pin down a private AI vendor

Sales calls reward vague questions. These are written to be hard to answer vaguely. Send them in writing, before the demo if you can, and accept only answers that reference a document.

That last row deserves care in both directions. A vendor saying it has controls in place is making a weaker statement than one holding a completed third-party attestation with a report you can read. Both can be honest. Only one is an audit. Buyers should ask for the distinction, and vendors should state it plainly rather than letting a logo imply more than it should.

When the evaluation widens beyond security to whether the platform can be built on, the checklist in Evaluating an AI Platform: Developer Ecosystem Checklist covers the API and extensibility questions that sit next to these.

What a private AI platform still will not protect you from

Four exposures survive every architecture above, and they cause more real incidents than model providers do.

Over-broad retrieval inside your own company. The assistant is only as safe as the permissions on what it can read. If your document store has been accumulating open link sharing for six years, an AI search layer will surface things a human would never have found. Fix the permissions before you point anything at them.

Shadow usage. Employees will use AI whether you buy it or not. The effective control is not blocking, it is giving people a sanctioned tool good enough to be the path of least resistance, and teaching them what may and may not be pasted anywhere. Prompt Fluency at Work: Training Teams Beyond Engineers covers that training side, which matters more than most policy documents.

Output handling. A perfectly private query produces an answer someone pastes into a shared doc, a channel with contractors in it, or a customer email. Privacy at the model boundary says nothing about what happens next.

Copies you already made. Every export, every warehouse replica, every spreadsheet on a laptop is another surface. The tradeoffs in ETL Tools Compared: How to Pick One Without Overbuying are worth reading before you create a new copy of your customer table to make an AI project easier.

One automation helps here: a recurring review of which AI vendors are actually being paid for, cross-checked against the ones your policy knows about. Shadow spend is the earliest visible signal of shadow usage.

Quarterly AI vendor review

First of the quarter

Scheduled trigger

Pull vendor charges

Read charges from the accounting and card tools

Filter to AI vendors

Match against known AI and model providers

Compare to approved list

Check each vendor against the reviewed register

Flag unreviewed vendors

Anything paid for but never security reviewed

Post to security channel

Summary with amounts and owners

Where Skopx fits, and where it does not

Skopx is an AI workspace that connects to nearly 1,000 tools a company already uses, including Gmail, Slack, Stripe, HubSpot, QuickBooks and Google Analytics. You ask questions in chat and get answers cited back to the source records, you get a morning brief, an insights engine surfaces risks and anomalies across connected systems, and you build automations by describing them in chat.

On the four promises, here is exactly where it sits, stated without stretching.

BYOK: yes, and it is the default posture. Inference runs on your own provider key, for any major model, with zero markup. Your prompts travel under your own agreement with the model provider, and consumption is visible in your own provider dashboard rather than bundled into a seat price.

Tenant isolation: yes, per-tenant data isolation. Your connected data is separated per tenant by the platform's architecture, and answers are drawn from the sources your account is connected to.

Audit posture: SOC 2 controls in place. That is the accurate phrase and it should be read literally. It describes controls, not a completed certification, and it is not claimed as one. If procurement requires a third-party attestation report, ask for the current status rather than assuming from the phrase.

Self-hosted models: no. Skopx is a hosted product. If your requirement is that weights and inference run inside infrastructure you control, Skopx is not the answer, and no amount of BYOK changes that. BYOK moves the contractual relationship to you, not the compute into your data center.

Two more boundaries, because they save discovery calls. Skopx is not a BI tool and does not build dashboards, it is not a data warehouse or an ETL pipeline, and it is not a CRM. It reads from the systems you already run and answers over them. If you need governed semantic models and pixel-controlled reporting, that is a different category, and Power BI Cost in 2026: Licenses, Capacity, and Extras is the honest place to start on what it costs. If you need engineered pipeline orchestration with retries and DAG semantics, Workflow Orchestration Tools vs Workflow Automation explains where the line falls, and what Skopx workflows do and do not try to be.

Pricing is Solo at $5 per month and Team at $16 per seat per month, listed on the pricing page.

A selection sequence that avoids the usual mistake

The usual mistake is starting with vendors. Start with the requirement instead, and the vendor list shortens itself.

1. Name the actual constraint. One sentence: what specifically must not happen, and who says so. A customer contract clause, a regulator, a residency law, or an internal policy. If you cannot name the source, you are buying comfort, and comfort is expensive at the self-hosted end.
2. Classify the data the AI will touch. Not all of it, the specific systems you will connect. Customer PII, financial records, source code, and HR data have different answers. Most business AI touches operational data that needs a no-training term and good isolation, not an air gap.
3. Pick which of the four promises the constraint requires. Residency law usually means self-hosted or a regional endpoint. Customer contract clauses usually mean no-training plus sub-processor transparency. Multi-tenant nervousness means isolation questions. Cost and lock-in concerns mean BYOK.
4. Send the contract questions in writing. Answers that reference a document beat answers that reference a philosophy.
5. Run a bounded pilot on real data with real permissions. Connect one team's actual tools and watch what the assistant can retrieve. Isolation and permission bugs show up in minutes here and never in a demo.
6. Decide what the tool may do, not just read. Anything that can send an email or change a record needs approval rules, and the honest starting point is read-only plus explicit confirmation for writes.

For teams whose goal is understanding their own numbers rather than locking down a corpus, Automated Data Interpretation Tools That Explain the Why is a useful companion, because the privacy question changes shape depending on whether the AI is reading documents or reading metrics.

Frequently asked questions

Is private AI the same as an on-premises deployment?

No, and conflating them is the most common error in this category. On-premises means weights and inference run on hardware you control. Private AI, as vendors use it, more often means a no-training contract plus tenant isolation on hosted infrastructure. Only one of those requires GPUs, an MLOps owner, and a capability gap against frontier models. Decide which you need before you price either.

Does bring your own key make a platform secure?

It makes the chain of custody shorter and the commercial terms yours, which is genuinely valuable. It does not by itself provide tenant isolation, it does not enforce document permissions at retrieval time, and it does not stop an employee from pasting sensitive data elsewhere. Treat BYOK as one of four controls, not as the whole answer to keeping company data private with AI.

What does SOC 2 controls in place mean compared to a certification?

Controls in place means the organization has implemented security controls mapped to the SOC 2 framework. A completed attestation means an independent auditor examined those controls over a period and issued a report you can request. The first is a statement by the vendor, the second is a statement by an auditor. Ask which one you are being offered, ask for the report date if one exists, and be wary of any vendor that blurs the two.

How do we stop employees using unapproved AI tools?

Blocking works poorly and generates workarounds. Two things work better. First, sanction a tool good enough that the unapproved option stops being worth the friction. Second, teach the specific rule rather than the general policy: which categories of data may never be pasted anywhere, and where the approved tool lives. Reviewing card and accounting charges for unfamiliar AI vendors each quarter catches the rest.

Do we need a private LLM for companies our size, or is a contract enough?

For most companies under a few hundred people, a strong contract plus good isolation plus BYOK covers the real risk. A private LLM deployment adds cost and operational burden without addressing the exposures that actually cause incidents: over-broad internal permissions and unsanctioned tool use. Revisit that if a contract, a regulator, or a residency requirement names infrastructure explicitly.

Where should we look first for leaks that have nothing to do with the AI vendor?

Sharing settings on your document store, tokens and service accounts created by people who have since left, and every exported spreadsheet sitting in personal folders. An AI assistant does not create these exposures, it makes them findable. Cleaning up permissions before connecting anything is the highest-leverage step in a private AI rollout.