Train AI models on your own data without violating GDPR and the AI Act

Anyone who trains an AI model on corporate data must clarify three things: whether a legal basis supports further processing, whether the finished model itself still has personal references, and whether training turns you from a deployer into a provider. Your own data makes all three questions easier. It does not answer any of them.

The common summary is: own data instead of purchased data, minimize, encrypt, document. This is correct. It is only of limited help because it leaves out the questions that really cause a training project to fail. This article goes through them in order.

For each statement, the source is listed below in italics and on its own line. You can skip them and still understand everything. The basis is the legal texts themselves, Opinion 28/2024 of the European Data Protection Board, a guideline from the EU Commission, a ruling of the European Court of Justice, a peer-reviewed research paper, and our own analysis of the terms of use of major model providers. This is not legal advice.

Terms you need. The GDPR is the General Data Protection Regulation. The AI Regulation is the same as the EU AI Act; this article uses both names. The EDPB is the European Data Protection Board, which houses the national supervisory authorities; its opinions are not law, but they are the standard by which authorities measure compliance. Provider is whoever builds an AI system and offers it under their own name, while deployer is whoever uses it. GPAI are general-purpose AI models, such as a language model. Fine-Tuning means retraining a finished model with own examples. Distillation means training a small model on the answers of a large one. para. stands for paragraph, meaning the numbered section in a document.

In brief: The most important points

• Your own data shifts the legal question, it does not solve it. Your existing data was collected for a different purpose. Training is a new purpose, and there is a separate assessment for that. The EDPB has not yet committed to this specific assessment.

• A trained model is not automatically anonymous. The standard is strict: it must be negligible for every single data subject that their data can be retrieved from the model. Not rarely, not low on average, but negligible.

• A lack of documentation is itself a violation. If an authority cannot trace in your records that you have anonymized the model, that is enough for them to make an allegation. Regardless of whether the model is actually anonymous.

• The high-risk deadlines have been postponed, but the transparency obligation has not. Annex III applies from December 2, 2027, Annex I from August 2, 2028. In contrast, the labeling obligation has already been in force since August 2, 2026.

• The headline fine amounts will almost certainly not apply to you. The well-known 35 million euros only apply to prohibited practices. For everything else, it is 15 million or 3 percent of global turnover. And for small and medium-sized enterprises, the lower of the two values always applies.

• Fine-tuning usually does not turn you into a model provider. For that to happen, your training would have to consume more than one-third of the computing power embedded in the base model. A typical project is far below that.

• The real risk is the new purpose. Tailoring a general-purpose model to a sensitive task turns you into the provider of a high-risk system. The trigger is the purpose, not the computing effort.

• After training, you must measure safety again. In one study, the proportion of harmful responses increased from 5.5 to 31.8 percent after a single harmless training run. No attack, no intent, standard settings.

Table of Contents

1. Why your own data is the better basis, and where that advantage ends

2. The four core legal questions before the first training run

3. What the EU AI Act means for training

4. How to train in compliance: six steps

5. The special case: Your teacher model is a matter of contract

6. What is currently changing and remains open until the end of October

7. How we walk through this with you

8. Frequently Asked Questions

9. Sources

Why your own data is the better basis, and where that advantage ends

Your own data really helps you, but in a different place than usually claimed.

The advantage lies in the relationship with the data subject. A customer who writes you a support ticket is in contact with you. A person whose forum post was collected from the web is not. The EDPB explicitly evaluates these two cases differently. In which direction, it does not specify, but the direct relationship is the point of connection.

Source: EDPB Opinion 28/2024, para. 94

Then there are the practical benefits. You know the origin of every dataset. You have a deletion routine. You can actually address data subject rights. With purchased data, even the first of these three points often fails.

And now, the point where the advantage ends. Your data was collected for a specific purpose: contract, support, accounting. Training is a different purpose. The question is no longer whether you are allowed to have the data. It is whether you are allowed to use it for that. This is exactly where projects fail, not at encryption.

A common misconception at this point: simply write the training purpose into the privacy policy, and the matter is settled. This is wrong. The EDPB says to this effect that fulfilling transparency obligations alone is not sufficient to assume that a person must reasonably expect a certain processing.

Transparency is an obligation, not a blank check.

Source: EDPB Opinion 28/2024, para. 92. Original text: „the mere fulfilment of the transparency requirements set out in the GDPR is not sufficient in itself to consider that the data subjects can reasonably expect a certain processing“

