The tier you are on decides more than the toggle does
Across the market, the same product is usually sold twice. Free and personal subscriptions run on consumer terms: the account holder is an individual, defaults tend to favor product improvement, and the controls sit in a personal settings menu that no administrator can see. Team, business, and enterprise tiers of the identical interface typically run under a commercial agreement with different default handling, admin-level controls, and a data processing addendum you can point at during an audit. Same model, same answers, different contract.
This matters because AI adoption in small companies almost never starts with a contract. Someone signs up with a work email on a personal plan, gets real value, and the workflow becomes load-bearing before anyone reads the terms. By the time a business tier is purchased, months of prompts have already gone through the consumer path, in an account the company does not own, cannot audit, and cannot off-board when that person leaves.
So before you evaluate any vendor's privacy posture, establish which product you are actually on. Check the billing entity, confirm whether a data processing agreement exists and who signed it, and see whether an admin console shows you the accounts in use. If half your team is on personal plans, that is the finding. The terms you are relying on are not the terms you are operating under.
Training, retention, and abuse monitoring are three different settings
These get collapsed into one idea, and they do not work the way people assume. Opting out of training means your content should not be used to update model weights. Retention is how long that content sits in the vendor's systems in readable form. Abuse monitoring is a separate pipeline that keeps its own copy so the provider can detect misuse of the platform, and it commonly continues after training is disabled, often with its own window and its own possibility of human review.
The practical consequence is a conversation that goes wrong in an audit. A team flips the training switch, reports that customer data is not retained, and is mistaken. Content can be absent from the model and still sit in a log store that a support engineer or a safety reviewer can query. Whether a human at the vendor could ever read your prompt is a separate question from whether the model learns from it, and it is the question that matters when the content is health information or privileged client material.
Zero-retention arrangements do exist across the market, but they are not a checkbox in a settings page. They generally require a specific plan or a negotiated agreement, apply per endpoint or per API rather than blanket across an account, and switch off anything that depends on stored state: conversation history, file libraries, some caching, some evaluation tooling, and sometimes the vendor's ability to help you debug a failed request. Ask which endpoints are covered, what stops working, and how you would demonstrate the setting was in force on a given date.
The copies you made yourself
Retrieval systems are the largest blind spot. When you build a knowledge base for an assistant, source documents get chunked and embedded into a vector store, and every one of those chunks is a copy of your content living in a second system with its own access rules. Deleting the original file from your document system does nothing to the index. Treat the vector store as holding the material itself, not a harmless numeric summary, and assume anyone who can query it can recover the substance of what you put in.
The second blind spot is your own observability stack. If your application calls a model, you are almost certainly logging the request and the response so you can debug it, and if you added a tracing or LLM-monitoring tool you are storing full prompt and completion payloads by default. That store often has a longer retention window than anything the model vendor applies, looser access controls, and subprocessors of its own. Teams that negotiate hard on the vendor contract routinely pipe every prompt into a third-party dashboard that most of engineering can read.
Then there is ordinary sprawl. Prompt and output text pasted into support tickets, transcripts emailed to a client, evaluation datasets assembled from production traffic, response caches, and backups of all of it. Each is a copy with its own lifetime and its own audience. An inventory that stops at the model vendor is measuring the smallest part of the problem.
Deletion is a propagation question, not a button
In most systems, delete means the record stops appearing in the interface. What it does to derived artifacts is a separate question you have to ask out loud. A deletion request may remove a conversation from your account view while leaving entries in operational logs, safety review stores, and backups that age out on their own schedule. None of that is necessarily improper, but you cannot answer a customer's deletion request accurately unless you know which of those it reached.
Fine-tuning is where this gets genuinely hard. If a customer's records were in the training set for a fine-tuned model, removing them from the dataset does not remove their influence from the resulting weights, and there is no reliable way to extract one record from a trained model. The realistic remedies are retraining from a corrected dataset or retiring that model version, both of which cost time and money. Decide whether you can afford either one before you fine-tune on anything containing personal or confidential material.
This is why the design decision matters more than the deletion procedure. Where content is sensitive and subject to deletion requests, prefer retrieval over fine-tuning: an index entry can be removed, a weight cannot. Where you do fine-tune, keep dataset lineage, meaning which records went in, whose they were, and on what basis, so a deletion request produces an answer instead of a shrug.
Subprocessors and where the data physically sits
Your vendor has vendors. AI products run on cloud infrastructure, frequently route to a separate model provider, and commonly use third parties for content moderation, analytics, error tracking, and support tooling. Each one is a place your prompt can land. Commercial agreements usually include a subprocessor list and a right to notice when it changes, and both are worth reading, because that list does change and a change can move your data to a company or a jurisdiction you would not have picked.
Residency claims deserve the same scrutiny. A statement that data stays in a given region can still mean that inference runs there while support staff elsewhere can open a ticket containing customer content, or that payloads stay put while logs and metadata route globally. If residency is a real constraint for your business, ask which categories are covered by name: prompt payloads, model outputs, logs, metadata, backups, and staff access. The answers are frequently different for each.
None of this requires you to become a privacy specialist. It requires you to get the answers in writing before a workflow becomes load-bearing, keep them with the contract, and re-check at renewal. Terms behind products you already trust get rewritten more often than you will notice on your own, and your obligations to your customers do not move when a vendor's policy does.
Turning training off does not delete anything, and the copies most likely to hurt you sit in your own vector store and observability logs rather than the vendor's. Count the copies a single prompt creates, then find out what deletion actually reaches.