How to prepare company data for sale to AI labs

Prepare in this order: an inventory first, then a sample, then exports that keep their history, delivered in one of three shapes, with your code and its secrets cleaned by you, and a decision, made before anything leaves, on who removes personal data. Buyers open with counts, not files: Polyshares' intake asks for record counts, not files or exports, and Turing for a rough count per system, where estimates are fine. The price then follows a sample: SuperAnnotate reviews a sample for volume, quality and uniqueness before it gives a valuation, and Polyshares reads an anonymised sample before it prices. What gets refused or discounted is often missing history: a GitHub mirror clone keeps every branch, tag and commit but not issues or pull requests, DataVendor's listing checks look for a repository copy with its Git history and captured pull requests, and a Free Slack workspace holds at most one year of history. The data then reaches a buyer through a read-only connection ( Centific, Mercor), through exports you run yourself ( Troveo), or, for code, through a Git connection ( SimpleClosure). Secrets in code are yours to remove, and from every revision, including old ones. Who removes personal data differs by buyer: Scale does it inside your environment, before any data is extracted, Nyne on its side, after you transfer, and on DataVendor the job is yours, before upload.

Most of what a buyer refuses or counts out can be fixed before the first call, and very little of it can be fixed after. Turing rejects code written by a language model. pre.dev decides alone which files count toward its price and names generated, vendored and duplicated files among those it may leave out. Grepped delivers none of a dataset that cannot be brought to its de-identification standard. micro1 has you write the data manifest yourself and can ask for a refund of everything paid if that manifest proves materially inaccurate, even after it has accepted the data. Each of these costs an hour of counting or a scan to prevent before anything leaves your systems, and a discount, a refusal or a refund once a buyer finds it in review. And one warning applies to every holder whose subscriptions are ending: Appen says that once systems are decommissioned and licences lapse, the record often becomes unrecoverable.

This guide is for the founder, CTO or operations lead of a company that holds records or code (the holder) and is about to approach AI data buyers, or to accept one, and wants to know what to gather, export and clean, and in what order, so that nothing is refused or deducted. It covers what buyers ask for before a price, the inventory, the sample, exports system by system, the Slack question, the three ways data reaches a buyer, cleaning code, who removes personal data, what gets refused, the pages that contradict themselves, a checklist in order, and how preparation works in a sale AIData.Broker runs. Each buyer statement below links to the record that holds the buyer's own words and the day they were read; most were read on the buyer's own page on 19 October 2026. The whole selling process is in how to sell company data to AI labs, and what happens to the money after delivery is in when AI data buyers actually pay.

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

Contents

1. At a glance: what buyers ask for before a price
2. The inventory comes first, and it is not files
3. The sample: what it is for, and when to send it
4. Exports that keep their history, system by system
5. The Slack question
6. Three ways data reaches a buyer
7. Code: clean it before anyone reads it
8. Who removes personal data
9. What gets refused or counted out
10. Pages that contradict themselves
11. The order of work: a checklist
12. How preparation works in a sale we run
13. Questions people ask
14. What this means for you

1. At a glance: what buyers ask for before a price

Buyers differ less in what they want than in when they want it and who does the work. Almost all of them start from a description a holder can write without touching its systems, move to a count or a sample, and reach the records only after an agreement. The order matters to a holder for a simple reason: everything before the sample is information you control and can keep confidential, and everything from the sample onward is data that has left your hands.

The table sets out, for the buyers on our board whose pages describe these steps, what each asks for before it names a price, and who removes personal data from what it receives. Each cell links the record that holds the buyer's own words and the day they were read. A buyer missing from the table is not one that asks for nothing; its pages did not describe these steps in words we could cite.

Three things stand out once the rows sit side by side. No buyer asks for the records first. Every row begins with a description, a count or a manifest, and some buyers say so in as many words: Halluminate's data partnerships page tells companies making first contact: "No files are needed. Do not include confidential or sensitive information." ( Halluminate). The sample is the moment data first leaves you, and buyers place it at different points: Polyshares before its price, The General Data Company only after a data-processing agreement. And who removes personal data is the column that varies most, from the holder's own job to the buyer's pipeline, which is why it is a decision to make before the first call rather than a detail to settle at delivery. Sections 2, 3 and 8 take each column in turn.

