TL;DR & Quick Summary
"Is it safe to send our data to an AI model?" is the question that stalls more enterprise AI projects than any technical constraint. It is also the wrong question, because it has no general answer. The same model, from the same provider, can be governed by wildly different terms depending on which tier you bought and which configuration you enabled.
The answerable version is narrower and contractual:
Training — may the provider use our inputs to improve their models?
Retention — how long is our data stored, and can that be set to zero?
Human review — can staff at the provider read our prompts, and under what circumstances?
Sub-processors — who else receives this data downstream?
Residency — in which jurisdictions is it processed and stored?
Key Takeaway: Your data inherits the weakest terms in the chain. A vendor with excellent security whose product calls a model provider with weaker terms has passed you the weaker terms, whatever their own documentation says.
Get Started: Building on regulated or confidential data and want the architecture right before the build? Book a Strategy Call with Cogniq AI or see how we approach custom AI development.
A note on scope. This article gives you the framework and the questions. It deliberately does not publish a comparison table of named vendors' current terms, because those terms change frequently and a table that is wrong is worse than no table at all. Verify every answer against the agreement covering your tier, on the day you sign it.
Why the Consumer/Enterprise Distinction Dominates Everything
The single most common security failure in corporate AI use is not an exotic attack. It is an employee pasting confidential material into a consumer chat interface governed by consumer terms.
The distinction matters because providers generally operate at least two very different arrangements:
- Consumer tiers are optimised for product improvement. Historically these have often permitted training on user content by default, with an opt-out available to those who find the setting.
- Enterprise and API tiers are optimised for procurement. They typically exclude training by default, offer configurable retention, and are backed by a negotiated agreement with defined liability.
Two consequences follow, and both are routinely missed.
First, a company-wide policy banning "AI tools" does not work and tends to push usage underground. What works is providing a sanctioned route governed by the right terms, then making that route easier than the unsanctioned one.
Second, the technical evaluation and the contractual evaluation are separate exercises. Confirming that a model performs well on your task tells you nothing about whether you are allowed to send it the data. Teams that run only the first evaluation discover the second one late, usually during a security review that stops the project.
The Five Questions
1. Training rights
Ask: does our input, and the model's output, get used to train or fine-tune any model?
Get the answer in writing, scoped to your tier. Watch for two things. Marketing pages describe the product generally; the agreement governs your account specifically, and where they conflict, the agreement wins. And training exclusion is narrower than people assume — a provider can genuinely exclude training while still retaining your data for abuse monitoring, which is a separate question you must ask separately.
2. Retention
Ask: how long is our data stored after the request completes, and can that be reduced to zero?
Retention typically exists for a legitimate reason: providers store recent requests to investigate abuse. That is defensible, but it is still a window during which your data exists on someone else's infrastructure and is discoverable, breachable, and subject to their jurisdiction.
Zero data retention is commonly available on enterprise tiers as an opt-in rather than a default, and is sometimes a paid add-on. Two practical implications: enabling it is an explicit action someone must actually take, and its cost belongs in your build estimate rather than arriving as a surprise. Confirm it is switched on for your account, not merely available on the price list.
3. Human review
Ask: under what circumstances can your employees read our prompts?
Most providers reserve some right of human inspection tied to abuse detection or legal process. This is not unreasonable, but it must be known, because for some categories of data — privileged legal material, unreleased financials, patient records — any third-party human access is itself the breach, regardless of the reviewer's intentions.
4. Sub-processors
Ask: list every third party that receives this data.
This is the question most often skipped, and it is where the real exposure usually sits. A large share of AI products are interfaces over someone else's model. When you send data to such a product, it typically travels to at least the vendor's cloud host and the underlying model provider.
Each hop carries its own terms, and your effective protection is the weakest link in that chain, not the terms of the vendor whose logo is on the invoice. Ask for the sub-processor list explicitly, and ask to be notified when it changes — a vendor that silently switches model providers has silently changed your terms.
5. Residency
Ask: in which countries is this processed and stored?
Relevant when you have EU personal data subject to transfer rules, contractual commitments to your own customers about where their data lives, or sector rules requiring in-country processing. Note that processing location and storage location can differ, and that "we're hosted on a European region" is not the same as a contractual guarantee that no processing occurs elsewhere.
Turning Answers Into Enforceable Terms
Satisfactory answers on a sales call are not protection. The controls belong in the agreement.
| Term | What it does | Watch for |
|---|---|---|
| Data Processing Agreement | Defines the vendor as processor and binds them to your instructions | Must name sub-processors and require notice of changes |
| Business Associate Agreement | Required for protected health information under HIPAA | Needed from every party in the chain, not just the one you contract with |
| Confidentiality | Covers material that is sensitive but not regulated | Ensure it survives termination |
| Deletion on termination | Forces removal when you leave | Specify a deadline and require written certification |
| Breach notification | Obliges disclosure | Specify hours, not "promptly" |
| Audit rights | Lets you verify | A current third-party audit report is usually the realistic form |
Two clauses justify particular attention.
Deletion on termination is frequently vague. "We will delete customer data following termination" without a deadline is unenforceable in practice. Specify a number of days and require written confirmation that it has happened.
Breach notification measured in hours. GDPR obliges a controller to notify a supervisory authority within 72 hours of becoming aware of a personal data breach. If your processor is not contractually bound to a shorter window than that, you can breach your own obligation while waiting for them — you cannot notify within 72 hours if you learn on day four.
Architecture: Reduce What You Send
The strongest control is not contractual. It is sending less.
Redact before transmission. Many tasks do not need the identifiers they are routinely given. Summarising a support conversation rarely requires the customer's full name, account number, or email address. Strip identifiers at the application layer, process the redacted text, and re-associate the result locally. Data that never leaves your infrastructure needs no contract to protect it.
Segment by sensitivity. Not everything requires the same treatment. A workable three-tier split:
| Tier | Examples | Typical handling |
|---|---|---|
| Public | Marketing copy, published docs | Any sanctioned tier |
| Internal | Ops data, non-regulated records | Enterprise tier, no training, short retention |
| Regulated | Health, payment, privileged | Zero retention, signed DPA/BAA, redaction, residency control |
Applying tier-three controls to everything is expensive and slows adoption to the point where people route around it. Applying tier-one controls to everything is negligent. The segmentation is what makes the policy survivable.
Log what was sent. If you cannot reconstruct what data went to which provider on which date, you cannot assess the scope of an incident, and you cannot answer a regulator or a customer asking whether their information was involved. This logging is cheap to build at the start and unpleasant to retrofit.
Constrain agent permissions. An AI agent with write access to production systems is a security boundary, not merely a productivity feature. Scope credentials to the minimum the task requires, prefer read access where the task allows it, and require human confirmation for irreversible actions. The relevant question is not whether the model behaves correctly on a normal input, but what it can reach when given a malicious one — a live concern wherever an agent processes text originating outside your organisation.
What Good Looks Like
A defensible position on LLM data security has five components, and none of them are exotic:
- A sanctioned route that is easier to use than the unsanctioned one.
- A data classification that says plainly which tier may go where.
- Written answers to the five questions, for every provider in the chain.
- Contract terms with deadlines attached, not adjectives.
- Logs sufficient to scope an incident after the fact.
Notice that only one of these is about the model. The security posture of an AI system is mostly determined by decisions made before any model is chosen — which is why this work belongs at the architecture stage, alongside the automation audit rather than after the build.
Conclusion
The organisations that move fastest on AI are generally not the ones with the loosest security. They are the ones that answered these questions once, wrote the answers down, and stopped relitigating them on every project.
The questions are stable even though the vendor landscape is not. Providers change terms, launch tiers, and swap sub-processors; what you are allowed to send, to whom, under which agreement, and for how long it persists remains the same set of five things. Ask them at the start of each engagement rather than during a security review that has already stopped the work.
If you are building on regulated or confidential data and want the architecture and the contract questions handled before development starts, book a strategy call. We build AI integrations for businesses where getting this wrong is not a recoverable mistake.
