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

TL;DR — In my eyes, 2 August 2026 is the single most important regulatory threshold of the past year. On that date, the European Commission begins actively supervising — and, where necessary, fining — providers of general-purpose AI (GPAI) models. The obligations themselves entered into force on 2 August 2025, but the one-year adjustment window the Commission granted is closing right now. In this piece, speaking as a consultant working in the field, I'll explain why this date matters not only to European giants but also directly to Turkish companies touching the EU market, what the four core provider obligations mean, and the concrete checklist you should start in your organization today.

After years of training organizations on AI, I've seen one pattern over and over: regulatory timelines get pushed aside as "distant, abstract, not our problem." I've watched that same reflex play out with the EU AI Act many times. Yet the defining feature of this regulation is that it enters into force in phases. There's no single moment where "the law passed and enforcement began"; there are successive dates, each activating a different layer of obligations.

On the GPAI — general-purpose AI models — side, the picture is this: provider obligations entered into force on 2 August 2025. But the Commission's supervision and enforcement powers, including fines, apply from 2 August 2026. The year in between was an adjustment and grace window granted to providers. I call it the "gentle transition period." That gentle period is now ending.

There's one more detail most companies miss: for providers of GPAI models placed on the market before 2 August 2025, full compliance is required by 2 August 2027. So there's an extra year of breathing room for models already in circulation. But when it comes to new models and active supervision from 2026 onward, the tone changes entirely.

Let me be plain from the start: this is not a "maybe they'll enforce it" story. The Commission built a dedicated structure — the AI Office — whose job is precisely to monitor GPAI providers, request documentation, run evaluations, and pursue penalty proceedings when needed. The mechanism is institutionalized, staffed, and equipped.

In classic AI-regulation logic, you classify systems by risk level: prohibited applications, high-risk systems, limited-risk systems, minimal-risk systems. But the rise of generative AI added a new layer to that pyramid: foundation models — general-purpose models that serve not one purpose but many.

GPAI captures exactly this broad spectrum. Consider a language model: the same model can power customer service, legal-text summarization, code generation, and marketing content. One model, endless use cases. This ability of a single model to feed thousands of uses forced regulators beyond the traditional system-based approach.

The logic runs like this: if thousands of applications are built on top of one foundation model, then that model's transparency, documentation, and security affect the entire ecosystem. So the regulator places specific responsibilities on the provider at the top of the chain. This makes a lot of sense to me, because from what I see in the field, the vast majority of companies don't train their own model from scratch — they build on a ready-made foundation model. If that foundation is contaminated, everything built on top of it is contaminated too.

There are four core obligations for GPAI model providers. When explaining them to clients, I always use this frame: "write down what it does, tell those beneath you, don't infringe copyright, disclose your data." Let's go one by one.

First, write and keep technical documentation up to date. The provider must prepare technical documentation covering what the model is, how it was trained, its architecture, capabilities, and limitations — and keep it current. This is not a "write once and shelve it" task; as the model changes and updates, the documentation must live too. In my view this is the most neglected obligation, because engineering teams constantly improve the model but documentation falls behind.

Second, provide information and documentation to downstream providers. Companies that take a foundation model and build their own application on top of it are "downstream providers." The GPAI provider must supply these downstream providers with the information and documentation they need to meet their own obligations. This clause is critical to me, because the vast majority of Turkish companies sit in exactly this "downstream provider" position. Your compliance depends on the documentation the provider above you gives you.

Third, adopt an EU copyright-compliance policy. The provider must adopt a policy compliant with EU copyright law. This concerns, in particular, the copyright status of content used in the model's training data. It's one of the most contested topics in the generative AI world: whose content trained the model, could rights-holders object, were opt-out mechanisms honored. The regulator defines a clear responsibility here.

Fourth, publish a summary of training-data content. The provider must publish a sufficiently detailed summary of the kind of content the model was trained on. This isn't a full dataset dump; it's a transparency layer where society and rights-holders can find a reasonable answer to "what was this model fed on." Transparency is the word at the heart of this regulation.

These four obligations reflect a philosophy: the foundation model provider must be a "responsible source of information" to the ecosystem. It can't hide what it does, can't leave those beneath it in the dark, can't use others' work without permission, and can't keep its data entirely secret.

Now I come to the heavier side. Not all GPAI models sit in the same basket. Models exceeding a certain threshold are classified as "systemic-risk GPAI" and carry additional obligations.

