EU AI Act August 2026: Enforcement Powers Live, the Digital Omnibus Deferral

TL;DR — August 2, 2026 is the date that turns the EU AI Act's on-paper rules into a real enforcement regime. From this date, the European Commission begins actually exercising its powers over general-purpose AI (GPAI) model providers: requesting documentation, conducting evaluations, demanding measures, and imposing fines. In the same window, the "Digital Omnibus" package — provisionally agreed on May 7, 2026 — defers the expected August 2, 2026 deadline for high-risk systems under Annex III to December 2, 2027. So the picture is twofold: enforcement tightens on the GPAI front while high-risk deployment obligations get breathing room. For anyone in Türkiye selling services and products into Europe, this doesn't mean "no obligations" — it means "the timeline of your obligations has changed."

In recent months, nearly half of my enterprise consulting calls opened with the same sentence: "Are we subject to the EU AI Act or not?" The answer is "yes" more often than you'd think. The regulation doesn't look at geographic borders but at where the system is used and whether its output touches the European market. If a software house in Istanbul builds a hiring screening tool for a client in Germany; if a manufacturer in Bursa runs an embedded decision system in a machine it sells to Europe — you are within scope.

What makes August 2, 2026 special is this: GPAI rules have actually been in force since August 2, 2025. Large language model providers' obligations to maintain technical documentation, provide information to downstream developers, adopt an EU copyright compliance policy, and publish a summary of training data have existed on paper for a year. Only one thing was missing: teeth. The Commission's power to actually supervise and enforce these obligations comes into effect on August 2, 2026. The difference between a rule existing and an authority standing behind it able to levy fines is a difference every board that allocates a compliance budget knows very well.

"

In regulation, the "obligation date" and the "enforcement date" are not the same thing. The first binds you to the rule; the second makes the cost of breaking it real. August 2, 2026 is the second.

The powers the Commission gains over GPAI providers fall into four headings. I always explain these to clients with concrete scenarios, because in the abstract nobody takes them seriously.

First, the power to request documents and information. The Commission can ask for a model's technical documentation, training records, and safety evaluations. This means the "secret recipe" defense no longer holds in every case.

Second, the power to conduct evaluations. For models carrying systemic risk, the Commission can run independent assessments and test whether the model actually has the claimed safety measures.

Third, the power to request measures. This ranges from compliance measures to risk mitigation, market restriction, recall, and withdrawal. The Commission can effectively force a model off the European market.

Fourth, and the most talked about, the power to impose fines. For GPAI violations, fines can reach a certain percentage of global annual turnover. For a model's developer, this is not a theoretical risk but a balance-sheet item.

Power	What it means	Practical impact
Document request	Requesting technical docs and records	"Secret" defense weakens
Evaluation	Independent safety testing	Claimed measures get verified
Request for measures	Mitigation, recall, withdrawal	Model can be pulled from market
Fines	Turnover-proportional penalty	Balance-sheet risk emerges

Now to the other half of the picture, because describing only the tightening side paints an incomplete image. The "Digital Omnibus" package, provisionally agreed on May 7, 2026 and pending formal adoption, deferred the expected compliance deadline for high-risk AI systems under Annex III from August 2, 2026 to December 2, 2027.

What does Annex III cover? Use cases that directly touch fundamental rights: hiring and HR systems, credit scoring, education and exam assessment, critical infrastructure management, and law enforcement applications. In other words, most companies' AI projects fall squarely into this category. If you use CV screening in hiring or score customer credit with an algorithm, this deferral directly affects your timeline.

Why the deferral? Let's be honest: the compliance infrastructure wasn't ready. When harmonized standards, classification guidelines, and support tools were delayed, pressure came from industry and member states that "compliance is impossible on this timeline." The Commission postponed the actual application of high-risk obligations until the infrastructure matures.

"

A deferral is not an amnesty. It doesn't say "do less"; it says "do the same thing with more ready infrastructure, a little later." Explaining this distinction correctly to the board is one of a consultant's most critical jobs.

These are the mistakes I see most in the field, and each costs companies dearly.

"The deferral happened, so we don't need to rush anymore." This is the most dangerous reading. Compliance for high-risk systems is not a weekend job. Data governance, a risk management system, technical documentation, human oversight mechanisms, record-keeping infrastructure — all of these take months. December 2, 2027 looks far away, but if the compliance journey takes 18 months, starting today may already be late.

