The GDPR applies to AI whenever an AI system processes personal data, whether you train a model, fine-tune one or simply let your team paste customer records into an assistant. You need a documented purpose, a lawful basis for each stage, a data protection impact assessment where the risk is high, and a way for people to get a human decision when an automated one affects them. The EU AI Act sits on top of this and adds its own duties, including transparency. This guide explains how the two fit together for a B2B SaaS company, and what to do first.

It is general information, not legal advice. Your data protection officer or counsel should confirm how any of it applies to your company.

TL;DR

Table of Contents

How the GDPR applies to AI

The GDPR regulates personal data, not technology. One analysis of the law notes that AI is not explicitly mentioned, and that Article 22 on automated decision-making works as an indirect control on AI. Everything else comes from the general principles: lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, security and accountability.

For a SaaS company, the practical question is simple. Does the AI see names, emails, usage logs tied to a user, support tickets, invoices or anything else that identifies a person? If yes, the GDPR applies, even if the AI is a tool you bought and did not build.

Purpose and lawful basis, stage by stage

The UK data protection regulator’s guidance says that for each distinct processing operation in AI development and deployment, you should identify and document its purpose and an appropriate lawful basis before you process anything. It also says special-category data needs a separate condition. That guidance covers the UK GDPR, which mirrors the EU rules closely, and it is a useful reference for the logic.

The same guidance says training and deployment are different stages and may rest on different lawful bases. A basis that works for building a model does not automatically cover using it on live customer data.

In practice, write one line per AI use case:

  1. What is the purpose (for example, summarizing support tickets)?
  2. Which personal data does it read?
  3. What is the lawful basis (contract, legitimate interest, consent, legal obligation)?
  4. Who is the controller, and who is the processor?
  5. Where is the data stored and processed?

If you want a plain-language walk through how to pick and document a lawful basis and apply the core principles, this piece on core GDPR data protection principles shows the same reasoning applied to a booking system, and the logic carries over to AI projects.

Purpose limitation, minimization and accuracy

The Dutch data protection authority lists purpose limitation, data minimization and accuracy as core GDPR requirements for AI. Each has a direct effect on how you build.

The same Dutch guidance points to Article 32: you need appropriate technical and organizational measures, taking into account the state of the art, the context of processing and the risks to individuals.

What the EDPB said about AI models

In December 2024 the European Data Protection Board issued Opinion 28/2024 on AI models. An academic overview of the opinion explains that models trained on personal data can retain or infer information about identifiable people, so they cannot simply be assumed anonymous. It also covers how legitimate interest can be justified after training has finished. The takeaway for buyers: do not accept “the model is anonymous” from a vendor without asking how that was assessed.

Where the EU AI Act adds to the GDPR

The two laws have different roots. According to a European Parliament study, the AI Act draws on a product-safety model, while the GDPR protects personal data through rights and principles. The same study notes that obligations can overlap: a fundamental rights impact assessment (FRIA) and a data protection impact assessment (DPIA) may duplicate each other, and transparency and logging duties can be redundant.

Roles differ too. The GDPR uses controllers and processors. The AI Act uses provider, importer, distributor and deployer. A SaaS company can be a provider of its own AI features and a deployer of someone else’s model at the same time, and a controller or processor for the personal data involved. Map each role per use case.

GDPR EU AI Act
Starting point Personal data and people’s rights The AI system and its risk level
Key roles Controller, processor Provider, deployer, importer, distributor
Typical documents Records of processing, DPIA Technical documentation, logs, FRIA for some high-risk uses
Human involvement Right not to be subject to solely automated decisions with legal effects Human oversight for high-risk systems

Some national authorities have pointed out that a system can comply with one law and still breach the other, which is why a case-by-case approach is needed. The Belgian authority adds that the AI Act builds on GDPR accountability with formal incident reporting and human-in-the-loop governance.

NIS2 is a third piece, and it is about cybersecurity and risk management for in-scope entities, not about AI specifically. If your company falls within its scope, the security measures you put around AI systems belong in the same risk process. Whether you are in scope is a question for counsel.

Transparency obligations when AI meets people

Transparency shows up in both laws, and people often confuse them.

Timing matters. The Commission’s AI Act Service Desk states that the Article 50 obligations became enforceable on 2 August 2026, and that providers of systems placed on the market before that date have until 2 December 2026 to meet certain marking and detection requirements.

For a SaaS company, the common cases are a chatbot in your product or support widget, and generated text or images you publish. Label the chatbot as AI, and check how your tools mark generated content. For a deeper look at Articles 4 and 50, see our guide to EU AI Act Articles 4 and 50 for SaaS.

Support specialist testing a product chatbot

DPIAs, human oversight and automated decisions

Three safeguards come up most often.

DPIA. The Belgian authority explains that a DPIA is required in some cases, including high-risk processing and the use of new technologies. The Dutch authority similarly says one is needed when algorithmic systems process personal data and the risks to privacy are high. When unsure, run one. It is cheaper than explaining later why you did not.

Human oversight. The AI Act requires human oversight for high-risk systems across development, deployment and use, and the same Belgian source says so alongside the FRIA requirement.

Automated decisions. Under the GDPR, people have the right not to be subject to decisions based solely on automated processing that produce legal effects concerning them. If an AI agent could decide who gets a contract, a credit limit or access to a service, design a human approval step into the process.

