If you are building a product that uses artificial intelligence and personal data, the cheapest time to fix a privacy problem is before you have built it. After launch, a change to how your product collects or uses data can mean rewriting code, retraining a model, renegotiating contracts and writing to customers. Before launch, it is a conversation.
UK GDPR calls this "data protection by design and by default" (Article 25). The ICO describes it as embedding data protection practices "into every aspect of your use of personal information", and says it is "better to think about data protection issues from the start rather than at the end." This checklist turns that into ten questions a founder can answer in an afternoon.
What the law asks of you
Article 25 has two halves. By design means that when you choose how your product works, you consider the nature, scope, context and purposes of the processing and the risks to people, and apply suitable technical and organisational measures to reduce them. By default means that, unless a user chooses otherwise, you only use the personal data needed for each specific purpose, which covers how much you collect, how much you process, how long you keep it and who can access it.
The ICO's guidance says this does not necessarily mean switching every setting to "off"; the right approach depends on the processing and its risks. It also lists practical measures: map your processing, minimise data, secure systems, use only processors that give adequate guarantees, restrict access by role, provide clear privacy information and meaningful choices, and document significant decisions. A DPIA is expected where processing is likely to be high risk, and the ICO recommends one as good practice even where risk seems lower.
A ten-question checklist
- What personal data does the product use, and why? Write one sentence per data type: what it is, why you need it and what you do with it. If you cannot justify a field, remove it.
- Does it use special category data or data about children? Health, biometrics, religion, sexual orientation and similar data carry higher expectations. A product likely to be used by children needs to consider their needs at each age.
- What is your lawful basis for each purpose? Training a model on customer data is a different purpose from delivering the service to the customer. Each needs its own basis and its own explanation. Terms of service alone do not cover every use.
- Are you the controller, a processor, or both? If you process customer data on their instructions, you are probably a processor. If you also use that data for your own purposes, such as improving your model, you may be a controller for that use. Get this right in your contracts.
- Have you done a DPIA before your first customer? New technology plus personal data is exactly the case Article 35 has in mind. A short DPIA that shapes the design is far cheaper than one forced on you later by a customer's procurement team.
- Can you minimise or de-identify the data? Ask whether the model needs real personal data at all, and whether synthetic, pseudonymised or aggregated data would do. Remember that pseudonymised data is still personal data.
- How long do you keep it, and can you delete it? Decide retention periods for raw data, training sets, logs and outputs. Check you can honour a deletion request, including for data that has already shaped a model, or at least explain honestly what you can and cannot do.
- Who are your suppliers? Cloud hosting, model providers, analytics, support tools: each is a processor or sub-processor. Check each one's terms, security and where it processes data, and put contracts in place.
- Where does a human sit in the decisions? If your product produces decisions or scores about individuals, think about whether a person genuinely reviews them. Rubber-stamping does not count as meaningful human involvement.
- What happens when something goes wrong? Write a one-page incident plan: who decides, who tells customers, who reports to the ICO within 72 hours when required, and how you will preserve evidence.
A worked example
A two-person startup is building an AI tool that summarises recruiters' interview notes. The founders assume the data belongs to their customers and they are "just the software". A one-hour run through the checklist turns up four issues. They plan to use customers' notes to improve their model, which makes them a controller for that purpose and means they need a lawful basis and a clear explanation. The notes may reveal health or ethnicity, which are special category data. Their cloud and model suppliers are not yet covered by contracts. And there is no way to delete one candidate's data on request.
They fix the contracts, make model improvement opt-in, add a deletion route and write a short DPIA. The first enterprise customer's security questionnaire arrives a month later, and the answers already exist. (An invented example, for illustration.)
Four mistakes we see
- "We anonymise it" without a test. Removing names rarely makes data anonymous.
- Treating the supplier's terms as your compliance. You remain responsible for how your product treats data.
- Leaving privacy to the end. It is hardest to change after launch.
- Collecting "just in case". Every extra field is more data to secure, explain and delete.
Frequently asked questions
Do small startups need a DPIA? Size does not matter. If your product is likely to result in a high risk to individuals, for example by using sensitive data at scale or new technology in a way that affects people, you need one before you start.
Can we train our model on customer data? Only if you have a lawful basis for that purpose and have told people clearly. Check your contracts as well: customers often restrict it.
Do we need a data protection officer? Not always. It depends on your activities, such as large-scale monitoring or special category data. Take advice.
Is the ICO writing AI rules? The ICO has said it is developing guidance and a statutory code on AI and automated decision-making, and has opened a call for evidence on agentic AI. Keep an eye on its announcements.
How Pathway 2 Privacy can help: Data Protection by Design support works with your team while you build, so privacy decisions are made at the cheapest moment. A DPIA documents your design choices ahead of your first customer, and a Policy Review checks that your privacy notice and customer contracts match what the product does. See our GDPR support for SaaS and technology and our guide to DPIAs as a design tool. Or start with a free data protection review.
Sources: ICO guidance on data protection by design and by default; UK GDPR Article 35; PPC Land on the ICO call for evidence on agentic AI.
