Prompt Retention Is a Control, Not a Preference
“Zero retention” may sound sufficient, but buyers still need evidence for data-type coverage, storage layers, deletion timing, exceptions, administrative control, and contract scope.
AI Vendor Evidence Gap Notes #5
AI vendors often describe retention as a setting:
“Zero data retention is available.”
“Enterprise customers can configure retention.”
“Prompts are deleted after 30 days.”
These statements sound operational. They suggest that the buyer controls the data lifecycle.
But a retention setting is not automatically a retention control.
The real review question is not:
What retention period does the vendor advertise?
It is:
What data lifecycle does the available evidence establish for this product, plan, feature, region, and use case?
Claim
A vendor says:
Enterprise customers can configure prompt retention.
That may prove that a retention feature exists for a defined category of content.
It does not prove the full lifecycle.
Why it sounds sufficient
Retention is often reduced to one number: zero days, thirty days, customer-configurable, or deleted on request.
That makes the answer easy to place in a questionnaire and mark complete.
The problem is that an AI workflow rarely creates only one data object.
One interaction may produce:
prompts and outputs;
uploaded files;
extracted text or embeddings;
metadata and logs;
moderation or abuse-review events;
support artifacts;
cached copies;
backup copies.
The vendor may use “retention” to describe visible conversation history.
The buyer may assume the same statement applies to the entire workflow.
That assumption is the evidence gap.
What the statement may prove
If the source is reliable and product-specific, the statement may support a few limited conclusions:
a retention feature exists;
administrators may be able to shorten or disable visible history;
an enterprise plan may offer additional controls;
the vendor has defined a customer-facing retention option.
Those are useful signals.
They are not evidence that every relevant data object follows the same lifecycle.
The source matters too.
A product setting, FAQ, trust center, support email, contract, and customer-specific commitment do not carry the same weight or scope.
What it does not prove
A configurable retention statement does not automatically prove:
Data-type coverage.
Does the setting cover only prompts and outputs, or also files, embeddings, metadata, logs, support copies, and backups?Storage-layer coverage.
Deletion from the main application does not prove deletion from caches, indexes, vector stores, support tools, observability systems, or backup environments.Deletion timing.
“Deleted” may mean immediately removed, queued for deletion, removed from active systems within a stated period, or retained in backups until rotation.Exception paths.
Data may be retained longer for security investigation, legal obligations, customer support, abuse review, fraud prevention, or service improvement.An exception may be legitimate.
An undisclosed exception means the advertised period is not the full boundary.
Administrative enforcement.
A setting is weak if changes are not logged, new features bypass it, or different workspaces inherit different defaults.Product and plan scope.
Retention may differ across API and hosted products, enterprise and consumer plans, regions, integrations, beta features, or model routes.
A company-wide statement does not prove that the intended workflow is covered.
Weak-answer pattern
The vendor describes a retention preference without evidencing the full retention control boundary.
The response provides a duration or setting, but not the covered data types, storage layers, exceptions, deletion timing, administrative roles, audit evidence, or contractual scope.
This does not prove improper retention.
It means the buyer cannot yet determine which lifecycle is being accepted.
Evidence request
A stronger request is not:
What is your retention period?
It is:
Provide a product- and plan-specific retention matrix for prompts, outputs, uploaded files, embeddings, metadata, logs, moderation events, support artifacts, caches, and backups.
For each data type, identify:
default and configurable retention;
storage layer;
deletion timing;
backup handling;
exception paths;
support or human access;
administrator roles;
audit-log coverage;
contractual source.
The buyer should also ask:
Does a setting change apply to existing data or only new data?
Can the vendor override the configured period?
Are changes to retention behaviour communicated to customers?
Do new AI features inherit the same setting?
What evidence can the customer retain to show the configured state?
The vendor does not need to expose sensitive architecture.
It does need to establish an operationally usable boundary.
Review note
A review note could state:
The available statement identifies a configurable retention setting but does not establish the complete data lifecycle for the intended workflow. Coverage of files, metadata, logs, embeddings, support artifacts, caches, backups, and exception paths remains unclear. The response is not evidence-complete for data requiring verified deletion or short-lived processing.
Usage boundary
The correct boundary depends on the use case.
A thirty-day period may be acceptable for public marketing material and unacceptable for confidential meeting content.
Zero retention may reduce exposure in one workflow but reduce auditability or incident investigation in another.
The shortest period is not automatically the strongest control.
The control is whether the lifecycle is explicit, scoped, enforceable, observable, and supported by evidence.
Until that boundary is established:
Limit use to low-sensitivity data that does not require verified deletion, strict short-lived processing, or customer-specific retention commitments. Do not expand to confidential, regulated, or customer data until retention and deletion are evidenced by data type, storage layer, exception path, and contract scope.
That is not approval.
That is review preparation.
A retention setting may be useful.
But usefulness is not the same as evidence.
The review unit is not the vendor name.
The review unit is:
vendor + product + plan + use case + data type + region + contract terms + evidence date.
Prompt retention can support that review.
It cannot remain a single number inside it.
A retention setting can be part of the evidence.
It is not the whole control.
Boundary
This material is for evidence structuring and review preparation. It does not provide legal, regulatory, audit, procurement, certification, or implementation advice.
The goal is not to approve or reject a vendor.
The goal is to make the evidence gap visible before real data use.
I have a sanitized sample evidence gap memo showing how retention, routing, support access, and contract gaps can be recorded in a review file.
Reply if you want the sample.
#AIVendorAssessment #AIGovernance #ThirdPartyRisk #Privacy #VendorRisk