GDPR and AI Compliance: How GDPR Applies to AI Systems

Executive Summary

Your AI feature is already inside GDPR's scope. The EU AI Act did not replace it, and no AI-specific exemption exists. If a prompt, a training file, a retrieval index or a log line contains information about a person in the EU, GDPR and AI compliance is a live obligation today, not something to plan for after the next release.

GDPR and AI compliance means meeting the same GDPR duties for an AI system as for any other processing of personal data (a lawful basis, transparency, data minimisation, data subject rights, security and, where risk is high, a DPIA) at every stage from training through operation, plus the Article 22 limits on decisions made solely by automated means.

Quick take Five questions decide most of the work. Is personal data involved at any stage? Which Article 6 basis fits each stage? Do you need a DPIA? Does Article 22 apply to any decision the system makes? Can you answer an access or erasure request that touches the AI system?

Note This guide covers GDPR obligations for AI. For the general GDPR program, see the GDPR compliance guide. For the AI Act itself, see the EU AI Act compliance guide. For assessing the risks of one specific system, see the AI risk assessment guide.

By the end, you will have a stage-by-stage map of what GDPR asks of an AI system, a plain-English reading of what the EDPB and the Court of Justice have said, and a 30-day plan a small team can actually run.

Here's what I'll cover:

Where personal data hides in an AI system, and who is in scope
A lifecycle table: collect, train, deploy, operate
Controller or processor: who owns what when a vendor model is involved
How to choose an Article 6 lawful basis for each stage
What EDPB Opinion 28/2024 means if you build or buy a model
Article 22 after the SCHUFA and Dun & Bradstreet rulings
Data subject rights, DPIAs and how GDPR stacks with the AI Act
A worked example, a 30-day plan and a checklist

Does GDPR Apply to AI? Scope, Personal Data and Territory

GDPR is technology-neutral. It applies whenever an AI system processes personal data of people in the EU, whatever the model, vendor or architecture.

Scoping GDPR and AI Compliance: Where Personal Data Hides

The common mistake is to treat the training set as the only place personal data lives. An AI system touches personal data in at least seven places, and a data map has to list all of them.

Where	What it can contain	Why it gets missed
Training and fine-tuning data	Customer records, support tickets, scraped text	It is the one place people think of, so it gets reviewed once and then forgotten
Prompts	Names, emails, case details typed or pasted by users	Treated as "just a question", not as a record
Retrieved documents (RAG)	Whole files pulled into the context window	The index copy lives outside the source system
Outputs and inferences	Summaries, scores, predictions about a person	An inference about a person is personal data too
Logs and chat history	Prompt and response pairs, kept for debugging	Retention is rarely set
Embeddings and vector stores	Numeric representations of personal text	Assumed to be anonymous, which is not a safe assumption
Model weights	Memorised fragments of training data	Whether a model is personal data is a case-by-case question, covered below

Quick answer: if you cannot say where each of these sits and how long it is kept, you cannot answer a regulator or a customer who asks.

Do Non-EU Companies Need GDPR and AI Compliance?

Often, yes. Article 3(2) applies GDPR to a company outside the EU that offers goods or services to people in the EU, or monitors their behavior in the EU. A US startup with EU users or EU enterprise customers is in scope even with no office in Europe.

For the country-by-country picture, see which countries GDPR applies to.

GDPR

Selling to EU customers with an AI feature? Start from a GDPR program that already exists

ComplyJet's GDPR workspace helps you map processing activities, keep records and collect the evidence EU buyers ask for, so an AI feature slots into a program instead of triggering a new one.

See GDPR support

Why GDPR and AI Compliance Is Already a Live Risk

Enforcement against AI companies is public, large and not limited to the biggest names.

OpenAI, Italy. The Italian data protection authority (the Garante) announced a EUR 15 million fine in December 2024, citing the lack of a lawful basis for training, transparency failures and weak age verification. In March 2026 a Rome court annulled the decision, according to PPC Land's report of the judgment. The ground was jurisdiction: Ireland's authority had become OpenAI's lead supervisor in February 2024. The court did not decide whether the practices complied with GDPR.
Clearview AI, Netherlands. The Dutch authority fined Clearview AI EUR 30.5 million on 3 September 2024 for building a facial-recognition database from scraped images, a case that reached a US company with no EU establishment.

