Training Data Vs API Retention
AI privacy depends on two different data paths: data used to train a model and data sent to a model through an API during day-to-day use. Training data shapes the model’s learned patterns, while API data retention governs what the provider stores after you submit prompts, files, or conversation logs. These paths can both involve health information, but they raise different privacy questions and different legal obligations.
For example, a health app might use an AI model trained on large datasets to summarize symptoms, then call an API each time a user types notes. If the provider retains API requests for 30 days, those logs may include names, dates, or free-text diagnoses. If the model was trained on a dataset that included de-identified records, the training set may still influence outputs, even though you never send those original records again.
In practice, you often cannot verify what a model “remembers” at inference time. You can, however, evaluate retention policies, data handling controls, and contractual terms that describe what happens to your specific request data after submission.
Common Privacy Pain Points
People often treat “AI privacy” as a single setting, then assume the same protections apply to training and to API usage. That assumption breaks down because training data and API logs follow different workflows, retention schedules, and access controls.
One frequent confusion involves de-identification. A dataset may be labeled “de-identified,” yet still contain quasi-identifiers that can be re-linked under certain conditions. Another confusion involves consent and scope: a training dataset might have been collected for one purpose, while API usage occurs under a different product contract. A third confusion involves vendor wording such as “we may use data to improve our services,” which can cover both model improvement and operational debugging.
Supporting technologies also matter. Many AI systems use logging pipelines for abuse detection, rate limiting, and quality monitoring. Those pipelines can store request metadata, prompt text, and model outputs. If the system uses retrieval-augmented generation (RAG), it may also query a document store, which adds another retention surface beyond the API request itself.
Even when a provider offers “no training on your data,” the provider may still retain API logs for security or billing. That retention can be short, long, or conditional on account settings, and the policy language sometimes distinguishes between “training,” “improving,” and “storing.”
How To Reduce Exposure
Ask For Retention Details
Request the vendor’s retention schedule for API inputs and outputs, including whether logs are stored, for how long, and under what conditions. Look for separate timeframes for: raw request text, attachments, derived embeddings, and conversation history. If the vendor mentions a versioned policy, record the date you reviewed it; policies can change without notice, and the current terms may differ from what you saw during onboarding.
When you see a retention window such as 30 days, treat it as a maximum unless the contract states otherwise. If the vendor offers a “no retention” or “zero data retention” mode, confirm what still gets logged for security. In many systems, some metadata remains even when prompt text is not retained, and that metadata can still reveal sensitive patterns.
Control What You Send
Minimize sensitive content in prompts. Replace direct identifiers with placeholders, and avoid pasting full medical records unless the workflow requires it. For example, instead of “John Smith, MRN 12345, diagnosed with…” use “Patient A, record ID redacted, diagnosis summary…” and keep dates relative when possible. This reduces the chance that retained API logs contain direct identifiers.
Use structured inputs when the API supports them, because structured fields can be validated and filtered more reliably than free text. If you must include free text, remove names, addresses, and exact dates. I often see teams forget that model outputs can echo sensitive phrases from the prompt, so redaction should apply to both inputs and any text you plan to store or share afterward.
Use Contractual Safeguards
For health-related use, ask for a Data Processing Agreement (DPA) and a description of security controls. In the U.S., HIPAA applies only when a covered entity or business associate handles protected health information, so the vendor’s role matters. In the EU/UK, GDPR applies based on roles and lawful basis, and the vendor’s obligations depend on whether it acts as a processor or controller.
Check whether the vendor offers a Business Associate Agreement (BAA) for HIPAA contexts. If it does, confirm whether the BAA covers API inputs, outputs, and logs. If it does not, treat the workflow as outside HIPAA coverage and rely on contractual privacy terms plus technical minimization.
Also ask about sub-processors and cross-border transfers. If the vendor uses third-party logging or monitoring services, the DPA should list them. A clause that says “we use subprocessors as needed” without a list makes it harder to assess retention and access.
Verify Model Improvement Claims
Clarify what “not used for training” means. Some providers mean they do not train future models on your data, while still using your data for service improvement or evaluation. Ask whether API data is used for: model training, prompt tuning, safety classifiers, or internal analytics. If the vendor offers an opt-out, confirm whether it applies to all data types, including outputs and feedback.
Look for a mechanism to disable feedback loops. For instance, if the product includes a “thumbs up/down” feature, ask whether feedback is stored with the prompt and how long it is retained. In one review I did of an API policy draft dated 2024-11-03, the retention section covered “requests and responses,” but the improvement section referenced “user-provided data,” which could include attachments and ratings. That mismatch is the kind of detail that can change your risk profile.
Educational Case Examples
Case 1: Symptom Triage App
A symptom triage app sends user-entered text to an AI API to generate a short summary and suggested questions for a clinician. The app’s privacy notice says “we do not train on your data,” but the vendor’s API terms state that request logs are retained for 60 days for “abuse monitoring.” The app team decides to redact names and exact dates before sending prompts, and it stores only the AI summary, not the raw conversation.
After the change, the retained API logs still exist for 60 days, but they contain fewer direct identifiers. The app also adds a setting so users can opt out of “diagnostic feedback,” which the vendor uses for evaluation. The team documents the retention window and the redaction rules in its internal risk review, because the privacy notice alone did not specify the vendor’s retention duration.
Case 2: Clinic Document Assistant
A clinic uses an AI assistant to extract structured fields from uploaded visit notes. The clinic uploads a PDF containing patient identifiers, then asks the assistant to return a JSON object with diagnoses and medication names. The vendor offers two modes: one that retains uploaded files for 7 days and another that retains only derived text for 24 hours.
The clinic chooses the shorter retention mode and modifies the workflow so the upload step uses a redacted PDF. The assistant’s output is reviewed by staff before it enters the electronic health record. This case highlights a practical point: even if the model does not train on the data, the provider may retain uploaded content unless the workflow and settings match the retention mode.
Retention Comparison Checklist
| Decision Point | Training Data | API Data Retention | What To Ask |
|---|---|---|---|
| Where your data goes | Into model training pipelines (if included) | Into request/response logs and related systems | Is my data used for training, evaluation, or only inference? |
| Time horizon | Long-term model lifecycle | Short-to-medium retention windows for logs | How long are inputs, outputs, and attachments retained? |
| Deletion behavior | Hard to reverse once training occurs | Often deletable after retention period | Can you delete my past API logs on request? |
| Risk at inference | Model may reflect learned patterns | Logs may expose what you sent | Does the model echo sensitive text from prompts? |
Step-by-step checklist for API privacy reviews:
- Write down the exact data you plan to send: names, dates, lab values, images, and free text.
- Ask for a retention table covering inputs, outputs, attachments, and derived artifacts like embeddings.
- Confirm whether “no training on your data” also covers evaluation and safety classifier training.
- Check whether conversation history is stored by default and whether you can disable it.
- Verify whether the vendor retains raw logs for abuse monitoring even when you disable training.
- Document your redaction rules and test them with a small set of sample prompts.
- Review the DPA/BAA terms for sub-processors and cross-border transfers.
Common Mistakes That Mislead
One mistake involves reading only the marketing line about “not using data for training,” then ignoring the retention section that covers logs. Another mistake involves assuming that de-identified training data removes all privacy risk; de-identification quality varies, and re-identification risk depends on context and safeguards.
People also confuse model behavior with data retention. A model can generate text that resembles patterns from training without storing your specific prompt. Conversely, a provider can retain your prompt text in logs without training on it. Treating these as the same risk leads to wrong decisions about what to redact.
Teams sometimes store full prompts in their own databases for debugging, then discover that the vendor’s retention policy does not cover their internal logs. If you run your own application, your logging choices become part of the privacy picture. I’ve seen teams forget to rotate logs after a test sprint, leaving sensitive prompts in backups longer than the vendor retains them.
Another mistake is failing to version-control privacy settings. If you change a retention mode or disable conversation history, you need evidence of when the change happened. Without timestamps, you cannot explain why one user’s data was retained longer than another’s.
FAQ
Does No Training On My Data Mean No Retention?
No. A provider can avoid using your API inputs for training while still retaining request logs for security, billing, or abuse monitoring. The retention period and log scope determine the practical exposure.
How Can I Tell If API Logs Include My Health Info?
Ask for a data inventory: what fields are stored (prompt text, outputs, attachments, metadata) and for how long. If the vendor cannot describe log contents, treat the risk as higher and minimize sensitive content before sending.
Can A Provider Delete My API Data Immediately?
Deletion depends on the contract and the system design. Many providers delete after a retention window rather than on demand, and some data may persist in backups for a limited period.
Is De-Identified Training Data Always Safe?
De-identification reduces risk but does not guarantee zero re-identification risk. The strength of de-identification depends on the dataset, the safeguards, and the possibility of linking with other data sources.
What Should I Redact Before Sending Prompts?
Redact direct identifiers (names, addresses, phone numbers), exact dates when not required, and record numbers. Use placeholders and summaries rather than pasting full documents unless the workflow requires it.
Author's Insight
Training data and API data retention solve different problems: training shapes model behavior over time, while retention governs what the provider stores after each request. Privacy reviews work best when you ask for a retention breakdown by data type, not a single statement about “training.” Contract terms under HIPAA, GDPR, and related agreements can change the obligations, but technical minimization still reduces exposure regardless of legal role.
When vendors describe policies, the most actionable details usually sit in the retention and logging sections, not in the general “no training” language. If you document your redaction rules and test them with sample prompts, you can reduce the chance that sensitive content ends up in logs or outputs.
Key Takeaways
- Training data affects model learning; API retention affects what gets stored after you send prompts.
- “Not used for training” does not automatically mean “not retained.” Ask for retention windows for inputs, outputs, and attachments.
- Redact identifiers and exact dates before sending prompts, and treat outputs as potentially echoing sensitive text.
- Use contracts (DPA/BAA) and ask about sub-processors, cross-border transfers, and deletion behavior.
- Review your own app logging too; internal backups can outlast vendor retention.