"We only use the model, we don't build it, so we're not responsible." Wrong. The regulation defines "provider" and "deployer" roles separately and assigns distinct obligations to each. If you take a GPAI model and use it in a high-risk application, as a deployer you have human-oversight, fitness-for-purpose, and record-keeping obligations.

"Türkiye isn't an EU member, this doesn't bind us." Market, not geography, is decisive. If your output is used in Europe, you're in scope. Moreover, Türkiye's own KVKK framework brings parallel obligations on automated decision-making and profiling; the two regimes must be considered together.

KVKK's provisions — especially on automated decision-making, profiling, and explicit consent — share largely the same logic as the EU AI Act's transparency and human-oversight obligations. In my consulting work I always tell organizations: don't run two separate compliance projects; build a single governance backbone and feed both from it.

In practice, that means: if you keep a personal-data processing inventory (which KVKK already requires), link that same inventory to a risk-classification table for AI systems. If you have a DPIA (data protection impact assessment) template, add the AI Act's fundamental-rights impact assessment (FRIA) fields to it. ISO 42001 (the AI management system standard) offers a good skeleton for uniting these two frameworks under one roof.

Let me summarize the action plan I give organizations in four phases.

Phase one, inventory and classification. First, list all AI systems operating in your company — the official ones and the shadow AI tools that units quietly use. Place each system into a risk category: prohibited, high-risk, limited-risk, minimal-risk. No compliance work is meaningful without this inventory, because you can't protect what you don't know you have.

Phase two, role clarification. For each system, determine whether you are the provider, deployer, or importer. The role determines the obligation. Most Turkish companies are both a deployer consuming a GPAI model and a provider selling their own product into Europe; this dual role must be managed well.

Phase three, documentation and technical infrastructure. Technical documentation templates, model cards, data-governance records, a risk management system, and human-oversight procedures. This is the longest phase; the deferral bought you time precisely to set this phase up properly.

Phase four, monitoring and refresh. The regulation is a live target. Digital Omnibus itself is proof: timelines change, standards mature, guidelines get published. Compliance is not a one-off project but a continuous operating discipline.

"

If you treat compliance as a "compliance project," it ends and gets forgotten. If you treat it as an "operating discipline," it institutionalizes and becomes a competitive advantage. The Turkish company that confidently sells into Europe uses compliance not as a cost but as a door.

Most Turkish companies don't train their own foundation model. So it's tempting to think "GPAI enforcement doesn't concern us." But the essence is this: if you build an application on top of a GPAI model, you depend on the documentation and transparency information that model's provider submits to the Commission. After August 2, 2026, providers will be forced to produce more rigorous documentation, which will make it easier to feed your own compliance file. Make it a habit starting today to request model cards, usage restrictions, and safety-evaluation information from your provider.

Also, watch your contracts. Does the service agreement you signed with your GPAI provider commit them to supplying you the information you need for regulatory compliance? If not, ask for it at the next renewal. Compliance is only as strong as the weakest link in the supply chain; your file rests on your supplier's transparency.

It's not only the EU AI Act — the general AI governance environment is tightening too. Industry analyses project that AI-related legal claims will exceed 2,000 by the end of 2026 due to insufficient risk guardrails. This shows the governance gap isn't an abstract risk but a measurable wave of litigation. The deferral gave you time; but you need to spend that time preparing, not waiting.

For most companies the real bottleneck isn't technology but process. Who's responsible, which system is in which category, who keeps the documentation, which file will you present within 48 hours when an audit arrives? If you don't have answers to these questions today, December 2, 2027 is not far at all.

Delegating regulatory compliance to the technical team is the most common strategic mistake I see. The penalty architecture in the EU AI Act is exactly why this is a board-level matter. The most serious violations — for example, the use of prohibited practices — can be met with fines up to 7% of global annual turnover. Violations of high-risk system obligations carry lower but still balance-sheet-shaking rates. For GPAI specifically, the fines the Commission can impose reach a certain percentage of global turnover.