The four core legal questions before the first training run

A distinction first, because it is often confused. Using a third-party model via an API is different from training your own. Using is about data processing agreements, server locations, and data transfers to third countries. We covered this in the article on OpenAI, Claude, and Gemini in Europe.

Here we are talking about the other case: your data goes into the model itself. This is the more difficult case, because choosing a European data center does not solve it.

One question comes even before that, and it is not a legal one: Is training even the right lever for your task? Often, a better prompt or a retrieval system solves the same problem. How to recognize this beforehand is explained in the article When is it worth fine-tuning a model.

Question 1: Does a legal basis support the further processing?

In practice, legitimate interest is usually the only option. Obtaining consent from all data subjects fails due to the sheer volume. Contract performance rarely supports training. The French supervisory authority CNIL shares this view.

Source: Art. 6 (1) (f) GDPR. CNIL, Recommendations on legitimate interest in AI development

Legitimate interest is tied to three conditions. First, a legitimate interest must exist. Second, the processing must be necessary for it. Third, the interests and fundamental rights of the data subject must not outweigh it. Two points regularly decide the outcome in projects.

The interest must be concrete. "We want to use AI" is not enough. It must be lawful, clearly defined, and real, not just potential. The EDPB lists three examples that can justify a legitimate interest, provided the other two stages also hold up: an assistant to support users, a system to detect fraudulent content or behavior, or improved threat detection in one’s own information system.

Source: EDPB Opinion 28/2024, para. 66, 68, and 69

Necessity is a high hurdle. For many projects, this is the breaking point. The rule is effectively: if your goal can also be achieved with a model that does not process personal data, then the processing of personal data is not necessary.

Translated for your project: can it be done with pseudonymized or synthetically generated data? If so, you are not allowed to use the real data. This is not a formalism. It is a question that your team can answer technically beforehand.

Source: EDPB Opinion 28/2024, para. 73

Question 2: Does the change of purpose hold up?

If you use data for a new purpose, the law requires an assessment: is the new purpose still compatible with the original one? Five criteria must be considered, and the list is not exhaustive.

Source: Art. 6 (4) GDPR

A trap that is rarely mentioned. This assessment is only open to you if you did not collect the data via consent. Anyone who collected data with consent cannot transition to training via a change of purpose. They need new consent. This affects newsletter and tracking databases more often than those involved realize.

And an honest gap. The EDPB deliberately left this question open. In its opinion, it lists the regulation under "not analyzed," adding that it could be relevant to training and that supervisory authorities must assess this. Thus, there is no European consensus on this, only national practice. Anyone promising you a clear answer here is promising too much.

Source: EDPB Opinion 28/2024, para. 17

Question 3: Is there sensitive data in your inventory?

The law protects certain details particularly heavily: health, origin, religion, union membership, sex life, political opinions. You can check for this in structured fields. In free text, you cannot.

Yet that is exactly what most training projects boil down to: tickets, emails, meeting notes, complaints. These contain sick leaves and indications of origin without there being a dedicated field for them.

The European Court of Justice has made a statement on this that is unpleasantly clear for free-text inventories. To the effect: if a dataset is collected as a whole and sensitive and harmless details cannot be separated, then the processing of the entire dataset is prohibited as soon as even one sensitive detail is inside and no exception applies.

Source: ECJ (Grand Chamber), Judgment of 04.07.2023, C-252/21 (Meta Platforms v. Bundeskartellamt), ECLI:EU:C:2023:537, para. 89. The EDPB refers to the same passage in para. 17 of its Opinion 28/2024.

What exceptions remain realistic? Explicit consent, and for employment data, labor and social security law. Do not rely on someone having "manifestly made their data public." The Court requires a clear action with exactly that intent. The fact that something can be found on the web is not enough.

Source: same decision, para. 77 and para. 82 to 84

There is a workaround via the AI Act. It allows the processing of sensitive data, but solely for the purpose of detecting and correcting bias in the model. Under strict conditions, and the data must be deleted afterwards. This is an exception for fairness testing, not a training permit. An obligation to look for bias explicitly does not follow from this.

This permission was in Art. 10 (5) until July 2026 and only applied to providers of high-risk systems. The Digital Omnibus has detached and expanded it: it now also applies to deployers and providers of other AI systems and models. The workaround has thus become broader, not narrower.

