EU AI Act GPAI Enforcement Begins August 2, 2026: What Changes for Turkish Companies

TL;DR — 2 August 2026 is the date when the EU AI Act stops being paper and becomes real enforcement. From that day, the European Commission's AI Office starts actively using its power to supervise and fine providers of general-purpose AI (GPAI) models. The ceiling is not small: up to 3% of global annual turnover or €15 million, whichever is higher. Many executives in Turkey wave this away with "it does not concern us, we are not in the EU." But just like GDPR, what matters here is not geography — it is market access. Any Turkish company serving EU users, customers, or business partners is in scope. In this post, drawing on what I see in the field, I will walk you through which obligation binds whom, why the "provider" versus "deployer" distinction can decide your fate, and how to use your existing KVKK groundwork as leverage rather than starting from zero.

Over the past year, working with companies as a consultant, I have watched the same scene play out again and again. I walk into the meeting room, I say "EU AI Act," and around the table I get either blank stares or a dismissive "that is a European issue, it came out last year, it does not bind us." The painful part is that most of this comfort is fed by a misunderstanding: because the Act entered into force in 2024, people assume "it is done, we either comply or we do not." The truth is that the EU is rolling this law out not all at once but on a staggered timeline. And the most critical stop on that timeline, for GPAI providers, is 2 August 2026.

Let me be precise. GPAI provider obligations actually entered into force on 2 August 2025. But the EU granted the sector a one-year breathing window. So the period between 2 August 2025 and 2 August 2026 was a "preparation" phase in which the obligations existed but the Commission was not yet actively exercising its power to fine. On 2 August 2026 that grace window closes and the AI Office's enforcement teeth come out. There is one more detail that is often missed in the field: models placed on the market before 2 August 2025 have until 2 August 2027 to comply. So if you have a legacy model, you have another year — but anything new you release falls directly under the 2026 regime.

Understanding this staggered structure matters, because both the panic of "the law is already in force, we are too late" and the complacency of "there is plenty of time" are wrong. The correct posture is this: you have a preparation window that, used well, is enough — but that, wasted, never comes back.

If we leave the numbers abstract, nobody takes them seriously, so let us make them concrete. The AI Act builds a tiered penalty architecture based on the type of violation. Here it is as a table so it sticks:

Type of violation	Penalty ceiling
Prohibited practices (Article 5)	7% of global annual turnover or €35 million (whichever is higher)
High-risk system violations	3% of global annual turnover or €15 million (whichever is higher)
GPAI provider obligation violations	3% of global annual turnover or €15 million (whichever is higher)

The phrase "whichever is higher" is critical. For a small company, €15 million is an astronomical figure; for a large company, 3% of turnover can be far more than €15 million. So the penalty mechanism is designed to hurt both the small and the large player. Remember the GDPR logic of 4% / €20 million; the EU has carried the same deterrence philosophy into AI, and for prohibited practices it has gone even harder at 7%.

I want to stress that the prohibited-practices ceiling (7% / €35 million) is separate from and higher than the GPAI obligations. In the field, people tend to lump all penalties into one bucket. But the EU's risk-based approach shows itself here: the heaviest penalty is reserved for the behaviors deemed most dangerous (social scoring, manipulative systems), while GPAI provider obligations sit at the same level as high-risk systems (3% / €15 million). Knowing this hierarchy lets you prioritize as you draw your own risk map.

This is the most confusing but most decisive part. By "GPAI provider" the Act means the party that develops and places a general-purpose AI model on the market — the actor that trains a foundation model, brands it, and makes it available via API or otherwise. Names like OpenAI, Google, Anthropic, and Mistral are the classic GPAI providers.

Up to here most Turkish companies feel safe: "I do not train models, I just use ChatGPT or an open-source model." True — but there is a dangerous boundary right at this point, and many executives do not know which side of it they stand on.

The Act draws a sharp line between "provider" and "deployer." A deployer takes an existing model and uses it in its own business processes. A provider's obligations are far heavier. So where is the danger? Here: if you take a model, perform substantial fine-tuning on it, and release it under your own brand, you can legally shift into the "provider" position too.

Let me make this concrete with an example. Say you are a software company in Istanbul. You took an open-weight model, retrained it heavily with your own sector data, called it "CompanyAI," and sold it to your European customers. In your own head you are saying "I am just building an application." But in the EU's eyes, because what you did combines substantial fine-tuning with release under your own brand, it may well count you as a GPAI provider. At that moment you fall under obligations like keeping technical documentation and publishing a training-data summary.

