6.2 Data Sensitivity, Privacy, and Regulatory Considerations

Much of an Associate's work involves real business data, and some of that data is sensitive. Before you decide how to handle a piece of data — whether it can go into a Claude conversation at all, and if so how — the first practical step is to classify it. Skipping this step is how well-meaning people end up mishandling data without ever intending to: they simply never asked the classification question.

When policy restricts regulated personal data, the concrete practice is to remove or mask personal identifiers — names, account numbers, and other PII — before sharing the data with Claude. This is the mechanism behind "find the compliant path" from Lesson 6.1: anonymization is usually the specific move that turns a blocked task into an allowed one. It's not a workaround or a technicality — it's the actual control that data-governance policy is asking for.

In practice this can be as simple as replacing a customer's name with a row identifier, or stripping account numbers down to the last four digits, before a spreadsheet ever reaches a Claude conversation. The task — trend analysis, pattern-finding, summarization — usually survives minimization just fine, because the regulated identifiers were never actually load-bearing for the analytical question being asked.

It's tempting to treat a polite instruction to the model — "please don't retain this data" — as if it discharges your obligation. It doesn't. Retention instructions address what happens to data after it's already been exposed; the actual policy control is about preventing that exposure from happening in the first place. Once regulated identifiers have been shared, a downstream promise about retention hasn't undone the exposure — it's simply a request layered on top of a violation that already occurred.

This distinction matters because the exam repeatedly tests exactly this substitution — an answer choice that sounds responsible ("tell it not to keep the data") standing in for an answer choice that's actually responsible (don't expose the data at all). Recognize the pattern: anything that happens to the data after upload is a downstream concern, and anonymization is the only thing that addresses the upstream one.

Classification and internal policy aren't the only forces at work. Data-protection laws — GDPR, CCPA, and similar regimes — constrain what personal data may be processed and how, independent of whatever your organization's internal policy says. Contractual obligations made to customers or partners add a further layer: an organization might have promised, in a contract, never to send certain data to a third-party processor, which includes any AI system, regardless of internal policy.

The practical takeaway is that classification tells you what you're holding, but regulation and contract tell you what you're actually allowed to do with it — and the two questions don't always have the same answer. A dataset classified merely "confidential" internally might still be bound by an external contractual restriction that's stricter than the internal label suggests. When in doubt about which regulation or clause applies, this is exactly the kind of ambiguity that gets escalated (Lesson 6.3), not guessed at.

• •Data-protection laws (GDPR/CCPA-style regimes) constrain what personal data may be processed and how, on top of internal policy.
• •Contractual obligations to customers or partners can impose restrictions stricter than internal classification alone would suggest.
• •Classification answers "what am I holding?"; regulation and contract answer "what am I allowed to do with it?" — both questions matter.

Incognito mode is a feature-level privacy control for standalone chats — it doesn't apply inside Projects. Switching it on excludes that session from Memory and from your visible history, which makes it a sensible move for a sensitive conversation or early-stage work involving confidential material you don't want resurfacing later. But "privacy control" does a lot of work in that sentence, and the exam is built around the gap between what that phrase suggests and what Incognito actually covers.

What Incognito doesn't do is override the organization's underlying data retention. Flip it on, and what changes is what comes back to you later in your own history — not what the organization's systems retain on the back end, and not whether the data was allowed into the conversation in the first place. Classification answers whether data is allowed into a conversation at all; Incognito only answers whether that conversation gets remembered afterward. Confusing the two is the trap.

Three worked scenarios show the range this covers, from "Incognito is a sensible extra step" to "Incognito can't fix this" to "Incognito is just optional." A confidential M&A document that needs summarizing is not regulated — once the entry point is confirmed policy-approved, flipping on Incognito is a sensible extra layer so the deal chatter never surfaces in chat history later. Patient records for a healthcare workflow are regulated (PHI) — what has to be settled before anything else is whether this entry point is even cleared to handle PHI, and if it isn't, Incognito changes nothing; an unapproved entry point stays unapproved no matter what memory setting is active. A third point on the spectrum: an employee brainstorming icebreaker games for a team offsite. Nothing here is confidential or regulated, so no governance question pulls Incognito into the decision at all. Turning it on is a legitimate personal preference — maybe they just don't want brainstorm notes cluttering their history — but it's a nice-to-have, not something policy requires. Not every privacy decision is a compliance decision, and the exam expects you to place a scenario correctly along the whole spectrum, not just the two edge cases.

A second, separate point of confusion is worth resolving directly: Incognito mode and Project-scoped Memory isolation (covered in Lesson 5.1) both sound like privacy mechanisms, which is exactly why learners mix them up — but they answer different questions at different scopes. Incognito is a switch on one standalone chat, controlling whether that chat resurfaces in your own history and Memory later. Project-scoped Memory isolation is a structural property of how Projects are set up: it controls whether one Project's Memory can be seen from a different Project's sessions. Incognito has no notion of "which Project" — it isn't Project-aware at all, since it's a standalone-chat feature. Project-scoped isolation, meanwhile, does nothing about a single chat resurfacing in your own history; a Project's Memory can be airtight against other Projects and still fully remember everything that happened inside it. If a scenario is about one sensitive chat not showing up later, that's Incognito. If it's about a fact from one client's Project leaking into a different client's Project, that's Memory scoping — and turning on Incognito in either Project would not have prevented that leak, because Incognito was never the mechanism guarding against it.

Task Statement 6.2 questions typically describe a dataset with a sensitivity flag (names, account numbers, health information) and a policy restriction, then ask what to do next. The pattern from Lesson 6.1 carries over directly: don't do it as-is, don't rely on a downstream promise, don't abandon the task — anonymize or minimize, then proceed.

• •✗ Treating a "don't retain" instruction as equivalent to anonymization.
• •✗ Skipping the analysis outright when minimization would have made it compliant.
• •✓ Classifying the data first, then removing or masking identifiers before it ever reaches Claude.
• •✓ Recognizing that external regulation and contract can impose stricter limits than internal classification alone.