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

TL;DR — On August 2, 2026, the European Commission's supervision and enforcement powers over general-purpose AI (GPAI) providers become applicable. GPAI obligations have technically existed since August 2, 2025, but the Commission's power to request documentation, run evaluations, demand measures, and impose fines only activates now. The ceiling is serious: up to 3% of global annual turnover or EUR 15 million, whichever is higher (Article 101). On June 16, 2026, the European Parliament pushed most high-risk obligations to December 2027 and August 2028 — but the Article 50 transparency duties (chatbot disclosure, AI-content marking, deepfake labeling) were NOT delayed. Below I walk through the provider-vs-deployer distinction, the GPAI Code of Practice, the training-data-summary and copyright duties, and a concrete compliance checklist for Turkish companies, drawn from what I see in the field.

The question I get most often in the field lately is this: "We're in Turkey, why should the EU AI Act concern us?" I heard it from the IT manager of a textile exporter and from a SaaS founder in Istanbul. My answer is always the same: the regulation looks at the market, not the border. If your product or model reaches the EU market, you're in scope, no matter where you're headquartered. Just like GDPR, the decisive question is not "where are you established" but "whom do you serve."

August 2, 2026 is therefore a turning point. We move from a period where the text sat on paper to one where the Commission can actually knock on the door. From what I see, most companies in Turkey still treat the AI Act as a "2027-2028 problem." But on the GPAI front, the clock has already started. I'm writing this not to create panic, but to make concrete what you should actually do over the next 12 months.

The AI Act phases in over time, and most of the confusion in the field comes from exactly that staggering. So let's lay down a clear schedule first.

Date	What happens
Aug 1, 2024	The AI Act entered into force
Feb 2, 2025	Prohibited practices (unacceptable risk) and AI-literacy duties began
Aug 2, 2025	GPAI provider obligations took effect; governance (AI Office) established
Aug 2, 2026	The Commission's supervision and enforcement powers over GPAI become applicable
Aug 2, 2027	Deadline for GPAI models placed on the market before Aug 2, 2025 to become compliant
Dec 2027 / Aug 2028	The June 16, 2026 amendment pushed most high-risk obligations to these dates

The most critical row is the middle one. GPAI duties existed on paper for a year but had no teeth behind them. From August 2, 2026, those teeth are fitted. The "obligations existed but nobody enforced them" era ends.

Let's be concrete, because "enforcement is coming" stays abstract on its own. Through the AI Office, the Commission gains these powers:

• Request documentation and information: It can ask a provider for technical documentation, model cards, information about training processes, and risk assessments. This will be the most frequently used power.
• Conduct evaluations: Through independent experts, it can test a model and run red-teaming. This will be more intensive for models with systemic risk.
• Request measures: It can demand compliance, risk mitigation, and if necessary a market restriction, recall, or withdrawal of the model.
• Impose fines: Under Article 101, the ceiling for GPAI providers is 3% of global annual turnover or EUR 15 million, whichever is higher.

These powers apply, as a rule, to all GPAI providers, not only the large "systemic risk" models. Models above the systemic-risk threshold (roughly, flagship models trained with very high compute) carry extra obligations; but the basic transparency and documentation duties bind every GPAI provider.

The biggest misconception I see in the field: people assume the fines are only for giants like OpenAI, Google, or Anthropic. The truth is that if you take an open-weight model, fine-tune it, and offer it to the EU market under your own brand, you may cross into "provider" status under certain conditions. Let me unpack that in the next section, because that's the real crux for Turkish companies.

The entire obligation architecture of the AI Act shifts depending on where you sit in the chain. There are two core roles, and the difference determines which duties fall on you.

Provider: The party that develops a GPAI model, or has it developed, and places it on the market under its own name or brand. Labs that train models from scratch fall here. But note: if you take someone else's model, make a substantial modification (e.g., significant retraining, architectural change, major fine-tuning), and offer it under your own brand, you may be considered a provider with respect to that modification.

Deployer: The party that uses the model in its own business processes — for example, a bank using an off-the-shelf model in its customer-service bot. Deployer duties are lighter than provider duties, but not zero — especially transparency (Article 50) and, in high-risk uses, human-oversight duties.

