AI in software development: who owns the code and who is liable for errors?

Does an IT service provider have to disclose that it uses AI?

An IT service provider does not have to tell its client of its own accord that it uses AI. There is no direct statutory obligation to do so, not even in the AI Act, the European AI Regulation, because AI is a working tool of the contractor. The situation is different if the parties have contractually agreed on the use of tools.

The question of disclosure affects both sides: contractors do not always want to disclose their use of AI, while clients sometimes want to ensure or exclude it, for example because of the price.

Contracts for IT services are usually service contracts or contracts for work (Dienstverträge or Werkverträge). What is owed is an activity or a specific result, such as a development outcome. Standard contracts usually do not specify how the contractor gets there. If the contract structures the development process in advance, for example according to the waterfall method or Scrum, it can also specify the tools.

As with a tradesperson, whom you would not tell which hammer to use, the rule is: anyone who wants to specify the tools has to agree on them.

The labelling obligations under Art. 50 AI Act do little to change this either. Providers of AI systems must mark audio, video and text in a machine-readable format. For deployers, put simply, there is a perceptible labelling obligation for text intended to inform the public. A service provider that uses AI as a tool is generally a deployer. Even if code is regarded as text in the broadest sense, commissioned software code almost never serves to inform the public.

A conversation about the use of AI nevertheless becomes advisable or even necessary in any of these cases:

• Contractual agreement: The contract governs which working tools the contractor may use.
• Duty to inform: The circumstances give rise to an obligation to inform the client.
• Rights to the input: The client's code, data or trade secrets are to be fed into the AI.
• Client's interest: The client explicitly wants to know whether and how AI is used in the project.

Rather than a statutory disclosure obligation, in practice it is the setup and scope of the AI use, above all the input, that determine whether the use of AI can be kept secret.

What may a service provider enter into a prompt?

A service provider may enter anything into a prompt that is not subject to third-party rights: its own works for revision, public domain content and its own prompts. Copyrighted works such as specialist articles, photos, videos or songs should not be entered without the corresponding rights.

"Third-party rights" is to be understood broadly here. These three categories of content come with caveats when they are to be entered into an AI:

• Copyrighted works: Entering them into an AI regularly constitutes a use relevant under copyright law, because a copy is created, at least initially.
• Personal data: Strictly speaking, not a third-party right in legal terms, but processing in the AI requires a legal basis.
• Trade secrets and confidential information: The client wants them protected, and contracts often expressly govern how they are to be handled.

How strict the requirements are depends on the purpose. If a developer uses AI as a research tool or as a substitute for a Google search and does not enter anything sensitive, the risk is low.

The situation is different in a typical development project. A client wants its software 1.0 turned into version 2.0, and the code of version 1.0 is to form part of the input. This immediately raises the copyright question of whether the service provider may enter this code into the AI.

Depending on the project, certain rights of use will already have been transferred with the commission. For more complex projects, we recommend a contract that expressly permits entering material into the AI. If personal data is to be processed in the AI, the contractual relationship must reflect the legal basis for this.

It is therefore necessary to clarify where the input comes from and who holds rights to it or can block its use for AI. This determines whether a contract or licence must cover the use to the intended extent.

As soon as the input affects the client's rights, the use of AI can hardly be kept secret any longer, and the parties must clarify in advance, to an extent that depends on the AI use, what may go into the prompt and what happens to the data afterwards.

What happens to the data at the AI provider?

If the service provider does not run the large language model (LLM), i.e. the language model, on its own servers, it generally passes the input on to a subcontractor. The obligation to protect the client's content generally extends to this chain of subcontractors as well. The contract with the LLM provider must therefore match the commitments made to the client.

Between input and output lies processing in the LLM. Depending on the setup, an entire chain of service providers is involved, filtering at interfaces so that certain data does not reach the base model. In the worst case, the AI provider trains its model on the client's trade secrets.

Before using an LLM service to deliver its services, the contractor should answer these questions:

• Who receives the input from the service provider?
• What do the subcontractors do with personal data, copyrighted works and trade secrets?
• Does the engagement of the subcontractor cover what has been promised to the client?

