What happens to what you type into an AI tool

The same model, three different contracts

A consumer chat app, a business or API account, and a model running on hardware you control are not one product at three prices but three legal arrangements that share a model. The consumer tier is written for the largest number of users and the loosest expectations; the business tier is where the commitments a professional needs — no training on your content, a data processing agreement, a named retention period — tend to live. The underlying model is often identical while the terms are entirely different.

This article deliberately names no provider's current settings, because that is the fastest way to be wrong. Major providers have changed their training defaults more than once, and a policy summarised in a blog post eighteen months ago is not evidence of anything today. What governs you is the page dated today on the provider's own site, plus whatever contract your organisation signed, which overrides it.

Four questions, and what the answers mean

Is my input used to train models, and is that the default or something I switch on? Notice the second half. A provider that trains by default and offers an opt-out has told you something different from one that trains only on opt-in, and both differ from a business tier where training is contractually excluded. Ask whether the opt-out is retroactive: it normally governs future training runs only, and nothing you can request will remove what a shipped model has already learned.

How long is it kept? "We don't train on your data" is not an answer to that. Three separate stores are usually in play: the conversation history you can see and delete, abuse- and safety-monitoring logs you cannot, and backups. Deleting a chat typically removes it from the first and starts a clock on the others. A serious answer is a number of days, in writing. Some providers offer zero-retention arrangements to API customers who ask and qualify — the request is processed and nothing is stored afterwards — which is the strongest ordinary commitment available short of running the model yourself.

Who inside the company can read it? Every provider has staff access of some kind: support handling a ticket, an engineer debugging an incident, a reviewer looking at content a classifier flagged. "Nobody" is not credible; the credible answer is a small set of named roles, logged access, and a stated trigger. Ask specifically whether flagged content is routed to human reviewers, because that is the likeliest path by which an unusual document is read by a person.

Which tier am I actually on, and what happens in a shared workspace? The common failure in professional settings is not a provider breaking its word — it is a lawyer or clinician using a personal free account for work because it was already open in a tab. In a team workspace, ask who else sees a conversation, whether an administrator can export everything, what happens to a departing employee's chats, and what connected integrations pull in without the person typing having chosen it.

Things people don't count as data, but are

A screenshot is data. It is uploaded, stored as a file and read by a vision model, and it usually carries more than intended: the email subject lines behind the window, the file path, another client's name in an adjacent tab. Uploaded files often sit in a different store from chat text, under a different retention rule. If the document was indexed for retrieval, deleting the file does not necessarily delete the derived index — ask about that explicitly, because a retrieval index almost always keeps the chunk text itself beside the vector, which makes it a second copy of the document by construction. The vectors alone are not a safe anonymisation either.

The layer between you and the model may not belong to the model's maker. A browser extension, an IDE plugin, a mobile app wrapping someone else's model — each is a separate company with its own terms, and some proxy every request through their own servers, where it can be logged. A free wrapper is not necessarily selling anything, but if you cannot say how it is funded and where its servers are, you have added an unknown party to a confidential matter. Coding assistants deserve the same question: many send surrounding lines and sometimes neighbouring files as context, not only the snippet you highlighted.

One correction, because the fear is usually aimed at the wrong place: your prompt does not flow into the model's weights as you type. Training is a separate, batched, later process, so the realistic risk from one sensitive paste is a copy sitting at rest somewhere, or inclusion in a future training set — not the model repeating your contract to a stranger this afternoon. The exceptions are features designed to do exactly that: persistent memory, and shared workspaces where the audience is your own colleagues.

Running it yourself, and what that costs

Open-weight models you can run on your own server, or a small one on a laptop, remove the provider from the question: nothing leaves the building. Models small enough for modest hardware are meaningfully weaker at long multi-step reasoning, at using tools reliably, and at holding a complicated document in mind — and small open models are weaker again in Arabic, where they have seen far less training data, dialect, unvocalised text and the root-and-pattern morphology most of all.

Self-hosting also relocates the problem rather than dissolving it. Your inference server has logs. Your GPU machine needs access control, patching, backups and someone who understands all three. A hospital that self-hosts has become the custodian of the same sensitive text, and may be less practised at it than the vendor it was avoiding. Between the extremes there is ordinary discipline: strip names and identifiers before sending, describe the situation rather than uploading the whole file when reasoning is what you need, keep work on a work account, and turn retention off where the tier allows it.

Where the data is, and whose rules apply

Most major providers process requests in the United States or Europe. The large clouds do operate regions in the Gulf, but whether the specific model you want is served from one of them is a separate question, and the answer often lags the model's release badly. For many Iraqi and Gulf organisations this settles the matter before anyone reads the privacy policy: if the data may not leave the country, no amount of good contractual language satisfies the requirement.

Whether that requirement applies to you depends on your sector and your jurisdiction, and this article will not tell you what the rule is. The shape of the question is consistent even where the answers differ: a national data protection or telecoms rule may exist; a sector regulator — banking, health, telecoms — often imposes stricter requirements than the general ones; a government or client contract may be stricter than either; and lawyers and doctors owe a professional duty of confidentiality directly to the person whose information it is. That last one matters most, because it does not transfer. A vendor's clean policy does not discharge your obligation; it may only mean that disclosing to the vendor requires the client's or patient's informed consent, and your bar association, ministry or regulator answers that, not the provider's marketing page.

Get the answers before the upload, not after, and get them from documents rather than a chat window — a support agent's reassurance is not a contract. MentronX publishes Firas AI, and these questions apply to it too, including what happens to a document placed in Firas Brain. Ask us in writing, as you would any vendor.