How buyers judge a sample of company records
When a company is talking about licensing support tickets, work orders, mail, chat, or similar operating history to an AI developer, someone will eventually ask for a sample. That request is reasonable. A sample is also a delivery of real records, even when it is small. It should come after a written description of the archive, not instead of one.
This page is about what a careful buyer is usually trying to learn from that sample, and what makes a sample useful rather than merely large. It is not a scoring rubric, and it is not legal advice.
They are not mainly counting rows
Volume matters later. In a first sample, buyers are usually testing three things: whether the records match the description they were given, whether a record is complete enough to learn from, and whether they can work with the residual risk that remains after obvious identifiers are reduced. A file with a hundred thousand thin rows can fail all three tests. A few hundred complete, honestly chosen records can pass them.
Completeness is about the chain of work, not the number of fields. A ticket with no resolution, a work order with no findings, or a thread that stops before the outcome is a weak lesson. Representativeness is about whether the slice looks like the archive you claimed to have. A sample drawn only from the cleanest month, only from one product line, or only from jobs that went well will look better than the history a model would actually see. Error and gap rate is about missing attachments, broken threads, inconsistent labels, and fields whose names do not match what they contain.
Buyers also look for content that should not have been in the sample at all: live credentials, payment data, children's data, or direct identifiers that a stated reduction step was supposed to remove. Finding those does not only lower the quality score. It raises a trust problem that a larger second sample will not fix.
Why intended use changes the test
A sample meant to preview a training corpus is judged on coverage and on whether the records still teach the task once identifiers are reduced. A sample meant for evaluation is judged on whether it can serve as a held-out test: is it independent enough, is it labeled clearly enough, and does it represent the cases the buyer actually wants to measure? Origin's short entry on an evaluation dataset and its guide to licensing data for AI evaluation draw that distinction in more detail. The brief and the sample plan should say which job the sample is being asked to do.
What a high-risk AI provider is required to check
Not every buyer is building a high-risk AI system under EU law, and this page does not assume that yours is. The standard is still a useful window into what careful technical diligence looks like. Article 10 of Regulation (EU) 2024/1689, the EU Artificial Intelligence Act, requires providers of high-risk AI systems that train models to use training, validation, and testing data sets that are "relevant, sufficiently representative, and to the best extent possible, free of errors and complete in view of the intended purpose." The same article requires governance practices that cover, among other things, the origin of the data, the original purpose of collection when the data are personal, preparation steps such as annotation and cleaning, the assumptions about what the data are supposed to measure, and the identification of gaps. The official text is in Regulation (EU) 2024/1689.
Those duties sit on the provider of the high-risk system, not automatically on every company that might license its records. They still explain the questions a serious buyer will bring to your sample: is this relevant to the intended use, is it representative, how complete and how noisy is it, and can you document where it came from and what was done to it?
Agree the specification before you prepare the files
The ICO's guidance on data sharing agreements says the parties should set out the types of data they intend to share, sometimes called a data specification, and that in some cases it is appropriate to share only certain information from a file, omitting other, more sensitive material. A sample should follow a written specification of that kind: the record types, the date window, the approximate size, the reduction steps, and what will be excluded. An open-ended request for "a few thousand tickets" is not a specification.
Do this work from a description first. Origin Data Partners' fit check starts without file uploads and without system access. If there is a fit, Origin organizes a licensing brief and introduces a buyer. Your company approves what is shared, negotiates, and signs directly. A sample, if one is needed, comes after that scope exists, not before it.