One instrument for this is the zero data retention agreement. In it, the LLM provider contractually undertakes not to store inputs and not to use them to further train its model.

Such agreements cost money and are reflected in the price. Anyone who enters a client's trade secrets into a free language model that can be used anonymously risks a breach of contract, especially if they have concluded a confidentiality agreement with the client.

The costs of protected LLM access should therefore be factored into the pricing from the outset, so that the chain of protection from client to model remains intact.

Who is liable for errors in AI-assisted software development?

The contractor who delivers AI-generated code to its client as a deliverable or as part of one is liable for it. This responsibility for results follows from the contract and the classic attribution rules of applicable law, not just from the AI Act. It applies regardless of the tool used. Pointing out that the AI made the mistake does not relieve the contractor of liability.

Courts are only just beginning to work out where responsibility begins and ends when AI is used, and with differing results. Three judgments from 2026 show the range:

• Higher Regional Court (OLG) of Hamm, judgment of 12 May 2026, 4 UKl 3/25 ("Aesthetify"): A website operator is liable for false statements made by its own AI chatbot. The bot had wrongly described managing directors as medical specialists, using a specialist title that did not exist.
• Regional Court (LG) Munich I, judgment of 28 May 2026, 26 O 869/26 ("Google AI Overview"): Google is liable for an incorrect AI Overview that associated publishers with scams, subscription traps and dubious practices. Google could not rely on having merely summarised third-party sources.
• Regional Court (LG) Berlin II, judgment of 1 June 2026, 52 O 62/26 ("AI and fragrance dupes"): Google is not liable for an AI-generated trade mark infringement. Google had not directly booked third-party trade marks as keywords. Nor had Google adopted the statement as its own, because an average user recognises that an AI was at work.

There is no settled line yet. In the provision of IT services, however, contractors should assume that an error will be attributed to whoever used the AI and concluded the contract for the result.

Contractors thus bear the liability risk for their AI code, but liability is only one half: the other concerns the rights to the code itself.

Is AI-generated code protected by copyright?

Under German law, AI-generated code is generally not protected by copyright. It is automatically generated content without the character of a work, because no human wrote it. Code that comes out of the AI unchanged is therefore not eligible for protection.

The following classification applies to copyright in software and other AI-generated content:

Reproduction is rare but illustrative: anyone who uses AI to develop a word processor and ends up with Word has a problem.

The normal case of newly generated code has more far-reaching consequences. In a typical contract for work for software development, the client receives rights of use in the development result, either expressly or implicitly. In genuinely bespoke development, exclusive rights of use are usually provided for.

If the contractor delivers pure AI output, there is no protectable subject matter in which it could grant these rights. The deliverable then has a defect of title.

The machine-readable marking that AI providers are required to apply under Art. 50 AI Act makes matters worse. If the output carries such a marker, anyone who can read it can tell that it is AI output. This makes it provable that no rights of use could be granted.

Anyone who promises exclusive rights to AI-generated code is therefore promising something they cannot deliver without further safeguards in the contract or the development process.

How can contractors secure the rights to the deliverable?

A contractor owes rights of use in a result in which no rights arise if it is pure AI output. This problem can be solved in two ways: through the contract or through the development process.

The first and simplest way is a contract that reflects the reality of AI use. Giving blanket guarantees of exclusive development results with exclusive rights of use is usually not a good idea in AI-assisted development.

AI-assisted software development means that developers continue working with the AI output and edit it to the point where, legally, the end result is a human development result. Contractors use this second route to make the code eligible for protection after all. Ideally, the code then reaches the threshold of originality, i.e. the threshold for a copyright-protected work.

These building blocks safeguard the AI-assisted deliverable legally and commercially:

• Contractual provision on rights of use: The contract describes which rights to the deliverable can realistically arise when AI is used.
• Internal guidelines: The development team has clear rules on what it uses AI for and how.
• Approval process: Developers edit the AI output before it goes into the deliverable, making a creative contribution in the process.
• Indemnity clauses: Interests that cannot be safeguarded otherwise are covered commercially through indemnities.

