Legal Issues for Data Professionals is a quarterly TDAN column published by DATAVERSITY.
A retailer packages its customer data and sells access for $500,000 a year. The product is defined the way most data products are defined: by the number of records and how often they refresh. The agreement says the buyer may use the data in the consumer packaged goods industry.
Months later, the buyer uses the data to train a model and sells access to the result. Nothing in the arrangement stopped it, because nothing in the arrangement ever said what the buyer was allowed to do. The product was described by what sits in the file. It was never described by what the file lets someone do.
That gap is where data monetization programs lose their value, and closing it is work that belongs to the data organization rather than to the legal department.
What a Data Product Actually Sells
A data buyer is not buying records. The buyer is buying the ability to make decisions they could not make before. Which shoppers to target. Which items to stock. Which price to set. Whether to train a model. Whether to build a segment and sell access to it. Whether to combine your data with another source and sell the combination.
Each of those has a different value. A buyer who wants to plan next season’s assortment is getting something much narrower than a buyer who wants to train a model that will still be running after the arrangement ends. When the product is described by record counts, those two buyers look identical and pay the same.
Decision Rights Licensing
I introduced decision rights licensing in this column in March 2025, in A New Data Licensing Model.
Decision rights licensing scopes a data license by the decisions the licensee is permitted to make with the data, rather than by the industry in which the licensee operates. Every decision not listed is not granted.
The usual approach is field of use, which names an industry, a territory or a customer type. Field of use describes where the buyer operates. It says nothing about what the buyer does. Two companies in the same industry can do entirely different things with the same file, and a field of use boundary cannot tell them apart.
Describing the product by permitted decisions does three things. One data set becomes several products at several prices, since a targeting and assortment product is not the same product as one that includes model training. You get a record of what has not been sold, which is what makes the next sale to a different buyer possible. And the uses that would otherwise travel along for free become things somebody has to ask for.
Build the Decision Inventory
The practical step comes before any commercial discussion.
List every decision your data supports, in the words the business already uses for those decisions. Mark which ones are in this deal and which are held back. Attach a value to each. Keep the list of what was not sold, because that list is the pipeline for the next buyer.
This inventory is not a legal document. It is a description of the product, and the data team is the only group that can write it, because nobody else knows what the data actually supports.
Make the Vocabulary Match
An agreement that permits analytics and a data catalog that calls the same activity segmentation are describing one thing in two languages. When a new job spins up, nobody on either side can say whether it is inside the scope or outside it.
The contract and the catalog have to use the same names for the same things. That sounds like a documentation exercise and it is not. It is what makes the commercial terms operable, and it is the difference between a scope people can follow and a scope people discover they broke.
A Limit Nobody Can Administer Is Worse Than None
The strongest objection to narrow scopes comes from the receiving side, and it is correct. A company taking in data must be able to live inside the boundary. A limit it cannot see, monitor, or enforce in its own environment creates risk without giving anyone control of it.
That objection sets the standard. Every permitted decision should map to something observable. A named workflow. A specific system or model. A documented use case with an owner. If a permitted decision cannot be tied to something a data team can point at, it is not a scope. It is a hope.
This cuts both ways, which is why receiving companies should want it too. Broad permissions feel like flexibility until a new team starts a use nobody cleared, and the company finds out later that it was outside the boundary all along. A narrow scope with a defined path to add new uses is easier to run than a broad one nobody has mapped.
Training Is Its Own Decision
Model training deserves separate treatment because it does not behave like other uses.
Most uses end when the arrangement ends. The data is returned or deleted and the receiving company is back where it started. Training does not work that way. Value moves out of the data and into a model, and the model keeps running after the data goes back, still carrying what it learned.
So, training belongs on the inventory as its own line, valued separately, with the exit terms settled at the start. What happens to the model, to anything derived from it, and to outputs already generated are questions to answer while both sides still want to work together.
What the Data Team Owns Here
None of this is legal drafting. It is product definition.
The decisions your data supports, the names those decisions carry in your systems, whether a given permitted use can actually be observed, and what a model retains after an arrangement ends are all questions the data organization answers. The agreement only records the answers.
Data monetization is not a decision to sell data. It is a decision about which decisions to sell.
Developing Data Products
Gain the knowledge and tools to design, build, and deploy impactful data products that drive business value and innovation.