"

My clearest warning from the field is this: before you utter the sentence "I am just a user," look at how much you have modified the model and whether you present it under your own brand or as-is. Those two questions are the breaking point that determines which set of obligations binds you.

This distinction is so important that one of the first things I do in a consulting project is to make the company answer, for each individual use in its AI inventory, the question "are we a provider or a deployer here?" Because the same company can be a deployer in one product and a provider in another. Categorizing yourself with a single label and relaxing is one of the most expensive mistakes.

If you came out of the test above with "yes, we are a provider," you need to internalize four core obligations. Let me unpack them one by one, with what each actually means.

1. Keep technical documentation. You must maintain a regular, up-to-date technical file on how your model was trained, what architecture it uses, and its capabilities and limitations. This is not a "write something and put it in a drawer" task; both the AI Office and the downstream providers who use your model may need this information. In Turkish engineering culture documentation is often the last thing anyone thinks of; here that habit needs to be reversed.

2. Share information with downstream providers. Companies that take your model and embed it into their own products need certain information from you to meet their own legal obligations. You cannot sell your model as a black box; you are obliged to provide the technical and legal information the integrating party needs in order to comply with the law. This is not a "transfer of responsibility" along the supply chain — it is a "sharing of responsibility."

3. Adopt a copyright policy compliant with the EU copyright directive. The copyright dimension of the data you used to train your model is no longer something you can ignore. You must have a policy compliant with the EU copyright directive, one that in particular respects rightsholders' opt-out rights regarding text and data mining. This is a topic that requires the legal team and the engineering team to sit at the same table.

4. Publish a sufficiently detailed public summary of training data. This is perhaps the most debated obligation. You are asked to provide a public, "sufficiently detailed" summary of what you trained your model on. The balance here is delicate: on one hand you want to protect your trade secrets and competitive edge, on the other you must meet the transparency obligation. The AI Office provides templates for this; but the spirit of it is that "the public and rightsholders can form a reasonable idea of what the model learned."

When they read these four obligations, most executives' first reaction is "this is a lot of work." They are right. But I would add: most of these obligations are, in fact, already part of good engineering and good governance. Proper documentation, traceability of data sources, a clean conscience on copyright — these are things that should exist even without the law. The law simply makes them mandatory.

There is also a layer that sits on top of this. If your model is classified as one carrying "systemic risk" — that is, a frontier-level model trained with very high compute, with potential impact at societal scale — additional obligations kick in. These are:

• Model evaluation, including adversarial testing (red-teaming): systematically stress-testing the model against misuse scenarios.
• Systemic-risk documentation and mitigation: documenting the societal-scale risks the model could create and taking measures to reduce them.
• Serious incident reporting: reporting to the competent authorities when a serious incident involving the model occurs.
• Cybersecurity: high-grade security measures to protect the model and its weights.

Let me be candid: the overwhelming majority of companies in Turkey will not enter this "systemic risk" league. This category essentially targets the world's few largest model developers. But knowing this layer exists is still valuable, because it shows the EU's risk-based way of thinking: the more powerful and widely impactful a system you build, the heavier the responsibility you carry. That logic is a principle you can take as a guide when designing your own internal governance too.

To show that this process is not only stick, the EU also offered a carrot: the voluntary GPAI Code of Practice. This is a framework that clarifies the compliance path for providers and, once you sign it, gives you a kind of "safe harbor"-like advantage. In other words, if you demonstrate your compliance through this framework, your legal uncertainty shrinks and you have proven your good faith.

The engagement of major players like Anthropic, Google, OpenAI, and Microsoft in this process is an important signal. It shows that the rules are not just abstract texts written at a desk in Brussels, but a consensus that includes the sector's de facto leaders. For Turkish companies, the practical meaning is this: instead of saying "we will figure out compliance along the way," you can read this voluntary framework as a road map. However the big players position themselves, the rest of the ecosystem will be pulled toward that standard.

One of the sentences I hear most often from executives in Turkey lately is: "I heard the EU is postponing this, so there is no need to rush." I need to clear this up, because there is a dangerous misunderstanding here.

