# EU AI Act GPAI Obligations Enforceable from 2 August 2026: A Compliance Guide for Model Providers and Fine-Tuners

> Source: https://sukruyusufkaya.com/en/blog/eu-ai-act-gpai-zorunluluklari-2-agustos-2026
> Updated: 2026-07-22T00:06:23.473Z
> Type: blog
> Category: yapay-zeka
**TLDR:** EU AI Act GPAI obligations become enforceable on 2 August 2026. A guide to technical documentation, copyright, data summaries, and KVKK compliance for model providers and fine-tuners.

**TL;DR —** August 2, 2026 is a quiet but critical threshold in EU AI Act history: the Commission's supervision and enforcement powers against general-purpose AI (GPAI) model providers become operational. GPAI obligations have technically been in force since August 2, 2025, but providers were given a one-year adjustment window. That window is now closing. In this piece I explain who counts as a GPAI provider, the technical documentation and training-data summary obligations, the systemic-risk threshold (10^25 FLOP), the fine ceiling of €15 million / 3% of global turnover, and most importantly — when a Turkish company that fine-tunes an open-weight model crosses into "provider" status, with examples from the field.

## Why this date matters for teams in Turkey too

The first reaction is usually: "We're in Turkey, the EU AI Act doesn't bind us." This is one of the most expensive misconceptions I see in the field. The Act's scope is not geographic but market-based. If a model's output is used within the European Union, the actor providing or deploying that model — wherever they are — can fall within scope. A Turkish company exporting software to Germany, selling SaaS to a client in the Netherlands, or operating a chatbot serving European users is squarely within that scope.

The second issue is subtler. Most people think of the AI Act along the axis of "high-risk systems" and "prohibited applications." But what activates on August 2, 2026 is a different layer: the special regime for general-purpose AI models. This regime imposes direct obligations on actors who "provide" GPT-like foundation models. And the AI Act's definition of "provide" is far broader than most engineers assume.

> An observation from the field: most enterprise teams I spoke with in the second half of 2025 assumed that when they took an open-weight model and fine-tuned it on their own data, they were "just users." Yet under certain conditions, that fine-tuning can move you into the position of a new GPAI provider. Not knowing this distinction leads you to build your compliance plan wrong from the start.

## What is GPAI and what exactly changed on August 2, 2026?

A general-purpose AI model (GPAI), per the AI Act's definition, is a model trained on large amounts of data using self-supervised methods, capable across a wide range of tasks, and integrable into many downstream systems. In practice these are the large language models, multimodal models, and image-generation models we know.

The obligations already took effect on August 2, 2025. What changed is **enforcement**. From August 2, 2026, the European Commission can effectively exercise the following powers against GPAI providers: requesting documentation and information (technical documentation, the training-data summary, evidence of compliance); conducting or requiring independent evaluation of the model; requesting measures such as compliance, risk mitigation, and if necessary market withdrawal or recall; and imposing fines — the maximum penalty for GPAI breaches is €15 million or 3% of global annual turnover, whichever is higher.

So obligations that existed "on paper" a year ago now acquire a real enforcement mechanism. This is the moment the "warning first, then penalty" logic begins.

## The systemic-risk threshold: why does 10^25 FLOP matter?

The AI Act splits GPAI models in two: ordinary GPAI models and GPAI models with **systemic risk**. A model is presumed to carry systemic risk when the total compute used in its training exceeds 10^25 floating-point operations (FLOP). This threshold targets the largest foundation models; an ordinary enterprise fine-tune stays well below it.

Models with systemic risk carry extra obligations: model evaluation including adversarial testing, documenting and mitigating systemic risks, reporting serious incidents to the Commission, and ensuring adequate cybersecurity protection. Most teams in Turkey will not fall into the systemic-risk category — but knowing where that threshold sits is the first filter for "are we in scope?"

| Category | Who falls in? | Core obligations |
|---|---|---|
| Ordinary GPAI | Most foundation-model providers and certain fine-tuners | Technical documentation, copyright policy, training-data summary, downstream disclosure |
| Systemic-risk GPAI | Largest models above 10^25 FLOP | The above + model evaluation, systemic-risk management, incident reporting, cybersecurity |
| Open-source exception | Certain openly licensed models | Some documentation duties are relaxed; copyright and training-data summary remain |

## The four core obligations: what do they mean in practice?

**1. Technical documentation.** The model's architecture, parameter count, training and testing processes, evaluation results, and design choices must be documented. This is the first thing requested in an audit. The most common gap: teams ship a model to production but never keep the "how we trained this and why" documentation. Writing it retroactively is both expensive and unreliable.

**2. Copyright compliance policy.** The provider must establish a policy demonstrating compliance with EU copyright law — especially the opt-out rights under the text and data mining (TDM) exception. You must document that you honored rights-holders' objections to using their data.

**3. Training-data summary.** In line with the Commission's template, a "sufficiently detailed" summary of the content used to train the model must be made public. This is a delicate balance between trade secrets and transparency — but it cannot be skipped.

**4. Informing downstream providers.** You must supply downstream developers who integrate your model with the information they need to meet their own AI Act obligations. This is how compliance flows along the supply chain.