Source: Art. 4a AI Act, inserted by Regulation (EU) 2026/1744. It replaces Art. 10 (5), which was repealed as of 27.07.2026.

The practical path therefore involves removing sensitive details before training. How well this must succeed and where automated procedures fail is explained in our article on Redacting personal data.

Question 4: Does anything remain in the finished model?

This question almost never appears in guidebooks, yet it determines everything else. Because if the model weights contain personal data, the GDPR also applies to any subsequent transfer, export, and operation of the model.

A trained model is not automatically anonymous. This must be verified case by case.

The reason: during training, information from the data moves into the weights of the model. It exists there in a different form, as numbers, but the content is preserved. Under certain circumstances, it can be retrieved.

Source: EDPB Opinion 28/2024, para. 31 and 34

The standard for anonymity is strict. Two paths must be practically excluded: that someone extracts the data directly from the model, and that the model reveals it in its answers. And this must hold true for every data subject, not just on average.

Source: EDPB Opinion 28/2024, para. 43

One point is favorable for most corporate projects. A model that is only accessible internally and can only be queried by employees is evaluated differently than a public chat service. This saves many projects.

Source: EDPB Opinion 28/2024, para. 46

An open dispute you should be aware of. In 2024, the Hamburg data protection authority took the position that a stored language model contains no personal data at all. Half a year later, the EDPB saw it differently. Both papers are published, neither has been repealed. If you rely on the Hamburg approach, do so deliberately and write it down. Do not do it by accident.

Sources: HmbBfDI, Discussion Paper of 15.07.2024 vs. EDPB Opinion 28/2024, para. 31, 34, and 43

What the EU AI Act means for training

Which deadlines actually apply

Many texts contain errors on this point, including those from summer 2026. The so-called Digital Omnibus postponed the deadlines for high-risk systems. It did not postpone the labeling obligation.

Source: Regulation (EU) 2026/1744, published on 24.07.2026, in force since 27.07.2026

The widespread all-clear that "everything is postponed to 2027" is therefore incorrect. The labeling obligation has been in force since August 2, 2026. It does not depend on the risk class, but on the type of system. Anyone operating a chatbot or outputting AI-generated content is subject to this duty, even at minimal risk. What this concretely requires is detailed in our article on the labeling obligation under Art. 50.

Does fine-tuning make you a provider?

This is the most expensive question of the entire topic. Because a provider must deliver significantly more than a deployer: conformity assessment, technical documentation, risk management, registration.

Three things make you the provider of a high-risk system.

Source: Art. 25 (1) AI Act

The third case affects most projects. It applies even if the original system was never high-risk. An example: anyone tailoring a general-purpose language model to pre-screen job applications becomes the provider of a high-risk system. How much computing power the training cost plays no role here.

A shortcut that appears in several guidebooks and is incorrect. They claim that fine-tuning is "a substantial modification." This is too broad. A substantial modification requires two things: it was not foreseen in the original assessment, and it either affects compliance with high-risk system requirements or changes the purpose. Fine-tuning that keeps the purpose unchanged and was foreseen in the manufacturer's original conformity assessment is precisely not a substantial modification. A single line in the factsheet is not enough for this.

Source: Art. 3 No. 23 AI Act

If you become a provider, the original manufacturer is released from their obligations. However, they must cooperate with you, provide you with technical documentation, and disclose known limitations and errors.

And now, the catch that regularly hits in practice: this obligation is completely waived if the manufacturer has explicitly specified that their system must not be converted into a high-risk system. Major providers specify this in their terms. This is exactly why this point belongs in your contract before you begin.

Source: Art. 25 (2) AI Act in the version of Regulation (EU) 2026/1744. The list of cooperation duties was only added with this amendment; it is not in the original version.

Will you become a model provider? Probably not

Here, the news is better than the usual alarmist tone suggests.

The AI Act says it itself: anyone who merely modifies or retrains a model has obligations limited to that specific modification. In essence, it states that you supplement the existing technical documentation with details of the changes, including new training data sources.

You do not have to document the training data of a third-party base model that you have never seen.

Source: Recital 109 of the AI Act

The EU Commission has narrowed this down further. You only become a model provider yourself if your change significantly alters the model. As a benchmark, the Commission states: your training would have to consume more than one-third of the computing power embedded in the base model. The Commission itself assumes that currently very few modifications reach this threshold.

