Who Owns AI-Generated Code?

Why is code ownership critically important in the AI era?

In the last months of 2025 and at the beginning of 2026, we have seen a number of court cases in the USA (for example, Doe v. GitHub) and in Europe dealing with authorship of AI-generated works. In the Czech Republic, for example, the Municipal Court in Prague has already ruled that an AI-generated image is not protected by copyright without demonstrable human creative activity. This is not just a legal abstraction. If you do not know who owns your code, you can expect problems that will reduce your company’s value, block an investment, or put you on the defensive in litigation.

Code ownership is essential for several key areas. When selling or merging companies, the buyer will ask you for warranties that you truly own the code. If you cannot provide clean title, the transaction will be blocked.

In contractual commitments to clients, you promise code exclusivity; if you do not own it, you are in breach of contract and risk being sued. When licensing, without clear ownership you cannot provide the code to third parties and you are unable to enforce your rights. Finally, without ownership you cannot effectively protect your competitive advantage as a trade secret, and your investment in development may be difficult to monetise.

This is why the attorneys at ARROWS advokátní kancelář see ownership of AI-generated code as one of the most common legal gaps that then surfaces at the worst possible times – in a buyer’s reluctance to acquire your company, in a regulator’s request, or in a court dispute.

How is ownership of AI-generated code determined in legal reality?

In the USA, as well as in the Czech Republic and other European Union countries, a basic principle has applied since the foundational legislation (the 1976 Copyright Act in the USA, and the Czech Copyright Act No. 121/2000 Coll.): only works created by a human are subject to copyright.

In March 2025, the DC Circuit Court of Appeals (USA) again confirmed that artificial intelligence cannot be an author. Even if someone gives an AI a command – prompting alone, without further creative work, is not enough for a person to be considered the author.

This means very concretely: code that AI generates without meaningful human creative interaction is not protected by copyright. Without copyright protection, practically anyone can use it. It does not protect your competitive advantage, it cannot be effectively enforced, and in a company acquisition you will simply say, “that’s not ours.”

Czech legal practice follows the same principles as the USA and the European Union on this point. In the Czech Republic, this issue has not yet been extensively litigated in the courts (unlike in the USA), but case law from other EU countries and interpretations by Czech lawyers indicate that Czech courts will behave the same way: without human creative work, there is no copyright protection.

What counts as sufficient human creative work?

The attorneys at ARROWS advokátní kancelář handle specific cases in practice and know that the line between a “simple prompt” and “creative input” is often blurred in court. In general, the following is recognised as creative work:

• Repeated, targeted prompting – not just one simple command like “create a login,” but a series of sophisticated instructions with specific requirements.
• Editing, modifying, and improving the AI output – the developer intentionally changes parts of the code, reworks the logic, fixes errors.
• Substantive decision-making about the architecture and structure of the code – the person independently chooses how the whole will be structured, which patterns to use, and how to integrate AI-generated pieces.
• Integrating an AI-generated part into the overall system with one’s own intellectual contribution – not merely “gluing together” AI outputs, but a systemic approach where AI-generated code is part of a broader creative vision.

Practical example: if a developer enters the AI prompt “create a login form” and takes the code exactly as returned by the AI, without further modifications, simply copying it into the project – that is not enough for copyright protection.

However, if they specify particular security requirements, iteratively fix errors, rewrite key parts for integration with the rest of the application, and create documentation explaining how it works, they have a better chance of having creative authorship recognised.

The problem is that the boundary is uncertain. Even experienced lawyers are not always sure in litigation where exactly “creative work” begins and where “mere application” ends. That is why the attorneys at ARROWS recommend that whenever the code is important for your business, you document everything that happened – prompt logs, file versions, edits made, everything. This documentation then becomes your best evidence in court.

Code ownership in an employment relationship

