What Really Happens to a Prompt Sent to a Public AI (and When It Becomes a Problem)

July 14, 2026 · 4 min read · SOVALYX Technologies

A prompt sent to a public AI leaves your organisation: it is transmitted to the provider's servers, logged, retained for a period defined by the provider's policy and, depending on the plan and settings, sometimes used to improve the models. None of this is secret — but few users have actually read it. Here is the real journey of a prompt, and the cases where it becomes a problem.

The journey of a prompt, step by step

1. The prompt leaves your network, encrypted in transit, and lands on the provider's servers — often in a different jurisdiction from yours.
2. It is logged: prompt, response and metadata (account, timestamp, IP address) enter the provider's systems.
3. It is retained according to the provider's retention policy — a period the provider sets, and which legal obligations can extend.
4. Depending on the plan and settings, it may be reviewed (moderation, abuse prevention) or used to train the models.

Serious providers document all of this in their policies. So the problem is not that the provider lies: it is the gap between what the policy says and what your teams believe. A free consumer plan and an enterprise API account do not follow the same rules at all — and the former is often the one your staff actually use.

Three questions that determine the risk

Training. Some consumer plans use conversations to improve the models unless a setting says otherwise; enterprise plans generally exclude it by contract. The right question is not "does the provider train on data?" but "which exact plan, with which settings, is really being used by my teams?" — the one you bought is not always the one in use.

Retention. Even without training, prompts are kept: technical logs, conversation histories, the provider's own internal backups. Data "deleted" from the interface has not necessarily disappeared from the systems, and a legal preservation obligation can extend its lifetime without your knowledge.

Sub-processors. An AI provider relies on hosting companies, moderation tooling, support contractors. Each one is an extra link, potentially in a different jurisdiction, with its own practices. Your data inherits the weakest link of that chain — a chain you generally do not know.

When it becomes a real problem

• Personal data: sending a client's or employee's data to a tool without an adequate contractual framework engages your liability. For a Mauritian company serving European clients, the obligations follow the data — see DPAs, GDPR and hosting in Mauritius.
• Trade secrets: source code, contracts, unpublished financials, product roadmaps.
• Contractual commitments: your clients' confidentiality clauses and NDAs prohibit disclosure to third parties — and a public AI is a third party.
• Regulated sectors: finance, healthcare, legal services, where traceability of processing is required.

It is no coincidence that, since 2023, corporate policies banning public AI for sensitive data have been multiplying. But prohibition alone fails predictably: if the tool is useful, it will be used — quietly. It is the same blind spot as the OAuth connectors of SaaS AI assistants: the durable answer is not a ban, it is an alternative that is just as convenient.

The alternative: an internal LLM on private infrastructure

Open-weights models now make it credible to run enterprise AI entirely on infrastructure you control. The principle is simple: the prompt never leaves your perimeter. No imposed retention — you set the logging policy; no third-party training — nothing your teams write leaves the building; no invisible sub-processor chain — you know every link. We detail the real budget, hardware and use cases of a private LLM in a dedicated article. It is the architectural choice SOVALYX operates with private AI: internal LLMs, hosted on a private cloud, where no data is ever sent to a public AI.

Checklist: before pasting text into a public AI

• Does the text contain personal data (clients, employees, applicants)? If so: stop, or apply genuine anonymisation — not just removing names.
• Does it contain information under NDA or covered by a client confidentiality clause?
• Does it contain trade secrets: code, contracts, unpublished figures, roadmaps?
• Do you know which exact plan (consumer or enterprise) and which settings apply to the account being used?
• Is the provider's retention policy compatible with your contractual commitments?
• Is there a validated internal alternative for this type of task?
• Is your AI usage policy written, known and workable — rather than a ban everyone works around?

If the answers to these questions are not obvious to your teams, the subject deserves more than an internal memo. Talking it through with an architect often settles it in a single meeting: what may go to public AI, and what must stay inside.

🧰 The companion tool: Are you ready for the AI Act? — free · 2 minutes.

Reviewed and optimised by AI.