What an AI lab checks before it buys your data: the due diligence questions

Before an AI data buyer pays, its counsel checks six things: that someone with authority can sign and that the company holds the rights to what it licenses, where each record came from and under what terms it was collected, whether the people in it consented or have been removed from it, whether the same data was licensed to anyone before, how the data left each software system, and whether what is delivered matches what was described. These are not courtesy questions. Turing buys only from someone with admin authority. Mercor's intake asks whether you have the legal right to license the data for commercial use and AI training. Defined.ai requires proper consent, documentation and the right to commercialise the data for AI training. micro1 has the holder promise it has not already licensed the same data on the same or similar terms to anyone else. And our rights checklist, built from what buyers' counsel ask, holds 27 questions, 16 of which stop a sale until they are settled, one of them being simply how the data left each software system.

What happens when a statement proves wrong is written into the buyers' own terms. Under micro1's master terms, if the data manifest the holder wrote turns out to be materially inaccurate, nothing is payable and the holder refunds what was paid, even after micro1 accepted the data. Kled requires a contributor to refund what it was paid for content whose consent is withdrawn. pre.dev may take back its share from later payouts when a buyer's payment is refunded or clawed back. SimpleClosure's terms make the company cover its losses and legal costs from a breach of its warranties about the assets. So diligence is the cheap moment to find a problem. Every answer a holder gives becomes a warranty in the licence, and every warranty that proves wrong costs money after the sale, not before it.

This guide is for the founder, CFO or counsel of a company that holds records or code (the holder) and is preparing for an AI data buyer's diligence. It takes each area as the questions a buyer's counsel asks, the evidence that answers each one and the clause of the licence it feeds; then the red flags that stop a sale outright, a checklist for the diligence pack, and how a sale AIData.Broker runs prepares that pack before any buyer sees the lot. Each buyer statement links to the record that holds the buyer's own words and the day they were read. The whole selling process is in how to sell company data to AI labs; the practical export and cleaning work is in how to prepare company data for sale, and the licence itself, clause by clause, in what a data licensing agreement is.

This guide is research from public sources, not legal advice.

Contents

1. At a glance: six areas, the evidence and the clause each feeds
2. Who can sign, and does the company hold the rights?
3. Where did each record come from, and how did it leave the system?
4. Under what terms was it collected?
5. Consent and personal data
6. Earlier licences, exclusivity and vendors that already trained
7. Quality against the description
8. What happens if a statement proves wrong
9. Red flags that stop a sale
10. The diligence pack: a checklist
11. How a sale through us prepares it
12. Questions people ask
13. What this means for you

1. At a glance: six areas, the evidence and the clause each feeds

A buyer's diligence on a data licence is narrower than diligence on buying a company, but it goes deeper into one thing: the right to use each record for training. The reason is practical. A model trained on data of uncertain origin cannot be untrained, and the courts have started to sort training data by where it came from: in Bartz v. Anthropic a federal judge held that training on books was fair use but sent the pirated library copies to trial, and the case then settled with final approval in July 2026. Regulation points the same way. The EU AI Act requires a provider of a general-purpose model to publish a sufficiently detailed summary about the content used for training, and its technical documentation must cover the type and provenance of data and how it was obtained. California requires developers to post the sources of the datasets they trained on. A buyer can only answer those questions about its model if the holder can answer them about its data, which is why our guide to training data provenance calls provenance the record that makes claims about data checkable.

The table sets out the six areas this guide covers, what the buyer is trying to establish in each, the evidence that answers it, and the term of the licence the answer becomes. The terms in the last column are those in our licence terms register, which holds 15 terms a data licence turns on, each with its public evidence.

Two things follow from the table. First, most of the evidence is documents a company already has: its board minutes, its customer contracts, its old privacy policies, its admin consoles. Diligence rarely asks for something that does not exist; it asks for things nobody has gathered in one place. Second, every answer becomes a promise. A buyer's counsel does not ask questions out of curiosity: each answer is copied into a warranty, a representation or a schedule, and the remedies in section 8 attach to it. The safest diligence answer is the one a holder can prove from a document it can hand over.

2. Who can sign, and does the company hold the rights?

This is where every buyer starts, because a licence signed by someone without authority, or granted by an entity that never held the data, is worth nothing to the buyer whatever the data is.

The questions counsel asks

