Privacy and Your Data

A lawyer joins one of Plateful's data-team meetings and asks a question that stops the room: the churn model from Chapter 7 was trained on customer behavior — orders, taps, cancellations. Did those customers agree to that? They agreed to have food delivered. Nobody remembers a checkbox about becoming training data. And while the team is untangling that one, Iris, mid-sip of coffee, has a quieter realization: she pastes real customer complaints into a chatbot about once a week, to draft replies faster.

Those are the two seats you occupy in this page, and you occupy both at once. You are a person in the data — your orders, routes, and reviews are feeding somebody's models right now. And you are a person using the tools — typing things into models that someone else runs. Privacy in the ML era is a set of working rules for each seat, and both sets are learnable in one page.

Training Data Is People

Chapter 2 called behavior logs "data exhaust" — the records that pile up as a side effect of an app doing its job. Step back one inch and the exhaust is people: who ordered what, when, from where, how they complained, what they photographed. There is no such thing as training data about customers that is not, ultimately, information about humans and their lives.

Here is the distinction the lawyer was reaching for, and it is worth learning in exact words: using records to run a service and using them to train models are two different acts. You need the delivery address to deliver dinner — that use is obvious and agreed. Feeding a year of your dinners into a model that predicts, profiles, and nudges is a second use, and consent to the first is not consent to the second. Regulation increasingly agrees: Europe's GDPR, the landmark data-protection law, is built around exactly this idea — that people must know and agree to what their data is used for, not just that it is collected.

An analogy carries all three sections of this page, so meet it now: lending your diary to a biographer. Lending it so they can summarize your era is one agreement. Opening the finished book and finding your entries quoted verbatim is a different thing entirely. And anything you tell the biographer directly, over coffee, is theirs to keep. Diary-as-training-data, quotes-as-leakage, coffee-chat-as-prompts: three separate agreements, and the next section takes up the second.

Can a Model Leak What It Learned?

Topic 41 described a language model as something like a compressed picture of its training text — patterns kept, individual pixels mostly lost. Mostly. It is time to cash the "mostly" honestly: models can sometimes reproduce rare or unusual training text nearly verbatim. A name and address that appeared in one place. A private code snippet. An odd, distinctive sentence from a leaked document. Researchers have demonstrated this repeatedly by prompting models into regurgitating such fragments.

Keep the size of the risk precise, because both exaggerations are wrong. A model does not store its training set, and the overwhelming majority of records dissolve into patterns beyond recovery — your Tuesday pad thai is safe. Memorization happens at the tails: the rare, the repeated, the one-of-a-kind records are the ones that can surface. That is exactly why "it was just training data" is not a firewall — if your data is unusual enough to matter, it is unusual enough to potentially come back out.

What You Type In Goes Somewhere

Now the second seat. When Iris pastes a customer complaint into a chatbot, it feels like using a notes app — the words sit in a box on her own screen. But Topic 42 showed what actually happens: the prompt travels to the computers of whoever runs the model, gets processed there, and is governed by their terms — which may include keeping it, reviewing it, or using it to improve future models. A prompt is not a note. A prompt is a transmission.

That single reframe explains why workplaces now have rules about AI tools. Iris's complaint paste-ins contain names, order details, sometimes a phone number — she has been transmitting customer data to a third company weekly, with none of the agreements that would normally require. The working rule is one sentence: don't paste what you couldn't post. If a customer record, a contract, or a medical detail would be a breach on a public forum, it does not belong in a consumer chatbot either. Company-approved tools with proper agreements exist precisely to give that data a sanctioned place to go.

The Emerging Etiquette

Teams that handle this well follow a small set of habits, and none of them require a law degree. The first is data minimization: collect what the question needs, not everything you can grab "just in case". Topic 08 warned that hoarded data becomes a liability; here is the bill — every record you hold is a record you must protect, justify, and answer for. The second habit: anonymization, stripping names and identifiers from records, genuinely helps — and is famously breakable, because combining an "anonymous" dataset with other public data re-identifies people embarrassingly often. Use it; do not worship it.

The third habit is the lawyer's question, asked at the right time: did these people agree to this use? — asked before training, when the answer can still shape the project, not after, when the model already exists and the answer is a scandal. Iris adds it to her checklist right next to "which error hurts more?". It costs one sentence in a planning meeting and it is where privacy stops being an abstraction and becomes a work habit.