A design constraint, not a document
The Digital Personal Data Protection Act, 2023 is usually met at the end of a project, as a policy page and a consent checkbox. That is the expensive way to meet it. Most of what the Act asks for is architectural, and retrofitting architecture is the costliest kind of rework there is.
This is not legal advice — take that from your counsel. It is what we have found the Act changes in the engineering.
Who you are in the transaction
If you decide why and how personal data is processed, you are the Data Fiduciary. A supplier building a system for you is typically a Data Processor, acting on your documented instructions. That distinction determines who answers a data-principal request, who notifies a breach, and what has to be in the contract before any data moves.
Settle it in writing before the first extract is shared, not at the security review.
What it changes in practice
- Minimisation is an architecture decision
- The Act expects you to process what is necessary for the stated purpose. In an AI project that means asking whether the model needs identified data at all — frequently it does not, and pseudonymised or synthetic data will train it just as well.
- Purpose limitation constrains reuse
- Data collected to deliver a service cannot be quietly repurposed to train a general model. If training is a purpose, it has to be a stated one.
- Retention has to be designed
- 'Keep everything forever in case it is useful' is not a retention policy. Deciding the period up front changes storage design and the pipeline.
- Erasure has to be possible
- A data principal can ask for deletion. If personal data has been copied into feature stores, training snapshots and logs with no lineage, honouring that is close to impossible. Lineage is what makes it tractable.
- Consent must be withdrawable as easily as given
- Which means consent state has to be a live input to the system, not a checkbox recorded once at signup.
- Children's data is stricter
- Additional protections apply, including restrictions on behavioural monitoring and targeted advertising directed at children. This shapes what an education product may do at all.
The model-provider question
This is the one most AI projects miss. If your system sends personal data to a third-party model API, that provider is processing personal data on your behalf — with its own terms, retention and jurisdiction. It belongs in your processor register and your DPA, and it needs to be a decision rather than an implementation detail chosen by whoever wrote the integration.
Where the answer is that data must not leave your environment, self-hosted open-weight models are a normal option rather than an exotic one — and for steady high-volume workloads they are often cheaper as well as simpler to govern.
Getting it right early
Decide four things before writing the pipeline: what personal data is genuinely needed, where it may live, how long it is kept, and who — including which third parties — can reach it. Those four answers shape the data model, the deployment target and the provider choice.
Answer them at the diagnostic and they cost days. Answer them at the security review and they can cost a rebuild.
More
Also worth reading.
Other arguments we make often enough to have written down.
Why AI projects fail after the prototype
The demo is roughly 40% of the work. Here is what the other 60% consists of, why it gets cut, and what it costs to add later.
Twelve questions to ask an AI vendor
Questions that separate a supplier who has shipped production systems from one who has shipped demos. Use them on us too.
Next step
Have a version of this problem?
Tell us what is slow, expensive or error-prone. A diagnostic will tell you honestly whether it is worth solving with machine learning — including when it is not.