Most Turkish companies relax at first, thinking "we just use it, we're deployers." But the real picture I see is more complex:

• A software company that fine-tunes an open-source model on its own data and sells it to European customers as "our AI product" — high risk of sliding into provider responsibility.
• A startup calling a model via API, adding its own layer, and offering it as SaaS in Europe — mostly a deployer with respect to the model, but the AI system they offer creates other duties (especially transparency).
• A company using a model purely internally, never touching the EU market — largely outside the GPAI front of the AI Act, but don't forget the KVKK side.

My field advice is clear: settle your role with a legal opinion, not an assumption. "We're probably deployers" won't help you in an audit.

The GPAI Code of Practice, published around August 2, 2025, is a voluntary tool but extremely practical. Why does it matter? Because compliance with it was positioned as the easiest way to demonstrate that you meet your obligations — a kind of "safe harbor" logic. The Code runs on three main pillars:

1. Transparency: Preparing a standardized documentation set (model-card-like); explaining the model's capabilities, limits, and intended use.
2. Copyright: Adopting a policy to comply with EU copyright law; respecting the "opt-out" rights in the text-and-data-mining (TDM) exceptions.
3. Safety and security: Only for models with systemic risk — assessing, mitigating, and reporting systemic risks.

My recommendation: if you build your own model or do substantial fine-tuning, use the Code as a checklist. Even if you don't sign it, its documentation templates will make your life significantly easier when an audit arrives.

This is the most misread aspect of the June 16, 2026 amendment. Yes, Parliament pushed most high-risk obligations to December 2027 and August 2028. But the Article 50 transparency duties stayed outside that delay. They were not postponed; they are in force.

In practice, Article 50 requires:

• Chatbot disclosure: Users must know they are interacting with an AI system. Creating the impression that "there's a human here" is not allowed; the bot must clearly be identified as a bot.
• AI-content marking: Text, images, audio, and video generated by AI must be marked in a machine-readable way (e.g., watermark / metadata).
• Deepfake labeling: Synthetic content resembling real persons, places, or events must be clearly labeled as "artificially generated/manipulated."

These directly concern Turkish companies, because the first AI product most companies push into Europe is exactly a chatbot or a content-generation tool. The most-skipped point I see is deepfake and synthetic-content labeling — marketing teams generate AI visuals but never think about the marking step. It looks like low-hanging fruit, but it will be one of the first things an audit checks.

Another frequent question: "We started using a model before 2025 — are we retroactively liable?" The answer is nuanced. For GPAI models placed on the market before August 2, 2025, the compliance deadline is August 2, 2027 — a two-year transition window for their providers. This indirectly affects you as a user too: you must be sure your supplier will become compliant by that date. I recommend adding this as a commitment in your contracts.

It would be a big mistake to skip the Turkey side when discussing the AI Act. KVKK (the Turkish Data Protection Authority) recently published two important guides, and I always put them on the table in the field:

• Generative AI Guide (Nov 24, 2025): Explains the principles to observe when processing personal data in generative AI systems — data minimization, the duty to inform, purpose limitation, automated decision-making.
• Agentic AI Guide (Mar 12, 2026): Addresses responsibility, auditability, and human oversight in autonomous agent systems that make decisions and act.

These guides are not binding legislation; they are guidance reflecting the Authority's expectations and interpretation. But my experience is this: when the Authority publishes a guide, it largely draws the frame of future audits. What is "advice" today becomes a de facto expectation tomorrow. So treat these two guides not as "optional reading" but as part of your compliance roadmap.

When we overlay the two frameworks, the picture is this: the AI Act is oriented around product safety and market access; KVKK around personal data protection. For a Turkish company selling into Europe, both apply at once. The AI Act asks for transparency; KVKK asks for a lawful basis and a duty to inform. The good news: the two frameworks largely overlap. Build proper governance once, and you cover most of both sides.

Now to the most practical part. I've ordered the steps below the way I hand them to the teams I work with. You can spread this over 12 months, but the right time to start is now.

1. Scope assessment (do this month).

• Do you touch the EU market? Are your customers, users, or data subjects in the EU?
• What is your role in the chain: provider, deployer, or both depending on context?
• Which models do you use, and are they GPAI? Build an inventory.

