A learning technologist is rolling out an AI tutor to 8,000 employees when a single line in the data-processing addendum stops her cold. It reads: "Customer data may be used to improve and train our models." Eight thousand people are about to type their performance gaps, their wrong answers, their honest questions about a harassment policy into a tool that will fold those keystrokes into someone else's product. Nobody decided that. Nobody consented to it. It was the default, buried in a clause, and it was one signature away from being true. That clause, and whether it applies to your people, is the entire subject of this lesson.

The Clause Nobody Reads Decides Everything

The feature comparison gets all the attention. The data-processing clause decides the outcome. When you put a learning-AI tool in front of your workforce, every interaction generates data: what a learner asked, what they got wrong, how long they hesitated, what they typed into a free-text reflection about a sensitive policy. The question that governs all of it is deceptively simple. Does that data stay yours, used only to give your people the service, or does it become raw material the vendor uses to train and improve the model they sell to everyone else?

Let me define the term that anchors this lesson. Model training, in this context, means the vendor uses the data your learners generate to adjust the AI model itself, so that what your people produce improves a product the vendor offers to other customers, possibly your competitors. Why you care: a model trained on your learner data can, in principle, leak patterns from that data, and even when it cannot, you have handed a third party a license to profit from your workforce's behavior without the workforce ever knowing. This is not a hypothetical edge case. It is the default in many contracts, and the default is the thing that ships when nobody intervenes.

The reason this lands on L&D rather than purely on legal is that L&D is the data controller's representative for the most sensitive learning interactions in the company. Legal can read the clause. Only the learning professional knows that the harassment-policy module collects disclosures, that the DEI reflection captures protected-characteristic signals, that the performance-support tool logs exactly where each employee is weak. The sensitivity of learner data is a learning judgment, and the consent it requires is a learning responsibility.

Your people did not consent to becoming training data for a product they will never use. If the default clause says they did, the default is the breach.

Why Learner Data Is More Sensitive Than It Looks

It is tempting to treat learning data as low-stakes. It is course completions and quiz scores, not bank details. That framing is wrong, and dangerously so, because of what modern learning AI actually collects. An AI tutor in a compliance course does not just record a score. It records the conversation: the employee who asked, in their own words, whether a gift from a supplier crosses the line, the manager who admitted uncertainty about a harassment-reporting obligation, the new hire who revealed a gap in understanding a safety procedure. That is a behavioral and sometimes psychological record of individuals, tied to their identity, on regulated and sensitive topics.

Now layer the categories. A DEI module may capture data that touches protected characteristics. A wellbeing or mental-health training may capture data that is, in some jurisdictions, special-category personal data with heightened protection. A performance-support assistant logs a precise map of every employee's competency gaps, which is exactly the data a manager could misuse and a learner would never want surfaced. The point is not that all learning data is special-category, but that learning data routinely contains far more sensitive signal than the "scores and completions" framing admits, and the model-training question multiplies whatever sensitivity is there by sending it somewhere you no longer control.

The Consent That This Requires

This is where GDPR-style thinking becomes a practical tool, not a compliance abstraction. Under a GDPR-style regime, processing personal data requires a lawful basis, the use must be limited to the purpose the data was collected for (purpose limitation), and individuals have rights over their data. Why you care: collecting a learner's question to teach them is one purpose; using that question to train a vendor's commercial model is a different purpose, and a different purpose generally requires a different and explicit basis. You cannot quietly repurpose data collected to help an employee learn into data that improves a product, and call the original click-through consent good enough.

The practical consequence is that the model-training use is almost never something you can default your way into. It needs to be surfaced, decided, and where required, consented to, transparently. The honest position for most learning deployments is the simplest one: learner data is used to provide the learning service to the learner and the organization, and it is not used to train the vendor's models. That is the clause to seek, and the opt-out, ideally the off-by-default, is the mechanism that delivers it.

The Data-Processing Terms That Actually Matter

Contracts are long; the part that decides the model-training question is short. Here is the map of the terms that matter, what the risky version says, and what the defensible version says.

The single most decisive line is the model-training term, and the single most important property of it is the default. A clause that says "you may opt out of model training" sounds reassuring, but if the opt-out is buried in an admin setting and on by default, then the moment of deployment is the moment your data starts training the model, and most organizations never find the switch. The defensible posture is off by default, in writing, so that the safe state is the one you get without heroics. The opt-out you have to discover and enable is not protection. It is a trap with a label that says "we offered you a choice."

A Worked Example: The Tutor and the Clause

Return to the AI tutor and the 8,000 employees, and watch two ways the rollout goes.

Before (the default clause ships). The procurement focused on the tutor's quality, which was genuinely excellent. The data-processing addendum, eleven pages in, said customer data "may be used to improve and train our models," with an opt-out available in a settings panel nobody opened. The tool launched. For three months, every honest question employees typed about the harassment policy, every admitted gap, every wrong answer in the DEI module flowed into the vendor's training pipeline. Then a works council asked a simple question: is our staff's training data being used to build the vendor's product? The honest answer was yes, by default, without consent, including special-category-adjacent disclosures. The remediation was expensive, the trust damage was worse, and the sentence "nobody decided that" was the whole problem.

After (the clause is read and rewritten). The same tutor, the same quality, but the L&D strategist treated the data clause as a gate. She flagged the model-training line, required it rewritten to "customer data is not used to train or improve vendor models," and made the opt-out off by default in writing. She named the sensitive modules, harassment, DEI, wellbeing, and got explicit handling terms for them. She confirmed the processing region and the deletion-on-termination clause. When the works council asked the same question months later, the answer was a documented no, here is the clause, here is the default state, here is what happens to the data at exit. Same tool, same learners, completely different exposure, because one person read the clause that decides everything and refused to let the default ship.

