# The EU AI Act's August 2 Just Vanished: A Full Anatomy of the Digital Omnibus Deferral and a 16-Month Readiness Plan > Source: https://sukruyusufkaya.com/en/blog/eu-ai-act-yuksek-risk-erteleme-dijital-omnibus-2026 > Updated: 2026-06-27T17:02:10.910Z > Type: blog > Category: yapay-zeka **TLDR:** The Digital Omnibus defers high-risk AI obligations from 2 August 2026 to 2 December 2027. Full timeline, what Annex III means, Article 99 penalties, the KVKK overlap, and a concrete 16-month readiness plan from the field. There was a date many of us had circled in red: 2 August 2026 — the day the EU AI Act's core obligations for high-risk AI systems would take effect. Last week, that date quietly moved. And let me be honest: I spoke with a few teams who greeted the news with "phew, we're off the hook," and my heart sank a little. Because this delay is not what it looks like — and organizations that misread it will face the same panic at the end of 2027, only more expensively. In this piece we'll talk it through end to end: a one-minute refresher on the Act's risk pyramid, the parts already in force, exactly what the Digital Omnibus changed, what "high-risk" means in practice for Turkish companies, why the penalties are still on the table, and how to use these 16 months quarter by quarter. My goal isn't a news summary; it's a readiness plan you can actually take to production. ## The EU AI Act in one minute: the risk pyramid The Act regulates AI by risk level, in four tiers. At the top sit unacceptable-risk practices — social scoring, exploitative manipulation, real-time public biometric identification for law enforcement — which are banned. Just below are high-risk systems: not banned, but carrying the heaviest duties (risk management, data governance, logging, human oversight, technical documentation, conformity assessment). Then limited-risk (transparency) systems where users must know they're dealing with AI, and finally minimal-risk uses, left free. The date at the center of all this — 2 August 2026 — concerned that high-risk tier: not spam filters or recommendation engines, but systems that directly affect people's lives, like credit scoring, hiring, critical infrastructure, and access to public services. ## First, correct the misunderstanding: not "everything was delayed" This is the confusion I meet most often. What was deferred is only the start date of the obligations for high-risk systems. Much of the Act is already in force and was not delayed: - Since **2 February 2025**, the prohibited practices and the AI literacy duty have applied. Social scoring or manipulative systems are already illegal today and sit in the highest penalty tier. - Since **2 August 2025**, obligations for general-purpose AI (GPAI) models and governance rules apply. GPAI providers must prepare technical documentation, inform downstream providers, implement copyright-compliance policies, and publish training-data summaries. Dozens of firms — Amazon, Google, Microsoft, OpenAI, Anthropic — signed the Code of Practice early for a "presumption of conformity." The reason I keep stressing this: if your company uses generative AI or offers a model/service into the EU, the AI Act has already begun for you. The only thing deferred is the clock on the heaviest high-risk package. ## What exactly did the Digital Omnibus change? A provisional political agreement was reached in May 2026 under the package known as the "Digital Omnibus," confirmed by Council representatives on 13 May. Its essence: simplify implementation and give the market time to prepare. The headline changes: - Stand-alone high-risk systems under Annex III move from 2 August 2026 to **2 December 2027** — roughly 16 months. - AI embedded in regulated products (medical devices, machinery, vehicles under Annex I) is pushed to **2 August 2028**. - Transparency and watermarking obligations (Article 50) are deferred only to **2 December 2026** — the genuinely near date. - New prohibitions were added to Article 5: tools generating non-consensual intimate imagery ("nudifiers") and child sexual abuse material are explicitly banned. - The EU database registration duty is reinstated for providers who consider their systems exempt from high-risk classification. So the obligations didn't disappear. They were spread across the calendar. Those are very different things: one says "you don't have to," the other says "later, but you must." The Omnibus is the second. These changes only take legal effect once the Omnibus is formally adopted and published in the EU Official Journal. Publication is expected before 2 August 2026 — but we all know the difference between "expected" and "confirmed." A team that builds its plan entirely on this deferral could face the original date if publication slips. My advice: read the deferral not as "we can relax," but as "we run a dual plan until publication is confirmed." ## What "high-risk" actually means: Annex III and Turkish sector examples Neither the delay nor compliance matters unless it applies to you. So the critical question is: are your systems high-risk? Annex III lists the high-risk use cases. The ones Turkish organizations hit most often: **Credit scoring and insurance pricing.** An AI system assessing a loan application or setting an insurance premium falls squarely under Annex III. In Turkey these areas are already heavily regulated by BDDK, SEDDK and KVKK; the AI Act adds an explainability and human-oversight layer on top. **Hiring and HR.** Systems that screen CVs, rank candidates, or evaluate performance are high-risk. "It only does pre-screening" doesn't take a system out of scope; any decision-support layer that can discriminate against people belongs here. **Critical infrastructure, education, access to public services.** AI used in grid management, exams/assessment, or allocation of social benefits and public services is also high-risk. The trap is the comfort of "we just built a POC." Annex III looks at intended purpose, not maturity. Even a demo, once in production affecting people's credit, jobs or service access, brings the high-risk obligations with it. ## The "we're in Turkey, it doesn't bind us" fallacy: territorial scope A sentence I hear often in the field: "We're not in the EU, this isn't our problem." If only it were that simple. The AI Act's scope knows no borders; if a system's output is used inside the EU, the obligations apply even if the provider or deployer sits in Turkey. So a Turkish software firm offering SaaS to EU customers, a consultancy building a model for a European bank, or a manufacturer selling products into the EU market — all are in scope. This is the same logic of GDPR's territorial reach that once surprised Turkish companies; better not to learn the same lesson twice. If any end of your business model touches the EU, the AI Act is not "a foreign regulation" but a framework you must follow directly. ## Provider or deployer? Your role defines your obligations AI Act obligations vary with your relationship to the system, so the first thing to clarify is your role. The provider develops and places the system on the market under its own name and carries the heaviest load (Article 16): risk management, technical documentation, conformity assessment, record-keeping. The deployer uses the system in its own processes and, under Article 26, carries human oversight, fitness for intended purpose, input-data appropriateness and logging duties. Most Turkish organizations are deployers — using a foreign model (OpenAI, Anthropic, Google) or a vendor solution in their own processes — and "we just use it" doesn't take you out of scope. Moreover, if you substantially modify a model, offer it under your own brand, or change its intended purpose, you may legally become a provider and move into the heavier tier. I've seen many companies find themselves a provider without realizing it. So for each system in your inventory, settle one question: am I the provider, the deployer, or both? ## Seven concrete obligations of a high-risk system Let's make it concrete. For a system stamped high-risk, there are seven things to build in practice. First, a risk-management system: a documented, continuously updated process across the lifecycle. Second, data governance: the quality, representativeness and bias control of training, validation and test data. Third, technical documentation: an audit-ready file showing how the system works. Fourth, automatic logging: events kept traceable and reviewable after the fact. Fifth, transparency to deployers: clear communication of usage instructions, limits and conditions of appropriate use. Sixth, human oversight: a person able to meaningfully review and, if needed, override the decision. Seventh, accuracy, robustness and cybersecurity: consistent and attack-resilient operation under expected conditions. These seven are the backbone of the work you must finish by 2027. None is built in a week; each requires process, ownership and testing. That is precisely the real value of the time the deferral bought you: to build these seven layers right, without rushing. Let's unpack the three teams stumble on most. ## What a risk-management system actually looks like The heart of the high-risk obligations is the risk-management system, yet most teams mistake it for a one-off document. It is a living process. First you identify the system's reasonably foreseeable risks: discrimination, wrongful rejection, security holes, misuse. Then you design and apply measures to mitigate each. Then you assess the residual risk and decide whether it's acceptable. The last part is the critical one: monitoring continues after the system goes live, and new risks surfacing in the real world feed back into the loop. A risk assessment written once and shelved is the document that decays fastest in an audit. When an auditor asks "when, by whom, and against what data was this risk last re-assessed?", you need a living record to show. ## Data governance and bias: the obligation teams stumble on most The duty most often tripped over in the field is data governance. A high-risk system's training, validation and test data must be fit for purpose, sufficiently representative and as error-free as possible. The real issue here is bias: discrimination hidden in historical data seeps silently into the model and shows up in a credit or hiring decision. So you must deliberately examine the distributions in your dataset, the under-represented groups, and possible proxy variables — for instance a postal code becoming a proxy for income or ethnicity. In the Turkish context this overlaps directly with KVKK's sensitivity around special-category data. Saying "we don't discriminate" about a system whose bias you never measured is not a valid audit defense; without measurement you simply don't know. ## Human oversight is not "clicking approve" Human oversight is the most misapplied obligation. Putting an "Approve" button on a screen and auto-passing every output is theater, not oversight. The AI Act wants meaningful oversight: the overseer must have the competence to understand the system, the time to question the decision, and the real authority to override it. The true enemy here is automation bias — people tend to over-trust the machine and approve blindly. A well-designed oversight layer surfaces high-risk cases, asks for a rationale, and measures whether the overseer actually intervened. If your approval rate is 99.9%, you're probably running a rubber stamp, not oversight. ## Supply chain and contracts: compliance isn't built alone AI Act compliance rarely ends within one organization's walls; it's a supply-chain matter. Different parties may provide the model, the data, the integration and the use. So compliance must be written into contracts: which documents will your vendor provide, which usage limits will they guarantee, how is liability shared if a non-conformity arises? If these clauses don't enter the contract today, you'll have no negotiating power when the audit arrives in 2027. That's the quietest advantage of organizations that move early: they make compliance part of procurement and contracting — not a patch bolted on afterward. ## A delay is not "no risk": the Article 99 penalty table The most expensive part of mistaking the delay for a break is forgetting the penalties are still on the table. The Act's enforcement regime (Article 99) has three tiers, and it's deterrent even for teams used to KVKK or GDPR. Note: the top tier (35M€/7%) is for prohibited practices, and those bans have been in force since February 2025 — nothing to do with the deferral. Even if the high-risk date slid to 2027, if you run a manipulative or prohibited system today, the risk is real today. ## The thresholds that didn't move: the truly near dates Because the headline is "delayed to 2027," three things get missed — and they concern 2026 itself. First, the transparency and content-labeling duty on 2 December 2026. If you produce content with generative AI (text, image, audio, video), it must be machine-readably marked and users must know they're interacting with AI. This is far nearer than the high-risk package — and an area most organizations are far less prepared for. Second, the prohibitions: in force since February 2025, not deferred. Third, the GPAI obligations: in force since August 2025. If you train or fine-tune your own model, the documentation and copyright duties already bind you. ## A shared backbone with KVKK/GDPR: don't do the work twice Perhaps the most practical insight for Turkish organizations: the EU AI Act and KVKK are not separate worlds. The two regimes demand largely the same engineering disciplines; one governance layer serves both. Data minimization and purpose limitation appear in both. Logging and traceability: KVKK wants an audit trail, the AI Act wants automatic logging — same infrastructure. Access control: role-based access and data boundaries in both. Explainability and data-subject rights: KVKK's right to contest automated decisions, the AI Act's human oversight and explainability. KVKK's data protection impact assessment (DPIA) and the AI Act's fundamental-rights impact assessment (FRIA) largely overlap; designing them as one process cuts cost and improves consistency. My practical advice: don't build governance as two silos, "one for the EU, one for Turkey." Produce a single control catalog, map each control to both KVKK and AI Act articles, and implement once. ## A bank example: how 16 months should go in credit scoring A concrete scenario teaches more than abstract articles. Say a Turkish bank runs a model that pre-assesses loan applications — squarely Annex III, high-risk. In the first quarter, the system must be inventoried, tagged "high-risk," and the bank's role clarified — provider or deployer (was the model built in-house or bought from a vendor?). In the second quarter, bias analysis of the training data and data governance are documented; crucially, this is merged into the same file as the BDDK and KVKK requirements — not three folders for three audits. In the third quarter, a human-in-the-loop flow and audit trail are built so every rejection can be meaningfully reviewed by a person, and an explainable rationale is produced for the customer. In the final quarter, technical documentation and the conformity assessment are completed, and gaps are closed with an internal audit rehearsal. This plan uses the deferral instead of hiding behind it. The result: by the end of 2027 the bank has not just a "compliant" system but one that makes more consistent decisions, is audit-ready, and preserves customer trust. Compliance is often framed as a cost; designed right, it's actually a quality investment. ## If you use a ready-made model: GPAI and your downstream responsibility Most organizations don't train their own foundation model from scratch; they use a ready GPAI model like GPT, Claude or Gemini. This doesn't free you from responsibility, but it distributes it. The GPAI provider has carried its own duties — technical documentation, copyright compliance, training-data summary — since August 2025. You, deploying that model in a high-risk use, take on the deployer duties: fitness for intended purpose, human oversight, input-data appropriateness and logging. In practice that's three steps: contractually pin down your vendor's conformity documents and usage limits; test and document the model's behavior in your context; and build the oversight and audit layer on your side. "Responsibility lies with the vendor" won't protect you in an audit — because you are the one using that model in a high-risk decision. ## Who owns governance? Give responsibility to a single owner The quietest cause of failure I see is that no one owns the responsibility. Make AI governance "everyone's job" and in practice it becomes no one's. Name a clear AI governance owner; form a small but empowered committee from legal, data, security and the business; keep the inventory, risk classification and control catalog under this structure. Without clear decision rights and accountability, even the best technical preparation falls apart in the field. I judge an organization's AI maturity less by the model it uses than by whether this ownership structure exists. ## How to use the 16 months: a quarter-by-quarter roadmap Working with Turkish and EMEA teams, I keep watching the same story: a demo that works beautifully, a governance task that sits on the shelf for months, then a panic in the final three. When regulation is delayed, the pattern only worsens. Yet what you hold is a gift for the opposite — time to build it right, calmly. Here's the order I'd follow. ## Five mistakes I see in the field First, mistaking the delay for a stop signal. When the date moves, budget and attention drift elsewhere; yet all you gained is time, not a reprieve. Second, skipping the inventory. Any compliance spend made without knowing which systems are high-risk is either incomplete or wasted. Third, missing the transparency date. While everyone fixates on 2027, 2 December 2026 quietly approaches. Fourth, running KVKK and the AI Act as separate projects — doing the same work twice at double the cost. Fifth, the "we just did a POC" comfort. Scope looks at intended purpose, not maturity; if it affects people in production, it's high-risk. ## Where to start: a 30/60/90-day first move Let's drop the theory and give a concrete start. First 30 days: produce an AI inventory and tag each system to a risk tier; put the "high-risk candidates" on a separate list. First 60 days: build a single governance catalog mapping KVKK and AI Act controls; run a gap analysis on your two or three highest-risk systems. First 90 days: test a transparency/labeling prototype on one generative use case and add human approval + an audit trail to a high-risk decision flow. These three steps move you toward both KVKK and the AI Act today, independent of the deferral. The Digital Omnibus is part of the EU's "let's simplify implementation and give the market some air" approach — good intentions. But it doesn't erase obligations; it spreads them over time. Organizations that use these 16 months to make their systems genuinely operable, auditable and KVKK-compliant will be ready by the end of 2027; those who trust the date and wait will meet the same panic, just later and more expensively. You decide today which group you want to be in — and you have a full 16 months to decide, with not a single quarter to waste. ## A quick self-assessment: how many can you answer "yes"? Set the whole framework aside, turn to your organization, and ask a few honest questions. Do you have a complete inventory of your AI systems, each assigned to a risk tier? For each high-risk candidate, have you settled whether you're the provider or the deployer? Do your generative outputs carry a notice that clearly tells users they're talking to an AI? For your high-risk decisions, is there an oversight point where a human can genuinely review and override — or just an "Approve" button? Do your contracts with the providers of the models you use contain compliance and liability clauses? Do you manage your KVKK and AI Act controls in a single catalog, or are two teams working in two separate spreadsheets? If you answered "not yet" to most of these, you're not alone; most organizations I see in the field are exactly here today. What matters is reading this list not as an accusation but as a starting map. Each "no" points to a concrete gap to close over the next 16 months — and addressing each one today is both cheaper and healthier than wrestling with panic in 2027. And don't run this self-assessment once and shelve it; repeat it each quarter and measure the "no"s turning into "yes"es. Compliance isn't a single delivery; it's a curve you track. ## Compliance is not a burden but a positioning Finally, I'd urge you to flip your perspective on compliance. Most organizations see the AI Act as a "to-do list" or a weight on the legal team's back. Yet the deferral gives us the chance to rethink exactly that. An organization that builds governance right isn't merely avoiding fines; it ends up with a system that makes more consistent decisions, can account to its customers, and is audit-ready at any moment. In regulated sectors — banking, insurance, healthcare, the public sector — that translates directly into trust, and therefore into commercial advantage. Your customer trusts you more when they know a demonstrable discipline stands behind the decision; your auditor's job — and yours — gets easier when the files are ready; your team moves faster and with less fear when it knows what it's doing and why. Organizations that use the 16 months this way will enter 2027 not just "compliant" but "ahead." I've seen it many times in the field: those who treat regulation as an obstacle to be cleared at the last minute are tired and defensive; those who internalize it as a design principle are calm and confident. What decides which side you're on isn't the legislation itself — it's the first step you take today.