2. The inventory comes first, and it is not files

The first document every buyer wants is a list, and it is the same list in different words. Polyshares asks, for each system, how much data sits in it, how long you have used it and how many seats it has, and says an estimate from the admin console is enough to start. Turing's intake asks for the rough count for each app category, accepts any historical system from Lotus Notes to Bugzilla, and will only buy from someone with admin authority. Troveo's licensing guide asks for a list of the systems you run and the years each one 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. Handshake has you define which records are included and what sensitive information needs to be excluded.

None of this needs an export. It needs an afternoon with each system's admin console, your contract folder and someone who knows how the company actually used its tools. Writing it once, carefully, is the cheapest work in the whole sale, and it is the work that every later step reuses: the sample is drawn from it, the exports follow it, the manifest restates it and the licence annexes it.

What a good inventory holds

The buyers' questions add up to nine fields per system. The table maps each to the buyers that ask for it, so a holder can see which answers carry the most weight.

Two of these fields deserve more care than they usually get. "Who can sign" is a legal question, not an administrative one. Turing will only buy from someone with admin authority, and the rights questions we keep ask whether the company selling the data owns it, and someone with authority has approved the sale. A former employee with an old admin login can export a workspace; that person cannot license it. "Rights" is a different question from "can we export it". Nyne puts it plainly: your ability to export a record does not by itself establish permission to license it. Customer content held to serve a customer, other companies' confidential material and licensed third-party content are the usual exclusions, and the readiness questions walk through each before any buyer is involved.

Count net, and count the links

The count you write becomes a promise. micro1's master terms make the manifest your written description of the data, approved by micro1, and its refund right turns on whether that description was materially inaccurate. So count what you can deliver, net of what will come out. For code, the gap is large: SimpleClosure found that roughly 37% of raw code disappeared once third-party, generated and duplicated code was removed, and pre.dev's agreement lets it exclude generated, vendored, binary, duplicated, third-party and secret files from the count it prices. A holder that counts net first sees the real number before any buyer does.

The other thing to count is connections. Mercor says connecting more tools generally results in a higher payout. Ooak's estimator showed a mid-sized operating company at $85k to $121k with six tools, and $16k to $22k with three. And buyers prize records that point at each other: a Jira ticket tied to the commit that closed it is, in Sunset's words to Forbes, worth more than a standalone document. An inventory that says which systems link to which (tickets to code, chat to tickets, CRM to email) describes an asset larger than the sum of its rows, and costs nothing extra to write.

3. The sample: what it is for, and when to send it

After the inventory, most buyers want to see a slice of the real thing before they commit to a number. SuperAnnotate reviews a sample for volume, quality, and uniqueness, then comes back with a valuation. Polyshares has someone read the anonymized sample before it prices the record. Grepped asks whether you can provide a small representative sample, and asks you not to paste any actual records into its form. The General Data Company reviews a sample, your rights to it and its suitability for AI customers, but only after a confidentiality and data-processing agreement. DataVendor says a small representative sample also helps.

A second kind of sample comes later, in the other direction: the buyer shows you what it made of your data before it goes further. Ooak lets you review a sample before delivery. Appen has you review a representative sample pack before anything is licensed. HUMXN has you approve the final dataset. Grepped sends a release summary and gives you 5 business days to object. These protect the holder, and they are worth asking every buyer for.

Treat the sample as a delivery

A sample is data leaving your systems, so it carries the same risks as the full delivery, at smaller scale. The sell-side guidance we keep in our rights questions says it directly: "Do not share sample data before this review, since a sample itself could be a disclosure". Four rules follow:

