Data minimization

Every field written and every record retained is a liability with no expiry: it can be adopted as fact, retrieved into a model, replicated to a system nobody is watching, or pasted into a tool nobody vetted. Data minimization treats the record itself as the attack surface and shrinks it — collect only what the task needs, write only what must persist, and age out what no longer earns its place.

In a sociotechnical deployment this is not a one-time schema decision but a standing discipline on the write edges: what the model is allowed to commit to the record, what a worker documents from an AI draft, how long either survives. Bounding those flows lowers exposure everywhere downstream at once, because there is simply less identifiable material in motion — less to read and believe, less to retrieve back into the model, less to carry out of the building under time pressure. It also bounds the ways data crosses the system boundary: less identifiable material reaches a vendor-hosted model and less is left to replicate out to an ungoverned store. Minimization slows those exits — it does not close them; a data-processing agreement or self-hosting closes the model's path out, and connection authorization closes the record's.

The person who owns this is typically a data-protection officer: an accountable role scoped to the systems holding personal data, empowered to say what is written and kept and what is not. National-survey findings put the demand squarely here — concerns about client data privacy and security are the profession's most-reported barrier to AI use, and stronger privacy and confidentiality protection is the single most-requested improvement to the tools.

Two costs belong in the same paragraph as the protection, because the practice already carries both. Practitioners in the cited literature deliberately omit sexual-orientation and gender-identity data from client information systems to protect people from exposure, forced outing or violence — a considered deviation from data-completeness norms, not a recording error. And a record deliberately kept thinner supports less verification: minimising trades exposure against the evidence the correction loop itself runs on. The duty that travels with it is purpose limitation — consent obtained for one purpose does not cover reuse of that data to train a model for another — which is how the data-protection regulation states the two together. Direction only: none of these sources measures the size of either cost.

The discipline it must never collapse into: deleting records blind to buy the appearance of safety. Removing content by volume rather than by what it contains can strip the benign material that was diluting the harmful, and a documented PAN-run scenario shows exactly this backfire — the contaminated share of a record system rising after a content-blind purge. Minimize what is written and how long it is kept; correct what is already there by content, never by panic.