Abstract
The article examines the main legal issues connected with the use of AI in software development. It clarifies when the generated code may belong to the user and when it may be protected exclusively. It also analyses similar outputs between users, unfair competition and possible forms of registration or protection. It addresses the risks connected with entering code, know-how and ideas into AI platforms.
If I use AI to program, who owns the generated code?
Anyone who develops software with tools such as Claude, ChatGPT or Copilot often asks a simple question: does the code generated with the help of AI really belong to the user?
To answer, it is useful to distinguish between two different profiles. The first concerns ownership of the output, that is, the code produced by the platform. The second instead concerns the possibility for the user to claim an exclusive right over that code.
On the first point, the answer is found in the terms of service of the platform used. In general, the user is considered the owner of the output, but there may be limits connected with the type of subscription, free or paid, and with the use that the user intends to make of the result, especially if commercial.
The second profile is more delicate. The terms of service, by themselves, are not sufficient to establish whether the code is protected by copyright. For a creation to be protected, it must have creative character. The Italian law on artificial intelligence amended Article 1 of the Copyright Law, providing that “works of human intellectual creation having creative character […] whatever their mode or form of expression, including where created with the aid of artificial intelligence tools, provided that they constitute the result of the author’s intellectual work” are protected.
This means that the more relevant the creative and design contribution of the human developer is, the more it will be possible to argue for the existence of exclusive protection over the software. If, instead, the result derives almost entirely from the intervention of AI, without a recognisable human contribution, copyright protection becomes more uncertain.
In some cases, the practical result could be that the generated code is not protected by an exclusive right and ends up, at least in concrete terms, in an area comparable to the public domain.
This does not mean, however, that code generated with AI is always freely copyable. Even when copyright protection is uncertain, other rules may come into play, including those on unfair competition. In particular, the slavish reproduction of a competitor’s software, if capable of creating confusion or of exploiting the work of others, may be unlawful regardless of the tool used to create it. The point, therefore, is not only whether the code was written by a person or generated with AI, but whether the concrete use made of it amounts to a form of slavish imitation or improper appropriation of another’s result.
For those who systematically use AI in software development, therefore, the question should not only be “who owns this code?”, but also whether there is sufficient human intellectual work to give rise to copyright in the result obtained with the aid of AI. And, on the other hand, whether that result is truly independent from competing products already present on the market.
Can AI platforms use my code or my idea to train their models?
When a developer enters source code, technical documentation, know-how or product ideas into an AI platform, the question becomes different: what use can the service provider make of it?
In Europe, there are regulatory safeguards. The GDPR applies when the input contains personal data and requires, among other things, lawfulness, transparency, purpose limitation, minimisation and security of processing (Arts. 5 and 6 GDPR). The Data Act, instead, regulates access to and use of data, including non-personal data, in the European digital market, and has been applicable since 12 September 2025 (Regulation (EU) 2023/2854).
Then there are the terms of service, which vary greatly from platform to platform. OpenAI, for example, states that the content of business users, including ChatGPT Business, ChatGPT Enterprise and API, is not used by default to train models. For individual users, instead, the use of content for model improvement also depends on settings and on any opt-out.
Anthropic adopts a similar distinction: for commercial products, such as Claude for Work, Anthropic API and Claude Gov, it states that inputs and outputs are not used by default for training. For consumer products, instead, the rules are different and may include the use of conversations or coding sessions to improve the models, according to the applicable conditions.
Google, in turn, distinguishes between consumer services and business or cloud environments. For Gemini in Google Workspace, Google states that content is not used to train Gemini models outside the domain without permission; for Gemini Enterprise Agent Platform, it states that data is not used to train or fine-tune AI/ML models without the customer’s prior authorisation or instruction.
In practice, however, the issue remains. These statements are important, but they do not eliminate the problem: who can truly verify, from the outside, how those data are processed at every technical, organisational or infrastructural step? In the case of strategic code, non-public know-how, credentials, proprietary architectures or product ideas not yet protected, the safest rule remains the simplest: do not enter them in the prompt.
For a company, therefore, the use of AI in software development should not depend on the prudence of the individual developer. A clear internal rule is needed on which tools to use, with which accounts, for which activities and with which limits. Because the most effective way to protect confidential information is to prevent it from ceasing to be confidential.
Looking ahead, the AI Act should make the framework clearer, especially as regards providers’ transparency and documentation obligations. Some deadlines, however, have already arrived and others will arrive in the coming months. The fact remains that, for a company, the strongest protection cannot depend only on what the provider states in its terms of service. If information is truly strategic or confidential, the safest way to protect it remains not to enter it into the platform.
Can another user receive suggestions similar to mine?
Yes, it is possible. Generative AI systems do not work like a consultant who reserves a solution for a single client. They produce responses on the basis of probabilistic models, instructions received and available data. For this reason, two users who formulate similar requests may receive similar outputs, especially when they request standard technical solutions, recurring portions of code or common architectures.
It is no coincidence that many platforms include in their terms of service a disclaimer on this side effect of generative AI: outputs may not be unique and different users may receive identical or similar results, even without any direct transfer of content from one account to another.
This does not necessarily mean that the platform has “copied” one user’s work in order to deliver it to another. Often it only means that, when faced with similar problems, the model tends to propose similar solutions. In software this is particularly evident: many development functions, structures and patterns are already widespread, documented and repeated.
The point, however, is important for anyone seeking a competitive advantage. The output generated by AI is not automatically exclusive merely because it originates from the user’s prompt. If the request is generic, the result will also tend to be generic. Protection becomes stronger only when there is a recognisable human contribution: design choices, integration into the product, adaptation to the context, code review and overall organisation of the software.
For a company, therefore, AI can help in development, but it should not be treated as the place in which to deposit the most confidential part of the project. If an idea, an architecture or a technical solution must remain truly distinctive, it must be managed outside the platform or entered only after carefully assessing the terms of service, the account used and the level of confidentiality required. Otherwise, the risk is not only that someone “copies” the result, but that that result was never truly exclusive.
Can the result developed with AI be registered?
Yes. The fact that a solution was developed also with the help of AI does not, in itself, prevent it from being protected or registered. It is necessary, however, to understand what the object of protection is.
If the result is software, copyright protection may come into play and, in Italian practice, also filing with the Special Public Register for computer programs kept by SIAE.
If, instead, the solution solves a technical problem in a new and non-obvious way, patent protection may be considered. Here AI may have helped in research or development, but the inventor must be a natural person and must have made a recognisable inventive contribution. Ownership of the patent may then belong to the company, the client or another party, according to contracts, employment relationships and applicable rules.
In other cases, what deserves protection is not the code itself, but the external appearance of the product, the interface, the shape of a device, the layout or the visual experience. In these cases it may make sense to consider registration as a design or model, provided that the required conditions are met.
The point, therefore, is not to ask in abstract terms whether “something made with AI can be registered”. The correct question is: which part of the result do I want to protect? The code, the technical solution, the external appearance, the name, the logo, the database, the know-how? Depending on the answer, the instrument of protection, the requirements and the party that may proceed with registration change.
For this reason, when AI enters development, it is advisable to keep track of the path followed: specifications, relevant prompts, revisions, tests, design decisions, contracts with collaborators and licences for the tools used. Not to make the work heavier, but to be able to demonstrate where the result comes from and on what basis it can be protected, registered or exploited.
Reviewed by: Arlo Canella
Publication date: 17 June 2026
© Canella Camaiora S.t.A. S.r.l. - All rights reserved.
Textual reproduction of the article is permitted, even for commercial purposes, within the limit of 15% of its entirety, provided that the source is clearly indicated. In the case of online reproduction, a link to the original article must be included. Unauthorised reproduction or paraphrasing without indication of source will be prosecuted.
Margherita Manca
Avvocato presso lo Studio Legale Canella Camaiora, iscritta all’Ordine degli Avvocati di Milano, si occupa di diritto industriale.