The threshold: if the total compute used to train the model exceeds 10^25 FLOP, the model is considered systemic-risk. It's a technical line targeting very large models. The idea: the larger and more capable a model, the broader its reach, and thus the greater its potential systemic risk.

Providers of systemic-risk models must, on top of the four core obligations, also:

• Model evaluation: systematically assess the model's capabilities and risks, applying advanced testing methods such as adversarial testing.
• Systemic-risk mitigation: assess identified systemic risks and take measures to mitigate them.
• Serious-incident reporting: track, document, and report without delay serious incidents and corrective measures to the AI Office and relevant national authorities.
• Cybersecurity: ensure an adequate level of cybersecurity protection for the model and its physical infrastructure.

This extra layer is the concrete expression of the regulator's logic that "the biggest models deserve the most attention." I read it as a proportionality principle: the weight of the obligation scales with the magnitude of the risk.

There's an important mechanism that makes companies' lives easier here: the voluntary GPAI Code of Practice. Under three main headings — transparency, copyright, and safety/security — it offers providers a framework that makes compliance concrete.

The logic: legal text usually says "what must be done" but doesn't detail "how to do it." The Code of Practice fills exactly this gap. If a provider commits to these rules, it has found a practical, predictable way to demonstrate it is meeting its obligations. I call this the "compliance highway": instead of blazing your own trail, you drive the paved road the regulator laid down.

That it's voluntary matters; no one is forcing you. But from what I see in the field, such frameworks tend to become de facto standards over time. What is "voluntary" today can become tomorrow's "what everyone does, so if you don't, you owe an explanation."

From 2 August 2026, the tools the Commission — in practice, the AI Office — can use are:

• Request documentation and information: it can demand technical documents, information, and explanations from the provider.
• Conduct evaluations: it can evaluate the model, testing it through independent experts where needed.
• Request mitigation measures: it can require measures against identified risks.
• Impose fines: it can apply administrative fines for non-compliance.

This is where the weight of the 2026 date lies. In 2025 the obligations existed but had no "teeth"; from 2026 the teeth engage. Fine amounts depend on the severity of the breach and the company's global turnover; I avoid giving specific figures here, because they vary case by case. But I can say plainly: these fines are designed to be deterrent, not symbolic.

Now we reach the part that directly concerns us. In conversations with many Turkish executives, I hear this objection: "We're not an EU member, this law doesn't bind us." That's a dangerous misconception. One of the most striking features of the EU AI Act is its extraterritorial reach.

Think of it this way: the law's applicability looks not at where the company is established but at where the output is used. So a company established in Turkey that uses its AI system — or the output that system produces — in the EU market, or serves people located in the EU, can fall within the law's scope. What matters is not where you physically sit, but where your digital footprint lands.

This will feel familiar to anyone with KVKK experience. GDPR had the same logic: if you process European data, you're in scope no matter where you are. The EU AI Act carries this "effect-based jurisdiction" approach into the AI world.

We've understood extraterritorial reach. But what I really want to emphasize is a less-discussed risk: indirect exposure.

Say you never touch the EU market. You're an entirely local Turkish company. You still face an indirect risk if the foundation model you build on isn't compliant. Because you are a "downstream provider," and to meet your own obligations you depend on the documentation the foundation model provider gives you.

Let me make it concrete: if you have a customer using the system in the EU, and you owe that customer transparency, traceability, or documentation obligations, you can only produce those documents if the provider above you gives them to you. If the provider doesn't provide documentation, or is itself non-compliant, your compliance chain breaks. Someone else's non-compliance becomes your problem.

I call this "supply-chain compliance risk." Just as a contaminated raw material contaminates your product, an undocumented, non-compliant foundation model leaves your application carrying a compliance gap. That's why you must now evaluate model choice not purely on technical performance but also on compliance documentation.

On the Turkey side, there's an important development that completes this picture: KVKK's guide on "Generative AI and the Protection of Personal Data," prepared as a practical resource in a 15 question-and-answer format. I always have my clients read this guide, because it aligns beautifully with the transparency and accountability spirit of the EU AI Act.

Why read them together? Because the two regulations complement each other. Where the EU AI Act defines responsibility at the model and system layer, KVKK binds you at the personal-data processing layer. When you build a generative AI application, you must deal with both the model's compliance (the AI Act side) and the lawfulness of the personal data you process (the KVKK side).

Consider a chat assistant. It processes user data: KVKK engages. The same assistant is built on a foundation model and used in the EU: the AI Act engages. You must stand at the intersection of both regulations. That's why I always design compliance work on "twin rails": one rail KVKK, one rail AI Act.

