Data protection law applies to any work that uses personal data. AI work uses personal data all the time, often in ways that are easy to miss. Someone pastes a customer email into a public AI tool to help draft a reply. A workflow moves staff records between systems. A new tool starts scoring or sorting people. Each of these is using personal data, and the law has something to say about it.

Working safely in your role means two things together. You need to know what the law actually requires. You also need to spot it being triggered in the work in front of you. Knowing the rules without recognising them in real situations is not enough. Sensing that something looks wrong without knowing why is also not enough. Both go together.

In this section you will learn:

• what the UK data protection framework requires of AI and automation work, and what its key rules look like in practice
• how to spot when a data protection rule is being triggered in live AI work
• how to act correctly within your role once you have spotted a rule being triggered
• how to find out where data protection responsibility sits in your own organisation, before you need to act on it
• the patterns of mistake that catch people out in AI work, so you can catch them yourself

The UK data protection framework

The main rules for handling personal data in the UK are set out in two places. The first is the UK GDPR. GDPR stands for General Data Protection Regulation, and the UK GDPR is the version of those rules that applies in the UK. The second is the Data Protection Act 2018. These two work together. The UK GDPR sets the main framework, and the Data Protection Act 2018 fills in the UK-specific detail.

These rules have been updated by the Data (Use and Access) Act 2025, which came into law in June 2025. This Act did not replace the framework. It made changes to parts of it, including the rules on automated decisions. The framework itself is still the UK GDPR plus the Data Protection Act 2018.

The body that regulates this area is the Information Commissioner’s Office, usually called the ICO. The ICO publishes guidance, investigates problems, and can take action against organisations that get things wrong. Its guidance on AI and data protection is the most useful day-to-day source for how the rules apply to AI work.

What “personal data” actually covers

Personal data means information about a living person who can be identified. This is broader than most people think.

The clear cases include things like:

• names
• home and email addresses
• dates of birth
• photos and voice recordings
• ID numbers
• staff records
• customer records

But personal data also includes information that does not name a person directly, if that information could identify them when put together with other things. A postcode plus a job title plus an employer can identify someone. A device ID, which is the unique number a phone, computer or browser carries, can identify someone. A location trail across a day can identify someone. If a person can be picked out from the information, it is personal data.

Special category data

Some personal data carries stronger protection. This is called special category data. It is given stronger protection because it can cause more harm if it is misused.

Special category data includes:

• health information
• racial or ethnic origin
• religious or philosophical beliefs
• political opinions
• sexual orientation
• biometric data used to identify someone
• genetic data
• trade union membership

When AI or automation work touches any of these, the rules are tighter. You need to recognise this category exists and that it changes what is allowed.

The principles and what they mean in practice

The UK GDPR is built around a set of principles. You do not need to memorise them as a list. You need to know what each one requires when you are working with AI tools.

Lawfulness, fairness and transparency

Personal data can only be used if there is a valid reason in law to use it, the use is fair to the people whose data it is, and those people generally know what is happening to their data.

In AI work, this means three things. Using personal data to train or run an AI tool needs a reason that is recognised in law. These are called lawful bases. The processing has to be fair to the people whose data it is. And there usually needs to be some kind of notice telling those people their data is being used this way.

Purpose limitation

Personal data collected for one purpose should not be used for a different purpose, unless the new use is compatible with the original one or has its own justification.

In AI work, this means you cannot take data that was collected for one reason and feed it into an AI tool for a different reason without checking. Customer data collected to run someone’s account should not be fed into an AI tool to analyse customer feelings unless that new use either fits the original purpose or has been justified separately.

Data minimisation

Only the personal data actually needed for the purpose should be processed. No more.

In AI work, this means thinking about what the tool actually needs. If an AI tool only needs first names and order numbers to do its job, sending it full customer records is more than is needed and breaks this principle.

Accuracy

Personal data should be accurate and kept up to date.

In AI work, this matters in two ways. AI tools that learned from out-of-date data can produce results that are wrong about real people. Automation systems acting on stale information can take action against the wrong person, or about the wrong fact. Both are accuracy problems.

Storage limitation

Personal data should not be kept for longer than it is needed.

In AI work, this means watching where data goes and how long it stays. Data sent to an AI tool may be retained by that tool’s provider for future training or other uses. Automation systems can hold personal data indefinitely if no one has set them up to delete it. Both can break this principle.

Integrity and confidentiality (security)

Personal data must be kept secure and protected from people who should not see it.

In AI work, this is one of the most common places things go wrong. Pasting personal data into a public AI tool that has not been approved by your organisation puts that data outside the organisation’s control. An automation workflow that exposes personal data to the wrong people, or moves it to a system that is not secure, breaks this principle too.

Accountability

