In short
- Code produced by AI alone is probably not protected by European copyright. What counts are human choices, and you must be able to prove them.
- Do not rely on payment alone to become the owner of a development. Have the rights assigned to you in writing, each right named, with its extent, its purpose, its place and its duration.
- Require delivery of the source code, the documentation and the access. Also check whether your software falls under the European regulation on the cybersecurity of products.
You are having software developed for your business. Your supplier writes part of the code with artificial intelligence. Three questions arise: is this code protected? Who owns it? What should you look for in the contract before signing?
This article is based on European law. It informs, it does not replace the advice of a lawyer. Have the clauses reviewed by counsel from the country whose law governs your contract.
Copyright and AI: the originality test
A 2009 European directive requires every EU country to protect software by copyright, as literary works. It includes preparatory design material (Directive 2009/24/EC, Article 1). But software is protected only if it is original, that is, if it is the author's own intellectual creation. No other criterion applies.
The author, under the same directive, is in principle the natural person, or the group of persons, who created the program (Article 2). Code produced by AI alone is therefore probably not protected.
What this means for you: the legal value of your software rests on the human contribution. The specification, the architecture (the way the software is organised), the choices made along the way, and the review and rewriting of the code must leave a written trace. The version history is part of it: it is the register that keeps each change to the code, with its date and its author.
AI providers' terms: who gets the outputs
Your supplier uses an AI tool under its provider's terms. These terms bind the provider and your supplier: you are not a party to them.
Take Anthropic, the publisher of Claude. Its commercial terms (version of 17 June 2025) provide that its customer, here your supplier, owns the outputs produced, “to the extent permitted by applicable law”. Anthropic also assigns to it its rights in those outputs, “(if any)”. A provider cannot assign a copyright that does not exist. It is then up to your supplier to assign to you what it holds.
These terms also provide that Anthropic defends its customer, for paid use, if a third party claims that the outputs infringe its intellectual property. This protection does not apply, among other cases, where the customer has modified the outputs or combined them with elements that Anthropic did not provide. Yet custom software almost always mixes code that has been reviewed, modified and assembled with other building blocks.
The Claude Code development tool falls under the commercial terms for the Team and Enterprise plans and the API, but under consumer terms for the Free, Pro and Max plans (Claude Code legal page). The consumer terms (version of 8 October 2025, published on Anthropic's website and accessed on 13 October 2026) also assign Anthropic's possible rights in the outputs, but do not provide this defence against third-party claims. So ask your supplier which tool it uses, on which plan, and what those terms say about the outputs.
The assignment contract: name each right, its territory and its duration
Do not rely on payment alone. For software, the same directive provides that the rights in a program created by an employee in the course of their duties go to their employer, unless the contract says otherwise (Article 2). The rights in the code written by your supplier's employees therefore go, in principle, to your supplier. To receive them, you need an assignment.
Do it in writing, and name each right assigned, with its extent, its purpose, its place and its duration. The exact formal requirements, especially when your supplier is a company and not the author itself, are to be checked with your counsel. This precision remains the surest way to know exactly what you are receiving.
For software, the rights to name are those the directive reserves to the author (Article 4):
- reproduction of the software, in whole or in part;
- translation, adaptation, arrangement or any other alteration;
- any form of distribution to the public, including rental.
A sentence such as “the client becomes the owner of the software” remains too vague: it does not say which rights you receive, or for which uses. A good clause names each right, its uses, its territory (the whole world, for example) and its duration (the whole period of protection provided by law, for example). It covers the source code, the ready-to-run software, the documentation and the design documents.
Add two warranties. First, the supplier does hold the rights of everyone who wrote the code: its employees, but also its subcontractors and freelancers. It cannot assign you more than it has. Second, it declares all third-party elements built into the software, in particular open-source components, each with its licence.
Reversibility: source code, documentation and hosting access handed over to the client
Reversibility is your ability to change supplier or take back control without starting from zero. Owning the rights is useless if you do not have the code.
The contract must provide for the handover of:
- the complete source code, with its version history;
- the documentation: installation, how the software is organised, the choices that guided the development;
- the access: hosting, domain name, accounts of the services used, backups.
Set the timing (at each delivery and at the end of the contract), the format and the deadline. For example, an SME of 40 employees that has a site-scheduling tool developed must be able to hand its maintenance to another supplier the day it decides to.
At Kendu Intelligence, what you receive on delivery of custom software (source code, documentation, hosting access) is specified in your quote.
Cyber Resilience Act: according to the Commission, a web application used in the browser is not covered, an installed application may be
The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) imposes cybersecurity rules on “products with digital elements”. Its main obligations apply from 11 December 2027 (European Commission). Since 11 September 2026, the manufacturer of a product concerned must already report actively exploited vulnerabilities and serious incidents affecting the security of the product. It sends them to the national computer security incident response team (CSIRT) of the country of its main establishment; ENISA, the EU cybersecurity agency, receives them at the same time (European Commission).
Custom work is not excluded in principle. The guidelines published by the Commission on 27 July 2026 recall, following the Blue Guide, that placing on the market is assessed product by product, whether made as a single unit or in series (point 11).
These guidelines give useful examples (examples 3 to 5):
- a web application used only in a browser is not a product within the meaning of the CRA; it falls within its scope only if it serves the operation of a product that is one;
- a mobile application downloaded and installed on the phone, or a desktop application installed on the computer, is one. It may then fall under the CRA if it is placed on the market as part of a commercial activity.
Beware of in-between cases. For the Commission, everything depends on where the software runs: software supplied to the user and running on their own computer system may fall within the scope (point 20). Another example: a company that hands a client, under licence, the source code of an internal platform places that code on the market, even if the client still has to adapt it (example 7). Will your web application be installed on your servers, or will its source code be handed to you? Ask your supplier and your counsel. These guidelines are not binding: only the Court of Justice interprets the regulation with authority (point 8).
The five clauses to check before signing
- The assignment of rights: in writing, each right named, with its extent, its purpose, its place and its duration; and the warranty that the supplier holds the rights of everyone who wrote the code.
- The trace of the human contribution: approved specification, choices, reviews and version history, handed over with the code.
- The AI tool: which tool, which plan, who gets the outputs; the list of third-party components and their licences.
- Reversibility: source code, documentation and access handed over, with a timing, a format and a deadline.
- Security: web application, installed application, hosting with you or handover of the source code? Who monitors and fixes vulnerabilities, and for how long?
Going further
- How we build software for which you set the budget: Custom software.
- Where your data goes and how we protect it: Data and security.
- The steps, from approved specification to delivery: Our method.
- To tell us about your project: contact us.