1. After the rights review, not before. A sample drawn before you know which customers, channels and people must stay out is a sample of things you may not have the right to share.
2. De-identified, by the same method as the delivery. If personal data is removed before anything leaves you, remove it from the sample too, and ask that the sample a buyer reviews comes from the same run that will be delivered.
3. Under a signed confidentiality agreement. The General Data Company's order (agreement first, sample second) is the one to ask every buyer for.
4. Representative, not flattering. No buyer we read gives a size; the words they use are "small" and "representative". A sample that hides the gaps your inventory admits will be contradicted by the delivery, and Grepped asks you to state known quality issues, gaps, duplication, or bias up front for the same reason.

The order of the two documents matters as much as their contents. A buyer that has your inventory and your sample has most of what it needs to price, so send both to every buyer at the same time, under the same terms, and you get prices that can be compared. Send them to one buyer first and the others are pricing against a holder who has already shown its hand.

4. Exports that keep their history, system by system

What makes company records valuable to a buyer is history: who replied to whom, which ticket led to which fix, how a decision changed over months. Troveo says a snapshot of source code with no history is worth little to a lab, and Scale wants tickets and wikis carried over with their complete history and metadata and chat with threads, participants and reply structure preserved intact. The default export of many systems loses exactly that, which is why the export method is a decision rather than a button.

The table sets out, for the systems buyers name most often, the export route our records describe, what it keeps or loses, and what buyers say they want from it. It is built only from what the records hold; where a record says nothing about a point, the cell says what to check.

Read the table from the right

The right-hand column tells you what a buyer prices; the middle column tells you whether your export can deliver it. Where they disagree, the export loses money. A Jira CSV without its changelog is a list of tickets in their final state, when buyers ask for the path each ticket took. A Git mirror without its pull requests is code without the review conversations that explain it. A Free Slack workspace offers one year, whatever its age. In each case the fix is a second or fuller export, and in each case it has to happen while the account is still live: Atlassian deletes customer data following expiration or termination, Salesforce makes the data available only on request within 30 days of the contract ending, and GitHub deletes a migration archive seven days after it is ready.

Polyshares' system guides are a useful reference because they name a native export for each tool, for example Outlook to PST, Zendesk as a full JSON export and Jira as a full site backup, and each of those is an export run by your own administrator under your own account. That matters for a reason section 5 explains: the restrictions in our records of these vendors' terms sit mostly in their API and developer terms, and an export your own admin runs with the vendor's own tool is the route our rights questions treat as the standard: each system exported by its own admin with the vendor's native export tool, the method recorded per system.

Record each export

Write down, for each export, the date it ran, who ran it, the tool and settings used, any filters, what it left out, and where the file now sits. Troveo asks for the same thing in its own words: a short note on what each system was used for and over what dates. The record is cheap to make on the day and impossible to reconstruct later, and it answers the first questions a buyer's counsel asks about provenance.

5. The Slack question

Slack is in almost every startup archive and among the first records buyers name, and it is the system where the rules are least settled, so it gets its own section. Among the startup workspaces SimpleClosure evaluated for sale, 95% use Slack. micro1's revenue chief has said that if a company won't sell its Slack, customer relationship management, or email records, the rest of the corpus is less valuable. Several buyers name Slack as a source: Scale wants Slack, Microsoft Teams and Google Chat histories with threads and reply structure intact, Mercor's program lists Slack among the tools it connects, and Handshake lists Slack in its examples of sources it buys.

Against that, Corpus Bridge, a broker, warns that in May 2025 Salesforce changed Slack's API terms to prohibit 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 the terms before assuming a dataset can be assembled. The record we keep of Slack's own API terms holds, among the things a developer may not do, "use API Data to train a large language model". The same record describes Slack's own export tool: admins can export public channels in JSON, while private channels and direct messages are not available on Free and Pro and require an approved application. Read on 19 October 2026, the API terms put that ban on an app offered for use outside your organization, so it binds a buyer's connector rather than your own admin export; the guide to selling Slack data reads Slack's terms in full.

Both things are true at once, and neither cancels the other. Slack records are valuable, and a company can export its own workspace with Slack's own tool. Corpus Bridge's warning is about data reached through Slack's API, which is the route an app connected to the workspace uses. What neither side can tell you is how your own plan and your own agreement with Slack treat the route you choose. So before you promise a Slack export to anyone:

1. Check your plan. It decides which channels you can export and how many years exist at all; a Free workspace holds at most one year of history, and private channels and direct messages need more than Free or Pro.
2. Read your own Slack terms, the ones your company accepted, for what they say about exports and about using workspace data to train AI models. Your counsel decides how they apply to the route you pick.
3. Ask each buyer how it would reach the data. A buyer that connects to Slack through an app is using the API; ask it, in writing, how that route complies with Slack's developer terms before you grant access.
4. Prefer the export your own admin runs, recorded per system, and decide who reads the private channels and direct messages before anyone outside the company does: they usually hold the most personal material in the archive.

The same pattern runs through other systems, and the records show it: HubSpot's terms bar using data accessed through the APIs to train, fine-tune, or improve AI, Zendesk's developer terms bar creating, training, or improving any general AI model, and Google's user-data policy for Workspace APIs rules out using user data to create, train, or improve a machine learning or AI model beyond a user's own model. The question to put to every buyer that wants to connect is the same: which interface does your connector use, and how does it comply with that vendor's terms?

6. Three ways data reaches a buyer

Once the price is agreed, the data has to move, and buyers describe three shapes. Which shape a buyer uses decides how much work falls on you, what leaves your systems in identifiable form, and which software vendor's terms come into play.

A read-only connection

Connectors ask least of the holder. Mercor has you choose from its supported tools and link your accounts, and its platform extracts and de-identifies the data. Centific offers read-only access across 188 supported enterprise applications, where you choose which and set the exclusions. Mode has your team sign in to the approved systems, with no passwords handed over, and then exports and de-identifies the agreed copy. Labelbox says it uses read-only connectors to your source systems with zero engineering burden on your side.

The cost of that convenience is control. A connector reads your systems in their identifiable state, so unless the buyer removes personal data before anything leaves (as Labelbox says it does), identifiable records reach the buyer. A connector also reads through the vendor's interface, which brings in the API terms section 5 describes. Before you switch one on, write down the systems, teams and periods it may read, the exclusions in each, and the date access ends; Centific's own words make that list yours to set.

Exports you run

The second shape reverses the work. Troveo connects to none of your systems: no OAuth into your systems, no platform to install, and you spend a few hours on exports with its guidance. Ooak takes either a native export from each tool or read-only access, and puts your time at about an hour. Grepped's agreement summary says data travels by the encrypted transfer method it specifies, to Grepped only. Labelbox says most teams can export the operational data it needs using existing tools.

This is the shape that gives a holder the most say. You see exactly what leaves, you can remove personal data before it does, and the export is your own admin's act under your own account. The price is your time and a few decisions per system, which the table in section 4 sets out. If the buyer then removes personal data itself, the exports you send are identifiable, so the transfer method, the recipient and what happens to your copy after processing belong in the licence.

Code by Git connection

For code, the first step is often a connection rather than an export. SimpleClosure's AssetHub starts from a short form or a connection to your GitHub repository. Turing's process page starts from a screen of the repository against five requirements. Collinear takes private repositories with pull requests and linked tickets, CI logs and coding-agent sessions, and lists database dumps among its sources. A connection reads every revision in the history, including the ones holding keys and passwords someone committed years ago, which is why section 7 puts the clean-up before the connection, not after it. Grant access to the repositories you mean to offer, not to the whole organisation.

7. Code: clean it before anyone reads it

Code is the one asset where the holder is expected to do most of the cleaning, and the buyers' terms say so. pre.dev's agreement has you warrant that the codebase does not contain any personal data, customer data, trade secrets of third parties, credentials, API keys, or passwords, except as expressly disclosed. DataVendor tells you to remove secrets, credentials, customer information, and anything you do not have the right to share before you connect or upload. Corpus Bridge adds the detail that catches most teams: secrets have to be purged from every revision, including old ones.