A typical fine-tuning in mid-sized businesses is far below that, not just slightly. The benchmark is not a hard limit, and the Commission admits it is difficult to apply when the computing power of the base model is unknown. Still, it serves as a guide. The real risk for your project is the new purpose, not the computing power.

Source: European Commission, Guidelines on the scope of the obligations for providers of general-purpose AI models, C(2025) 7719 final of 19.11.2025, para. 60 f. If the computing power of the base model is unknown, the guideline alternatively suggests one-third of 10²³ FLOP as a baseline, or one-third of 10²⁵ FLOP for models with systemic risk.

What a violation actually costs

The figure of 35 million euros appears in almost every text on the topic. It is correct, but it applies to something other than what we are discussing here. The fines are tiered.

In principle, the higher of the two values applies. And then comes the rule that almost no guidebook mentions, which is the actually important one for mid-sized businesses: for small and medium-sized enterprises, including startups, the lower value applies in each case.

A calculation example for a company with 10 million euros in annual turnover. For the duties discussed in this article—namely documentation, data governance, and provider duties—the upper limit is 3 percent, which is 300,000 euros. Even for a prohibited practice, it would be 7 percent, or 700,000 euros. In no case is it 35 million.

This is still highly threatening to a business, but it is a different order of magnitude than the headline. Anyone arguing internally with 35 million to secure a budget is arguing with a number that does not apply to their company.

Source: Art. 99 (3) to (6) AI Act

How to train in compliance: six steps

The steps take place in this order, and each generates a document. This is not for its own sake. At the end of the section is the list of what should be in your file. GDPR and the AI Act largely require the same records, just under different names.

1. Record data sources, including the original purpose

The AI Act requires you to document where your data comes from, how it was collected, and, for personal data, for what purpose it was originally collected.

This last clause is inconspicuous and at the same time the most useful in the entire topic. Because you also need exactly this detail for the purpose compatibility assessment in Question 2. A single register thus serves both regulatory frameworks. Anyone who keeps one of the two documentations clean has already completed half of the other.

Maintain the register per data source, not per project. It should include: table, field, reason for collection, legal basis, retention period, deletion routine.

Source: Art. 10 (2) (b) AI Act, combined with Art. 6 (4) GDPR

A German special case that stops real projects. As soon as employee data enters the training set, two additional regulatory frameworks apply. And for that, it is enough for clerks to appear by name in tickets.

The first is the German Federal Data Protection Act (BDSG), though with a restriction that many checklists do not yet reflect. Its general clause for employee data, Section 26 (1) sentence 1 BDSG, has been considered contrary to EU law since a 2023 ruling of the European Court of Justice and is no longer used as a legal basis. Instead, you rely directly on the GDPR. The remaining paragraphs remain in force, especially those on sensitive data and works agreements. A dedicated Employee Data Protection Act has been announced for years but has still not been passed.

The second is the Works Constitution Act (BetrVG). It gives the works council an enforceable right of co-determination regarding technical devices designed to monitor the behavior or performance of employees. Important to note: it is sufficient that the system is capable of doing so. You do not need to intend to monitor anyone.

A model that learns from processing workflows easily meets this. Involve the works council before the first training run, not just before rollout. Retrospective approval of fully trained weights is the most unpleasant version of this conversation.

Sources: Section 26 (3) and (4) BDSG; on the non-applicability of Section 26 (1) sentence 1 BDSG: ECJ, Judgment of 30.03.2023, C-34/21. Section 87 (1) No. 6 BetrVG; on objective capability Federal Labour Court (BAG), Decision of 23.03.2021, 1 ABR 31/19.

2. Verify the legal basis and write down the assessment

The three-stage assessment from Question 1 belongs in a document, not in a meeting. The EDPB explicitly requires authorities to check whether controllers have carried it out carefully and written it down.

Source: EDPB Opinion 28/2024, para. 66

One point is regularly done wrong here. Measures that you are already legally required to take do not count as a plus point in the balancing test. Data minimization, which you are already obligated to do, does not improve your position. What counts are measures that go beyond the mandatory program.

Source: EDPB Opinion 28/2024, para. 97

The EDPB lists four such voluntary measures. Two of them are particularly easy to implement. First: let data subjects delete their data even if they have no legal claim to it. Second: give them a way to report that the model is leaking their data, along with the circumstances under which this can be repeated.