In an employment relationship, the rule is clear and is set directly in the Czech Copyright Act: the copyright to a work created by an employee in the performance of their work duties is exercised by the employer in its own name and on its own account (Copyright Act No. 121/2000 Coll., Section 58(1)), unless the contract provides otherwise.

This applies regardless of whether the code is generated by a human, partially by AI, or fully AI-generated. However, one condition is critical: although the employer exercises the rights by operation of law, it is highly recommended that this also follows from the employment contract or an internal company policy—clearly and specifically enough.

Companies that assumed “it’s obvious” without stating it explicitly later found that the employee has some room to argue—especially if they file a claim asserting that “AI generated the code, I just clicked.” If the contract says nothing, or is vague (“the employee participates in projects”), a dispute may arise.

Written documentation is key here. You should:

• Have a written employment contract (or at least an addendum) that expressly states that all intellectual property created within the scope of work duties belongs to the employer.
• Implement an internal AI policy or directive specifying how AI tools may and may not be used, and that all output belongs to the company.
• Document which AI tools employees used within the project and how they used them—especially what the human creative contribution was.

Attorneys at ARROWS advokátní kancelář regularly help companies with such policies and with reviewing employment contracts. This is not just an academic exercise—it is protection that will matter in the event of a dispute, a conflict with an employee, or a review by third parties (an investor, a buyer).

Code ownership for independent suppliers and contractors

Here, the situation becomes more complicated—and for many entrepreneurs, surprisingly so.

In the USA, the Czech Republic, and the EU, the following basic principle applies: if you hire an independent developer, an agency, or a contractor and they generate code for you, the code belongs to them by law unless a written contract expressly states otherwise. It is not like with an employee. An independent contractor “works for themselves”—even if you pay them, legally they are creating for themselves, not for you.

For ownership to be transferred to you, the written contract must include:

• An express assignment of rights—in English, this is called an “assignment of rights.” In Czech, it should read, for example: “Zhotovitel převádí na Objednatele veškerá autorská práva, včetně výlučných práv na užívání, reprodukci, distribuci a úpravu, na veškerý kód vytvořený v rozsahu této smlouvy o dílo, a to s okamžitou účinností a v plném rozsahu.”
• It must be signed by both parties. A verbal agreement, an email, or a spoken promise is not legally binding. It must be a written document with signatures.
• It must be an immediate transfer of rights—it must be “The Contractor assigns/transfers” or “The Contractor hereby assigns,” not “The Contractor will agree to transfer.”

What problem often occurs? A company hires an agency, the contract either says nothing about ownership at all or contains a vague sentence about a “licence,” and then the company finds out that:

• The agency reuses the code as a template for its other projects and sells it to competitors.
• The agency “lends” the code to competitors because it effectively owns it.
• When selling the company, a buyer appears who has conducted a review (due diligence), and the buyer’s lawyer concludes that your software is not actually your property—you only have a licence, i.e., limited rights.
• The transaction is blocked, the price is reduced by 20–50% (or more), or the deal is cancelled entirely. This is a common legal reason why a transaction may not be feasible at all.

This is serious, and attorneys at ARROWS advokátní kancelář see similar cases far too often. They are ready to address such situations—both through prevention (proper contract drafting at the outset) and through remediation if the problem has already occurred.

What risks arise from failing to clarify code ownership?

This is not merely theoretical. In practice, entrepreneurs avoid ownership questions—and then the problem arises at the worst possible moment.

Risk 1: Blocking the sale of the company or financing

When you are preparing for a sale of the company, an investor’s entry, or a merger with another company, the first thing a buyer or investor will verify is: “Do you really own all the code that forms the core of your business?”

If the answer is “We’re not sure, we use AI-generated code, it’s unclear what part belongs to us and what part belongs to the supplier,” or “We have a licence from an agency, but we never addressed ownership,” the due diligence (legal review) will stop.

The buyer will fear that one day a competitor will prohibit it or that the agency will take the code back. The transaction will be delayed, the price will be reduced by 20–50% (or more), or the deal will be cancelled entirely. This is a common legal reason why a transaction may not be feasible at all.

