Introduction
Under current US law, copyright requires human authorship, so code produced entirely by an AI agent with no human creative input is unprotectable. Ownership flows to the person or company that directs, selects, and meaningfully modifies the output. Under work-for-hire doctrine, that typically means the employer. Without a documented record of human involvement, your IP claim is fragile, and the gap between how much AI code enterprises are shipping and how carefully they are documenting it is widening fast.
Why AI Code Ownership Is Now a Board-Level Risk
AI-assisted development has moved from experiment to default. Google CEO Sundar Pichai stated in April 2026 that 75% of the company's new code is generated by AI and subsequently approved by engineers. That figure is not an outlier. Approximately 42% of all code produced across the software industry is now written by AI. At that scale, the IP question stops being a legal department footnote and becomes a core governance issue.
The business risk is straightforward. If a significant share of your codebase lacks clear human-authorship documentation, you face three concrete exposures. First, your IP portfolio may be unenforceable: code with no protectable copyright cannot be defended against a competitor who copies it. Second, acquirers and investors conducting due diligence will flag undocumented AI contributions as a liability, potentially reducing valuation or blocking a deal. Third, regulated industries, financial services, aviation, insurance, face additional scrutiny from regulators who want to know exactly what produced the software running critical systems.
The legal distinction that creates this risk is simple but easy to overlook. When an engineer writes code, authorship is clear. When an AI model generates code and a human accepts it verbatim, the authorship picture blurs. The law does not automatically assign ownership to the person who clicked "accept." It asks whether a human exercised genuine creative judgment over the final output.
Most enterprises have not built the documentation habits to answer that question. They are shipping AI-assisted code at volume while their IP records still reflect a world where every line had a named human author. That gap is where the risk lives. Boards and general counsel are starting to ask about it, and engineering teams need a concrete answer before an acquisition, audit, or dispute forces one.
For a deeper look at why AI-generated code often stalls before production in enterprise settings, see Why AI-Generated Code Rarely Reaches Production in the Enterprise.
What Does US Copyright Law Actually Say About AI-Generated Code?
US copyright law protects original works of authorship fixed in a tangible medium. The critical word is authorship. The Copyright Act does not define the term, but decades of case law and Copyright Office guidance have made one thing clear: the author must be human.
The Copyright Office has refused to register works created autonomously by AI systems, citing the human-authorship requirement directly. The Thaler v. Perlmutter case brought this principle into sharp focus. The court upheld the Copyright Office's refusal to register an image generated entirely by an AI system with no human creative input, affirming that human authorship is not a technicality but a foundational requirement. The ruling did not address AI-assisted work, only autonomous AI output, but it drew a line that every enterprise IP strategy now has to work around.
The practical implication is a spectrum, not a binary. At one end, a developer uses an AI tool to autocomplete a single function, reviews it, modifies it, and integrates it into a larger architecture they designed. That developer almost certainly retains copyright over the work as a whole. At the other end, an agent generates an entire module from a single prompt and the developer accepts it without modification. That module may have no protectable copyright at all.
The distinction the law draws is between AI as a tool and AI as an autonomous author. A photographer owns the photograph even though the camera produced the image, because the photographer made the creative choices. The same logic applies to code: if a human made the meaningful creative decisions, the architecture, the logic, the selection and arrangement of components, the human (or their employer, under work-for-hire doctrine) holds the copyright.
The EU and UK take different approaches. The UK's Copyright, Designs and Patents Act explicitly grants copyright in computer-generated works to the person who made the necessary arrangements for the work to be created. The EU has no equivalent provision; its copyright framework also requires a human author. Neither jurisdiction has fully resolved how these rules apply to large-scale agentic development, but US enterprises operating globally need to track which jurisdiction's law governs each piece of IP.
The takeaway for engineering teams is this: human creative involvement must be real and documented, not assumed.
Who Owns the Code Generated by Claude or ChatGPT?
The answer depends on three things: the tool's terms of service, how much human direction shaped the output, and whether the resulting code clears the human-authorship threshold.
Start with the terms of service. Both Anthropic (Claude) and OpenAI (ChatGPT) assign output ownership to the user, not to themselves. That means the platform is not claiming your code. What the terms of service cannot do is manufacture a copyright where US law says none exists. If the output lacks sufficient human authorship, assigning it to the user just assigns an unprotectable work.
Claude Code is an agentic coding tool that can plan, execute, and commit code changes directly within a repository. By default, it adds a "Co-Authored-By: Claude" trailer to commits, which creates a visible attribution record. That record is useful for provenance tracking, but it does not resolve the authorship question. Per cc.bruniaux.com, code accepted verbatim from Claude Code without significant human modification may be uncopyrightable regardless of what the commit message says.
The degree of human direction matters more than the tool's name. A developer who writes a detailed prompt specifying architecture, constraints, edge cases, and integration requirements, then reviews, tests, and modifies the output, has a stronger authorship claim than one who types "write me a REST API" and ships whatever comes back. The prompt itself can be evidence of creative input, which is why prompt logging has become a serious IP practice.
ChatGPT operates under similar logic. OpenAI's terms assign output to the user, but the copyright question still turns on human creative contribution to the final work. If your team uses ChatGPT to generate utility functions that get accepted and deployed without review, those functions may sit in your codebase with no enforceable IP protection.
The practical risk is that you cannot stop a competitor from copying code you have no enforceable copyright over.
Can You Patent Code Written by AI?
Patents present a harder problem than copyright. The USPTO requires that every patent name a human inventor, defined as the person who conceived the claimed invention. Conception means forming a definite and permanent idea of the complete and operative invention. An AI system cannot conceive in that legal sense, so it cannot be listed as an inventor.
The USPTO issued formal guidance in 2024 confirming that AI-assisted inventions remain patentable, provided a human made a significant contribution to each claimed element. Listing an AI as a co-inventor is not permitted. Failing to disclose AI involvement when it was material to conception could constitute inequitable conduct, which can invalidate a patent entirely.
You need to show that a human engineer made the inventive contribution, not just the implementation decision. Choosing which algorithm to use, identifying the technical problem worth solving, and defining the constraints that make a solution novel, those are conception-level acts. Accepting an AI-generated solution to a problem the AI also framed is much harder to defend.
Before filing a patent on any AI-assisted invention, reconstruct who defined the problem and who made the judgment calls that distinguish it from prior art. If that reconstruction points primarily to an AI agent rather than a named human, the application carries real invalidation risk.
Software patents are already difficult to obtain and defend in the US. AI involvement in the inventive process adds another layer of vulnerability. Document human creative decisions at the time they happen, not after a filing deadline forces the question.
How to Build a Defensible AI Code Ownership Record: A Step-by-Step Checklist
Pull requests co-authored by AI contain 1.7× more issues than those written solely by humans, according to Exceeds AI's 2026 analysis. That quality gap matters for IP as well as reliability: code that ships with unresolved issues is also code that likely received less human review, which weakens the authorship record. The steps below build both a cleaner codebase and a defensible ownership trail.
1. Maintain a durable prompt log. Record every significant prompt used during development, including the context you provided, the constraints you specified, and the goal you were solving for. The prompt is evidence of human creative direction. Store it alongside the code it produced, not in a chat window that expires.
2. Label commits with attribution metadata. Use Git trailers or commit conventions to distinguish human contributions from AI-generated content. git-ai links lines of code to specific agents, models, and prompts using Git Notes without requiring workflow changes. It also lets you view aggregate stats on accepted versus generated AI code across the repository, which is useful both for internal governance and for due diligence responses. Per cc.bruniaux.com, git-ai uses local-first storage for prompts to prevent PII leakage.
3. Log architectural decisions and rejected alternatives. A decision log that records what you considered, what you rejected, and why demonstrates human judgment at the design level. This is the kind of documentation that survives a copyright challenge or a patent office inquiry, because it shows a human was steering, not just accepting output.
4. Substantially modify and refine AI-generated code. Verbatim acceptance is the weakest position. Review every AI-generated block, refactor where the logic can be improved, and make the code your own. Changes do not need to be wholesale rewrites, but they need to reflect genuine human judgment about quality, correctness, and fit.
5. Generate a Software Bill of Materials. An SBOM that tracks code provenance and AI tool involvement gives acquirers, auditors, and regulators a clear picture of what produced each component [S5]. Up to 30% of AI-generated code snippets include security vulnerabilities such as XSS or SQL injection, and an SBOM that maps AI contributions helps security teams prioritize review of the highest-risk segments.
6. Add a public disclosure file to the repository. A machine-readable file describing which AI tools were used and which codebase segments are heavily AI-assisted creates a transparent record. It also signals to future maintainers and acquirers that the team managed AI contributions deliberately rather than ignoring the question.
For guidance on building the audit trail that boards and regulators expect from AI-assisted development, see AI Delivery Audit Trails for Boards and Regulators.
Handling AI Code IP in Third-Party Agency and Vendor Contracts
When an outside agency or vendor uses AI agents to build your software, the IP risk does not stay with them. It transfers to you at delivery, along with any gaps in the ownership record.
The median AI Code Halflife, the time it takes for half of AI-generated code to be replaced, is approximately 3.33 years, based on repository data tracked by git-ai. That turnover rate matters for contracts because it means AI-heavy codebases change faster than traditional ones. An IP gap in the initial delivery compounds quickly as the codebase evolves and the original provenance records become harder to reconstruct.
Three contract clauses address the core risk. First, an IP assignment clause should confirm that all code delivered under the engagement is assigned to you on creation, not on final payment. "Work made for hire" language covers employees; explicit assignment language covers vendors. Second, an AI disclosure requirement should obligate the vendor to identify which tools they used, which codebase segments are AI-generated, and whether they maintained prompt logs and attribution metadata during development. Third, an indemnification clause should require the vendor to defend you against any third-party IP claim arising from their use of AI tooling, including claims that AI-generated code infringes a training data copyright or violates an open-source license.
Add an SBOM delivery requirement to the statement of work. Require the vendor to deliver a complete SBOM at each release milestone, not just at project close. That gives your legal and security teams a current picture of code provenance throughout the engagement, not just a snapshot at handoff.
Regulated industries should also require the vendor to confirm that their AI tooling agreements do not grant the tool provider any rights over your code or data. Some enterprise AI tool licenses include broad rights to use inputs for model training. If a vendor runs your proprietary requirements through such a tool, your confidential information may have left the building before a line of code was written.
When a Managed Delivery Model Shifts the Ownership Risk
Internal AI tooling puts the documentation burden on your engineering team. A managed delivery model shifts that burden contractually.
Tmob AI Studio is a done-for-you software delivery service where specialized AI agents handle design, product, and testing work around the clock, while senior human experts sign off at every release gate. The delivered code is deployed directly into the client's own cloud environment, fully owned by the client with no vendor lock-in. Ownership is not a negotiation point at the end of an engagement. It is the default position from day one.
That structure matters for IP governance because it separates two problems enterprises often conflate: building software with AI agents, and maintaining a defensible ownership record for what those agents produce. When
a named human expert signs off at every release gate, the human-authorship requirement has a clear answer. The sign-off is documented evidence of human involvement, which is the foundation of a defensible authorship record.
This model fits best when an enterprise needs production-grade output quickly and does not have spare engineering capacity to build and maintain the provenance infrastructure described in the checklist above. For teams that do have that capacity, Human Oversight in AI Software Development covers how to structure the internal governance layer.
Prices and plan limits verified as of October 2026.
FAQs
Is it true that Google says 75% of its new code is AI-generated? Yes. Google CEO Sundar Pichai stated in April 2026 that 75% of the company's new code is generated by AI and subsequently approved by engineers. The approval step is important: engineers review and accept the output, which is the human-authorship element that keeps the code protectable. The figure illustrates how quickly AI-assisted development has become the default at scale, not an edge case.
What is the AI Code Halflife and why does it matter for due diligence? The AI Code Halflife measures how quickly AI-generated code gets replaced. Repository data tracked by git-ai puts the median at approximately 3.33 years. During an acquisition, that turnover rate means a codebase with heavy AI contributions from two or three years ago may already look different from what was delivered. Buyers should request provenance records at each release milestone, not just a snapshot at the time of the deal.
Does the EU treat AI-generated code differently from the US? The EU's copyright framework requires a human author, similar to the US position. It has no provision equivalent to the UK's Copyright, Designs and Patents Act, which grants copyright in computer-generated works to the person who arranged for their creation. Neither the EU nor the US has fully resolved how these rules apply to large-scale agentic development, so enterprises operating across jurisdictions need legal counsel familiar with each regime.
What should an SBOM include to satisfy IP due diligence during an acquisition? An SBOM for IP purposes should identify each component's origin, the AI tools involved in generating it, the version of those tools, and whether prompt logs and attribution metadata exist for AI-assisted segments. It should also flag any open-source licenses that carry copyleft obligations. Delivering an updated SBOM at each release milestone, rather than only at project close, gives acquirers a current provenance picture rather than a point-in-time snapshot.
Does using GitHub Copilot mean Microsoft owns my code? No. GitHub Copilot's terms of service assign output ownership to the user, not to Microsoft. The ownership question that does remain open is whether AI-generated code accepted verbatim without significant human modification is protectable by anyone. Microsoft does not claim it, but US copyright law may not protect it either. The safeguard is the same as with any AI tool: review, modify, and document your human creative contribution to the final output.
Conclusion
Under current US law, AI-generated code has no automatic copyright protection. Ownership flows to the humans who directed, shaped, and meaningfully modified the output, and only if they can prove it. The legal framework is not going to resolve this ambiguity quickly, so the documentation practice has to come first.
The concrete next step is to audit your current development workflow against the six-step checklist in this article. Check whether your team logs prompts, labels commits with attribution metadata, and generates SBOMs at release. If any of those practices are missing, that is where the IP gap lives. Fix the record-keeping before an acquisition, audit, or dispute forces you to reconstruct it from memory.