Why do these numbers matter? Because compared with the cost of a compliance investment, the size of the fine makes the decision easy. In a mid-sized company, the full compliance cost of a high-risk system — documentation, risk management system, human oversight, auditing — is usually a six-figure number. The fine can be seven or eight figures. When you show the board this comparison clearly, the compliance-budget debate ends in seconds.

"

Compliance is not a cost center but an insurance policy. If you don't pay the premium today, you'll pay the claim far more dearly tomorrow.

There are two tiers in the GPAI world. Ordinary GPAI models and GPAI models "with systemic risk." The second category covers models trained above a certain compute threshold — the largest and most capable models. These carry additional obligations: systemic risk assessment and mitigation, adversarial testing, serious incident reporting, and cybersecurity measures.

The Commission ran a Code of Practice process to make it concrete how these obligations should be met. These codes offer a roadmap for how providers can demonstrate compliance in practice. For Turkish companies the key message here is: even if you don't train your own model, you need to know whether the model you use falls into this category. Because if you build an application on top of a model with systemic risk, some of the risks that model carries also flow into your application.

In my consulting, translating abstract regulatory language into sector terms is what works best. Let's take a quick tour.

In banking and finance, credit scoring and fraud detection systems are high-risk under Annex III. In Türkiye, the BDDK's own regulations add to these; there's a two-layer compliance situation. For financial institutions operating in Europe or serving European customers, the deferral is a relief, but every credit-decision algorithm must be explainable, auditable, and subject to human oversight.

In healthcare, diagnostic support, patient triage, and medical device software sit at the intersection of both the EU AI Act and medical device regulations. Compliance here is two-directional and must be the most rigorous, because both fundamental rights and direct patient safety are at stake.

In human resources, CV screening, candidate ranking, and performance evaluation systems are classic high-risk examples. Many Turkish companies use these tools for their European subsidiaries or remote worker pools, and most aren't even aware this falls under the regulation.

In manufacturing and industry, there are decision systems embedded in machines, quality-control AI, and predictive-maintenance tools. For Turkish manufacturers exporting machinery to Europe, this is an area intertwined with product safety regulations.

Sector	Typical high-risk system	Extra layer in Türkiye
Banking	Credit scoring, fraud	BDDK regulations
Healthcare	Diagnostic support, triage	Medical device law
HR	CV screening, ranking	KVKK profiling
Manufacturing	Embedded decision systems	Product safety

The most important thing that determines a compliance effort's success isn't technical detail but clarity of responsibility. The healthiest structure I see in the field is this: set up an "AI governance committee." On this committee, legal, information security, data protection (DPO), a business-unit representative, and a technical lead sit together. Every AI system should have an "owner" — a single name responsible for that system's risk category, documentation, and compliance.

Without this structure, compliance hangs in the air. The principle that "everyone's job is no one's job" applies ruthlessly here. When an audit arrives and you can't instantly answer "who's responsible for this system?", your compliance exists only on paper. I always tell organizations: governance comes before documentation. First clarify who's responsible for what, then let those owners produce the documents.

I touched on this briefly above, but the topic deserves its own heading, because this is where Turkish companies are weakest. Your AI supply chain has at least three parties: the foundation model provider, intermediary platform/tool providers, and your own development. Compliance information must flow through every link of this chain.

In your contracts, look for or add these clauses: Does the provider commit to supplying the technical documentation and model information needed for regulatory compliance? Do they notify you when the model changes significantly or moves to a new version? Do they have an obligation to inform you in the event of a serious incident? Without these clauses, your compliance file can collapse at any moment on your supplier's silence.

Also mind the "intended purpose" definition. The provider may have certified the model for a specific use; if you use it in a completely different high-risk context, in the regulation's eyes you may become that system's new "provider" and all obligations fall on your shoulders. This is a hidden risk many companies take on without realizing it.

If you do just one thing after reading this, let it be this: within the next two weeks, produce an inventory of the AI systems in your company and place each into a risk category. You can keep this inventory as simple as an Excel table — system name, purpose of use, data type processed, risk category, responsible unit. This table will be the shared backbone of both your KVKK and EU AI Act compliance. It's also exactly what will be asked first when an audit arrives. The cheapest way to be prepared is to start earliest; and the deferral opened a gift window precisely for that early start.

