Three weeks ago, a founder shared something with me. His startup managed clinical workflows — paying customers, growing ARR, preparing for Series A. The investor's legal team ran standard due diligence. Their IP lawyers asked one question:
"Who owns the copyright to this codebase?"
He didn't have an answer.
The code was almost entirely written by Cursor. Reviewed, tested, deployed. But nobody had ever systematically asked: which parts had meaningful human input, and which parts were AI output accepted wholesale? That question was now threatening the round.
Here's what I keep seeing: this isn't a developer problem. It's a PM problem.
You think you own the product. You have customers, revenue, a roadmap. But technically — legally — you might be operating on a codebase you don't fully own.
Here's why.
US copyright law is unambiguous: only humans can hold copyright. Anthropic and OpenAI both say in their terms that AI outputs belong to you. That's contractually true. But contractual ownership and legal copyright protection are not the same thing.
Code accepted wholesale from an AI — without meaningful human creative input — may not be eligible for copyright protection. Which means a competitor could run the same prompts, get similar output, copy your product, and you'd have no recourse.
The second risk gets far less attention: open-source contamination.
AI models were trained on millions of GitHub repositories. Some were GPL, LGPL, or AGPL licensed. These models can "remember" that code and produce structurally similar outputs in your production environment. If you don't have a license scanner — FOSSA, Snyk, something — running in your CI/CD pipeline, you don't know what's been introduced.
What happens if you unknowingly include GPL code in a commercial product? You may be required to open-source it. For a SaaS product you're selling as a service, that can mean effectively making your product public.
In the clinical software space I work in, this kind of legal exposure bleeds into customer trust. When a hospital administrator asks "is this code properly licensed?", "an AI wrote it and I'm not sure" is not a defensible answer.
So what do you actually do?
The answer isn't to stop using AI. It's to treat AI output as raw material.
Raw material means: you take the output, read it, change it, decide. Code committed without a genuine "review, modify, decide" process may legally belong to no one. But documenting that process is now a PM responsibility. Which decisions were human decisions? Who made the architectural choices? These questions protect you in a future legal dispute.
More practically: establish a commit message convention for AI-assisted work. Something like "AI-assisted: reviewed and modified." It sounds trivial. During a due diligence audit, it's the difference between provable human authorship and ambiguity.
And this isn't only a legal matter.
If your Series A investor doesn't ask, your Series B will. During an acquisition, the buyer's legal team will. A large enterprise customer's vendor risk assessment will.
You don't know when the question is coming. But when it does, you want the answer ready.
The speed of building with AI today is remarkable — a three-person team shipping enterprise software. That's real. That's valuable.
But you can lose just as fast: in a funding round, an M&A process, a competitor lawsuit.
AI writes the code. Humans own the product. Except "owning it" now requires documentation.