1. Which legal entity collected the data, and is that the entity licensing it? Our checklist puts it as does the company selling the data own it, and has someone with authority approved the sale? A good answer is that the entity that collected the data is the licensor and the board has approved the licence in writing; where the data is all or substantially all of the company's assets, shareholders have approved too.
2. Who is signing, and what authority do they have? Turing's intake says it can only buy from someone with admin authority. Admin authority over the systems and authority to bind the company are different things, and counsel wants both.
3. Do investor agreements or the charter give anyone a veto? The checklist asks whether investor agreements or charters give investors a veto over selling or licensing key assets, and treats an exclusive licence of the main data with no board or investor sign-off as a red flag.
4. Does a lender hold security over the company's assets or IP? Venture debt often carries a covenant on disposals. The checklist asks whether any lender holds security over the company's assets or IP, or has a right to approve asset sales or IP dispositions, and the good answer is that the licence is a permitted disposition or the lender consented in writing.
5. If the company is closing, who now has the power to sell? For a company being wound up, insolvent or in bankruptcy, the checklist asks who now has legal authority to sell: the board, an assignee for the benefit of creditors, a bankruptcy trustee, or a Dutch curator. In US bankruptcy the sale goes through section 363, with an ombudsman where personal data is involved.

The evidence that answers them

A board resolution approving the licence, the company's entry in its register naming its directors, the investor rights agreement and charter (or a note that they contain no relevant veto), the loan documents with any consent, and, for a closing company, the document appointing whoever now acts for it. None of this is about the data itself, and all of it can be gathered before any buyer is approached.

The red flags

The checklist names them plainly: a founder selling personally after a shutdown, a former employee holding an export, or no board resolution. The first is common among closing companies, and it is the single most avoidable failure in this area. A founder who exported the company's workspace on the way out holds a copy, not a right. For a company in a formal procedure, the red flag is a founder selling a bankrupt company's archive directly.

The clause it feeds

These answers become the title and authority warranties. Our licence terms register records that holders commonly give title and authority without qualification and qualify the rest by knowledge. That asymmetry matters: title and authority are facts the company can know for certain, so buyers expect them unqualified, and a holder that cannot give them unqualified has a problem to fix, not a clause to negotiate. SimpleClosure's terms show the remedy attached: the company covers SimpleClosure's losses and legal costs from a breach of its warranties about the assets.

3. Where did each record come from, and how did it leave the system?

Provenance is the question behind every other question. Our provenance guide splits it into four parts: origin (which system, who created it, over what period), rights (the terms it was collected under), processing (what was done to it) and custody (who has held it since it left the source). This section covers origin and custody; section 4 covers rights and section 5 the processing of personal data.

The questions counsel asks

1. Which systems does the data come from, over which years, and in what volume? Buyers start with an inventory. Troveo's licensing guide asks for a list of your systems and the years each covers, your customer contracts and employee agreements, and a first view of what you would keep out. DataVendor asks for the asset type, where it came from, who owns it, whether you have the right to license it, what documentation exists and any obvious restrictions.
2. How did the data leave each system? This is a blocker on our checklist: a built-in export run by your own admin, or an app or script using the vendor's API? The good answer is that each system was exported by its own admin with the vendor's native export tool, the method is recorded per system, and no third-party connector touched it.
3. Who has held the data since it left the source? For a closing company, the export may have passed through a former employee's laptop, a wind-down provider or a storage bucket nobody now controls. Counsel wants a chain without gaps.
4. Do the records name the company? A mailbox at the company's own domain, invoices issued in its name, repositories in its organisation: the records themselves should show whose they are.

Why the export route matters so much

A native export by the company's own admin is the company getting its own data out under its own subscription. Data pulled through a vendor's API by a connector is governed by the vendor's developer terms, which can forbid exactly this use. Corpus Bridge says that since May 2025 Slack's API terms forbid bulk export through the API, long-term copies of API data and use of that data to train language models, and tells holders to check a platform's terms before assuming a lot can be assembled. Our checklist's red flag is data pulled through a connector or scraper from Slack, Zendesk, Xero, Zoom, HubSpot or Google Workspace APIs, or Slack direct messages exported without the approved application Slack requires.

The vendor's own terms also decide what a native export can contain. Slack's terms, as we read them, allow private channels and direct messages only by approved application, and not on Free and Pro plans; a Slack export on Free and Pro covers public channels only, and a Free workspace holds at most one year of history. Zendesk keeps exports off until its support switches them on. A holder that knows these rules before diligence can state, per system, exactly what its export holds and why; one that does not will be asked, and will have to find out mid-review. The rights page sets out what each business system lets a company export and what its developer terms say about training.

