GDPR and a DPA When Deploying AI: What to Sign and Check (2026)

Before AI touches company data you need at least three things: a data processing agreement (DPA, art. 28 GDPR) with every vendor that sees personal data, a defined processing location, and a clear rule on what may leave the company. The rest is detail. This is not legal advice, just a list of things to check before you deploy.

Quick answer

GDPR does not change because a language model, rather than a person, processes the data. One thing changes: a new vendor now sees your data. So before deployment you settle three things and fit every other document around them:

• A data processing agreement (DPA, art. 28 GDPR) with every vendor that processes personal data on your behalf: the model, the hosting, the automation tool. Without it, simply wiring data into an external API is flawed at the root.
• A defined processing location. You know where the data is physically computed. If it leaves the European Economic Area (EEA), you need a basis under GDPR Chapter V.
• A rule on what may leave. Which data you even let into the model, and which stays in the company. This is a boundary, not a statement: it is enforced by code, not by a policy document.

On top of that comes a duty most companies hear about for the first time: art. 4 of the AI Act has applied since 2 February 2025 and requires AI literacy from every company using AI professionally, regardless of sector or size (AI Act, art. 4; Polish Ministry of Digital Affairs, January 2025).

The first step to sort this out on a real process is free: a process scan (€0), 30 minutes with an engineer and a written takeaway in two business days.

What is a data processing agreement (DPA) and when do you need one?

A DPA is an art. 28 GDPR contract between a controller (you) and a processor (the AI vendor that processes personal data on your behalf). You need one whenever an external tool sees the personal data of your customers or staff. An ordinary services contract is not enough: the processing relationship has to be described explicitly (art. 28(3) GDPR).

A good DPA binds the vendor to a few specific things, and these are the points you check before signing:

• Processing only on your documented instructions, not for the vendor's own purposes (so not for training models without your consent).
• Confidentiality of the people with access to the data.
• Art. 32 GDPR security: appropriate technical and organisational measures, including encryption and pseudonymisation where they make sense.
• Sub-processor terms: an AI vendor usually relies on further sub-contractors (cloud, hosting), and you should know who and on what terms.
• Help with data subject rights (access, deletion, objection) and with handling breaches.
• Breach notification without undue delay and return or deletion of data when the service ends.
• Audit rights: the ability to verify that the vendor does what it committed to.

This is not a box to tick. It is a list of questions that separate a vendor ready for production from a tool that "sort of works."

What to sign and check before AI touches data

This is not the whole of compliance, just the five things that in practice block or unblock a deployment. The "when needed" column matters more than the document's name.

Can you put customer data into ChatGPT?

Short answer: not unconditionally, and this is the most common mistake. An employee who pastes a customer list or a complaint into free ChatGPT to "write a reply faster" has just sent personal data to an external vendor with no data processing agreement and no control over where it lands. This is not about the employee's good faith; it is a missing boundary in the process.

It can be done well, but on terms:

• A plan with a DPA. You feed personal data into the model only through a channel where you have a signed DPA and control over processing, not through a consumer account. For OpenAI this means a business plan or the API with a DPA, where by default models are not trained on your data (OpenAI, business data, as of December 2025).
• Minimisation. Only what the task genuinely needs reaches the model. A case number instead of a full record, a fragment instead of the whole database.
• Anonymisation and pseudonymisation. Where the model does not need a name or a national ID to do the task, those fields are stripped or replaced before sending.
• A hard boundary. Categories of data that never leave the company (sensitive data, legal documents, secrets) are enforced by code, not by a sentence in a policy.
• A trail. You know what type of data reached the model, when, and why, so it can be checked and demonstrated after the fact.

In our production automation of a shared inbox (a B2B services company, about 3,000 emails a month) the model only classifies a message; a deterministic process policy, not the model, decides what happens next. Personal data is minimised before sending, boundaries are enforced in code, and prompt-injection attempts go to quarantine. We report 3,000 as an input volume; we do not invent percentage results.

Where your data physically lands

GDPR does not ban processing data outside Europe, but it sets a condition. Chapter V of the GDPR allows personal data to be transferred outside the EEA only on one of two bases: a Commission adequacy decision for the country (art. 45) or appropriate safeguards, most often standard contractual clauses (SCCs, art. 46). Without one of these, a transfer outside the EEA is simply unlawful (gdpr-info.eu, Chapter V; EDPB SME guide).

