Your AI Is On-Premise. Your Prompts Are Still Leaving the Building.

Your AI Is On-Premise. Your Prompts Are Still Leaving the Building.
Here is a scene we see constantly. A regulated enterprise runs a serious data-sovereignty program: models deployed on internal infrastructure, inference traffic locked to a private subnet, contracts forbidding vendors from training on customer data. The architecture diagram on the wall looks immaculate.
Then someone pulls up the observability dashboard — traces, spans, prompt logs, retrieval chunks, tool-call arguments — and realizes that the entire agent's reasoning trace is being shipped, in real time, to a third-party SaaS endpoint outside the country. The model never left. The data left with it.
This is the least-discussed failure mode in private AI. Practitioners spend weeks on model placement and network segmentation, then wire up a two-line observability SDK import that quietly reintroduces the outbound data flow they just spent a quarter eliminating.
The telemetry default nobody reads the docs for
The modern agent stack is consistent in its defaults, and consistent in the direction it leaks.
Framework and observability vendors have converged on OpenTelemetry for instrumenting LLM calls — and its GenAI semantic conventions define span attributes carrying the prompt text, the completion, the model name, token counts, and tool-call arguments. That is exactly the payload a sovereignty program is trying to keep inside the perimeter. Tracing is not a metadata side-channel; it is a transcript of the workload.
The default destinations are well known:
- LangSmith, the observability platform from LangChain, is cloud-hosted by default. Tracing a LangChain agent sends prompt and completion content to a SaaS endpoint unless you explicitly configure a self-hosted deployment and point the client at it.
- Weights & Biases Weave and Braintrust both run in a cloud-first mode where traces are hosted on their platforms by default, with self-hosting or on-prem options available on higher tiers.
- Langfuse and Arize Phoenix are genuinely open-source and self-hostable — and Langfuse Cloud is a live hosted product, so the operational default is very often the hosted one.
- Datadog LLM Observability and Honeycomb are commercial APM platforms whose agents, model routers, and processors run inside your VPC but whose LLM-tracing backends are SaaS by design.
Note the asymmetry: the tracing SDK is almost always fine, because it just emits spans. The backend is the risk — and the backend is the part nobody looks at. An instrumented production agent and a compliant private AI deployment look identical in code review.
There is a second, quieter leak path: evaluation harnesses. Sweep frameworks, LLM-as-judge graders, and prompt-optimization tools routinely submit curated evaluation sets to a hosted model endpoint for grading. That data is usually the most sensitive slice you have — the examples your team deliberately chose because they are hard and revealing of failure modes.
And a third: error and crash reporting. Sentry, Rollbar, and Honeycomb all ingest exception payloads. If your traceback includes the prompt or the retrieved document chunk — and structured logging frequently does — your observability configuration has become a data export.
Why this is a compliance problem, not an engineering preference
Governance teams rarely model this exposure, so it stays invisible until an auditor asks where prompt logs physically live. But the obligations bite hard:
HIPAA. A prompt containing a patient's name, MRN, or lab result is PHI. If that prompt lands in a SaaS tracing backend, you have made a disclosure to a business associate that likely has no BAA with your covered entity, and your data inventory is now wrong.
GDPR. Prompt content is personal data. Routing it to a US or non-EU backend is a transfer that needs a lawful transfer mechanism and a transfer impact assessment. Relying on a vendor's generic "enterprise" posture is not the same as having assessed your telemetry path.
The EU AI Act. High-risk systems carry logging and documentation obligations, including automatically generated logs kept for traceability. Your audit trail sits wherever the spans land. A sovereignty claim that a regulator can disprove from your own vendor contracts is worse than no claim at all.
PCI DSS and sector regimes. Payment data and critical-infrastructure data carry retention, residency, and third-party-access requirements that your tracing configuration quietly participates in.
The uncomfortable symmetry: your observability stack is now a processor of your regulated data, and it is almost never on your vendor register, in your DPA, or in your DPIA.
The fix is a four-layer control, and layer one is the one that matters
The good news: this is tractable, and mostly boring infrastructure work. Here is the pattern we implement.
Layer 1 — Egress allowlisting at the network boundary. The AI platform's egress policy is default-deny, with allowlists for exactly the destinations the workload needs: inference endpoints, a package registry, an identity provider, and nothing else. The observability backend is either inside the perimeter or explicitly allowlisted with a documented rationale and a signed DPA. If you cannot articulate every destination an AI workload can reach, you do not have a sovereignty program — you have a diagram.
Layer 2 — Self-hosted telemetry backend. The most cost-effective decision in this article is to self-host the tracing and metrics backend: an OpenTelemetry Collector inside the perimeter exporting to a stack you operate — Prometheus or VictoriaMetrics for metrics, Grafana for dashboards, Loki for logs, Tempo for traces. This is commodity open-source software, it is not expensive, and it eliminates an entire class of third-party processor relationships. Most enterprises also get better observability, because they stop paying per-span for traces they cannot afford to retain.
Layer 3 — Redaction at the collector, not at the application. Scrubbing has to happen where the data is captured, or it will be missed by whichever team ships a new instrumentation call tomorrow. A collector-stage filter that drops or masks prompt bodies, retrieved chunks, and tool arguments is one enforcement point. Add an allowlist for span attributes rather than a denylist of phrases — denylists leak.
Layer 4 — Continuous egress verification. Policy is a control only if it is tested. Deploy canary tokens in prompt payloads and periodic synthetic probes that assert they never surface in any third-party endpoint. Then audit the vendor list quarterly: a new observability package in a dependency tree is a new processor relationship until proven otherwise.
Where to put the remaining effort
None of this means every workload needs sovereign infrastructure — teams that over-rotate get cut for over-engineering. The right move is to tier by data sensitivity, assign a deployment pattern per tier, and then verify the tier assignment matches what the runtime actually does. A "Tier 3 internal" agent that calls a hosted tool API or ships spans to a SaaS tracer is a Tier 1 workload in everything but the diagram.
We have also found it worth running a quarterly data egress rehearsal: pick a representative agent workload, run it against production-like data, and map every byte that leaves the boundary with packet-level evidence rather than architecture documentation.
Pi Data Science helps enterprises build private AI deployments that are actually private. We run egress audits across agent and inference stacks, design self-hosted telemetry architectures, implement collector-stage redaction, and put the data processing agreements and registers in place that the EU AI Act, GDPR, and HIPAA obligations assume you already have. If your AI runs on-premise but your prompts still land in a third-party dashboard, the fix is well-understood engineering — and we would be glad to scope it with you.