What buyers then refuse is as specific. Turing accepts only pull requests from a human author, and no LLM-written code. Collinear does not need AI-generated code, or a public framework with a thin layer on top. Troveo says copyleft or redistribution-restricted code needs to be identified and either excluded or handled under its own terms, and that a dependency inventory is a standard part of packaging code. Turing's code screen asks for at least 50,000 lines, English comments and issues, a Dockerfile that builds and runs, a screenshot of the running application and the top three feature pull requests. DataVendor wants a README, setup instructions, architecture or product notes, ticket and pull request history and test information.

The code checklist, in order

1. Export with the full history first, before any plan lapses: every branch, pull request, review and issue, plus design docs and ticket archives, before any subscription lapses. On GitHub that is a mirror clone and a migration archive, the second downloaded within seven days.
2. Scan the whole history for secrets, not only the current branch, then rewrite the history to remove them and rotate every key that was ever committed. A key that sat in a repository for years should be treated as known.
3. Scan for personal and customer data in code, fixtures, test data, seed files and database dumps. Collinear lists database dumps among its sources, which makes them a common place for customer records to travel with code.
4. List third-party code and licences: a licence scan or software bill of materials, with vendored and copied code removed or delivered with its licence. Our rights questions ask for a licence scan, with only the company's own code warranted.
5. Check who wrote it. Corpus Bridge says missing ownership causes most problems: client-owned code, and contractor work without an assignment. Our rights questions ask for signed assignment agreements for all contributors, with gaps listed and excluded.
6. Mark AI-written and bot pull requests. Turing and Collinear count AI-written code out; knowing which pull requests they are keeps your estimate honest.
7. Write the documentation: README, setup, architecture, what the tests cover. It is what a buyer's engineers read first, and you write it once for every buyer.
8. Count net of generated, vendored, duplicated and third-party files, the categories pre.dev may exclude from its own count.

Our guide to selling your codebase to AI companies covers what code is worth and who buys it; this list is the preparation that protects that value.

8. Who removes personal data

Every company archive holds personal data: employees' messages, customers' tickets, names in commit logs. Removing it is the step buyers describe most and agree on least, and the difference is not cosmetic. It decides whether identifiable data ever leaves your systems, which law applies to the transfer, and who carries the risk if the removal misses something. The records sort buyers into four models.

Before it leaves you. Scale says it anonymizes everything inside your environment, before any data is extracted. Labelbox says that when data is exported it first removes all personally identifiable information and then transfers it into its infrastructure. Polyshares uses a specialist PII partner that strips identifying fields before Polyshares or any lab sees the record.

By the buyer, after you transfer. Nyne takes the data as it exists today and removes identifying details on its side. Collinear removes personal data after export, replacing names with consistent pseudonyms. Mode prepares the agreed copy after your team signs in, Troveo handles the anonymization and packaging after you export, Mercor's automated pipeline extracts and anonymises, and Appen detects and removes personal data, rewriting synthetically where the structure has to survive. micro1's master terms oblige it to redact, anonymise or pseudonymise before it sublicenses the data to a customer for AI training, which places the duty after micro1 receives the data and before it passes it on.

By you. DataVendor puts removal on the holder, before upload, and pre.dev has you warrant that the codebase holds no personal data. micro1 adds a list of categories you promise are absent unless the order form says otherwise: health information under HIPAA, biometrics, card and bank account numbers, and children's data, with any found removed at your cost.

To whose standard. Grepped applies the strictest standard that applies, such as for health records or UK and EU data, and has a reviewer try to identify people using the dataset plus public sources before release; if a dataset cannot meet it, Grepped delivers none of it. SuperAnnotate removes identifying detail to the standard your team sets. Corpus Bridge's partner negotiates the standard with the buyer, you approve it, and your own counsel decides what is enough. Labelbox's buying list requires IRB approval or qualified de-identification for clinical data.

What the choice means for the holder

When the buyer removes personal data after transfer, identifiable data leaves the company, and that transfer is the holder's act under the holder's law. For staff in the EU or UK, our rights questions note that only truly anonymous data is outside GDPR, and that de-identified or pseudonymised data stays personal data. For customer records, the question is whether your customer contracts and data processing agreements allow the use. A buyer that does the work after transfer may do it well; the point is that the legal exposure of the transfer sits with you whatever the buyer does next.