The evidence that answers them

An inventory per system (what it holds in its own unit, the years, the seats, who administers it), a short record of each export (who ran it, when, with which native tool, and what it covered), and the account or domain the records belong to. Our preparation guide covers the exports system by system; for diligence, what matters is that the method is written down at the time it is done, not reconstructed months later when a buyer asks.

The clause it feeds

Origin and custody feed the lawful collection warranty, which a typical template words as that the data was collected in compliance with applicable law, and the description of the data, which is what quality is later measured against (section 7). A connector-built export can turn a true description into a breached warranty: the data is exactly what was described, but the holder had no right to take it out that way.

4. Under what terms was it collected?

Being able to export a record does not settle whether the company may license it. Nyne puts it in one line: being able to export a record does not mean you may license it, and it asks holders to review ownership, third-party restrictions and exclusions before sharing. This is where buyers' counsel spend the most time, because the restrictions sit in contracts the buyer has never seen.

Customer contracts and data processing agreements

The first question is whether any of the data belongs to or describes the company's customers. Our checklist asks whether your customer contracts and data processing agreements allow using it for anything other than serving them. The good answer is that customer content (support tickets, customer files, CRM notes, customer email) is excluded, or each customer contract expressly permits this use, or the data is anonymised and the contract does not forbid that. The red flag is support tickets, customer success call recordings or customer-uploaded files in the lot, under contracts that restrict use to providing the service. For code, Corpus Bridge says that code that belongs to a customer, or contractor work without an assignment, is what most often stops a codebase. Our guide to whether it is legal to sell customer data goes through the contracts and laws in detail.

Other companies' confidential information

Company records are full of material that belongs to someone else: partner documents, supplier pricing, a counterparty's roadmap shared under an NDA. Counsel asks whether the data contains other companies' confidential information. The checklist's red flags are specific: Slack Connect channels, vendor negotiation threads, M&A data rooms, or client deliverables in the archive. The good answer is that shared channels, external email threads, partner folders and third-party attachments are excluded or reviewed, and the holder can list which counterparties appear.

Licensed and third-party material

Two related questions cover content the company did not create. The first is material it licensed: purchased contact lists, research reports, stock media, fonts or design kits, with the red flag of CRM records enriched from a list vendor or stock images inside design files. The second is content others created that the company simply holds: articles, reports, books, customer uploads, screenshots of other products, where shared drives full of downloaded PDFs are the classic failure. Both are fixable by identifying and removing the material before packaging; neither is fixable after a buyer finds it.

Code: open-source licences and IP assignment

For code, counsel asks two more questions. Whether it includes third-party open-source code, and whether you have a list of each licence: the good answer is a software bill of materials or licence scan, with vendored code removed or delivered with its licence, and only the company's own code warranted. Troveo says the same from the buyer's side: copyleft or redistribution-restricted code must be found and excluded or handled under its own terms, with a dependency inventory in the package. And whether every employee and contractor who created the code, documents or recordings signed an agreement assigning their work to the company; freelancers and agencies without written assignment, and founders who never assigned pre-incorporation work, are the gaps. Our guide to selling your codebase to AI companies covers code in depth.

Privilege, trade secrets and controlled technology

The last group is material that should not leave at all. Counsel asks whether the data includes legal advice, litigation material, or trade secrets, with #legal channels, email with outside counsel and board minutes as the red flags. And whether it includes controlled technical information, such as semiconductor designs, aerospace or defence engineering, or advanced encryption source code, which is a blocker until screened.

The clause it feeds

All of this feeds the non-infringement warranty and, more usefully for the holder, the schedule of exclusions. Our register records the holder's position as qualifying warranties by knowledge tied to a disclosed rights inventory (schedule), so the warranty is that the disclosed limits are accurate rather than that the data is perfect. A holder that has written down what it excluded and why can give that warranty honestly. One that has not is warranting a lot it has not read.

5. Consent and personal data

Personal data is where buyers' diligence is most detailed and where the law differs most by country. The questions fall into three groups: what the company promised people when it collected the data, which law applies to the people in it, and how they are removed if the answer is to remove them.

What did the company promise?