Source: EDPB Opinion 28/2024, para. 102

The decision on the Data Protection Impact Assessment (DPIA) belongs in the same document. It is mandatory if the processing is likely to result in a high risk to the rights of the data subjects. The law lists three key examples: systematic and extensive automated evaluation of personal aspects, on which decisions with significant effects are based; large-scale processing of sensitive data; and systematic monitoring of a publicly accessible area on a large scale.

A training project on large legacy databases regularly triggers at least one of these. If you decide against a DPIA, the reasoning must also go into the file. The EDPB explicitly demands documentation of the decision why none was necessary.

Sources: Art. 35 (1) and (3) GDPR, EDPB Opinion 28/2024, para. 58 (a)

3. Minimize, before the GPU runs

The necessity test from Question 1 is essentially a technical question: can it be done without personal data? For extraction, sorting, and formatting tasks, the answer is surprisingly often yes. The model is supposed to learn the structure there, not the individuals.

The EDPB looks at four areas of your model design: the selection of data sources, the preparation and reduction of data, the training decisions themselves, and the measures applied to the model's outputs.

Regarding training decisions, it mentions two methods by name. Regularization ensures that the model does not memorize the examples. Differential Privacy adds targeted noise during training so that individual datasets can no longer be extracted.

Memorization is therefore not just a quality problem. A model that memorizes training examples is also a poorer model from a data protection perspective.

Source: EDPB Opinion 28/2024, para. 49 to 53

4. Process securely, and test the model itself

Encryption, access control, and a data processing agreement are mandatory and undisputed. For the contractual side, we have written a checklist for DPAs with AI tools, which also applies to training service providers.

The part that is missing almost everywhere is testing the model itself. The EDPB lists five test areas involving six types of attacks and explicitly states that the list is not exhaustive. This is the most concrete passage of the entire document and can be translated directly into a test plan.

The EDPB itself notes a limitation: a passed test only proves that the model withstands the tested, currently known attacks. It does not prove anonymity for all time. This is an argument for repeating the test, not for omitting it.

Source: EDPB Opinion 28/2024, para. 55

5. Document, because the absence is itself the violation

This is the sharpest sentence of the entire opinion. If an authority cannot understand from your records that you have effectively anonymized, it may derive a violation from that alone. The missing documentation is therefore not just an evidentiary problem. It is a separate allegation.

Source: EDPB Opinion 28/2024, para. 57, in conjunction with Art. 5 (2) GDPR

What belongs inside? The EDPB has a list, the AI Act has a list, and both largely overlap. Combined, this yields the file that should be present at the end of a training run.

The "dated and signed" for the test report is meant literally. A test report that only exists as output in a notebook does not satisfy this. This is a requirement for your toolchain, not a legal formality, and it can be automated.

6. Remeasure after the run, do not just monitor continuously

"Continuously monitor compliance" is in every guide and usually remains vague. One point is regularly overlooked: fine-tuning degrades the safety properties of the base model. Even when your training data is completely harmless.

A research group measured this. A single run, the settings recommended by the provider, an ordinary training dataset.

What the numbers mean: the model was presented with 330 intentionally harmful prompts. The percentage of prompts it answered fully in a harmful manner is shown. This was evaluated by an evaluation model on a scale of one to five, with only the highest level counted. For GPT-3.5 Turbo, this share almost sextupled.

The study also shows that, in particular, a learning rate that is too high and batch sizes that are too small further worsen the outcome. Thus, the choice of these settings becomes a risk that belongs in the training protocol from Step 5.

Two caveats apply. The tested models are from 2023 and are outdated. And the authors note themselves that the affected provider received the results in advance and may have improved them.

There are newer works confirming the finding, and at least one that relativizes it. These follow-up works are preprints without peer review. The basic finding is still too clear to dismiss as measurement noise.

In practice, this means: measure safety anew after every training run. Do not adopt it from the base model. How a resilient test set is created for this is explained in our Evals Guide.

Source: Qi et al., „Fine-tuning Aligned Language Models Compromises Safety, Even When Users Do Not Intend To!“, ICLR 2024

The special case: Your teacher model is a matter of contract

This point is in neither the GDPR nor the AI Act, yet it still stops projects.

Many teams have their training data generated or corrected by a large model. This is technically logical. Legally, you end up in contract law, not in regulatory law.