When you remove personal data yourself, you control what leaves, but the quality of the removal is your problem, and a customer's email address missed in a test fixture breaches a warranty like pre.dev's. That is why the strongest arrangement separates the two jobs: removal before anything leaves you, and a test of the result by someone who is neither you nor the buyer. Our de-identification standard is built that way: records are rewritten on your own computer, so the originals and the key linking stand-ins stay with you, and before a buyer receives anything an independent provider you choose tests the copy as an attacker would and certifies it before each transfer. The free de-identification tool runs the first part in your browser: it removes names, emails, phone numbers, IDs and addresses from mailboxes, Slack and Office exports, PDFs and spreadsheets without uploading a file. Health records need more, and our guide to HIPAA de-identification for AI training sets out the two routes the law allows; employees' messages raise their own questions, covered in employee emails and chats in AI training.

Whichever model a buyer uses, settle four things in writing before extraction: who removes personal data, to which named standard, who tests the result, and what you see before release. Handshake's scoping already asks the first: who will access and prepare the data, including any required de-identification.

9. What gets refused or counted out

The rejections buyers publish fall into a short list, and nearly every item on it is a preparation step done late or not at all. The table pairs each with the buyer that states it and what to do before the first call.

Two patterns run through the list. The first is that refusal is often total rather than a discount: Grepped delivers none of a dataset that misses its standard, and DataVendor's listing checks look for Git history and captured pull requests before code is listed. A holder that learns this at delivery has lost the time, not just some of the price. The second is that the same archive can pass one buyer and fail another. Turing's code screen asks for English comments and issues, while Corpus Bridge counts languages other than English as adding value, because they are underrepresented in public training data. Preparing well is partly preparing for the right buyers, which is one reason to put a lot before every buyer that fits at once rather than one at a time.

Acceptance criteria are the defence against a late refusal. Nyne agrees use, data categories, volume, privacy constraints, and acceptance criteria before anything is collected or transferred, and that is the order to ask for everywhere: criteria written before extraction, tested against objective measures, with a fixed review window. micro1's terms show what a window looks like: 30 business days after delivery to reject in writing, with silence counting as acceptance. Our guide to when AI data buyers actually pay covers how acceptance ties to payment.

10. Pages that contradict themselves

Three buyers publish preparation terms that disagree with themselves, on their own pages, on the same day, and two more disagreements run across buyers. None of this suggests bad faith; pages are written at different times by different people. But it means a holder cannot prepare against one page and assume the rest agree.

Turing on code. Its main page says code is "never bought on its own": communications, tickets, wikis and databases stand alone, and code is welcome alongside them. Its own pages also say repositories typically pay $10k to $100k+, and its process page sets out a full screen for a single codebase. And on that screen, the length of a linked issue differs between two of its pages: 10 to 6,000 words on the process page, 20 to 2,000 words in the technical overview. An issue of 15 words, or one longer than the overview's ceiling but within the process page's, passes the process page and fails the technical overview.

Polyshares on what leaves before an offer. Its data-handling page says nothing leaves your systems until Polyshares has made an offer and you have accepted it, and the same page says someone on the team reads the anonymized sample before Polyshares prices the record. A sample read before pricing is data that left before the offer. Ask when the sample is taken, under what agreement, and who anonymises it.

Grepped on how data moves. Its business page describes read-only access to the approved sources; its agreement summary says data travels by the encrypted transfer method it specifies. One is a connection into your systems, the other a transfer out of them, with different preparation for each.

Language, across buyers. Turing's code screen asks for English-language comments and issues, and Corpus Bridge counts languages other than English as value. Not a contradiction within one buyer, but a reason to read each buyer's own rule before you translate, filter or drop anything.

The Slack disagreement in section 5 belongs on this list too, though it is between a broker's warning and several buyers' source lists rather than within one buyer's pages.

How to pin it down