Let me tie it together and give you a tangible roadmap. If you're a company building an application on top of a foundation model — which most companies in Turkey are — here are the steps I recommend before 2 August 2026:

1. Build a model inventory. Which AI models are used in your organization? From which provider, which version, in which application? Without knowing this you can't do any compliance work. You'll be surprised, but many companies lack this simple inventory; different teams quietly use different models. First, visibility.

2. Collect provider documentation. For every foundation model you use, obtain the provider's technical documentation, terms of use, and copyright/training-data disclosures. If a provider won't give you these documents, that's a risk signal in itself. A provider who can't document leaves you undocumented too.

3. Classify your use. Does your application fall into a high-risk use area, or a limited/minimal-risk one? For example, hiring, credit assessment, health, and education lean toward the high-risk category. Classification determines the level of obligation that falls on you.

4. Apply transparency labeling. Is the user interacting with an AI or a human? Is the generated content an AI output? You must clearly disclose these distinctions to the user. I call this the "honesty label": the user has the right to know they're facing a machine.

5. Set up logging and traceability. Make the system's decisions, inputs, and outputs traceable. Build the logging infrastructure today that lets you answer "what happened, why" when a problem arises. Traceability is worth its weight in gold for both the AI Act and KVKK.

6. Review contracts. Clarify how compliance responsibility is allocated in contracts with your providers and customers. Does the provider commit to giving you the necessary documents? In case of non-compliance, who bears responsibility? These contract clauses will either protect you or leave you exposed in a future dispute.

I recommend framing these six steps not as a one-off project but as an ongoing governance loop. Models change, providers update, the regulatory calendar advances. Compliance is not a photograph, it's a film.

Let me not leave without sharing the three mistakes I see most in the field.

First, the "we're just users" defense. Many companies think they bear no responsibility because they use a ready-made AI tool. Yet the moment you embed that tool into your own product or process and offer it to customers, you move from being a mere user toward a provider role. Reading your role correctly is the first step of compliance.

Second, mixing up the dates. The 2025, 2026, and 2027 dates get tangled, and companies either panic early or fall behind. Let's be clear: obligations began in 2025, active supervision and fines arrive in 2026, full compliance for existing models by 2027. You must know where your own situation falls on this timeline.

Third, outsourcing compliance entirely to legal. Compliance isn't just a matter of reading a legal text; it requires engineering, product, data, and legal teams working together. Technical documentation is engineering's job, transparency labeling is product's, data disclosures are the data team's. Legal alone can't carry this load.

If you were to sit down and do one thing today, I'd suggest this: first organize a half-day "compliance discovery session." Invite one representative each from engineering, product, data, and legal. The single agenda item: "Which AI models are we currently using, where, for whom, and do we have their documentation?"

This simple question is often met with a big silence. That silence is your starting point. If there's no inventory, inventory first; no documentation, request it first; no classification, classify first. Compliance starts not with perfection but with visibility.

2 August 2026 is really not a penalty date but a maturation date. Europe chose to make AI accountable rather than to ban it. As Turkish companies, this train includes us too — whether directly because we touch the EU market, or indirectly through the foundation models we use. My advice is clear: read this date not as a threat but as an opportunity to prove your organizational maturity. A documented, transparent, and traceable AI practice is not only the surest way to avoid fines but also to win the trust of customers and partners. The inventory and documentation steps you take today will carry you a step ahead next year, both before the regulator and in the market.

I touched briefly on the risk categories above, but I want to open this pyramid up further, because most companies misread their own position. The core philosophy of the EU AI Act is not to put all AI in the same basket. Subjecting a product-recommendation engine on an e-commerce site to the same obligations as a screening algorithm making hiring decisions would be neither fair nor sensible. So the regulator adopted a proportionality design.

At the very top are prohibited applications: systems that manipulate behavior to cause harm, social-scoring applications, and the like. These are unambiguously banned. Just below are high-risk systems: those that directly affect human lives and rights in areas like health, education, hiring, credit, critical infrastructure, and justice. This category carries the heaviest documentation, monitoring, and human-oversight obligations. Below that are limited-risk systems, where the main obligation is transparency — such as the user knowing they're talking to an AI. At the bottom are minimal-risk systems: spam filters, in-game AI. These carry almost no specific obligation.

