
The undefined word ‘derived’ shows up in a lot of our AI contracts. It’s familiar, and most of us read it and keep going. We have an idea of what we think the plain language means.
What we don’t dwell on is that the plain language meaning is vague and imprecise. The courts and practitioners don’t have a uniform approach to what it means. What counts as derived? When we say derived data, what source are we talking about? And what time frame do we mean? We don’t know or haven’t taken time to nail down these details, so we leave it loose.
We accept lots of vague terms in our AI contracts, not just this one. We are in the early stages of AI product contracting. Plus, the technology itself keeps moving and what AI products do is still evolving. So derived data ends up being like human-in-the-loop and system data. The vagueness feels like the price of getting a deal done.
Two recent webinars highlighted that risk.
In a recent session on AI confidentiality provisions, Shannon Yavorsky pointed to one carve-out for derived data. She shared that using this term without restrictions and without time limits is worrying. This is the path by which information can surface elsewhere. The vendor can label the data aggregated or derived and move it outside the clause.
Matt Kohel had concerns based on the ownership side during a session on AI data use provisions, noting that it makes his intellectual property (IP) spidey sense start tingling. If the “derived data” was created using IP that meets the criteria of a trade secret, that derived data may be a trade secret as well. "AI models don’t just learn from the data you submit, but even learn from patterns of data as well."
The other problem with ‘derived’ as a term of art is its similarity to ‘derivative works,’ a definition from the US Copyright Act that also appears in contract licenses and assignments. ‘Derived’ sounds a lot like derivative works, so the risk is that people confuse them and use them in imprecise, incorrect ways.
All of this raises a question we should be asking. Yes, we have adopted some contractual vagueness because the concepts are evolving. But is that an acceptable reason to still use a vague concept and not shift our contracts to a more precise defined term? Is that still serving us, or is it time to say what we mean?
I’m in the camp that thinks it is time to define “derived” so that we go into our AI product contracts with clarity and precision. Let’s stop using this loose word to protect us in a risky world.