The first question is historical. Counsel asks what your privacy policy, terms of service and employee handbook said about sharing or selling data at the time it was collected. The good answer is that the policies in force at collection allowed this kind of transfer, or affected people gave fresh affirmative consent, or the data is fully anonymised. The red flags are "We never sell your data" in an old privacy policy; a policy changed recently to add AI training; no record of past versions. A holder that has not kept old versions of its policies should retrieve them before diligence, from its own repository or an archive of its site.

Which law applies to the people in it?

Then counsel asks, person group by person group, what the applicable law requires. Our checklist covers the main cases:

• Staff in California. Whether the data includes personal information of employees, contractors or applicants in California, and whether they have been told about the sale and given a way to opt out. The good answer is removal to the CCPA de-identified standard, or notice and an opt-out to current and former staff.
• Staff in the EU or UK. What legal basis lets you reuse the personal data in their work for a sale, and is that new purpose compatible with why you collected it? The good answer is anonymisation to the EU standard with a documented assessment. The red flag is relying on an employee consent tick-box, or treating name-replaced chat logs as outside GDPR.
• Works councils. For a Dutch or German entity, whether the works council has been consulted about processing staff data for this sale.
• Union and workplace discussion. Whether records include staff discussing pay, working conditions or union matters, which the checklist treats as material to exclude.
• People in Canada. Whether each person consented to the new use or the data will be anonymised to the Canadian standard before it leaves, with a privacy impact assessment for Quebec.
• Health data. Whether any data comes from health care, health insurance, or work done for a health client under a business associate agreement, which requires expert determination or safe harbor removal of all 18 identifiers.
• Biometrics. Whether the data contains voices, faces, fingerprints or other biometrics of people who may be in Illinois, Texas or Washington.
• Recordings. Whether calls and meetings were recorded with every participant's consent, and that consent covered use beyond the meeting. Call libraries recorded under "for quality and training purposes" notices are the red flag.

Our guides to employee emails and chats in AI training, GDPR and licensing data for AI training and HIPAA de-identification take each of these in depth.

Some buyers turn part of this into a flat warranty. micro1's terms have the holder promise, unless the order form says otherwise, that the data holds no HIPAA health information, biometrics, card or bank account numbers or children's data, and make best efforts to remove any that is found at no cost to micro1. pre.dev's agreement has the holder warrant the code holds no personal or customer data, third parties' trade secrets, credentials, API keys or passwords, except as disclosed. A warranty like that is only safe after a scan.

How are people removed, to which standard, and who tested it?

Where the answer is removal, counsel asks three further questions: which standard, who did it, and who tested it. The checklist's EU question is has personal data been removed to the EU anonymisation standard, and who tested it? The good answer is that an independent de-identification provider ran a documented test, certified the result before transfer, and the buyer commits not to re-identify and flows that down. The red flags are names swapped for tokens in workplace chat, small teams where writing style or role identifies people, no written test, or you keep the key. For US data the CCPA definition needs more than removal: a published commitment not to re-identify, and a licence that obliges the buyer to do the same.

Buyers themselves are candid about the limits. Handshake says its de-identification is designed to minimise the risk of re-identification, and that no de-identification process removes that risk entirely. Grepped applies the strictest legal standard that fits the data, and has a reviewer try to identify people before release, and if a dataset cannot be brought to its standard it delivers none of it.

Who controls the removal is itself a term with a price. In the Spirit Airlines auction one bidder offered $5.2M with third-party de-identification or $7.0M if it could de-identify with its own tools, and the debtors chose the lower third-party bids. In the sale agreement proposed to the court, the price was paid only on delivery of de-identified data, with an agent's certification filed with the court before every transfer. Our register's position is that the holder selects or jointly selects the de-identification provider, approves the protocol and requires certification before anything leaves. Our de-identification standard sets out the protocol we advise.

The US bulk data rule

One question runs in the other direction: it is about the buyer. Under the US Department of Justice rule on bulk sensitive data, counsel on both sides asks whether the buyer, or anyone it may pass the data to, is a foreign person, and whether the dataset contains US sensitive personal data above the bulk thresholds. The good answer is a buyer screened for ownership by or location in a country of concern, the data checked against the thresholds, and an onward-transfer clause for foreign buyers. Section 11 describes how we screen every buyer before it sees anything.

The clause it feeds

Consent answers feed the representations on consent and opt-outs, where our register's position is to warrant to knowledge, keep a consent ledger per person or per work, and agree a process (not a guarantee) for later opt-outs, and to exclude people who did not opt in rather than promise consent you cannot show. De-identification answers feed the no-re-identification clause, where the position is that the buyer will not attempt re-identification, will not resell or sublicense the raw data, and will bind any permitted recipient to the same terms. When the archive mixes clean operational records with personal data that needs consent, the Spirit sale shows another route: the competing bidders agreed a schedule that excluded personal information, which was set aside for a later, separate auction.

6. Earlier licences, exclusivity and vendors that already trained

Buyers pay for access their competitors do not have, or at least for a clear picture of who else has it. So counsel asks what has already happened to the data.

The questions counsel asks

1. Has this data been licensed to anyone before? micro1's master terms turn this into a warranty: the holder has not previously entered into any transaction granting a third party rights to license, access, use or otherwise exploit the same Data on the same or substantially similar terms. A holder that licensed a slice of its support tickets to one buyer last year needs to know whether that licence covers "the same data" before it gives this warranty to another.
2. Is any existing licence exclusive? Some buyers' standard terms take exclusivity. Kled's licence is exclusive to Kled, and every licence on Polyshares' track-record page is a perpetual exclusive licence to the company's operational record. Protege's own case study says it held exclusive AI-training rights to a partner's catalogue so buyers could not negotiate with anyone else. An exclusive licence signed earlier can make a second licence a breach.
3. Has a software vendor already trained on this content? Our checklist asks whether a software vendor has already used this content to train its own AI, naming Atlassian since August 2026, GitHub Copilot interactions, HubSpot, ServiceNow Now Assist and Figma as examples. The good answer lists each vendor's AI-training setting and when it was switched off, and the licence states exclusivity only against third parties the holder controls. The red flag is promising "never seen by any AI" when the workspace sat on a plan where vendor training defaulted on.
4. Will this licence have to be disclosed later? A company that may itself be sold one day should expect the question to come back. In Ooma's purchase of FluentStream, the company sold represented that, except as scheduled, it had not let any company or customer data, de-identified data included, be used as training data by another party.

The evidence that answers them

A list of every earlier data licence, evaluation agreement and sample shared, with its scope and term; the AI-training settings of each software vendor, with dates; and, for a living company, an eye on what its own future buyer will ask. Samples belong on that list too. Our checklist asks whether any sample of the data has already been shown to a buyer or broker before this rights review, because a sample itself can be a disclosure.

The clause it feeds

These answers feed the no-prior-licence warranty and the exclusivity clause. Our register records that holders should offer exclusivity only for a defined field and a defined window, and charge a multiple for it, and disclose any vendor that already trained. Our guide to exclusive and non-exclusive data licences covers the pricing of exclusivity.

7. Quality against the description

The last area is the one most holders expect to be the whole of diligence: does the data match what was described? It matters because buyers measure delivery against the description the holder wrote, and the remedies in section 8 turn on any gap.

The description is the holder's document

At micro1, the holder writes the data manifest itself, describing the data by sources, types, volumes and specifications, and micro1 approves it. That manifest is then the yardstick: the refund right turns on whether it was materially inaccurate, and a claim for a latent defect in quality or a material mismatch with the manifest must come within 60 days of acceptance, with the holder choosing whether to correct, replace or refund the proportionate amount. Grepped asks holders up front to state known quality issues, gaps, duplication or bias. The lesson is the same at every buyer: describe the data as it is, gaps included, because the description is what you will be held to.

The questions counsel asks

1. Are the counts net? A count that includes material that will come out is a count that will be wrong. SimpleClosure found that about 37 percent of raw code disappeared after removing third-party or generated code and internal duplication. pre.dev decides alone which files count toward the price, naming generated, vendored, binary, duplicated, third-party and secret files among those it may exclude.
2. Was any of it written by a model? Turing takes only pull requests by human authors and rejects code written by a language model. Collinear does not need AI-generated code, a public framework with a thin layer on top, or anything you do not hold the rights to.
3. Does it meet the buyer's technical filters? Turing's screen sets limits on linked issues and tests, though its pages disagree on the issue length: 10 to 6,000 words on its process page and 20 to 2,000 words in its technical overview. A holder should ask in writing which applies.
4. Does a sample show what the description claims? Polyshares reads an anonymised sample before it prices, and The General Data Company reviews a sample, your rights to it and its fit for AI customers after a confidentiality and data-processing agreement. A sample that flatters the lot will be contradicted by the delivery.
5. For code, does the copy carry its history? DataVendor's listing checks look for a readable repository copy with its Git history and captured pull requests.

