The correction: most timelines you will find are out of date
If you searched for an EU AI Act timeline at any point this year, there is a good chance you read that the full high-risk regime starts on 2 August 2026. Turkish compliance pages repeat it almost word for word, and several English ones have not been touched since 2024. It is no longer true. The Digital Omnibus on AI changed the applicability dates for high-risk systems before that deadline arrived. If your programme plan, your board deck or your supplier questionnaire still carries the old date, the correction is worth making now, before a customer makes it for you in the middle of a procurement review.
The instrument is Regulation (EU) 2026/1744 of 8 July 2026, which amends Regulation (EU) 2024/1689 along with Regulation (EU) 2018/1139 and Regulation (EU) 2023/1230. It was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. The text sits at eur-lex.europa.eu/eli/reg/2026/1744/oj, and the European Commission maintains its own regulatory-framework page at digital-strategy.ec.europa.eu, which is where we point a legal team that asks for something citable. Those two sources settle almost every argument about dates. Neither is a blog post, neither is behind a paywall, and both are maintained by the bodies that own the text rather than by an aggregator.
An outdated date can distort a product roadmap. Use the Commission timeline to distinguish obligations already applicable from the deferred high-risk rules, then classify each system with counsel before setting milestones. The postponement does not make every AI use case high-risk and does not suspend obligations that already apply.
The timeline that actually binds
Start with the base regulation. The AI Act is Regulation (EU) 2024/1689. It entered into force on 1 August 2024 and became applicable on 2 August 2026, with exceptions, and two of those exceptions are already behind us. The prohibited practices in Article 5 and the AI-literacy obligations have applied since 2 February 2025, which means anything on the banned list has been unlawful in the Union for more than eighteen months. Obligations on providers of general-purpose AI models, in Articles 51 to 56, have applied since 2 August 2025. If your compliance narrative begins in 2026, it begins a year and a half late.
Then the omnibus. Annex III standalone high-risk systems, the category covering biometrics, critical infrastructure, education, employment, migration, asylum and border control, were deferred from 2 August 2026 and now apply from 2 December 2027. Annex I product-embedded high-risk systems, the ones built into regulated products such as lifts, toys and machinery, apply from 2 August 2028. Those are the two headline moves and the reason the old timelines are wrong. Note the shape of the change carefully: it is a deferral of applicability, not a repeal, not a narrowing of the categories, and not a change to what a high-risk system is. The definitions you would have been assessed against still stand.
There is a nearer date that gets far less attention. Article 50(2) gives systems already on the market a grace period for synthetic-content marking until 2 December 2026, and the new prohibitions introduced by the omnibus carry a grace period to the same date. That is under four months away. For most product teams 2 December 2026 is the deadline that matters this year, not 2027 and certainly not 2028. So the working calendar is: now, general applicability plus Article 50 transparency; 2 December 2026, grace periods close; 2 December 2027, Annex III standalone high-risk; 2 August 2028, Annex I product-embedded high-risk. Four dates, in that order, in the roadmap.
Two practical notes on how to hold this calendar. First, the dates attach to systems, not to companies, so an organisation can be simultaneously past a deadline on one product and eighteen months away on another. A single company-wide compliance date is a fiction that will cost you the ability to prioritise. Second, the deferred dates are the outer edge of a process that runs backwards from them. If a system needs third-party conformity assessment, the work has to be finished, not started, well before December 2027, and the queue for that assessment is shared with every other company in Europe reading the same calendar.
Article 50 was not delayed, and it is the clause that touches most products
The single most consequential fact after the omnibus is a negative one: Article 50 transparency obligations were not delayed. They took effect on 2 August 2026 as scheduled. This is the clause that says a person interacting with an AI system should know it, that synthetic audio, image, video and text should be marked in a machine-readable way as artificially generated or manipulated. It also has the widest blast radius of anything in the Regulation, because it does not care whether your system is high-risk. A support chatbot, a marketing image generator and an internal drafting tool that publishes externally are all in range.
Machine-readable marking needs testing across the publication path. A content-management system, image conversion or export step may remove metadata. For content where Article 50(2) applies, verify the marker in the final published asset, not only at generation time.
The disclosure side is cheaper but easy to get wrong in ways that annoy users. A single line at the top of a chat window is usually enough; a modal that must be dismissed every session is not proportionate and will be tested away within a quarter. Put the wording in a shared component, version it, and log which version each user saw, because the question you will eventually be asked is not whether you disclosed but whether you disclosed on a particular date. The fairness and bias questions covered in AI ethics and bias run alongside this work rather than replacing it.
What the deferral buys you, and what it does not
What the extra time genuinely buys is room for the slow parts. Conformity assessment for an Annex III system is not a document written in a sprint. It involves a risk management process that runs across the lifecycle, data governance evidence for training, validation and test sets, technical documentation, logging, human oversight design, and accuracy, robustness and cybersecurity claims you can defend under questioning. The harmonised standards that make those claims tractable are still maturing, and notified body capacity for the categories needing third-party assessment was never going to absorb the whole market in a single quarter.
What it does not buy is the thing most teams assume. It does not exempt you from Article 5, in force since February 2025. It does not touch the general-purpose AI obligations that have applied since August 2025. It does not delay Article 50. It does not affect the GDPR, which continues to apply to every personal data flow in your system independently of the AI Act, and it has no effect whatsoever on Turkish law, where Law No. 6698 and the regulator's own guidance already govern what you may do with personal data in a model pipeline, as set out in KVKK's generative AI guidance for engineering teams. A team reading the omnibus as a general amnesty has misread it.
The subtler cost of the deferral is behavioural. The long-lead item in AI Act compliance is not policy, it is evidence, and evidence is hostile to retrospective assembly. If you decide in mid-2027 that you need eighteen months of evaluation results, drift monitoring, incident records and human-override statistics for a system that has been live since 2025, you cannot manufacture them. Every month you defer the logging is a month of technical documentation you will never have. Pause the paperwork if you must, but do not pause the instrumentation, because instrumentation is the one part that cannot be backfilled.
Extraterritorial scope: why a Turkish company is already inside it
The AI Act is not a rule about where your company is registered. It is a rule about where the system and its effects land. A provider that places an AI system on the Union market is in scope regardless of where it is established. So is a provider or deployer established outside the Union where the output produced by the system is used in the Union. That second limb is the one that catches Turkish companies, and it catches them quietly. A Turkish SaaS vendor with three enterprise customers in Germany is in scope for those deployments. So is a Turkish services firm whose model ranks job applications for a client in the Netherlands, even though every server, every engineer and every contract sits in Türkiye.
In practice the trigger patterns are boringly common. You have an EU subsidiary or a reseller. Your product has self-serve signup and EU users found it. Your output is consumed by an EU deployer who then makes decisions with it. You white-label into a platform that ships into the Union. Any of these puts part of your portfolio under the Regulation, and the assessment is per system and per role, not per company. The right response is to draw a line through the inventory separating systems with EU exposure from systems without, and to keep that line current, because sales will move it without telling engineering.
Even where the legal analysis says you are outside scope, the Act usually arrives through procurement instead. EU customers who are in scope push their obligations down the supply chain in contract language, and the questionnaires now ask for model documentation, evaluation evidence, log retention terms and incident notification windows. We see this in nearly every EU-facing RFP a Turkish vendor answers. Answering well is a commercial advantage; answering badly loses deals that had nothing to do with regulators in the first place. For the domestic half of the picture, including how the same obligations reach Turkish vendors through export relationships, see where Turkey's AI regulation actually stands.
Penalties: the structure, and the number everybody quotes
The Act uses a tiered penalty structure, expressed as a share of worldwide annual turnover or a fixed euro amount, whichever is higher. Qualitatively there are three bands. The highest band is reserved for breaches of the prohibited practices. A middle band covers failures against most other obligations, including the high-risk requirements and the transparency duties. A lower band applies to supplying incorrect, incomplete or misleading information to notified bodies or national competent authorities. That design is deliberate, and it tells you something about how supervision is expected to work: misleading a regulator is punished on its own track, separately from failing a technical requirement.
The figure quoted everywhere is the top of the highest band: up to 7% of worldwide annual turnover or EUR 35 million, whichever is higher. Two things about it are usually missed. The first is that it is a ceiling rather than a tariff; actual amounts turn on the nature and duration of the infringement and whether the entity cooperated. The second is the phrase whichever is higher, which is what makes the number bite for smaller companies. A firm with EUR 40 million of turnover does not face a neatly proportionate fine, because the euro floor applies. For a mid-sized Turkish exporter that is the entire company, and a board deserves to hear it stated plainly.
That said, fines are rarely the first-order risk for an engineering organisation. The realistic sequence is market pressure long before enforcement: a customer audit fails, a procurement gate closes, a distributor pulls a listing, a system is withdrawn while a documentation gap is fixed. The cost of a six-week withdrawal from a revenue-generating product usually dwarfs anything a first supervisory action would produce, and it arrives years earlier. Size the programme against that outcome rather than against the headline percentage. It is the outcome you can actually forecast, it is the one your commercial team already understands, and it makes the budget conversation an operational one rather than a legal one.
Are you a provider or a deployer, and is the system high-risk at all
Almost every obligation in the Act attaches to a role, so classification comes before everything else. A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses one under its own authority. The obligations are asymmetric: providers carry the heavy conformity, documentation and post-market monitoring load, while deployers carry oversight, input-data and instruction-following duties. The trap is that roles are not stable. Rebranding a third-party system as your own, or making a substantial modification to one, can move you from deployer to provider, and plenty of teams have made that move accidentally by shipping a fine-tuned model under a product name.
The second question is whether the system is high-risk at all, and the honest answer for most enterprise deployments is no. An internal document search assistant, a drafting tool for marketing copy, a code assistant, a customer FAQ bot: none of these fall into Annex III categories, and pretending they do wastes budget. High-risk means the enumerated Annex III uses, such as employment screening or biometric identification, or an AI system acting as a safety component of a product covered by the Annex I legislation. If you are in neither bucket, your obligations this year are transparency, general product and consumer law, data protection, and whatever your customers demand contractually.
What we insist on is that the classification be written down. A one-page decision record per system, carrying the role, the category, the reasoning, the person who signed it and the date, is worth more than a hundred-page policy. It is the artefact that answers an auditor's first question, it survives staff turnover, and it forces the uncomfortable conversation early, which is the point of it. Re-run the assessment whenever the system materially changes, and treat a change of role as a release-blocking event needing fresh sign-off. That record, along with the other fields an inventory entry has to carry, is specified in the governance artefacts engineers actually run.
GPAI obligations already apply, and they land on your suppliers
Obligations on providers of general-purpose AI models, in Articles 51 to 56, have applied since 2 August 2025. If you build on top of a foundation model rather than training one, you are not the addressee of those articles, but you are their principal beneficiary. They are the reason your model supplier can be asked for technical documentation, information for downstream providers, a policy on copyright, and a sufficiently detailed summary of training content. Now it corresponds to an obligation on the other side of the table, and the correct move is to ask for the artefacts in writing during procurement rather than at audit time.
Put the requests in the contract, not in the kickoff call. The list we use is short: model and version identifiers with a change-notification commitment; the supplier's own documentation package; evaluation results relevant to your use case; a statement of data-handling terms for prompts and outputs, including whether either is used for training; incident notification timelines; and an exit path if a model version is withdrawn. Model deprecation is the underrated item. Hosted model versions retire on the supplier's calendar rather than yours, and a forced migration invalidates every evaluation result you hold.
There is an architectural consequence as well. The heavier your regulatory exposure, the more attractive it becomes to control the model layer, whether through self-hosted open-weight models or through a supplier willing to contract on the terms you need. That decision remains mostly economic rather than legal, and the trade-offs are unforgiving in both directions, but the regulatory column in the comparison has grown heavier since August 2025. We would not move a workload in-house for compliance reasons alone, and we say so to clients who ask. We would refuse to build a regulated system on a model whose supplier will not say what changed between versions.
What to build in the next twelve months, deferral or not
A practical starting sequence is to inventory AI systems, record each provider or deployer role, document the relevant use and classification, and review any Article 50 exposure. These are planning recommendations, not statutory project phases or staffing estimates. The required controls and dates depend on the particular system.
Months three to six are instrumentation, the part that cannot be backfilled. Build the evaluation harness against a versioned dataset, wire structured logging that captures inputs, outputs, model version, retrieval sources and latency, and design the human oversight mechanism for real rather than as a sentence in a policy. Retention has to be settled with your privacy people at the same time, because the AI Act pushes you to keep logs while data protection law pushes you to keep less. The mechanics live in AI observability and evaluation, and this is where most of the engineering effort actually goes.
For a system that is subject to high-risk duties, connect technical documentation to versioned evidence such as model changes, evaluation results and incident records. Decide the scope and retention of records with the applicable legal duties and privacy requirements in view. No universal engineering budget or timetable follows from the Act.
One thing not to do: build a parallel compliance stack. Every artefact above has a legitimate engineering purpose independent of the Regulation. Evaluation datasets stop regressions. Structured logs shorten incidents. Change control prevents silent model swaps. An inventory prevents paying twice for the same capability. If your compliance programme produces documents that nothing else consumes, it will rot, and the audit will find that it rotted. The teams that come out of this well are the ones who made the regulator a secondary consumer of artefacts the engineers wanted anyway. That is the entire trick, and it is why we treat this as a platform problem rather than a legal one.
How we handle this at Hatson Tech
We are an engineering company, not a law firm, and we are careful about the line. We do not give legal advice on classification. We build the systems that make a classification defensible, and we tell clients plainly when we think their counsel should look at something. In practice that means the evaluation harness, the logging and retention design, the human-review workflow, the model and prompt change-control process, and technical documentation generated from those systems rather than typed into a template. When a client's lawyers produce a position on scope, our job is to make the software match it and keep it matching after the next release.
A useful review compares the legal classification with the deployed system: its model versions, evaluation records, logging, human review and change approvals. Gaps found in that comparison become specific work items, with an owner and a due date.
If you are starting from nothing, the sequence we recommend is inventory, then Article 50 surfaces before December, then instrumentation, then documentation. That is deliberately backwards from how compliance is usually sold, because the cheap wins sit at the front and the expensive commitments belong at the back, once you know which systems justify them. We build this into custom platforms as part of normal delivery rather than as a separate compliance project, which is what our custom software engineering practice exists to do. If it helps, bring the timeline slide you are using today and we will tell you which dates on it are wrong.
Primary sources
Check the European Commission implementation timeline, its AI Omnibus announcement, and Regulation (EU) 2026/1744 for the text and current dates. This article gives an engineering interpretation; counsel should assess a particular system's classification and duties.