In the last unit you decided how long data should live and when it should be disposed of. Now the question moves one step deeper. It's no longer "are we allowed to keep this" but "should we use it this way at all?" Here's the trap waiting for you: a request can clear every legal and privacy box, sit comfortably in the right classification tier, and still cause real harm to real people. Your triage habit doesn't change. You still identify the risk, gather context, consult the right partner, and document a recommendation. What changes is the kind of risk you're scanning for, because the most important line in this unit is that "legal to hold" is not the same as "appropriate to use."

Most harmful uses don't announce themselves. They look like ordinary, well-intentioned requests, so you need a short list of warning signs to catch them early. The first is hidden secondary use: data collected for one reason gets quietly repurposed for another. Support notes gathered to resolve tickets, for example, later get mined to rank customers, a use no one mentioned when the notes were written. The second is unfair exclusion, where a process leaves a particular group worse off without a justifiable reason, like a model that consistently routes certain customers to slower service.

The third signal is the sneakiest. A proxy variable is a field that looks neutral but quietly stands in for something you'd never deliberately score on, such as race, age, or income. ZIP code is the classic example: it seems like a harmless location field, yet it often tracks closely with protected characteristics. The fourth is weak consent context, where people technically agreed to something buried in a terms-of-service page but would be surprised, even upset, to learn what their data now drives. When you spot any of these in a request, that's your cue to slow down, the same way "I'm not sure about the rules" was your cue in the retention unit.

Once a signal trips, you need a structured way to think it through rather than reacting on instinct. The Ethical Data Use Review gives you that structure. You clarify the purpose, name the affected groups, check the data's provenance (where it came from and what it was collected for), surface fairness concerns, weigh transparency expectations, identify the accountability owner, walk through foreseeable harm scenarios, and only then land on a go, no-go, or go-with-safeguards recommendation. Four lenses do most of the work: fairness (does this disadvantage anyone unfairly?), transparency (would the people affected be shocked to learn this is happening?), accountability (who owns the outcomes when it goes wrong?), and foreseeable harm (what's the realistic worst case?).

• Chris: We already store ZIP code and purchase totals, so building a value score from them is fair game, right?
• Matt: Legally holding the data is one question. Whether scoring on ZIP is fair is a different one.
• Chris: It's just a location field. How is that unfair?
• Matt: ZIP often tracks closely with income and race, so the score could quietly shut out whole neighborhoods, even if no one intended that.
• Chris: So it stands in for something we'd never score on directly.
• Matt: Exactly. That's a proxy variable, and it's the kind of thing we flag before anything launches, not after.

Notice that Matt didn't accuse Chris of anything. He separated the two questions and gave him a concrete picture of who could be harmed, which is what moves a confident sponsor from "what's the problem?" to "I hadn't seen that."

Spotting the risk is only half your job. A flat "no" rarely lands, and it isn't yours to issue anyway. Your move is to protect the person's goal while removing the harm. That usually means one of three things. You recommend a safeguard, like removing or testing ZIP code to see whether it's driving the outcome. You add a review checkpoint, such as a fairness review before launch rather than after. Or you offer an alternative path, like scoring on actual customer behavior that doesn't stand in for a protected trait. Each of these keeps the business outcome alive while cutting the avoidable harm.

And you must know your ceiling. The moment a use involves automated scoring that affects how people are treated, a real possibility of discrimination, or a contested high-impact decision, you've reached the governance-versus-specialist boundary again. Document your review and pull in an ethics, legal, or privacy partner for the final sign-off. You frame the risk and recommend; they make the call.

The single takeaway: holding data legally never settles whether using it is fair, so your job is to scan for the signals, run the review, and recommend safeguards before anything ships. Three practices build on each other from here. You'll first spot the biggest ethical risk in a set of proposed uses, then write a full review of a customer-scoring case, and finally challenge a confident sponsor live. For the next data request that feels a little too clever, try asking one question out loud before anything else: "Who could this quietly leave worse off?"