Training a shared AI model on customer data needs each customer's written approval

Your engineers want to train a suggestion model on a year of support threads from every customer account, and your DPA says you may use Customer Data "to improve our services", so everyone assumes you are covered. Under GDPR you are probably not. A model that serves all your customers is a purpose of your own, and whoever decides the purpose of processing is its controller, so for that training you stop being your customers' processor 1. France's data protection authority, the CNIL, says a vendor may reuse customer data like this only with each customer's written authorisation for that specific use, given after the customer has checked the use fits why it collected the data. The vendor then carries a controller's duties for it, including a legal basis of its own and informing the people whose data it is 3. Done without that, the EDPB, the board of all EU data protection authorities, says the vendor infringes GDPR and may be sanctioned 2.

Atlassian's DPA is a public, dated example of a contract that keeps the two uses apart. Since 17 August 2026, its Data Processing Addendum has one section for improving the products "for Customer only", and a second saying Atlassian "must de-identify and aggregate Customer Data" and may use the result "to improve the Cloud Products [...] generally". On the Free and Standard plans of Jira and Confluence, that second use includes the text people type, by default, according to Atlassian's data contribution page.

Why does training a shared model make you a controller?

Because a processor may act only on its customer's instructions, and Article 28(10) says a processor that breaks this rule by deciding the purposes and means of processing is treated as a controller for that processing 1. The EDPB gives an example in its guidelines on controllers and processors. A marketing supplier, named as a processor in its contract, starts using its client's customer database to develop its own business. Adding that purpose "converts" the supplier into a controller for those operations, and processing for that purpose would infringe GDPR 2.

For a SaaS product, the line runs between work done for one customer and work done for all of them:

• For that customer: fixing a bug the customer reported, building the search index for their workspace, tuning a model that serves only their account. These stay inside the service, so you stay their processor.
• For every customer: a shared model trained on many customers' content, or a benchmark built from their data. These serve your business, so you are a controller for them.

The buyer's side of the same rule is in my post on which vendors need a DPA.

Can a clause in your DPA authorise training on customer data?

Yes, on the CNIL's reading, if two conditions are both met: the new use is compatible with the purpose the customer collected the data for, and the customer authorises it in writing 3. That route is one national authority's position. The EDPB's guidelines are stricter on their face: a processor "may not carry out processing for its own purpose(s)" [2]. They reach a similar result by another path, though, since a company that receives data on the controller's instruction and uses it for its own purposes is a controller in its own right [2]. On both readings the customer decides first, in writing, and you then carry a controller's duties.

The compatibility check is the customer's job, done case by case. The CNIL points to the factors GDPR lists for it: the link between the original and the new purpose, the context in which the data was collected and the customer's relationship with its users, how sensitive the data is, the possible consequences for the people in it, and safeguards such as encryption or replacing names with codes 1 3. The customer also needs a legal basis for handing the data over, since the EDPB says every disclosure by a controller needs one 2. If the customer finds the new use incompatible, it must refuse. If it finds the use compatible, the CNIL says it is still free to agree or not 3.

Three consequences follow for the clause itself:

1. It has to describe the use, and the customer has to agree after reading the description. The CNIL says a prior, general authorisation to reuse data is not lawful, because the check has to be run for each specific use 3. A line in your onboarding template that lets you reuse data for whatever improvement you choose later is that general authorisation. The subject can be broad, since the CNIL's own example of a use that could pass is a provider improving its cloud services 3; what has to be specific is what the customer agrees to, such as "train the ranking model behind search on de-identified ticket titles".
2. The use has to be one a customer could find compatible. Improving your service with safeguards such as anonymisation could pass, while reusing the data for commercial prospecting would struggle to pass at all 3.
3. Once authorised, you are the controller of the new use. The CNIL says the processor becomes the controller of that new processing, and you stay the customer's processor for everything else 3.

What counts as written? The CNIL accepts electronic form 3. My recommendation is an admin switch for each use, off by default, that shows the description, asks the admin to confirm their company has checked the use, and records who turned it on and when. I would treat that record as the customer's written authorisation, provided your terms say which admin role can bind the customer. A default-on setting leaves you arguing that an admin who never opened the settings page agreed to something in writing, and I would not want to make that argument. I would also offer the switch on every plan: the CNIL does not require that, but a customer whose check fails is obliged to refuse, and without a switch its only way to refuse is to leave.