The OpenAI result is worth reading carefully. A fine that falls on a procedural point still leaves the substantive questions open, and the lead authority can pick them up.

GDPR's own ceilings explain why this matters. Under Article 83, breaches of the basic principles, the lawful bases, special-category rules and data subject rights (which includes Article 22) sit in the upper tier: up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. Failing to run a DPIA, ignoring privacy by design or weak processor contracts sit in the lower tier: up to EUR 10 million or 2%.

The customer side arrives sooner than a regulator does. EU enterprise security questionnaires now ask which models you use, where prompts go, and whether customer data trains anything. A vague answer stalls a deal.

Watch out The AI Act has its own fines: up to EUR 35 million or 7% of turnover for prohibited practices, and up to EUR 15 million or 3% for most other operator duties. The two regimes stack. Satisfying one does not satisfy the other.

GDPR and AI Compliance Across the AI Lifecycle

Each stage of an AI system is a separate processing activity with its own purpose. Data collected to run support tickets is not automatically available to train a model: reuse for a new purpose needs a compatibility check under Article 6(4), or a fresh basis.

Stage	Processing activity	Likely Article 6 basis	DPIA trigger	Rights that bite	Usual failure
Collect and prepare	Gathering, cleaning and labelling data	Legitimate interest, contract or consent, depending on source	Large-scale or special-category data	Information (Articles 13 and 14), objection	Scraped or repurposed data with no notice
Train or fine-tune	Using personal data to build or adapt a model	Legitimate interest (with a documented test) or consent	New technology plus another risk factor	Objection, erasure	Training on customer data the contract never allowed
Deploy and prompt	Users send personal data to a model	Contract, or legitimate interest	Profiling or sensitive prompts at scale	Access, information	Staff pasting personal data into unapproved tools
Operate and monitor	Logging, evaluation, outputs about people	Legitimate interest or legal obligation	Automated decisions with significant effects	Access, rectification, Article 22	Logs kept forever, no way to find one person's data

Four stages of an AI system, collect, train, deploy and operate, each with the GDPR question it raises: is there notice, is there a basis, who is the controller, and can you answer a request.

A short rule of thumb: for every stage, write down the purpose, the basis and the retention period on one line. If any of the three is blank, that stage is not compliant yet.

Controller or Processor: Who Owns What in GDPR and AI Compliance

By default you are the controller (you decide why and how personal data is processed) and the model vendor is a processor (it processes on your instructions) under an Article 28 data processing agreement. That default breaks in two places, so check which setup you actually have.

Setup	Your role	The vendor's role	What to check
Vendor API, no training on your data	Controller	Processor	Article 28 terms, retention, sub-processors, transfer mechanism
Vendor trains on your data for its own purposes	Controller for your use	Likely a separate or joint controller for the training use	Whether you have a basis to disclose the data and whether notices cover it
Self-hosted or open-weight model	Controller	None for inference	Security, access control, the licence of the weights

A contract review should confirm four things:

No training on your data unless you chose it, in writing.
Retention: how long prompts and outputs are stored, and whether you can set it to zero.
Sub-processors: who else sees the data, and how you are told about changes.
Transfers: the Chapter V mechanism if data leaves the EU.

The AI vendor risk management guide has the full questionnaire.

Pro tip The consumer and business tiers of the same product can carry different data terms. Check the tier your staff actually use, not the one procurement bought. The shadow AI risk guide covers how unapproved use creates this gap.

GDPR AI Lawful Basis: Choosing an Article 6 Basis for Each Stage

Every stage needs one of the six Article 6 bases. Three are realistic for AI work, and each has an honest limit.

Basis	Where it fits	The honest limit
Consent	Optional features, special-category data	Must be freely given and withdrawable, and withdrawing from a trained model is hard to honour
Contract	Delivering the feature the customer bought	Covers what is objectively necessary for the service, not model improvement or experimentation
Legitimate interest	Training, evaluation, security and fraud work	Needs a documented balancing test, and the right to object remains
Legal obligation	Logging or reporting a law requires	Rarely the basis for the AI work itself

Training on scraped data rarely fits contract, because the people never contracted with you. Consent for training is difficult to make withdrawable. That leaves legitimate interest as the working basis for most training, which makes the test below the part to get right.

Legitimate Interest in GDPR and AI Compliance: The Three-Step Test

Legitimate interest is assessed in three steps: identify the interest, show the processing is necessary for it, and balance it against the person's rights and reasonable expectations. A written balancing note might read:

"Interest: improving ticket classification accuracy for our own customers. Necessity: a model trained only on synthetic data performed measurably worse in our own testing, so real tickets are needed. Balancing: customers are told in the privacy notice and can opt out, tickets are pseudonymised before training, and no special-category fields are included."

The note is only as good as its facts. A commenter on a September 2025 Hacker News thread about LinkedIn's plan to train on EU members' data doubts that "we want to feed data to our AI so we can make more money" passes the legitimate interest assessment. Commercial benefit alone does not carry the test. Expectations, safeguards and an easy opt-out do the work.

Special Category Data in Prompts and Training Sets

Article 9 adds a second requirement for health, biometric, genetic and similar data: an Article 9(2) condition on top of the Article 6 basis. The realistic risk is not a health dataset you chose to train on. It is special-category data typed into a free-text prompt by a user who never thought about it. Plan for it with input filters, short retention and a notice that tells users what not to enter.

GDPR AI Training Data: What EDPB Opinion 28/2024 Actually Says

The European Data Protection Board adopted Opinion 28/2024 on 18 December 2024, after the Irish authority asked it under Article 64(2) to answer four questions: when is an AI model anonymous, whether legitimate interest can justify development, whether it can justify deployment, and what follows when a model was developed unlawfully.

When Is an AI Model Anonymous? The Two-Part Test

A model trained on personal data cannot in all cases be considered anonymous. The EDPB wants a case-by-case assessment, which is different from a blanket rule in either direction. For a model to count as anonymous, two things must both be insignificant, taking account of all the means reasonably likely to be used:

The likelihood of extracting personal data from the model directly, including probabilistically.
The likelihood of obtaining personal data from queries put to the model.

If you claim a model is anonymous, keep the evidence: the testing you ran, the extraction attempts, the safeguards in training. A claim with no file behind it will not survive a request from an authority.

Legitimate Interest After the Opinion

The opinion confirms legitimate interest can be a basis for developing and deploying a model. It does not presume it. The three steps apply to development and to deployment separately, because they are different processing activities with different risks. The EDPB lists mitigating measures (for example, pseudonymisation, opt-outs and filtering outputs) and describes the list as non-exhaustive and tailored to the case.

Unlawfully Trained Models: What a Buyer Has to Check

If you deploy someone else's model, the opinion matters to you. It describes three scenarios:

Scenario	What happens	Consequence for you
1. Same controller trained and deploys, data retained in the model	One party did both	Unlawful training can affect the lawfulness of deployment
2. Another controller deploys a model whose data is retained	You are the deployer	You must assess whether the model was developed unlawfully before using it
3. Model anonymised before deployment	Personal data no longer in the model	GDPR does not apply to the model's operation, though it applied to its training

A decision tree for the three unlawful-training scenarios in EDPB Opinion 28/2024: same controller deploys, another controller deploys, or the model was anonymised first.

As a deployer, record how you assessed the vendor's training data source and whether any authority or court has found an infringement. A short file is enough:

The vendor's stated data sources and any public documentation
Whether a supervisory authority or court has made a finding against the vendor
The vendor's contractual commitments about lawfulness of training
The date you checked, and who checked it

GDPR Article 22 Automated Decision Making and AI

Article 22 restricts decisions based solely on automated processing, including profiling, that have legal or similarly significant effects on a person. It is a restriction with exceptions, not an absolute right.

What Counts as a Solely Automated Decision After SCHUFA

The Court of Justice held in C-634/21 on 7 December 2023 that a credit score can itself be an automated decision where the lender attributes a determining role to it, according to the Court's own press release. The agency producing the score does not make the final call, and the ruling still treats the score as the decision.

The consequence for AI teams is direct. A model output that a human clicks "approve" on may still be Article 22 territory if the human in practice defers to it. A commenter on a May 2026 Hacker News thread about algorithmic hiring puts it plainly: companies "can't just smash a button and claim meaningful interaction".

Decisions in a SaaS product that can qualify:

Hiring or screening filters
Fraud blocks that stop a transaction or lock an account
Credit, limit or pricing tiers
Account suspensions and access removal

The Three Exceptions and the Safeguards That Come With Them

