AI Data Compliance Map: The 10 Places a Prompt Gets Stored

OpenAI, Anthropic, Google, Mistral, xAI and Cohere keep API prompts for 30 to 55 days by default. Your own trace store and vector memory keep it until you delete it. When we review an AI stack, the question is never “which model do you use”. It is where the prompt gets written along the way: tracing platforms, evaluation datasets, vector stores, gateway logs and caches, the vendor’s abuse-monitoring logs, stateful API objects, and your own application logs. Each of those places has to answer the same questions. How long is it kept, can it be used for training, who can see it, which country is it in, and can it actually be deleted.

Key takeaways

A prompt in a production AI stack can land in 10 kinds of storage across the agent and application layer, the AI gateway, the inference provider and your own infrastructure; which ones apply depends on the features you have turned on. Trace stores, evaluation datasets and vector memory are the most common ones that do not expire on their own.
The question that matters most is whether a party uses your data for purposes it decides on itself, such as training a model it serves to other customers. That use needs its own assessment of role and legal basis, and signing a data processing agreement (DPA) does not settle it. “Product improvement” depends on the specifics: under CCPA it is not automatically out of bounds.
What zero data retention (ZDR) covers has to be confirmed vendor by vendor: which accounts, endpoints and models, whether caching counts, and whether stateful features still work. Among the vendors we checked, some disable batch and file features under ZDR and some carve caching out of the contractual definition, but neither is a general rule.
Choosing an EU region only covers part of the data flow. Global endpoints, cross-region inference, stateful features without regional endpoints and the location of abuse reviewers can all move data out of the region.
The AI-specific laws already in force ask deployers for three things: tell users they are dealing with AI, label generated content, and embed a provenance marker in file metadata. All three can be built as product defaults.

We do privacy and security reviews of AI stacks, and this is the map we work from. It is part 1 of our series on privacy compliance across the AI supply chain: the map and the method here; later parts apply the six questions at the end of this article to real vendor terms for model vendors, AI gateways and inference hosts, and tracing platforms and coding agents. The legal points center on US and EU law, with rules already in force in the UK, South Korea, India and Vietnam mentioned where they add something. We state conclusions rather than quote statutes; primary sources are listed at the end. This is practitioner guidance, not legal advice.

Where does a prompt get written?

Commonly in 10 kinds of storage across four locations. Treat this as a checklist, not a claim that every application uses all 10, and do not infer what a component collects from its name; check the actual fields and configuration.

Location	Storage	What it holds	Default retention	Example
Agent and app layer	Tracing and observability platform	Prompts, outputs, tool-call arguments and results	14 days to “until you delete it”	LangSmith: 14 days base, 180 days extended; self-hosted Langfuse: indefinite
Agent and app layer	Evaluation datasets	Inputs and outputs copied out of traces	Never deleted	LangSmith datasets “will never be deleted”
Agent and app layer	Vector memory	Conversation chunks and their embeddings	No expiry	Deleting a conversation does not delete its vectors
Agent and app layer	Front-end analytics and session replay	Whatever the user types into the input box	Per tool settings	Captures the prompt before your backend sees it
AI gateway	Request logs and console	Full requests and responses, if enabled	By plan or by count	Cloudflare AI Gateway logs are on by default and evicted by count, not by age
AI gateway	Response cache and semantic cache	Full responses; semantic caches also keep prompt text and vectors	Minutes to a month	LiteLLM’s semantic cache stores the raw prompt text
Inference provider	Abuse-monitoring logs	Prompts and outputs; flagged content on a separate clock	30 to 55 days at the six major vendors we checked; flagged content on its own clock	Anthropic keeps flagged content up to 2 years and classifier scores up to 7
Inference provider	Stateful API objects	Conversation state, uploaded files, batch inputs and outputs	Per feature, often “until deleted”	OpenAI Conversations objects persist until deleted
Inference provider	Prompt cache	Prompt prefixes or KV tensors	Minutes to 24 hours	OpenAI: 30 minutes to 24 hours; Anthropic: 5 minutes or 1 hour
Your infrastructure	Application logs, reverse-proxy logs, developer transcripts	Request bodies, stack traces, session records	Often on by default	Claude Code keeps plaintext local transcripts for 30 days by default