2. Role clarification (get a legal opinion).

• If you fine-tune, assess whether you cross the "substantial modification" threshold.
• If you offer under your own brand, put the provider-responsibility risk on the table.

3. Prepare your documentation set.

• Create a model card for each model you use/develop: capabilities, limits, intended use, known risks, evaluation results.
• If you're a provider, prepare technical documentation and the training data summary — following the template published by the AI Office.
• Put your copyright policy in writing; document how you manage TDM opt-out processes.

4. Turn on transparency controls today (Article 50 was not delayed).

• Add an "you are talking to an AI" disclosure to your chatbots.
• Put machine-readable marking on all AI-generation flows.
• Get marketing and content teams to adopt a deepfake / synthetic-media labeling process.

5. Stand up an incident-reporting process.

• Define an internal process to detect and report serious incidents and malfunctions.
• Write down who reports what, in what timeframe, to whom. In an audit, you should be able to answer "do you have a process?" with "yes, right here."

6. Appoint an EU authorized representative.

• GPAI providers not established in the EU must appoint an authorized representative within the Union. If you offer a model into Europe, solve this early; last-minute appointments cause contractual delays.

7. Update your contracts.

• Add compliance commitments and documentation-sharing clauses to upstream (model provider) contracts.
• Clarify role and responsibility allocation in customer contracts.

8. Don't forget the AI-literacy duty.

• In force since February 2025, this duty requires your staff to use AI systems with sufficient understanding. A simple, regular training program covers it.

I keep seeing the same mistakes across different companies. Let me share them so you don't fall in:

• The "we're in Turkey, out of scope" comfort. In market-based regulation, geography won't save you. If you sell to Europe, you're in scope.
• Misreading the delay news. Seeing "high-risk systems delayed" and hearing "everything delayed." GPAI enforcement and Article 50 transparency were not delayed.
• Deciding the role by assumption. Saying "we're probably deployers." Many fine-tuning companies slide into provider status without realizing it.
• Leaving documentation for last. A model card and training-data summary can't be produced overnight when an audit arrives. Keep them current now.
• Postponing transparency as "we'll handle it later." Yet this is the most visible and easily audited duty. If your bot doesn't identify itself as a bot, that's caught at first glance.
• Ignoring the KVKK guides. Skipping them because they're non-binding means missing the frame of future audits.

A frequent objection: "This is all cost, our budget is tight." Fair — you don't need to do it all at once. Here's how I prioritize:

Priority	Action	Why now
High	Scope and role assessment	The foundation for everything; a wrong assumption is expensive
High	Article 50 transparency controls	Not delayed, visible, easily audited, cheap
Medium	Model card and documentation	Takes time; you must start early
Medium	EU authorized representative	Critical if you're a provider; needs contractual lead time
Medium	Incident-reporting process	Building a process takes time; technical investment is small
Ongoing	AI-literacy training	Already in force; low cost, high protection

Use this table as a starting roadmap. Clear the two high-priority rows over the next few weeks; spread the rest across quarters.

GPAI duties have a heightened layer too: models carrying "systemic risk." This category roughly targets flagship models trained with very high compute. Once scale crosses a threshold, the model is deemed capable of affecting not just individual users but broad societal systems. Their providers additionally owe:

• Model evaluation and red-teaming: Testing capabilities and risks with standardized protocols, running adversarial tests.
• Systemic risk assessment and mitigation: Assessing broad-impact risks (misuse, biosecurity, cybersecurity, disinformation) and taking mitigating measures.
• Serious-incident tracking and reporting: Reporting serious incidents to the AI Office and relevant national authorities.
• Cybersecurity protection: Adequately protecting model weights and infrastructure.

The vast majority of companies in Turkey don't train models at this scale from scratch, so this extra layer won't bind most of you directly. But it concerns you indirectly: if the provider of the flagship model you use is subject to these duties, the safety documentation and evaluation results it publishes become inputs to your own risk assessment. So instead of saying "it's not my model," request those documents from your supplier and put them in your file. Being able to answer "how did you assess this risk?" by pointing to the provider's published evaluation makes your life much easier in an audit.