Does de-identifying the data first keep training outside GDPR?

Only the result can be outside GDPR. Stripping identifiers from customer data is itself processing of personal data, and the EDPB's draft guidelines on anonymisation, version 1.0 from July 2026, say it needs a legal basis 4. When you do it for your own cross-customer purpose, my reading is that the basis has to be yours, since the draft presumes the earlier basis carries over where the anonymisation is part of the same processing activity and serves the same purposes 4.

The draft sets three tests for anonymous data, which it calls no record isolation, no linkage and no inference: nobody's record can be picked out, connected to other data about them, or used to deduce something about them. Data that meets all three may be regarded as anonymous, and data that fails one needs further analysis 4.

As a data scientist, my view is that free text is the hardest kind of data to pass them with. Removing names and email addresses from a ticket comment still leaves "the outage the new backend hire caused on Friday", which everyone at that company can resolve to one person. I covered what "anonymised" means under these guidelines when the draft came out.

The model is a separate question. The EDPB's opinion on AI models says a model trained on personal data is anonymous only if the chance of extracting that data from it, or of getting it out through queries, is insignificant 5. A model that can be prompted into repeating a training ticket fails that.

What do you owe once you are the controller for training?

The same duties as for any processing you decide on yourself. The CNIL lists them 3:

• a specific purpose, and a legal basis for it;
• telling the people whose data it is what you do with it, which on my reading of Article 14(4) means before the training starts, unless an exception applies or the customer has already told them 1 3;
• a retention period, and no more data than the purpose needs;
• a way for those people to exercise their rights;
• security measures for the new processing.

You will most likely rely on legitimate interest as your legal basis, because you cannot easily ask your customers' users for consent. My guess is that it holds only with strong safeguards: someone typing a comment into their employer's ticket tracker does not expect it to train a product sold to other companies, and the EDPB's opinion on AI models makes those expectations part of the test 5. Legitimate interest also gives those people a right to object.

Do not plan on skipping that duty because it is a lot of work. GDPR's exception for disproportionate effort names archiving, research and statistics in particular, guidelines the EDPB has endorsed say it should not be routinely relied on outside those purposes, and where it does apply you still have to make the information public 1 6. In principle the customer tells its users, which the CNIL treats as the default, or hands you the task where you already hold their contact details 3. So the clause has to give the customer text it can show its users, and your own privacy policy describes the training use too.

What should a SaaS vendor change before training on customer data?

If you sell a B2B product and want to train on what customers put into it, make these changes first:

• Split the clause. Keep "improve the service for this customer" in the processor part of your DPA, and move every use for all customers into a separate clause that names it.
• Name each use. "Train the model behind feature X on de-identified ticket text" is something a customer can check. A blanket "improve our services", agreed at signup for whatever comes later, is not.
• Ship each use as an admin switch, off by default, on every plan. I would treat the record of who switched it on, and when, as the customer's written authorisation.
• Give the customer what its check needs. Describe the data used, the safeguards and the retention, and supply text it can show its users.
• Publish your side. Your privacy policy, as a controller, describes the training use, its legal basis and how people exercise their rights.
• Keep the anonymisation records. The EDPB's July 2026 draft expects the method and the test results to be documented and kept 4.
• If you already train under a broad clause, ask existing customers to turn the new switch on, and leave data from those who do not out of the next training run. As a first check, which falls short of proving anonymity, prompt your model with the opening words of real tickets and see whether it completes them; if it does, retrain on data you are authorised to use. The new clause covers future training only, and the training already done stays open to regulator action 5.

These clauses usually go out of date in code before anyone edits the contract: an engineer adds a job that copies customer content into a training set, and the DPA still says what it said at signing. Lawcel, the compliance platform my co-founder and I built, reads pull requests and flags a change for review when the code stops matching what your DPA or privacy policy says, naming the documents it affects. Whichever way you catch it, catch it before the first training run.