Ask the buyer in writing which wording applies to your sale, and keep a dated copy of the page you relied on. We date every reading of a buyer's page for this reason: each link in this guide opens the record of the buyer's exact words and the day they were read, so a holder can show a buyer what its own page said. The licence terms page collects the published clauses across buyers, and the offer check, for a buyer whose offer you already hold, lists the clauses to read first and the questions to send back.

11. The order of work: a checklist

Put together, the buyers' requirements give a sequence in which each step uses the one before it and nothing is done twice. The list below gives the order, what each step produces and why it sits where it does.

1. Name who can sign. The person with authority over the company and admin authority over its systems. Turing buys only from someone with admin authority, and for a company that is closing, the person the law lets act for it.
2. Write the inventory. Per system: what it holds in its own unit, years, seats, admin, export route, links to other systems, exclusions and known gaps, from the admin consoles, with an estimate from the admin console enough to start. No files.
3. Build the rights file. Customer contracts, employee agreements, third-party material, open-source licences, who appears in the data and whether they agreed. Being able to export a record is not permission to license it. The readiness questions walk through each.
4. Decide who removes personal data, and to which standard. Before any buyer conversation, so that the first conversation can state it. This decides which delivery shapes you can accept.
5. Secure the exports, with history, before anything lapses. Native admin exports per system, a record of each, stored where you control them. Appen's warning is the reason this comes before buyers rather than after: once licences lapse, the record often becomes unrecoverable.
6. Clean the code. Secrets purged from every revision, licences listed, AI-written pull requests marked, documentation written, counted net.
7. Prepare a de-identified sample. Small, representative, drawn from the reviewed set, removed by the same method as the delivery, sent only under a signed confidentiality agreement.
8. Write the datasheet and the manifest. The inventory, the rights answers and the sample turned into the one description every buyer receives, counted net, because under terms like micro1's an inaccurate manifest can reverse a paid sale.
9. Settle delivery and acceptance in the licence. The shape per system, who removes personal data and to which standard, objective acceptance criteria written before extraction, a review window, and what you see before release.

Steps 1 to 5 need no buyer at all, and they are where most of the time goes; steps 6 to 9 move fast once they are done. A holder that walks into its first buyer conversation with steps 1 to 4 finished can answer most scoping questions on the call, and one with step 5 done has removed the deadline that otherwise sets the pace of a closing company's sale. The deletion clock counts the days each system keeps your data after you cancel, and the main selling guide explains how this order protects your position with buyers.

12. How preparation works in a sale we run

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. Preparation in a sale we run follows the order above, with three documents carrying most of it (the valuation, the datasheet and the rights file) and three clauses of the mandate fixing who does what.

The valuation comes first, and needs no upload. The valuation starts from your answers about your systems, close to the inventory of section 2 in question form. If you add exports, it measures them on your own computer. Of your data, we hold only what you choose to share to value and sell it: your answers and counts, a de-identified sample whose text we delete once it is measured, the rights file and the datasheet. The valuation binds no one.

The datasheet is written for you and approved by you. 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 your answers and your valuation, and that you approve in writing before it goes to any buyer. Those headings are the questions buyers ask in section 1, answered once, so every buyer receives the same description and prices the same thing. We pass it on labelled as your statement, saying its figures come from your own valuation and any sample you sent. The free datasheet builder lets you draft the same document yourself, with nothing saved. Behind it sits the Rights File: your answers on who owns each part of the data, which contracts limit it, who appears in it and whether they agreed.

You deliver, directly. Under the mandate, delivery under a licence is from you, or from a delivery or de-identification provider you choose, to the buyer directly. We do not send or show a buyer any part of the data, and each buyer pays you directly. So the export work of sections 4 to 7 stays yours or your provider's, and the delivery shape is a term of each licence, not something we decide for you.

You decide who removes personal data. The mandate says we are not the de-identifier of record, including where you use our de-identification tool on your own computer, and that you decide who removes personal data and to which standard. We advise that it is removed before anything leaves you, by you or an independent provider you choose, and certified by an independent provider before each transfer, as our de-identification standard describes; we propose that a buyer removes personal data itself only if you instruct us so in writing. That is the first model of section 8, made our default advice.

