Ask most founders whether they own the code their team shipped and the answer comes back instantly: of course, we paid for it, our engineers wrote it. Ask the same question about code an AI assistant helped generate, and the confidence should drop, even if it usually doesn't. Ownership of AI-assisted code isn't automatic, isn't uniform across tools, and isn't a question most founders think to ask until it matters, in an acquisition, a fundraise, or a dispute with a former contractor, by which point it's considerably harder to fix than it would have been to ask up front.
Why this is genuinely unsettled, not just a technicality
Copyright law was built around human authorship, and most jurisdictions still require a human creative or intellectual contribution for something to be protectable at all. Code that an AI model generated with minimal human direction sits in a genuinely gray zone: some of it may not be copyrightable by anyone, which sounds harmless until you realize it means you may not be able to stop a competitor from using the exact same output, or enforce exclusivity over it in due diligence. This isn't a settled question with a clean answer yet. It's an active, evolving area, which is exactly why relying on assumption instead of a specific, current answer for your situation is the risky part.
The three places this actually bites
- Tool terms of service. Some AI coding tools claim broad rights to use your prompts and generated output for model training or other purposes, depending on your plan and settings. Few founders read this before adopting a tool company-wide, and fewer still revisit it as the tool's terms change over time.
- Training data provenance. If a model was trained on code under restrictive licenses, there's a live, unresolved question about whether output resembling that code carries any of the original license's obligations. This is being actively litigated in multiple jurisdictions right now, and the outcome isn't fully settled.
- Contractor and agency agreements. A standard "work made for hire" clause was written assuming a human did the writing. If a contractor used AI assistance extensively, it's worth confirming your agreement's IP assignment language is actually broad enough to cover that, rather than assuming decades-old boilerplate anticipated this.
What investors and acquirers are starting to ask
Technical and legal due diligence is catching up to this faster than most founders expect. It's now a reasonable, increasingly common question in a diligence process: which parts of the codebase were AI-assisted, what tools were used, what those tools' terms actually say about ownership and training rights, and whether every contractor's agreement was actually broad enough to assign IP generated with AI assistance. A founder who's never considered the question looks meaningfully different in that conversation than one who can answer it specifically and confidently.
"We own our code" and "we've verified we own our code" are different claims. Only one of them survives a diligence process intact.
What to actually do about it
Start by knowing which tools were used across the codebase and reading their current terms, specifically around training data use and output ownership, not just skimming the marketing page. Review contractor and agency agreements for IP assignment language broad enough to explicitly cover AI-assisted work, not just human-authored work. And if a fundraise, acquisition, or major partnership is on the horizon, get a straight answer from someone who's actually looked, rather than carrying an assumption into a data room and finding out it was wrong in front of the people deciding whether to write you a check. This is the same principle behind what IP ownership actually means when you hire a dev shop: the clause in a contract that everyone assumes is standard is usually the one worth reading most carefully, and "we used AI to help build it" is a new enough wrinkle that most standard clauses were never written with it in mind.