Risk 2: Copyright disputes and unexpected lawsuits

If your code is similar to another entrepreneur’s code and you cannot prove that you created it through your own creative work (especially with AI), you may be sued for copyright infringement.

A person who claims to own the code and is unhappy with you may sue you for “unauthorized use”. At the same time, if the AI you use trained its model on third-party data without their consent, you may find yourself having to defend a third-party copyright infringement claim.

This was the case with Getty Images and The New York Times against OpenAI and other AI companies. If your software contains snippets that the AI copied from their material, they may send the claim to you as well.

Risks specific to AI-generated code:

• Security vulnerabilities: AI is trained on public data; this may include old, vulnerable code and outdated security practices. AI has learned these patterns and will occasionally reproduce them. If you integrate AI-generated code without a thorough security review, you may introduce SQL injection, XSS, or other vulnerabilities into your application.
• Licence violations: AI may generate a piece of code under the GPL or AGPL licence (copyleft licences), and you integrate it into your proprietary software without realizing it is there. Later it is discovered and you are obliged to disclose the entire codebase – a disaster for competitive advantage.
• Unknown origin: If AI generates code that resembles someone else’s, and this is later discovered and that person claims it as their own, you may end up buying yourself a patent or copyright dispute. It is known that AI tools sometimes “hallucinate” – generating snippets that look like code they saw during training.

Risks arising from insufficient documentation:

• You cannot prove that you made a creative contribution to the code – so copyright does not apply to it.
• You cannot prove that an employee created it within the scope of their duties – the employee may then believe it is theirs.
• You cannot rule out that you breached an open-source licence – during a regulator’s audit or in court, it will not look good.

Most common risks and how ARROWS helps

Legal framework in the EU, in the Czech Republic, and new regulation

The Czech Republic is governed primarily by the Copyright Act (No. 121/2000 Coll.), which protects works created by humans. Legal interpretation is based on EU Directive 2019/790 (the Copyright Directive in the Digital Single Market), which harmonises copyright across the EU.

In addition, the EU AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024 and will be phased in gradually through the end of 2026.

What does the EU AI Act mean for you?

The EU AI Act classifies AI systems into categories based on risk. If you develop software using AI that falls into the “high-risk” category (for example, decision-making in employment, access to services, or systems used in critical infrastructure), you must meet strict obligations:

• Documentation – you must keep a detailed record of how the AI works, what its limitations are, and how it was developed.
• Testing and validation – you must test the AI and verify that it does what it is supposed to do and that it is reliable and accurate.
• Event logging (audit trail) – you must keep records of how the AI operates and what decisions it makes so that its functioning can be reviewed retrospectively.
• Human oversight – you must ensure meaningful human oversight of AI decisions so that a person can intervene and correct the decision.
• Cybersecurity – you must ensure that the AI is secure and resilient against attacks, manipulation, and unauthorised access.

The obligations will be introduced gradually and will be fully effective for high-risk AI systems from August 2026. If the software you develop is not classified as “high-risk AI”, you have lighter obligations (e.g., transparency), but you should verify which category your system falls into.

A revision of the existing Product Liability Directive is also expected, which will have a significant impact on liability for damage caused by AI systems. This newly proposed framework envisages stricter liability for AI.

If AI generates a security vulnerability in code and it causes damage (e.g., a hacker accesses data through your application), you may be liable even if you “thought things through” and did what was reasonable. The introduction of “strict liability” is anticipated – you are liable regardless of fault. This is why auditing and documenting AI-generated code is more necessary than ever.

In the Czech Republic, there is not yet specific legislation for AI-generated software (as there is in some other countries), but case law is developing. Attorneys at ARROWS, a Prague-based law firm, monitor developments in the courts’ decisions and are ready to advise you based on the latest legal interpretation.

Practical steps you need to take now

If you use AI for software development, you should ask without delay:

Step 1: Do you have existing documentation proving your creative contribution to AI-generated code?

If not, start immediately. Without documentation, you will not be able to prove creative authorship later.

You should keep prompt logs with timestamps, code versions showing iterations and changes, design documents, and schematics you created. Start doing this today. It will cost you a few hours a week, but in a year it will save you a lot of trouble.

Step 2: Do you have a contract with all employees and contractors that clearly states that all code belongs to you?

If not, this is a critical deficiency. Contact the attorneys at ARROWS, a Prague-based law firm, to review and amend your contracts.

This is not just about having a sentence on copyright. You should ensure it is drafted clearly and specifically for your situation. For employees: the clause in the employment contract must be specific and refer to Section 58 of the Czech Copyright Act. For contractors: an addendum or a new contract with an explicit assignment of rights.

Step 3: Do you use open-source components (libraries, frameworks)?

Do you know what licenses they have? If not, the risk is significant. A license audit should be carried out as soon as possible. If your software contains code licensed under the GPL and you believe everything is proprietary, you have a problem. The attorneys at ARROWS can help with this.

Step 4: Do you have an internal AI policy?

Do you know who can use which AI tools? What is allowed and what is not? If not, you should implement one.

Mishandling AI (e.g., an employee sending proprietary data to ChatGPT) can create a security or legal issue that will be difficult to explain during an inspection or in court. The attorneys at ARROWS can help you with such internal guidelines.

Step 5: Contracts with new suppliers

If you hire an agency or a developer, make sure the contract includes an explicit transfer of all rights to all code, including AI-generated code. Have it drafted by the attorneys at ARROWS so it is legally watertight and clearly states who is the author, who is the owner, and that the rights are unconditionally assigned to you.

The attorneys at ARROWS can help you with all five steps. This is not just a “check-box” list—it is a strategic approach that protects you in the long term.

Final summary

Code ownership in the AI era is not just a legal issue—it is the issue that determines whether you will have exclusivity over your software, whether you will be able to sell it, whether a competitor can take it, and whether, when selling your company, a buyer will tell you, “no thanks, that’s not your code.”

The key takeaway is this: entering an AI prompt alone is not enough for copyright protection. There must be documented human creative work. This means that companies that use AI without clear documentation and without clear contracts expose themselves to enormous risk. When an investor or buyer looks at it, or when a court examines it, they will find that “things are not clear,” and the transaction will either stall or the price will be reduced.

The second takeaway is that the EU AI Act and the newly proposed Product Liability Directive bring stricter liability. If AI-generated code causes a security incident or an infringement of rights, you will not be able to excuse yourself by saying “AI did it.” You are responsible. You are responsible for quality, security, and licensing compliance.

The third takeaway is that ownership is handled on paper. Without a written contract with a clear assignment of rights, it is not clear who owns the code. Discussing it by email, or “relying on it being clear,” is not sufficient.

If you do not want to risk serious legal, financial, and business problems—and believe us, it happens—you should act now. The attorneys at ARROWS, a Prague-based law firm, can provide a comprehensive solution:

• Review of your existing contracts and identification of gaps.
• Updating employee and supplier contracts.
• Preparation of an AI policy and a compliance audit.
• Legal opinions on specific issues.
• Representation if a dispute arises.

Do not hesitate to contact ARROWS advokátní kancelář at consultation@arws.cz. They will be happy to help you with ownership of your code and with avoiding similar problems in the future. Thanks to the ARROWS International network, ARROWS advokátní kancelář also handles matters with an international element, if relevant to your situation.

Read also:

• How to protect your brand and online store from Czech copycats:
• Termination clauses that work – and those that don't in the Czech Republic:
• How to Structure Intercompany Agreements in a Holding to Avoid Disputes and Tax Risk:
• Supply chain disputes in Czech law: How to win or settle smart:
• How to outsource legal tasks in the Czech Republic without losing control over strategy: