The AI Didn’t Sign Your IP Agreement

8 min read

For C-level leaders and boards pushing organizations toward an AI-first future, especially those exploring how far AI can replace or reduce human engineering capacity, speed cannot be the only measure of progress.

AI may help teams generate more code, modernize faster, and reduce certain forms of manual work. But when AI becomes part of how the product is built, leaders also inherit a new ownership problem.

Before leaders celebrate how much code AI is generating, they should make sure the company can support a more durable claim: Can we prove we have the rights to use, sell, enforce, and defend the software we are shipping?

When I was hired as a software engineer, one of the first documents I signed was an intellectual property agreement.

Later, as an engineering and technology leader, I saw how much organizations depend on that accountability extending across employees, contractors, open-source software, and technology vendors. Through enterprise customer reviews, acquisitions, and due diligence, it was never enough to know that the software worked. We also had to explain where it came from, who was responsible for it, and whether the company had the right to use and sell it.

The premise was simple. I was being paid to build software for the company. Anything I designed, wrote, improved, or contributed to in that role belonged to the organization.

That model worked because the accountability chain was clear. The individual who wrote the code could assign the rights, certify the source of the contribution, and be held responsible for any copyright, licensing, trade secret, or invention issues it created.

AI-generated code changes that chain.

A model cannot assign rights. It cannot certify originality or promise that a generated function, test suite, migration script, or refactored module is free of third-party code. It cannot stand behind open-source license compliance.

For executives pushing AI initiatives, this deserves more attention.

The speed gains can be real, especially in the right systems. So are the ownership gaps.

GitLab’s 2026 AI Accountability Report found that 91% of organizations have two or more AI coding tools in active use, 78% report that developers are writing and committing code faster, and 43% say they cannot reliably distinguish AI-generated code from human-written code in their own codebase. The same report says 80% of organizations adopted AI tools faster than they developed policies to govern them. (GitLab)

That is the leadership concern: companies are accelerating code creation faster than they are maturing code accountability.

Vendor terms only close part of the loop

Many executives hear that AI vendors assign output rights and assume the ownership concern has been handled.

That assumption is too thin.

OpenAI’s terms say that, as between the user and OpenAI, the user owns the output, and OpenAI assigns whatever rights it may have in that output. The same terms also say output may not be unique and that other users may receive similar output. (OpenAI)

GitHub’s terms are especially relevant for software teams. GitHub says it does not claim ownership of user inputs or outputs. In the same area of its terms, GitHub warns that output may resemble training data, may include material subject to third-party copyrights or open-source license terms, and that the user is responsible for determining whether a third-party license is required. (GitHub Docs)

That distinction matters.

A company may have permission from the AI vendor to use the output. That does not automatically create a clean ownership trail. The generated code could resemble someone else’s code, omit required attribution, introduce open-source obligations, include a vulnerability, or weaken the company’s ability to claim exclusive rights.

The U.S. Copyright Office has also clarified the human authorship issue. Its 2025 AI copyrightability report concluded that works generated entirely by AI are not copyrightable, that prompts alone generally do not create enough human control, and that only human contributions in AI-assisted works are potentially protected. (U.S. Copyright Office)

For software leaders, the practical implication is straightforward. The human contribution needs to be visible.

A developer who designs the approach, uses AI for assistance, reviews the output, rewrites sections, integrates the code, tests it, and accepts responsibility gives the company a stronger ownership story. Large blocks of AI-generated code accepted with light review create a weaker trail.

The warning signs are already visible

There are still few public examples of companies shutting down because AI-generated source code directly infringed another company’s code. That pattern may be happening quietly through customer audits, diligence reviews, settlements, or remediation work.

The public warning signs are already strong enough.

ROSS Intelligence is the clearest example of a shutdown. ROSS built an AI-powered legal research platform and was sued by Thomson Reuters over alleged use of Westlaw content to build a competing product. ROSS later ceased operations, attributing the shutdown to the legal fight and insufficient funding. A federal judge later rejected ROSS’s fair-use defense in a ruling Reuters described as the first U.S. ruling on fair use in AI-related copyright litigation. (The Verge)

ROSS was not a source-code generation case. It still shows how AI-related IP risk can become existential. Financing, acquisition options, customer confidence, and runway can all be affected before a final judgment.