An AI Act checklist for SaaS teams

The Commission’s overview of the AI Act says high-risk systems must cover risk assessment and mitigation, dataset quality, logging, technical documentation, information for deployers, human oversight, robustness, cybersecurity and accuracy. Most SaaS products are not high-risk, but the list is a good standard for any AI that touches people’s data.

Deadlines for high-risk systems are later than many expect. The Service Desk FAQ says systems in sensitive areas such as employment (Annex III) must comply by 2 December 2027, and those embedded in regulated products (Annex I) by 2 August 2028. Check the official page for the current position, as timelines can change.

A working checklist:

  1. Inventory every AI use. Include tools individuals adopted on their own.
  2. Classify each one. Is it a chatbot, internal assistant, scoring model or something that makes decisions about people? Ask counsel whether any use is high-risk.
  3. Map roles. Provider, deployer, controller, processor.
  4. Document purpose and lawful basis for each stage.
  5. Run a DPIA where the risk is high.
  6. Set permissions. The AI should read and change only what the user could.
  7. Add approval steps for actions with real consequences.
  8. Keep logs of what the AI read, wrote and triggered.
  9. Label AI interactions and generated content.
  10. Train people. Article 4 asks for AI literacy.
  11. Check vendors. Where is data processed, and is it used to train their models?
  12. Assign an owner. One named person should be accountable.

Our AI governance framework for B2B SaaS companies turns this into a working structure.

Where AI does not belong

Good compliance includes deciding what AI should not do. We would keep AI out of these places:

Build the data foundation first

Most GDPR trouble with AI starts in the data, not the model. If you cannot say where a customer’s data lives, which system is correct, and who can read it, you cannot honor access or deletion requests, and you cannot control what an AI reads.

That is why we work in a fixed order:

  1. Data foundation. Your CRM and finance data become the source of truth, with the systems around them reconciled into one agreed version.
  2. AI layer. The assistant your team already uses is connected to that data through MCP, within permissions.
  3. Department agents. Purpose-built agents for Finance, Sales and Customer Success, so people can ask, report and look up across systems, and update records or trigger processes with approval where needed and an audit trail.

Build, pilot and testing run on self-hosted European infrastructure in Germany, and GDPR, NIS2 and the EU AI Act are treated as design requirements from the start. No design guarantees compliance, and that judgment stays with you and your counsel. But a system with permissions, approvals and logs in place makes the questions regulators ask far easier to answer. You can see how this works in practice on our page on AI agents for Finance, Sales and Customer Success, and the Admin Portal shows how access and approvals are managed in one place.

Our perspective

We see the same pattern in growing SaaS companies. People already use AI, in the CRM, in support, in finance, and nobody owns it. Nobody decided which data it may read, nobody keeps a record of what it did, and the privacy notice was written before any of it existed.

Our view is that compliance is mostly an operations problem. A privacy policy does not stop an assistant from reading a record it should not. Permissions, approvals and logs do. That is why we start with the data foundation, then connect the AI layer, then build department agents, and why we adopt AI one process at a time, starting with the most expensive one.

It also helps to have one person who both decides where AI pays and builds it, so the strategy and the working system do not drift apart. That is the idea behind a Fractional Chief AI Officer backed by 25 years of running operations. We design to GDPR, NIS2 and the EU AI Act from the first day, and you own the source code, documentation and infrastructure at handover.

We do not give legal advice, and nothing we build guarantees compliance. We make the systems easier to govern, and we work alongside your counsel.

Claus Nielsen

Where to start

If AI is already in use and nobody owns it, the first step is an honest picture of what you have. Our AI Readiness Assessment starts from €4,500 and looks at your data, your processes and your regulatory exposure, so you know where AI pays and where it does not. For continuing ownership, the Fractional Chief AI Officer retainer has three levels: Advisor from €3,000 per month, Operating from €6,500 per month, and Embedded from €11,000 per month.

Builds are priced either at 30% of the first-year saving, once measured and proven, or at a fixed price agreed before work starts. You can also book a free 30-minute discovery call through our main site.

FAQ

Does the GDPR apply if we only use a third-party AI tool?

Yes, if personal data goes into it. You are usually the controller and the tool provider is a processor, so you need an agreement, a purpose and a lawful basis, and you should know where the data is processed. Check whether the vendor uses your inputs to train its models.

Is the EU AI Act a replacement for the GDPR?

No. They apply side by side. The GDPR protects personal data, while the AI Act regulates AI systems by risk level. A single AI use case can trigger duties under both, and some documents, such as impact assessments, may overlap.

Do we need a DPIA for every AI project?

Not necessarily. A DPIA is required in some cases, including high-risk processing and new technologies, according to the Belgian authority. If an AI system processes personal data in a way that could seriously affect people, run one. Ask your data protection officer when it is unclear.

What do we have to tell users about AI?

Under the GDPR, explain what personal data you process and why. Under AI Act Article 50, which is enforceable since 2 August 2026, people must be told when they interact directly with an AI system, and AI-generated content must be marked in machine-readable form. Your counsel can confirm which parts apply to your products.

Can an AI agent make decisions about customers on its own?

For routine, low-impact tasks, yes, within permissions and with logs. For decisions with legal or similarly significant effects on a person, the GDPR gives people the right not to be subject to solely automated decisions. Build in human review for those.

Sources