GDPR

What GDPR is

GDPR is the EU’s data protection regulation. It covers how personal data may be collected, used and stored. On this site the point is narrower and more practical: it is relevant wherever an AI system touches personal data, and it is checked alongside the EU AI Act at the same step of an audit, not as a separate exercise.

This page is not legal advice. The site says the same about its own work: an audit is a diagnostic and not a legal opinion, and no audit substitutes for advice from a qualified lawyer. What follows explains how the site treats the regulation and where it comes up. It does not set out the text of the law.

The trigger is Personal Data

The question to ask of any AI use is whether it touches personal data. A process that drafts a generic announcement from public material may never go near it. A process that summarises a client email, scores a candidate or reads an HR record does. The regulation attaches to that, and the tool’s name, price or brand does not change it.

The site puts the same idea from the other side. GDPR duties attach to what a tool does with personal data, whoever bought it. That matters because AI tools often arrive without anyone deciding to buy them, and a duty that attaches to the data does not wait for a purchase order.

GDPR and the EU AI Act side by side

The two are easy to confuse and easy to treat as one topic. They are two sets of rules that meet in the same use case. The Act classifies a system by what it does and puts obligations on it by risk. GDPR looks at the personal data the system handles. Any use case touching personal data carries obligations under both at once, and the site checks them at the same point in the process, not as a separate review added afterwards.

The clearest case is recruitment. The Act classifies systems that filter CVs or score candidates as high-risk. The same HR data that triggers that classification is also personal data under GDPR. The HR article makes the point that a curriculum treating the two as separate topics describes half the picture.

Where it is checked in an Audit

Every audit checks GDPR at the Identify step, inside the ranking of opportunities and not as a review at the end. Each candidate process is weighed on how often it repeats, what the manual version costs, whether the data it needs exists in a usable state and what regulatory exposure attaches to it. GDPR is part of that last question.

Where a tool would touch personal data, the audit checks it under data protection rules before the tool is recommended, not after it is in use. The site’s reasoning is that a data protection problem found after roll-out costs far more to unwind than one flagged at the scoping stage. The result includes a compliance checklist covering the EU AI Act and GDPR obligations the recommended opportunities carry. The audit methodology sets out the five steps, and opportunity identification covers the step itself.

The questions it adds to a check

The audit article describes a proportionate check, sized to what each process touches and not to a template built for a much larger business. Inside it, GDPR asks the more familiar questions. What is the lawful basis for processing the data involved? What do the third-party tool’s own terms say about where that data goes and who can see it? Can a person still get an explanation and a correction when an AI-assisted decision affects them?

The site does not go further than those three, and this page does not either. They are questions to answer for each process, before the tool is used. A process that never touches personal data or a regulated decision carries a short risk section. One that does gets a longer one.

A worked example

This is an illustration, not a real client. A small firm wants an assistant to summarise incoming customer emails. The emails contain names, contact details and sometimes account problems, so they are personal data. Before anyone signs up, the firm answers the three questions. It works out the lawful basis for handling those emails. It reads the tool’s terms to see where the text goes and who can see it. And it checks that a customer could still get an explanation and a correction if a summary led to a wrong decision.

If the terms are unsuitable, the firm does not use that tool for that data. The site’s own rule says so: where GDPR applies to the personal data involved and no approved tool with suitable terms exists yet, the honest answer is not to use AI on that data until one does. The firm might still use the tool for work that involves no personal data.

Where the Tool runs does not settle it

There are two common shortcuts, and both are wrong. One is that a hosted service is automatically the risky option. The other is that running a model on your own hardware makes a business compliant. The site’s answer to both is the same. GDPR and the Act attach to what the system does and what data it processes, not to where the software runs.

A poorly governed local deployment can breach either as easily as a poorly governed hosted one. What changes is who is directly accountable for the data path and how much of it the organisation can see and control. The Claude page sets this out for hosted and self-hosted models, and the same reasoning applies to any tool.

What staff may enter into a Tool

Most exposure begins with a person and a tool, not with a system. The site’s article on why banning AI tools backfires argues for a one-page rule drawn by kind of data and not by tool. The first part lists what may never be entered into any AI tool: client names and contact details, contracts, HR records, credentials and anything under a confidentiality agreement. The second lists what is fine in the approved tool. The third says anything else goes to one named person first.

The article adds that client and HR data is exactly what a business’s data protection duties already cover, so the page adds no new principle. It makes an existing one usable on a busy afternoon. It also notes that personal data entered into a tool the business has not assessed can breach its GDPR duties, and that confidentiality clauses in client contracts apply whichever tool is used. Legal advice on your own contracts and sector is still needed.

Anonymisation and Local Hosting

Two of the practical choices the site teaches follow from the regulation. One is anonymisation, which means removing what identifies a person before text goes into a tool. The other is where a model runs, in the cloud or locally. Neither is a cure-all, and each needs a decision made before use.

The HR course closes on both. Its data protection session covers cloud versus local hosting, running a model with the wifi switched off, anonymisation done live, and where the regulation puts responsibility for a screening decision. The admin and document workflows course treats secure document translation as classification, automated anonymisation and private translation. The data protection page covers these as practical choices and not as law.

Data Protection is one part of Governance

GDPR is one part of AI governance, and it is not the whole. The governance article says so directly. Governance also covers accountability for a wrong AI-assisted decision, verification of a result before it is used, and classification under the EU AI Act. A policy that deals only with data handling and says nothing about who checks an output leaves most of the risk open.

It also needs an owner. The duties under GDPR attach to what a tool does with personal data, and someone has to be assigned to answer for that. A business that has not decided who that is will find the question arriving without an answer. The ownership article’s table gives the question of whether the data a tool touches is allowed to whoever holds data protection.

In Training

The courses do not treat GDPR as a module at the end. EU AI Act and GDPR content is built into every foundational programme, and both the core and bespoke formats carry it inside the session. The core courses carry their own governance and safe-use content as part of the day.

The HR article makes the same case for its own field. Data protection belongs in the same session as the bias and screening material, with anonymisation and local hosting covered directly and not assumed. The bespoke training page sets out how the formats differ, and the HR course is the fullest example.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating GDPR and the EU AI Act as one regulation, when one looks at the personal data a system handles and the other classifies the system by risk. The second is assuming a hosting choice settles compliance, in either direction.

The third is treating a vendor’s assurance as the end of the matter. The site’s position is that “the vendor handles compliance” is not a defensible answer, because a business that deploys a tool keeps duties of its own. The fourth is treating an audit as a certificate. It identifies and checks obligations. It does not certify them.

Where it goes wrong

One failure to avoid is checking too late, when a tool is already in daily use and someone asks afterwards what happened to the data. The site’s answer is to check before the tool is recommended, at the scoping stage, because the problem costs far more to unwind after roll-out.

Another is writing a rule and stopping there. A rule with nobody responsible for enforcing it is a document, not a control. A third is the blanket ban, which the site argues against. Some restrictions should be firm, but a good one is narrow: it names the tool or the data, gives the reason in a sentence, points to the approved alternative and says who to ask.

Where it is taught and where it appears in an Audit

GDPR runs through the foundational programmes and through the HR course, which closes on data protection. The rest sit in the wider training catalogue.

In an audit it appears at the Identify step, beside the EU AI Act, and its output is a line in the compliance checklist. The article on what an AI audit actually checks explains how deep that check goes for a small or mid-sized business. The AI audit page states the limits: obligations are identified and checked against, and they are not certified.