Who owns AI-generated code depends on three things: the human design work in it, your AI tool’s terms and the contracts with everyone who wrote code for you. The answer matters most when an investor, an acquirer, an enterprise customer or a court has to rely on it.
This guide is for founders and COOs of products built largely with AI coding tools, from an EU and Dutch perspective. It compares the copyright rules in the United States, the EU and the Netherlands, and sets out five IP and licensing questions to answer before you raise or sell. It also shows three records that turn an ownership claim into evidence, and when you need a lawyer rather than a technical review. It belongs to our guide to shipping AI-built products safely. The guide explains the legal position in general terms; confirm contracts and warranties with a lawyer.
TL;DR
Treat ownership of an AI-built product as something you prove, not something you assume. Copyright covers only the parts a person authored. Your AI tool’s terms set the rights you hold in the output, and contracts decide whether the rights of employees, freelancers and agencies reached your company. Check all three before a funding round, sale or enterprise contract.
- Copyright rules: US law requires a human author (Thaler v. Perlmutter, 2025), and the EU Software Directive 2009/24/EC protects a program only if it is the author’s own intellectual creation. Human design and edits can be protected; code produced without them is unlikely to be.
- Five IP and licensing questions: AI tool terms, proof of human contribution, open-source licences, written transfers from freelancers and agencies, and confidential inputs in prompts.
- Three ownership records: an IP register, a licence scan exported as a software bill of materials (SBOM) in SPDX or CycloneDX, and the history of human design and review decisions.
- Lawyer or technical review: a lawyer drafts IP transfers and warranties; a technical review establishes what the codebase contains and which licences apply.
Who owns AI-generated code?
AI-generated code is owned through three layers. Copyright covers only the parts a person authored. The AI tool’s terms set the rights the vendor grants you in the output. Contributor contracts decide whether rights held by employees, freelancers and agencies passed to your company, and a gap in any layer weakens the ownership claim.
Copyright is the legal right to copy, change and license a work, and software counts as a work. It arises automatically, but only for material a person created. The AI tool’s terms are a contract between your company and the vendor. The EU IP Helpdesk notes that standard AI tool terms consider the user the right holder of the output, and advises checking each tool’s terms. A contract can pass on whatever rights the vendor has, but it cannot create copyright where the law grants none.
The third layer covers people. Code written by employees, freelancers, agencies and the founders themselves belongs to the company only if an employment relationship or a signed contract puts it there. “We built it with AI, so it is ours” is therefore an incomplete answer. The answer an investor can rely on names which parts people designed, which tool terms applied and who signed the IP transfers.
Can AI-generated code be copyrighted? US, EU and Dutch rules compared
AI-generated code can be protected by copyright only where a person made the creative choices. Code a machine produced without that input is unlikely to be protected in the United States, the EU or the Netherlands, and Table 1 shows the legal test behind each answer.
| Jurisdiction | Legal test | Key source | What it means for your codebase |
|---|---|---|---|
| United States | A human author is required. Prompts alone are not enough; human selection, arrangement or changes can be protected. | US Copyright Office report Part 2 (29 January 2025); Thaler v. Perlmutter, D.C. Circuit (18 March 2025) | Only the human-authored parts can be registered, and AI-generated material must be disclosed. |
| European Union | A program is protected “if it is original in the sense that it is the author’s own intellectual creation”. | Software Directive 2009/24/EC, Article 1(3); CJEU Infopaq (C-5/08) | Protection depends on human creative choices you can document. |
| Netherlands | Computer programs are protected works under the Auteurswet, which applies the EU originality test. | Auteurswet, Article 10(1) item 12; Directive 2009/24/EC | Same test as the EU; Dutch contract rules decide who holds the rights in protected code. |
The US position is the most developed. In Thaler v. Perlmutter, the D.C. Circuit held on 18 March 2025 that the Copyright Act requires a human author; the Supreme Court declined review on 2 March 2026. The court added that works made with AI assistance are not excluded. The Copyright Office’s January 2025 report draws the line: output is protected where a human determined enough of its expressive elements, through selection, arrangement or modification, but not through prompts alone.
In the EU, the Software Directive protects a program that is the author’s own intellectual creation and applies no other criteria. No court has yet drawn the line between AI-assisted and AI-generated software; a June 2026 analysis by the law firm Dreyfus found no case law on software coded entirely by AI. Until a court rules, the practical answer matches the US one: protection follows the human creative choices you can show.
Code that copyright does not protect can still be valuable. Kept private, it can qualify as a trade secret under Directive (EU) 2016/943 if it has commercial value because it is secret and the company took reasonable steps to keep it secret.
Five IP and licensing questions to answer before you sell or raise
Five questions cover the IP and licensing issues of an AI-built product, each tied to one thing that can go wrong: rights in the output, proof of authorship, third-party licences, transfers from contributors and inputs to AI tools. The grouping is this guide’s own, not a legal category, and each question ends with what to ask your developer or lawyer.
AI tool terms: who holds the rights to the output
Your AI tool’s terms decide which rights you receive in the code it generates. For every tool used on the product, check who holds the rights in the output and whether your prompts and code may train the vendor’s models. Also check whether your plan includes any IP indemnity, and on what conditions.
Someone accepted these terms, sometimes on a personal or free account instead of a company account. Terms differ between plans and change over time, so keep the version that applied when the code was written. Ask: “Which AI tools and plans were used to write our code, and under whose account?”
Human contribution: proof of who designed what
Copyright protects the parts of AI-assisted code that a person authored: the architecture, the choice and arrangement of components, and meaningful changes to generated code. Without records of that work, a company may be unable to show that any part of its code is protected.
Prompts alone do not count under the US Copyright Office’s approach, so the record has to show design and editing. Commit history, pull-request reviews and design notes can provide it when they name who made each change. Ask: “Can we show where a person designed, chose or changed the code?”
Open-source licences: obligations that travel with generated code
AI coding models are trained on large amounts of public code, and generated code can match code published under an open-source licence. When it does, that licence’s conditions can apply to your product, from keeping a copyright notice to making your own source code available.
Permissive licences such as the MIT licence require the copyright and permission notice to stay in copies of the software. Copyleft licences such as the GNU GPL require you to provide source code when you distribute software based on GPL code. The GNU AGPL extends this duty to users who reach the software over a network.
US courts are still testing these questions. In Doe v. GitHub, the Ninth Circuit on 16 September 2026 upheld the dismissal of a DMCA claim, while the open-source licence contract claims remain pending. Ask: “Has anyone scanned our code for open-source licence matches?”
Freelancers and agencies: rights transferred in writing
Under the Dutch Auteurswet, the employer is treated as the maker of works an employee creates where making such works is part of the job, unless agreed otherwise (Article 7). A freelancer or agency keeps the copyright unless it is transferred in writing, by deed (Article 2). Using AI tools does not change who has to sign.
The same applies to code a founder wrote before the company existed or without an employment contract with it. An invoice or a chat agreement does not transfer copyright; a signed assignment or IP clause does. That contract can also state whether the contributor may use AI tools, on which accounts, and who carries the risk of a licence match. Ask: “Do we have signed IP transfers from every freelancer and agency that wrote code?”
Confidential inputs: code and data you put into prompts
Unless an AI tool runs on your own infrastructure, what you paste into it is sent to the vendor’s systems. Client code, credentials and personal data in prompts can breach confidentiality agreements and the GDPR, and can weaken trade-secret protection.
A written rule on what may go into prompts, and which tools and accounts are approved, is one of the reasonable steps that trade-secret protection under Directive (EU) 2016/943 depends on. Where the vendor processes personal data on your behalf, GDPR Article 28 requires a processing contract with it; GDPR for startups covers those duties. Ask: “What are we allowed to paste into AI tools, and is that written down?”
If you cannot yet answer these five questions from records, a technical review can establish the facts. An AI-built product review covers maintainability and code ownership alongside security and data, and gives you findings with the evidence behind them and a prioritised action plan to take to your lawyer.
What investors and acquirers ask about AI-written code
Investors and acquirers want evidence that the company owns or may use its code, and that no licence or third-party claim will surface after the deal. In an investment or share purchase agreement, that evidence can be required through IP warranties the founders sign, with known exceptions listed in a disclosure.
Due diligence tests those warranties: who wrote the code, under which contracts, which open-source components it contains and how AI tools were used. An unanswered question can become a disclosure, a condition before closing or a point in the price negotiation. Our guide to technical due diligence explains how investors review an AI-built product as a whole.
How to document ownership of an AI-built product
Three records turn an ownership claim into evidence: an IP register, a licence scan exported as a software bill of materials, and a history of human design and review decisions. Together they show who wrote the code, under which terms and with which third-party components.
Keep an IP register for the codebase
An IP register is one document that lists every repository, every contributor with their contract and IP clause, the AI tools and plans used, and the third-party services the product depends on. It answers the chain-of-title question, meaning how the rights in each part of the code reached your company.
Update the register when a contributor, repository or AI tool is added, and link each entry to the signed contract. A register kept from the start can be handed over as it is; one built during a funding round has to be pieced together from email.
Run a licence scan and keep the report
A licence scan uses a software composition analysis (SCA) tool to list the open-source components in your code and the licence of each one. Export the result as a software bill of materials (SBOM) in a standard format such as SPDX or CycloneDX, and keep one report per release.
A dependency scan lists only the packages your project declares. Code fragments copied into your own files need a snippet-matching scan, so ask your developer which type was run. A code audit report shows how findings like these are recorded with evidence and priority.
Record human design and review decisions
Architecture decision records, pull-request reviews and commit history show where people designed, chose and changed the code. These records are the evidence for the human contribution that copyright protects.
An architecture decision record is a short note of one design decision, the options considered and the reason for the choice. Requiring a named reviewer before generated code is merged into the main branch adds a dated record of human review to every change.
When you need a lawyer and when a code review is enough
A lawyer drafts and checks IP transfers, AI-use clauses and investor warranties, and advises on disputes. A technical review establishes the facts those documents rely on: what the codebase contains, which licences apply and where records of human contribution are missing.
| Task | Lawyer | Technical review |
|---|---|---|
| Draft or check IP transfers and AI-use clauses | Yes | No |
| Write IP warranties and disclosures for a deal | Yes | Supplies the facts |
| List open-source components and their licences | Interprets licence duties | Yes |
| Find gaps in commit and review history | No | Yes |
| Advise on a dispute with a contributor or vendor | Yes | Supplies evidence |
The two work in sequence: the review produces findings, and the lawyer turns them into contract changes, disclosures or a negotiation position. An AI code audit covers the technical side; it does not replace legal advice on your contracts.
How Sunbytes helps you establish what your codebase contains
IP warranties are only as reliable as the facts behind them, and a lawyer cannot read those facts from a contract. Sunbytes reviews AI-built products to establish what the code contains and where its records are incomplete, so your lawyer and your investors work from findings instead of assumptions.
The AI-built product review covers five areas: security and data, code and architecture, reliability and critical flows, deployment and operations, and maintainability and code ownership. You receive clear findings with the evidence behind them, a prioritised action plan and a technical handoff your developers can act on. Access to your code is handled under Sunbytes’ ISO 27001-certified information security management system, with Netherlands-led client governance, 15+ years in software delivery and 300+ projects delivered. Sunbytes does not give legal advice.
If a funding round, sale or enterprise contract is coming up, talk to us about scoping a review of your codebase. We agree the scope case by case.