Your organisation has to be able to show it is meeting the other principles. Saying “we do the right thing” is not enough. There has to be evidence. That evidence includes things like written policies, records, impact assessments and reviews.

In AI work, this is why you may be asked to record what tool was used, what data was used, what the tool was used for, and what was decided. The record is part of how the organisation shows it is meeting the rules.

Lawful bases

Lawfulness needs more detail. To use personal data lawfully, your organisation has to rely on one of the recognised reasons. These are called lawful bases.

There are six of them:

• consent
• contract
• legal duty
• vital interests
• public task
• legitimate interests

You do not need to know how to choose between these. That is not your job. What you do need to know is that one of them must apply for any use of personal data, and that “we have always used the data this way” is not on the list. If you see personal data being used in a way that does not seem to match any clear reason, that is a signal something needs checking.

Individual rights

People have rights over their own personal data. Your job is to know these exist, not to handle requests yourself.

These rights include:

• the right to ask what an organisation holds about them
• the right to have wrong information corrected
• the right to have their data deleted in some situations
• the right to limit what is done with their data
• the right to take their data to another provider
• the right to object to certain uses
• specific rights about decisions made by automated systems

When someone exercises one of these rights, your organisation has duties to respond. If you receive a message that looks like one of these requests, even if the person does not use the formal language, you need to pass it on to the right person quickly. There are time limits attached.

Automated decisions and special rules

Some AI work falls under a specific rule about automated decisions. This rule matters because it is one of the few places where AI gets named directly in the law.

What the rule covers

The rule applies when two things are true together. First, the decision is made by an automated system, with no real human involved. Second, that decision has a legal effect on the person, or a similarly significant effect.

“Legal effect” means the decision changes their legal position. For example, a decision that affects whether a contract starts or ends.

“Similarly significant effect” means the decision changes something important to that person’s life.

The clearest examples are:

• whether someone gets a job or is filtered out of a hiring process
• whether someone gets a loan and at what rate
• whether someone gets insurance and at what price
• whether someone qualifies for a benefit
• whether someone gets access to a service that matters to them

Not every automated decision counts. The effect has to be significant to the person.

What the rule requires

Where a decision falls under this rule, specific protections apply.

The person affected:

• has a right to be told the decision was made by an automated system
• has a right to ask for a human to look at the decision
• has a right to put forward their own view
• has a right to challenge the outcome

For special category data, which is the stronger-protection list above, the rules are stricter again. A solely automated decision on special category data is generally not allowed unless very specific conditions apply.

The 2025 changes have made these rules more permissive for ordinary personal data, but the protections for the person being decided about are still in place. You do not need to know the legal detail. You need to know that this rule exists, that it applies in AI work, and that the line between “AI helps a human decide” and “AI is the decision” is the line that triggers it.

Where this shows up in AI work

This rule comes up in a wider range of places than people often expect:

• AI-assisted hiring tools that filter or rank candidates
• automated credit decisions
• AI-driven insurance pricing
• automated benefit calculations
• AI triage tools in healthcare
• AI-assisted decisions about access to services

In each of these, the question is how much actual human judgement is in the final decision. A human who clicks “approve” on every result the AI produces is not really making the decision. The AI is. That is where the rule applies.

Data Protection Impact Assessments

A Data Protection Impact Assessment, usually called a DPIA, is a structured check the organisation does before starting a piece of work that is likely to be high risk for people’s rights.

DPIAs are required by law in some situations and strongly recommended in others. New AI and automation projects often fall into one or both. This is especially true when they involve new technology, large amounts of personal data, automated decisions, or special category data.

You do not run the DPIA yourself. Your role is to spot when a project probably needs one, and to raise it. A new AI tool being introduced to score customers, screen applications, triage requests, or handle personal data in large amounts is the kind of thing that should trigger a DPIA before it starts running. If a project is being set up without one, that is a signal worth raising.

Breach notification

When personal data has been exposed, lost, or accessed by someone who should not have it, this is called a personal data breach. Where the breach poses a risk to people, the organisation usually has 72 hours to report it to the ICO from the point of becoming aware of it.

You do not file the report. Your role is to recognise that something has gone wrong, raise it fast to the right person inside the organisation, and not delay because you are not sure how serious it is. The 72 hours start counting early, and slow reporting is itself a problem.

Spotting the rules in live AI work

Given a real AI or automation situation, you can spot that a data protection rule applies, and you can spot which one.

Here are the categories of situation where the rules are likely to apply, with what to look for in each.

Personal data being sent to an AI tool

Watch for any moment where information about real people is being typed, pasted, uploaded, or fed into an AI tool. Customer emails, staff details, support tickets, candidate information, meeting transcripts naming real people. Each of these is personal data going somewhere new.

