AI-Generated Software: software ownership, human contribution, and evidence of rights

What risks arise when code is generated, suggested, or integrated by AI?

The use of artificial intelligence tools in software development raises three areas of concern:

• the protectability of the code;
• its provenance; and
• the legal certainty of its use.

The first concerns the protectability of generated code. As noted above, copyright protection is stronger where the code proposed by AI is selected, modified, and integrated by the programmer into an overall form of expression attributable to human choices. Conversely, standard, commonplace, or functionally dictated code may receive weaker protection.

The second concerns similarity to pre-existing code. Generative AI tools are trained on large volumes of data and may produce outputs similar to portions of existing code, including libraries, snippets, or public repositories. In such cases, the assessment must focus on the provenance of the output and the potential incorporation of third-party material.

The third concerns open-source licences. Code suggested by AI may display similarities to components distributed under permissive or copyleft licences. Certain licences impose obligations relating to attribution, the retention of notices, the distribution of source code, or the release of modifications under the same licence. This issue has already arisen in Italian case law, as discussed in “Open-Source Licences and Copyright: The Court of Milan on Licence Infringement”: in Judgment No. 7112/2023, the Business Court Division of the Court of Milan addressed the infringement of an open-source licence applying to software, confirming the legal significance of obligations concerning the retention of copyright statements, notices, and licence terms. The inadvertent inclusion of code that is incompatible with the project’s business model may give rise to contractual claims, removal requests, disclosure obligations, or the loss of exclusivity in the software.

The use of AI is also material in relation to contracts and warranties given to customers, investors, or purchasers. In development, licensing, assignment, investment, or acquisition transactions, the ownership of the code, freedom from third-party restrictions, licence verification, and documentation of the human contribution become central.

The prudent operational rule is that AI-generated code must be verified, documented, subjected to similarity and open-source compatibility checks, integrated through human review, and accompanied by a clear chain of provenance. In this way, AI remains an efficiency-enhancing tool without becoming a weakness in the protection and exploitation of the software.

What documentary evidence is required to prove ownership and human contribution?

Evidence of ownership of software developed using artificial intelligence tools concerns the process that led to the final code: design, selection, modification, integration, and human oversight.

In AI-assisted software, evidence concerns not only the existence of the code, but also the manner in which that code was conceived, directed, selected, modified, and integrated. The case law treats the assessment of creative contribution as a question of fact; it is therefore essential to build a body of documentation capable of explaining the process, not merely the result (see Italian Supreme Court, First Civil Division, Judgment No. 13524 of 13 June 2014; Judgment No. 10300 of 29 May 2020; and Order No. 32871 of 8 November 2022: “The actual substance of that autonomous contribution is subject to an assessment that ultimately constitutes a determination of fact”).

This approach finds significant support in the case law of the Court of Justice of the European Union. In Painer (CGUE, 1 December 2011, Case C-145/10), the Court observed that the originality of a photograph may arise from the free and creative choices made by the author at the various stages of creating the work, from preparing the shot to selecting the final image. Although the judgment concerned photography, it highlights a principle of general application: creativity may manifest itself through a plurality of decisions that characterise the process by which the work is created. In software developed using artificial intelligence tools, this principle supports attaching weight to choices concerning the design, selection, integration, revision, and organisation of the code, which may constitute the principal manifestation of the human creative contribution.

The first safeguard is the project’s technical history. Put simply, it is necessary to preserve records showing how the software originated and changed over time: versions of the code, modifications, corrections, tests, commits, technical notes, and review stages.

The second safeguard is evidence of human control over the AI. This category serves a different purpose from the mere chronology of development: it demonstrates how the human being directed the generative tool. Relevant evidence includes the prompts used, outputs produced by the system, alternatives generated, notes explaining why a solution was accepted, rejected, or reformulated, and the corrections through which the code proposed by the AI was adapted to the project.

The third safeguard is project documentation. Functional specifications, architecture documents, diagrams, technical roadmaps, manuals, API documentation, decision logs, and preparatory material help demonstrate that the software results from human design direction.

The relevance of project documentation is confirmed by European Union case law on software. In Bezpečnostní softwarová asociace (CGUE, 22 December 2010, Case C-393/09), the Court of Justice recalled that the expression “computer program” also includes “preparatory design work leading to the development of a computer program”, provided that the nature of the preparatory work is such that a computer program can result from it at a later stage.

This principle was applied in a particularly useful manner from an evidential perspective by the Business Court Division of the Venice Court of Appeal in Judgment No. 1665 of 7 June 2021. In that case, the Court stated that relevant preparatory material “already presupposes the use of technical language enabling the programmer to proceed immediately with the subsequent creation of the source code.” The Court also held that documents consisting of “nothing more than an explanation of the result that the program was intended to achieve” [sic] and “a specific indication to the programmers of what the program was required to provide to the user” were not relevant.

The principle is also valuable in relation to AI-assisted software: project documentation evidences the choices that shaped the final result, going beyond a mere description of the program’s objective. Architecture documents, diagrams, technical specifications, and decision logs may therefore prove decisive where they demonstrate logical flows, module organisation, criteria for selecting outputs, revisions, tests, and code integration.

Project documentation serves to demonstrate that the program does not originate from an isolated instruction, but from organisational, technical, and expressive choices attributable to a human author.

The fourth safeguard concerns code provenance. Where AI outputs, libraries, snippets, frameworks, or third-party components enter the project, it becomes important to preserve dependency lists, licences, notices, similarity-scan reports, open-source audits, Software Composition Analysis reports and, in more structured projects, a software bill of materials (SBOM). These documents help clarify which parts derive from human contribution, which originate from external components, and which must be managed in accordance with specific licensing terms.

This issue is central in light of the risks associated with open-source licences, already addressed in “Open-Source Licences and Copyright: The Court of Milan on Licence Infringement.” Moreover, in its judgment of 18 December 2019 in Case C-666/18, IT Development SAS v Free Mobile SAS, the Court of Justice of the European Union clarified that the breach of a term in a computer-program licence agreement, where it concerns intellectual property rights, may amount to an infringement of intellectual property rights.

The fifth safeguard is evidence of priority in time. Trusted timestamping, deposit of the source code, deposit with SIAE, software registration, digital notarisation, and legally compliant electronic preservation serve to establish that a given version of the program existed at a particular point in time. Their function is evidential: they strengthen the position of the party required to prove that the software, or that specific version of it, already existed on a certain date.

These mechanisms do not replace evidence of the human creative contribution, but supplement it.

The categories of evidence are similar in all cases; what changes is the degree of formalisation. An individual developer may rely on the code history, retained prompts, technical notes, tests, and trusted timestamps. A freelance developer or software house should add contracts, clauses governing the use of AI, warranties as to code provenance, and rules governing delivery of the source code. A company or structured team should integrate these elements with internal policies, roles, approval workflows, periodic audits, and document-retention procedures.

Without prejudice to what has already been stated regarding providers’ Terms and Conditions and third-party material, the contractual dimension is particularly significant where the software involves clients, freelance developers, software houses, employees, collaborators, or suppliers. In such cases, in addition to proving the human creative contribution, it is also necessary to establish the chain of title to the economic rights.

The strongest evidence consists of a coherent documentary chain: the technical history of the code, evidence of human control over the AI, project documentation, code-provenance checks, mechanisms establishing priority in time and, where necessary, contracts clarifying the chain of title.

The operational rule is clear: ownership of AI-assisted software is defended by demonstrating that AI operated as a tool and that the final result reflects an identifiable, verifiable, and legally relevant human process.