One thing inventories often miss: the prompt sent to the model is not the same as the user’s input. The application adds system instructions, conversation history, retrieved document chunks and tool results, so look at both what the user submitted and what later steps added. Object storage, database replicas, backups and manually exported files belong on the list too.

Reading the table left to right, each location carries a different kind of risk.

In the agent and application layer, retention is by design. A tracing platform is, as a product, a database of prompts and outputs, and how long it keeps them is a project setting. Evaluators and automation rules can quietly move traces to a longer retention tier, and once a record is copied into a dataset the retention policy no longer applies to it. Langfuse’s documentation says so directly: project data retention “does not delete audit logs or dataset items”, and a saved dataset item remains usable after the original trace expires. Vector stores have no concept of expiry, so anything memory features write there stays.

The gateway chooses what it keeps. Billing needs usage records, so those always exist. Payloads can technically be skipped entirely. What usually crosses that line is a request-inspection console or a cache. An aggregator gateway adds another party: it forwards your request to an upstream model vendor, which becomes one more link in your chain.

Inference providers come in three kinds with very different terms. There is the model vendor’s own API; a cloud provider hosting the model on its own shared inference platform, under your cloud contract and region settings but not inside your tenant; and GPU hosts running open weights. The same open-weight model on a different host can land in a different country under different training terms.

Self-hosted inference removes the model vendor and the gateway, not the third parties. The weights run in a colocation facility, on cloud instances or on rented GPUs, so the data center operator or GPU provider is still a processor of yours; what changes is that nobody reads the prompt as a service feature anymore. Retention comes home: inference servers, reverse proxies and trace files all log by default, so the problem shifts from managing vendors to managing your own logs, plus one DPA with the infrastructure provider.

When does a vendor stop just processing data for you?

When it starts using your data for purposes it decides on itself. Training is the most common case, but the call depends on the specific use and who decides it, not on the feature name. Position in the technical chain does not fix the legal role either: the same vendor can play different roles in different processing activities.

Behavior	Crosses the line?	Where it shows up
Training or fine-tuning a general model served to other customers on your prompts and outputs	Needs its own role and legal-basis assessment; usually not processing on your behalf	Free tiers of model vendors; some domestic versions of Chinese vendors
Using conversations for “product improvement”	Depends on the use: improving the service provided to you may stay within CCPA service-provider limits; using the data to serve others does not	Tracing platforms, agent platforms, some open-weight hosts
Training its own routing or classification model on your requests	Needs its own assessment, depending on whom the model serves and whether data leaves your business relationship	Aggregator gateways
Granting a perpetual license to your prompts in exchange for a discount	Yes; the license itself authorizes the vendor’s own use	An opt-in at some aggregator gateways
Caching, billing and abuse detection needed to serve you	No, but the retention period must be stated	Every location
A model fine-tuned only for you and served only to you	No	Customer-dedicated models at hosts

GDPR and CCPA point the same way on this line but test it differently, so a conclusion under one cannot simply be carried over to the other. GDPR looks at who decides the purposes and essential means. A vendor processing for purposes it decides needs its own role, legal-basis and transparency analysis for that activity, and your DPA does not cover it; a vendor that exceeds the agreed use is also still bound by the contract’s limits and is in breach. The CCPA regulations let a service provider use data internally, under set conditions, to improve the services it provides to that business, so “product improvement” is not automatically disqualifying; check the specific use and whether the data serves anyone else. Where a vendor genuinely falls outside those limits, disclosing data to it may count as a “sale” or “sharing” that users can opt out of. The US Federal Trade Commission (FTC) has been equally direct: model-as-a-service companies are accountable for the privacy commitments they make, and quietly changing terms to start training on customer data may be deceptive.

The practical conclusion is simple, and it is the order we follow in every vendor review: before signing, check the default state and scope of the training and product-improvement switches and how the terms define “improvement”, and only then read the DPA. EU regulators start in the same place: in the questionnaire European data protection authorities sent OpenAI, the first two questions on disclosure asked whether OpenAI is the sole controller and whether it uses processors.

