01 · DIAGNOSTIC FRAMEWORK

Turn the symptom into a testable decision.

Private does not describe one hosting location. It describes enforceable boundaries for data, models, tools, identity, logs and human approval. The sequence below is designed to preserve definitions, expose alternative explanations and lead to a decision that can be validated.

  1. Map the full data pathInclude connectors, temporary files, retrieval indexes, telemetry, support logs, backups and model-provider retention.
  2. Classify each taskDifferent tasks can route to different models and environments based on data sensitivity and required capability.
  3. Constrain toolsUse scoped read-only credentials by default, explicit write approvals and per-action audit events.
  4. Minimize and transformRetrieve only required fields; redact or tokenize identifiers before any boundary crossing.
  5. Verify controls continuouslyTest access denial, prompt injection, secret leakage, rollback, incident response and deletion.
02 · EVIDENCE

Ask for the minimum data that can change the answer.

Begin with read-only access and a field-level purpose. Reconcile samples before scaling extraction, preserve event time and source provenance, and record missingness rather than silently filling it.

Data inventorySource owner, classification, residency, purpose, fields, retention and downstream copies.
Identity and accessUser, service account, role, connector scopes, approvals, key custody and session lifetime.
Model and tool registryProvider, version, hosting, training/retention terms, allowed data classes and callable actions.
Audit evidenceRetrievals, tool calls, decisions, approvals, exports, errors, model version and policy result.
03 · PROOF OF CONCEPT

Validate the claim before changing the operation.

Prove the boundary with adversarial tests

Deploy one representative workflow and attempt prohibited actions: retrieve an unauthorized document, exfiltrate a canary secret, invoke a blocked write, cross tenant boundaries, retain a deleted record and bypass an approval. Verify that controls stop the action and logs explain why. Functional accuracy is only one acceptance criterion; boundary failure should block promotion.

04 · FAILURE MODES

What makes the diagnosis look right and still fail.

  • Calling an API privateProvider retention, support access, telemetry and subprocessors may still cross the intended boundary.
  • Giving the agent a user tokenBroad credentials turn a reasoning error into an enterprise-wide action.
  • Logging everythingPrompts and traces can recreate the sensitive data the architecture meant to protect.
  • Redacting after retrievalThe system already crossed the boundary before the protection ran.
  • Assuming on-premises is sufficientLocal hosting still needs identity, isolation, patching, model provenance and incident response.
05 · SOURCE TRAIL

Primary and official references

These sources define the measurement, control or operating context. They do not replace validation on the company’s own data.

  1. NIST SP 800-207, Zero Trust Architecture
  2. CISA, Secure by Design
  3. OWASP, Top 10 for LLM Applications
  4. NIST, AI Risk Management Framework
06 · FAQ

Questions enterprise teams ask first.

Does private AI require an on-premises model?

No. The right deployment depends on the data class, contract, jurisdiction and task. Some tasks fit isolated SaaS; others require customer cloud, on-premises or offline execution.

What should be retained?

Retain the minimum evidence required for audit and improvement, with explicit fields and expiry. Avoid retaining raw source material by default.

How should write access work?

Use narrow action-specific credentials, previews, policy checks and human approval for consequential operations.

Can confidential data be used with external models?

Only if the chosen boundary, contract, technical controls and customer policy permit it. Route or redact per task rather than using one global rule.