The local boundary does not end at the model

A company can run an LLM on its own server, deny it internet access, and still create a new leakage channel. The cause is often not inference but telemetry: a debugger, trace, or observability pipeline records the original prompt, system instructions, retrieved RAG passages, the response, tool arguments, and tool results.

The data may not leave the local model, yet it appears in a second system—the log store. That system can have different administrators, backups, retention periods, and export policies. Access to an observability dashboard may even be broader than access to the CRM or file repository from which the assistant obtained the source data.

An official OpenTelemetry article from May 2026 makes the boundary concrete. The GenAI semantic conventions support recording the model, duration, input and output token counts, and finish reason. Full prompts, responses, system instructions, tool calls, and results are also supported, but content capture is a separate opt-in. By default, prompt content and tool arguments are not recorded because they may contain sensitive data.

The practical lesson for a small business is that “local” describes where the model runs, not the full lifecycle of its data. Security policy must cover the path from user input to traces, metrics, logs, backups, and deletion.

What should actually be recorded

Operations teams do not need to read every word of every conversation. Telemetry is easier to control when divided into three classes.

**Operational metadata** is usually useful continuously:

  • service identifier and pinned model version;
  • operation type without the prompt body;
  • duration of the model call and individual tools;
  • input and output token counts;
  • result code, finish reason, timeout, or refusal;
  • queue size, retry count, and CPU, GPU, and memory load;
  • security-policy version and triggered rule identifier.

**Correlation identifiers** help investigations but should be pseudonymised:

  • a random trace ID instead of a name, email address, or contract number;
  • an internal department identifier instead of a customer name;
  • a hash of a prompt pattern or detection rule instead of full content;
  • a reference to a protected business record instead of a copied record in the log.

**Content**—prompts, responses, RAG context, system instructions, arguments, and tool results—is the high-risk class. It should be captured only for a defined purpose, limited sample, and pre-set period. “Just in case” is not a purpose.

This separation still reveals latency, errors, cost, and unusual actions without turning each request into a new indefinite copy of personal and commercial data.

Architecture: filter before the collector

A secure design begins where telemetry is created, not in a dashboard setting.

1. **The model gateway** assigns a random trace ID and knows the business operation: knowledge search, email drafting, field extraction, or a tool call.
2. **The telemetry policy** decides which fields that scenario may emit. Metadata-only is the default.
3. **Filtering and masking** remove secrets, personal identifiers, access tokens, and document content before anything reaches the collector. Redacting after ingestion leaves an exposure window and does not clean existing copies.
4. **A local collector** receives standardised events and routes data classes to different stores. This does not require a cloud service: OpenTelemetry works with local backends.
5. **The metrics store** retains aggregates and low-risk technical fields longer. Debug-content samples are isolated, encrypted, and deleted sooner.
6. **Access auditing** separately records who viewed a sensitive trace, exported it, or changed retention.

The key rule is not to turn observability into a business archive. If an investigation needs the original conversation, the logging system should keep a reference to a record protected by its own access controls, not another copy of the full conversation.

Why regular-expression masking is not enough

Regular expressions can find phone numbers, emails, payment-card patterns, and common tokens. They miss trade secrets written in natural language: discount terms, defect descriptions, internal strategy, or medical details. They also do not understand when several harmless-looking fields together identify a person or client.

Protection therefore needs layers:

  • do not enable content capture by default;
  • allow only required fields through an allow-list;
  • mask known patterns before the collector;
  • limit sampling and retention;
  • separate developer, operator, and security roles;
  • test the filter on realistic anonymised examples and deliberately difficult inputs.

OWASP classifies personal, financial, medical, and confidential business data as sensitive information and warns that system-prompt restrictions alone are not a reliable control: they may be bypassed. Sanitisation, access controls, least privilege, and transparent retention and deletion policies remain necessary.

What to log for incident response

Full text looks like convenient evidence but can increase the impact of an incident. Most technical investigations can correlate events with:

  • trace ID and timestamp;
  • application, model, prompt-template, and policy versions;
  • operation and tool type without arguments;
  • filter decision: allowed, masked, or blocked;
  • hash of the matched pattern or signature;
  • result code, latency, and token volume;
  • identifier of the person who approved a privileged action;
  • immutable record of the command actually executed in the system of record.

When content is genuinely required, use a break-glass process: a request for access, narrow role, stated reason, short expiry, notification, and a full view audit. Debug samples should not automatically flow into ordinary multi-year backups.

The NIST Privacy Framework treats privacy as an enterprise risk to be managed. For local AI, that means assigning a data owner, documenting the processing purpose, defining the minimum fields, setting retention, and establishing deletion before enabling expanded telemetry.

The economics of unnecessary logs

Security and economics point in the same direction. Full prompts and responses are high-cardinality data. They aggregate poorly and inflate indexes, storage, replicas, transfers, and review workload.

The following is a modelled example, not a result from a particular company. Assume a local assistant handles 20,000 requests per day and the full bundle of prompt, context, answer, and tools averages 20 KB. That is about 400 MB of raw data per day and 12 GB over 30 days. With an index, replica, and backup, actual storage may reach 24–60 GB.

If the system continuously stores about 1 KB of metadata per request instead, the result is 20 MB per day, or roughly 600 MB per month before overhead. Full traces can be restricted to a 0.1–1% anonymised diagnostic sample retained for 3–7 days. Each stack must be measured, but the order-of-magnitude difference is visible before buying storage.

Disks are only part of the cost. Budget also covers filter configuration, masking-quality checks, access separation, incident investigation, and deletion from every copy. The cheapest gigabyte of sensitive logs is often the one never created.

A five-day pilot

**Day 1: inventory.** Choose one local-AI service. Export the event schema without values and mark every place where prompts, responses, system instructions, RAG passages, tool arguments, and user identifiers may appear.

**Day 2: minimum profile.** Keep model, duration, token counts, status, trace ID, and policy version. Disable content capture by default. Verify that the data can still locate a slow call, timeout, and retry.

**Day 3: filter.** Add an allow-list and masking before the collector. Run a test set containing phone numbers, emails, tokens, account details, contract terms, and nested tool results.

**Day 4: access and retention.** Separate metrics, action audit, and diagnostic content. Assign owners, roles, deletion periods, and temporary-access procedures. Check backups and exports.

**Day 5: exercise.** Simulate an incorrect answer and suspicious tool call. The team should reconstruct the chain from safe metadata. If the investigation genuinely needs content, add one tightly scoped field or sample instead of enabling full-stream capture.

The management takeaway

Deploying a local model does not close the privacy question. Ask for a diagram of every post-inference copy: traces, logs, dashboards, exports, and backups. Store metadata by default; enable content only for a measurable purpose, small sample, and short period.

Good observability explains where a system is slow, expensive, or wrong. If it indefinitely copies every conversation to do so, it is no longer merely observability—it is a new unmanaged database.