Most data ethics failures I've seen up close don't come from bad people. They come from a skipped question at the wrong moment: a survey reused for a purpose nobody consented to, a "de-identified" dataset that wasn't, a transcript pasted into a chatbot because it was 11pm and the deadline was 9am. The researcher in each case would have made the right call if the question had been in front of them at the time.
So this article isn't a theory of ethics. It's the set of questions I ask, and teach others to ask, at the four moments in a project where the harm usually gets baked in: when you collect, when you de-identify, when you share or reuse, and when you hand the data to a machine. It comes out of years of supporting researchers through data services and IRB preparation, watching where projects actually go wrong.
Moment one: collection. What did people actually agree to?
Consent isn't the signature. It's the match between what participants understood would happen to their information and what actually happens to it. The signature just records the promise. That framing makes the practical questions obvious:
- Would a participant be surprised? If someone who signed your form watched everything you later did with their data, would any of it surprise them? Surprise is the test. Legality is a floor, not the test.
- Are you collecting more than the question needs? Every extra field is a liability you carry for years. If you don't need date of birth, collect an age range. If you don't need names, don't take them. The cheapest data protection is the data you never collected.
- Does your consent language survive the whole project? If you might share the data, deposit it in a repository, or use it to train a model later, the form has to say so now. Retro-fitting consent is somewhere between painful and impossible.
Moment two: de-identification, and its limits
Removing the name column doesn't de-identify a dataset. This has been demonstrated over and over: a handful of ordinary attributes (a ZIP code, a birth date, a job title, a rare diagnosis) can be enough to re-identify a person when combined, especially in small populations. A "de-identified" survey of faculty at one small college can be trivially re-identifiable, because how many associate professors of chemistry does one campus have?
The questions to ask:
- How small are the cells? Cross-tabulate your quasi-identifiers (role, department, gender, year). If any combination points to fewer than a handful of people, you haven't de-identified anything; you've written a puzzle with an easy answer.
- Who would bother, and what would they gain? Threat isn't abstract. A dataset about course evaluations invites different re-identification interest than one about commuting patterns. Match the effort of protection to the realistic incentive to attack.
- Free text is the leak. Open-ended responses carry names, places, and stories that no column-dropping touches. If you share qualitative data, someone has to actually read it first.
Dropping the name column doesn't make data anonymous. It makes it a puzzle, and for small populations the puzzle is easy.
Moment three: sharing and secondary use
Funders increasingly require data sharing, and that's mostly good: shared data gets checked, reused, and cited. But "share responsibly" hides real decisions. Not all data belongs in a public repository, and access tiers exist for a reason. Aggregate tables can be fully public while the record-level file sits behind a data use agreement. Restricted doesn't mean hidden; it means the reuser makes the same promises you did.
Secondary use deserves its own question, because it's where consent quietly expires. Data collected to evaluate a tutoring program is not automatically fair game for a study of student mental health, even if the variables happen to be there. Before reusing data (yours or anyone's), ask: is this new purpose within what participants were told, and if not, who gets to decide that it's acceptable? Often that's the IRB, and often the answer is yes with conditions. The failure isn't asking and being told no. The failure is not asking.
Moment four: AI tools, the newest way to leak data
The fastest-growing data ethics problem on campuses right now is ordinary and mundane: a researcher pastes interview transcripts, student records, or grant text with preliminary data into a public AI chatbot to "help summarize." At that moment the data has left the institution, landed on a third party's servers under that company's terms, and possibly entered a training pipeline. No consent form anywhere covers that, and no IRB protocol I've seen approves it by default.
The questions before any dataset touches an AI tool:
- Where does this tool actually send the data? Not the marketing page: the terms. Consumer chatbot tiers, institutionally contracted versions, and models running on hardware you control are three different answers with three different risk levels.
- Would you email this data to a stranger? If the answer is no, don't paste it into a consumer tool. The test is the same because the act is roughly the same.
- Is there a private option? Increasingly, yes. Universities can run capable models on their own infrastructure, which is exactly why I build private, document-grounded AI for institutional data. Sensitive data and useful AI aren't mutually exclusive; they just can't meet on a public server.
Making it routine instead of heroic
None of this works as a one-time compliance event. What works, in my experience, is making the questions boring and habitual: a short data plan at project start (the same thinking a data management plan forces anyway), a named person who owns the dataset, a five-minute check before anything is shared or pasted anywhere new, and an honest conversation with your IRB early instead of a defensive one late. IRBs are far more helpful as consultants at the design stage than as auditors after the fact.
Data ethics has a reputation as the thing that slows research down. Done at the right moments, it's the opposite: projects that settle these questions early don't stall mid-stream when a repository asks about consent language, a reviewer asks about re-identification risk, or a chatbot's terms of service turn out to say what they've said all along.
If your institution wants help putting this into practice, from consent language and de-identification review to a private AI setup that keeps sensitive data in-house, get in touch.