Acceptance: when the description is tested

The delivery is tested against the description during acceptance. micro1 has 30 business days after delivery to reject the data in writing; silence counts as acceptance, and nothing is owed for any part it validly rejects. Nyne fixes the use, data categories, volume, privacy constraints and acceptance criteria in the agreement before anything is collected or transferred, which is the order to ask for everywhere: objective criteria written before extraction, so diligence on quality is a test against a known standard rather than a judgment after the fact. For a codebase, pre.dev says a buyer usually reviews it for 4 to 12 weeks before anything is agreed. Our guide to when AI data buyers actually pay covers how acceptance ties to payment.

Some buyers also offer the holder a look before release, which protects the holder's side of the quality question: Appen has the holder review a representative sample pack before anything is licensed, Ooak lets it review a sample before delivery, and Grepped sends a release summary and gives 5 business days to object.

8. What happens if a statement proves wrong

Every answer in sections 2 to 7 ends up in the licence as a warranty, a representation or a description. What happens when one proves wrong depends on how it was worded and what remedy is attached.

The remedies buyers write

The sharpest is micro1's. If micro1 finds the manifest materially inaccurate, no amounts are payable to Licensor, Licensor will refund any amounts already paid, and no license attaches to any Data, and that right survives acceptance. For narrower problems its terms are gentler: a latent defect or material mismatch must be claimed within 60 days of acceptance, and the holder may correct, replace or refund the proportionate amount. Kled requires an immediate refund of what was paid for content whose consent is withdrawn. pre.dev may deduct proportionate amounts from future payouts or recover them from the holder if a buyer's payment is refunded or clawed back. SimpleClosure's terms put an indemnity on the company for a breach of its warranties about the assets, claims that the assets infringe others' rights, and privacy breaches in their transfer.

Indemnities are the other remedy. Buyers ask the holder to cover third-party claims that the data infringes or was unlawfully collected. Our register's position is to limit indemnity to precisely defined claim types, cap it (a multiple of fees), and carve out claims caused by the buyer's own use, combination with other data, or outputs. The reverse also exists: NVIDIA's own data agreement makes the recipient indemnify the provider ( register).

Knowledge qualifiers, and what they need

The holder's best protection is how the warranty is worded. Title and authority are given flat, because they are knowable. Everything else (lawful collection, non-infringement, consent) can be qualified by knowledge, tied to a disclosed rights inventory. A knowledge qualifier is only as good as the enquiry behind it: a buyer will accept "to the best of our knowledge" from a holder that can show it asked the right questions, kept the answers and disclosed the limits, and will resist it from one that cannot. That is the real purpose of preparing for diligence. It is not to pass the buyer's review; it is to turn every warranty from a bet into a statement the company can stand behind.

Records and audit after the sale

Diligence does not always end at signature. Our register records that holders can ask buyers for records sufficient to show compliance with the licensed uses, an annual compliance certificate, and audit only on reasonable suspicion of breach, and should expect the mirror request: buyers want certification of de-identification before each transfer. The licence also fixes what happens to the copy at the end: our register's position is deletion of the dataset within a fixed number of days, with a written certificate.

9. Red flags that stop a sale

Some findings are not negotiated; they end the review until they are fixed, and some cannot be fixed at all. Our checklist marks 16 of its 27 questions as blocking a sale until settled. The table sets out the red flags behind the ones holders meet most, in the checklist's own words, with what settles each.

Two patterns run through the list. Most red flags are about rights, not data. A buyer rarely refuses because the records are poor; it refuses because it cannot be sure the company may license them, and it cannot price a lawsuit. And most are fixable by exclusion. Taking out customer content, shared channels, external call participants or a vendor's API export usually leaves a smaller lot that can be licensed, which is worth more than a larger one that cannot. The buyers that do their own review say as much: SimpleClosure states that any acquisition is subject to its satisfactory completion of due diligence and a separate agreement, so a valuation before that review is not a commitment to buy.

10. The diligence pack: a checklist

The pack is the set of documents that answers the questions above before they are asked. Each item uses work a holder does anyway; the point is to gather it once, in one place, before the first buyer conversation. The readiness questions walk a holder through the rights questions and show what would block a sale, and the datasheet builder turns the answers into the one description buyers ask for.

