Summary: Why your worry is rational: three things to actually worry about

The lesson started with a cloud: the word “privacy” in the news, arriving as a flood of overlapping concerns with no clear floor or ceiling. Aisha, an eighth-grade English teacher handed a new AI tool by her principal, did not want the cloud. She wanted a list. The lesson turned the cloud into one. There are not infinity privacy concerns for the situations Sarah encounters. There are three. Naming them is the first move; acting on them is the rest of the track.

Worry 1: Surveillance

The threat. When Aisha types a student’s name into the tool, the text leaves her laptop immediately. It travels across the network to the AI company’s systems, a model processes it, and the reply comes back. At multiple points along that path, software handles the text automatically and the people who maintain that software can read it if they have a reason and the access. Some logging systems record pieces of it by design. This is not a failure of the system; it is how the system works. The specific path shape differs from vendor to vendor; what matters at this stage is that the moment Aisha presses Enter, the content is no longer only on her own machine. The Electronic Frontier Foundation frames the intimacy problem plainly: chatbots reveal people’s most sensitive information, including questions about health, safety, and personal situations that people would never post publicly.

What Aisha can do. Treat the chatbot like a postcard, not a sealed envelope. Postcards are fine for general questions with no identifying information attached. They are wrong for student names, parent phone numbers, or anything where exposure would have a real consequence. Prefer tools that let you opt out of training data collection, prefer shorter retention windows, and check the data-handling policy before you paste anything sensitive. The full data-flow trace comes in Phase 2.

Worry 2: Storage and leak risk

The threat. Surveillance is about what gets seen on the way. Storage is about what gets kept after the trip. AI chatbot requests are typically processed on a cloud server and may be stored by the company. Mozilla’s privacy research is direct: nothing on the internet can be 100 percent secure. Your conversations with an AI chatbot are valuable to hackers, which raises the risk that the stored data is exposed in transit or from storage. A softer version of the same risk: a human reviewer at the company may read a conversation flagged for a policy concern, or one selected for training review. The content Aisha pastes is not guaranteed to stay between her and the model.

What Aisha can do. Apply the what-if-leaked-tomorrow test. Before pasting anything, ask: if this conversation appeared in a news article next year with my name attached, what is the consequence? If the answer is nothing serious, paste. If the answer is job loss, a client complaint, or a parent’s legitimate grievance, do not paste. Two secondary moves help: find the tool’s settings for retention and training opt-out, and prefer tools whose architecture limits storage by design. Lessons 5.1 and 5.2 of this track teach how to recognize those tools.

Worry 3: Vendor lock-in

The threat. This is the slowest of the three to show up, and the one Sarah is least likely to anticipate. The rules under which she trusted the tool can change after she has trusted it. One major chatbot provider has 18 privacy documentation links: policy documents, usage policies, terms of use, model cards, system cards. A Mozilla privacy researcher working through them wrote, “I’m more confused than when I started.” Policy changes can shift a training-data default from off to on with the opt-out buried several menus deep. Data already given to the tool does not unsend reliably: some can be deleted on request; some has already been used to train a model in a way that is not easily reversed. And the longer Aisha depends on the tool, the harder it is to switch when the policy she doesn’t like becomes the one she has now.

What Aisha can do. Solve this worry earlier and later, not in the moment of use. Earlier: prefer tools whose privacy posture is architectural (the system cannot retain certain data because of how it is built) over tools whose posture is promise-based (the company says it will not retain the data). Promises change faster than architectures. Later: every few months, check whether the tool’s policy has changed in a way that affects you, and be willing to switch when it has. The five-question rubric in Phase 4 makes this check take under ten minutes.

Three pitfalls worth carrying

“Privacy mode” is not a privacy guarantee. Read what each mode actually promises: the specific protections are real, but narrower than the word suggests. “They cannot identify me” is not the same as “they cannot reach me.” Data about how you use a tool can be exposed in a breach even when your legal name is not attached. And the first privacy setting you find is rarely the whole picture. Multiple layers of settings interact: account-level, app-level, browser-level, feature toggles. Never assume the visible setting is the only one.

What comes next

Lesson 1.2 takes the three worries you can now name and turns them into a seed: one paragraph, written in your own words, about what you are protecting and from whom. That paragraph is the first draft of the personal privacy plan you will complete in lesson 6.6, after every phase of this track has added a piece to it. Aisha is no longer looking at an undirected cloud. She is looking at three specific questions, three specific protections, and a path that runs all the way through the track.

The cloud disperses when you name what is inside it.