AI conversation evidence

Something goes wrong with an AI-assisted process — a customer receives a reply that should never have gone out, a summary contains a figure from another account, a tool action fires against the wrong record — and the first question is always the same. What was it asked, and what did it say back?

Metadata alone cannot answer that. A trace showing a request to a model at a timestamp with a token count establishes that something happened and nothing about what. Meanwhile the content that would answer it is the most sensitive material the system touches: the prompt may contain a customer's personal data, the reply may contain a credential somebody pasted in, and storing all of it indefinitely creates a liability considerably larger than the incident being investigated.

Both extremes are easy and both are wrong. Capture nothing and every investigation ends in speculation. Capture everything and you have built the estate's most attractive target, filled it with other people's personal data, and put it outside the retention scope somebody signed off.

So text capture here is a deliberate, per-deployment decision rather than a default; what is kept is redacted before it is stored and bounded before it is kept; and the bounds and the redactions are visible in the record rather than silent, so that a reader of the evidence knows what they are not seeing.

Reasoning models produce internal reasoning that is not returned to the caller. Some providers return a summary of it; some return an encrypted state token that only they can interpret; none returns the reasoning itself.

Token Observe records what a provider actually exposes as text. Where a provider supplies an exposed summary, that summary can be retained. Encrypted provider reasoning state is not readable content and is not treated as evidence, and hidden chain of thought is not available from any provider at all.

This distinction is stated here rather than in a footnote because the opposite claim is common and would be attractive. An assurance built on the idea that you can audit what a model was thinking is an assurance built on something nobody can supply, and it would collapse the first time a technically literate reviewer asked which API field it came from.

The detectors that run before storage find personal data and credentials by pattern and checksum. They are the same heuristics used elsewhere in the product and they carry the same honest caveat: they catch known shapes, and they cannot identify every confidential business fact in free text.

A prompt containing an unannounced acquisition, an unreleased figure or a customer's circumstances described in ordinary prose contains nothing a detector recognises, and it will be stored. Redaction reduces the sensitivity of this store considerably. It does not make it a store of non-sensitive material, and a deployment should treat captured conversation content as sensitive regardless.

The existing trace retention, erasure and team access controls all cover these event contents, so this content inherits the lifecycle you already configured rather than needing a second one. Note the boundary in the other direction: the trace erasure route erases trace evidence and not the separate invoice and subscription ledger, which has its own retention scope.