VibeCoding Liability: Legal Risks & Due Diligence | IT-Medienrecht

VibeCoding describes a current trend where software is no longer programmed manually. Instead, it is developed almost exclusively using AI systems or no-code platforms. Founders and developers explain in natural language what their software should do or configure it via visual interfaces. Modern AI tools like Codex, ChatGPT, or specialized platforms then automatically translate these instructions into executable program code.

As an experienced IT lawyer with a particular passion for AI topics, I observe this development with fascination. While VibeCoding enables a significant increase in efficiency and drastically speeds up development, automated code creation also raises completely new legal issues.

For instance, it remains unclear who is liable if AI-generated code contains errors or causes damage. Similarly, the question of who ultimately owns the rights to such automated creations is unresolved. In this article, I will therefore focus on the civil liability of tech startups when using VibeCoding and no-code tools. I will also discuss the responsibility of platform providers and highlight the associated copyright challenges.

Furthermore, I will explain how uncertain intellectual property rights situations surrounding AI-generated code can lead to difficulties in legal due diligence and what this means for future investor discussions. I will also examine relevant standards such as Sections 823, 831, and 307 BGB, the German Product Liability Act (ProdHaftG), as well as provisions of the German Copyright Act (UrhG), and recent developments in EU law (e.g., AI Regulation) to provide practical guidance for founders, developers, and investors.

Liability Risks for Startups with AI-Generated Code

Startups that largely use AI-generated code face the challenge of being legally responsible for the quality and safety of this code. This applies even if it has not been fully tested or written by humans. In principle, AI systems have no legal capacity and therefore cannot be held liable themselves.

The responsibility for AI output—be it program code, texts, or images—lies with the person who uses the AI and utilizes its results. A company cannot claim that the AI is "responsible." An exclusion of liability merely by referring to the AI's origin is legally ineffective. This situation presents several facets:

Liability in Tort (Section 823 BGB)

• If faulty AI code causes damage, the startup is liable according to general tort principles. Section 823 (1) BGB establishes liability for damages if, for example, an absolutely protected legal interest (such as life, health, or property) is violated by negligently inadequately checked code.
• This could occur if software generated by the AI causes material damage to the user due to a programming error, such as data loss or system failure with consequential damage. The decisive factor is whether the startup has breached its duty of care, meaning it failed to exercise the care required in commerce.
• In the absence of human control over AI code, the startup could be accused of negligence, especially if a review or tests would have been required according to the state of the art. However, it must be considered that software errors can never be completely ruled out. Liability, therefore, requires a breach of duty, such as a complete lack of quality assurance.
• In addition to Section 823 BGB, tortious producer liability can also be considered. According to established case law, anyone who places a product (here: software) on the market must exercise sufficient control to avoid risks. Otherwise, they are liable in the event of damage through producer liability based on Section 823 (1) BGB.
• It should be noted that an AI itself is not a "product" in the legal sense. Instead, it is part of a software product or service offered by the startup. For further information on general legal challenges for startups, consider consulting legal experts.

Contractual Liability and Warranty

• The startup is contractually liable to customers for defects in its software. In the B2B context, startups often attempt to limit their liability contractually through general terms and conditions or specific agreements.
• However, in Germany, this encounters legal limits. A complete exclusion for simple negligence is usually ineffective in GTCs if it covers essential contractual obligations or unreasonably disadvantages the contractual partner (Section 307 BGB).
• Cardinal obligations—central obligations whose breach jeopardizes the purpose of the contract—may not be completely excluded in GTCs. In individually negotiated contracts between entrepreneurs, liability can be limited further, but intent can never be excluded (Section 276 (3) BGB). Strict standards apply to gross negligence and personal injury.
• Practically, this means a startup can limit its liability for slight negligence towards business customers to a certain extent. However, it cannot limit liability for serious negligence or damage to life, body, or health. Standard clauses that broadly exclude any liability for AI errors would generally be ineffective.
• Even in a purely B2B relationship, a complete exclusion of liability for AI errors, for which the startup is responsible, would often not withstand a content review pursuant to Section 307 BGB. This is because the customer would then bear the full risk. Moreover, a startup cannot invoke such clauses against consumers at all (Section 309 No. 7 BGB prohibits exclusions of liability for bodily injury and gross negligence in consumer contracts). For more details, consider insights on legally compliant contract drafting for software development on no-code platforms.

