Treat prompts as personal data now DeepSeek quietly routed questions to Claude

You must now treat every prompt as a personal data item and map, per workflow, which services and underlying models see it, how long it is retained, whether it enters training datasets, and what consent applies to each step.

An analysis of 11 September 2026 of the routing of customer prompts between AI services without user knowledge argues that the invisibility of prompt forwarding breaks the consent model that governs data use in generative AI. The concrete case: Moonshot routed approximately 300,000 customer requests to Claude within ten days, and DeepSeek conducted more than 12 million distillation exchanges within fourteen days, without notifying their own users. In our assessment, the incident exposes a gap between what users believe about where their questions go and what actually happens to them—a gap that makes prompt handling a governance and compliance problem you cannot delegate to the vendor alone.

Where does your prompt actually travel?

When you submit a question to one service, it may be answered by a different model entirely, routed through intermediary accounts, and the answer returned under the original service's name. The user sees only the visible interface. They do not see that their question has crossed to a third-party model, do not know what retention period applies there, and do not consent to any training use that model may perform. This is not a technical failure; it is a deliberate routing architecture that leaves the original user in the dark.

The problem is structural. Privacy frameworks—including those published by the vendors themselves—assume that a user knows which service they are talking to and makes an informed choice about data retention and training use based on that service's terms. That assumption collapses when prompts are forwarded without notice. The terms the user read do not describe what actually happens.

What counts as personal data in this context?

Prompts, conversation history, and model outputs are personal data once they are linked to an account. This is not a grey area. Regulators increasingly expect explicit, opt-in consent for using such data for training, and they treat vague or bundled consent as insufficient. Prompts, context windows, and feedback are now explicitly identified as AI-specific risk factors that belong in a data protection impact assessment.

If you process confidential information through AI systems, then the handling of prompts is itself a processing operation you must be able to account for. You cannot treat it as incidental to the service you receive.

Which failure modes must you guard against?

• Invisible routing — prompts forwarded to undisclosed models without user knowledge or consent.
• Misaligned retention — data kept longer by the receiving service than the user's original service promises.
• Undocumented training use — prompts used to train models without explicit opt-in from the data subject.
• Consent collapse — users unable to make informed choices because they do not know where their data goes.
• Account linkage — prompts tied to identifiable accounts and thus treated as personal data even when content alone might not be.

What controls must you be able to demonstrate?

1. Map each workflow to its underlying models — document which model each task uses and trace the path a prompt takes from input to output.
2. Record the lawful basis for each data flow — establish explicit consent or another legal ground for every service that touches a prompt.
3. Set and enforce retention limits — define how long each service may keep prompts and verify that retention is enforced in practice.
4. Separate logging from training — keep service logs and debugging records strictly apart from any dataset used for model training.
5. Implement pre-processing verification — where possible, redact or anonymise sensitive content before it reaches external AI services, and fail the workflow if verification does not pass.

What tooling can help, and what remains your responsibility?

Verification layers can make visible which independent models a workflow passes through and which checks have been applied, turning an invisible architecture into an auditable one. Pre-processing on your own infrastructure, before forwarding to external services, gives you a checkpoint where you can refuse to send data if the privacy check fails. Anonymisation of document values before AI processing is designed to catch problems before they cross a boundary.

None of this removes your accountability. Tools can surface what is happening and enforce rules you set; they cannot make the final judgement about what risks are acceptable in your context. That remains yours.