What you are looking at is the tool now holding personal data that started inside your organisation. Has that move been approved? Is the tool one your organisation has cleared for this kind of use? If not, this is the start of a security and lawful-basis problem.

An AI tool producing personal data

Watch for tools that produce predictions or scores about people. A tool that predicts whether a customer is likely to leave, a tool that scores how risky an application looks, a tool that predicts a health outcome. Each of these is generating new personal data about real people.

What you are looking at is this. Even if the input to the tool was not obviously personal, the output might be. New personal data has the same rules attached as data the organisation collected directly.

Automated decisions with significant effects

Watch for AI tools being used to filter, rank, or decide. The question is how much real human judgement is in the final decision.

What you are looking for is this. If a human is in the process but is mostly clicking through whatever the AI suggests, the decision is substantially automated, and the rule about automated decisions applies. A human review that is real takes time and sometimes changes the outcome. A human review that always agrees with the tool is not really a review.

Special category data in the workflow

Watch for any AI or automation work that touches the special category list.

That includes:

• health information
• ethnicity
• religion
• sexual orientation
• biometric identification
• genetic data
• political opinions
• trade union membership

What you are looking at is this. The moment one of these appears anywhere in the data the tool is using, the rules are tighter. An automation tool moving HR records routinely touches health information. A customer support AI that handles complaints about a medical product is processing health information. The category does not have to be the main point of the work for it to count.

Data heading outside the UK

Watch for any AI tool that runs in the cloud and any automation that sends data to a tool or provider based abroad.

What you are looking at is this. Most cloud AI tools send some data outside the UK. If your organisation has not set up the right protections for this, the international transfer rules are being broken even though no one feels like anything has gone wrong.

A new project that needs a DPIA

Watch for proposals to use AI to score people, screen applications, triage requests, automate decisions, or handle personal data in large amounts. What you are looking at is this. A new project of this kind being set up without a Data Protection Impact Assessment having happened first is a problem. This is true even if everyone involved has good intentions and the tool seems useful.

See it in action

A team lead asks a colleague newer to the team to help summarise common themes in customer complaint emails. The team lead suggests pasting a batch of emails into a public AI tool to produce the summary quickly.

You are watching this happen.

You spot the rule being triggered straight away. The emails contain customer names, contact details, and specific complaint information. That is personal data. The public AI tool is outside the organisation’s approved set of tools. Sending the data there means it leaves the organisation’s control.

You also spot more than one rule applying at once. Security is one. The data is going somewhere not approved. Lawful basis is another. There is no clear reason in law that allows customer complaint data to be used this way. There may also be an international transfer issue, because the public AI tool is hosted outside the UK.

The reasoning is important. You have not picked up a single problem. You have picked up several, and you have noticed that this is a real situation with several rules attached, not a single tidy one. You also recognise that this is not the new colleague’s fault. They were asked to do this by a more senior person. The recognition matters because it has to happen before anyone presses send.

The outcome at this stage is recognition. Acting on what you have spotted comes next.

Acting correctly within your role

Once you have spotted that a rule applies, what to do depends on what is happening and what your role allows.

What is within your role to do

There are four things that sit clearly within what you can do.

The first is to stop or pause the action. If something is about to happen that would break the rules, for example customer data is about to be pasted into a public AI tool, the first job is making sure it does not happen. Pausing the work is something you can do.

The second is to record what you have spotted and what you have done about it. This is not formal reporting. It is a clear note of what the situation was, why it was a concern, and what action followed. It helps your organisation learn from the situation, and it gives you a record if anyone asks later.

The third is to raise the situation to the right person. Who that is depends on your organisation. It might be a Data Protection Officer. It might be a named person in a legal or compliance team. It might be a senior leader who is responsible for data matters. Part of acting correctly is knowing who that person is in your own organisation, before you need them.

The fourth is to adjust the work going forward. If the situation has shown that a way of working is causing problems, the working approach needs changing so the same situation does not keep happening. For example, if the public AI tool is being used because no approved tool exists for this work, that gap needs raising too. Otherwise people will keep falling into the same problem.

What is not within your role to do

There are also things that are clearly not your decision.

You do not make the final decision on legal questions. The kinds of questions that are not yours to answer include:

• whether something is actually lawful
• which lawful basis applies
• whether a transfer is properly protected
• whether a use of personal data should continue after a concern has been raised

You do not run the formal Data Protection Impact Assessment. You spot when a project probably needs one. The assessment itself is specialist work.

You do not file the breach report to the ICO. You raise the breach inside your organisation to the right person quickly. The notification to the ICO is the job of whoever in your organisation is named to do it.

Knowing what is not your decision is part of the job, not a sign of stepping back. Acting in your role means acting fully on the parts that are yours and passing the rest on cleanly.

