{"id":"38a370a0-196e-447b-b110-1f67dc57f408","title":"EU AI Act After the Omnibus: What Moved, What Didn't, and a Developer Checklist","content":"# EU AI Act After the Omnibus: What Moved, What Didn't, and a Developer Checklist\n\nMeta Description: The EU delayed high-risk AI Act rules to 2027 and 2028, but Article 50 transparency duties already apply. What changed, what didn't, and a practical checklist for developers.\n\nIf you build software that uses AI and has any European users, one date probably matters more to you than the headline about the delay: 2 August 2026. It has already passed.\n\nIn July 2026 the EU's Digital Omnibus on AI came into force and pushed back the most demanding parts of the AI Act, the rules for high-risk systems. That news travelled as \"the AI Act has been delayed.\" It is true for one category of system and false for a much larger group of ordinary products, because the transparency duties in Article 50, the ones that hit chatbots and generated content, kept their original date.\n\nThis post separates what moved from what did not, and turns the parts that already apply into a developer checklist with a working component. I am reading the Act's text and law-firm analyses, not giving legal advice, so treat this as a map to take to your counsel.\n\n## What Moved\n\nThe Omnibus was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026, according to a Cloud Security Alliance research note that tracked it. Its main effect is on high-risk AI systems:\n\n| Category | Original date | New date |\n| --- | --- | --- |\n| Stand-alone high-risk systems (Annex III) | 2 August 2026 | **2 December 2027** |\n| High-risk systems embedded in products (Annex I) | 2 August 2027 | **2 August 2028** |\n\nAnnex III covers the uses most people think of when they hear high-risk: employment and worker management, education, access to essential services such as credit, and similar areas. If that is your product, you have gained about sixteen months.\n\nTwo other changes are worth knowing:\n\n- **AI literacy got softer.** The obligation moved from ensuring a specific level of literacy to a duty to support the development of AI literacy among staff. It is still an obligation, with a lower bar.\n- **A new prohibition was added.** AI systems that generate non-consensual intimate imagery, or child sexual abuse material, where that output is a reasonably foreseeable and reproducible result, are now banned, with a transitional period to 2 December 2026.\n\n## What Did Not Move\n\nArticle 50 transparency obligations applied on 2 August 2026 as scheduled, and most of them are already live. A law-firm analysis describes these as the requirements the delay left untouched, and puts the fines at up to 15 million euros or 3% of worldwide annual turnover, whichever is higher. The general-purpose AI model obligations have applied since 2 August 2025 and were not changed.\n\nThe one softening is narrow. Providers whose systems were already on the market before 2 August 2026 got until **2 December 2026** to implement the machine-readable marking of synthetic content. That exception covers only that marking duty, not the other Article 50 obligations.\n\nSo today, 29 September 2026, the position for most developers is that Article 50 is in force, and the machine-readable marking deadline for existing systems is about two months away.\n\n## What Article 50 Actually Requires\n\nThe text is short. Here is each paragraph in plain terms, from the Act itself.\n\n**Paragraph 1: tell people they are talking to AI.** Providers must design AI systems that interact directly with people so that those people are informed they are interacting with an AI system. The exception is where it is obvious to a reasonably informed person, from the circumstances and context of use.\n\n**Paragraph 2: mark synthetic output.** Providers of AI systems that generate synthetic audio, image, video or text must make sure outputs are marked in a machine-readable format and detectable as artificially generated or manipulated. There are exceptions for assistive editing functions and for output that does not substantially alter the input data.\n\n**Paragraph 3: emotion recognition and biometric categorisation.** Deployers of such systems must inform the people exposed to them.\n\n**Paragraph 4: deepfakes and public-interest text.** Deployers of deepfakes must disclose that the content is artificially generated or manipulated. Deployers who publish AI-generated text to inform the public on matters of public interest must disclose it, unless the text has been human reviewed or is under editorial control. Artistic, creative and satirical works get a limited version of the duty.\n\n**Paragraph 5: timing and accessibility.** The information must be given clearly and distinguishably, at the latest at the time of the first interaction or exposure, and it must meet accessibility requirements.\n\nThat last paragraph is easy to get wrong. A disclosure buried in a footer, or shown only after the third message, is not a disclosure \"at the latest at the time of the first interaction.\"\n\n## Are You a Provider or a Deployer?\n\nThe obligations attach to roles, and one product can hold both. Broadly, a provider develops an AI system or has it developed and puts it on the market under its own name. A deployer uses an AI system under its own authority.\n\nFor most product teams this means the following, with the caveat that your situation may differ:\n\n- If you build a chatbot or assistant on top of a model API and offer it to your users under your brand, you are likely the **provider** of that chat system, which puts Paragraph 1 on you.\n- If your product generates images, audio, video or text for users, you are likely a **provider** for Paragraph 2 purposes, even though the underlying model belongs to someone else.\n- If you publish AI-generated media or public-interest text yourself, you are a **deployer** for Paragraph 4.\n\nDo not assume the platform you build on has taken care of this. Whether a model vendor or an agent platform adds a disclosure is a question about their product, not a transfer of your obligations. Check what your platform actually does, and cover the gap yourself.\n\n## A Disclosure Component\n\nParagraph 1 and 5 together give you a concrete UI requirement: a clear, accessible notice, before or at the first interaction, that stays discoverable. Here is a small React component that does that. I type-checked it under strict mode against React's types.\n\n```tsx\nimport { useId, useState } from 'react';\n\ninterface AiNoticeProps {\n  assistantName: string;\n  humanHandoffUrl: string;\n  onAcknowledge?: () => void;\n}\n\nexport function AiNotice({ assistantName, humanHandoffUrl, onAcknowledge }: AiNoticeProps) {\n  const headingId = useId();\n  const [acknowledged, setAcknowledged] = useState(false);\n\n  if (acknowledged) {\n    // Stays visible as a compact label so the disclosure is never lost mid-conversation.\n    return (\n      <p role=\"note\" aria-label=\"AI disclosure\">\n        {assistantName} is an AI assistant.\n      </p>\n    );\n  }\n\n  return (\n    <section role=\"region\" aria-labelledby={headingId}>\n      <h2 id={headingId}>You are chatting with an AI assistant</h2>\n      <p>\n        {assistantName} is an automated AI system, not a person. It can make mistakes, so check\n        anything important. You can ask for a human at any time.\n      </p>\n      <a href={humanHandoffUrl}>Talk to a person instead</a>\n      <button\n        type=\"button\"\n        onClick={() => {\n          setAcknowledged(true);\n          onAcknowledge?.();\n        }}\n      >\n        Continue to chat\n      </button>\n    </section>\n  );\n}\n```\n\nMount it before the chat input is enabled, so the notice appears at the first interaction rather than after it. Semantic markup, a labelled region and real links and buttons cover the basic accessibility expectation, but test with a screen reader and keyboard, because the Act's accessibility requirement points to the wider accessibility rules and this component is a starting point, not a certification.\n\nThe compact label matters as much as the first notice. A conversation that continues for an hour should still tell a returning reader what they are talking to.\n\n## Marking Generated Content\n\nParagraph 2 is a provider duty and the technically hardest one. \"Machine-readable and detectable\" is not a single standard, and the Act qualifies it with \"to the extent technically feasible.\" Practical options for the kinds of output you might generate include embedded provenance metadata for images and video, watermarking, and an explicit field in your API responses.\n\nThe last is the cheapest to do today and worth doing regardless. If your API returns generated text or media, add an unambiguous flag for downstream consumers:\n\n```json\n{\n  \"content\": \"…\",\n  \"ai_generated\": true,\n  \"generator\": { \"system\": \"support-assistant\", \"generated_at\": \"2026-09-29T09:14:03Z\" }\n}\n```\n\nThat does not by itself satisfy Paragraph 2 for every medium, and for images and video you should look at established provenance standards and your model vendor's tooling. But it gives every consumer of your API the fact in a machine-readable form, and it makes the later work of adding a standard mark much smaller. If your system was on the market before 2 August 2026, remember your grace period on the marking duty ends on 2 December 2026.\n\n## An AI Inventory You Can Actually Maintain\n\nYou cannot classify what you have not listed. A small register beats a large one nobody updates. One entry per AI feature is enough:\n\n```yaml\n- system: support-assistant\n  owner: platform-team@example.com\n  users_in_eu: true\n  vendor_model: third-party API\n  my_role: provider            # provider | deployer | both\n  interacts_with_people: true  # Article 50(1) applies unless obvious\n  generates_synthetic_content: true   # Article 50(2), marking\n  emotion_or_biometric: false         # Article 50(3)\n  publishes_public_interest_text: false   # Article 50(4)\n  annex_iii_area: none         # employment, education, credit, etc.\n  disclosure_shown_at: first-message\n  marking_deadline: 2026-12-02   # only if on the market before 2026-08-02\n  last_reviewed: 2026-09-29\n```\n\nThe `annex_iii_area` field is the one that decides whether you are in the delayed group. Fill it in honestly. An \"internal tool\" that screens candidates, scores applicants or decides on credit is Annex III territory whatever you call it.\n\n## Checklist\n\n- List every AI feature, with an owner and whether it reaches EU users\n- Decide your role for each: provider, deployer or both\n- Chatbots and assistants: show a clear AI notice at or before the first interaction, keep a persistent label, and offer a human route\n- Generated audio, image, video or text: add machine-readable marking, and confirm your deadline if the system was live before 2 August 2026\n- Deepfakes or public-interest text you publish: add disclosure, and document any human review or editorial control you rely on\n- Check whether anything you ship falls under Annex III, and note your new December 2027 or August 2028 date\n- Remove any capability that could generate non-consensual intimate imagery or CSAM, and check your transitional deadline of 2 December 2026\n- Record what your platform vendors do and do not disclose, instead of assuming\n- Book time with counsel, because roles and exemptions turn on facts this post cannot see\n\nThe delay was real, but it applied to the narrow, heavily regulated end of AI use. For the everyday case, an assistant in a web app or a feature that generates text, the transparency rules are already the law, and the fix is mostly a matter of putting the right words in the right place at the right time.\n\n## Sources\n\n- [EU AI Act Omnibus Agreement: postponed high-risk deadlines and other key changes](https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/), Gibson Dunn\n- [EU AI Act's high-risk deadline: deferred, not cancelled](https://labs.cloudsecurityalliance.org/research/csa-research-note-eu-ai-act-high-risk-deadline-omnibus-20260/), Cloud Security Alliance\n- [Yes, August 2 still matters](https://www.joneswalker.com/en/insights/blogs/ai-law-blog/yes-august-2-still-matters-the-eu-approved-a-high-risk-ai-delay-but-most-trans.html?id=102nbon), Jones Walker\n- [Article 50: transparency obligations for providers and deployers of certain AI systems](https://artificialintelligenceact.eu/article/50/), EU AI Act text\n","excerpt":"The EU delayed high-risk AI Act rules to 2027 and 2028, but Article 50 transparency duties already apply. What changed, what didn't, and a practical checklist for developers.","slug":"eu-ai-act-after-the-omnibus-what-moved-what-didnt-and-a-developer-checklist","authorId":"1","author":{"id":"1","username":"ajith","email":"contact@ajithjoseph.com","name":"Ajith joseph","bio":"Full-stack developer passionate about React, .net core and AI","avatarUrl":"images/users/ajith.jpg","createdAt":"2025-03-02T00:00:00"},"createdAt":"2026-09-29T17:53:15.5","updatedAt":"2026-09-29T17:53:15.5","likesCount":0,"commentsCount":0,"featured":true,"tags":[{"id":1,"name":"react"},{"id":8,"name":"ai"},{"id":161,"name":"regulation"},{"id":162,"name":"eu-ai-act"},{"id":163,"name":"compliance"}],"readingTimeMinutes":9,"difficultyLevel":"intermediate"}