PearAI gives software leaders a more direct open-source lesson. TechCrunch reported in 2024 that the YC-backed AI coding editor admitted it was essentially a cloned copy of VS Code and Continue, another AI editor covered by the Apache open-source license. PearAI initially applied its own closed license, which its founder said was written by ChatGPT, before changing course after public backlash. (TechCrunch)

That story damaged more than licensing posture. It raised concerns about attribution, ownership, product credibility, and how confidently a company can claim it built something new.

Corgi and Papermark show the newer wrinkle. In June 2026, TechCrunch reported that Papermark accused YC-backed Corgi of stealing its open-source data room software and passing it off as its own. Corgi denied using Papermark’s code, while also acknowledging that vibe-coded design led to replica features that were later changed. (TechCrunch)

That is where AI changes the risk profile. A team may avoid copying the source code verbatim and still use AI to rebuild the shape, language, workflow, and product behavior of something already on the market.

The source files may differ. The product may still look too familiar.

Refactoring may be the quieter risk

AI-generated features get the attention. AI-assisted refactoring may become the larger enterprise issue.

Refactoring feels safer because the company starts with code it already owns. A modernization effort may use AI to update frameworks, split services, write tests, clean dependencies, translate languages, or break apart legacy modules.

That work can create real value, but also blur the code origin.

A model may introduce helper functions, replace implementation patterns, add dependencies, create tests, or restructure logic in ways that move beyond cleanup. After enough AI-assisted refactoring, the company may struggle to explain which parts came from the original human-authored code, which were generated, which were reviewed, and which may resemble third-party material.

That becomes important during customer audits, security reviews, M&A diligence, financing, litigation, and enterprise sales cycles. A company claiming proprietary technology should be able to explain the ownership trail behind the code it sells.

A commit history may show when code changed. It may not show whether the company has the rights to use, sell, enforce, and defend the result.

Human accountability has to stay in the loop

The Linux kernel’s AI coding assistant policy offers a useful model because it accepts AI as an engineering reality while maintaining human accountability.

The policy says AI agents cannot add Signed-off-by tags because only humans can legally certify the Developer Certificate of Origin. The human submitter remains responsible for reviewing AI-generated code, ensuring licensing compliance, adding their own sign-off, and taking full responsibility for the contribution. The policy also supports an Assisted-by tag to identify the AI tool and its model version. (Linux Kernel Docs)

That is the right instinct for enterprise software organizations.

AI can assist. A human still needs to stand behind the contribution.

Executives do not need to slow AI adoption to a crawl. They need to govern AI-generated code as part of the software supply chain.

That means approved tools. Enterprise contracts. Clear rules on what source code and data can be shared with AI systems. Public-code matching where available. Software composition analysis. Open-source license review. Human code review. Clear records for higher-risk AI-generated or AI-refactored changes.

I would add an AI code-origin record to the process.

We already talk about SBOMs for dependencies. AI-generated and AI-refactored code needs a similar mindset. Which tools contributed to the code? Which model was used? Who accepted the output? What review took place? Did the change introduce new dependencies, licensing concerns, or customer-facing claims?

This may feel heavy during a sprint. It will feel very different when an enterprise customer, investor, acquirer, or opposing counsel asks where a critical part of the product came from.

The executive message

AI coding tools can create real leverage. They can also create ownership gaps that remain invisible until the company is under pressure.

The risky path is treating AI-generated code as if it enters the company the same way employee-created code does.

Employees sign IP agreements. Contractors can assign rights. Open-source contributors can certify contributions. AI models generate output without legal accountability and without the ability to explain the origin of every pattern they produce.

Before leaders celebrate how much code AI is generating, they should make sure the company can support a more durable claim:

Can we prove we have the rights to use, sell, enforce, and defend the software we are shipping?

That proof will become part of modern software governance.

The companies that handle this well will move fast with evidence. Human accountability will stay in the loop. Code origin will be tracked where risk is higher. Open-source obligations will be respected. Vendor contracts, employee agreements, customer warranties, and engineering policies will be updated for the reality of AI-assisted development.

Because the AI did not sign the IP agreement.

And if the product depends on code the AI helped create, the company still needs someone who can stand behind the rights.

How is your organization tracking ownership and human accountability for AI-generated or AI-refactored code?

References