Who Owns Your AI-Written Code? What Acquirers Will Ask

A quiet shift has happened in M&A diligence: buyers have started asking who actually owns the AI-written code. Not "do you use AI?" — at this point everyone uses AI, and a company that claims it doesn't is its own red flag. The new questions are sharper: can you prove that a human contributed to and reviewed the code your product runs on, and can you show it the way you'd show any other asset you're selling?

If your team has been shipping with AI for two years and nobody has thought about what a buyer will ask, this is the checklist to work through before the data room opens. (I'm a technologist, not a lawyer — treat this as the technical preparation, and get counsel for the legal specifics.)

Why ownership isn't automatic

In the U.S., copyright requires human authorship. When a model generates code, what you can actually claim depends on the human contribution around it — the prompting, the review, the modification, the judgment about what ships — and on the terms of the tools and models you used. A buyer can't just assume the code they're acquiring is clean IP, and their counsel knows it: law firms now publish diligence checklists aimed specifically at AI-built code. The practical consequence is simple. "The AI wrote it" is not an ownership story. "A human directed, reviewed, and approved it, and here are the records" is.

The five things to have ready

1. Records of human review. Source-control history that shows real human contribution to material code — commits, review evidence, decisions a person made and can explain. Not "the model wrote it and I clicked merge." If your review discipline was genuine, this already exists; the work is making it legible to a non-engineer.

2. A license inventory that includes model weights. Most companies have some handle on their open-source licenses. The new part is everything underneath: datasets you used, and the licenses on any model weights you rely on — each with its obligations spelled out. Model licenses are not all permissive, and "we didn't check" is not an answer a buyer accepts.

3. Your AI tools' business terms and data-retention settings. Which commercial AI tools touched proprietary code, on what terms, and with what retention settings. The question underneath is: was your code used to train someone else's model? Consumer accounts with default retention used on proprietary code are the finding buyers look for.

4. Training-data provenance — if you trained or fine-tuned any model. Data scraped against site terms, or personal data used without consent, creates contract, privacy, and deletion exposure that follows the model into the deal.

5. A written AI-use policy and governance evidence. A policy on employee use of generative AI in production, a named owner for AI standards, documented human oversight. This is the part that surprises founders: buyers ask for the policy, not just the practice, because the policy is what survives the people.

The model-origin question

One more, if you sell to government or regulated buyers: where did the model come from? The federal ban on DeepSeek and products built on it now flows down to subcontractors, not just primes, and similar restrictions on other Chinese-origin models are being debated; regulated customers increasingly put origin questions in security questionnaires. You don't need to have picked the "right" model — you need to be able to answer the question, and to show the model layer is swappable if a customer's contract requires it.

I ran this on my own build

I practice what I'm describing. Pilot for Trades — a full field-service platform I built solo with AI in about six months (the build story) — went through the same diligence treatment I'd run on a client's codebase. It's an R&D build · never released · no customers — by design, and it was architected to SOC 2 controls — built to the controls, not audited. But it carries a full diligence suite: a commit history and design records showing that every AI output was directed, reviewed, and accepted by one human owner; a documented license posture for its dependencies, with a formal SBOM and license report named as the next step rather than assumed; security and compliance architecture documented as designed; and an honest ledger of known limitations. I built that packet because a diligence suite run on your own build is the most credible way to know exactly what a buyer's process finds — and what it costs to be ready versus to reconstruct.

The cheap-now, expensive-later math

Every item on this list is cheap to have ready and brutal to reconstruct in a data room. Review records exist as a byproduct of good discipline — the work is assembling, not creating. A license inventory is a few days of attention. A written AI-use policy is a document. Set against the timeline pressure of a live deal, where every open question extends exclusivity and every shrug gets priced into the valuation, this is the highest-leverage engineering work you can do in the quarter before a raise or a sale.

The companies that kept review discipline while they shipped fast answer these questions in an afternoon. The ones that didn't answer with a shrug — and the buyer prices the shrug.

If diligence is coming

This is exactly the kind of readiness work I do: an AI-augmented Technology Diagnostic sizes where you stand in writing, and the AI-built-code checklist slots straight into it. Book a call and we'll talk through what a buyer would find — before a buyer finds it. You can also point your team at the free AI-First Readiness Scorecard for a quick self-read, or start with how investors spot technical risk early.

Tom Lang has led engineering organizations from founding teams to 150+ engineers across regulated, reliability-critical industries, and provides AI-augmented fractional and interim CTO leadership — including technical due-diligence readiness — through Heart of the Rockies Management Consulting.