Make this judgment for every hop, not just the model vendor. A tracing platform running product analytics on your prompts, a gateway training its router on your requests and a GPU host keeping logs to tune its inference stack are the same problem in different places.

If you wrap someone else’s model and sell it to customers, there is a second line to watch. The EU AI Act calls the company that develops a system and places it on the market under its own name the provider, and the company using it the deployer. General-purpose model duties such as technical documentation and training-data summaries stay with the model maker. Using a vendor’s high-risk system as intended keeps you a deployer. You become the provider of a high-risk system, with its conformity, documentation and risk-management duties, when you put your name or brand on one, modify one substantially, or repurpose a general model or other non-high-risk system into a high-risk use such as screening job candidates or scoring credit. Building a hiring or credit tool on top of a general model is the most common route there. Companies outside the EU are in scope whenever the system’s output is used in the EU.

Who sits behind your vendor?

Its sub-processors, and on an aggregator gateway that layer can change with every request.

The standard practice is familiar: get the sub-processor list, confirm you are notified before additions, and check that you can object. That works for traditional SaaS because the list is stable. In an AI stack it breaks down in two places.

The first is the aggregator gateway, where routing decides which upstream receives your prompt, and routing can differ per request. OpenRouter’s API lists 82 upstream providers, 36 of which retain prompts and 25 of which state no retention period. Its published sub-processor list names only three parties involved in inference, and its DPA expressly excludes AI model providers from change notices. For an aggregator, the real change is a routing change, and no vendor promises to notify you of those. Technically, keep three control goals apart: no training, data residency and fixed routing. OpenRouter’s data_collection: deny and Vercel’s disallowPromptTraining filter upstreams by their data policies, which addresses the first goal; they do not pin routing, and they do not limit retention or processing abroad. If the business needs to restrict recipients, use an explicit allowlist of upstreams that also covers failover and retry paths, log which upstream actually served each request, and put downstream authorization and change terms in the contract.

The second is cloud-hosted inference, where the cloud’s architecture, not the model, determines whether the model provider touches your data. The same Claude Fable 5 model is reviewed on Bedrock without “sharing with the model provider”, while Google’s platform requires that “you must enable sharing this data with Anthropic”. Your choice of cloud decides whether Anthropic is part of your chain.

How do you verify contract terms technically?

Translate every contractual requirement into a setting, a log or an API behavior you can check. If you cannot check it, the requirement has not landed in your system yet.

Contract requirement	Technical counterpart	Where to look
Process only on your instructions	Default state of training and product-improvement switches; whether they apply per organization, project or workspace	Console, plan-specific terms
Specific processing purposes	Inference, caching, logging, evaluation and abuse detection listed separately, each mapped to a storage point	Your own data-flow diagram
Confidentiality and human access	Who can see flagged content, the approval process, where reviewers are located	The vendor’s abuse-monitoring documentation
Security measures	Encryption in transit and at rest, tenant isolation, whether cache keys include a tenant identifier	Security whitepapers, questionnaires, source code of open-source components
Sub-processors	The list, how changes are announced (email or RSS), whether routing can be pinned	Trust center, gateway configuration
Help with user requests	Whether you can find and delete a user’s data by user ID in traces, vector stores and logs	API documentation
Deletion on termination	Deletion window, backup purge cycle, whether dataset and evaluation copies are included	DPA annexes, product documentation
Demonstrating compliance	Per-request evidence, access logs, third-party audit reports	Response headers, trust center

Verification happens at three levels, and the three have to line up: the contract describes obligations, configuration shows feature state, and request records show observable behavior.

At the contract level, attach the vendor’s feature eligibility table to the contract instead of pointing to a web page that can change at any time.

At the configuration level, confirm the scope of each switch. Some apply per organization, some per project and some per workspace, and the level decides whether it covers your production traffic.