GPAI models stand beside this pyramid like an axis perpendicular to it. Because a foundation model can, depending on where it's used, feed applications that fall into any of these categories. The same language model can power both a minimal-risk writing assistant and a high-risk hiring system. That's precisely why provider-specific, use-independent obligations were introduced. Your job is to correctly determine where your own application falls in this pyramid. Misclassification means either unnecessary cost or a dangerous gap.

A regulation is only as strong as the institution behind it. That's why I want to draw special attention to the existence of the AI Office. This body will play the central role in supervising GPAI models. Requesting documents, evaluating models, conducting investigations into systemic risks, and running proceedings in case of breach are among its tasks.

Why does this matter? Because from the GDPR experience we know there's a big gap between a law passing and that law actually taking effect. In GDPR's early years, many companies waited to see "will this really be enforced." Then the first big fines arrived and everyone understood the seriousness. I expect a similar curve for the AI Act. Once active supervision begins in 2026, the first precedent cases will set the tone for the sector. I always tell my clients: "be ready before a precedent case emerges, because once it does, it's already too late."

Another important function of the AI Office is guidance. It's not only a body that fines but one that interprets, publishes guidelines, and shapes the Code of Practice. So a dialogue channel between the regulator and the sector stays open. Following that dialogue should be part of your compliance strategy. Tracking published guidelines and updated Q&As protects you from surprises.

The biggest structural gap I see in the field is that AI compliance has no clear owner. For KVKK there's usually a contact person or a data-protection officer. But for AI compliance, most companies operate in an "everyone's job, no one's job" state. I strongly recommend filling this gap.

Setting up an AI governance committee may sound large and bureaucratic, but for medium and large companies it's now unavoidable. This committee brings together representatives from engineering, product, data, legal, and information security. Its job is to maintain the inventory of models in use, evaluate new AI projects for compliance, track provider documentation, and follow the regulatory calendar. In small companies this can rest on a single responsible person; what matters is that ownership is clear.

I also want to emphasize the "human oversight" principle. The EU AI Act expects meaningful human oversight, especially in high-risk systems. The system cannot make vital decisions on its own, without anyone's supervision. A design where a human can intervene, review the decision, and halt it when necessary is essential. I call this the "human in the loop" principle. Being seduced by the allure of automation and removing the human entirely is a major risk, both ethically and legally.

So far I've spoken in the language of obligation and risk. But the coin has a bright side too, and I don't want to skip it. Compliance is not only about avoiding fines; it's also a competitive advantage and a form of trust capital.

Picture it: you're a Turkish software company wanting to sell into the EU market. If your competitor says "our documents are incomplete, our compliance status is unclear," while you can say "here is our technical documentation, here is our transparency policy, here are the compliance records of the models we use," who wins the tender? More and more corporate buyers demand proof of AI compliance from suppliers. It's just like how information-security certifications gradually became an entry ticket. Your compliance documents can be the key that gets you a seat at the table.

There's also a reputational dimension. An AI scandal — a biased algorithm, a leaked dataset, an unexplainable decision — can damage a brand for years. A transparent, documented, and traceable AI practice is the best insurance against such crises. I recommend seeing compliance not as a cost line but as a resilience investment. In a crisis, the inventory and documentation steps you take today will be your lifeline.

Finally, let's turn our gaze to the local horizon too. Turkey does not currently have a comprehensive AI law on the scale of the EU AI Act; but KVKK's generative-AI guide, the digital-transformation work under the Presidency, and steps taken by sectoral regulators (especially on the finance side) show that a governance skeleton is slowly forming. My expectation is that, just as KVKK followed GDPR, Turkey's AI regulation will draw serious inspiration from the EU AI Act.

What does this mean? The preparation you do today for the EU AI Act will largely serve you tomorrow when Turkish regulation arrives. So "preparing for the EU" is really "preparing for the future." Rather than advancing on two fronts, it's far smarter to build one solid compliance infrastructure and adapt it to both frameworks. I call this the "build once, use many times" approach. A solid model inventory, clean documentation discipline, and a clear governance structure form your foundation no matter which regulation arrives.

When I look at this whole picture, I see 2 August 2026 less as an exam day and more as a turning point. The difference between companies that take AI seriously, extract value from it, yet act responsibly, and companies just getting by, will become clear precisely after this date. Build your inventory, collect your provider documentation, classify your use, and assign governance ownership today. These steps may sound modest, but they'll carry you a meaningful step ahead — before the regulator and in the market alike — and, most importantly, prove that you are an organization using AI not with fear but with maturity.