If you search for research on privacy attacks against machine learning, you'll find no shortage of it. Papers show, again and again, that a trained model can leak surprising things about the data it was trained on — whether a particular person's record was included, what an unusual pattern in the dataset says about a whole group, sometimes even fragments of the original data itself. What you won't find nearly as often is anyone asking the people who actually build and run these systems whether they think any of this matters in practice.

That gap is where my current project starts. Not "can this attack work in a lab," which the literature has answered many times over, but "does anyone building real systems on real sensitive data think this is a risk worth worrying about — and if so, how much risk is too much?" Answering that meant putting together a study built around actual conversations with practitioners, rather than another simulated attack. This post is about what went into designing that study — the decisions that don't make it into the results section, but that shape everything about what the results end up meaning.

Why interviews, and not a survey

My first instinct, honestly, was to reach for something more scalable — a questionnaire I could send to a few hundred people and analyze statistically. But the questions I actually care about don't fit that format well. I want to know which threat scenarios practitioners find realistic, and there's no way to write a multiple-choice list of scenarios without deciding in advance what counts as a scenario — which is exactly the assumption I'm trying to test. I also want to know what makes a privacy leak "acceptable" or not, and that turns out to be a reasoned judgment people arrive at, not a number they already have on hand.

So the study is built around semi-structured interviews: a shared set of core questions asked of everyone, so I can compare across conversations, but enough openness that people can introduce scenarios or reasoning I hadn't anticipated. Concretely, that meant designing the guide in two different registers for two different goals. For "what threats do you consider realistic," I ask open questions and let people describe their own systems and concerns — that part is genuinely exploratory. For "what makes a leak acceptable," I start open-ended too, but then show people a set of candidate factors drawn from the existing attack literature (things like how close a leaked result is to the real data, or how confident an attacker would need to be) and ask them to validate, reject, or extend that list. It's a small distinction, but it matters: one part of the interview is discovery, the other is checking existing assumptions against reality.

Who gets to answer

The other decision that took longer than I expected was who counts as a "practitioner" here. It would have been easy to only talk to ML engineers — people who build the models. But threat relevance and acceptable risk are judgment calls that get made differently depending on where you sit: a data protection officer, a product manager weighing a feature's business value against its risk, and a clinician who works with patient data every day but has never trained a model are all going to answer these questions differently, and all three answers are relevant.

So recruitment is deliberately built around that variation — a short screening step checks people's technical background, their domain, and their exposure to sensitive data, so I can watch for genuine diversity of role and perspective rather than accidentally interviewing twenty variations of the same job title. It also means being careful about who not to include: it would be tempting to interview academic security researchers, since they know this literature best, but that's arguably the population whose assumptions I'm trying to check against reality, not confirm — so if they're included at all, it has to be a deliberate, clearly-labeled comparison group, not folded quietly into the main sample.

The unglamorous parts

A surprising amount of the design work has nothing to do with research questions at all. Every participant needs to know, in plain language, what happens to what they tell me — that interviews are recorded only to support accurate analysis, that transcripts are anonymized, that anyone can skip a question or stop at any point without needing a reason. None of that shows up in a results section, but skipping it isn't really an option: people are more candid about what worries them professionally when they trust the process around the conversation, and that trust has to be earned before the first question is even asked.

Where this goes next

The interviews haven't started yet — I'm still finalizing recruitment — but designing the study has already reshaped how I think about the underlying research question. Writing questions that had to work for a clinician, a compliance officer, and a security engineer alike forced me to strip out assumptions I didn't even realize I'd built into the framing. If the interviews go the way I expect, the result won't be a cleaner version of the existing attack literature — it'll be a genuinely different picture of which risks matter, to whom, and why, grounded in how people who actually carry this responsibility think about it.