Liability for Legal Infringements (in particular Copyright)

• Another risk is that AI-generated code infringes third-party intellectual property rights. AI models, such as code generators like GitHub Copilot, have been trained with vast code datasets that may include copyrighted source code. Studies show that AI outputs are sometimes very similar to the training material.
• Consequently, there is a risk that newly generated code may fall under an open-source license, unbeknownst to the startup. For example, the AI could reproduce code from a GPL-licensed library. If the startup integrates this into its proprietary product, it risks violating license terms and potentially copyrights. Further information can be found in discussions about copyright in the digital world.
• Copyright-protected code segments may not be adopted without further consideration. Otherwise, there is a risk of injunctive relief and claims for damages by the copyright holder (Sections 97, 69c UrhG). A startup is liable here as the perpetrator or instigator of a copyright infringement, even if the adoption was unknowingly done by the AI, as the use of the result in its own product is attributed.
• Experts already warn that AI-generated code could be the "next warning trap" for developers. For example, if AI code output corresponds to a third party's code published on GitHub, the latter can send warning letters. A resourceful "troll" could even deliberately post code online under a strict license, speculating that AI systems will feed this code into various projects.
• This entails considerable risks for the startup, ranging from compliance violations for open-source software to claims for damages due to copyright infringement. Accordingly, a startup must thoroughly check all AI outputs, for example, by using code scanning tools for matches with known codes, and ensure it has rights to all code components. Failure to conduct such checks could also be considered negligence. For comprehensive insights, refer to information on open source in software development.

Product Liability

• In rare cases, damage caused by faulty code can also fall under the Product Liability Act (ProdHaftG). However, product liability traditionally applies to physical injury to persons or damage to property caused by a product defect. Whether purely digital products like software fall under the definition of a product has long been controversial.
• According to the current legal situation, software as such (without a physical data carrier) is not clearly defined as a "product" within the meaning of Section 2 ProdHaftG. This means that a pure software error, leading to data loss for example, does not currently regularly trigger product liability. In such cases, tortious and contractual claims remain.
• The situation is different if AI-controlled software is integrated into a physical product (e.g., an AI controls a machine or a vehicle) and an accident occurs as a result. Then, the entire system can be considered a defective product, and the manufacturer is liable under ProdHaftG.
• It is important to note that product liability is independent of fault; the manufacturer is already liable for product defects without proof of negligence. Therefore, it is particularly important in cases of personal injury whether the AI-based system can be qualified as a product. In cases of doubt, the injured party would in any case pursue parallel tortious action against the startup, for example, for breach of a duty of care.
• ProdHaftG liability cannot be excluded by contract. Section 14 ProdHaftG prohibits any advance agreement that excludes or limits the manufacturer's liability towards the injured party; such agreements are null and void. A startup can therefore not waive its product liability through general terms and conditions, neither towards consumers nor towards business partners, regarding claims of injured parties. Recourse agreements are only permissible in the internal relationship (e.g., between manufacturer and supplier).
• This means for AI startups: If their products fall under product liability, the strict liability rules are mandatory, and contractual indemnification is excluded. Given the previous uncertainty as to whether pure software is covered, this may not have been a major issue in practice. However, new EU rules are imminent and will clearly include software. For more details on this, see the New EU Product Liability Directive 2023.

Interim Conclusion: Startup Liability

A startup using AI and no-code for programming is generally liable for errors and damages like any software manufacturer. This holds true even though code creation is automated. The challenge lies in maintaining sufficient due diligence measures, such as quality tests, code reviews, and license checks, despite a high level of automation.