Anthropic, OpenAI, and Google forbid in their terms of use using their outputs to train competing models. This applies via any acquisition route, including Bedrock, Azure, and Vertex. OpenAI allows a narrowly defined exception for classifiers and embeddings that you do not share with third parties.

The terms of four major providers, ten European hosters, and over twenty open models were analyzed in full text for this. The result, including quotes, can be found in the article on distillation clauses of teacher models. Clarify the question before the first test run, not after.

What is currently changing and remains open until the end of October

Two drafts from the EDPB directly affect this topic: Guidelines on Anonymization, which are intended to replace Opinion 05/2014 of the Article 29 Data Protection Working Party, and Guidelines on Web Scraping of Data for Generative AI.

Both are in public consultation until October 30, 2026. They are therefore not yet an applicable standard, and it would be wrong to present them as such here. Two points are nevertheless relevant for planning today.

The Anonymization Guidelines follow three criteria: Is it possible to single out an individual dataset? Is it possible to link datasets together? Can anything be inferred about a person from them? Anyone aligning their anonymity assessment from Step 5 with these three questions is already working in the direction in which the standard is moving.

On web scraping, the EDPB clarifies: processing sensitive data is prohibited in principle, and it requires two things: a legal basis under Art. 6 and additionally an exception under Art. 9 (2). Anyone wishing to supplement training data from public sources should wait for the consultation or plan very carefully.

Source: EDPB, Guidelines 02/2026 (Anonymization) and 03/2026 (Web Scraping), adopted on 07.07.2026, Press release of 08.07.2026

A third event belongs here because it is still stated incorrectly in many texts. The Italian supervisory authority had imposed a fine of 15 million euros on OpenAI. A court in Rome overturned it on March 18, 2026, case number 4153/2026. A free full text of the ruling is not available, but the grounds for the judgment have been published since June 2026 and analyzed in Italian specialist literature.

The reason was jurisdiction. OpenAI has had a main establishment in Ireland since February 15, 2024. Therefore, the proceedings should have gone through the Irish authority, not the Italian one.

The court explicitly did not rule on the merits. The substantive allegations regarding the legal basis for training are therefore open, not settled. Anyone citing the case as a precedent for training violations is citing it incorrectly.

How we walk through this with you

The six steps are described so that your team can follow them itself. All sources are in this post.

If you do not want to do it yourself: we train and operate models on dedicated GPUs in EU data centers, without US hyperscalers in the chain. We sign the data processing agreement before the first dataset. Data and intermediate states are versioned and logged. The documentation is mapped to the obligations from GDPR, the AI Act, and DORA.

Weights, eval sets, and documentation belong to you, exportable at any time. And no model goes into production without an eval gate.

The first step is a conversation about your task and your database: 30 minutes, engineering is present, no sales pitch. If it turns out that your task can be solved without personal data, we will tell you in the call. That is also the technically simpler path. The legal assessment of your individual case remains with your legal department or your data protection officer; we provide the records for it. Schedule an appointment.

Frequently Asked Questions

Do I need consent to train on customer data?

Usually not. Most of the time, legitimate interest supports this if you pass the documented three-stage test. An exception applies if you originally collected the data with consent. Then the path via change of purpose is blocked, and you need new consent.

Is fine-tuning allowed under GDPR?

Yes, if a legal basis supports it. For legacy data, this is usually legitimate interest combined with the purpose compatibility assessment, both recorded in writing. Added to this is the question of whether the finished model still carries personal references. Fine-tuning is not prohibited.

Does fine-tuning make me a provider under the EU AI Act?

Not through fine-tuning as such. The decisive factor is whether you change the purpose such that a high-risk system is created. An extraction model for internal documents does not do this. A model for pre-screening applicants very much does. The computing effort plays no role.

Are my model weights personal data?

Possibly. There is no blanket anonymity; a case-by-case assessment is required. Two paths must be practically excluded: that someone extracts the data directly from the model and that the model reveals it in responses. Internal models are evaluated more leniently.

What happens in the event of a deletion request after training?

Individual weights cannot be deleted. The supervisor can order parts of the dataset to be deleted, and in the extreme case, the entire dataset or the model itself. Retraining is the remedy you can offer; the authority takes this into account for proportionality. Plan for that, not for surgical deletion.

Have the high-risk obligations been in force since August 2, 2026?