At the observability level, get per-request evidence. xAI returns an x-zero-data-retention header on every response, so you can log whether each call ran under ZDR as the vendor declares it. That is the vendor’s statement about one request, not independent proof that nothing was stored, copied or used for training. For what you cannot observe, such as internal security logs and backups, rely on contracts, technical documentation and audit reports, and write down what remains unverified.

What ZDR covers has to be confirmed vendor by vendor rather than assumed. Among the vendors we checked, OpenAI’s ZDR covers only stateless endpoints, with Assistants, Files and Batches unavailable, and OpenRouter’s DPA excludes caching strictly necessary to complete a request from its definition of ZDR. Other vendors differ, so check the terms and feature lists for which accounts, endpoints and models are covered, what data is still kept, and for how long. Retention can also be forced the other way: Anthropic lists Claude Fable 5, Mythos 5 and related models as Covered Models that require at least 30 days of retention on every platform, and ZDR customers are refused when calling them directly. Anthropic says a ZDR path for Fable 5 and 5.1 under its Enterprise Frontier Safeguards arrangement will roll out in fall 2026.

How long is data kept, and can it be deleted?

Each storage point runs its own clock, the longest ones usually sit on your side, and deleting a stored copy does not remove data from a model.

The legal requirement is simple to state. GDPR and CCPA both require retention to match the purpose and require you to tell users at collection how long you keep data or how you decide. Two categories have harder rules: COPPA requires a written retention policy for children’s data and forbids indefinite retention, and the FTC’s Safeguards Rule under GLBA, which covers non-bank financial institutions, requires customer information to be disposed of within two years of its last use unless it is still needed for business operations, the law requires keeping it, or targeted disposal is not feasible. The AI Act points the other way for high-risk systems, requiring deployers to keep system logs for at least six months.

In engineering terms, every storage point needs a documented purpose, a retention period or expiry condition, a deletion method and an owner, rather than a default. A system that can keep data forever does not show that the business needs it forever. The cells in the table above that say “until you delete it” or “never deleted” are exactly where you have to write your own deletion jobs. When a user asks for deletion, you should be able to find the linked conversations, evaluation samples, vector entries and files. Where backups cannot be purged selectively right away, document access restrictions, the overwrite cycle, and how deletion is re-applied after a restore.

Test deletion as well. Run a record containing no real personal data through the stack: create a session, generate a trace, and create an evaluation sample or memory entry in whichever of those features you actually use. Trigger deletion, then query each object and index to see what was removed immediately, what waits for expiry, and whether failures are retried. A test record that disappears proves deletion only for the objects and paths you tested; vendor-internal logs and backups you cannot query still depend on contracts and audit material. GDPR’s right to erasure has exceptions, and legal holds can pause deletion, but check the basis, scope and duration; “we might need to preserve it” is not a general reason to keep everything.

The biggest gap between buyers and vendors is the difference between deleting a conversation and removing data from a model. HECVAT 4.1.6, the security questionnaire used by US higher education, includes question AISC-01, which asks whether sensitive data that entered the vendor’s AI model can be removed on request, and names training sets, vector stores and memory. None of the vendor trust centers we checked answer it, and in our experience it is the question that stalls higher-education and healthcare deals. They answer the easier neighboring question of whether stored conversations can be deleted. Once data has been used for training, whether deleting the source files answers a deletion request has to be assessed against how the model processed it, and that is exactly the part vendors answer least. That is why “does it train by default” should be checked before “how many days is it kept”.

Two transparency points apply to training. The European Data Protection Board (EDPB) expects users to be told at collection that their input may be used for training, and says responsibility cannot be shifted onto users through terms of service. The AI Act requires general-purpose model providers to publish a training-content summary on the European Commission’s template, which includes a yes-or-no answer on whether data from user interactions was used for training. You can read that summary instead of relying on a sales pitch.

Which country does each hop’s data end up in?

You have to check endpoints, features and who has access one by one. Choosing an EU region covers only part of it.

