Unit 13: Privacy and data handling

Reading time: about 12 minutes. Activity: about 12 minutes.

1. The question this unit answers

The usual advice is a single paragraph: do not paste confidential or personal material into an AI system. That is a sound instruction and it is not enough to act on, because it does not say what happens to what you paste, and without that you cannot judge the cases the sentence does not cover.

This unit says what leaves your device, what is retained, and what "do not paste this" means when the material is not obviously secret.

It does not state your institution's rules or the law. Those exist, they differ by place and by organisation, and they are not this course's to invent. What the course can give you is the shape of the thing, so that when you read your own rules you know what they are talking about.

2. What leaves the device

With a hosted service — anything you reach through a browser or an app, rather than a model running on your own machine — what you supply leaves your device. Exactly what happens to it then is a property of the product, and products differ. The rule that holds regardless:

Assume material you submit to a hosted service may be transmitted to and processed by the provider and whoever it works with, unless that product's documentation and settings establish otherwise.

That covers your prompt, the conversation, any file you attach, and anything a tool fetched on your behalf.

None of this is specific to AI. Online translators, grammar checkers, cloud drives and a forwarded screenshot raise the same questions, and people leaked confidential material long before any of them. What AI changes is how much gets handed over and how casually: whole files and whole inboxes rather than a sentence, and, with agents and connectors, material that leaves without you pasting anything. Asking the assistant what it does with your data is not a check, either: its answer is generated text and may not reflect your account's settings. The policy and the settings page, read on a date you record, are the evidence.

Three things follow that people are routinely surprised by.

An attachment goes whole. You asked about one clause; the document went. If the file has tracked changes, comments, hidden columns, or a second sheet, those are text too. Whether the whole of it then reaches the model is a separate question — some products index or chunk a file and retrieve parts of it — but the file left your machine either way, and that is the part that matters for privacy.

Earlier turns keep going. A conversation carries its history, so something you pasted twenty turns ago is generally still in play rather than gone. Whether it is re-sent verbatim from your device, summarised, or kept by the service and read back in varies by product. Either way it is processed again with each new turn, in whatever form is kept, rather than once.

Deleting the conversation is not deletion. It removes it from your view. Whether and when the provider's copies, backups and abuse-monitoring logs go is a question about that service's policy, not about the button.

3. What is retained, and by whom

This is where a course that cannot date itself has to be careful. Retention depends on the service, the plan you are on, and settings that change. So rather than facts that will be wrong next year, three questions whose answers you can go and find, and which your own rules will assume you have found:

1. Is this input used to train future models? It may be a setting, and the answer may differ between a free tier and a paid or institutional one; the provider's policy says which. A default may answer it differently from the way you would.
2. How long is it stored, and who can read it? A provider may retain conversations for a period, for example for abuse monitoring, and that can mean staff access under conditions its policy states.
3. Where is it processed, and under what terms? Server location is part of this and not the whole of it: which law applies can depend on who the data is about, who is responsible for it, and what the contract says. You are not expected to settle that. You are expected to notice that it is a question, and to ask whoever handles it where you work or study.

If you cannot answer all three for the service in front of you, that is itself the finding. Record it, and apply the classification below strictly.

A product can also keep material by design. One provider's documentation, as of November 2026, describes two such features. Saved memory and instructions carry from one conversation into later ones, and memory can be on by default [D1, "Instructions for Claude"], [D2, "What is Claude's memory?", "How Claude stores memory"]. A public link to a shared conversation can be read by anyone who has the link, and copies made from it survive after you revoke the link [D3, "Frequently asked questions"]. A connector that gives a service access to your mail or files works the other way round: material reaches the service without you pasting anything. Find out which of these are switched on for you, and note the date you looked.

4. What can happen to a copy

Once your material reaches a service, there is a copy you do not control. A policy says what the provider intends to do with it, and what it commits to; it does not decide everything that can happen to it. Five routes, three of them with a documented case:

• Kept and read. As the questions above ask: a provider may keep copies, in logs, backups or for abuse monitoring, and its policy states for how long and who may read them.
• Learned from. Where input is used for training, a model can occasionally repeat what it was trained on: researchers extracted hundreds of passages word for word from one model's training data, names, phone numbers and email addresses among them [L12, p. 2633]. That is how something you sent could reach someone else, long after your conversation ended.
• Ordered kept. A court can require a provider to keep what it would otherwise delete. In 2025 one provider was ordered, in a copyright lawsuit, to keep chat logs it would otherwise have deleted, until late September; the logs kept under the order stayed available [D7, pars. 1-3].
• Exposed by mistake. In March 2023 a bug in an open-source library showed some users of one chat service the titles of other users' conversations, and could show them some paying subscribers' names, billing addresses and the last four digits of their cards [D6, "How did the ChatGPT data leak happen?"].
• Taken on purpose. A person with access inside the provider, or at a contractor it works with, can misuse what they can reach, and an attacker who breaks into a service can copy what it holds. That can happen wherever data is held, whatever the policy says.

