Start by treating every model API as an external data processor and verifying what it stores, where it stores it, who can access it, and how long deletion takes. Do not commit until the provider’s written terms, technical controls, and test results match your data classification and threat model.
Classify the data before comparing providers
List the information your application may send to the API. Include prompts, uploaded files, system instructions, retrieved documents, tool outputs, conversation history, metadata, and model responses.
Then assign each data type a handling rule. A useful classification might separate public information, internal material, personal data, customer confidential data, regulated records, credentials, and security secrets.
This step sets the boundary for the evaluation. If the application could expose medical records or payment data, a general privacy statement will not settle the question. You need contractual coverage, appropriate technical controls, and evidence that the proposed architecture meets the rules governing that data.
Also identify prohibited inputs. API keys, passwords, session tokens, private signing keys, and raw payment credentials should generally stay out of prompts regardless of the provider’s assurances.
Map the complete data path
A model request rarely travels directly from your application to a model and back. It may pass through an observability platform, API gateway, content filter, vector database, support console, or retry queue.
Draw the path from user input to final output. For every component, record:
- The data received and generated
- Storage location and retention period
- Encryption in transit and at rest
- Staff and service accounts with access
- Subprocessors involved
- Deletion process and expected completion time
- Logs, backups, caches, and abuse-monitoring copies
This exercise often exposes a gap outside the model provider. Zero Data Retention from a frontier model vendor does little if your proxy records complete prompts for 30 days or your tracing tool stores retrieved customer documents.
Verify what Zero Data Retention covers
Treat Zero Data Retention, or ZDR, as a precise configuration with defined exclusions. Ask which endpoints, models, regions, features, and account types qualify. Confirm whether the policy covers prompts, outputs, uploaded files, embeddings, safety classifications, metadata, and failed requests.
Features that require persistent state may operate under different rules. Batch jobs, stored conversations, file search, prompt caching, fine-tuning, and provider-hosted tools deserve separate checks. Do not assume an account-level ZDR agreement automatically applies to every new feature your developers enable.
Obtain the answer in binding terms or provider documentation attached to the contract. A sales email can clarify intent, but it should not carry the full weight of your privacy decision.
Separate training restrictions from retention
“Your data is not used to train models” answers one question. It does not tell you whether prompts remain in logs, appear in support systems, enter abuse-review queues, or persist in backups.
Record separate answers for:
- Use of customer content for model training or improvement
- Operational retention of prompts and outputs
- Human access for support, safety, or incident response
- Retention of account and request metadata
- Backup deletion schedules
- Legal preservation obligations
Ask whether provider defaults differ from your negotiated settings. Then confirm how administrators can detect a configuration change that weakens those protections.
Test access controls and isolation
Use a non-production account to examine authentication, authorization, and administrative controls. Prefer short-lived credentials, separate keys by environment, narrow permissions, and a documented rotation process. Check whether the provider supports single sign-on, multi-factor authentication, role-based access, audit logs, usage limits, and restrictions by project or workspace.
Tenant isolation also needs evidence. Review independent security assessments, penetration-test summaries, and incident response commitments where available. Certifications can support due diligence, but their scope matters. Confirm that the API service, region, and controls you plan to use fall within the assessed system.
Your own architecture should limit the damage from a compromised key. Put model access behind a controlled service, cap spending and request rates, and prevent client applications from holding unrestricted provider credentials.
Run adversarial tests with synthetic data
Build a test set that resembles production structure without containing real customer records. Include personal identifiers, confidential document markers, prompt-injection strings, oversized inputs, malformed files, and requests designed to make the model reveal prior context.
Test for cross-session leakage, unintended logging, insecure error messages, excessive tool permissions, and failures in redaction. If the model can call tools, treat its output as untrusted instructions. Require authorization checks in the application before any consequential action.
A poisoned document can turn retrieval into an authority problem, as this LLM attack-surface analysis shows. Privacy controls cannot compensate for an agent that can read broad datasets and execute high-impact actions.
Put operational promises into the contract
Review the data processing agreement, security schedule, subprocessor list, breach-notification terms, deletion commitments, audit rights, and data-location options. Identify which party handles data-subject requests and how the provider supports deletion or export.
Set a process for model deprecations and new subprocessors. Frontier API features change quickly, and a safe approval can become stale when a team switches endpoints or enables hosted storage.
Document an exit plan too. Know how you will revoke credentials, delete stored assets, obtain deletion confirmation, and move workloads if the provider changes its terms or controls.
Make a bounded production decision
Create a pass, fail, or compensating-control decision for every requirement. Unresolved items should have an owner and deadline. High-risk gaps, such as unclear retention, missing contractual coverage, or unrestricted tool access, should block production use.
The next action is concrete: schedule a 60-minute review with engineering, security, privacy, and the product owner. Bring the data-flow map, provider terms, ZDR scope, test evidence, and proposed controls. Approve one defined workload, model, region, and feature set rather than granting blanket permission for the provider’s entire platform.
Comments
No comments yet.