A buyer's checklist for licensed company data

Company data is becoming a regular input for teams training and evaluating agents. As more of it comes onto the market, the differences between sources matter more. Two datasets can look similar in a pitch deck and turn out very differently once you ask where they came from, how they were anonymized and whether they will actually teach a model anything.

This checklist is for data-acquisition, research and evaluation teams weighing a source of licensed company data. It is organized around the questions that tend to surface problems early. Not every item will matter equally for every project, but a supplier who cannot answer most of them clearly is telling you something.

Start with where the data came from and who agreed to license it. A dataset is only as clean as the chain of consent behind it, and that chain is increasingly something buyers are asked to document. We covered the broader trend in data provenance is becoming a buying requirement.

• Was the licence signed by someone with authority over company assets, such as an officer, director, liquidator or assignee?
• For winding-down or closed companies, was an authority document collected before any data moved?
• Did payment go to the company entity rather than an individual?
• Are the seller's scope and exclusions written down and annexed to the contract?
• Can the supplier say how each company was sourced, and whether the brief shaped the mix?

This is general information, not legal advice; the right contractual protections depend on your situation, and your counsel should review any licence before you sign.

"Anonymized" can mean very different things. Ask for specifics, and ask to see examples.

Check whether identifiers are tokenized consistently across every tool. If the same person becomes PERSON_014 in Slack but a different token in Jira, cross-tool trajectories fall apart. Check what is removed outright rather than tokenized: credentials, API keys, card numbers and government IDs should not survive in any form. Ask how images and PDFs are handled, specifically faces, logos and signatures.

Ask about default exclusions. HR, payroll, medical and legally privileged material should be out by default, and direct messages should be included only when the company chose to include them and had the right to. Ask who touched raw data during processing; a pipeline where no third party handles raw data is simpler to reason about. Finally, ask what happens to the raw archive afterward. A contractual deletion obligation, with a certificate, is a meaningful commitment. Ours is deletion within 30 days of seller sign-off.

The terms of the licence shape what your team can do and what risk it carries. Look for clear answers on:

• Permitted use, such as training and evaluation, and whether anything beyond that is allowed
• A prohibition on marketing to, profiling, contacting or re-identifying anyone in the data
• Restrictions on onward transfer, including that the data is never resold for marketing or people search
• How the seller's exclusions are documented and enforced

Restrictive terms can look like a cost to the buyer. In practice they are part of what makes a source defensible. A dataset that could legally be used for people search is a dataset you would have to explain later. More on structuring these terms in what a training-only licence should include.

A clean dataset that does not reflect real work is still a poor buy. Quality for agent training is mostly about structure, not size.

Ask how many systems each company contributes and whether the same project can be followed across them: email to ticket to chat to pull request to CRM. Ask how many years of continuous history are included, and whether there are gaps from tool migrations or lapsed subscriptions. Ask about headcount, since more active people means more varied work. Ask how thread structure, timestamps and cross-references are preserved in delivery, because flattening a Slack export into plain text throws away much of its value.

Look at the sector and size mix as a whole, not only company by company. A dataset dominated by one kind of business, such as early-stage software startups, may teach patterns that do not transfer to logistics, healthcare services or finance teams. If your agents need to work across industries, the supply should reflect that.

Ask for a sample, and test it the way you will use it. Try to reconstruct a few long-horizon tasks end to end. If you cannot, the dataset may not support the environments or evaluations you have in mind. Our post on how AI labs evaluate a new data source goes further into that process.

The last question is whether the supply matches what your team actually needs. Inbound sources tend to reflect whoever chose to come forward, which can skew toward particular sectors, sizes or stages.

A sourcing brief flips that. You specify sector, headcount, tool stack, years of history, regions and operating versus winding down, and the supplier goes out and finds companies that fit. Martal Group brings 17 years of B2B outbound and more than 200 onshore reps across the US, Canada, the EU and LATAM to that work. We build target lists from company and technographic data, our reps call the people who can sign, and data is evaluated, anonymized and delivered on a rolling basis.

If you are working through a checklist like this one, we are happy to answer each item for our own pipeline, and the trust page covers much of it in writing. To start a conversation about supply, send us a sourcing brief.