Some of this nobody at the provider intended: a bug, a breach, a log kept longer than the policy says, a court order to keep data or hand it over. Some of it is somebody's deliberate misuse. None of it needs the provider to mean to break its word. A provider's terms are a promise about what it intends and commits to, not a guarantee of what happens to your copy. So before you send something, ask not only whether the service promises to keep it private, but whether it would matter if this copy got out. If it would, the classification below decides, not the promise.

5. A classification you can apply in seconds

Not a legal taxonomy. Four bands, sorted by who is harmed if the material becomes readable by someone else.

These bands are one dimension, not a permission slip. That is the most important sentence on this page. A band tells you about the privacy risk — who is harmed if this becomes readable by someone else. It does not tell you whether you may use the material, and three other questions sit alongside it:

• Rights. Public does not mean unrestricted. A published paper, a photograph, a piece of code on a public repository and a database of public records all carry licences or terms, and Unit 14 is about exactly this. "I found it in public" settles nothing about what you may do with it.
• Purpose and terms. The service you are pasting into has its own terms, and your institution or employer may have approved some services and not others.
• Assessment rules. Material that is entirely yours may still be assessment-restricted, and that is a rule about the task rather than about the data.

So the first row means "the privacy risk here is low", and the second means "no third party is exposed by this". Both leave the other three questions open. A published page can still hold someone's sensitive details, and your own notes can describe identifiable people; material like that belongs in the third band.

The third and fourth bands are the ones that matter most, and they are the ones a sentence about "confidential information" does not reach.

Someone else's is broader than it sounds. A message a friend sent you. A draft your colleague shared. An interview transcript. A photograph with a person in it. Health, financial or immigration details about anybody. The test is not "is this marked confidential" but "did somebody else give me this expecting it to stay where I put it".

Not yours to decide is the band people miss entirely, because nothing about the material feels sensitive. A dull internal spreadsheet is often covered by an agreement someone else signed. The point of the band is that the decision is not yours to make on the material's apparent importance.

6. Working with material you cannot paste

The useful move is almost never "do not use the tool". It is to change what you send.

Redact and generalise. Replace names, dates, identifiers and distinctive details. "A patient" not a name; "a large employer in the sector" not the employer. The task usually survives this untouched, because you were asking about structure, not about the person.

Redaction reduces risk; it does not by itself make material anonymous or make its use authorised. A combination of details can identify someone with every name removed — a role, a date and a place is often enough — and an organisation may forbid sending even de-identified material to a service it has not approved. Removing the names is the beginning of that judgement rather than the end of it.

Abstract the question. You rarely need to send the document to get what you want. "Here is a clause I have rewritten with all identifying detail removed — does it say what I think it says?" is a different question from pasting the contract, and it usually gets the same answer.

Bring the tool to the data. Where a locally-run model or an institutionally-approved service is available, the first question — what leaves the device — gets a different answer, and that is often the whole difficulty solved. It does not remove the question. A local application may still check for updates, download models, sync to cloud storage, or send diagnostics, and the device it runs on has its own exposure. Ask what leaves, rather than assuming that local means nothing does.

Watch re-identification. Removing a name is not always removing a person. A combination of details — a role, a place, a date, an unusual circumstance — can identify somebody as surely as a name, especially in a small institution. Ask whether the remaining details would let a colleague work out who it is. You are the worst possible judge of that, because you already know the answer.

7. The one about your own work

Your unsubmitted coursework is in the "yours alone" band as far as privacy is concerned. Whether you may use an AI system on it is a different question entirely, governed by your institution's rules on assessed work, which this course does not state and cannot.

Keeping those two questions apart matters, because they have different answers and different authorities. "It is my own work so there is no privacy problem" can be true at the same time as "and I am not permitted to do this".

A rule like this protects only as far as anyone can check that it is kept. An institution that forbids or requires something it has no way to verify may believe it is protected when it is not, and it is fair to ask what such a rule can achieve on its own. That is a question for the people who write the rule, and it does not make a rule you are bound by optional. Those writing one have to ask what they can realistically expect people to do, and what they can check, and design the rule, and the guidance and support around it, on that basis.

8. What this unit is not saying

It is not saying hosted services are unsafe. It is saying that what leaves your device is a fact you can establish, and that the classification depends on whose material it is rather than on how secret it feels.

It is not giving you a rule to follow instead of your institution's. Where they conflict, theirs governs. This gives you the vocabulary to read theirs.

Summary

• With a hosted service what you supply leaves your device, including the parts of an attachment you were not asking about, and earlier turns are processed again as a conversation grows, whether your device re-sends them or the service keeps them and reads them back in.
• Deleting a conversation removes it from your view; what it does to stored copies is a question about the service.
• Three questions to answer about any service you use for anything but public material: is it used for training, how long is it kept and who can read it, and where is it processed.
• Classify by whose material it is: public, yours alone, someone else's, or not yours to decide. The last two are the ones a warning about "confidential information" misses.
• The move is usually to change what you send — redact, generalise, abstract the question — rather than to abandon the task.

Then answer cp13-what-leaves and cp13-whose-material at the foot of this page.