## The critical question: when does a Turkish fine-tuner become a "provider"?

This is the heart of the piece. Suppose a Turkish fintech takes an open-weight model (say a Llama or Qwen derivative), fine-tunes it on its own Turkish financial data, and offers it to European customers. Is this company a GPAI provider?

The answer is "it depends," along two axes. First, does the change significantly alter the model's generality and capabilities? A superficial prompt-tuning or light LoRA adapter generally does not make you a provider; but a re-training that substantially transforms behavior and spends meaningful compute can move you into "significantly modifying" territory. Second, are you offering this model on the EU market under your own name? If so, at least partial documentation and downstream-disclosure obligations regarding your changes may pass to you.

My practical advice: keep a "change log" from the start. Which base model, with how much data, by which method (LoRA or full fine-tune), spending how much compute, running which evaluations? This log protects you in both an AI Act audit and on the KVKK side. A team with no records cannot claim "we were just users" a year later — because there is no evidence.

## Intersection with KVKK: two-layer compliance

If you operate in Turkey, the EU AI Act alone is not enough. The generative-AI and agentic-AI guides KVKK published in late 2025 and early 2026 add the personal-data dimension. The AI Act looks at "how the model is provided," while KVKK looks at "how personal data is processed in it."

The two regimes intersect: if training data contains personal data, both the AI Act's training-data summary and KVKK's legal-basis and notice obligations apply. If the model produces a decision about a person (credit score, hiring screen), KVKK's automated-decision-making provisions and the AI Act's high-risk-system obligations overlap. Rather than managing these separately, merging them under a single "AI governance file" is far more sustainable.

> The approach that works: a single compliance folder per AI project — a data-processing inventory (KVKK), model documentation (AI Act), a risk assessment (both), and a decision log. Whichever door the audit comes through, you open the same file.

## A 90-day compliance plan: where to start?

**First 30 days — Inventory.** Which models do you use? Which are self-built/fine-tuned, and which are third-party APIs? Do your outputs reach the EU market? Start with a simple table: model name, source, purpose, does it touch the EU, does it make you a provider.

**30–60 days — Gap analysis.** For each "yes, we're in scope" row, mark each of the four obligations one by one: present, absent, or partial? Prioritize the gaps. Usually the biggest gap is technical documentation, because no one made time to write it in the production rush.

**60–90 days — Filling and processizing.** Produce the missing documentation, write your copyright policy, prepare the training-data summary. More importantly, make this an ongoing process. A documentation template that auto-updates with each new model version saves you a year from now.

## Common mistakes and how to avoid them

**The "no fines the first year, just warnings" assumption.** It may be true, but it's not ground for a strategy. The Commission's enforcement power is now active; a serious incident or complaint can quickly bring you into focus. Deferring compliance ignores the cost of producing documentation retroactively.

**Overstating the open-source exception.** Documentation duties are relaxed for certain openly licensed models, but core obligations like copyright compliance and the training-data summary can remain; and the exception does not fully apply to systemic-risk models. "We use open source, so we're exempt" is a dangerous oversimplification.

**Dumping compliance on the legal team alone.** AI Act compliance is a technical-legal intersection. Only the engineer who trained the model can write the technical documentation correctly; only counsel can make the legal interpretation. The best results come when engineer and lawyer sit at the same table.

## How a real audit unfolds: a step-by-step scenario

Suppose a user in Europe complains to the national competent authority, claiming harm from an output your model produced. Or a civil-society organization alleges your training data used copyrighted content. This triggers the audit chain.

The first step is usually an **information request**: submit the technical documentation, training-data summary, and copyright policy within a set period. A company that cannot respond — or responds late — is cast as non-cooperative from the outset. If documentation is already prepared, this is a routine file share; if not, it becomes a days-long marathon of panic.

The second step may be an **evaluation** — whether your model behaves as claimed can be independently tested. If a nonconformity is found, the third step is a **request for corrective measures**: achieve compliance within a set time, mitigate the risk, or withdraw the model. A fine is the heaviest tool at the end of this chain, generally reserved for non-cooperation or repeated, serious breaches. But an audit itself is a serious cost in time and reputation. The cheapest way to "win" one is to have your file ready.

## Automating documentation: an engineering practice

What makes compliance sustainable is not leaving documentation to human willpower. The best approach embeds model-card generation into your training and deployment pipeline. Whenever a new version ships, the system automatically collects the base model and version, dataset source and size, compute used, evaluation metrics, and known limitations.

Combined with a model registry, each production model gains a traceable lineage. When an auditor asks "how did you train this?", the answer is a report pulled from the system, not a manual recollection. This is also good MLOps practice — AI Act compliance merely mandates the discipline you should already have. In the Turkish context, if your training data contains Turkish personal data, the same automatic record can feed both the AI Act's training-data summary and KVKK's data-processing inventory. Two compliance outputs from one source is far cheaper than two separate processes.

## The GPAI Code of Practice and the voluntary compliance path