Article 22(2) allows a solely automated decision in three cases: it is necessary for a contract, it is authorised by Union or Member State law with suitable safeguards, or the person gave explicit consent. Where an exception applies, Article 22(3) requires safeguards: the right to human intervention, to express a view and to contest the decision. Article 22(4) adds that decisions based on special-category data need explicit consent or a substantial public interest basis.

One practitioner on a 2022 Hacker News thread about an eBay ban says Article 22 receives "too little attention and more so enforcement". Regulators have started to catch up, and the two rulings here make the standard concrete.

What an Explanation Has to Contain After Dun & Bradstreet

In C-203/22 on 27 February 2025, the Court held that the controller must describe the procedure and principles actually applied so the person can understand which of their data were used and how, according to the Court's press release.

The Court added that telling the person how a change in the input data would have changed the result may be appropriate. Handing over the algorithm is not enough.

Where a controller says the information contains trade secrets, it must give that information to the supervisory authority or court, which balances the interests.

A practical template for the explanation:

Inputs: which data about the person the system used.
Main factors: what mattered most in this result.
What would change it: the kind of change that would alter the outcome.

Try this yourself Pick one automated decision in your product, such as an account flag or a score. Write the three-line explanation (inputs, main factors, what would change it) as if a customer asked. If you cannot write it from what your team knows today, the decision is not yet explainable under Article 15.

GDPR AI Data Subject Rights: Access, Erasure, Objection and the Model

People keep every GDPR right when an AI system is involved. The hard part is knowing which store a request touches.

Right	Where the data sits	A realistic response
Access (Article 15)	Prompt logs, retrieval index, outputs about the person	Search logs and the index by identifier, provide the copy and the Article 15(1)(h) explanation where decisions apply
Rectification (Article 16)	Source records, outputs, profiles	Fix the source and regenerate or suppress the output
Erasure (Article 17)	Logs, index, fine-tuning set, possibly weights	Delete from sources and logs, remove from the index, exclude from future training
Objection (Article 21)	Training and profiling on legitimate interest	Stop the processing unless you show compelling grounds, and exclude the person from training
Restriction (Article 18)	Any store	Flag the record so it is retained but not used

One person's data in an AI system sits in five places: prompt logs, retrieval index, fine-tuning set, outputs and model weights, with the data subject requests that reach each one.

Erasure from model weights is the unsolved case. A commenter on a March 2023 Hacker News thread about Italy's ChatGPT ban writes that LLMs "seem as though they would struggle with that" when it comes to the right to be forgotten. The EDPB's position that a model may not be anonymous means the question is real, not academic.

The defensible position today has four parts:

Delete from the sources, the logs and the retrieval index
Retrain or filter on a schedule, and exclude objectors from the next training run
Document what you can and cannot do for the weights, and why
Do not promise what you cannot deliver

GDPR DPIA for AI: When It Is Required and What to Put in It

Article 35 requires a data protection impact assessment where processing is likely to result in a high risk to people. Three triggers appear in the Article itself: a systematic and extensive evaluation of people based on automated processing, including profiling, that produces significant effects; large-scale processing of special-category data; and large-scale monitoring of public areas. Supervisory authorities also publish lists of their own. New technology combined with another high-risk factor is the combination that catches many AI features.

AI use	DPIA needed?	Reason
CV screening or ranking	Yes	Evaluation of people with significant effects
Fraud scoring that blocks accounts	Likely	Automated decision with significant effects
Chatbot answering from customer records	Likely	New technology plus personal data at scale
Support-ticket summariser, no sensitive data	Depends	Check scale and what the tickets contain
Internal code assistant, no personal data	No	No personal data involved

The table reflects my own assessment of typical cases. Your supervisory authority's list controls.

A DPIA contains four things: a description of the processing and its purposes, an assessment of necessity and proportionality, the risks to people, and the measures that address them. If high residual risk remains, Article 36 requires you to consult the supervisory authority before starting.

DPIA vs FRIA in GDPR and AI Compliance: Who Owes Which

The AI Act's fundamental rights impact assessment (FRIA) is narrower than many summaries suggest. Under Article 27, it applies to deployers of high-risk systems that are public bodies or private entities providing public services, and to deployers of the Annex III systems for creditworthiness and for life and health insurance pricing. Article 27(4) lets a FRIA cross-reference an existing DPIA.

Most SaaS teams owe a DPIA, not a FRIA. The AI risk assessment guide compares the assessments side by side.