Automation does not remove responsibility; it merely shifts the nature of the risks. A lack of human final control over AI results can increase liability risks, as errors may remain undetected. Startups should, therefore, clearly regulate contractually what they promise without giving unrealistic guarantees.

It is crucial to recognize that they cannot exculpate themselves across the board. Ultimately, the person who places AI code on the market is liable for its effects.

Liability of Operators of No-Code Platforms and AI Coding Tools

Not only startups, but also providers of no-code platforms or AI coding tools could come under scrutiny if faulty or malicious software is generated via their systems. This raises the question of the extent to which platform operators are liable for results that their users generate with the tool.

Essentially, a no-code or AI code generator is a tool. The operator provides the infrastructure and perhaps predefined building blocks, while the user (e.g., the startup) uses them to build the actual application. This is why the industry often tries to contractually shift most of the liability to the user.

Typically, the terms and conditions of such services contain clauses stating that the user is responsible for compliance with all laws and that the platform operator assumes no liability for the accuracy or suitability of the applications created. Exemptions from liability in B2B T&Cs are permissible to a certain extent. Unlike consumer transactions, Section 309 BGB (list of prohibited clauses) does not apply directly. However, Section 307 BGB (content control) also applies between companies.

A complete indemnification of the provider for its own fault is likely to be ineffective in B2B T&Cs if it unreasonably disadvantages the customer. However, a distinction will be made: The platform provider should typically not be liable for errors based solely on the specific implementation of the user. This would be comparable to a tool manufacturer who is not liable for every misuse of their tool.

The situation could be different if the platform itself has an error that leads to damage, such as a software bug in the no-code engine that systematically causes incorrect calculations in all apps created with it. In such a case, the platform provider takes on the role of a manufacturer of a defective product. This is where liability for defects and the German Product Liability Act (ProdHaftG) come into play. The provider is liable to its direct customer (the startup) under contract law for ensuring that its tool has the agreed quality and is functional.

Under certain circumstances, the platform operator could also be liable in tort to third parties who are harmed by the error in the generated software if it can be accused of fault, such as gross negligence in the programming of the platform.

Contractual Limitations of Liability of Platform Operators

In practice, platform providers protect themselves in their terms of use. Exemptions from liability state, for example, that the provider is not liable for indirect damages, loss of profit, etc., and is only liable up to a certain amount. In B2B contracts, such limitations, like capping the amount of liability to the annual fee, can be effective, provided that no fundamentally important obligations are affected and no intentional conduct is excluded.

It is important to note that willful misconduct on the part of the provider always remains liable. A provider can exclude gross negligence to a certain extent in GTCs vis-à-vis an entrepreneur, but this is tricky. German courts tend to assume that clauses also exempting gross negligence are unreasonably disadvantageous, especially if the provider effectively has sole influence on the source of the error. Furthermore, liability for personal injury may not be contractually excluded in B2B either, as this violates fundamental legal principles.

Product Liability of Tool Providers

As mentioned earlier, it was unclear whether purely digital products fall under the ProdHaftG. The operators of no-code platforms could previously argue that software was not a product. Liability under the ProdHaftG therefore did not appear to apply. However, this legal situation is about to change at the EU level. In October 2024, an amendment to the EU Product Liability Directive was adopted that explicitly classifies software, including AI systems, as a product.

Article 4 of the new directive clearly defines software as a product. This means that in the future, manufacturers of software in the EU (after transposition into national law) will also be liable under the German Product Liability Act (ProdHaftG). This means for platform operators: If their no-code tool itself is faulty and causes personal injury, for example, if the generated application malfunctions on a device and someone is injured, the injured party can claim product liability directly against the tool provider once the new directive has been implemented.

Exclusion of liability is then excluded, as already provided for under current German law (Section 14 of the Product Liability Act). The Directive also tightens manufacturer liability. According to Art. 11 Para. 2, manufacturers should also be liable if product defects are caused by a lack of software updates. This is relevant if the platform provider fails to rectify known security vulnerabilities in its system by means of an update, thereby causing damage.