Yes, there is a package on the EU agenda called the "Digital Omnibus," and this package proposes postponing some high-risk system deadlines. But watch two critical details here. First, this is a proposal. For a regulatory proposal to take legal effect, it must be published in the EU's Official Journal. Until it is published, no date changes — it is all speculation. Second, the postponement under discussion mainly concerns the high-risk system timeline; 2 August 2026 remains an active date on the table.

"

My advice from the field is very clear: planning as if a regulation has been published in the Official Journal when it has not is contrary to the most basic rule of corporate risk management. Plan for 2 August 2026 as if there were no chance of postponement at all. If a delay does come, having a ready compliance infrastructure in hand makes you strong, not weak.

I would add one more thing here: news of postponements always creates a sense of relief, and that relief kills preparation momentum. One of the most expensive mistakes I have seen across my career is leaving the work to the last minute in the expectation that "it will be postponed anyway." Compliance is not a product you can buy at the last minute; it is a process spread over months. So treat postponement speculation not as a break, but at most as a bonus.

Now let us come to the Turkey dimension, because that is the real concern of this post. I hear the objection "we are not an EU member, this law does not bind us" a lot, and every time I give the same answer: remember GDPR.

When GDPR came into force there was the same comfort. "We are in Turkey, what does Europe's data rule have to do with us?" Then what happened? Every Turkish company serving an EU customer, processing an EU user's data, found itself within GDPR's scope. Because GDPR was defined not by geography but by market access. The AI Act is built on exactly the same logic.

Concretely, who is in scope? If you fit one of these profiles, this law directly concerns you:

• Turkish technology companies selling AI-powered software or services to customers in the EU.
• Manufacturers who export products to the European market where those products contain an AI component.
• Companies operating an AI product (app, platform, API) accessible to EU users.
• Turkish firms sitting in the supply chain of an EU company and supplying it with an AI component or model.

That last item is especially critical. Turkey is an export-oriented economy, and many of our companies sit in the supply chains of large European brands. Because that European brand must comply with the law, it will demand proof of compliance from you too. So even if you do not sell directly to the EU, if you are a supplier to a customer that sells to the EU, the compliance pressure will flow to you through contracts. We are already starting to see this in the field: European buyers have begun adding AI compliance clauses to supplier contracts.

Now let me get to the good news, because most Turkish companies are sitting on an advantage they are not aware of: KVKK, Turkey's data protection law.

Companies that have invested in KVKK compliance for years have, in fact, already laid some of the cornerstones of AI Act compliance. There are serious overlaps between the two regimes, and if you use those overlaps deliberately, you extend your existing infrastructure instead of starting from scratch.

The most obvious overlap areas are:

• Data inventory: The personal data processing inventory you prepared for KVKK forms the skeleton of the data governance the AI Act expects. If you have already documented what data you take from where and how you process it, you are far more prepared for the training-data transparency obligation.
• DPIA (Data Protection Impact Assessment): The impact assessment methodology you used under KVKK is conceptually related to the AI Act's risk assessment logic. You have already exercised the muscles of risk identification, likelihood-impact analysis, and defining mitigating measures.
• Governance structures: The controller / processor distinction, responsibility assignment, and documentation discipline you built for KVKK transfer directly to the AI Act's provider/deployer distinction and its accountability expectation.

So my message is this: do not file KVKK away as a "finished project." Reposition it as the springboard for AI Act compliance. Turkish companies that do this well can start out ahead even of a European competitor that has no KVKK groundwork at all. This is the concrete way to turn a defensive obligation into a competitive advantage.

Set aside the GPAI obligations for a moment — the AI Act also has a "high-risk systems" category, and many Turkish companies fall right into it by virtue of their use cases. The Act lists the application areas deemed high-risk in Annex III. The main ones that may directly concern you:

• Hiring and employment decisions: AI systems that screen CVs, rank candidates, or generate promotion or termination recommendations. This concerns anyone using or building HR technology.
• Credit scoring: Systems that determine individuals' creditworthiness. An area my friends on the fintech and banking side need to watch closely.
• Biometric identification: Facial recognition and similar biometric identification systems.
• Critical infrastructure: AI used in managing critical infrastructure such as energy, water, and transport.
• Law enforcement: Systems used in security and justice applications.

If you look at this list and say "we have one of these," then independently of the GPAI side you also need to put high-risk system obligations on your agenda. HR technology and fintech in particular are two rapidly growing areas in Turkey, and both are on this list. If you build or use a hiring algorithm, the moment you sell it to a European customer you enter the high-risk system regime.

