Model change releases

Review new model destinations and retained payloads

A model migration can change where prompts, files and traces are processed. Review the actual data path and configuration before treating it as a like-for-like replacement.

In this article

Inventory what leaves the application

List user messages, retrieved passages, files, tool definitions and tool results included in model requests. Separate essential task data from fields passed through for convenience.

Then inspect evaluation and monitoring paths. A candidate may receive additional traces or production samples during testing, creating data copies beyond the normal request flow. Include those destinations in the review.

Use the provider's current documentation and your organisation's applicable agreement to establish processing, retention and access behaviour. Do not infer those properties from a product name, region label or assumption about another service tier.

Compare configurations, not marketing descriptions

Record the endpoint, deployment region where applicable, logging settings, retention controls and identities allowed to invoke the service. Confirm the actual environment matches the reviewed configuration.

Check whether fallbacks route to another endpoint with different properties. A secondary model used only after a timeout still receives real data and belongs in the same review.

Avoid making broad legal conclusions from technical settings alone. The responsible business and privacy advisers should determine the applicable requirement, while engineering verifies the configured data path against it.

Minimise the candidate's input

Use the migration to remove unnecessary fields from prompts and tool results. A model extracting invoice dates may not need unrelated account notes. Smaller inputs can reduce exposure as well as cost.

Keep credentials, hidden application secrets and unrestricted internal identifiers out of generated context. The executor should use credentials internally rather than asking the model to handle them.

For evaluation, prefer synthetic or appropriately reduced fixtures when they preserve the behaviour under test. Production examples need a documented purpose and controlled access, not an informal copy into a shared benchmark folder.

Verify the deployed path

Inspect a controlled request and its traces to confirm which endpoint received which fields. Check error and retry paths, because they may log more detail than successful requests.

Record the review evidence and configuration version with the release. Revisit it when providers, regions, fallbacks or logging settings change. A model switch is operationally equivalent only when both its behaviour and its data handling meet the requirements of the application.

Primary sources

OWASP: logging guidanceOWASP: authorisation guidance

References checked 11 September 2026.