Planned EU AI Liability Rules

In addition to product liability, the EU is pursuing a comprehensive approach to regulating AI. The EU AI Regulation (AI Act) was adopted in 2024 as the first global legal framework for AI. It will largely come into force from 2026 and obliges providers of AI systems to carry out risk assessments, transparency, and safety precautions.

However, the AI Regulation does not contain any direct liability provisions. It is a market authorization and supervisory law, not a liability law. It does not contain any new offenses; rather, the obligations for the provision of AI are intended to reduce technical and organizational risks.

Additionally, the EU Commission proposed an AI Liability Directive in 2022 to make it easier for victims to obtain compensation. Among other things, this was intended to introduce simplified rules of evidence and presumptions in favor of injured parties, such as a right to information to identify the developer of an AI system and a presumption of causality if an AI breach of duty probably led to the damage.

In particular, it was planned to establish a claim under Section 823 (2) BGB in conjunction with the AI Regulation as a protective law in the event of breaches of the AI Regulation, for example, non-compliance with prescribed safety measures. This would have made AI violations directly sanctionable under civil law. However, the new EU Commission decided at the end of 2024 to withdraw this draft directive for the time being.

For operators of no-code platforms, it is important to note that they may already have to fulfill strict obligations under the AI Regulation as providers of high-risk AI systems, for example, if their tool is used for safety-critical applications. However, they should not be lulled into a false sense of security under liability law. Even if the special AI liability directive has been stopped, they remain vulnerable under general law.

Disclaimer clauses only help to a limited extent. An AI cannot be interposed as a "responsible party"; ultimately, a human or legal actor is always liable. Practice will show whether injured parties will try to hold platform providers more liable, for example, by arguing that the tool offered is similar to a product or that they were partly responsible.

Providers should, therefore, clearly regulate contractually what the user has to do, such as testing obligations and notification obligations in the event of malfunctions, and, if necessary, provide for recourse options. Ultimately, however, a platform operator who provides an unsafe AI tool in gross breach of duty cannot expect to be completely exculpated by general terms and conditions. Statutory guidelines such as Section 307 BGB, the German Product Liability Act, and, in future, the EU liability regime set limits so that the risks are not unilaterally passed on to the user.

Copyright Protectability of AI-Generated Code (VibeCoding)

A key question for startups that use AI code is: Is the AI-generated code protected by copyright at all? Only if a program source code is to be regarded as a personal intellectual creation of a person does it enjoy protection under the German Copyright Act (UrhG). Section 2 (2) of the German Copyright Act expressly requires that the work is a "personal intellectual creation."

Computer programs are protected by copyright in the same way as linguistic works (Section 2 (1) No. 1 in conjunction with Section 69a UrhG). However, this protection applies only if they reach the level of creation, meaning they exhibit a minimum degree of individuality through human design. For a deeper understanding of software ownership, explore the article on ownership of software.

Fully AI-Generated Code Lacks Human Creation

Fully AI-generated code precisely lacks this human act of creation. An AI does not "think" creatively in the copyright sense but generates content based on probabilities and training data. According to current understanding, an AI cannot, therefore, be an author.

In the patent case DABUS 2024, the Federal Court of Justice (BGH) clarified that an invention cannot have a non-human inventor. This assessment can be transferred to copyright law, where the creator principle also applies, according to which the author is always the human creator of the work.

Works created autonomously by AI—that is, works created without any formative human influence—are undoubtedly not protected by copyright. This is because "the human substrate" is missing in the creation, as it has been legally formulated. The European courts emphasize that only a human author can create originality in the legal sense.

The European Court of Justice (ECJ) defines a protectable work as the result of the author's own intellectual creation, which implicitly presupposes a human being. For example, in decisions such as Infopaq, the ECJ has stated that the author's individuality and creative decisions are essential, neither of which a machine can exhibit.

