Why “private AI” isn’t a buzzword: models and logs that never leave your boundary

Every vendor claims “secure” and “AI-powered.” Few spell out where models run, what gets logged, and whether your customer list trains their next feature. Trade owners are right to be skeptical, because the interesting questions are architectural and most decks answer them with adjectives.

The way to cut through it is to insist on a data-flow diagram and a threat model. Where does data live at rest, where does it move, and what is the trust boundary? Which of the classic threats—an attacker, a curious insider, a compromised dependency, a subpoena to the vendor—does the design actually mitigate? ‘Private AI’ is only meaningful as a set of answers to those questions.

Private deployment means the forward pass and the operational logs stay inside the boundary you control—on-prem or in your VPC—not in a multi-tenant pool where your job costing sits next to a competitor’s. The subtle part is that the obvious asset (the database) is rarely where pooled systems leak. The leaks are in the derived data paths that teams forget to classify.

Prompts and completions contain the customer and job data verbatim, so a prompt log shipped to a third party is an exfiltration channel. Embeddings built for retrieval are lossy but far from anonymous; they belong to the same trust zone as their source text. APM traces, error reports, and crash dumps routinely carry payload fragments. A credible private deployment keeps all of these—inference, vector indexes, prompt/response logs, and telemetry—inside the boundary, or scrubs them at the edge before anything leaves.

‘We don’t train on your data’ is a claim you should be able to verify, not just read in a contract. The strong version is architectural: if inference runs against your data inside your boundary and no training pipeline reads from that boundary, then there is no path by which your data reaches shared weights. Data lineage—being able to name every process that reads a given dataset—is what turns the promise into a property.

This is also why retrieval-augmented generation is the right default for domain knowledge instead of fine-tuning on customer data. RAG keeps your data in a store you control and pulls it into context at inference time; it never bakes your customer list into model weights that are hard to audit and impossible to un-learn. Personalization without contaminating shared weights is a design choice you can insist on.

Role-based access, SSO for larger teams, and approval policies are not IT luxuries—they are how you keep a dispatcher from approving a credit memo they should not touch, and how you keep the AI itself scoped. An agent acting on a user’s behalf should inherit that user’s permissions, not run as an omnipotent service account; otherwise the automation quietly becomes a privilege-escalation path.

The controls worth requiring are concrete: least-privilege roles mapped to real job functions, SSO/SCIM so access is provisioned and de-provisioned with employment, and an authorization check on every action—including automated ones—recorded in the audit log. ‘The AI did it’ should still resolve to ‘as which principal, with what rights.’

Run the evaluation like a design review. Ask for architecture diagrams under NDA and locate the trust boundary on them. Walk a failure scenario end to end: the model runtime is down, or a dependency is compromised—what data is exposed, and does billing still work? Confirm the egress allowlist and that integrations only touch third parties you already use. Ask how model and image updates are signed and rolled out, since that is a code path into your environment.

If the demo is all sparkle and no boundary diagram—if nobody can tell you where embeddings live or which principal an agent acts as—keep looking. The vendors worth trusting answer in topology, lineage, and access control, because those are the things that actually determine whether your data stays yours.