Pro tip Keep one assessment document with a DPIA section and an AI risk section. It serves both audiences, and updating one document at each change is more realistic than maintaining two.

GDPR and EU AI Act: Where They Overlap and Where They Diverge

The AI Act stacks on top of GDPR. It does not replace it. A system can be fully compliant with one and in breach of the other.

Dimension	GDPR	EU AI Act
Trigger	Processing of personal data	AI systems placed on the market or used in the EU, by risk tier
Who is regulated	Controllers and processors	Providers, deployers, importers, distributors
Risk method	DPIA where processing is high risk	Risk classification, with obligations for high-risk systems
Documentation	Records of processing, DPIA	Technical documentation, logs, instructions for use
Individual rights	Access, erasure, objection, Article 22	Transparency duties and a right to an explanation of certain decisions
Top fine	EUR 20 million or 4%	EUR 35 million or 7% (prohibited practices); EUR 15 million or 3% (most other duties); SMEs pay the lower figure

On timing, the Digital Omnibus on AI (Regulation (EU) 2026/1744) moved the Annex III high-risk obligations to 2 December 2027. The prohibitions have applied since 2 February 2025. The EU AI Act compliance guide and the risk classification guide give the current dates and tiers.

The Act touches personal data directly in two places. Article 10(5) permits processing special-category data for bias detection in high-risk systems under strict conditions. Article 26(9) tells deployers to use the provider's instructions to carry out their DPIA.

Watch out The Commission's GDPR "Digital Omnibus" proposal includes a new Article 88c, which would treat AI development as a possible legitimate interest, and a more relative definition of personal data. It is a proposal under negotiation, not law. Plan on today's text and check its status before relying on any change.

GDPR Compliant AI in Practice: A Worked Example

The Setup: Northwind's GDPR and AI Compliance Review

Northwind is an invented 30-person SaaS company. It adds an LLM feature that summarises support tickets for its EU customers. The example is illustrative, not a real customer.

The Completed GDPR and AI Compliance Record

Stage	Data	Role	Article 6 basis	DPIA	Rights path	Vendor terms
Ticket ingestion	Customer support tickets	Northwind is processor for its customer	Customer's instruction	Covered by the customer's DPIA	Route to the customer	Customer DPA updated
Prompt to model	Ticket text, names, emails	Northwind processor, vendor sub-processor	Customer's instruction	Covered	Access via prompt log search	Vendor DPA, no training, 30-day retention
Retrieval index	Embedded ticket text	Northwind processor	Customer's instruction	Covered	Delete by ticket ID	Stored in the EU
Summary output	Summaries attached to tickets	Northwind processor	Customer's instruction	Covered	Regenerate on rectification	None
Log retention	Prompt and response pairs	Northwind processor	Customer's instruction	Short note	30-day auto-delete	None
Automated decisions	None. The summary does not decide anything	n/a	n/a	n/a	n/a	n/a

What the Example Shows About GDPR and AI Compliance

Three lessons come out of the record:

The logs and the retrieval index were the personal data nobody had listed. The team had thought only about the model.
The "no training" contract term did more than any technical control. One clause removed the largest risk.
There was no Article 22 decision, and writing that down was the work. A recorded "not applicable, because the summary does not decide anything" is evidence.

ComplyJet customers

How a small AI team got compliance moving fast

Nitin Pande, CTO at Vink AI, an AI go-to-market platform, says "as a small team, we needed a partner who could move quickly and handle the heavy lifting." Read how they earned SOC 2 Type 1 in under a month.

Read the Vink AI story

How to Start GDPR and AI Compliance in 30 Days

Four weeks is enough to get a small company from nothing to a defensible baseline.

