Compliance by Design: Why Compliance in Vibe Coding Is a Process, Not a Final Check

Compliance Is Not a Sticker You Slap On at the End

This is the fourth article in the From Vibe Coding to Production series. We are at Level 6 of the pyramid, and it is the one that differs most from the others: it is not a technical control, it is a process.

The typical vibe coding mistake is treating compliance as the last step, a checklist to tick before launch: cookies, privacy, terms and conditions, done. It does not work like that. Compliance is not something you add at the end: it is a choice you make, knowingly or not, from the very first line.

Architecture Is Already a Compliance Choice

Every technical decision made in the previous levels, where you keep data, how you handle PII, which external services you call, is also a compliance decision.

You cannot separate "how the app is built" from "whether it is compliant". If an external agent can forward personal data to a data center outside the European Union, that is not a technical detail: it is a regulatory problem born from an architecture choice. That is why compliance must be treated like security or scalability: a design constraint, not a final touch-up.

AI Act: What You Must Guarantee if You Build AI

The AI Act (Regulation EU 2024/1689) has a guiding principle: artificial intelligence must be trustworthy and human-centric. In practice that means protecting people's fundamental rights, with obligations that grow with the risk level of the system and that fall on whoever builds it.

Translated for a founder: before going to production you need to know which risk tier your application falls into and what you must guarantee, from transparency toward the user to human oversight, to proper data handling. The point is not to memorize a regulation: it is to know it exists and ask the right questions early, not late.

Compliance by Design or Late Compliance?

The best practice is simple to state and hard to apply: compliance by design and by default, with a risk assessment before delivery. It means bringing "people's rights and freedoms" into the analysis and design phase, not at go live.

The alternative is late compliance, fixing everything after the product is already online. And the bill is steep:

• partial redesign of the application;
• additional, unplanned delivery;
• impacted project economics;
• in the worst cases, a product positioning problem, because some features can no longer be offered.

It is the same message that runs through this whole series: discovering a constraint at the start costs a consultation, discovering it at the end costs a rewrite.

What You Really Risk: the AI Act Fines

This is not theory. The AI Act fines are heavy and scale with the severity of the violation:

• Very serious violations: up to 35 million euros or, for companies, up to 7% of total worldwide annual turnover of the previous year.
• Medium violations: up to 15 million euros or up to 3% of worldwide annual turnover.
• Minor violations: warnings and non-monetary measures.

For an SME or a startup, even the middle tier can be fatal. And it is exactly the kind of risk a non-technical founder does not see while building in vibe coding, focused on making the product work.

Law 132/2025: the Rules for Those Building for Italy

If you build for the Italian market, there is one more layer. Italy's Law 132/2025 states that the use of artificial intelligence systems must guarantee lawful, fair and transparent processing of personal data, compatible with the purposes for which it was collected and compliant with European Union law on data and privacy.

It then adds special principles for sensitive areas: healthcare, employment, intellectual professions, public administration, justice, copyright. If your application touches one of these sectors, the rules become stricter, and they must be known before you write the business logic. We covered the topic in the article on the AI Act for Italian companies.

The Team Changes: Enter LegalTech

Here is the real paradigm shift. To build a compliant AI app, the classic team is not enough, project manager, business analyst and developer. You need an AI Engineer and, above all, a LegalTech professional.

Bringing a LegalTech lawyer into the project is not a cost: it is what lets you make the right choices early, instead of chasing compliance later. There is also an intellectual property angle: without a well-structured license agreement from the start, a client can claim part of the code, especially on customizations. You defend the ownership of your product with paperwork, not just with code. We discussed this in the piece on the legal tech analyst.

Trust Is Designed and Verified

The point is one: trust in an AI system is designed at the architecture level and verified at the legal level. The two are not separate. An app can be technically perfect and legally unusable, or compliant on paper but fragile with data.

Taking a product from vibe coding to production means holding these two planes together from the start. It is the last control before the top of the pyramid: in the next article we reach infrastructure and maintenance.

Get a compliance check before going to production, not after.