Skip to content

Insights · 6 min read

How to Prepare Company Data for AI Labs: An Eight-Step Checklist

Most of the work in selling data happens before any buyer sees a file. Here is the order that saves rework.

Bearish AI ·


An export of your Git repositories, chat workspace and ticket system is not something an AI lab can use. It is a pile of raw material with unknown rights, live credentials and a lot of real names. Buyers pay for data they can train on or turn into tasks, so the preparation is the product. This checklist walks through the steps in the order that avoids doing work twice.

Step 1: Take inventory of what you hold

List each source: code and Git history, team chat, tickets and issues, code reviews, design files, recordings, support conversations and business documents. For each one, write down the date range, the rough size, who created it, where it lives and which other sources it points to. A commit message that cites a ticket number, or a chat thread that links to a pull request, is a join key. Those links are what turn separate archives into a record of how a decision was made.

Step 2: Review rights before you touch the files

Decide what you are actually allowed to license. Check employment and contractor agreements, customer contracts, third-party and open-source licenses inside the code, and the privacy notices your customers saw. Buyers will ask, and they know paperwork is where problems hide: an audit of more than 1,800 text datasets found license information omitted on more than 70 percent of entries on popular dataset hosting sites, and wrong on more than 50 percent.

The regulatory side is real too. The US Federal Trade Commission has warned that using customer data for model training in ways customers were not told about can be a violation, and it has previously required companies to delete models built on unlawfully obtained data. Reported sellers of company archives exclude HR records, and buyers say they scrub again on their side. Have a lawyer review the result. Nothing in this checklist is legal advice.

Step 3: Find and rotate secrets

Credentials hide in old commits, config files, chat messages and screenshots. Scan the whole history, not only the current branch. GitHub’s secret scanning, for example, covers the entire Git history on all branches. If you find a live key, rotate it first. Rewriting history does not remove copies from forks and clones, so a rotated key is the only fix that holds.

Do not trust one tool. In the StarCoder team’s work on code PII, a regular expression for keys reached an F1 score of only 6.74 percent, while a trained model reached 70.41 percent. Combine patterns, models and a human review of samples.

Step 4: Pseudonymize the people

Replace names, handles, emails and other identifiers with stable stand-ins, so the same person keeps the same stand-in across every source. That preserves who argued, who reviewed and who fixed, which is much of the value. Regulators are clear that pseudonymized data is still personal data, so this reduces risk and does not end the legal review. Our guide to pseudonymizing data for AI training at /insights/pseudonymizing-data-for-ai-training covers the details.

Step 5: Deduplicate and clean

Remove vendored dependencies, generated files, build output, bot chatter and repeated boilerplate. Duplicates matter beyond tidiness. Researchers found that models trained on deduplicated data emitted memorized text about ten times less often, and that overlap between training and test sets affected more than 4 percent of the validation sets of standard datasets.

Step 6: Link the records

Keep the identifiers that connect a bug report, the discussion about it, the commit that fixed it and the review that approved it. Do this after pseudonymization so that links and people stay consistent. Linked episodes show reasoning and mistakes, which a pile of separate files does not. Our article on how preparation changes value, at /insights/how-data-preparation-increases-data-value, shows why buyers care.

Step 7: Document what you did

Write a short data card: sources, dates, size, what was removed and how, known gaps, and the license basis. See /insights/data-cards-and-provenance-for-ai-training-data. A buyer’s legal and research teams will ask for exactly this.

Step 8: Cut a sample

Prepare a small, representative slice with the same pipeline as the full set, so the buyer is judging what they would actually receive. Do not hand-polish the sample. A sample that is cleaner than the rest erodes trust the moment the full delivery arrives.

Which source to start with

You do not have to prepare everything at once. Code with its Git history is usually the anchor, because it can be built and tested and because other sources gain meaning when they point to it. Chat and tickets come next: reporting on archive sales describes buyers valuing variety and depth, including disagreements and tricky judgment calls, which is exactly what discussions contain. Recordings and support conversations carry the most personal and customer information, so most owners do them last. Prove your pipeline on the easiest source, measure what it removed and what it missed, then repeat it.

Do the steps in order. Linking before pseudonymizing means breaking the links later, and preparing before checking rights means paying to clean data you cannot sell. The common slips are collected in /insights/mistakes-when-selling-company-data.

What you should have at the end

  • Rights memo: what you can license, what you excluded and why, reviewed by a lawyer.
  • Scrubbed archive: secrets rotated, identifiers pseudonymized, mapping kept separate and secure.
  • Clean, linked records: duplicates and generated files removed, cross-references intact.
  • Data card: a plain description of what is inside and how it was processed.
  • Sample: a small slice built with the same process as the full set.

If you want to see what this preparation could change in the value of your archive before you start, the free estimator at /estimate gives a conservative range for the data as it is and for the data once prepared. Bearish AI does this preparation work itself: cleaning, pseudonymizing, linking and grading, so data sells for more than it would raw.

Questions we get

What data do AI labs want from companies?
Records of how real work gets done: code with its history, plus the discussions, tickets, reviews and documents around it. Epoch AI’s interviews with people in the field describe growing demand for enterprise workflows such as CRM updates, expense reports and spreadsheets, alongside software engineering.
Do I need to remove personal data before selling company data?
In practice, yes. Sellers and buyers both scrub personal details. Removal or pseudonymization is only one part of the work, though. Rights, confidentiality and licensing need a separate review, and a lawyer should check it.
Can I sell data that contains customer information?
Often not without careful review. Customer contracts and the privacy promises you made may restrict it, and the FTC has said using customer data for AI training contrary to those promises can be unlawful. Many sellers leave customer records out. Ask a lawyer before including them.
How long does it take to prepare company data?
It depends on size, the number of linked sources and how clean the rights position is. There is no public benchmark. See /insights/how-long-does-it-take-to-sell-data-to-an-ai-lab for the stages that set the pace.

Sources

  1. Longpre et al., “The Data Provenance Initiative: A Large Scale Audit of Dataset Licensing & Attribution in AI” (2023)
  2. FTC Office of Technology, “AI Companies: Uphold Your Privacy and Confidentiality Commitments” (9 January 2024)
  3. FTC, press release on the Everalbum settlement over facial recognition and deletion of models (2021)
  4. MIT Technology Review, “AI labs are buying data from dead startups to train models” (October 2026)
  5. GitHub Docs, “About secret scanning”
  6. GitHub Docs, “Removing sensitive data from a repository”
  7. Li et al., “StarCoder: may the source be with you!” (2023), PII redaction section
  8. European Data Protection Board, “Guidelines 01/2025 on Pseudonymisation” (adopted 16 January 2025, version for public consultation)
  9. Lee et al., “Deduplicating Training Data Makes Language Models Better” (2021)
  10. Epoch AI, “An FAQ on reinforcement learning environments” (January 2026)