The round then does the rest. Every buyer whose published requirements fit the data receives a first description that does not identify you; each that gives its confidentiality undertaking receives the same datasheet with one deadline for offers, and every offer reaches you with its full terms as the buyer stated them. Because the datasheet already states the delivery format, the standard for personal data and the known limits, the offers that come back can be compared on those terms as well as on price: a buyer that wants to connect to your systems against one that takes your export, a buyer that removes personal data after transfer against one that accepts your certified copy. 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 you.

Questions people ask

What do AI data buyers ask for before making an offer? A description per system first: what it holds, years covered, seats and what stays out ( Polyshares, Troveo, DataVendor). Then, at most buyers, a sample: SuperAnnotate reviews one before its valuation and Polyshares reads one before pricing.

Do I need to upload data to get a price? Not for the first step. Polyshares' intake asks for record counts, not files or exports, Turing accepts estimates per system, and our valuation starts from your answers with no upload. A sample usually comes before a firm price.

How big should a sample be? No buyer we read gives a size. Grepped and DataVendor ask for a small representative sample; Appen reviews a representative sample pack with you before licensing. Draw it after the rights review, de-identified by the method the delivery will use.

Can I export my company's Slack to sell it for AI training? Check your own plan and Slack terms first. Corpus Bridge says Slack's API terms bar bulk export through the API and use of that data to train language models since May 2025, while Scale and others list Slack as a source. Your plan also decides how much exists: a Free workspace keeps at most one year.

What format do buyers want the data in? Each system's own full export, with its history: PST for Outlook, JSON for Zendesk, a full site backup for Jira, and for code a repository with its Git history and captured pull requests. A Jira CSV carries no changelog history.

Who removes personal data, me or the buyer? It depends on the buyer. Scale removes it inside your environment before extraction, Nyne after you transfer and Collinear after export, and on DataVendor you do. Decide before the first call, and name the standard and who tests the result.

Do I have to remove secrets from my code before selling it? Yes, at most buyers. pre.dev has you warrant the code holds no credentials, API keys or passwords unless disclosed, and Corpus Bridge says secrets must be purged from every revision, including old ones. Rotate any key that was ever committed.

How long does preparation take? Your own time can be short: Ooak puts it at about an hour and Troveo at a few hours on exports. The buyer's processing is longer: Mode collects and de-identifies over 15 to 30 days, and Centific reaches a first accepted contribution in six to ten weeks. In our reading, the rights file usually sets the pace.

What this means for you

Preparation decides most of what a buyer refuses or deducts, and almost all of it can be done before you speak to one. In order:

1. Name who can sign for the data, and check that person has authority over both the company and its systems.
2. Write the inventory per system from the admin consoles: unit counts, years, seats, links, exclusions, known gaps. No files yet.
3. Answer the rights questions before anything is exported: customers, employees, third parties, licences, authors.
4. Decide who removes personal data and to which standard, and who tests the result, before the first call.
5. Export with history while every account is live, using each system's native admin export, and record each export.
6. Clean your code yourself: secrets out of every revision, licences listed, AI-written pull requests marked, counted net.
7. Send a sample only after the rights review, de-identified, under a signed confidentiality agreement, to every buyer at once.
8. Put delivery and acceptance in the licence: the shape per system, objective criteria fixed before extraction, a review window, and what you see before release.

Start with what the data is worth: the valuation prices it against public sales and offers, binds no one and needs no upload. The datasheet builder turns your answers into the one description buyers ask for, the readiness questions show what blocks a sale before a buyer finds it, and the de-identification tool removes people from your exports on your own computer, to the standard we advise for every sale. If you already hold an offer, the offer check lists that buyer's clauses to read first. The rest of the path is in how to sell company data to AI labs, code in selling your codebase to AI companies, staff messages in employee emails and chats in AI training, health records in HIPAA de-identification for AI training, and payment in when AI data buyers actually pay. How it works sets out a sale we run, step by step.

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