This means for VibeCoding code: If the code was generated without the creative contribution of a human being, it does not enjoy copyright protection. It would be virtually in the public domain and could not be monopolized by anyone as their own work. Any third party could copy and use such code without infringing the Copyright Act. This has serious consequences for a startup: the AI code could not be used exclusively; competitors would be able to legally take it over, which weakens the competitive position.

Human Influence in AI-Supported Creation

However, the reality is often more complex. Software is rarely created entirely without human intervention. There is usually a developer who prompts and directs the AI, selects the result, and perhaps combines or reworks parts. The legal question is whether this human contribution is sufficient to speak of human co-authorship or authorship. Here, case law and literature differentiate according to the degree of human influence:

• Autonomous AI Products

  If the AI truly creates autonomously and the human only gives a general order, such as "Write me a program that does X," then there is no personal creation by the human. A simple prompting ("Develop code for function Y") without specific content specifications will not grant the user authorship. The work then originates intellectually from the AI, which is why no protection arises in the absence of a human creator.

• Computer-Implemented Works with AI Support

  In this case, the human provides essential specifications, and the AI only serves as a tool for implementation. In the DABUS patent case, the Federal Court of Justice indicated that a significant human influence can enable attribution. In copyright law, this corresponds to the case where the user already provides the AI with a formulated idea or structure, such as their own draft source code or detailed instructions that the AI only refines.

  In this scenario, it could be argued that the human provided the "intellectual creation" and the AI acted as an extension, perhaps comparable to an autocomplete, but controlled by the human. Copyright protection would then be granted to the human if their contribution reaches the level of creation.

  An example: A developer designs the software architecture and core algorithms conceptually themselves (creative achievement) and then uses AI to program routines or optimize code. In this case, the result is a personal imprint of the developer that manifests itself in the code. The code would be protected as a computer program, and the developer or their company would be the author or owner of the exclusive rights.

• Borderline Cases

  Constellations in which AI and humans work closely together are difficult. Has the human only sketched out rough ideas, and the AI generates the creative code flow independently? Or did the human select many small suggestions from the AI and combine them (curator role)? This raises the question of the level of creativity of the human contribution.

  The current prevailing opinion is that mere selection or commissioning ("Make code for X") is not sufficient for authorship. There would have to be a qualitative creative influence. If the AI has created the majority of the code independently and the human only makes minimal corrections, protection is unlikely to be assumed. In case of doubt, the code would remain in the public domain, as no sufficient human design is recognizable.

It becomes clear: Copyright protection of AI code is possible, but only if the AI truly acts as a subordinate tool and the creative value content ultimately comes from humans. In many VibeCoding scenarios, where developers have 95% of the code generated by the AI, this threshold is probably not reached. The majority of the creative programming work is done by the machine, not the human. Accordingly, the resulting code components will be unprotected.

This assessment is also reflected in expert recommendations: companies are advised to clarify contractually and organizationally how AI output is handled, as "AI output is generally not protected." It is "not possible to assert any rights to it," which is crucial for commercial exploitation. Startups should be aware of this: code generated by an AI system may not provide a copyright defense against imitators.

At best, alternative protection mechanisms remain, such as trade secret protection (if the code is kept secret) or patents for underlying technical solutions (whereby AI-generated inventions again have the dilemma with the inventor—analogous to DABUS, a human inventor must then be named who has significantly controlled the use of AI). Furthermore, considering property rights to algorithms can provide additional layers of protection.

In summary: no copyright protection without human creativity. AI-generated code, therefore, often falls into a protection gap. A startup must, therefore, check exactly what share human developers have in an AI-generated code and document these shares to be able to argue for protection in the event of a dispute. Otherwise, it risks its core software product being legally regarded as "freely available"—which significantly impairs investment and innovation protection strategies.

Effects on Legal Due Diligence for Venture Investments

For investors and their legal advisors in legal due diligence (LDD), a startup's handling of AI-generated code is a growing concern. In financing rounds or tech M&A, the IP position and liability risks of the target company are carefully examined. If a startup relies heavily on automated code generation (VibeCoding), this poses particular difficulties.

Lack of IP Protection Rights and Impairment

