Data handling for model requests

Classify before sending

Start by identifying the data a task needs and its sensitivity. Separate public material, internal information, personal data, credentials, and regulated or contract-restricted content according to your organization’s definitions. Confirm that the selected provider and integration are approved for each class. If a task can work with a redacted or minimized input, prefer that smaller representation.

The application should gather only the context necessary for the task. Check access rights before retrieval, and avoid using a model prompt as a way to move data around authorization boundaries. Treat user-supplied content as untrusted input; it may include instructions that conflict with the application’s intended behavior.

Map each copy and transfer

Trace where request data may appear: application memory, gateway processing, provider request, logs, traces, evaluation datasets, support exports, and backups. For each location, identify the operator, purpose, access controls, retention period, and deletion path. Check whether data crosses organizational or geographic boundaries and whether contractual terms permit the intended use.

Do not assume that a gateway automatically changes a provider’s handling terms. Verify the current agreement and service configuration directly. Record what is known and what needs confirmation; avoid broad public statements that compress different providers or plans into one claim.

Limit collection and access

Routine telemetry can often use identifiers and outcomes without full prompt or response content. If content is necessary for a limited purpose, document the rationale, restrict the audience, minimize the sample, and delete it when the purpose ends. Masking can help, but test its limitations and remember that surrounding context may still identify a person or reveal confidential information.

Keep secrets out of model inputs and logs. Use a managed secret store for credentials, rotate them according to your procedures, and ensure support tools do not expose them through copied request details. Restrict access to operational data based on role and review access when responsibilities change.

Plan for incidents and requests

Define how the team will respond if data is sent to an unintended route, exposed in a log, or retained longer than expected. The response should identify containment steps, system owners, evidence to preserve, and any notification obligations determined by counsel or policy. Test the contact path before an incident; an undocumented escalation chain is difficult to use under pressure.

Where relevant, document how data access, correction, or deletion requests flow through derived systems such as evaluation stores and exports. A request may involve multiple services and legal requirements, so assign an owner to coordinate the response.