When should you capture full prompts and responses, and when should you not?

Most teams adopting AI assistance reach the same crossroads sooner or later: how much of what staff actually type into a model should you keep? It is tempting to treat this as a technical setting. In practice it is a governance decision, and the right answer is rarely "capture everything" or "capture nothing". This guide walks through the trade-offs so you can choose capture depth deliberately, workflow by workflow.

The three depths, and why the choice matters

Evaident gives you three levels of capture, and they sit on a deliberate spectrum from low exposure to high evidentiary detail.

• Metadata is the default. It records who used a model, when, which model, how many tokens, and any risk flags raised, but it stores no content at all. It is the safest option because there is no prompt or response text to protect.
• Preview keeps a short, PII-redacted snippet of the prompt. You get readable evidence of what was being asked, with the exposure kept low by truncation and redaction.
• Full content keeps the complete prompt and the complete response.

The reason the choice matters is straightforward. Metadata tells you *that* something happened and lets you reconstruct patterns of use. Content tells you *what* was said. The first is almost always defensible to hold; the second carries real obligations, because the moment you store a staff prompt you may be storing personal, client, or privileged data along with it.

What you gain by going deeper

There are genuine reasons to capture content. When you are investigating a specific incident, verbatim text answers questions metadata cannot: what exactly was disclosed, whether an instruction was appropriate, what the model returned, and whether a human acted on it. For a regulator, an auditor, or an internal investigation, a faithful record of the actual exchange can be the difference between a credible account and an educated guess.

Preview captures much of this value at a fraction of the risk. A short, redacted snippet is often enough to show the *nature* of a request without reproducing it in full. For everyday assurance work, that readable-but-restrained evidence is usually the sweet spot.

The goal is not maximum data. It is the least content that still answers the questions you can reasonably expect to be asked.

What you take on by going deeper

Raising capture above metadata is a data-protection decision, not a toggle. Staff prompts can contain names, account details, health information, legal advice, or commercially sensitive material, often entered without thinking of it as a record. Once you store that, you inherit the usual responsibilities:

• Confirm a lawful basis for processing the content you intend to keep.
• Tell staff what is being captured, through a clear notice.
• For UK and EU teams, complete a DPIA before you switch full content on, because this is exactly the kind of processing that warrants one.

Evaident reduces the residual risk rather than removing it. Redaction is on by default for captured content, masking common identifiers such as National Insurance numbers, card numbers, sort codes, IBANs, NHS numbers, and email addresses. That lowers exposure, but it does not relieve you of the lawful-basis, notice, and DPIA work.

How to capture full content safely

Full content in Evaident is the Enhanced Content Capture add-on, and it is built to be used sparingly. It is not part of any standard plan and is off by default, even in trial. Turning it on is a deliberate act, which is the point.

When you do enable it, several controls keep the blast radius small:

• It is scoped to a specific workflow rather than switched on across the board, so only the high-risk process that genuinely needs verbatim evidence is captured.
• It is approval-gated, so enabling it is a decision someone owns, not a default someone forgets.
• Content is retained for an agreed short period, while a tamper-evident digest of that content is sealed into the integrity chain.

That last point deserves emphasis. Event retention and content retention are configured separately. The tamper-evident record and its digest can outlive the content itself, so when the content is purged on schedule you still hold cryptographic proof that the original record existed and has not been altered. You keep the integrity evidence without keeping the sensitive text indefinitely. Short retention and a durable proof are not in tension; they are the design.

A practical default

For most teams, a simple posture works well:

• Default to metadata everywhere. It is safe, it is always-on, and it covers the bulk of your assurance needs.
• Use preview where you want everyday readable evidence of what staff are asking, with exposure kept low by redaction and truncation.
• Reserve full content for a single, named, high-risk workflow that genuinely needs verbatim evidence, and only after the lawful basis, the staff notice, and the DPIA are in place.

The instinct to record everything "just in case" usually creates more data-protection risk than it resolves. The instinct to record nothing can leave you unable to account for a serious incident. Choosing depth per workflow, and keeping the integrity proof even when the content is gone, gives you a defensible middle path.

This supports your compliance work; it is not legal advice. Your DPO and counsel should sign off on where you draw the line.

If you want to understand where your current exposure sits before changing anything, start with our /exposure overview, then see how the capture depths map to plans on /pricing.