The lesson is not that AI tutors are dangerous to deploy. It is that the value of the tutor was never the thing at risk. The thing at risk was 8,000 people's sensitive learning data, and it was protected or lost in a single clause that took ten minutes to read and a negotiation to fix. The learning professional was the only person in the room who understood how sensitive that data really was, which is exactly why the decision could not be left to default.

The Two Harms, and Why Anonymization Does Not Save You

It helps to separate the two distinct harms hiding inside the model-training question, because vendors often answer one to distract from the other. The first harm is leakage: data your learners generate can, in principle, resurface in the model's outputs to other customers, so a phrase from your proprietary policy or a pattern from your employees' mistakes could appear in a competitor's session. The second harm is licensing: even if nothing ever leaks, you have handed a third party the right to profit from your workforce's behavior, building a better product on the backs of your people, without their knowledge. The first harm is a probability; the second is a certainty the moment the clause is signed. A defensible posture has to close both, and a vendor who reassures you only about leakage has left the licensing harm entirely intact.

This is also why "we anonymize the training data" is not the answer it sounds like. Anonymization is genuinely hard for the kind of data a learning AI collects: free-text reflections, conversational questions, and competency-gap maps are rich enough that re-identification is a real risk, and a confident anonymization claim is itself a claim to verify, not to repeat. But even where anonymization works perfectly, it does not resolve purpose limitation. The data was collected to teach an employee; using it to train a commercial model is a different purpose regardless of whether a name is attached, so anonymization addresses one risk (re-identification) while leaving the purpose problem untouched. The clean answer is still the simple one: the data is not used to train the vendor's models at all, anonymized or not.

Anonymization answers the wrong question. The question is not "can they hide whose data it is," it is "did your people agree their learning would build a product they will never use." For most learning deployments, the only clean answer is that it does not.

Making the Clause a Gate, Not an Afterthought

The structural fix for everything above is to stop treating the data-processing terms as a legal formality reviewed after the tool is chosen, and start treating them as a gate the tool must pass before it can be deployed at all. The difference is decisive. As an afterthought, the clause is read once the decision is emotionally made, the team wants the tool, and the risky default ships because nobody wants to be the person who killed the rollout over fine print. As a gate, the clause is read first, the unacceptable terms are surfaced before anyone falls in love with the demo, and the negotiation happens while you still have the leverage of a buyer who has not yet committed.

The gate has a fixed checklist, and any unmet item blocks deployment rather than triggering a shrug. The processing purpose must be scoped to serving you, with model improvement excluded. Model training must be off by default, in writing, not an opt-out you have to find. Sub-processors must be named, with notice of changes and the same terms flowing down, so the protection cannot be quietly routed around. The processing region must satisfy your strictest applicable residency obligation. Retention must be bounded, with return and deletion at termination and deletion on request for individuals. And the sensitive modules, harassment, DEI, wellbeing, must be named explicitly so their data gets the heightened handling it requires. Run this as a gate and the safe state is the one you reach by default; run it as an afterthought and the breach is the one you reach by default, because the contract's risky terms take effect the moment no one stops them.

For a multinational deployment the gate gains one more dimension. Different jurisdictions impose different rules, and the responsible posture is to design to the strictest applicable standard rather than the most permissive, because a single tool serving employees across regions cannot quietly apply weaker protection to the people whose laws allow it. Processing location and purpose are separate requirements: a compliant region does not cure a model-training use, and a no-training clause does not cure an out-of-region default, so both must clear the gate independently. The learning professional does not have to be a lawyer to run this gate. They have to know which modules are sensitive, insist the terms are read before the tool is loved, and refuse to let the default ship.

The Questions to Ask Before Any Rollout

• Does our data train your model? Get a yes or no in writing, and require the answer to be no for sensitive learning content.
• Is the opt-out on or off by default? Off by default is protection; on by default with a hidden switch is a trap.
• What purpose are you processing for? Reject "and improve our services" as a smuggled training license.
• Where is the data processed, and who are the sub-processors? Confirm it meets your residency obligation and the terms flow down.
• What happens at termination? Require return and deletion, not indefinite retention.
• How is special-category and disclosure data handled? Name your harassment, DEI, and wellbeing modules explicitly.

Key Takeaways

• The feature comparison gets the attention, but a single data-processing clause decides whether your learners' data stays yours or becomes training material for a vendor's commercial model.
• Model training means the vendor uses your learners' data to improve a product sold to others; in many contracts it is the default, and the default ships when nobody intervenes.
• Learner data is more sensitive than "scores and completions" admits: AI tutors capture conversations, disclosures, and a precise map of every employee's competency gaps on regulated and sensitive topics.
• DEI, wellbeing, and disclosure modules can capture special-category or protected-characteristic data, multiplying the stakes of sending it anywhere you no longer control.
• Purpose limitation means data collected to teach a learner cannot be quietly repurposed to train a vendor's model; the new purpose generally needs an explicit, separate basis, not click-through consent.
• The decisive term is model training and its decisive property is the default: off by default in writing is protection, while an opt-out you must discover and enable is a trap with a friendly label.
• The defensible posture for most learning deployments is the simplest: data serves the learner and the organization and is not used to train vendor models, with defined location, retention, and deletion.
• L&D owns this because only the learning professional knows how sensitive the data really is; the iron rule holds, AI assists, the human verifies the clause, and "we didn't read it" is never a defense to a works council or a regulator.