Vibecoding in Practice: Who Is Responsible for the Code and Security?

Vibecoding - that is, building software simply by describing what you want and letting AI handle the rest - has opened programming to people who have never written a single line of code. But with it comes a question that most enthusiasts never think about: once that app goes out to the public, who bears responsibility for what it does?

At the event Vibecoding Without Consequences we looked at this from two angles. Simona Hodovská took on cybersecurity, data protection and GDPR. Pavel Čech followed up with the AI Act, copyright and the labelling of AI content. The common denominator of both talks was a single sentence: responsibility stays with you, not with the platform

Part one: “The biggest risk is ignorance”

Right at the start, Simona Hodovská dismantled the most common myth of the vibecoder. “You may be thinking: but I am not actually responsible for it, it is the AI, the platform, that creates it. But that is the catch - in most cases you really will bear the responsibility,” she warned.

To keep this from staying purely theoretical, she opened with three stories from the real world.

Lovable. A popular vibecoding platform on which people build websites and applications experienced what was probably its biggest security incident this year. A researcher discovered that he could get into the user database, read other people’s source code and their conversations with AI - things he should never have been able to access. The vulnerability remained open for 48 days before anyone began to take it seriously. It affected millions of projects that had previously remained public, because the closed version was a paid feature.

Replit. Entrepreneur Jason Lemkin publicly documented how he was building a robust application on the platform. The idyll ended the moment the AI agent stopped listening. “He told it clearly: I am leaving the computer, do nothing more, and above all nothing without my permission. Despite that explicit prohibition, the agent deleted the entire production database - more than 4,000 users. And then it even tried to cover it up,” Hodovská described. On top of that, the agent claimed that recovering the data was impossible. That was not true, but according to Simona even the loss of data alone can amount to a security and GDPR incident.

A platform for gamers. The third case - a sort of “Tinder for shooter gamers” - had, right on the home page, a database of all users accessible in the browser, including their e-mails, billing and contact details. The operator had no idea about the problem and only learned of it months into operation, when a researcher alerted him. “And that is exactly the worst part - the ignorance. Often you only discover the problem months after something actually happens. And again, it will be your responsibility,” she summarized.

To show that these are not three random outliers, Simona cited a study she mentioned in her presentation: of 5,600 audited publicly available vibecoded applications, roughly 60% contained security vulnerabilities, some of them critical. “That number seems terribly high to me. And in my view it is a good starting point for getting it lower.”

What to do about it - from the triad to an audit

According to Hodovská, the goal of every secure solution should be the so-called CIA triad: confidentiality (data that should stay with you stays with you), integrity (no one tampers with the data) and availability (you have the data at your disposal when you need it - for example when a user asks you for an export of their personal data).

Simona then walked the audience through specific regulations:

• The key is to determine whether you are a controller (you decide what happens to the data and how - and bear the responsibility) or a processor. And be careful: you are responsible for your processors. “Lovable, ChatGPT, any platform like that - those are still your processors. Even though they are much bigger than you, you are responsible for them.” Ideally you should have a data processing agreement with them, or at least their terms. You report a security incident within 72 hours, you respond to a data subject request usually within 30 days - and your app must technically make that possible.
• The Act on Cybersecurity. Your app probably will not fall under it (it targets mainly medium and large enterprises in critical sectors). But you can easily supply customers who are regulated - and they will require security measures from you contractually.
• The Cyber Resilience Act (CRA). It applies to practically every connected piece of software and hardware, and takes full effect from December 2027. The good news: the vast majority of products will fall into the mildest class, and you will be able to draw up the declaration of conformity for them yourselves.

In closing, Simona highlighted six things you can do right away: documentation, training, an AI policy, a directive on the processing of personal data, an incident response plan (who handles it even at nine in the evening) and a check of your security measures - plus an honest audit of what you actually clicked together. “Investigate. Ideally contact a lawyer, but it is not a must. Above all, do not leave it to chance.”

Part two: The AI Act is mainly about risk

Pavel Čech took the floor with the task of lightening up a heavy topic - and began with a surprisingly reassuring message. “What you have to take away from the AI Act is that the whole thing is really just about assessing risk. And the interesting conclusion is that the vast majority of AI products you can think of are not regulated at all. Not at all.”