As explained above, AI-generated code often cannot be protected as intellectual property. However, for investors in a software startup, the uniqueness and legal security of the code is an important value factor. If the startup has no patentable inventions and no copyrighted code (because much of the code comes from the AI), it lacks essential protection mechanisms against competitors.

Any competitor could reuse the disclosed code without paying a license. This is identified as a weakness during due diligence; the IP portfolio looks thin. Investors typically ask specifically: "What copyrighted software components or patents does the startup own? Have all rights to the software been clarified?"

If the answer is that the software is largely AI-generated and therefore virtually in the public domain, alarm bells start ringing. The startup then primarily owns know-how, brand, or customer access, but no exclusive code. From an investor's perspective, this can depress the valuation, as future competitive advantages are uncertain. Furthermore, investors will insist on comprehensive guarantees in the investment agreement that no third party can assert rights to the code, which is difficult to insure if there are actually no rights of their own.

Unclear Copyright and License Chains

A due diligence team will check exactly who is considered the author of the software and whether all rights have been effectively transferred. In traditional startups, there are usually developers (employees or freelancers) who assign their copyrights to the client by contract (Section 69b UrhG for programs). In the case of AI-generated code, the question is: to whom should rights be assigned if the AI has no copyright status?

Providers of AI coding tools often state in their terms of use that the user receives the rights to the output. However, such clauses have more of a declaratory legal effect; they cannot create copyright where there is none. At best, they act as a contractual promise that the tool provider will not make any claims of its own and will allow the user to use it.

In due diligence, these terms of use would have to be examined to ensure that no catch is hidden, for example, that the platform operator retains certain rights of use after all. Investors also check whether all human contributors (e.g., prompt engineers or employees who have curated AI results) have employment or service contracts with IP clauses to ensure that the company holds any rights that may arise.

A risk would be, for example, if a freelance consultant created prompts, the AI generated code from them, and this consultant later claims co-authorship because their contribution was creative. Due to the uncertainty, investors will demand that the startup has legally bound all parties involved via IP assignment and confidentiality agreements.

Risks from Open Source and Third-Party Code

A particularly sensitive point in due diligence is open source compliance and possible infringements of third-party rights. In the case of traditionally developed software, one examines which open source components were used and whether licenses (GPL, MIT, etc.) were complied with. This is more difficult with AI-generated code, as the startup may not even know if and which third-party code snippets have been incorporated.

As Chan-jo Jun (IT lawyer) points out, AI code is often very similar to the training material. Depending on the license of the original material, this may mean that the new code is also subject to licensing. In due diligence, experienced auditors will therefore ask: "Do you use AI for code? If so, what measures have you taken to exclude licensing risks?"

They may require that the code has been audited, for example, by tools that compare source code with known repositories (Black Duck, Fossology, etc.). Chan-jo Jun expressly recommends that buyers check AI-generated code line by line for matches with existing software. For more on this, consider the risks from code and asset production using AI in game development.

If identical or very similar sections are found, it must be clarified whether these are harmless (e.g., trivial lines of code that do not enjoy protection) or whether there is a risk of license infringement. The result of such an examination can be a deal breaker. If it turns out that central parts of the code should actually be under GPL or belong to proprietary third parties, the investor either demands cleanup (re-implementation of the relevant parts without AI) or assesses the legal risk as too high to invest.

Even in the early phase, a VC can have the term sheet guarantee that no significant part of the technology is based on problematic AI outputs. Otherwise, there is a risk of claims for damages against the founders under the contract.

Reputational and Liability Risks

Investors also consider the liability risk and the associated financial exposure. If a startup sells software developed with AI support, the due diligence will also check whether there have already been or are likely to be liability cases. For example: Have there been customer complaints or cases of damage in connection with a software error? Are there contractual limitations of liability, and are they effective?

A startup that has negligently delivered unsafe AI code could be confronted with latent liability lawsuits; this deters investors. They will want to know if the startup has taken out insurance (e.g., product liability, tech E&O) to cover such risks.