Authority and title

1. Board resolution approving the licence, and shareholder approval if the data is all or substantially all of the company's assets.
2. The company's register entry, naming the person who signs, or a written authorisation of that person.
3. Investor agreements and charter checked for vetoes; loan documents checked for disposal covenants, with consent where needed.
4. For a closing company: the document appointing whoever now acts for it, and any court consent its procedure requires.

Origin and export route

5. An inventory per system: what it holds in its own unit, years covered, seats, administrator, links to other systems.
6. A record of each export: who ran it, when, with which native tool, what it covered. No connector exports.
7. Proof that the records are the company's: the mailbox domain, invoices in its name, repositories in its organisation.

Terms of collection

8. Customer contracts and data processing agreements reviewed; customer content excluded or permitted.
9. Shared channels, external threads and partner folders excluded or reviewed; counterparties listed.
10. Licensed and third-party material identified and removed.
11. For code: a licence scan or software bill of materials, IP assignments from every contributor, secrets purged from every revision.
12. Legal, privileged and export-controlled material excluded.

Consent and personal data

13. Every version of the privacy policy, terms and employee handbook in force while the data was collected.
14. For each group of people in the data (staff, customers, contacts, call participants), the law that applies and how it is met: notice, consent or removal.
15. The de-identification standard chosen, who applies it, and who tests and certifies the result before transfer.

Earlier licences

16. Every earlier licence, evaluation agreement and sample shared, with scope and term.
17. Each software vendor's AI-training setting and when it was switched off.

Quality against the description

18. Net counts, after removing generated, vendored, duplicated and excluded material.
19. Known gaps, duplication and bias, written down.
20. A small, representative, de-identified sample, drawn from the reviewed set, shared only under a signed confidentiality agreement.
21. Proposed acceptance criteria: objective, written before extraction, with a review window.

Items 1 to 17 need no buyer at all. A holder that finishes them before the first conversation can answer most of a buyer's counsel's questions on the call, and give its warranties knowing what they cover.

11. How a sale through us prepares it

AIData.Broker is the holder's broker: its agent in the sale, acting only for the holder, for holders based in the United States, the United Kingdom and Canada. In a sale we run, the diligence pack is built before any buyer sees the lot, in three documents and a set of checks on both sides.

The rights file comes first. The mandate defines the Rights File as the holder's answers on who owns each part of the data, which contracts limit it, who appears in it and whether they agreed. Those are the questions of sections 2 to 6, answered once and kept. A question answered no means part of the lot may not be the holder's to license, and a person looks at it before anything goes further.

The datasheet is written for the holder and approved by it. The mandate defines the Datasheet as the document describing the data (its source, contents, measured size, rights, personal data, format and delivery, the licence offered, and its known limits) that we prepare from the holder's answers and its valuation, and that the holder approves in writing before it goes to any buyer. Those headings are the six areas of this guide. Every buyer receives the same description, so every buyer's diligence starts from the same facts, and the known limits are stated before a buyer finds them. We pass it on labelled as the holder's statement, saying its figures come from the holder's own valuation and any sample it sent, and that we have not inspected the rest of the data.

The holder's confirmations are to the best of its knowledge after reasonable enquiry. Under the mandate the holder confirms that it holds the rights needed to license the data, and that its rights file and its answers for the datasheet are true, complete and not misleading to the best of its knowledge after reasonable enquiry, and will be corrected promptly if anything changes or proves wrong. That is the standard of section 8 built in from the start: confirmations backed by an enquiry the holder actually made, which is what lets the holder give a buyer knowledge-qualified warranties with confidence.

We check the holder before we approach anyone. Our checks of the holder run after it accepts the mandate, as our verification standard and clause 13.4 describe: sanctions screening, who the holder is from its register, whether the person accepting can bind it, and its right to license the data from the rights file and evidence that it controls the data. Until every check has passed we approach no buyer and send no datasheet. So by the time a buyer's counsel opens the pack, the questions of section 2 have already been answered by documents.

We screen every buyer before it sees anything. Under clause 6.1 of the mandate, before a buyer receives the datasheet or learns the holder's identity, we screen its name against the sanctions lists of the European Union, the United Nations, the United Kingdom and the United States and the US Department of Justice's covered persons list, and ask it to confirm where it is organised, who owns 50 per cent or more of it, and whether any country of concern does. A buyer that fails, or does not confirm, receives nothing, and the holder is told which buyer and why. That is the bulk data question of section 5, settled for the holder.