Week	Focus	Output	Effort (author's estimate, team of 50 or fewer)
1	Inventory AI use and data flows	List of AI systems, vendors and the personal data in each	6 to 10 hours
2	Lawful basis, roles and vendor terms	One line per stage, DPA review for each vendor	8 to 12 hours
3	DPIA, rights procedure, notices	DPIA on the highest-risk system, request playbook, updated privacy notice	10 to 16 hours
4	Logging, review cadence, owner	Retention settings, a quarterly review date, a named owner	4 to 6 hours

A four-week timeline for GDPR and AI compliance: inventory in week one, basis and vendors in week two, DPIA and rights in week three, logging and ownership in week four.

For the policy that sets rules for staff use of AI tools, see the AI governance policy. For what a SOC 2 report does and does not say about AI, see does SOC 2 cover AI. For governing individual models once the baseline is in place, see AI model governance.

Mistakes That Break GDPR and AI Compliance

These are the six mistakes that show up most often, each easy to make.

Treating only the training set as personal data. Prompts, logs, the retrieval index and outputs are all in scope.
Assuming the vendor's DPA covers your lawful basis. The DPA governs the vendor's processing. The basis for your own use is still yours to document.
Calling a model anonymous without evidence. Under EDPB Opinion 28/2024 anonymity is a conclusion you have to be able to support.
A human rubber-stamp that is not real review. If the reviewer has no time, information or authority to change the result, Article 22 can still apply.
Promising erasure from model weights. Promise what you can do: deletion from sources, logs and the index, plus a retraining schedule.
One DPIA at launch and never again. A new model, a new data source or a new purpose is a reason to revisit it.

GDPR and AI Compliance Checklist

Collect and prepare

☐ We have a list of every AI system and the personal data in each place it sits.
☐ Each use of data has a documented purpose, a lawful basis and a retention period.
☐ Privacy notices say what is used for AI, and for what.

Train or fine-tune

☐ A legitimate interest assessment exists for any training on personal data.
☐ Customer data is not used for training unless the contract and the notice allow it.
☐ Any claim that a model is anonymous is backed by recorded testing.

Deploy and prompt

☐ Every vendor has an Article 28 agreement with no-training, retention and sub-processor terms.
☐ Staff use approved tools on the business tier of each product.
☐ Special-category data is filtered or excluded from prompts.

Operate and monitor

☐ We can search logs and the index to answer an access or erasure request.
☐ Any decision with significant effects has real human review, an explanation and a way to contest it.
☐ A DPIA covers each high-risk system and is reviewed when the system changes.

FAQs

Does GDPR Apply to AI Systems?

Yes. GDPR applies whenever an AI system processes personal data of people in the EU, whatever the technology. That includes training data, prompts, outputs and logs. Companies outside the EU are covered under Article 3(2) if they offer services to people in the EU or monitor their behavior.

Is AI GDPR Compliant by Default?

No. Compliance depends on what you do with the system: the lawful basis, the notices, the contracts and the controls around it. A vendor's marketing claim of "GDPR compliant" covers the vendor's own processing, not your use of the product.

Can You Use Legitimate Interest to Train AI?

Possibly. EDPB Opinion 28/2024 confirms legitimate interest can be a basis for developing and deploying models, but it does not presume it. You must pass the three-step test (interest, necessity, balancing) separately for development and deployment, and the right to object stays.

Is an AI Model Personal Data Under GDPR?

Not always, and not never. The EDPB says a model trained on personal data cannot in all cases be considered anonymous. It is a case-by-case question: the likelihood of extracting personal data from the model and of obtaining it through queries must both be insignificant.

Do You Need a DPIA for an AI System?

Often. A DPIA is required where processing is likely to result in a high risk to people. AI uses that evaluate people, process special-category data at scale or combine new technology with another risk factor usually qualify. A support summariser with no sensitive data may not.

Does Article 22 GDPR Apply to AI Decisions?

It applies when a decision is based solely on automated processing and has legal or similarly significant effects. After the SCHUFA ruling, a score a decision-maker relies on heavily can itself be the decision. A human who only clicks approve may not take you outside Article 22.

Is ChatGPT GDPR Compliant for Business Use?

It depends on the product tier and your contract. Business and API tiers typically offer a data processing agreement and options on retention and training, which consumer tiers may not. You still need a lawful basis, notices, a DPA and a transfer mechanism for your own use.

Does the EU AI Act Replace GDPR?

No. The two apply together. GDPR governs personal data processing, and the AI Act governs AI systems by risk tier. The same system can owe a DPIA under GDPR and conformity duties under the AI Act, and the fines can stack.

What Are the GDPR Fines for AI Violations?

GDPR fines reach EUR 20 million or 4% of worldwide annual turnover for breaches of the principles, lawful bases, special-category rules and data subject rights, including Article 22. Failing to run a DPIA or to set processor terms is in the lower tier of EUR 10 million or 2%.

Book a demo

Put your AI features inside a GDPR program that holds up to a buyer's review

Walk through the AI systems you run, how each one maps to your GDPR records, and what an EU customer or regulator would expect to see for a team your size.