How ICO guidance on UK GDPR changes AI marketing tool data flows

What to take away

What the ICO's AI and data protection guidance actually covers

The Guidance on AI and data protection is not a separate rulebook. It explains how existing data protection law applies when you build or buy systems that infer things about people, which is what most AI marketing tools now do.

That matters for UK marketing operations because the guidance assumes you can explain your system. It asks for a documented purpose, an identified lawful basis, an assessment of risk and a way to answer a customer who asks why they were targeted.

The ICO's Artificial intelligence resource page collects the guidance, the risk tools and the casework in one place, and it is the sensible starting point before you sign a martech contract.

The guidance distinguishes two broad situations. In one, the tool supports a human decision, such as ranking audiences for a planner to review. In the other, the tool decides, such as excluding a household from a campaign automatically.

The second situation attracts more scrutiny. If your platform quietly suppresses or deprioritises groups, you are making decisions about people, and the ICO expects you to treat that as a data protection question, not a media buying one.

The guidance also covers training data, inference accuracy, explainability and the risk of bias. For a UK retailer or agency, the practical output is a record of what the model does, what it was trained on and who checked it.

None of this replaces the Advertising Standards Authority's rules on targeting or the CMA's work on online choice architecture. Data protection sits alongside those regimes, and a campaign can breach more than one.

UK GDPR article 5 principles inside an AI marketing tool

UK GDPR article 5 principles are where most AI marketing tool problems start. Purpose limitation, data minimisation, accuracy, storage limitation and accountability all apply to the audience file you upload, not just to the database it came from.

Purpose limitation means deciding why the data is in the tool before it arrives. "Improve marketing" is too wide to defend. "Score lapsed customers in the South East for a win-back email series" is a purpose you can test against.

Data minimisation means the model rarely needs everything the CRM holds. If a propensity score only uses recency, frequency and basket value, sending names, addresses and full order histories adds risk without adding accuracy.

Accuracy is the principle people forget. A model that infers a household is expecting a child, or that a customer has churned, is creating personal data. If the inference is wrong, the accuracy principle still applies to it.

Storage limitation interacts badly with retraining. Many platforms keep historical audience snapshots to improve future models. That is a retention decision, and it needs a retention period and a deletion route.

Accountability sits above the rest. You must be able to show how each principle was handled, which is why the mapping work in section five is not optional paperwork.

One practical habit helps here: write the purpose on the campaign brief, then check the tool's configuration matches it. Where data is being reused for a new purpose, revisit your data protection rules before the audience is rebuilt.

Choosing a lawful basis under article 6 for audience data

UK GDPR article 6 lawful basis is a per purpose decision. A single marketing database can rest on different bases for different activities, and the ICO's Lawful basis guidance sets out how to choose and document one.

Consent is the safest basis for email and SMS to individuals, and the hardest to maintain. It must be specific, freely given and easy to withdraw, and withdrawal has to reach the model, not just the CRM.

Legitimate interests suits many profiling and postal activities, but it requires a three part test: identify the interest, show the processing is necessary, then balance it against the individual's rights and expectations.

Contract is narrow. It can cover processing needed to deliver something the customer asked for, such as a service update, but it does not stretch to persuading them to buy something else.

Special category data, including health, ethnicity and some political inferences, needs an article 9 condition on top. Models can generate these inferences accidentally from postcode, name or browsing patterns, so check outputs rather than assuming you never collected them.

Keep the basis next to the purpose in your record of processing. When a vendor asks to reuse audience data for product improvement, that is a new purpose with a new basis question, and it belongs in the UK regulations to verify before you agree.

Article 22 and automated decision-making in campaign targeting

UK GDPR article 22 automated decisions give people rights when a decision is based solely on automated processing and produces legal or similarly significant effects. Most ad targeting sits below that threshold, but some marketing decisions do not.

Price personalisation is the obvious example. If a tool sets an individual's price or discount without human input, that can be a significant effect, and article 22 safeguards apply.

Exclusion is the subtler case. A model that permanently removes a group from all offers, or that drives a credit or insurance decision through a partner, moves closer to article 22 territory.

