"Training" - Matt highlighted how training is not a defined term. It could include training, retraining, and fine-tuning. Just saying “training” also doesn’t address how the vendor can or can't use the data. Matt mentioned that you may sometimes see the word “improve” instead of or in addition to training. While those two terms have an overlap, they aren’t synonyms. "Improve" is the broader term. Kate confirmed, referring to “training” is a "big tent.” She urged the audience not to rely on the buzzword. Instead, make sure the contract provision describes specifically what the vendor is doing.

"Use of the services to improve Vendor's models and algorithms" - Kate explained how this language should also get the same layer-by-layer treatment as the training restriction. Whether that happens in the definitions section or a separate provision varies by company. The other problem with this language is the implied inverse restriction, namely that the vendor will not use the data in other ways. Kate highlighted that this claim, like similar broad promises, are nearly impossible to prove in an audit. If someone digs hard enough, they'll find a way to retrieve data claimed to be anonymized.

"Except that" - Matt reminded everyone how important the exception is. He would add exceptions to the exceptions. The vendor may use aggregated or anonymized data for a stated purpose, but never to identify the customer or its users. That kind of language provides a path forward if the vendor won't make changes to the base language.

"Its artificial intelligence or machine learning model" - Matt highlighted that this language is much too narrow. Really it should be "any" AI or ML model, including third-party ones. Kate then talked about the real world reality of underlying systems. She said that most vendors license a foundation model rather than own one (Anthropic and Amazon Bedrock for example). And then that underlying model can get swapped out over time. The question is whether the language permits "enhancing ChatGPT with its own data,” Kate's phrase for the when you allow your data to improve a third-party model with which you have no relationship.

The vendor’s technology layers - Kate highlighted a huge issue that’s often overlooked. That is that AI and ML models are just one part of a system. We need to be looking at how those models are layered with the vendor’s own technology or other third-party systems. Kate would split provision’s language around third-party AI models from the vendor's own technology. Treat vendor's own tech and third-party tech the way you'd separate a vendor's own IP from third-party IP. You likely want the vendor's own product to keep improving. Customers need to be asking if it is a RAG layered on a third-party model, whether the data feeds back to that model, and whether multiple models are chained together. We also need to figure out if its training the layer on top, or the underlying model? Do you have clear rights over that layer? Know your own product before you negotiate.

"Anonymized" - Kate pointed out using this term creates a huge risk on both sides. There is no clear legal definition across jurisdictions. GDPR ties this concept to re-identification risk. As Kate explained, AI can now re-identify in minutes what used to take years. Instead of an undefined “anonymized,” pick a specific standard, possibly NIST generally or HIPAA for health data, and reference it directly. You also can address specific techniques like differential privacy or hashing are options.

"Derived from" - Matt pointed out the issues with “derived from” in model training provisions. He highlighted how this phrase is not the IP-doctrine idea of "derivative works." It is closer to non-public proprietary information and trade secrets. An AI note-taker in an R&D meeting surfaces analysis and insights derived from the conversation, not just a transcript. Information derived that way can meet the legal standard for a trade secret.

“Customer’s use of the system” - Matt also focused on the output data that is derived from use of the system. He explained that AI models learn from patterns in the data, not only the data you submit. Data given away through this language way could end up training something whose output surfaces the information elsewhere. If the vendor can derive data from the output, that means it can use insights, innovations, or analyses being paid for. If the contract defines "output," that definition should include derived information. Customers need to ask the vendor directly what aggregated or anonymized data it wants, why, and how it improves the services.