Databases built for one purpose get repurposed. That is the observed default, not a prediction. Data minimisation has been sold to executives as a compliance cost; it is more accurately a purchase of optionality across every future where the data becomes a liability.
The FBI’s CODIS database began in 1990 as a tool for matching DNA evidence at violent-crime scenes. It now holds over 20 million profiles, and its inclusion criteria have widened repeatedly, statute by statute, arrest category by arrest category. Nobody voted for the aggregate outcome. Each widening was individually defensible.
That trajectory is the observed default of every database that outlives its founding purpose, not a scandal. The question for an enterprise is not whether it would ever repurpose its data but whether the systems it is building this year will make the same offer to somebody, someday, that CODIS made to its successive custodians.
Repurposing is the default, and your systems are already making the offer
Apply the lens inward. Your customer data platform was built for personalisation. Your employee monitoring telemetry was built for security compliance. Your call recordings were built for quality assurance. Every one of those datasets has a second use that becomes attractive to somebody: a regulator, an acquirer, a litigant, or a future version of your own leadership under different pressure.
The offer does not need to be accepted today. It needs only to remain open. A dataset with no deletion schedule is a standing option, exercisable by whoever controls it next, under rules that do not exist yet.
The test that takes one meeting
Pick your largest customer dataset and ask what your legal obligation would be if a court ordered its production tomorrow. Most enterprises discover the answer depends entirely on retention policy, and that their retention policy was written by whoever configured the storage bucket.
The regulatory frameworks agree on the principle. UAE PDPL and GDPR’s storage limitation both require that personal data be kept no longer than its purpose demands. The enforcement pattern, however, is that regulators find out after the repurposing, not before. The control that actually binds is the one you write into your own architecture.
Minimisation is an optionality purchase
Data minimisation has been sold to executives as a compliance cost, a tax paid to privacy teams. Priced honestly, it is the opposite: an optionality purchase. Data you never collected cannot be subpoenaed, breached, or repurposed by a successor who does not share your scruples.
The savings are not in storage, which is nearly free. They are in the range of futures where the data becomes a liability. Every durable record about a named person is, in the language of stored AI judgements, a future exhibit. The cheapest exhibit to defend is the one that was never created.
The AI-era tension: retain sequences, minimise identities
Here a careful reader will notice an apparent contradiction. The business-case argument says append rather than overwrite, because models need sequences that cannot be reconstructed later. This article says collect less and delete sooner. Both are right, about different classes of data.
Business-process history — status transitions, price revisions, queue times, decision outcomes — should be retained aggressively. Its value compounds and its legal exposure is low.
Durable personal identifiers — biometrics, free-text about individuals, behavioural profiles — should be minimised just as aggressively. Their legal exposure compounds and their modelling value usually does not.
The failure mode is letting a single bucket default answer both questions. Retention should be a per-class decision, written down, with an owner, the same way any policy that will one day be read aloud in a hearing deserves.
What to do before the agent estate arrives
For a UAE firm building toward agents, the sequencing matters. Agents multiply both the production and the consumption of data: they log decisions (good), read histories (good), and can quietly accumulate personal data in intermediate stores nobody inventoried (the CODIS pattern, at startup speed).
Classify before you scale. One afternoon spent labelling your stores as sequence-valuable, identity-sensitive, both, or neither will shape every retention default your agents inherit. Firms that skip this step make the decision anyway, silently, in whatever direction the default bucket points.
Retention design is a half-day conversation when it happens before the build, and litigation support when it happens after. The five-step consulting method includes the data-class map as standing work: what to keep, what to delete, and who owns each answer, before your first agent inherits the defaults.
Frequently asked questions
Why is data minimisation more than a compliance cost?+
Because data you never collected cannot be subpoenaed, breached, or repurposed by a successor with different priorities. The savings are not in storage. They are in the range of futures where the dataset becomes a liability: litigation discovery, an acquirer's due diligence, a regulator's production order, or an internal use nobody would have approved at collection time.
How should AI-era retention policy differ by data class?+
Retain business-process history aggressively, because models that predict stalling deals or churn need sequences that cannot be reconstructed later. Minimise durable personal identifiers just as aggressively, because they compound legal exposure with volume. The failure mode is letting one bucket default answer both questions.
What is the quickest test of your data exposure?+
Pick your largest customer dataset and ask what your legal obligation would be if a court ordered its production tomorrow. Most firms discover the answer depends entirely on retention policy, and that their retention policy was written by whoever configured the storage bucket.