Vibe Coding: Legal Issues and Liability Risks of AI-Generated Software

Generative artificial intelligence has noticeably transformed software development within a short period of time. Software code and entire programs are increasingly created in dialogue with language models – no longer only by software developers or in the IT department, but also in business units without any programming skills. Under the term "vibe coding", a way of working has become established in which applications are created solely through natural-language instructions – often without the generated code being read or reviewed. The considerable efficiency gains are offset by legal issues ranging from data protection and the protection of one's own code to liability for infringing third-party rights. At the same time, EU law attaches to software irrespective of how it was created: the reporting obligations under the Cyber Resilience Act (CRA) have applied since 11 September 2026, and the new Product Liability Directive, which expressly covers software as a product, must be transposed into national law by 9 December 2026.

This article explains the forms vibe coding takes, classifies the associated legal issues and shows how companies can structure its use in a legally sound manner.

I. Definition and Forms

Vibe coding refers to the creation of software through natural-language instructions to an AI system that independently takes over design, architecture and implementation. The user merely describes the desired functionality, tests the result in live operation and requests changes where necessary. Many users neither read nor review the generated code itself. Since language models generate their output on the basis of statistical probabilities, the code is also only reproducible to a limited extent and often not comprehensible to the user. The problem is therefore less the use of AI as such than the absence of human oversight.

Vibe coding must be distinguished from forms of AI assistance in which the developer retains responsibility for the structure and content of the code, for example code completion suggestions or the generation of individual program components. The legal consequences depend largely on how far the design of the program is handed over. The intended use is also significant: for internal tools, data protection and security law issues are paramount; for software intended for customers or the market, product-related obligations and liability risks are added.

II. Legal Assessment

1. Data Protection

From a data protection perspective, a distinction must be drawn between the use of the AI system during development and the operation of the resulting application. Coding tools process not only the user's instructions but regularly the entire project context, including databases, configuration files and logs. If these contain personal data, such as customer data in test environments, their transfer to the provider constitutes processing within the meaning of the GDPR. A data processing agreement under Art. 28 GDPR is then required and, where processing takes place outside the European Economic Area, the requirements of Art. 44 et seq. GDPR must be observed. If the provider reserves the right to use inputs to train its models, it is likely to be a controller in its own right to that extent – and the processor privilege does not apply. In that case, there will generally be no sound legal basis for the disclosure to the AI provider. This is of practical relevance above all where business units use freely available tools via private or free accounts whose terms provide for training use. Their use with personal data should be prohibited by internal policies.

The company remains the controller of the resulting application, regardless of who wrote the code. Under Art. 25 GDPR it must ensure data protection by design and, under Art. 32 GDPR, guarantee an appropriate level of security. Unreviewed code may contain typical vulnerabilities, such as missing access restrictions, unprotected interfaces or credentials stored in the code. In addition, AI systems sometimes integrate external services on their own, thereby triggering unnoticed data transfers to third parties. Since the controller must demonstrate compliance with the data protection principles under Art. 5(2) GDPR, the productive use of unreviewed applications is hardly likely to be compatible with the accountability obligation. If a risk materialises, the notification obligations under Arts. 33 and 34 GDPR apply. Infringements of Arts. 25 and 32 GDPR are also subject to fines under Art. 83(4) GDPR.

2. Protection of One's Own Code

Computer programs are protected by copyright under Section 69a of the German Copyright Act (UrhG) if they are the author's own intellectual creation. Under Section 7 UrhG, only a human being can be an author. For AI-generated code, protection therefore often fails at the outset for lack of a human creation. Even an extensive program remains unprotected if it has been generated entirely by AI. The user's instructions generally do not change this, as they merely describe ideas and functions, which are not protected under Section 69a(2) sentence 2 UrhG. A program created through vibe coding is therefore likely to be largely in the public domain. The situation may be different if the developer specifies the architecture, data structures and module layout and the AI only carries out the implementation, or if the developer substantially revises the output. Protectability must then generally be assessed for individual program components. Anyone relying on copyright protection must set out and prove the human contribution in the event of a dispute. Without documentation of the development process, this is unlikely to succeed. The consequences also affect licensing models, contractual grants of rights and the valuation of software in transactions.

The German Trade Secrets Act (GeschGehG), which can also protect machine-generated information, may serve as fallback protection. However, this requires a legitimate interest in confidentiality and appropriate confidentiality measures. If the company permits the provider to use its code for training, these requirements are likely not to be met. Protection may also be lost if source code is delivered to third parties without protective measures, as is frequently the case with web applications. Trade secret protection therefore does not fully replace the exclusive right under copyright law but shifts protection to contract and organisation.

