Vibecoding in production: regulatory scope, real risks and the checks to run before deploy

A young entrepreneur showed us his application in June, built in eleven days with a code generator and already used by four paying customers. It worked well. Asked which npm packages were inside it, he said he did not know, because the model had picked them. Asked who could read the users table, he opened the database console and found a permissive policy across every row, written by the generator on day two and never looked at again.

Vibecoding has moved the bottleneck in software development from writing code to verifying it, and the jump from prototype to production, which used to take weeks of visible work, now happens without anyone noticing. This article sets out where applications generated with these tools actually sit inside the European regulatory perimeter, which structural problems the method introduces regardless of regulation, and which concrete checks belong on suppliers and on the team before anything goes in front of a real user. A glossary of the terms used follows at the end.

The scope of the Cyber Resilience Act

The common assumption is that the Cyber Resilience Act catches any software. On the point that matters for most applications generated with these tools, the Commission's guidance says the opposite.

On July 27, 2026 the Commission approved the application guidance required by Article 26 of the regulation, document reference C(2026) 5252, with the stated aim of making compliance easier for small and medium-sized enterprises. Its largest section deals precisely with scope.

The criterion is where the software runs. Software that executes on the user's device, meaning a downloaded app, a browser extension, a locally installed client, is a product with digital elements. Software merely accessed remotely through a browser is not, on that basis alone, and web applications used only through a browser together with websites that merely present information are generally not products with digital elements. They fall in scope only where they qualify as remote data processing supporting a product's function.

The draft guidance of March 3, 2026 had already confirmed explicitly that standalone SaaS falls outside scope. Cloud and SaaS come within scope only where the component qualifies as a remote data processing solution, which requires three conditions at once: that it processes data at a distance, that the product is unable to fulfil a core function without it, and that it was designed by or under the responsibility of the same manufacturer that designed the supported product. Only components satisfying all three legs fall within scope as remote data processing. Even where SaaS stays outside the Cyber Resilience Act, providing it in the Union can trigger the NIS2 Directive for the organisation.

One further clarification matters to anyone working with public repositories: the regulation's definition of software covers both machine code and source code, but simply sharing open-source code on a public repository is generally not placing on the market.

Translated into a triage table you can complete in half an hour:

What you put into production	Cyber Resilience Act	What applies anyway
Web app used through a browser only	out of scope	AI Act, GDPR, NIS2 if you are in scope
Mobile app downloadable from a store	in scope, together with the backend that makes it work	everything else
Desktop application, Electron, browser extension, CLI	in scope	everything else
SaaS with an installable agent or distributed SDK	in scope, and the backend comes with the product	everything else
Backend powering a customer's device	in scope as remote data processing	everything else
Progressive web app installable on the device	grey area, document case by case	everything else

For the typical portfolio built with these tools most applications stay outside the Cyber Resilience Act, and the real exposure comes from other directions. The recurring exceptions are installable progressive web apps, applications published on app stores and any browser extension, categories these environments produce as easily as a web page.

It is worth writing down the triage result and filing it with the reasoning, because the question will come from an enterprise customer long before it comes from an authority, and a documented answer is worth more than a correct answer improvised on the spot.

Obligations that apply anyway

Outside the Cyber Resilience Act does not mean outside everything. The four exposures below apply to an application generated in three days exactly as they apply to a product developed over three years.

AI Act transparency, applicable since August 2, 2026. If the application exposes a chatbot, an assistant, a text or image generator, there is already an obligation to inform users that they are interacting with an artificial intelligence system, and to mark synthetic content in machine-readable form. It is the most likely exposure and the cheapest to fix, and almost no application built over a weekend covers it.

Literacy, applicable since February 2, 2025. The obligation covers both those who develop and those who use artificial intelligence systems, and it is demonstrated through documented evidence. A team generating code with a model without being able to read what the model produces is exactly the case the provision means to cover, and training here is the condition for noticing an error rather than a formality.

High risk, applicable from December 2, 2027. An application built in three days can be high-risk without anyone having decided so. Candidate screening, evaluation or task allocation for employees, scoring for access to credit or essential services, assessment in education. These are all Annex III cases and they are all among the first problems a young entrepreneur tries to solve with a generator, because they look like interface and database problems. Anyone in scope will need a risk management system, data governance, technical documentation, automatic event logging, human oversight and conformity assessment.

NIS2 and data protection. Providing a service in the Union can bring the organisation into NIS2 scope based on sector and size, independently of the Cyber Resilience Act. Data protection law applies always, with one particularity: a database generated from prompts almost always carries a minimisation nobody designed, because the model adds columns when it needs them and never removes them.

