AI’s next gold rush is the work your company almost deleted

AI companies are looking beyond finished content to the histories behind real work. That could create a new licensing market, but an archive is not an asset you can sell just because you can export it.


AI’s next gold rush is the work your company almost deleted
Image Credits Credit: Numan Ali on Unsplash

Your next customer might not buy what your company makes. It might license what your company learned from making it.

Consider a software business with a product it no longer sells. The final codebase is only part of what remains. There may also be years of bug reports, proposed fixes, rejected approaches, tests, and decisions.

To the founder, that material looks like the residue of an old business. To an AI developer trying to teach a system how to complete real work, some of it could be the beginning of a useful dataset.

The question is no longer simply whether a company has data. It is whether that data preserves a problem worth learning from, an outcome worth checking, and rights that can actually be licensed.

On October 9, micro1 announced a commitment to spend $1 billion over the following 12 months acquiring and licensing enterprise operational data. It said the material would support reinforcement-learning environments that reflect real workflows, competing priorities, and exceptions.

This is a spending commitment, not a billion dollars already distributed to businesses. But it makes the direction of interest unusually explicit.

There is already money changing hands in adjacent categories. Wiley reported $14 million in AI licensing revenue for the quarter ended July 31, 2026. That is publisher revenue, not a price guide for a startup’s archive.

The distinction matters: evidence that one kind of data sells does not mean everything sitting on a company server has a buyer.

The answer is not the whole lesson

A finished document shows what a team decided. It often conceals the uncertainty that made the decision difficult. A functioning application shows what the software does now. Its history can reveal which change broke an assumption, which test caught the failure, and how someone repaired it.

For a system expected to perform work rather than merely describe it, that difference matters. Imagine asking an agent to fix a payment bug. A clean example of payment code may help.

A reproducible task containing the original defect, relevant context, and a test that distinguishes a genuine repair from a plausible-looking answer gives an evaluator something more concrete.

This is already visible in how AI capabilities are tested. OpenAI’s SWE-Lancer benchmark drew on more than 1,400 real freelance software-engineering tasks. Its GDPval evaluation used professional tasks and reference materials across 44 occupations.

Neither establishes that an arbitrary corporate archive will improve a model. They do demonstrate the usefulness of evaluating systems against work with context and a checkable result.

There is a revealing limitation, too. GDPval’s original description acknowledges that its one-shot tasks do not capture all the iteration and context-building involved in real work.

That is precisely why I think some work histories deserve closer attention. The opportunity is not simply to collect more answers. It is to preserve enough of the problem for someone else to attempt it meaningfully.

The release note tells you what shipped. The history can tell you what it took to get there.

An archive is not yet a product

The phrase “AI training data” hides several different jobs. Material used to teach a model is not identical to a held-out test used to assess it. Nor is either the same as an environment in which an agent takes actions and receives feedback.

SWE-Lancer and GDPval are evaluations; micro1’s announcement describes environment building. A seller needs to know which job a buyer is paying for.

For example, a collection of resolved support tickets might help describe recurring problems. Turning it into an evaluation would require a defensible answer to what counts as a successful response.

Turning it into an interactive environment would require more work still: relevant state, available actions, constraints, and a way to judge the result. These are possible uses, not automatic properties of a ticket export.

That changes the inventory question. I would ask whether a record connects a problem to its context and outcome; whether the outcome can be verified; whether similar material is already easy to obtain; and what it would cost to prepare the record safely.

A million disconnected messages may be less useful than a smaller collection of well-documented tasks. Volume alone answers none of those questions.

This is the opportunity we are pursuing with Rightmark: helping rights holders assess and license private datasets, including code histories and operational records. An initial appraisal can begin with a description rather than handing over an entire archive.

That separation matters. Establishing potential relevance should not require surrendering access first.

For code, our published Repo Check tool is designed to run locally and produce a limited report of counts and fixed labels rather than upload source code. Such a report can support an initial discussion; it cannot establish every ownership right or guarantee a sale.

Administrator access is not a licence

The most dangerous version of this market would turn “we have an export button” into “we are entitled to sell everything behind it.” A founder with administrator access is not automatically a founder with licensing rights.

A business archive can mix employee work, contractor contributions, client material, third-party software, and information subject to confidentiality restrictions. These are different rights questions. At Rightmark, the documented review includes ownership, assignments, restrictions, and prior licences, rather than treating possession as sufficient.

Privacy adds another question. Replacing a name with a number does not necessarily make a person unidentifiable. The UK Information Commissioner’s guidance distinguishes pseudonymisation from anonymisation and explains why additional information and the means available to identify someone matter. A scrubbed-looking export is not, by itself, privacy clearance.

The European Data Protection Board likewise calls for case-by-case assessment in the AI context, including people’s reasonable expectations when legitimate interests are considered. A licensing agreement cannot substitute for doing that work. The applicable obligations depend on the data, the parties, and the proposed use.

There is a commercial question as well: what exactly does the buyer receive? Permission to train a model, run an evaluation, construct an environment, or create a derived dataset can produce materially different exposure.

Exclusivity, sublicensing, and what survives the end of a contract deserve explicit answers. Those are deal terms to establish, not details to discover after delivery.

My operating principle is simple: assess before sharing, narrow before transferring, and decline a transaction when the useful material cannot be separated from unacceptable risk. Some archives should never enter this market.

The most interesting inventory may be ordinary

Imagine a small industrial-software company. It has no famous publication, no consumer social network, and no ambition to train a foundation model. What it does have is a carefully maintained record of unusual customer requirements and the engineering work needed to meet them.

One project might contain a reproducible failure, the constraints that ruled out an obvious fix, a reviewed change, and a test showing that the customer’s problem was resolved. With suitable rights and preparation, that is a candidate for assessment. It is not automatically a valuable dataset, but it is a more intelligible proposition than “we have six terabytes.”

The same reasoning could apply to a documented reconciliation process or a versioned design task. The unit of interest is not necessarily a company’s entire memory. It may be a tightly bounded episode of work whose context and outcome can be understood.

That also changes how I would approach a buyer. Start with the work represented, its provenance, and a limited description. Establish a relevant use case. Then investigate rights, preparation, and a controlled sample. The headline number attached to somebody else’s deal is not a substitute for that conversation.

Do not turn the workplace into a recording studio

A market for work histories creates an incentive worth resisting: recording more of everyone’s activity simply because it might become saleable. That would be a bad bargain. Employees should not have to wonder whether every aside is being preserved for a future data customer.

Nor should speculative licensing revenue become an excuse to ignore retention limits, deletion commitments, or basic security discipline.

Better documentation of a legitimate business process is different from indiscriminate surveillance. A useful, narrowly scoped task record is a better starting point than a permanent archive of everything people said.

There will also be archives that cost more to clear and prepare than a buyer will pay. There will be material whose strategic value is greater inside the company. And there will be attractive offers that should be rejected because the underlying permission is missing.

The opportunity is not that every business has discovered free money. It is that some businesses may possess a form of documented expertise they have never evaluated as a separate product.

The first customer paid for the work to be done. A second might pay for a carefully licensed way to learn from it. The companies that deserve to benefit will be those that can explain both what the record teaches and why they have the right to share it.

Get the TNW newsletter

Get the most important tech news in your inbox each week.

Thanks! Check your inbox to confirm your subscription.

By subscribing you agree to our Privacy Statement.