The holder decides who removes personal data. The mandate says we are not the de-identifier of record, and that the holder decides who removes personal data and to which standard. We advise that it is removed before anything leaves the holder, by the holder or an independent provider it chooses, and certified by an independent provider before each transfer, as our de-identification standard describes. That answers the "who tested it?" question of section 5 before a buyer asks it.

The round then puts a first description that does not identify the holder before every buyer whose published requirements fit; each that gives its confidentiality undertaking receives the same datasheet, with one deadline for offers. How it works sets out every step and term in plain words, and the pricing page the fee, which is due only out of money a buyer has paid the holder.

Questions people ask

What due diligence questions does an AI data buyer ask? Six groups: who can sign and whether the company holds the rights; where each record came from and how it left each system; the terms it was collected under (customer contracts, NDAs, third-party material); consent and personal data; earlier licences; and quality against the description. Our checklist holds 27 such questions, 16 of them blocking a sale until settled.

What do AI buyers ask a holder to warrant? Title and authority, usually without qualification, and lawful collection, non-infringement and privacy compliance, which holders commonly qualify by knowledge, tied to a disclosed rights inventory. Some add flat warranties: micro1's terms exclude health information, biometrics, card numbers and children's data unless the order form says otherwise.

What happens if the data does not match the description? It depends on the buyer. Under micro1's terms a materially inaccurate manifest means nothing is payable and everything paid is refunded, even after acceptance; a narrower mismatch must be claimed within 60 days of acceptance and can be corrected or replaced. Write the description from net counts and state the known gaps.

Does it matter how we exported the data? Yes. It is a blocker on our checklist. A native export by your own admin is the company taking out its own data; a connector using a vendor's API may breach the vendor's developer terms. Slack's API terms, as Corpus Bridge reads them, forbid bulk export through the API and use of that data to train language models.

Can we sell data if we licensed it to another buyer before? Possibly, if the earlier licence was non-exclusive and the new one does not promise otherwise. micro1 asks the holder to warrant it has not already licensed the same data on the same or similar terms. Some buyers take exclusive licences as standard, so read every earlier licence before you answer.

Do buyers check that people in the data consented? Yes, by asking what your privacy policies said at collection, which law applies to each group of people, and how anyone is removed. Defined.ai requires proper consent, documentation and the right to commercialise. Where consent is missing, the usual answer is exclusion or anonymisation to the applicable standard, tested independently.

Who should de-identify the data, us or the buyer? The holder should decide, and our register's position is that it selects or jointly selects the provider, approves the protocol and requires certification before anything leaves. Buyer control has a price: in the Spirit auction one bid was $7.0M with its own tools against $5.2M with a third party.

How long does a buyer's review take? It varies. pre.dev says a buyer usually reviews a codebase for 4 to 12 weeks before anything is agreed, and micro1's acceptance window after delivery is 30 business days. A pack gathered in advance shortens the part that depends on the holder.

What this means for you

A buyer's diligence asks the questions your own counsel should have asked first, and every answer becomes a promise you will be held to after you are paid. In order:

1. Settle who signs. Board approval, the signer's authority, investor and lender consents, and for a closing company the person the law lets act for it.
2. Write down where every record came from, per system, and export each with its own native tool, recording how. Never through a connector.
3. Read the contracts behind the data: customer agreements, NDAs, third-party licences, open-source licences and IP assignments. Exclude what they forbid.
4. Find the privacy promises you made when the data was collected, and decide for each group of people whether notice, consent or removal meets their law.
5. Choose who removes personal data, to which standard, and who certifies the result before anything leaves.
6. List every earlier licence and sample, and each vendor's AI-training setting.
7. Describe the data as it is: net counts, known gaps, a representative sample, and acceptance criteria fixed before extraction.
8. Give warranties to your knowledge, tied to that file, with title and authority flat and the rest qualified by what you disclosed.

Start with the readiness questions, which show what would block a sale before a buyer finds it, and the valuation, which prices the data against public sales and offers, binds no one and needs no upload. The datasheet builder drafts the one description every buyer's diligence starts from, and the de-identification tool removes people from your exports on your own computer, to the standard we advise. If you already hold an offer, the offer check lists that buyer's clauses to read first. How it works sets out a sale we run, step by step.

This guide is research from public sources, not legal advice.