For concreteness, here's an anonymized example. Last period I worked with an Istanbul-based team selling invoice and expense-management software to European SMEs. They'd added a "smart assistant" to their product: users ask questions in natural language, the assistant calls an off-the-shelf large language model via API and summarizes invoices. In the first session, the team's opening line was classic: "We don't train the model, we only use it."

Together we followed these steps:

1. Scope: Most customers were in Germany and the Netherlands. They were in the EU market; scope was clear.
2. Role: They didn't modify the model, only called it. They were a deployer with respect to the model. But the assistant they offered was an "AI system," which triggered the Article 50 transparency duty.
3. First gap: The assistant didn't identify itself as AI. We added a clear "This assistant is powered by AI" disclosure to the interface. Half a day's work.
4. Second gap: The assistant occasionally produced synthetic charts in its summaries; these needed marking. We added generation labels to the metadata.
5. KVKK layer: Invoice data contained personal data. We reviewed the disclosure text and minimization of data sent to the model; we set a masking rule for sensitive fields before they reach the model.
6. Contract: We added the provider's AI Act compliance commitment and documentation sharing to their contract with the model provider.

None of this was a panic-inducing giant project; it was a few weeks of focused work. My takeaway: for the early-moving company, AI Act compliance is not a burden but an opportunity to build order. For the late company, the same work gets done under audit pressure and at higher cost.

Let me briefly answer the questions that keep coming up in the field:

• "Are we exempt if we use open-source models?" No. There are some exceptions for open-source/open-weight models, but systemic-risk and basic transparency duties don't disappear. And if you fine-tune and offer under your brand, you may slide into provider responsibility.
• "We only use it internally, we don't sell to Europe." Then you're largely outside the GPAI front of the AI Act. But your KVKK duties continue; even in internal use, if you process personal data you need a disclosure and a lawful basis.
• "Will fines really be imposed, or stay on paper?" GDPR experience showed that even if the first year leans on warnings and guidance, the penalty mechanism works. Aim for documented compliance rather than waiting for a fine.
• "We're a small startup, does it apply to us too?" Regardless of scale, if you're in scope the obligation applies. Good news: at small scale, documentation and transparency controls can be set up cheaply.
• "Who prepares the model card, legal or technical?" Both together. The technical team writes capabilities and limits; legal adds compliance and liability language. Leave it to one alone and it comes out incomplete.

Suppose one day a request for information arrives from the AI Office or a competent national authority. The biggest mistake I see in the field is answering such a letter in a panic and in scattered fashion. Yet for a prepared company this is not a crisis, just a matter of opening the file and presenting it. The first-contact reflex I recommend:

• Read the request correctly. What is being asked: documentation, an evaluation of a specific model, or an explanation of an incident? Don't draft an answer before you clearly understand the scope.
• Note the deadline. Such requests carry a response window. Set the calendar on day one and assign an owner internally.
• Open your role file. If you have already clarified "are we a provider or a deployer?" with a legal opinion, half the answer is already prepared.
• Present the model card and inventory. A current model card, training-data summary, and model inventory cover most of the request in a single folder.
• Speak with one voice. Let a single person coordinate between technical, legal, and management; conflicting information reaching the authority is the worst-case scenario.
• Keep records. What was asked, what you answered, which documents you shared — archive all of it with dates. If a dispute arises later, this record protects you.

Once you turn this reflex into a procedure, the fear of audits largely disappears. Because fear usually feeds on unpreparedness. The company with an orderly file doesn't panic when the door knocks; it simply opens the cabinet.

The healthiest approach I see is to treat compliance not as a "fear project" but as a maturity signal. Your European customer will ask "are you AI Act compliant?" — many already do. Being able to answer with a clear, documented "yes" is, beyond avoiding fines, a sales advantage. A Turkish company that keeps its documentation current, labels its bot honestly, and has clarified its role may be better prepared than most of its European competitors.

Concretely, for the next 12 months: finish scope-and-role assessment and Article 50 controls this quarter. Stand up your documentation set and incident-reporting process in the third quarter. If you're a provider, run the authorized representative and training-data summary in parallel. Toward year-end, update your contracts and complete internal training. Keep this rhythm, and August 2, 2026 becomes not a crisis but merely a marked day on the calendar — and you'll have passed the real maturity test long before any audit arrives.