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.
Why does an engineering article open with a correction? Because the wrong date produces two equally expensive mistakes. Teams that believed in an August 2026 cliff built compliance theatre at speed: a policy document, a spreadsheet of systems, a governance committee that met twice and then stopped. Teams that later heard about a delay concluded that nothing applies and stood down entirely. Both readings are wrong, and the second is worse, because the obligations that did take effect this month are precisely the ones that touch consumer-facing products. Read the timeline once, write the right dates into the roadmap, and get back to building.
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 is an engineering problem, not a policy problem, and it is harder than it looks. Provenance metadata embedded at generation survives a surprising number of steps and then dies quietly the first time a CDN re-encodes an image, a CMS strips metadata on upload, or a designer exports a crop from a different tool. In the pipelines we review, the marking is usually present at the model boundary and absent by the time the asset reaches production. The fix is to test the whole path rather than the generator: assert the marker at the point of publication, in an automated check, for every asset class you ship. Treat a stripped marker as a build failure, not a documentation gap.
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
Months zero to three are inventory and classification. List every AI-touching system, including the ones bought as features inside SaaS products, because that is where the surprises live. For each one, record the role you play, whether output reaches the Union, the data categories involved, and a high-risk determination with a date on it. Then sweep every user-facing surface for Article 50 exposure and close the gaps before 2 December 2026. In organisations of a few hundred people we typically see this take four to eight weeks of part-time effort from one engineer and one person from legal or compliance, and it reliably surfaces between two and five systems nobody knew existed.
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.
Months six to twelve are documentation as a build artefact rather than a document. Generate the technical file from the systems that already hold the truth: model registry, evaluation runs, data lineage, change log, incident tickets. If a human assembles it by hand each quarter it will be stale within one release cycle and wrong in the specific way reviewers notice. Add an incident taxonomy and a runbook with a named owner, fold in the supplier evidence collected during procurement. For an organisation with five to fifteen systems in scope, one experienced engineer at roughly a quarter of their time for a year is a realistic starting budget.
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 HatsonTech
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.
What we see most often in Turkish organisations is a gap between the two ends. The legal reading is fine, sometimes excellent, and the systems underneath have no logs, no versioned evaluation set and no record of who approved which prompt change. Closing that gap is unglamorous work: a model registry, a prompt repository under version control, an eval suite that runs in CI, and a retention policy someone actually implemented in the database rather than in a PDF. It also pays off well outside compliance, because the same instrumentation is what lets a team change models without fear. Our legal-domain work, described in AI in law, runs on exactly this stack.
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.