Describe retention for a specific data item, endpoint, model, account or project, and region—not for “AI” in the abstract. Ask where a source snippet or finding text enters the model request, whether that request or response is retained by the inference service, whether an application log or optional model log captures it, where any retained copy sits, who can read it, and when each copy expires. A provider's statement that prompts are not used to train a model answers only the training question. It does not establish zero retention, single-region processing or deletion of the vendor's own traces and backups.
The answer may change by model, API route, account setting and feature flag. Amazon Bedrock, for example, documents explicit retention modes for its current inference APIs: none, default, aws_review and a legacy provider_data_share mode. It says default depends on the model and that store=false on the Responses API does not by itself guarantee zero data retention (Bedrock data retention). Treat a mode name as one field in a data-flow record, not a promise covering every copy made before and after inference.
Separate the copies before reading contract language
Draw a simple route: repository → scanner workspace → selected prompt/input → inference API → output → verification workflow → retained report. Add branches for application logs, debugging traces, model invocation logs, retry queues, support bundles and backups. Label each branch with its operator. A code security vendor may minimize the prompt but still keep a broad transcript in its own telemetry. Conversely, a vendor may keep only a source-free final finding while an optional model log is enabled in the cloud account. Procurement needs both facts.
Use six distinct questions:
- Input: What exact classes of data enter the request—source lines, repository names, credentials, finding narratives, user identifiers or metadata?
- Route: Which service endpoint, account or project, model ID/version and AWS Region handle each call? Is any fallback or inference profile allowed?
- Inference retention: What effective account/project mode and model-specific allowed modes apply to the exact route? Is the setting enforced or merely requested?
- Additional copies: Are model invocation logging, application traces, request capture, conversation storage or support exports enabled?
- Access and lifetime: Who may read each copy, in what location, and under what deletion and backup schedule?
- Change control: Who can change the mode, model, route or logging setting, and what happens before a new model is admitted?
AWS describes its training and model-provider handling in the Bedrock FAQ; check that statement for the exact current service route. That statement is useful but narrower than “nobody stores or sees the input.” Bedrock's data-retention documentation describes model-specific retention and AWS review modes. Record the exact policy that applies to the call under review. For another provider or a direct API route, request that provider's current terms and technical settings instead of importing Bedrock's answer.
Copyable procurement request
Send the table below to the vendor. Its last column is a proposed target answer, using invented values; the AsterPay case that follows shows why mismatched evidence can fail to establish it; replace every value with your vendor's answer and evidence. Request a dated, redacted configuration or control-plane response for the live environment, plus a call trace that binds one sampled request to its model and route. A sales deck can orient the review but should not be entered as observed configuration.
| Field to complete | Question and evidence requested | Vendor response |
|---|---|---|
| Data in | Which source, metadata and report fields can be placed in one request? Supply a redacted prompt schema and exclusions. | Up to 40 source lines; repository slug excluded; schema supplied |
| Route | Give endpoint/API, cloud account or project, model ID/version, source Region and any allowed destination Regions. | Bedrock Runtime Messages in us-east-1; model ID recorded; no inference profile |
| Effective retention | Give endpoint-appropriate account/project policy, model requirements and dated evidence; do not assume every API exposes per-model allowed modes. | Account mode none; selected model allows none; redacted response supplied |
| API-specific storage | For a Responses API or equivalent, state the store behavior, background mode and whether safety retention remains possible. |
Not using Responses API; switching APIs requires another review |
| Logging and traces | Show whether model invocation logging and vendor application tracing capture input/output; list destinations. | Bedrock invocation logging disabled; application trace contents still to be checked |
| Other recipients | Name cloud operator, model provider, vendor personnel and subprocessors with access to each copy. | AWS operates inference; vendor retains its own result; staff access scoped separately |
| Time and deletion | State retention for request/response, app logs, reports, support attachments and backups separately; include deletion triggers and holds. | Inference mode none; source-free job metadata 14 days, findings 30, backups up to 45; support attachments pending |
| Changes and failure | Who may enable logging, change a model or route, or loosen retention? Does unsupported policy fail closed before source is sent? | Platform owner named; reapproval required; failure behavior still to demonstrate |
Reconcile three reassuring answers that refer to different scopes
Illustrative packet; AsterPay, the model labels and configurations are invented. No cloud account or model was invoked. Procurement receives “training disabled,” “logging off” and “retention none.” The last screenshot is for a bedrock-mantle project in us-east-1. The actual job trace names bedrock-runtime in us-west-2. The project screenshot cannot establish the effective policy of that call.
AWS's current retention guide distinguishes account settings by Region from project settings on bedrock-mantle; Runtime has no project scope. It also explains model-dependent defaults and policy rejection when a selected model requires a more permissive mode. The engineer must match the evidence to the real endpoint and Region before interpreting “none.” AWS also states that the Bedrock control plane exposes no per-model retention signal. Do not invent a Runtime allowed_modes response: combine its regional account-policy readback with the exact model's published requirements, and distinguish any bedrock-mantle model metadata from Runtime configuration evidence.
| Packet item | Initial buyer interpretation | Reconciled interpretation |
|---|---|---|
Project P4 shows none in us-east-1 |
All vendor inference is zero retention | Evidence for P4 in that Region; not the Runtime call in the trace. |
Runtime call R17 originates in us-west-2 |
Same provider, so same policy | Request account-level policy for that Region and requirements of the exact model. |
Invocation logging disabled in us-east-1 |
No model content exists anywhere | Wrong Region for R17; optional customer logging is also separate from provider retention and app telemetry. |
Responses request says store=false |
No retained request | Does not by itself exclude provider safety retention; exact API/retention policy required. |
| Vendor finding stored for 30 days | No source retained | Finding may contain source-derived sensitive text; inspect fields and its separate schedule. |
AsterPay keeps private input on hold. The corrected hypothetical packet supplies the Runtime account configuration for us-west-2, model eligibility evidence tied to the exact model, the logging setting for that Region, and the application trace schema. The named primary model permits the approved zero-retention mode. The fallback model requires retention, so it is incompatible with the pilot policy. The accepted behavior is to stop with a clear incomplete-job result, not to change mode or Region to complete the scan.
Make the fallback an explicit decision, not an exception buried in code
The platform owner documents the following proposed rule:
approved route available and policy matches → send permitted input
approved route unavailable → stop; record source-free failure
fallback requires broader retention → reject before sending source
route or retention configuration changed → require a new review record
This is a policy decision diagram, not executable AWS configuration. Implementation evidence must show which configuration and permissions enforce it. A single successful primary call cannot show that a capacity error will honor it.
The vendor then supplies a synthetic timeout trace. It contains the harmless source marker in exception.request.body, even though its normal event schema contains only job ID and timing. This is a vendor-held copy; an eligible provider mode does not delete it. The repair must cover nested error serialization and define what happens to existing trace records. Procurement keeps that obligation open while acknowledging that the corrected inference-route evidence is now sufficient for the named primary configuration.
The final plain-language answer is:
“The proposed primary call uses the evidenced account policy for this endpoint and Region and a model compatible with the approved retention rule. A fallback requiring retention is excluded. Vendor findings remain on a separate 30-day schedule. Error telemetry still carries source in the synthetic failure case, so private-source approval remains on hold until that path and its retained copies are resolved.”
The 30-day vendor period is invented, not an AWS default or recommendation. Replace it with the actual agreement. Do not copy a none project screenshot into a general zero-retention attestation, and do not describe a corrected provider setting as proof that every application copy disappeared.
Ask about logging and geography separately
Bedrock's model invocation logging guide says logging is disabled by default, can include full input and output on supported calls, and can send logs to CloudWatch Logs or S3 in the same account and Region. That is a configuration-specific fact. Ask for the current setting and destinations in each approved Region; do not infer the setting from the default. The same guide distinguishes calls to bedrock-runtime from endpoints its logging feature does not capture, so “no invocation log entries” is not proof that no request occurred or no other trace exists.
Bedrock also supports geographic and global cross-Region inference profiles. An inference profile can route a request to a destination Region; AWS documents that the selected destination can be found in CloudTrail's additionalEventData.inferenceRegion for cross-Region calls (cross-Region inference). “EU profile” is not the same claim as “one EU Region.” Ask for the allowed destination list and a sampled observed destination. If single-region processing is a condition of your approval, make the vendor show that cross-region routing is disabled or blocked for the relevant model and fallback paths.
AWS also states that content retained for abuse detection during geographic inference is stored in the destination Region for affected models (geographic inference). A source-Region log setting therefore cannot settle either the existence or location of those provider-held copies.
Decide what procurement can honestly sign off
Privacy counsel should record the contract purpose, permitted data categories, approved route, evidence date and unresolved technical questions. Counsel can decide whether the arrangement meets the organization's contractual or legal requirements; a product article cannot make that conclusion. If a model or region changes, refresh the record. If support, logs or backups still contain source, do not describe deletion of the scanner's task-local file as deletion of all copies. If no configuration evidence exists, start with synthetic or low-sensitivity material and keep private source out of scope until the route is proven.
Next action: send the table for one proposed model and one real deployment region, then ask the engineer to walk a sampled request from prompt construction to retained outputs. Review support access to sensitive findings for human access to traces and tenant isolation for the storage boundary.