Structure beats prose

Structure beats prose

A third minimisation that costs nothing. When you have structured data, send it as structure.

The bad version pastes a rendered document, an email chain, or an exported PDF into the prompt. Everything in that document goes, including the signature blocks, the disclaimer footers, the routing headers, the previous six replies, and whatever was in the quoted text at the bottom that nobody has read since March.

The good version extracts the fields the task needs and sends those. It is less convenient and dramatically smaller, which has the pleasant side effect of reducing cost and latency alongside exposure.

If you must send free text, send the relevant span rather than the whole document. The last message in a thread is usually the only one the task needs.

Ask whether the field is needed, out loud

The single most effective habit is embarrassingly low-tech: when adding a field to a prompt, say why.

Keep it in the code, where it stays honest:

public sealed record CandidateForScreening(
    string Skills,          // needed: the task scores against required skills
    string Experience,      // needed: years and relevance
    string EducationLevel   // needed: minimum qualification check
    // deliberately excluded: name, email, phone, address, photo, date of birth,
    // nationality, gender. None affects a skills match. Excluding them also
    // removes the most common bias vectors from the screening decision.
);

That comment is an artefact. It is your data protection impact assessment in the place where it is most likely to be maintained, it is the answer when an auditor asks how you determined what was necessary, and it is a standing argument with the next developer who wants to add a field for convenience.

What this actually eliminates

Run the exercise across your own application and count. This book will not give you a multiplier, because no study measures one and inventing a number here would undercut the argument of Chapter 4. What the exercise reliably surfaces is a category of finding rather than a ratio: fields that reach the model because an object was serialised, not because the task needed them. Count yours, and the count becomes the business case for the hour it takes to fix.

The detector is the most expensive row and the least effective. That is not an argument against it, because the remainder it catches is real and includes the free-text disclosures no projection can prevent. It is an argument for the order of operations. Minimise first, measure what is left, then size the detection layer against the residue rather than against the original problem.

Minimisation also happens to be exactly what GDPR Article 5 asks for. Data must be adequate, relevant, and limited to what is necessary. A field projection with a comment explaining each inclusion is that obligation, expressed in C#.

One weakness: minimisation is a decision each developer makes, hundreds of times, in dozens of places. Conventions decay, marker interfaces get bypassed with a quick record that implements the interface and carries everything, and someone always ships a hotfix at five o'clock on a Friday.

Which means you need one place where every model call passes through, whatever the calling code intended.

Sources for this chapter

• Data minimisation: personal data must be adequate, relevant and limited to what is necessary — GDPR Article 5(1)(c); equivalent purpose-limitation duties under the CCPA and the other state laws cited in Chapter 2.
• Minimise at source before applying detection — practitioner consensus across the architecture sources listed in Chapter 13.

This chapter deliberately contains no statistics. An earlier draft carried a multiplier for how much excess personal data a typical LLM feature sends. It was removed because no study measures it, and inventing one would contradict Chapter 4. The IPromptSafe marker, out-of-band slots and the justification comment are patterns offered as engineering arguments.