The future regulatory landscape also plays a role. An investor financing a startup in 2025 must anticipate which compliance obligations and liability rules will apply in the coming years. The EU AI Regulation, for example, will have to be complied with from 2026, which may mean registration and documentation obligations for a company specializing in AI code. If the startup were ignorant here, it would be a red flag in due diligence.

The same applies to the upcoming product liability reform: investors will price in the fact that claims could become more expensive once the new rules come into force because software manufacturers will then also be liable even if they are not at fault.

Recommendations and Measures for Due Diligence

From the investor's point of view, the following findings and conditions are typically made in a due diligence if highly automated software development is present:

• Transparency regarding the use of AI: The startup should disclose the extent to which AI was used and for which components. Due diligence consultants often request a list of all AI tools and an estimate of the proportion of code that originates from them. This is the only way to estimate the scope of potentially unprotected code.
• IP policy and controls: Does the startup have internal guidelines on how to handle AI outputs? For example, a guideline like: "No untested AI code should be transferred directly into the production system." A responsible startup implements quality controls to minimize risks. These include code reviews, including for AI-generated code, the use of plagiarism scanners, and documentation of all AI deployments (traceability). Such policies are noted positively in the LDD, as they show that management has recognized the issue.
• Legal opinion on the copyright situation: If necessary, the startup asks a lawyer to confirm how it views the intellectual property rights situation. Although uncertainty remains, an investor would prefer to hear that at least it has been checked whether there is a sufficient human contribution to critical code. If not, alternative protection must be found. Many startups then increasingly rely on secrecy (trade secrets). The due diligence process then checks whether, for example, the source code is not in the public domain and whether measures have been taken in accordance with the German Trade Secrets Act (GeschGehG). If copyright law does not apply, trade secret protection can at least prevent third parties from gaining unauthorized access to the code, provided that the startup protects it accordingly (access controls, NDA with partners, etc.).
• Insurance and indemnification: Investors will demand that the startup has insurance cover in the event of IP disputes or product liability cases, or that the founders are personally liable to a certain extent if they have concealed risks. Warranties are common in investment agreements, e.g., that all proprietary code is free from third-party claims. If founders know that they have used AI code, they must formulate this warranty very carefully. In the worst case, they must specify exceptions (disclosure schedules), which in turn discloses the problem to the investor. For more on this, review the legal preparation for the first investment round.
• Future IP strategy: A startup that has so far relied on AI code should be able to explain during due diligence how it intends to strengthen its IP in the future. This could involve targeted in-house developments of particularly critical components, patent strategies for AI-developed inventions (with naming of human inventors to ensure patentability), or exclusive training data that others do not possess. Investors want to see that the startup has a plan to create unique assets despite automation.

Specific Complications for Startups with a Strong Focus on AI

If a startup has created complex software based on AI generation in a short period of time with few staff, this may be impressive from a business point of view. However, in legal due diligence, it can lead to skepticism. Typical risks include:

• Code quality and maintainability: While not primarily a legal issue, tech due diligence and legal DD are intertwined here. AI-generated code could be difficult to maintain or understand, especially if no developer has fully grasped it. This can lead to delays in rectifying defects, which in turn becomes legally relevant if, for example, contractual service levels or warranty periods cannot be met.
• Dependence on third-party providers: If the startup uses third-party AI APIs (e.g., from OpenAI, Google), there is a contractual dependency. Due diligence checks: Does the startup have stable license terms with these providers? What happens if the service is discontinued or the conditions change (prices, rights to use the output)? These questions go beyond classic IP but concern operational risks that are considered in the investment.
• Regulatory environment: In the case of highly innovative AI startups, investors also look at future regulatory costs. For example: Does the product fall within the scope of the AI Regulation (possibly as generative AI, possibly with obligations for registration or conformity assessment)? Will the company be subject to certification obligations? For example, the due diligence may state: "The company must implement an AI compliance system within 2 years, costs approx. XYZ." Such aspects are then taken into account in the valuation or recorded as conditions subsequent in the investment agreement.