In my consulting I've seen that abstract advice doesn't work — people need dated, concrete plans. So let me share the 90-day plan I give organizations. In the first 30 days, produce the inventory and clarify roles; this month's output is a single table binding every AI system to a risk category and an owner. In the second 30 days, do a gap analysis for the systems you've flagged as high-risk: where is your existing documentation lacking, do you have a human-oversight mechanism, who keeps the records? In the third 30 days, begin closing those gaps and run an "audit drill" — that is, tell someone "the Commission arrived yesterday; prepare the file for system X in 48 hours" and see whether you actually can.

This drill ruthlessly exposes the difference between paper compliance and real compliance. In most companies the first drill ends in disaster: documents are scattered, ownership is unclear, records are missing. The good news is that discovering this in your own controlled environment, before an audit arrives, is far cheaper. I call it "the fire drill of regulation"; it's the safest way to learn what you'll do in a real fire.

One last reminder: this plan is not a one-and-done exercise. The very fact that Digital Omnibus changed the timelines shows the regulation is alive. So review your inventory quarterly, record new AI systems into the table as they're added, and keep owners current. Compliance is like a muscle; if you don't exercise it regularly, it atrophies. For every Turkish company that wants to sell confidently into the European market, this discipline is no longer a choice but an operating necessity.

At the end of my consulting sessions the same questions always come up; let me gather the most common ones with short answers, because these questions are probably on your mind too.

"We're a small company — isn't this regulation for the big tech giants?" No. The regulation looks not at company size but at the system's risk category and the market. Even a five-person software firm can be a high-risk provider if it sells a hiring screening tool into Europe. Being small doesn't put you out of scope; there may only be some flexibilities that make the compliance burden proportionate.

"We use ChatGPT or a similar tool only for internal productivity — is that in scope too?" Using a general-purpose assistant for low-risk work like internal correspondence and summarization doesn't fall into the high-risk category. But if you use the same tool in a hiring decision, a credit assessment, or to give a customer direct medical/legal advice, the picture changes. What's critical isn't the tool but the purpose of use and whom the decision touches.

"Do I have to hire expensive consultants right away for compliance?" No. The first steps — inventory, risk classification, role determination — can largely be done with internal resources. Outside support adds value at stages requiring technical depth, like gap analysis and documentation of high-risk systems. First get to know your own house, then call in an expert; the reverse is both expensive and inefficient.

"If my model provider is already compliant, am I automatically compliant?" Absolutely not. The provider's compliance covers obligations about the model itself. Your obligations as a deployer — human oversight, fitness for purpose, record-keeping, informing users — are separate and yours. Compliance is a chain of responsibility; each link answers for its own part.

The shared lesson of these questions is this: dismissing the EU AI Act as "it doesn't concern us" is the wrong reflex for most Turkish companies. The right reflex is to ask today, "which of my systems, in which category, under whose responsibility?" This three-part question is the starting point of an entire compliance program, and to find its answer you need neither expensive software nor an army; you need only an honest inventory and a clear distribution of responsibility.

So far we've talked only about obligation, penalty, and risk. But there's a bright side to the coin, and in my consulting I like to bring this side forward. EU AI Act compliance, positioned correctly, can be not a cost but a sales argument. Consider: when a European customer buys a solution containing AI, what do they fear most? Taking on regulatory risk themselves. If you can say "we're already AI Act compliant, our documentation is ready, we'll provide you all the necessary information," you get ahead of your competitors. Compliance becomes a differentiator in supplier selection.

I've seen many concrete examples of this. Turkish companies selling software into Europe increasingly face the question "do you have AI governance documents?" in tenders and supplier evaluations. Companies that come prepared for this question — able to put model cards, risk assessments, and compliance documentation on the table — win the business; those who say "we haven't looked at that yet" are eliminated. So compliance is as much about winning a contract today as it is about protection from an audit that will come one day.

Moreover, compliance discipline raises internal quality too. When you're forced to document an AI system, map its risks, and set up human oversight, you actually end up building a better system. Most of what the regulation asks for — explainability, traceability, data quality, error management — is already a requirement of good engineering. If you see compliance not as a bureaucratic burden but as an expression of engineering discipline, you stand on firmer ground before the regulator, the customer, and your own team. That's why I never present compliance as a "necessary evil"; done right, you become the party holding both the door and the key.