See it in action

A colleague has been pasting customer emails into a public AI tool to draft replies. You have spotted it. You have raised it to the head of operations, who is the named person in your organisation for data matters.

You are watching what happens next.

The first action is that the work is paused. The colleague is asked to stop using the tool that way until the situation has been looked at. This is straightforward and happens on the day.

The second action is that what happened is recorded. Not formally reported yet. Recorded. The note covers what was being pasted, when it started, roughly how often, and what was done as soon as it was noticed.

The third action is that the head of operations decides what comes next. This is not your decision. The head of operations may decide a formal breach has happened and needs reporting to the ICO. They may decide it does not meet the threshold but the working pattern needs changing. They may bring in legal advice. The point is that the decision is being made by the person who has the role to make it.

The fourth action is that the working pattern is changed. The team is told what is approved and what is not. If there is a real need for an AI tool to help draft replies, the question of which approved tool can be used is raised separately.

The reasoning is important. You did not try to make the legal decision yourself. You also did not stand quietly by once you spotted the problem. You acted on the parts that were yours, which were pausing, recording, raising and helping shape the change. You let the parts that were not yours sit with the right person.

The outcome is that the immediate problem is stopped, the right person is making the right decisions, and the working pattern is being adjusted so the same thing does not keep happening.

Knowing where your organisation’s route is

There is one part of this work that is often skipped. You need to know, before a problem arrives, where data protection responsibility sits in your own organisation.

In the moment a rule surfaces, you do not have time to work out who to raise it to from scratch. The work sits with knowing this in advance.

What to find out

Find out whether your organisation has a Data Protection Officer, or DPO. Some organisations are required by law to have one. This includes most public bodies, and any organisation doing large-scale special category data work. Many other organisations choose to have one. Some have none.

If there is a DPO, find out who they are and how to reach them.

If there is no DPO, find out who holds responsibility for data protection.

This might be:

• a named person in a legal team
• a named person in IT
• a named person in compliance
• a senior leader who has been given responsibility for it

In some organisations this is unclear, and that is information worth knowing too.

If no person clearly has responsibility, find out who concerns should go to in practice. A line manager may be able to raise things upwards. In a smaller organisation, concerns may need to go directly to senior leadership.

Find out what your organisation’s policy says about AI tool use. Which tools are approved. Which kinds of use are approved. Whether there are specific things that are not allowed.

What “beyond what I can decide” actually looks like

Your role is not to hold legal questions on your own. The kinds of decisions that are not yours to make include:

• weighing which lawful basis applies
• deciding whether a new use of personal data is allowed
• judging whether an international transfer is properly protected
• agreeing what the organisation will say to the ICO

Recognising that, and passing the question on clearly without hesitating, is part of the job.

This is not a step back. The people closest to the work are usually the ones who spot the problem first. That spotting is your job. The legal decision is someone else’s.

See it in action

You have just joined a team. You do not yet know whether the organisation has a DPO. You do not yet know who handles data protection concerns.

You decide to find this out before you need it.

You ask your line manager. They tell you the organisation does have a DPO and that the DPO sits in the legal team. They give you the DPO’s name and contact details. They also tell you that for most concerns, the route is to raise things first with the line manager, and the line manager judges what gets sent straight to the DPO and what stays at team level.

You also ask what the organisation’s position is on AI tool use. You learn three things. There is a list of approved tools. Public AI tools are not approved for use with customer data. And a new tool needs a check from the DPO before it is used in the team’s work.

You note this down somewhere you will be able to find it again.

The reasoning is important. You have not waited for a problem to make this question come up. You have done the work of finding out the route in advance, while you have time to ask without pressure.

The outcome is that if a situation comes up tomorrow, you already know who to raise it to and what your organisation’s position is. The preparation is done before it is needed.

Common Mistakes in Data Protection and AI

Summary

Data protection law is not a compliance task that sits with someone else. In AI work, the person closest to the work is often the only one who can see a rule being triggered as it happens. That is what working safely means in this role.

You now know what the UK data protection framework is. It is the UK GDPR and the Data Protection Act 2018, brought up to date by the Data (Use and Access) Act 2025, and regulated by the ICO. You know the principles that the rules are built on, and what each principle requires when AI tools are involved. You know the specific rule about automated decisions, what triggers it, and what protections it provides. You know what a DPIA is, when one is needed, and what your role is in raising it. You know that international transfers and breach notification have their own rules.

You can spot the rules being triggered in live AI work. You can act correctly within what your role allows. That includes pausing, recording, raising and adjusting. You can pass on what is not your decision, cleanly and without delay. You know the route in your own organisation before you need it. And you can spot the patterns that catch people out, because you have seen them named.

That is what working safely with personal data in AI work looks like.