In field conversations I keep running into the same three objections. I want to address them one by one here, because they are probably on your mind or your board's mind too.

"We already use a US provider's model, the responsibility is theirs." Partly true but dangerously incomplete. Yes, the US provider that trained the foundation model has its own obligations. But the moment you take that model, fine-tune it substantially, and offer it under your own brand, a provider obligation arises on your side. And even where you remain a deployer, if you have a high-risk use case your own obligations continue. Saying "the responsibility is entirely theirs" often does not reflect reality.

"How will the EU even supervise us, we are in Turkey?" The supervision mechanism does not work through an inspector knocking directly on your door; the real pressure comes through the commercial relationship. Your European customer, to secure its own compliance, will demand from you contractual proof of compliance, documentation, and commitments. So the one "supervising" you will most often be not an EU authority but your customer, deciding whether or not to keep working with you. That is a pressure you will feel even faster than a fine.

"We are a small company, nobody will bother with us." Remember the "turnover or fixed amount, whichever is higher" logic of the penalty architecture. Being small does not protect you from fines, because the fixed ceiling (€15 million) is already large enough to finish a small company. But more importantly, being small and agile can be turned into an advantage here: compared with the months-long compliance bureaucracy of a large institution, you can clarify your inventory and roles within weeks and tell the European customer "we are ready."

The common thread of these three objections is this: all of them are comforting in the short term and expensive in the long term. My job in the field is precisely to confront those comforting stories with reality.

Let us set theory aside and move to the practical steps I apply in the field. If you are reading this today, in mid-2026, and have not started yet, I recommend taking these steps without panic but without wasting time.

Step one — Build an AI inventory. Collect every AI system used, developed, or integrated in your company into a single list. Include shadow usage; the tools that departments use without anyone's knowledge are the biggest blind spot. Without this inventory, no compliance work can be realistic.

Step two — Assign a role to each system. For each item in the inventory, answer the question "are we a provider or a deployer here?" Pay special attention to systems you fine-tune and offer under your own brand; these are the red flags that move you into provider status.

Step three — Classify the risk. Map each system to the AI Act categories: prohibited, high-risk, GPAI, limited-risk? Keep the Annex III list at hand and look especially at areas like HR, credit, and biometrics.

Step four — Gap analysis. For the systems where you are a provider, check the four core obligations (documentation, downstream information sharing, copyright policy, training-data summary) one by one. List wherever you have a gap.

Step five — Wire in your KVKK infrastructure as leverage. Map your existing data inventory, DPIA, and governance structures to the AI Act requirements. Do not reinvent; extend.

Step six — Read the voluntary Code of Practice as a road map. If you are a provider, study the Code of Practice and calibrate your own compliance approach accordingly.

Step seven — Review your contracts. Check the AI compliance clauses in your contracts with European customers and suppliers. These clauses have started to appear; do not get caught unprepared.

If you apply these seven steps with discipline, you enter 2 August 2026 not with the fear of "will we be fined," but with the confidence of "we are ready."

Let me close with an analysis, because I do not want to leave someone who has read this far with only a to-do list. How you look at this issue determines the outcome.

Most companies in Turkey see the AI Act as a cost item, a burden, "a bureaucracy the Europeans are imposing on us." This view is understandable but strategically weak. Because this law, just like GDPR, will turn into a de facto global standard. The European market is large enough that anyone who wants to sell there will have to comply with these rules, and that automatically makes the rules a global norm.

Think of it this way: a Turkish company that does the compliance work early and properly gains two concrete advantages. First, the power to tell the European customer "we are compliant, working with us is not a risk for you." That is a direct competitive edge at the sales table. Second, the discipline the compliance process forces on the company — proper documentation, clean data governance, traceable processes — actually matures your AI operations. So while complying with the law, you also build a better AI organization.

On the other hand, a company that neglects this loses on two fronts: it faces enforcement risk (3% / €15 million), and it falls behind while its compliant competitors capture share in the European market. The worst-case scenario is a European customer suspending its relationship with you on the grounds of "compliance risk" — and we have started to see this happen in the field.

My clear conviction from the field is this: 2 August 2026 is not a threat for Turkish companies but a point of differentiation. Those who arrive prepared will capture the position of "trusted AI supplier" in the European market early. Those who are late will grapple both with fines and with lost contracts. The preparation window in your hands is still open; but with each passing week, a little less light comes through it. The inventory and role-assignment step you take today will determine which side you stand on a year from now.