Where the method is weak

These hold regardless of regulatory scope, because they are engineering problems before they are compliance problems. They are listed in the order we have met them in the field.

Nobody knows what is inside. A software bill of materials presupposes that somebody chose the dependencies. In vibecoding the model chooses them, often reaching for packages by plausible name, and the transitive chain stays invisible to anyone who only wrote prompts. The risk of abandoned packages or of names built to resemble known libraries is not theoretical, and it is compounded by the fact that the generator has no way of knowing whether a package was compromised last week. Even staying outside the Cyber Resilience Act, the component list is the first thing a structured procurement function asks for during supplier qualification.

The generator's security default. The most frequent class of error concerns row-level authorisation rules on managed databases, service keys ending up inside the bundle delivered to the browser, and serverless functions exposed without authentication. The generator produces code that works, and working is not the same as being protected. Anyone who does not know what a row-level security policy is cannot review one written by a model, and the model writes it permissive because that way the application starts on the first attempt.

The line between prototype and production evaporates. This is the central point. In these environments the prototype is deployed to a public domain from the first minute, so the moment when somebody consciously decides to go to production is missing. The decision happens by accumulation, when the first real user arrives and nobody notices. Every control that follows depends on restoring that decision point.

There is no change traceability. Without code review and without a change log nobody can answer the question of when a substantial modification was introduced, which is the test capable of reopening conformity assessment under the Cyber Resilience Act and technical documentation under the AI Act. Nobody can reconstruct which version was running when an incident occurred either, which is the first question in any post-event analysis.

Event logging and retention. For high-risk systems the AI Act requires automatic logging and retention for a defined period. Generated applications almost always carry development-grade logging, verbose where it is not needed and absent where it would matter, with personal data landing in logs without anyone having decided so.

Regressions without a safety net. A single prompt can rewrite a function nobody was watching. Without automated tests verification is visual, and visual verification does not cover authorisation, edge cases and error conditions. The speed of change that makes the method attractive is the same thing that makes silent regression likely.

The support period. Anyone within Cyber Resilience Act scope must declare how long they will maintain the product, on a horizon that in principle does not fall below five years. An application generated by a single startup founder, on a platform that may change its underlying model twice a year, has a problem sustaining that promise before it has a compliance problem.

Who the manufacturer is. If you place a product on the market under your own brand, the provider under the AI Act and the manufacturer under the Cyber Resilience Act is you. The platform on which you generated the code appears nowhere in that accountability chain. It works in the opposite direction too, and it bears directly on consulting work: if a prototyping unit delivers a prototype and the client puts it into production unchanged, the boundary of responsibility belongs in the contract before delivery.

Reliance on three suppliers

A typical vibecoded application rests simultaneously on three suppliers: the generation and hosting platform, the managed database, the model provider. Each with its own jurisdiction of corporate control, its own deprecation calendar and its own incident policy.

The due diligence question asked about these three suppliers today is almost always about price and speed. The questions the European framework makes relevant are of a different nature, and the cybersecurity package presented by the Commission on January 20, 2026 makes them current even for very small projects, because it introduces the possibility of designating suppliers as high-risk with progressive phase-out obligations.

The cost of exiting these three dependencies grows faster than a startup founder estimates, because the database schema, the serverless functions written for that platform, the prompts tuned to that model and the team's habits accumulate on top of the contract. Verifying real code portability before the third customer costs an afternoon, verifying it after the thirtieth costs a quarter.

Supplier checks

On the generation platform and the infrastructure, eight points to close in writing:

• Real code portability and repository ownership, proven with an actual export rather than a documentation entry
• Treatment of prompts and code, with explicit confirmation on use or non-use for training purposes
• List of sub-processors and data residency, current rather than generically declared
• Available certifications and independent assessments, with the date of the last offensive security test
• Vulnerability disclosure channel and timelines, checking compatibility with a twenty-four hour window where the reporting obligation sits with you
• Corporate control and jurisdiction, with future supply chain designation in mind
• The supplier's position relative to NIS2, because a supplier already in scope has processes you can inherit rather than build
• Incident and outage history, reconstructed independently rather than requested from the supplier

For the model provider, add four specific checks: versioning policy and deprecation notice period, behaviour when the model is updated under the same commercial name, location of data processing, and contractual clauses on the use of inputs sent for inference.

On each of these points the acceptable answer is a document or a clause. An answer given verbally on a sales call is worth nothing when it is actually needed.

Skills and accountability in the team

