Before you size a control, size the damage. This book uses blast radius for the question: if this specific leak happens, what actually follows?
It varies by more than people expect. A single customer's name reaching a model under a zero-retention contract has a small blast radius. It is still a processing event you need a basis for, and it is not a catastrophe. The same name inside a support corpus you embedded into a vector store, which is queried by every user in a multi-tenant application, has a large one, because the leak is not one record and it is not one time.
Three questions size it quickly:
Answer those three and you know whether you are dealing with something that deserves an architecture (Part IV) or something a field projection fixes in an afternoon (Chapter 12). Most teams apply uniform controls to wildly non-uniform risks, which is how you end up with a redaction layer on your internal changelog summariser and nothing at all on the RAG index that contains the case notes.
The reflex, at this point, is to buy or build a detector. Put something in front of the model that spots personal data and strips it. It is an appealing shape for the problem: one component, one integration point, one line in the security questionnaire.
That instinct is the reason Chapter 4 exists, and Chapter 4 is uncomfortable. The independent cross-domain benchmarks put the best open-source detectors at an F1 around 0.48 to 0.54, against vendor claims of 0.92 to 0.99. One well-regarded model scores 0.780 on the data it was trained on and 0.169 on financial text it has not seen. Your data is, by definition, data it has not seen.
That does not mean detection is worthless. It means detection cannot be the wall. It is a second net, and a second net is a genuinely useful thing to have, as long as you have not fired the wall to pay for it.
The wall is architecture. It is choosing which fields go into the prompt, keeping identifiers out of band, and designing so that a detection miss is survivable rather than fatal. That is cheaper than it sounds and it is mostly available to you today, in code you already control.
Don't detect what you can refuse to send.
Personal data is flowing into models at a volume that has tripled in two years, and the large majority of it moves through channels your monitoring does not cover. Some of that is employees with a clipboard, which procurement can address. Some of it is your own services, sending whole objects because whole objects were convenient, and that part belongs to you.
Before you can stop it leaving, you need to agree on what "it" is. That turns out to be harder than it looks, because three different definitions of personal data are in common use and they do not agree with each other.
Unsourced, and offered as the author's argument rather than research: that the dominant cause of prompt leakage is object serialisation rather than deliberate choice, and the three-question blast radius model. Both reason from the mechanism; neither is a measurement.
Download the full PDF for free?
Free download — no account required