Can a company license a labeled table of data to AI developers?
Some of the most useful data a company holds is not text. It is a table where each row is a case and one column says what happened: whether a customer left, whether a claim was paid, which category a ticket landed in. That result column is what lets a model learn from the rest. Whether the table can be licensed depends on where it came from and whether it contains people.
What a licensable labeled table looks like
| A row for each case | One customer, one job, one claim or one transaction per row, with the same columns every time. |
| A column that says what happened | The outcome the table exists to predict, such as paid, churned, repaired or approved. Without it, the table is a list. |
| A few clear input columns | Facts known before the outcome: size, type, date, region. A handful of meaningful columns beats hundreds of vague ones. |
| A record of where it came from | Which system produced it, over what years, and what rules created the outcome label. This is the provenance a reviewer asks for first. |
| A data dictionary | A page that says what every column means and how blanks should be read. Cheap to write, and often the difference between usable and unusable. |
The label has to be trustworthy
A model learns whatever the label says, so a sloppy label teaches the wrong thing. A flag entered by hand and sometimes forgotten is weaker than one produced by a rule or a system event. Say how the outcome was recorded, who recorded it and how often it was wrong or missing.
Personal data is where most tables fail
A table of customers or patients carries identifiers by default: names, addresses, birth dates, account numbers. The identifiers come out first. The harder step is the combinations, because a rare postal code, a date of birth and a job title can point to one person even with the name removed, which is why people review the cleaned table as well as the tools.
Public and purchased data does not count
A table built from public sources, or bought from another company, is not yours to license, and its value is low because anyone can find it. A table made from your own operations, with your own labels, is the kind that is hard to find elsewhere.
What stays out of a labeled table
| Direct identifiers | Names, contact details, account and government numbers are removed before anyone outside the company sees a row. |
| Rows whose label is unreliable | Periods where the outcome was entered inconsistently, or the rules changed, are dropped or marked. |
| Tables built from other people’s data | Anything compiled from a customer’s data, a purchased list or a public source you do not own stays out. |
| Sensitive categories | Columns on health, finances, ethnicity or similar topics need their own legal review and are often removed. |
An example, invented for illustration
A field-repair company with 45 staff has a table of 80,000 completed jobs with the type of equipment, the age of the unit, the region, the first diagnosis and whether the first repair held. The label, repaired the first time or not, comes from a system flag that has been in place for six years. The company writes a one-page data dictionary, removes addresses and customer names, rounds the dates to the month, and shows a sample of rows for the owner’s approval.
Questions owners ask about this
How many rows do we need?
There is no fixed number, and it depends on how many columns there are and how varied the cases are. Say how many you have, over what years, and how the outcome was recorded.
Can we license several tables from the same source?
Yes. Several tables from one system share the same provenance, which can make them easier to review and more useful together.
Do we need to explain every column?
Yes. A data dictionary is the cheapest thing you can add, and tables without one are slower to review and often set aside.
What if the table includes some people in Europe?
Then the privacy rules there apply to those rows. The tables are cleaned and reviewed with that in mind, and counsel confirms which rules apply.
Didn't find your question? Ask us directly.
Keep reading
Related kinds of records
- Support tickets: The whole thread, wrong guesses included, with customers replaced by stand-ins.
- Accounting and ERP records: Invoices, approvals and memos from QuickBooks, Xero, Sage, NetSuite, SAP and Odoo; payroll and bank details never.
- Claims and underwriting files: A risk decision, its reasons and what happened next, with every policyholder removed first.
Industries that keep these records
- Insurance agencies: A quote, a renewal and a claim follow-up in the agency’s own words, with customers and carrier files kept out.