No, the AI ​​Act has not been postponed (for your site)

The misconception going around

In late 2025 the European Commission proposed the so-called Digital Omnibus on AI, a simplification package that reached political agreement on 7 May 2026. The news bounced around everywhere under the same headline: "The AI Act has been delayed".

That's only partly true, and the part where it's true probably doesn't concern you.

The Omnibus did indeed push back the obligations on high-risk artificial intelligence systems — those used, for example, in critical infrastructure, hiring, or medical devices. Those deadlines have slipped to December 2027 and August 2028.

But the transparency obligations — Article 50, the one that says "if a user is talking to a machine, they must know it" — were left exactly where they were: they apply from 2 August 2026. A conversational chatbot, a virtual assistant, a configurator that answers in natural language all fall here, not under high risk. For them, nothing has changed.

(Update note: the Omnibus is still undergoing formal adoption and becomes definitive only upon publication in the Official Journal of the EU. The dates for high-risk systems should therefore be treated as provisional; the Article 50 date, by contrast, is already in the text in force.)

Before we even get to AI, though, it's worth setting straight an older and more widespread confusion: the one among the rules that govern a website. Because "being compliant" in 2026 means complying not with one set of rules, but three.

Three distinct sets of rules, often mistaken for one

When a client says "I've put up the cookie banner, I'm all set," they're usually conflating three regulatory regimes that have different logics, authorities, and penalties. Keeping them separate is half the work.

1. The GDPR — the protection of personal data. It's the regulation that governs any processing of data relating to a person: a name in a form, an email in a newsletter, an IP address, an e-commerce order. It imposes legal bases, clear notices, data subject rights (access, erasure, portability), and contracts with those who process data on your behalf. Penalties reach up to 20 million euros or 4% of annual worldwide turnover.

2. The ePrivacy Directive and the cookie rules — tracking. It's a layer separate from the GDPR, often confused with it. It concerns the reading and writing of information on the user's device: profiling cookies, third-party pixels, analytics scripts. In Italy the operational reference is the Garante's 2021 cookie guidelines, which require, among other things, genuine prior blocking of non-technical scripts before the user's choice, and forbid treating scrolling as consent.

3. The AI Act — transparency about artificial intelligence systems. It's the most recent layer and it adds to the first two, it doesn't replace them. It doesn't ask "what data do you process," but "does the user know they're interacting with an AI, or that a piece of content was generated by a machine?".

The practical point: you can have an impeccable cookie banner and still be non-compliant on the GDPR (for example, with a form that has no notice) or on the AI Act (with a chatbot that doesn't declare itself). These are separate checks, and all three have to be passed.

What you actually need, based on what you do

Not all websites carry the same obligations. Complexity grows with functionality. In practice, almost every project sits at one of three levels.

Basic profile — the brochure site. It presents the company, perhaps with Google Analytics and a contact form. Here you need: a cookie banner with effective prior blocking, privacy and cookie policies that are up to date and aligned with the tools actually in use, Google Consent Mode v2 configured, and — an often-overlooked detail — local hosting of fonts, so as not to send every visitor's IP address to Google's servers on every page load.

Marketing profile — leads and newsletters. On top of the basic level comes the management of the contacts collected: marketing consents kept separate from service ones, double opt-in on sign-ups (a confirmation email before activating the mailing), data processing agreements (DPAs) with email marketing providers, and prior blocking of advertising pixels such as Meta's.

Full profile — e-commerce and AI. Here everything else comes in: binding terms and conditions, DPAs with payment gateways, handling data subject rights at higher volumes, and — if there's a conversational assistant or a generative feature — the AI Act disclosure obligations we'll discuss shortly.

The value of this classification is that it lets you size the intervention: a craftsman with a brochure site doesn't need the apparatus of an e-commerce, and proposing it to them would be dishonest as well as pointless.

The AI chapter: what changes from 2 August 2026

Article 50 of the AI Act doesn't look at how "risky" a system is, but at a different question: is a person exposed to AI without knowing it? Where the answer is yes, a transparency obligation kicks in. The relevant situations are essentially four.

• Systems that interact directly with people — chatbots, virtual assistants. The user must be clearly informed that they're conversing with a machine, unless it's obvious from the context. This is the situation that affects most projects, and its deadline is 2 August 2026, with no postponement.
• Generative systems that produce synthetic text, audio, images, or video: their outputs must be marked in a machine-readable format as "AI-generated".
• Emotion recognition or biometric categorization: the people exposed must be informed.
• Deepfakes and artificially generated or manipulated audio/video/image content: it must be declared that the content is not authentic.

A useful distinction to keep in mind: the obligation to declare the interaction with a chatbot starts on 2 August 2026 and was not touched by the Omnibus. The technical obligation to mark generated content (so-called watermarking, Art. 50(2)) did get a little breathing room, on the other hand: for systems already on the market before that date, it slips to 2 December 2026.

From that same date, the AI Office and the national authorities also gain the power to impose penalties: for breaches of provider and deployer obligations, including Art. 50, the figures reach fines of up to 15 million euros or 3% of annual worldwide turnover. The obligation and the penalty, in other words, arrive together.

For those who build vertical assistants — a digital sommelier, a conversational harbor pilot, a product configurator — the implication is concrete: the disclosure must be designed into the interface, not stuck on afterward. And the quality of the answers isn't an aesthetic detail but a matter of liability: a model that "makes up" information exposes the owner. It's the reason why, in high-precision domains, we prefer a structured, verifiable knowledge base, integrated directly into the system, over solutions that leave the model free to improvise.

The mistakes we see most often

Compliance rarely fails through big omissions. It fails in the details, and that's where an automated check or an inspection finds its foothold.

• Google fonts loaded remotely. Every page that calls external Google Fonts transmits the visitor's IP to a US server. It has already led to penalties in Europe. It's solved by hosting the fonts locally — a quick technical fix, often forgotten.
• Banners without prior blocking. Many banners look compliant but let analytics scripts and pixels fire before the user has even clicked. It's exactly what the Garante's guidelines forbid.
• Unrecorded consents. Collecting consent isn't enough: in the event of a dispute you have to prove when and how it was given. Without a permanent, automated log, the proof isn't there.
• Consent Mode absent or in basic mode. Without Google Consent Mode v2 configured correctly, refusing cookies doesn't just degrade compliance: it zeroes out measurement data and throws campaigns into disarray. The advanced mode makes it possible to recover a significant part of the data through Google's statistical modeling — not a magic number, but a real difference compared to total darkness.

How to tackle it, with honesty about the roles

Bringing a project into compliance isn't "installing a banner," but it isn't a job for lawyers alone either. In practice the work splits into two distinct trades, and it's best to keep them separate in the quote as well.

There's a technical and systems part: the audit of the cookies and third parties actually active, the prior blocking of scripts, the switch to local fonts, the configuration of Consent Mode, input validation and the isolation of knowledge bases for web apps and AI systems, the insertion of the disclosure interfaces. This is the ground on which a development studio intervenes directly.

And there's a legal and documentary part: the privacy and cookie policy texts, the consent logs, the contracts with providers. Here the most solid approach is to rely on specialized, certified platforms that keep the texts dynamically updated as the regulations change — work that no technical studio should claim to do by hand.

A necessary clarification: this article offers guidance, not legal advice. Every situation has its own specifics, and the legal bases must be verified case by case. What we can guarantee is the technical architecture that makes compliance possible by design — the rest is built together, with the right professionals in the right place.

If you have a website, a web app, or an AI assistant and you're not sure which of the three profiles concerns you, a preliminary audit is the fastest way to find out: it starts from what actually runs on your domain, not from a generic template.