Data Minimisation Against AI Value

Last updated: 2026-08-15

The tension between data minimisation and AI value is resolved by sequence rather than compromise: decide what decision the system must support, work backwards to the minimum data that supports that decision, and collect only that. Systems designed by collecting everything available and then searching for value produce the largest exposure and the weakest results.

How to resolve the tension between collecting less personal data and building useful AI: decide what the system must accomplish before deciding what it may collect.

Data Minimisation Against AI Value

The tension is real and usually stated badly. Data protection asks for the minimum necessary. Machine learning improves with more data. Presented that way, the argument is unwinnable and typically resolved by whoever is more senior in the room.

The framing is wrong, because it assumes the amount of data is the variable. In practice the variable that decides both privacy exposure and system usefulness is the same one: how precisely the task has been defined.

Sequence, not compromise

Systems that collect broadly and then look for value produce the worst of both outcomes. The exposure is maximal because everything is retained. The results are weak because a model trained on whatever happened to be available is optimising for a task nobody specified.

The workable sequence runs the other way.

Start from the decision. What decision or process does this system change, and who owns that decision today? A system that cannot answer this is not ready for a data conversation, which is why the AI use case intake form asks it first.

Work backwards to the minimum data that supports that decision. Not the data that might be interesting. The fields whose absence would make the decision impossible.

Justify each additional field individually. Every field beyond the minimum should have a stated reason and an owner willing to defend it. In practice this conversation removes more fields than any policy does, because most additions turn out to be habit.

Set retention at collection. A retention period decided later is a retention period that never arrives. It belongs in the same decision as the field itself.

Where minimisation genuinely costs capability

Being honest about the trade matters, because pretending it is free invites the whole argument to be reopened later.

Minimisation costs most where the value lies in the long tail: rare conditions, unusual case patterns, small language communities. Aggressive minimisation can remove exactly the records that would let a system serve the least typical users, which is a fairness problem as much as a capability one.

Two techniques recover part of that. Working on derived features rather than raw records keeps the signal while discarding the identifying detail, for instance retaining a coarse age band rather than a date of birth. And synthetic or aggregated data supports development and testing without exposing the underlying population, though it should not be treated as equivalent for validating the final system.

Neither eliminates the trade. They narrow it.

Where minimisation is not the binding constraint

Often the argument for collecting more is really an argument about data quality. A team asks for additional fields because the existing ones are inconsistent, undocumented, or duplicated, and more data feels like the remedy. It is not. Fixing the fields already held usually delivers more than adding new ones, and it is what data readiness for AI describes.

The privacy assessment that is worth doing

A privacy impact assessment for an AI system is useful when it answers operational questions rather than restating law. Six are worth writing down.

What decision does the system inform or make, and about whom. What is the minimum data required for that decision, field by field, with a reason attached to each addition. Where does inference happen, under whose jurisdiction, and who can see the inputs, which for generative systems means who can read the prompts. How long is each category retained, and what deletes it. What happens to a person when the system is wrong, and how would they find out a system was involved. And who is accountable, by name.

The last question is the one that most often has no answer, and it is the one that determines whether the rest of the assessment has any force.

Where the subjects are vulnerable

In humanitarian contexts this stops being a compliance exercise. Data describing displaced people may expose them to the authorities they fled, so minimisation, retention limits, and access control are protection measures. The question of where inference happens becomes a safeguarding question, treated further in LLM security in public institutions and AI for humanitarian organisations.

In that setting the default inverts. Rather than asking what could be collected and whether it is permitted, ask what the system must accomplish and what the smallest amount of data is that would accomplish it. The answer is usually less than the original specification, and the system is usually no worse.

Written by Shahzad Asghar, Head of Data and Digital Solutions at UNESCWA. See all articles, the playbooks, and the templates.