3. Third-Party Rights in Generated Code

Language models are trained on large volumes of publicly available code and may reproduce parts of it in their output. If a company incorporates such code into its own software, it is itself liable for any infringements. According to the prevailing view, whether the training of the model was lawful is irrelevant in this respect. Short, common code sequences are generally not protected for lack of individuality. Longer, distinctive passages are what matter most.

In practice, open-source licences are the main concern. Copyleft licences such as the GNU General Public License (GPL) require that derivative software, when distributed, be licensed under the same terms, including disclosure of the source code. A breach can lead to the loss of usage rights. Breaches of permissive licences such as MIT or Apache 2.0 are likely to be more frequent; these require the retention of copyright and licence notices, which are regularly missing from AI-generated code. Injunctive claims exist irrespective of fault. For damages claims under Section 97(2) UrhG, the standard of care is likely to be guided by the available review tools, so that anyone who deactivates the filters offered or dispenses with a licence check will hardly be able to exculpate themselves. Indemnification commitments from tool providers offer only limited protection, as they are usually tied to the activation of such filters and only have effect between the parties.

4. Product Regulation and Liability

The CRA attaches manufacturers' obligations to the product with digital elements, not to how it was created (as we reported in Data Protection Update No. 243). Anyone placing vibe-coded software on the market must meet the same requirements for secure design, risk assessment and vulnerability handling as with conventional development. This presupposes that the manufacturer knows the composition of its product. However, third-party code reproduced by an AI system does not appear in the software bill of materials (SBOM) as a dependency, but as in-house development. Vulnerabilities in the original library may thus remain undetected and can hardly be attributed for reporting under Art. 14 CRA. Purely internal tools, by contrast, generally fall outside the scope of the CRA.

The new Product Liability Directive includes software in the definition of product irrespective of how it is supplied. Strict liability attaches to the defective product; the fact that the code is AI-generated therefore does not exonerate the manufacturer. Security vulnerabilities can also qualify as defects. According to the government draft, the German implementing act is to enter into force on 9 December 2026. In the contractual relationship with customers, the infringement of third-party rights constitutes a defect of title, while security vulnerabilities may constitute a material defect. Whether the mere lack of protectability of vibe-coded software already constitutes a defect where the customer was to be granted rights of use remains unresolved.

By contrast, the AI Act plays a subordinate role for companies using coding tools. What remains relevant is above all the obligation to promote AI literacy among staff under Art. 4 AI Act. Irrespective of this, management must, as part of its organisational duties, ensure that the use of such tools is governed by clear rules.

III. Recommendations

Companies should first govern the use of coding tools through an internal policy. This should specify which tools are approved in which configuration, which data must not enter the processing context, and from what level of use a human code review is mandatory. Lower requirements may suffice for internal prototypes. Applications that process personal data or are provided to customers, on the other hand, should not go live without review. From a technical perspective, the use of enterprise licences with a data processing agreement and excluded training use is recommended, supplemented by restricted file access and the exclusion of credentials. A licence and duplicate check should also be carried out before any release.

Documentation is equally important. Prompt histories, change logs and review results should be retained systematically, as they are needed both to prove copyright protectability and to exculpate the company in the event of liability, as well as to comply with obligations under the CRA. Manufacturers should supplement their software bill of materials with information on the origin of AI-generated components.

Finally, contracts need to be adapted. Contracts with development service providers should specify whether and to what extent AI may be used, how its use is to be disclosed, and who bears the risk of lack of protectability and infringement of third-party rights. With respect to tool providers, attention should be paid to the allocation of rights in the output, the exclusion of training use and appropriate confidentiality provisions. In M&A transactions, the use of AI in software development should be part of due diligence.

IV. Conclusion and Outlook

Vibe coding is not inherently unlawful. Rather, the risks arise from the absence of human oversight: the generated code is generally not protected by copyright, yet it may infringe third-party rights, contain security vulnerabilities and affect data protection obligations. Companies that govern its use through clear rules, review processes and adapted contracts can, however, reap the efficiency gains without losing legal control over their software.

Regulatory requirements will continue to increase in the coming months. The new Product Liability Act is to enter into force on 9 December 2026, and the CRA will apply in full from 11 December 2027. At the same time, case law on the protectability of AI-generated works and on the copyright assessment of AI training can be expected to take clearer shape.

This article was created in collaboration with our student employee Emily Bernklau.