For two years, 2 August 2026 was the date everyone circled. It was supposed to be the day the EU AI Act's hardest rules — the ones governing high-risk systems — finally became real. Then, in the months before it arrived, the Digital Omnibus on AI pushed those rules out to 2027 and 2028, the headlines announced that the AI Act had been delayed, and a great many teams quietly took the date off the calendar.
That was a mistake. The high-risk chapter moved. Almost nothing else did. On 2 August 2026 the transparency obligations in Article 50 became applicable, the enforcement powers behind them switched on, and the fines that back them became available. If your product talks to people, writes text, makes images, or reads faces, you acquired obligations this month that you did not have last month — and you acquired them whether or not you think of yourself as an AI company.
This is our read on what actually changed, who it lands on, and what a serious response looks like. It is the practitioner's version rather than the lawyer's: useful for deciding what to do on Monday, not a substitute for advice on your specific systems.
What moved, and what did not
The Digital Omnibus on AI, given its final green light by the Council on 29 June 2026 (https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/), deferred the Act's high-risk obligations. Standalone systems in the Annex III categories now have until 2 December 2027; AI embedded in products already regulated under Annex I has until 2 August 2028. The reasoning was less about appetite than about readiness: member states were behind on designating national competent authorities, and the harmonised standards that high-risk conformity assessment depends on were not finished.
The same package tightened the Act in one direction while relaxing it in another. It softened the AI literacy duty from a hard requirement into a supportive one, streamlined some registration and post-market monitoring mechanics — and added new prohibited practices to Article 5 covering AI-generated non-consensual intimate imagery and child sexual abuse material, which take effect on 2 December 2026 at the Act's highest penalty tier.
What did not move is the part that now matters most. Article 50's transparency obligations applied from 2 August 2026 as originally written. The Commission's supervision and enforcement powers over general-purpose AI model providers, exercised through the AI Office, came into force on the same day, along with the penalties attached to them. And the enforcement powers of the national competent authorities became exercisable across the Union.
There is a structural point buried in that, and it is the one most teams get wrong. Everyone learned the AI Act as a pyramid — prohibited, high-risk, limited risk, minimal risk — and learned to ask first which tier a system falls into. Article 50 does not care. It is not tied to the risk classification at all. A minimal-risk chatbot and a high-risk screening tool owe the same disclosure if they interact with a person. Waiting to classify your systems before you do anything is a way of missing an obligation that already applies.
Article 50, obligation by obligation
Article 50 (https://artificialintelligenceact.eu/article/50/) contains four substantive duties and one about how you present them. Two fall on providers, two on deployers. Reading it once is worth more than any summary, but here is what each one actually asks for and where the exemptions really sit.
50(1) — Tell people they are talking to a machine
Providers of systems intended to interact directly with people must design them so that the person knows they are interacting with AI, at or before the first interaction. That covers the support chatbot in the corner of your app, the voice agent that answers your phone line, and the assistant that replies to inbound email or tickets.
The exemption is for cases where it is obvious to a reasonably well-informed, observant and circumspect person. Teams lean on this harder than it will hold. If you have invested in making the assistant feel human — a name, a photograph, natural latency, no visible robot cues — you have engineered away the very obviousness you are claiming. The better test is not whether your team knows it is a bot, but whether a first-time user, reading nothing, would.
50(2) — Mark what your system generates
Providers of systems that generate synthetic audio, image, video or text — including general-purpose AI systems — must mark the output in a machine-readable format and make it detectable as artificially generated or manipulated. The Act asks for solutions that are effective, interoperable, robust and reliable, as far as is technically feasible, which is regulatory language for: this is a moving target and we know it.
Two exemptions matter in practice. Systems that perform an assistive editing function — grammar correction is the canonical example — are out, as is output where the AI does not substantially alter the input data or its semantics. The line between assistive editing and substantial manipulation is exactly where the arguments will happen, and it is worth writing down your reasoning now rather than reconstructing it later.
This is also the one obligation with a genuine grace period. Generative systems already on the market before 2 August 2026 have until 2 December 2026 to satisfy the marking and detection requirement. That is four months, not a reprieve, and it applies only to what was already shipping.
50(3) — Warn people before you read their faces or their feelings
Deployers of emotion recognition or biometric categorisation systems must inform the people exposed to them, and process the resulting personal data in line with the GDPR. Note that this sits underneath Article 5, which has already prohibited emotion inference in workplaces and educational settings outright since February 2025. Article 50(3) governs what is left over: the call-centre sentiment scoring, the in-store demographic analytics, the engagement measurement nobody in the room thinks of as biometrics.
50(4) — Label the synthetic, and the ghostwritten
Deployers who publish deepfake content — AI-generated or manipulated image, audio or video resembling real people, objects or events, which would falsely appear authentic — must disclose that it is artificial. The Commission's final Guidelines, adopted on 20 July 2026, are blunt about two points that catch people out. The duty applies without any intent to deceive; and content that looks or sounds like a real person must be labelled even where no actual individual is depicted. Clearly fantastical or physically impossible content falls outside the definition. Artistic, creative, satirical and fictional work gets a softer treatment — disclosure in a manner that does not hamper the display or enjoyment of the work — but content that is exclusively informative or commercial in nature does not get to borrow that softening.
The same paragraph covers AI-generated text published to inform the public on matters of public interest. Here the exemption is real and specific: no disclosure is required where the content has undergone human review or editorial control and a natural or legal person holds editorial responsibility for it. Read that as two conditions, not one. A cursory approval click is not editorial control, and an unnamed process is not a person holding responsibility. If you want to rely on this, make the reviewer and the review visible.
50(5) — And say it so that people can actually see it
The information must be clear and distinguishable, provided at the latest at the first interaction or exposure, and conform to accessibility requirements. This is the quiet one, and it is where otherwise diligent work fails. A disclosure in the terms and conditions is not a disclosure. Neither is a footnote, a low-contrast grey line, or a toast that appears for two seconds and disappears. The obligation is that a person notices, not that you technically said it.
Provider or deployer? The question that decides your duties
Every obligation above is addressed to one role or the other, so getting the role right is the first real piece of work. A provider develops an AI system and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its own authority in the course of a professional activity. The two are not exclusive: most companies are a deployer of several systems and a provider of one.
The trap is that deployer duties do not care who built the model. You can have written no models, trained nothing, and hired no ML engineers, and still owe disclosures under 50(3) and 50(4) because of what you chose to publish or run. And you can become a provider without meaning to — putting someone else's model behind your own brand, or substantially modifying a system, can move the role onto you.
The cases we see most often look like this:
- A support chatbot built on a third-party model but branded as your own assistant — you are likely the provider of that system for 50(1) purposes, not merely its user.
- Marketing imagery generated with a commercial image tool and published on your site — the tool's vendor owes the marking under 50(2); you owe the deepfake disclosure under 50(4) if the image depicts something that would pass as real.
- A help centre or changelog drafted by a model — usually outside 50(4) because it is not a matter of public interest, but the moment your content strategy touches health, finance, safety or elections, that changes.
- Sentiment scoring in a customer service platform, switched on in a settings panel by someone who did not read it as a biometrics decision — a 50(3) obligation acquired by configuration.
- An AI voice on your inbound phone line, procured as a feature of a telephony product — someone owes the 50(1) disclosure, and the contract probably does not say who.
That last point generalises. For most of these obligations, the technical capability sits with a vendor and the legal exposure sits with you. Which means the question you need answered is not only what your systems do, but what your suppliers have committed to do — in writing.
You are in scope even if you are not in Europe
The Act reaches providers who place AI systems on the EU market irrespective of where they are established, deployers located in the Union, and — the clause that surprises people — providers and deployers in third countries where the output produced by the system is used in the Union. A US company with European users, or whose generated content is read in Europe, is inside the perimeter. Being headquartered elsewhere is not a defence; it mostly just means you will hear about the problem later than a European competitor would.
The Guidelines and the Code of Practice
Two instruments sit alongside the Article itself. The Commission adopted the final Guidelines on the implementation of Article 50 on 20 July 2026 — less than two weeks before the obligations applied, which tells you something about how much time anyone had to prepare. They are the closest thing to an authoritative reading of the edge cases, and they are the document to hand your product and content teams (https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai).
The second is the Code of Practice on Transparency of AI-generated Content (https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content). It is voluntary, split into a section for providers marking synthetic content and a section for deployers labelling it, and had drawn roughly 190 signatories by the end of July 2026 — about half of them small and recently founded companies, which is a fair picture of who is actually building in this space. Rather than mandating one technique, it endorses layered transparency: metadata, watermarking and content provenance combined, on the honest premise that no single marking method currently satisfies effectiveness, interoperability, robustness and reliability at once. Signatories commit to having a watermark detection interoperability solution in place by 2 February 2027.
Be clear-eyed about what signing does. It is not a safe harbour, and it covers only parts of the Article — the marking, the labelling, and how disclosures are presented. What it offers is a recognised way to demonstrate that you have met those duties, and the reasonable expectation that a non-signatory will be asked to explain its alternative in more detail. If you do not sign, you are not non-compliant; you have simply chosen to carry the burden of showing your own method works.
What enforcement actually looks like now
Article 50 breaches sit in the tier that carries administrative fines of up to 15 million euro or 3% of worldwide annual turnover, whichever is higher. Enforcement for AI systems runs through national market surveillance authorities; for general-purpose AI models it runs through the Commission via the AI Office, which now holds the power to demand documentation, run evaluations, require mitigation or market restriction, and impose fines. The new Article 5 prohibitions arriving on 2 December 2026 carry the top tier — up to 35 million euro or 7%.
The realistic near-term picture is uneven. Several member states are still standing up the authorities that are supposed to do this work, and the first enforcement will follow complaints and visibility rather than systematic sweeps. But that is a poor reason to relax, because these are the most legible violations in the entire Act. Proving a high-risk conformity failure takes an investigation and a technical file. Proving that a chatbot never said it was a chatbot takes a screenshot, and anyone with a browser can take one. Transparency obligations are enforceable by the public in a way that the rest of the Act is not.
An audit you can run this week
The good news is that satisfying any individual obligation here is cheap. A sentence in a chat window. A label on an image. A line in a notice. Almost none of the cost is in the remediation; nearly all of it is in knowing the complete list of places the remediation has to happen. Which makes this an inventory exercise before it is a legal one. In an afternoon you can get most of the way:
- List every AI system that touches a person — customers, employees, candidates, or the public. Include the ones procured as a feature of something else, the ones a team switched on in a settings panel, and the ones running in marketing rather than engineering.
- For each, write down whether you are the provider, the deployer, or both. Where the answer is uncomfortable, write down why you reached it; that reasoning is the thing you will be asked for.
- Sort each system into the four Article 50 categories: direct interaction, generated content, emotion or biometric analysis, published deepfakes and public-interest text. A system can land in more than one.
- Read the disclosure copy you actually ship, in the place a user actually meets it. Not the copy in the design file, and not the sentence in your terms. Check it appears at or before the first interaction, and that a person would notice it.
- Check your vendors. Which of them mark their output machine-readably today, which have signed the Code of Practice, and which of your contracts say anything at all about it. Where the answer is nothing, that is a supplier question, not a legal one.
- Identify anything generative that went live before 2 August 2026. Those systems are inside the marking grace period, and it closes on 2 December 2026.
- Record the answers somewhere durable, with an owner and a date, next to the rest of your compliance evidence — not in the document you made for this audit and will never open again.
The problem underneath the disclosure problem
Run that audit and you will find the real issue is not that you failed to disclose something. It is that nobody in the company holds a current, complete list of the AI in the product. Every failure mode we see follows from that:
- AI arrives sideways. A team enables an assistant inside a tool you already pay for, and no procurement process or architecture review ever sees it.
- Vendors change the answer without telling you. The model behind a feature is swapped, the marking behaviour changes, and the first you hear of it is a release note you did not read.
- Disclosures drift out of the product. The banner was added at launch, a redesign moved it, and nobody was watching because the obligation lived in a document rather than in a check.
- There is no proof. You did disclose — but you cannot show when it went live, who approved the wording, or that it has been there continuously, which is precisely what an authority or an enterprise buyer will ask for.
- Nobody owns it. Legal assumes product handled it, product assumes legal reviewed it, and the system that needed the label was procured by marketing.
This is the same shape as every other compliance problem: an inventory that drifts away from reality faster than anyone updates the document describing it. The AI Act just made a new kind of inventory legally load-bearing.
Where the AI Act and the GDPR land on the same system
Before going further, it is worth killing a comfortable assumption. Most of Article 50 has nothing to do with personal data. Marking a generated image, telling someone they are talking to a bot, labelling a synthetic voice in an advertisement — none of those are privacy questions, and a privacy program will not find them for you. The temptation right now is to file the AI Act under privacy and assume the existing programme covers it. For three of the four duties, it does not.
One duty is different. Article 50(3) is a privacy obligation wearing an AI Act badge, and the Article says so itself: it requires the disclosure and compliance with the GDPR for the processing involved. Biometric data is special-category data under Article 9. Inferring emotional state from a voice, categorising a face by apparent age or ethnicity, scoring sentiment from a recorded call — each of those is a processing activity that already owed a lawful basis, a place in your Record of Processing Activities, and in most cases an impact assessment, long before the AI Act asked you to announce it.
Which means that if you keep a real data map, the signal is already in it. A field classified as biometric is flagged as special category when the map is built; special-category data is one of the conditions that makes an impact assessment necessary; and the activity holding it is the same activity that now owes an Article 50(3) notice. One classification, three obligations, pointing at one system. A team that already knows where its biometric processing lives has a dramatically shorter Article 50 audit than a team starting from a blank page.
The same overlap runs one layer out, and it matters more next year than this one. The data uses that describe profiling and automated decision-making are the ones that will help decide whether a system falls into the Act's high-risk categories when those obligations arrive in December 2027. The taxonomy also carries a data use for training AI systems, which is how you answer the question every enterprise buyer has started asking — which of our datasets feed a model, and on what basis. Neither of those is an Article 50 duty today. Both are the groundwork for the conversation that comes after Article 50.
But be precise about the limit, because the overclaim here is easy and tempting. A data map will not find your chatbot. Scanning classifies the personal data your systems hold; a service that generates marketing images may hold none at all and will never appear. The AI inventory and the personal-data inventory are different registers built from different signals, and anyone who tells you the second one satisfies the first is selling something. The honest claim is narrower and still worth having: where AI touches people's data, the work you have already done under the GDPR does double duty — and the place the two registers meet is where your first Article 50 findings will come from. If that is the part of the problem you recognise, the mechanics of deriving a map from code rather than from questionnaires are covered in our guide to privacy automation (https://noru.tech/resources/privacy-automation-guide) and in our piece on the Record of Processing Activities (https://noru.tech/resources/gdpr-ropa-record-of-processing-activities-guide).
Treating AI transparency as a control, not a copy change
The durable fix is to stop treating this as a one-off remediation and start treating it the way you already treat access reviews or vendor due diligence — as something with an owner, a control, and evidence that accumulates. That is the shape Noru gives it. The AI in your estate is registered alongside your other assets and vendors, each entry carrying the role you play, the Article 50 categories it triggers, and the person accountable for it, so the list survives the reorganisation that follows the audit.
The EU AI Act is one of the frameworks Noru runs, and it is deliberately harmonised onto the same underlying control library as ISO 27001 and the GDPR. That matters more than it sounds: the governance, risk management, incident response and training controls the Act expects are mostly ones a mature security or privacy program already satisfies. Rather than opening a second program with its own spreadsheet, an existing control is evidenced once and counts everywhere it applies — which is also how ISO 42001 and the NIST AI Risk Management Framework sit alongside it for teams who need a full AI management system rather than a transparency fix.
Around that, the pieces that make the answer hold: your model and tooling suppliers tracked as vendors, so their marking commitments and Code of Practice status are a due-diligence field rather than a rumour; assessments that open when something new and sensitive appears, and end in a documented outcome rather than a conversation; identified gaps linked into the risk register with a treatment and an owner; and evidence captured as a byproduct of the work, so that when a regulator or an enterprise buyer asks how long that disclosure has been live, the answer is a record and not a recollection. When the buyer asks first — and in our experience they usually do — the same posture publishes to a trust page instead of becoming another questionnaire.
What none of this does is make the judgement calls for you. Whether your assistant is obvious enough to fall inside the 50(1) exemption, whether the review your editor performed was substantive enough to carry editorial responsibility, whether a generated image would falsely appear authentic — those are decisions with legal weight, and they belong to people who are accountable for them. The machine's job is to make sure no system is missing from the list when those decisions get made, and to remember what was decided.
Key takeaways
- High-risk obligations were deferred to 2 December 2027 and 2 August 2028. Article 50 transparency, the enforcement powers and the fines were not — they applied from 2 August 2026.
- Article 50 is not tied to the risk pyramid. A minimal-risk system owes the same disclosure as a high-risk one if it interacts with a person or generates content.
- Two of the four duties fall on deployers, so companies that build no AI at all still have obligations — often acquired by procurement or a settings toggle rather than by a decision.
- The Act reaches you if your system's output is used in the Union, whatever your headquarters says.
- The next hard date is 2 December 2026: the marking grace period for generative systems that were already live closes, and the new prohibited practices take effect.
- Article 50(3) is the one duty your privacy program already reaches — emotion and biometric systems are special-category processing, so the record and the assessment you owe under the GDPR point at the same system as the AI Act notice. The other three duties are a different register; do not assume existing privacy work covers them.
- The obligations are individually cheap to satisfy and collectively easy to miss. The binding constraint is a complete, current inventory of the AI touching people — which is a compliance problem, not a copywriting one.
If you want to see what this looks like against your own estate — the AI you are running, the roles you are playing, the controls it maps onto, and the evidence that makes the answer defensible — you can explore it at https://noru.tech.