The AI Act suggests adhering to a **Code of Practice** as a way for GPAI providers to demonstrate compliance. It translates abstract provisions into practical, auditable steps. Showing adherence is the smoothest way to prove compliance, because the authority already accepts this framework as a reference. It also reduces uncertainty: the legal text contains interpretation-open phrases like "sufficiently detailed summary," while the Code makes concrete what that means. My advice to Turkish teams is to adopt these rules early and build internal processes around them.

## Review your contracts: supplier and customer side

Compliance is also contractual. On the **supplier side**: if you use a third-party GPAI model, make it explicit in the contract that the provider must give you the necessary documentation and downstream information. Their non-compliance can leave you non-compliant in the chain. On the **customer side**: if you offer a model to others, reflect your downstream obligations in the contract. If customers use your model in a high-risk application, providing the necessary information is your responsibility.

The biggest contractual gap I see is that the concept of an "AI supply chain" has never been considered. Companies have signed software licensing contracts for years, but most contain none of the information-flow obligations the AI Act introduces. Re-reading your existing contracts with this lens is a low-cost, high-impact step.

## Frequently asked questions

**"We only use the ChatGPT API — are we a provider?"** No; OpenAI is the model provider. But if you embed this API into your product and offer it to the EU, other obligations can pass to you as a "deployer" — especially in a high-risk category. Not being a provider does not mean you are entirely out of scope.

**"We fine-tuned only for internal use."** Then GPAI provider obligations largely do not apply, because you are not placing the model on the market. But if the output reaches an EU user indirectly, this assessment can change. "Internal use" is slipperier than it looks.

**"We're a small startup, this is too heavy."** The AI Act contains proportionality principles based on provider size, but core obligations apply to small companies too. Good engineering already satisfies most of them. Build compliance lightly and automatically from the start — retroactive correction grows exponentially with scale.

## Record retention: how long, in what format?

Producing documentation matters as much as retaining it. The AI Act expects providers to keep technical documentation accessible for a set period; an audit can arrive years after a model's release. Treat documentation not as a "produce-and-forget" file but as a versioned, archived living asset. The healthiest structure: a separate documentation snapshot per model version, so that 1.0, 1.1, 2.0 are each archived with their own documentation, training-data summary, and evaluation results. Keep it machine-readable and searchable — scattered slides and email attachments are your worst enemy during an audit.

## Role distinction: provider, deployer, and distributor

The AI Act defines multiple roles in the same value chain, each with different obligations: the provider develops or significantly modifies and places the model on the market; the deployer uses it under its own responsibility; distributors and importers move it onto the EU market. A Turkish company can fall into any of these roles project to project — sometimes several at once. Clarifying this early is the key to sizing your compliance burden correctly. Assuming you are automatically a "provider" wastes resources; ignoring all obligations as "just a user" is a risky gamble. Write each AI project into a table, mark your role and the concrete obligations it brings.

## Turkey's own regulatory journey

While focusing on the EU AI Act, don't lose sight of Turkey's own AI framework. KVKK's generative and agentic AI guides shape domestic expectations; sectoral regulators (like BDDK in banking) are building their own frameworks. Over the long term, a Turkish AI regulation that is EU-aligned but locally adapted is likely to mature. This dual reality can be turned into an advantage: compliance infrastructure built to EU standards satisfies most local requirements from the start, because the EU framework is generally more detailed and strict. "Be compliant for the EU, be automatically ready for Turkey" is far more efficient than running two parallel systems. Build your infrastructure to the highest bar, then place local requirements under that roof.

## Budget and team: the real cost of compliance

An often-missed line item is the real human and time cost. Writing technical documentation, preparing the training-data summary, creating the copyright policy, and binding all of this into sustainable processes requires a few weeks of focused work from one or two people. Budgeting for this in advance beats a surprise mid-project burden. The model that works: rather than loading compliance onto one person, name one owner each from engineering and legal and bring them together on a regular cadence (say biweekly). This pair updates the inventory, checks documentation for new versions, and tracks regulatory changes. Compliance is not a one-off project but low-intensity, continuous maintenance. For small teams the good news is that this cost scales — a single-model startup's burden is far lighter than an enterprise managing hundreds of models. Build the process lightly and automatically from the start; a hand-held, scattered process breaks as you grow, while a system-embedded one scales with you.

## A concrete action list

I suggest you see this regulation not as a threat but as a maturity opportunity. High-quality technical documentation, clean training-data records, and a transparent model log are already the marks of good engineering. The AI Act merely makes them mandatory.

Three things you can do today: First, produce an inventory of all models you use and, for each, answer "does it touch the EU, does it make me a provider?" Second, start keeping a change log today on active fine-tuning projects — retroactive writing is always more expensive. Third, merge KVKK and the AI Act into a single governance file; two separate processes are costly and error-prone. A team that takes these three steps can, when an information request arrives after August 2, open the file and respond instead of panicking. Remember: August 2, 2026 is not an end but a starting line. The regulatory framework will keep maturing and likely expanding. The clean, automatic, transparent infrastructure you build today keeps you ready for every regulatory wave to come, turning compliance from a burden into a trust-building competitive advantage.