On-Prem LLM Execution Path: Air-Gapped, Hybrid, and In-Region AI for Regulated Operations

Why two paths instead of one

Enterprises rarely have one regulatory profile. A telecom carrier might run NOC analytics on Path A and mission-critical incident workflows on Path B. A hospital might use Path A for routine documentation and Path B for clinical decision support. A defense contractor might use Path B exclusively. Forcing a single path forces a single regulatory floor; offering two lets governance match the path to the workflow.

Path A — external approved LLM with capsule data only

The capsule (structure-preserving, differential-privacy-protected) is transmitted to an approved external LLM endpoint — ChatGPT, Claude, Gemini, Perplexity, or any LLM API. Raw operational data stays inside the enterprise environment. Only the capsule leaves. The LLM processes the capsule and returns a response in the same substituted form. The internal mapping layer restores the original values inside the trust boundary.

• Best for: workflows with regulatory profiles that allow external transmission of differentially-private capsules
• Strength: access to frontier model capability
• Constraint: requires approved external LLM endpoint and policy alignment

Path B — on-prem local lightweight model

A small private lightweight model runs entirely inside the enterprise environment. The capsule is processed locally. Zero external transmission. Used for air-gapped, classified, OT, and strictly regulated operations where any external endpoint is unacceptable.

• Best for: air-gapped networks, classified operations, OT environments, strict data sovereignty
• Strength: zero external exposure, full data residency
• Constraint: model capability is bounded by the local lightweight model footprint

Internal naming. The internal team sometimes refers to “10G” — public documentation uses lightweight on-prem model, small private model, local inference path, or on-prem/local execution path. The exact size is a deployment decision based on hardware and workflow.

Path selection: a decision framework

Deployment topologies

On-premise

Capsule Runtime + on-prem local lightweight model deployed inside the enterprise data center. Path B is the default. Path A is available only if a separate approved external endpoint is whitelisted by policy.

Air-gapped

Capsule Runtime + on-prem local lightweight model deployed in a fully isolated network. Path A is unavailable by design. Path B handles all workflows. Common for classified operations, defense, and high-regulation OT.

Hybrid

Capsule Runtime on-prem; both paths active. Policy routes individual workflows. Common for telecom and finance where some workflows tolerate external endpoints and others require local execution.

In-region (data sovereignty)

Capsule Runtime + lightweight model deployed in a specific region (e.g., EU for GDPR-bound workloads). Path A may also be allowed only to in-region external endpoints. Common for multinationals with regional data residency obligations.

Cloud (AWS Marketplace)

Capsule Runtime deployed via AWS Marketplace, with the customer’s cloud account hosting both the runtime and the local lightweight model. Path A optional based on policy.

Embedded integration

Capsule SDK embedded into an existing application (NOC console, ticket system, hospital portal, mission system). Both paths supported; the embedded application chooses per workflow.

Slack App

Capsule plug-in for Slack workflows. Path A typical for general-purpose teams; Path B for regulated teams routing through Slack as a UI layer over an on-prem runtime.

What happens technically inside Path B

1. Connector lane delivers operational data into the Capsule Runtime (REST, webhook, log tap, SDK).
2. Structure-preserving substitution replaces operational identifiers while preserving sequence and structure.
3. Differential-privacy-based protection bounds inference risk on the capsule.
4. The capsule is dispatched to the local lightweight model running inside the same network.
5. The model produces output in the same substituted form.
6. The internal mapping layer rehydrates the original operational identifiers in the output, inside the trust boundary.
7. The result is inserted back into the originating workflow (ticket, runbook, EHR field, mission summary).
8. Governance records the path applied, the policy invoked, and the audit trail.

No step in Path B reaches outside the enterprise boundary.

The Zero Exposure claim — scoped correctly

“Zero Exposure” is a claim that needs a scope to be defensible. The scoped versions LLM Capsule uses:

• Path A: “No raw operational data exposure to external LLMs.”
• Path B: “Zero external exposure in the on-prem / local execution path.”

Avoid unbounded “Zero Exposure” as a top-level slogan. The technical guarantee is path-specific and policy-conditional.

What buyers should evaluate

1. Path coverage. Are both paths supported, or only one?
2. Path policy granularity. Can different workflows use different paths under the same governance?
3. Local model footprint. What hardware does the on-prem lightweight model require?
4. Air-gap support. Is the runtime fully operable without external connectivity?
5. Mapping layer locality. Does the internal mapping layer stay local in Path A as well?
6. Audit per path. Is the path applied recorded per request, per workflow, per policy?

Key takeaways

• Two execution paths in one AI enablement data layer: external approved LLM with capsule (Path A) or on-prem local lightweight model (Path B).
• Path B handles air-gapped, classified, OT, and strictly regulated operations with zero external transmission.
• Selection is policy-driven per workflow; governance records the path applied.
• Six deployment topologies: on-premise, air-gapped, hybrid, in-region, cloud, embedded, Slack App.
• The “Zero Exposure” claim is scoped to the path: “no raw data exposure to external LLMs” (Path A) or “zero external exposure” (Path B).