What should incident investigation retain? Minimizing AI telemetry across teams

THE TAKEAWAYS

What to take away

Define necessary diagnostic fields and viewers first.
Check filtering for the adopted instrumentation and verify actual exports.
Use dummy-data tests and time-bounded exceptions.

EDITORIAL PRACTICE

“Useful for investigation” is not a sufficient collection reason

If the same information remains in another log after a conversation disappears from the interface, user expectations and operations may diverge. This article offers technical and operational checks, not a determination of compliance with any specific law.

We suggest starting with a hypothetical incident resembling a recent problem and listing what is needed to diagnose it. Identifying a failed step may require only a step name and result category. Understanding why an answer was wrong may require a different validation method. Do not force different purposes into one logging policy; also make explicit the investigative limits of not retaining original content.

Sources:

FROM PRIMARY SOURCES

Distinguish documented responsibility from local decisions

Microsoft's OpenTelemetry documentation for Application Insights describes filters for excluding unnecessary telemetry and preventing collection of personal data and credentials. [1] The operating proposal below refers to that example, while owners must still classify sensitive information for their own environment.

Our proposal is to classify candidate fields as routine collection, purpose-limited consideration, or no collection. Processing stage and outcome might be routine candidates; user free text calls for careful consideration; authentication secrets should be excluded from raw incident records. This is not a universal classification for every project. Information-management owners must consider business identifiers and combinations of fields as well. Apply the same criteria to investigation material sent overseas rather than treating ticket attachments differently.

Sources: [1]

FROM PRIMARY SOURCES

A configuration file does not prove processing occurred

The Application Insights configuration documentation provides examples for avoiding collection of URL query strings. [2] Application methods differ by language and instrumentation, so verify the adopted configuration rather than transplanting a setting name to another environment.

The practical proposal is to separate reading deletion or transformation settings from observing the result at the actual destination. A validator, not only the configuration author, should trace which signal follows which path. Include alternative destinations and temporary debug output. Separately check whether original content exists or is stored between the application and the collector. Masking in the final interface alone is not evidence that sensitive content never existed upstream.

Sources: [2]

EDITORIAL PRACTICE

Test with identifiable dummy values, not real data

An acceptance approach is to use inputs containing clearly designated test values rather than personal information or real secrets. Exercise paths such as normal success, external connection failure and application exceptions, then check what each destination retains and removes. Even with dummy data, define a validation environment or identification method that prevents confusion with operational data. Record test identifiers, expected values and observation locations rather than complete input copies.

Also verify that diagnostic information intended for retention has not disappeared. Saving nothing may avoid some disclosure risks but could make causes untraceable. Explain necessity and protection individually for fields such as stage, outcome and correlation identifiers. We propose two acceptance conditions: sensitive-looking test strings are absent where required, and the intended investigation remains possible using permitted information.

Sources:

EDITORIAL PRACTICE

Give investigation exceptions an ending

If routine information is insufficient, decide who may authorize an exception and for what purpose rather than expanding logging indefinitely. Our proposal groups scope, duration, viewers and a closing check. Creating a shared link does not imply permission to distribute it to the entire overseas team; verify the actual investigating audience. Storage and transfer requirements need separate assessment against the chosen services, contracts and applicable rules.

Four handoff deliverables are sufficient: a field inventory, an export-path diagram, dummy-test results and a contact for exception requests. Do not confuse handing over large raw logs with a thorough handoff. When adding an instrumentation library or output field, review which of these four artifacts changes. Reducing collection while preserving investigative ability requires not only deletion settings but an operation that can explain the purpose of what it retains.

Sources:

WITH OPERUN.

Delegate everyday AI management.

For example, an investigation-ticket template can specify both permitted fields and material that must not be attached. If excessive original content is pasted into a ticket, follow the existing information-handling procedure rather than forwarding it unchanged to another location. Covering both instrumentation and human-prepared investigation material avoids a design that stops after fixing only the machine side. The cover is an AI-generated image of fictional people and a workspace.

Discuss your product and AI work

Primary sources

Sources checked on 2 November 2026. The workflows and checklists are editorial proposals.