No, this has been outdated since the Digital Omnibus. Annex III applies from December 2, 2027, Annex I from August 2, 2028. The labeling obligation was not postponed: it has been in force since August 2, 2026, regardless of the risk class.

Can I use GPT or Claude to generate training data?

Not for a competing model. Anthropic, OpenAI, and Google forbid this contractually, via any acquisition route. OpenAI allows a narrow exception for classifiers and embeddings that you do not distribute. This is a contractual issue, not a data protection issue, and belongs before the first test run.

How high is the risk of a fine for a mid-sized company?

Significantly lower than the usual headline. The 35 million euros only apply to prohibited practices. For everything else, it is 15 million or 3 percent. For small and medium-sized enterprises, the lower of the two values applies, which is the percentage of their own turnover.

Sources

• EDPB, Opinion 28/2024 on data protection aspects in AI models (adopted on 17.12.2024): anonymity of the model, legitimate interest, documentation requirements

• EDPB, Drafts on Anonymization and Web Scraping (07.07.2026): consultation until 30.10.2026, not yet in force

• Regulation (EU) 2016/679 (GDPR), official version; Art. 6 also in a user-friendly format at gdpr-info.eu: legal bases and the purpose compatibility assessment in paragraph 4

• Regulation (EU) 2024/1689 (AI Act) and Regulation (EU) 2026/1744 (Digital Omnibus), official versions. The Omnibus Regulation was published in the Official Journal on 24.07.2026 and entered into force on 27.07.2026. The article references also use the user-friendly explorer artificialintelligenceact.eu

• HmbBfDI, Discussion Paper „Large Language Models and personal data“ (15.07.2024): the deviating Hamburg position on personal references in the model

• ECJ, Judgment of 04.07.2023, C-252/21 (Meta Platforms et al.): para. 89 on mixed datasets, para. 77 on "manifestly made public"

• Art. 25 AI Act and Art. 3 No. 23 AI Act: the three triggers of the provider role and the definition of substantial modification

• Art. 53 AI Act and Recital 109: obligations during modification and fine-tuning of a general-purpose AI model

• European Commission, Guidelines on the scope of the obligations of providers of general-purpose AI models, C(2025) 7719 final of 19.11.2025, para. 60 f.: the benchmark of one-third of the computing power. The earlier document C(2025) 5045 final of 18.07.2025 only approves the content, it is not the guideline itself

• Art. 10 AI Act and Annex IV: data governance and the content of technical documentation. Note that Art. 10 (5) was repealed as of 27.07.2026 and replaced by Art. 4a; many versions on the web have not yet been updated

• Art. 50 AI Act and Art. 99 AI Act: labeling obligations and the tiered fines including the rule for small and medium-sized enterprises

• CNIL, Recommendations on legitimate interest in AI development: national supervisory position on the legal basis

• LfDI Baden-Württemberg, Discussion Paper Legal bases in the use of AI: German supervisory perspective, Version 2.0 of 17.10.2024

• DSK, Guidance on AI and Data Protection: including notes on technical and organizational measures in the development and operation of AI systems (June 2025)

• Il Sole 24 Ore and ADVANT Nctm on the annulment of the Garante decision on 18.03.2026: secondary reports, the judgment itself is not publicly available

• Section 26 BDSG, BAG, Decision of 23.03.2021, 1 ABR 31/19 and ECJ, Judgment of 30.03.2023, C-34/21: employee data protection and co-determination, including the non-applicability of the BDSG general clause

• Qi et al., „Fine-tuning Aligned Language Models Compromises Safety, Even When Users Do Not Intend To!“ (ICLR 2024): safety degradation through harmless fine-tuning. The values come from Table 3 of the ICLR version

• The Evals Guide: building test sets, scorers, and statistical evaluation

As of September 21, 2026 · kontinent.ai. All sources were retrieved on September 16, 2026, and individually cross-checked on September 21, 2026. Paragraph numbers refer to the English version of EDPB Opinion 28/2024. The EDPB drafts of 07.07.2026 are in consultation until 30.10.2026 and are not an applicable standard. The measurement values of Qi et al. are from Table 3 of the ICLR version and refer to model generations of the year 2023. Contractual clauses of the model providers were verified in full text on 07.09.2026 and change frequently. The author is not a lawyer, and this article has not been reviewed by a lawyer. It does not replace legal advice.