The AI Act divides systems into categories by riskiness. At the top are prohibited practices - subliminal manipulation, social scoring, emotion recognition in the workplace, blanket biometrics in public spaces. Below them are high-risk systems, which include safety components of certified products and listed areas such as HR (evaluation and promotion of employees), education (evaluation of entrance exams), client creditworthiness or critical infrastructure. “These three categories here - education, HR and the banking and healthcare systems - are the most surprising to me. Unless you happen to work for a power plant, this is exactly where it can catch you off guard,” Čech warned.

If you do not find yourself in any risk category, then according to Pavel you can applaud yourselves. At most you will be left with partial obligations for chatbots, voicebots and generative systems.

And one more relief: the deadlines have shifted. The Digital Omnibus pushed the effective date of obligations for high-risk systems to the end of 2027, or summer 2028 respectively. “For once it is not the lawyers’ fault but the engineers’ - we are missing technical standards. We have a regulation saying that risk management and human oversight should work, but nowhere is it precisely written how.”

Do I have to label content as AI? Usually not

The topic Pavel has been asked about most by people lately is the labelling of AI outputs. His answer is unexpectedly sober: “If someone told you that you have to label everything as AI, that is not true. The way it is set up now, the main obligation lies with the creators of generative AI themselves - OpenAI, Anthropic - to make sure the output carries a trace in its metadata or a watermark showing it was created by a machine.”

As a user (deployer), only three situations concern you in which you must label:

1. You create a deepfake that is interchangeable with reality.
2. You generate text that informs the public and that has not gone through human review.
3. You operate a chatbot or voicebot - a person must know they are not speaking with a human.

Everything else - internal tools, obvious satire, reviewed marketing texts - you do not have to label. These rules (Article 50 of the AI Act) start to apply on 2 August 2026, for which the European Commission has already issued a code of good practice.

Copyright? In the AI era “a somewhat dying thing”

Pavel saved the most provocative part for last. “What you create with Claude Code or anything else is not protected by copyright. Copyright today protects only what a human created.”

In practice, though, he says almost no one is bothered by this. If you give the code to no one, it is yours. If you do give it to someone, you have a contract with that person - an employment, development or licensing contract. You only really start dealing with copyright in one case: someone with whom you have no contract takes your code out. “And at a time when that code does not have to be a copyrighted work, because a human did not write it, you get into a tight spot. You have to prove that it is your work. And let me ask - who among you today documents how much code was written by people?” A single hand went up in the hall.

The conclusion is therefore unambiguous: the future is not copyright but contracts. “Without an NDA, without a rights assignment agreement, without a licensing contract, it will not work going forward. That is the only thing you can rely on.”

The final warning concerned training models on publicly available data. The European text and data mining exception allows this, but only if the author has not reserved the use (an opt-out, common across websites today) - and only for the training itself, not for copying. That this is not a theoretical boundary was shown by the judgment GEMA v. OpenAI, which the Munich court handed down on 11 November 2025: if a model “memorizes” training data and is able to reproduce it (in this case the lyrics of songs), it already amounts to unauthorized reproduction that the exception does not cover. OpenAI is appealing.

So how should you approach vibecoding

One sober but optimistic conclusion follows from both talks: vibecoding is neither forbidden nor impossible. It just requires you to admit that responsibility goes out with the app together with you. If you leave the event with a single task, let it be this little starter pack:

• Audit what you have clicked together - what the app collects, where it flows and who can access it.
• Map your processors (platforms and AI tools) and verify whether you have their terms or a data processing agreement.
• Set up basic security measures - access, permissions, backups, logs.
• Have an incident plan - who decides and whom you call when something happens.
• For AI content, deal with labelling only in three cases (deepfake, unreviewed text for the public, chatbot/voicebot).
• Contracts over copyright - NDAs, rights assignments and licences are what you can actually rely on.

As Simona Hodovská summed it up: “Just as ignorance of the law is no excuse, neither is the fact that AI generated it a legal excuse.” And as Pavel Čech added, the good news is that the vast majority of the strictest regulation does not concern you at all - as long as you know what you are doing.