Easy to miss	Why data leaves the region	Example
① Global endpoints and global deployment types	Inference can run in any region	Google’s global endpoints give no data residency guarantee; Azure Global deployments can process in any geography
② Cross-region inference	Requests are scheduled elsewhere and retained data is stored in the destination region	Bedrock with cross-region inference enabled
③ What “EU” means	An EU endpoint may exclude the UK and Switzerland	Google’s eu multi-region endpoint excludes the UK and Switzerland
④ Stateful features	Often not available on regional endpoints	Mistral’s stateful features do not support regional endpoints
⑤ Abuse review	Where data is stored and where reviewers sit are separate facts	Azure states that reviewers for EEA deployments are located in the EEA
⑥ CDN and edge networks	Requests are processed at the node nearest the user	Hosts commonly list their CDN as a sub-processor
⑦ Remote access	The data never moves, but people outside the region can log in and query it	A vendor’s support and operations staff outside the region; EDPB guidance treats this access as a transfer under GDPR, and the EO 14117 rule is about exactly this kind of access

The EU and US rules ask different questions, so the material you prepare differs too.

GDPR asks where the data goes, and who can reach it from where. When data leaves the European Economic Area, every hop needs a transfer mechanism and an assessment, and onward transfers by your vendors count as well. Storing data in Europe does not end the analysis: the EDPB’s guidelines on transfers state that remote access from a third country by another controller or processor, even just viewing data on a screen for support, troubleshooting or administration, is a transfer. Who is accessing matters. Your own employee on a business trip accessing company data is not a transfer; an independent vendor abroad getting access is.

The US asks who can access it. The Department of Justice rule issued under EO 14117 is concerned with whether bulk US sensitive personal data can be accessed by entities or people controlled by “countries of concern”, including China, and it expressly covers cloud computing services as vendor agreements. The DOJ has not addressed AI vendors specifically; applying the rule to them is our reading of its definitions.

In engineering terms, your data-flow diagram should mark three things for every hop: the endpoint type (regional, global or cross-region), where abuse logs and reviewers are, and who has access (your own staff or a vendor) and from which countries.

Which sectors add another layer?

Health, children’s, financial and education data, plus uses such as hiring and credit, add a set of requirements for every party in the chain. Being “just middleware” does not exempt anyone. In the US, where privacy law is sectoral and state by state rather than one federal statute, these are usually the first hard requirements a team runs into.

Data or use	Extra requirement	What it means technically
Health (HIPAA)	Every party and its downstream contractors need a business associate agreement; HHS lists third-party AI chatbot vendors as an example of business associates	If no model vendor will sign, route through a cloud provider that already signs a BAA for its hosted inference, which is why regulated teams tend to pick cloud hosting over direct vendor APIs
Children (COPPA)	Disclosing data to a third party that trains AI requires separate parental consent; a written retention policy is required	Keep training switches off with evidence; give every storage point an expiry
Finance (GLBA)	Under the FTC Safeguards Rule, service providers must be assessed periodically and customer information disposed of within two years of last use, with exceptions	Terms changes should trigger a reassessment; set expiry on traces and backups
Education (FERPA)	Contractors must be under the school’s direct control and cannot use data for themselves	Vendors that reserve “product improvement” rights generally do not qualify
Hiring and credit (AI Act)	High-risk system: human oversight, logs kept at least six months, use suspended when risks appear; a system in these categories that profiles individuals is always high-risk; applies from December 2, 2027, pushed back from August 2, 2026 by the 2026 amending regulation	Set a minimum log retention, not a maximum; build a switch that stops the system immediately; inferring emotions in workplaces and schools is prohibited

UK GDPR adds one more: significant decisions made solely by automated means need a route to human review and appeal, and that duty stays with you even when the output comes from a third-party model. South Korea’s AI Basic Act requires a pre-launch check on whether a system counts as high-impact AI, with hiring and loan screening explicitly listed.

What should users see?

Tell users they are dealing with AI, label generated content, and cover training and retention in your privacy notice. That is most of what the AI-specific laws in force require, and all of it can be built as product defaults.