Team checks are fewer and harder to pass, because they touch competence and accountability instead of documents.

Named ownership. You need one person, with a name, accountable for the application, who answers for reporting and documentation. Without this every other control stays theoretical, because what goes missing at the moment of an incident is somebody who decides.

Who can ship to production. A second pair of eyes on release, even in a two person team. Vibecoding makes release so cheap that the barrier has to be reintroduced by hand.

Reading competence. At least one person able to read generated code across three dimensions: authorisation, secret handling, input validation. If that competence does not exist internally it should be bought by the hour, and it costs less than one incident involving customer data.

Documented literacy. The AI Act obligation is demonstrated through training records and content, not through the sense that the team is good. It needs a trail with dates, content and participants.

Owning the clock. Who receives the security report on a Friday evening, through which channel, with which escalation procedure and which stand-in during holidays. Twenty-four hours does not allow the process to be built while the incident is unfolding.

Knowing the perimeter. The team has to know whether the application it is building falls under Annex III, and that question belongs before the first prompt. Discovering it once the product is live means rebuilding the data architecture and the human oversight design.

The pre-production gate

Eight checks, all answerable in half a day, none of which requires a consultant to set up the first time.

1. Written and filed scope triage. Cyber Resilience Act yes or no, AI Act yes or no, Annex III yes or no, each answer with its reasoning and its date.
2. Bill of materials generated and filed, with a scan for known vulnerabilities in the components and a scheduled rescan date.
3. Manual review of database authorisation rules, table by table, with a negative test proving that an unauthorised user receives a refusal.
4. No secrets in the client bundle, verified by searching the production package rather than the source code.
5. Transparency implemented wherever a generative component is exposed to users, with marking of synthetic content.
6. Structured event logging with a defined retention period, an aligned privacy notice and a check that logs do not contain data they should not contain.
7. Published security contact and a written reporting procedure, with internal timings set backwards from twenty-four hours.
8. Named owner and boundary of responsibility with the client set out in writing, including the case of a delivered prototype.

Anyone failing these eight points has a prototype. The distinction between prototype and product is a decision somebody has to take consciously, and in these environments it has to be reintroduced as a formal artefact because the technology removed it.

The checklist

The gate, the scope triage and the questions to put to suppliers and teams are collected in a three page document built to be completed rather than read.

What it is for. Turning an implicit decision into a recorded one, with a date and a name next to it. Today the move into production happens by accumulation and nobody writes it down anywhere, so when the question arrives, from a customer running supplier qualification or from someone investigating an incident, there is nothing to show. The checklist produces that trail in half a day, and it is the same trail you need six months later, when nobody remembers why a choice was made that way.

How to use it. The first page is completed once per application and revisited at every substantial modification: the scope triage establishes which regimes apply and why. The second page is used when selecting or renewing suppliers, and its rows work well as an attachment to a request for proposal. The eight point gate is walked at every release, and after the first time it takes an hour.

Who completes it. The named owner of the application for the scope and ownership parts, whoever runs the release for the gate, whoever handles procurement for the supplier checks. In a two person team the three roles coincide, and that is fine, provided the name written down belongs to a person and not to a department.

What it is not. It is not an attestation of conformity, it does not replace legal advice and it certifies nothing, because no document completed by the people who built the thing can do that job. It is a decision tool, and it serves to establish where you stand before opening a programme and spending a budget.

Licence and credits. The document is released under a Creative Commons Attribution NonCommercial 4.0 licence. You may use, print, complete and adapt it inside your own organisation, including as a commercial company, and share it with colleagues, suppliers and clients. You may not resell it or include it in paid consulting, audit or training services delivered to third parties. Every reproduction or citation must carry the source, ZeroFive.AI, with a link to zerofive.ai where the format allows. For commercial use write to hello@zerofive.ai.

Download the checklist as a three page PDF and keep it next to the repository, because the moment it is needed is the release, not the reading.

Running the checks

The gate checks become manageable once they translate into concrete operations. Those below can be run by anyone with access to the repository and the infrastructure console.

Bill of materials. Generate it from the package manager in a standard format, file it with the date and the reference commit, and pass it to a scanner for known vulnerabilities. The first pass almost always produces a long list, and the useful work is separating findings on code that actually executes from findings on development dependencies. Pin versions instead of leaving open ranges, because an open range means the product in production changes without anyone releasing it.

Database authorisation. List the tables, verify that row-level security is enabled on each, and read the condition of every policy. Any always-true condition needs rewriting. The check that counts comes afterwards: open a session as an ordinary user and try to read a row belonging to another user. Until you have seen a refusal with your own eyes, the policy is a hypothesis.