In practice this becomes three questions for every AI vendor:

1. Where is my data physically processed: inside the EEA or outside it?
2. If outside the EEA, on what Chapter V basis (adequacy or SCCs)?
3. Does the vendor offer data residency in Europe, and is it switched on for my configuration?

This is not theoretical. Larger vendors give real options here: OpenAI offers data residency in Europe for eligible API customers and business plans, though it has to be enabled deliberately, for new projects (OpenAI, data residency in Europe). The default configuration does not always keep data in Europe, so it is on you to arrange it.

Run your own exposure

Before you file this under "a topic for lawyers later," calculate what the company is exposed to. This is your substitution, not our threat. The ceiling for a GDPR fine is defined by statute:

Fine ceiling (GDPR, art. 83(5)) =
  the higher of:
  EUR 20,000,000
  or 4% of the company's total worldwide annual turnover

Fines at the ceiling are rare and reserved for serious, sustained breaches, so the point is not to scare you with that number. The point is that the exposure scales with your turnover, not with the cost of the deployment. If sorting the data out costs a fraction of that exposure, the decision stops being "is it worth it" and becomes "when." The real cost of compliance is usually time for contracts, location configuration, and boundaries in code, not a separate huge project.

How we do it

At Syntalith, compliance is not a stage after the build. It is how we build from day one. It is the same engineering that lowers cost and risk: less data in the system means less attack surface and less to demonstrate.

• Minimisation at the source. We design the process so that as little personal data as possible reaches the model, ideally none, when the task can run on anonymised data.
• Boundaries in code. What may be sent and what stays in the company is enforced by a deterministic policy, not by the good faith of the model or an employee.
• Location under control. We pick vendors and configuration so it is clear where the data is computed, and so a transfer outside the EEA either has a basis or does not happen at all.
• An audit trail. Every operation on data stays in the log, so accountability under art. 5(2) GDPR is a record, not a claim.

We describe the same thinking in our AI agent implementations and in the AI process audit. How we treat data in our own systems is on our privacy page. And why "model safety" alone is not enough once an agent reaches for data, we explain in the piece on prompt injection.

When you do NOT need a big legal project

Honestly: not every use of AI needs a separate legal project. Sometimes common sense and one deliberate decision are enough.

• You do not process personal data. If the AI works only on public, synthetic, or fully anonymised data, GDPR does not enter here. First check whether the data really is personal, instead of assuming the worst.
• The vendor already has a DPA, data stays in the EEA, and you do not feed in personal data. That is a genuinely sufficient setup for many simple use cases. Not every process needs a bespoke deployment.
• You use AI privately, not professionally. Personal drafts on a consumer account are a different situation from company customer data. Do not mix the two worlds, but do not over-lawyer where there is nothing to lawyer.

If one of these fits, we will say so plainly at the scan, before we propose anything paid.

This is not legal advice

This material describes deployment practice and points to rules worth knowing, but it does not replace legal advice. The specific data processing agreement, risk assessment (DPIA), or AI policy tailored to your company should be reviewed by a lawyer or a data protection officer. Our job is to build the system so that such a review has something to review: with boundaries, a defined location, and a trail, not with a promise that "it is compliant."

How to start

The cheapest sensible first step is to name the data in the process, not to buy a tool.

1. Book a free process scan and show one process where AI would touch data.
2. Prepare: which data is in play, whether it is personal, who sees it today, where it is processed, and what should never leave the company.
3. After the call you get a map: what needs a DPA, where to set the location, which boundaries to write into code, and whether you need an AI policy under art. 4.

Book a free process scan | AI agent implementations | AI process audit | Pricing

Sources

• GDPR (Regulation 2016/679): art. 28 (processing), art. 32 (security), Chapter V (transfers outside the EEA), art. 83 (fines)
• gdpr-info.eu, Chapter V; EDPB SME guide on international transfers
• AI Act, art. 4 (AI literacy); Polish Ministry of Digital Affairs, "First AI Act provisions," January 2025
• OpenAI: Data Processing Addendum (December 2025), business data, data residency in Europe

Related articles

• Prompt injection in AI agents: threat and defense
• AI Act article 4 literacy training for companies
• What an AI agent is: seven criteria
• AI agent implementations
• Syntalith privacy