Status as of 11 August 2026. Article 50 of the EU AI Act (transparency for certain systems that talk to people, generate synthetic content, run emotion recognition or biometric categorisation, or publish deepfakes) applies from 2 August 2026. The European Commission has begun enforcement of those transparency requirements. That is current law for application code, not a future deadline.
The bulk of the Chapter III high-risk-system requirements (Articles 8 through 15: risk management, data governance, technical documentation, record-keeping, instructions to deployers, human oversight, and accuracy, robustness, and cybersecurity) did not hit the old 2 August 2026 date. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It moves application of those high-risk duties to 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III (standalone systems such as employment, essential services, and law-enforcement tools), and to 2 August 2028 for systems classified under Article 6(1) and Annex I (AI embedded in products already regulated elsewhere, such as medical devices or machinery). Plans that still treat August 2026 as the high-risk compliance cliff are planning against a date that has already moved.
This guide is for developers. It does not classify your product as high-risk, run a conformity assessment, or replace legal advice. It names the calendar, the Article 50 duties that now show up as UI copy and metadata in a diff, and how a compliance reading of a pull request catches the common failure mode: a cleanup that deletes the disclosure.
What is live now (Article 50)
Article 50 sets out four main categories of transparency duty, split between providers (the org that builds the system) and deployers (the org that puts it into use), subject to exceptions including specified law-enforcement uses. Each commonly surfaces in running code, not only in paperwork. Art. 50(1): a system a provider designs to interact directly with a person has to make that person aware they are talking to an AI, unless it would be obvious to a reasonably well-informed person anyway; a chat widget, a voice agent, or a support bot needs a disclosure someone actually sees. Art. 50(2): a provider whose system generates synthetic audio, image, video, or text has to mark that output in a machine-readable format detectable as AI-generated. For systems already on the market before 2 August 2026, the machine-readable marking piece under Art. 50(2) is commonly described with a transition to 2 December 2026; confirm the exact transitional text against the Omnibus and Commission guidance for your product lineage, because other Article 50 duties do not share that runway. Art. 50(3): a deployer running emotion recognition or biometric categorisation on people has to tell the people it is running on. Art. 50(4): a deployer publishing a deepfake still has to disclose it is artificially generated or manipulated; for content forming part of an evidently artistic, creative, satirical, fictional, or analogous work, that disclosure obligation narrows to being made in a manner that does not hamper the work's display or enjoyment, rather than being waived. Separately, AI-generated or manipulated text published to inform the public on a matter of public interest needs the same disclosure unless the content has undergone human review or editorial control and a person or organisation holds editorial responsibility for publishing it.
Each of those duties commonly gets implemented as a UI element, a metadata write, or a copy string, which makes each exactly the kind of thing a refactor can remove without anyone flagging it as a compliance change. As of August 2026 that removal is not "early"; it is a live transparency gap.
Worked example: a UI cleanup removes the disclosure
Say a support chatbot shipped with a persistent line under its first message: "You're chatting with an AI assistant." A later pull request redesigns the widget for a cleaner first-open state and, trimming what a designer flagged as onboarding clutter, drops that line along with three other pieces of intro copy. The redesign is not wrong on its own terms: the widget reads cleaner and the other three lines were genuinely filler. But the Art. 50(1) disclosure was implemented as one of those lines, so removing it removed the disclosure, not just the clutter. Nothing about the diff looks unusual: a copy trim in a chat component is not the kind of thing a bug scanner, a QA pass, or a design review is built to catch.
This is what a compliance check reads a diff for: when a change removes or weakens an element tied to a control a team is tracking, cite Art. 50(1) on the pull request itself, rather than finding out from a complaint or an enforcement contact after the fact.
High-risk is deferred, not cancelled
Moving standalone Annex III high-risk requirements to December 2027 does not make the underlying question, whether a system counts as high-risk under Annex III, any easier to answer later than now. The controls behind Articles 8 through 15 are the same shape of "moves in a diff" problem the framework hub already tracks: a risk mitigation weakened, a dataset governance check dropped, a human override deleted as dead code. Building those habits now is cheaper than discovering gaps under a 2027 clock.
Two other date clusters are unaffected by this omnibus and already apply: the prohibited-practices and AI-literacy obligations from 2 February 2025, and the GPAI model rules and governance obligations from 2 August 2025. One more change worth knowing about from the same package: a new prohibition covering providers of systems intended to generate or manipulate non-consensual intimate material or child sexual abuse material, or systems for which that output is a reasonably foreseeable and reproducible outcome without significant technical modification and without reasonable and adequate safeguards against it, as well as deployers who use a system for that purpose, added to the Act's list of prohibited practices and applying from 2 December 2026.
Where heygrc fits, and the honesty boundary
heygrc is built to read each pull request against the frameworks you selected, including the EU AI Act when you have it enabled, and to name the article a change appears to touch (for example Art. 50(1) on a removed chat disclosure). The finding is a review comment with the clause attached so the author and reviewer can decide with full information. It does not certify AI Act compliance, classify high-risk status, run a conformity assessment, file supervisory notifications, or replace counsel. A green heygrc review is not a Commission sign-off; it is an earlier, clause-grounded signal that a change moved something those programmes care about.
If your team already uses a bug or quality reviewer on the same pull request, keep it. Those tools ask whether the code is correct and safe. Article 50 questions are about whether a person still knows they are talking to an AI, or whether synthetic content is still marked. The cleanup above can be clean, typed, and well-tested and still leave Art. 50(1) unfinished. Run both layers; neither replaces the other.