Secrets. Search for your key strings inside the production package served to the browser, not inside the source code, because the build process can include variables you do not expect. Repeat the search across repository history, where a key removed three weeks ago remains readable. Keys that turn up must be rotated, and removal from the code does not substitute for rotation.

Exposed surface. List the serverless functions and published endpoints, and for each verify which authentication control applies. The generator tends to create helper endpoints during development and not remove them, and those stay reachable.

Application logs. Read one day of records and look for what should not be there: email addresses, user-submitted content, tokens. Define a retention period and enforce it, because indefinite retention is a difficult position to defend.

Regression. Before a full test suite, write the three tests covering the most sensitive data operations in the application and run them at every release. Three tests that run beat thirty tests that are planned.

The contractual boundary

The accountability question deserves separate treatment, because it produces the most expensive damage and the most awkward conversations.

Whoever places a product on the market under their own brand is the manufacturer for the Cyber Resilience Act and the provider for the AI Act, regardless of who physically produced the code. A generation platform does not enter that chain, and neither does the consultant who built the prototype, unless the contract says otherwise.

When a prototype changes hands the contract should say at least four things. That the artefact is a prototype intended for validation rather than for serving real users. Which checks were performed and which were explicitly excluded, with the list. That moving to production requires further work, defined in scope and price. Who takes ownership from the moment of delivery, and from what date.

This is not legal caution for its own sake. A prototype delivered without those four lines ends up in production in the large majority of cases, because it works and because putting it online costs nothing, and the first incident reopens the discussion about who said what months earlier.

Glossary

Annex III to the AI Act. The list of use cases that qualify a system as high-risk, including recruitment, worker management, access to essential services, biometrics and education.

Client bundle. The code package the user's browser downloads and executes. Everything inside it is readable by anyone, including the keys that should not be there.

Transitive dependency chain. The set of packages your project installs indirectly, because they are required by the packages you chose. In a modern project it easily exceeds a thousand items.

Software bill of materials, or SBOM. A structured list of the software components in a product, including third party and open source dependencies.

Remote data processing. The Cyber Resilience Act category that brings a cloud service into scope when it processes data at a distance, when the product does not work without it, and when it is designed by the same manufacturer as the product.

Manufacturer. The party placing a product on the European market under its own name or brand and assuming commercial responsibility for it. It does not necessarily coincide with whoever wrote the code, nor with the platform that generated it.

Serverless function. A fragment of code executed on managed infrastructure, typically exposed at a public address. Without authentication controls, anyone who knows the address can invoke it.

Substantial modification. A change to a product already on the market sufficient to reopen conformity assessment. The Commission's July 2026 guidance devotes a section to defining its boundaries.

Support period. The span during which the manufacturer commits to handling product vulnerabilities, declared to the user and in principle not shorter than five years.

Row-level security policy. A rule determining which rows of a table a given user may read or write. A permissive policy makes the entire table accessible to anyone able to query the database.

Product with digital elements. The Cyber Resilience Act category covering hardware and software with a direct or indirect connection to devices or networks, together with the associated remote data processing.

Progressive web app. A web application that can be installed on a device and work partly offline. It is the most frequent grey area in scope triage.

Negative test. A check confirming that a forbidden operation is actually refused. It is the test that is almost always missing, because nobody thinks to try what is not supposed to work.

Typosquatting. Publishing packages with names similar to known libraries, so that they get installed by mistake or by automated suggestion.

Vibecoding. Software development carried out by describing the desired outcome in natural language to a generative model, with verification based mainly on observed behaviour rather than on the code produced.

In summary

The speed these tools introduced is real and worth keeping. What disappeared is the moment when somebody decided a thing was ready, and that moment has to be rebuilt by hand, because no platform will hand it back.

The eight gate checks cost half a day the first time and an hour at every subsequent release. An incident involving customer data costs the relationship with those customers, and that cost is not recovered through development speed.

Anyone wanting to understand where their organisation stands on these controls before opening a compliance programme can write to hello@zerofive.ai or book a conversation at calendly.com/fabiolalli/zerofive.

Sources. European Commission, guidance on the application of Regulation (EU) 2024/2847 approved on July 27, 2026, document C(2026) 5252, and draft interpretative guidance of March 3, 2026. Legislative texts cited: Cyber Resilience Act, Regulation (EU) 2024/2847; AI Act, Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744; NIS2, Directive (EU) 2022/2555. European Commission, cybersecurity package of January 20, 2026, proposals COM(2026) 11 and COM(2026) 13.