Requirement	Where it comes from	Engineering implementation
Tell users input may be used for training, and how long it is kept	GDPR, CCPA	Privacy notice plus a first-use prompt, with wording that matches the actual switch settings
Tell users they are interacting with AI	South Korea’s AI Basic Act, Vietnam’s Law on Digital Technology Industry	Interface labels, spoken disclosure at the start of voice sessions
Visible labels on generated content	AI Act (deepfakes), India’s IT Rules, Vietnam	Text notices, image badges, video title cards
Hidden markers in file metadata	India’s IT Rules	Embed a generated-content attribute or unique identifier in exported files; India also bars offering tools to strip labels
Notice for emotion recognition and biometric categorization	AI Act	Separate notice to the people being processed

Making AI disclosure, content labels and metadata markers default features covers most AI-specific obligations currently in force. What remains jurisdiction-specific is South Korea’s high-impact self-assessment and the EU’s high-risk classification. For the EU product checklist, see EU AI Act Article 50: Product Changes to Make.

Japan’s AI Promotion Act is in force but has no penalties, Canada’s AIDA lapsed when Parliament was prorogued, the UK has no cross-sector AI statute, and Brazil’s bill has not passed. None of these currently require additional engineering work.

When is an impact assessment required, and what technical material do you need?

Under GDPR, a data protection impact assessment (DPIA) is required when processing is likely to result in a high risk to people’s rights and freedoms. Launching an AI application is not a trigger in itself; the answer depends on the nature, scale, context and purposes of the processing. Regulator guidance lists common signals such as new technology combined with large-scale processing, sensitive data or employee data, and production AI stacks often meet several of them. The CCPA regulations also require a risk assessment before processing sensitive personal information or training automated decision-making technology used for significant decisions. Cross-border transfer is not itself a DPIA trigger; it has its own transfer assessment.

The quality of the assessment depends on the technical material behind it. You need at least these seven items:

A hop-by-hop data-flow diagram showing every storage point, endpoint type and region.
Retention and deletion for every storage point, including caches, datasets and backups.
The sub-processor list, and how gateway routing is pinned.
The state of training and product-improvement switches, with configuration screenshots or response headers as evidence.
Human access: who can see prompts, under what conditions, from which country, and how long flagged content is kept.
The path for user requests: which storage points a lookup and deletion by user reaches, and which it misses.
Legal holds and exceptions: which deletion jobs pause when a preservation order applies.

The CCPA regulations are specific about wording: purposes cannot be described in generic terms such as “improving our services” or “security purposes”, and the assessment must state how long each category of information is kept and which recipients receive it. The seven items above support the assessment but do not replace the judgment on necessity, proportionality and risk measures. Adding long-term memory, moving production records into evaluation, changing upstream routing or adjusting retention settings can all change the earlier conclusion, so the data inventory and test scope should be updated with them.

If a court orders a vendor to preserve data, does your deletion promise still hold?

Not necessarily. A vendor’s “deleted after N days” gives way to a court preservation order, and this has already happened.

In The New York Times v. OpenAI, the court ordered OpenAI on May 13, 2025 to preserve and segregate all output log data that would otherwise have been deleted, including data users had asked to delete. The obligation ended on September 26, 2025. Data already preserved stayed preserved, except for requests originating in the European Economic Area, Switzerland and the UK.

The inference for any party in the chain (our analysis): the deletion timelines in your privacy notice depend on every vendor’s deletion jobs running on time, and those jobs can pause because of litigation that has nothing to do with you. Three engineering measures help. Strip or pseudonymize identifiers you do not need before requests reach the gateway. Prefer stateless endpoints. Record “vendor subject to a preservation obligation” as a risk in your impact assessment.

Six questions to assess any party in the chain

The whole article reduces to a checklist you can apply to each party. Later parts of the series use it to assess vendors.