Clients are well advised to contractually oblige the contractor to follow such processes. Otherwise, if the deliverable is in the public domain, all that remains is damages, and the actual interest in exclusive software can no longer be fulfilled.

There is no standard solution for the rights to the AI-assisted deliverable, and even a clean approval process does not eliminate every risk of AI output.

What risks remain despite human editing?

Even if AI-assisted code reaches the threshold of originality, typical risks of AI output remain. The most important concern open source licences, security vulnerabilities and the documentation obligations under the Cyber Resilience Act (CRA):

• Open source components: Depending on how the language model is configured, open source components can find their way into the code. If a copyleft licence infects the development result, it suddenly becomes subject to an open source licence, and in a classic software development contract there is also a defect of title.
• Security risks: AI-generated code may contain vulnerabilities or be based on so-called hallucinations, i.e. outputs that seem plausible but are wrong. Here too, the contractor cannot escape responsibility by pointing to the AI.
• Documentation obligations under the CRA: For digital products, the Cyber Resilience Act may require a complete SBOM (software bill of materials, the list of all software components), comprehensive documentation and a certain security standard.

The contractor must therefore be able to trace and verify what happened during AI-assisted development and which open source components are in the code, otherwise licensing and security obligations cannot be reliably met.

What changes if the deliverable is itself an AI system?

If a service provider uses AI to develop a product that is itself a language model, the regulatory requirements shift significantly. The rules on input, processing and output continue to apply. For service providers developing AI systems, the following obligations are also decisive:

• Change of role under the AI Act: Anyone who makes an LLM available to customers goes from being a service provider to being a provider and bears the extended provider obligations.
• Product liability: Product liability requirements apply as they do to other software.
• Digital product under the CRA: The obligations for digital products under the Cyber Resilience Act also continue to apply.

The actual risks multiply when AI itself is the deliverable, and how the service provider structurally integrates AI as a tool becomes all the more important.

Conclusion: AI in software development needs both contract and process

AI software development only becomes legally secure through the interplay of two levels: the contractual design of AI use in each individual case and the internal structure at the contractor. Simply letting the AI get on with it is not a good idea.

It takes guidelines and a fixed approval process, anchored equally in the contract and in day-to-day development. Clients and contractors should clarify this before the project starts, because a result that is in the public domain or infected by a licence cannot be repaired after the fact.

Frequently asked questions

#1 Do I have to specify in the software development contract whether AI may be used?

There is no direct statutory obligation to regulate the use of AI in the software development contract. Depending on the extent of AI use, however, a provision is advisable or even necessary. This applies above all if the client's code, personal data or trade secrets are to be fed into the AI or if the client expects exclusive rights of use in the result.

#2 May a service provider enter client code into ChatGPT or Claude?

A service provider may only enter client code into an AI if it holds the necessary rights to it. In addition, the contract with the AI provider must generally also reflect the agreed protection. Entering the code regularly constitutes a use relevant under copyright law, because a copy is created, at least initially. For the client's trade secrets, free versions that can be used anonymously are generally ruled out, as there would otherwise be a risk of breach of contract.

#3 Does AI-generated code have to be labelled under the AI Act?

As a rule, commissioned code does not have to be perceptibly labelled. An IT service provider that uses AI as a tool is usually a deployer under Art. 50 AI Act, and for deployers, put simply, perceptible labelling only applies to text intended to inform the public. AI providers, on the other hand, must mark their output in a machine-readable format, which can make the absence of rights of use in the code provable.

#4 What is zero data retention?

Zero data retention is an AI provider's contractual undertaking not to store inputs and not to use them to train its model. For IT service providers, it is a way of protecting their clients' data and trade secrets throughout the subcontractor chain as well. Such agreements cost money and should be included in the project budget.

#5 Who owns code written by an AI?

Under German law, code generated by an AI without human editing is generally not protected by copyright because it lacks the character of a work. AI-assisted code can become eligible for protection if a developer edits it to the point where a human development result is created.

#6 What happens if AI incorporates open source code with a copyleft licence?

If a copyleft licence infects the development result, the delivered software is subject to an open source licence, and in a classic contract for work for software development there is a defect of title. For digital products, the Cyber Resilience Act may additionally require a complete SBOM.