Conclusion on Due Diligence

For founders, a strong use of AI in software development accelerates development, but creates additional work and uncertainty later in the investment process. Many of the advantages, such as quickly generated code, must then be weighed against the disadvantages, including a less clear IP situation and potential legal risks.

From an investor's point of view, a startup is most attractive if it uses the efficiency of AI on the one hand, but has also proactively done its legal homework. This means introducing compliance guidelines, considering IP law issues, adapting contracts (general terms and conditions, license agreements) accordingly, and making risk provisions. Such a company can convince the due diligence process that it is "investable" despite VibeCoding.

In contrast, a startup that naively assumes "the AI code is already ours and will fit" is likely to encounter considerable difficulties during the audit. In the worst-case scenario, unresolved IP relationships or pending liability risks could lead to an investor jumping ship or only getting involved on significantly less favorable terms.

Conclusion

The use of AI and no-code platforms in tech startups is currently evolving faster than the legal framework. Liability questions still have to be answered based on general principles: anyone who uses AI tools is liable for their output as well as for their own actions. Neither startups nor platform operators can hide behind the "responsibility" of a machine. For a broader perspective on legal aspects, refer to Artificial Intelligence in the Company: Legal Aspects and Risk Management.

Under civil law, established standards (Section 823 BGB, product liability, contractual obligations) apply. These are flexible enough to be applied to AI constellations. The upcoming EU regulations—above all the AI Regulation 2024/1689/EU and the amended Product Liability Directive (expected 2024/2853/EU)—will further specify the framework without turning it on its head. AI systems will be regulated, and software products will be explicitly included in manufacturer liability, which tightens rather than reduces responsibilities. The expressly planned but then withdrawn AI Liability Directive shows that the legislator struggled to make things easier for injured parties, but has left this to development for the time being.

In terms of copyright, VibeCoding reveals a protection gap: as long as there is no human creative contribution, AI code remains unprotected. For startups, this means their "USP" is more difficult to protect legally. Innovative solutions could be considered in the future, such as new categories of intellectual property rights or adjustments to copyright law, which would, however, be controversial (currently, there is a conscious decision to link protection to human creativity).

There are different approaches internationally (for example, British copyright law recognizes so-called computer-generated works with a short term of protection, whereas the US Copyright Office rejects AI works). However, in Germany/EU, the line is likely to remain the same for the time being: no protection without a human author.

For legal due diligence when investing in AI-heavy startups, this means that diligence and transparency are essential. Ideally, startups should audit and eliminate their legal risks before a financing round. This includes identifying AI-generated code components, reviewing them, and, where necessary, replacing or securing them. They should also draft their contracts (with customers, suppliers, platforms) in such a way that the use of AI is regulated, for example, with disclaimers where permissible, and information obligations towards customers if AI has been used.

When dealing with no-code platforms, it is advisable to pay attention to contractual assurances from providers, for example, that their tool does not infringe the rights of third parties and is state-of-the-art. Some AI platforms now offer liability assumptions or guarantees to appear more trustworthy; these should be used where possible to reduce your own risks.

Overall, liability and IP in VibeCoding are complex but manageable if traditional legal principles are carefully applied to the new technology. The message for founders and developers is to proactively involve legal expertise instead of having to react in the event of a dispute. Investors, on the other hand, need to develop new valuation criteria to assess the value of a company whose products are technically innovative but may not have a traditional IP portfolio. The value may be shifting from static IP to dynamic ability to develop quickly with AI, but as long as legal systems strongly link competitive advantage to legal exclusivity, lack of IP protection will remain a hard factor.

Finally, it should be emphasized that technological development is rapid: startups should develop their compliance and contracts just as quickly. The planned EU regulations are expected to come into effect in 2026 and beyond. Smart entrepreneurs will use the transition period to set up their AI-supported processes in such a way that they are compliant and secure by then. Then nothing will stand in the way of the full potential of VibeCoding, without any nasty legal surprises.