Where article 22 applies, you need a lawful basis, a way to obtain human intervention, an explanation of the logic and a route to contest the decision. Retargeting a browsing session usually needs none of that.

The ICO's wider AI material is useful for judging where the line falls, because it discusses human review, meaningful involvement and the difference between assisting and deciding.

Meaningful human involvement is not a rubber stamp. A reviewer who approves thousands of exclusions a day without context is not exercising judgement, and the ICO has said as much in its casework.

Automated decision-making advertising also interacts with transparency. People should know that automated processing is happening and understand the consequences, which is a privacy notice job, not a cookie banner job.

A useful test before launch: could you explain to the affected customer, in two sentences, why the system treated them that way? If not, the involvement is probably not meaningful and the decision probably is automated.

Mapping data flows from CRM to model to ad platform

Data flow mapping from CRM to ad platform is the exercise that turns policy into something an auditor can follow. Draw it before you configure the tool, not after a complaint arrives.

Start with the source system and the fields actually exported. Then record what the model adds, where it runs, who can see the output, and which platform receives it.

Most UK teams find two or three flows nobody owned. A hashed email list uploaded to a platform for matching is a transfer of personal data even when the platform cannot reverse the hash.

Keep the map in the same repository as your record of processing, and version it. When a vendor changes its matching model or adds a new audience feature, the map is what tells you whether a fresh assessment is needed.

Controller and processor roles in martech vendor contracts

The ICO's Controllers and processors guidance is the reference point for deciding who is responsible for what. Most martech contracts describe the vendor as a processor, but the label does not settle the question.

A vendor is a controller in its own right if it decides why data is processed. Product improvement, benchmark reporting and training shared models are common examples where vendors set the purpose, which makes them controllers for that activity.

Joint controllership is possible too. If you and a platform jointly determine the purposes and means of a matching exercise, both of you owe transparency and rights handling to the individuals involved.

Read the contract for four things: the subject matter and duration, the nature and purpose of processing, the type of personal data, and the obligations and rights of the controller. A processor clause without those details is thin.

The contract should also cover sub processors, breach notification timelines, assistance with rights requests and deletion on termination. If the vendor uses your data to train a shared model, that needs its own clause, not a line in the marketing brochure.

Run vendor due diligence against the contract rather than the sales deck. Ask for the sub processor list, the security certifications and the actual retention schedule, then check they match what the platform does by default.

International transfers when a tool trains outside the UK

International transfers rules apply as soon as personal data leaves the UK, including when a model is trained or hosted abroad. The ICO's International transfers guidance covers the mechanisms and the assessment you need.

An adequacy regulation is the simplest route. Where the destination country is covered, you can transfer without extra safeguards, though you still need to check the transfer is necessary for your purpose.

Otherwise you need an appropriate safeguard, most often the International Data Transfer Agreement or the UK addendum to the EU standard contractual clauses, plus a transfer risk assessment.

The risk assessment is where UK teams get caught out. It looks at the destination's laws and practices, the sensitivity of the data and whether the safeguard works in practice, not just whether the paperwork is signed.

Model training is the awkward case. If a vendor trains on your audience data in a third country and keeps the resulting weights, deletion of the source records does not necessarily remove the influence of that data.

Documenting accountability so an ICO audit holds up

Accountability is the thread running through all of this. An ICO audit will not ask whether you read the guidance. It will ask for the record that shows what you decided and why.

A data protection impact assessment is expected for large scale profiling, systematic monitoring and any use of new technology where risks are high. Audience modelling at scale usually qualifies, and the assessment should be live rather than filed.

The record should connect four things: the purpose, the lawful basis, the data flow map and the DPIA. When they disagree, the disagreement is the finding.

Keep evidence of the human review you rely on for article 22 arguments, including who reviewed what and how often. A rota without decisions attached proves very little.

Train the people who configure the tools, not just the legal team. Most incidents start when someone uploads a list, enables a lookalike feature or accepts a new default without checking.

Review the whole pack annually and whenever a vendor changes its model, its sub processors or its hosting region. The rules and ethics of AI marketing shift with the platforms, and your documentation has to move with them.

Common questions