#	Question	Evidence to obtain
1	How long is data kept by default, and does it vary by feature?	A retention table by endpoint and feature, covering abuse logs, flagged content, caches and stateful objects
2	Is there a no-persistence option, which features does it cover, and what breaks when it is on?	The accounts, endpoints and models ZDR covers, whether caching is included, and the features that stop working or behave differently under it
3	Is data used for training or product improvement by default, and at what level does the switch apply?	Defaults per plan; whether the switch applies per organization, project or workspace; per-request evidence
4	Where is data stored, can you choose a region, and where are downstream parties and reviewers?	Endpoint type, cross-region settings, sub-processor locations, reviewer locations
5	Who can access data manually, and how long is flagged content kept?	Review triggers, approval process, retention period
6	Who is the contracting entity, are the DPA and sub-processor list public, and how are changes announced?	Entity name and country; DPA version; list URL and notification channel

Fill in this table for every party in the chain: tracing platforms, vector memory services, gateways, model vendors, cloud hosts and GPU hosts. Any cell you cannot fill is your compliance gap, not the vendor’s.

Frequently asked questions

Is signing a DPA with a vendor enough to be compliant?

No. A DPA records what was agreed; compliance depends on what actually happens, including the real state of training switches, retention at each storage point, which upstreams your gateway routes to, and whether the terms have quietly changed. You need to confirm a vendor can deliver before signing and keep checking afterwards, reassessing whenever terms change. The CCPA regulations suggest reviewing at least once every 12 months.

A vendor says it does not train on or retain our data. How do we verify that?

At three levels that have to line up. At the contract level, attach the feature eligibility table. At the configuration level, confirm whether the switch applies to the organization, project or workspace, and whether it covers all production traffic and existing data. At the observability level, get per-request evidence such as a ZDR flag in the response headers. That flag is the vendor’s declaration for one request, not proof that nothing was stored or trained on; cover what you cannot see with audit reports and written statements.

What happens legally when employees paste customer data into AI tools using personal accounts?

The company has handed personal information to a third party with no data processing agreement, whose consumer tier usually trains on data by default. The Dutch data protection authority says that when employees do this against the employer’s agreements, it is a personal data breach, often one that must be notified; when the organization allows it, it is not a breach but is often still unlawful. Three controls address it: move business use to enterprise accounts or enterprise API keys enforced through single sign-on, block consumer AI domains at the network egress or gateway, and give employees a written policy on whether and how AI tools may be used.

If something goes wrong in the chain, who do users hold responsible?

You. Under GDPR the party that decides the purposes is the controller, and for an AI application’s users that is usually you; your vendors and their sub-processors answer to you, but you answer to users. CCPA gives users a private right of action when unencrypted personal information is breached because reasonable security was not maintained, with statutory damages of 100 to 750 US dollars per consumer per incident. A vendor’s fault does not automatically become your defense.

Primary sources (checked September 8, 2026; India IT Rules re-checked September 14)

EU: GDPR; EDPB guidelines on controllers and processors; EDPB guidelines on international transfers; EDPB ChatGPT Taskforce report; DPIA guidelines (WP248); AI Act and amending Regulation 2026/1744; training-content summary template; Dutch DPA guidance on AI chatbots.

US: FTC on AI companies upholding privacy commitments and on quietly changing terms of service; CCPA regulations; HHS business associate guidance; FTC Safeguards Rule; amended COPPA Rule; DOJ Data Security Program; NYT v. OpenAI preservation order and order ending it.

Vendor documentation (checked September 8 to 9, 2026; OpenAI, Anthropic and Mistral re-checked September 15): model vendors OpenAI your data; Anthropic API and data retention and commercial data retention and Covered Models; Mistral regional inference; xAI security FAQ. AI gateways OpenRouter provider logging, data collection and DPA; Vercel disallow prompt training; Cloudflare AI Gateway logging; LiteLLM caching. Cloud-hosted inference AWS Bedrock data protection, data retention and abuse detection; Google abuse monitoring and data residency; Azure data, privacy and security and abuse monitoring. Tracing and coding agents: LangSmith administration overview and data retention; Langfuse data retention; Claude Code data usage.

Other jurisdictions: South Korea AI Basic Act; Vietnam Law on Digital Technology Industry; India IT Rules 2021, MeitY consolidated text as of February 10, 2026, including the G.S.R. 120(E) synthetic-content amendment; EDUCAUSE HECVAT 4.1.6.