# EU AI Act GPAI Zorunlulukları 2 Ağustos 2026'da Yürürlükte: Model Sağlayıcılar ve Fine-Tune Edenler İçin Uyum Rehberi

> Source: https://sukruyusufkaya.com/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 zorunlulukları 2 Ağustos 2026'da yaptırıma geçiyor. Model sağlayıcılar ve fine-tune edenler için teknik dokümantasyon, telif, veri özeti ve KVKK uyum rehberi.

**TL;DR —** 2 Ağustos 2026, EU AI Act tarihinde sessiz ama çok kritik bir eşik: Komisyon'un genel amaçlı yapay zeka (GPAI) model sağlayıcılarına karşı denetim ve yaptırım yetkileri fiilen devreye giriyor. GPAI yükümlülükleri aslında 2 Ağustos 2025'ten beri yürürlükteydi; ama sağlayıcılara bir yıllık uyum penceresi tanınmıştı. O pencere şimdi kapanıyor. Bu yazıda GPAI sağlayıcısının kim olduğunu, teknik dokümantasyon ile eğitim verisi özeti yükümlülüğünü, sistemik risk eşiğini (10^25 FLOP), 15 milyon avro / küresel cironun %3'ü para cezası tavanını ve en önemlisi bir açık kaynak modeli fine-tune eden Türk şirketinin ne zaman "sağlayıcı" konumuna düştüğünü sahadan örneklerle anlatıyorum.

## Neden bu tarih Türkiye'deki ekipleri de ilgilendiriyor?

İlk tepki genellikle şu oluyor: "Biz Türkiye'deyiz, EU AI Act bizi bağlamaz." Bu, sahada gördüğüm en pahalı yanılgılardan biri. AI Act'in kapsamı coğrafi değil, pazar temelli. Yani bir modelin çıktısı Avrupa Birliği içinde kullanılıyorsa, o modeli sağlayan ya da devreye alan aktör — nerede olursa olsun — düzenlemenin kapsamına girebiliyor. Almanya'ya yazılım ihraç eden, Hollanda'daki bir müşteriye SaaS satan, ya da Avrupa'daki kullanıcılara hitap eden bir chatbot işleten bir Türk şirketi bu kapsamın tam içinde.

İkinci mesele daha inceliklidir. Çoğu kişi AI Act'i "yüksek riskli sistemler" ve "yasaklı uygulamalar" ekseninde düşünür. Oysa 2 Ağustos 2026'da devreye giren şey farklı bir katman: genel amaçlı yapay zeka modellerine ilişkin özel rejim. Bu rejim, GPT benzeri temel modelleri "sağlayan" aktörlere doğrudan yükümlülük getiriyor. Ve "sağlamak" kelimesinin AI Act'teki tanımı, çoğu mühendisin sandığından çok daha geniş.

> Sahadan bir gözlem: 2025'in ikinci yarısında konuştuğum kurumsal ekiplerin çoğu, açık ağırlıklı (open-weight) bir modeli alıp kendi verisiyle fine-tune ettiğinde "biz sadece kullanıcıyız" diye düşünüyordu. Oysa belirli koşullarda bu fine-tune işlemi sizi yeni bir GPAI sağlayıcısı konumuna taşıyabiliyor. Bu ayrımı bilmemek, uyum planınızı baştan yanlış kurmanıza yol açar.

## GPAI nedir ve 2 Ağustos 2026'da tam olarak ne değişti?

Genel amaçlı yapay zeka modeli (general-purpose AI model, GPAI), AI Act'in tanımına göre büyük miktarda veriyle, kendi kendine denetimli (self-supervised) yöntemlerle eğitilmiş, geniş bir görev yelpazesinde yetkinlik gösteren ve çok sayıda alt (downstream) sisteme entegre edilebilen modeldir. Pratikte bunlar bildiğimiz büyük dil modelleri, çok kipli (multimodal) modeller ve görüntü üretim modelleridir.

Yükümlülükler zaten 2 Ağustos 2025'te yürürlüğe girmişti. Değişen şey **yaptırım**tır. 2 Ağustos 2026'dan itibaren Avrupa Komisyonu, GPAI sağlayıcılarına karşı şu yetkileri fiilen kullanabilir hale geliyor:

- **Belge ve bilgi talep etme:** Sağlayıcıdan teknik dokümantasyonu, eğitim verisi özetini ve uyum kanıtlarını isteme.
- **Değerlendirme yapma:** Modelin bağımsız değerlendirmesini yürütme veya yürütülmesini talep etme.
- **Önlem talep etme:** Uyum sağlanması, riskin azaltılması, gerekirse modelin pazardan geri çekilmesi ya da geri çağrılması.
- **Para cezası kesme:** GPAI ihlalleri için azami ceza 15 milyon avro veya küresel yıllık cironun %3'ü — hangisi yüksekse.

Yani bir yıl önce "kağıt üzerinde" var olan yükümlülükler, artık gerçek bir icra mekanizmasına kavuşuyor. Bu, "önce uyarı, sonra ceza" mantığının başladığı an.

## Sistemik risk eşiği: 10^25 FLOP neden önemli?

AI Act, GPAI modellerini ikiye ayırıyor: sıradan GPAI modelleri ve **sistemik risk taşıyan** GPAI modelleri. Bir model, eğitiminde kullanılan toplam hesaplama miktarı 10^25 kayan nokta işlemini (FLOP) aştığında sistemik risk taşıdığı varsayılıyor. Bu eşik, en büyük temel modelleri hedefliyor; sıradan bir kurumsal fine-tune bu eşiğin çok altında kalır.

Sistemik risk taşıyan modeller için ek yükümlülükler var: model değerlendirmesi (adversarial testing dahil), sistemik risklerin belgelenmesi ve azaltılması, ciddi olayların (serious incidents) Komisyon'a raporlanması ve yeterli siber güvenlik korumasının sağlanması. Türkiye'deki çoğu ekip sistemik risk kategorisine girmeyecek — ama bu eşiğin nerede olduğunu bilmek, "biz de kapsamda mıyız?" sorusunun ilk süzgecidir.

| Kategori | Kim girer? | Temel yükümlülükler |
|---|---|---|
| Sıradan GPAI | Çoğu temel model sağlayıcısı ve belirli fine-tune edenler | Teknik dokümantasyon, telif politikası, eğitim verisi özeti, downstream bilgilendirme |
| Sistemik riskli GPAI | 10^25 FLOP üstü en büyük modeller | Yukarıdakiler + model değerlendirme, sistemik risk yönetimi, olay raporlama, siber güvenlik |
| Açık kaynak istisnası | Belirli açık lisanslı modeller | Bazı dokümantasyon yükümlülükleri hafifler; ama telif ve eğitim verisi özeti kalır |

## Dört temel yükümlülük: sahada ne anlama geliyor?

**1. Teknik dokümantasyon.** Modelin mimarisi, parametre sayısı, eğitim ve test süreçleri, değerlendirme sonuçları ve tasarım seçimleri belgelenmeli. Bu, bir denetimde ilk istenecek şeydir. Sahada gördüğüm en yaygın eksik: ekipler modeli üretime alıyor ama "bu modeli nasıl eğittik, hangi kararları neden verdik" dokümantasyonunu hiç tutmuyor. Denetim geldiğinde geriye dönük yazmak hem pahalı hem güvenilmezdir.

**2. Telif hakkı uyum politikası.** Sağlayıcı, AB telif hukukuna — özellikle metin ve veri madenciliği (TDM) istisnasındaki opt-out haklarına — uyduğunu gösteren bir politika oluşturmak zorunda. Yani eğitim verisi toplarken hak sahiplerinin "verimi kullanma" itirazlarını dikkate aldığınızı belgelemelisiniz.

**3. Eğitim verisi özeti.** Komisyon'un yayımladığı şablona uygun olarak, modelin eğitiminde kullanılan içeriğe dair "yeterince ayrıntılı" bir özet kamuya açıklanmalı. Bu, ticari sır ile şeffaflık arasında hassas bir denge; ama tamamen atlanamaz.

**4. Downstream sağlayıcıları bilgilendirme.** Modeli entegre edecek alt geliştiricilerin, kendi AI Act yükümlülüklerini yerine getirebilmesi için gereken bilgiyi onlara sağlamalısınız. Bu, tedarik zinciri boyunca uyumun aktığı mekanizma.

## Kritik soru: Fine-tune eden Türk şirketi ne zaman "sağlayıcı" olur?

Bu, yazının kalbi. Diyelim ki bir Türk fintech'i, açık ağırlıklı bir modeli (örneğin bir Llama veya Qwen türevi) alıp kendi Türkçe finansal verisiyle fine-tune etti ve bunu Avrupa'daki müşterilerine sundu. Bu şirket GPAI sağlayıcısı mı?

Cevap "duruma göre"dir ve iki eksende düşünmek gerekir. Birincisi, yaptığınız değişiklik modelin genelliğini ve yeteneklerini önemli ölçüde değiştiriyor mu? Yüzeysel bir prompt-tuning ya da hafif bir LoRA adaptörü genellikle sizi sağlayıcı yapmaz; ama modelin davranışını esaslı biçimde dönüştüren, kayda değer hesaplama kaynağı harcayan bir yeniden eğitim sizi "modeli önemli ölçüde değiştiren" aktör konumuna taşıyabilir. İkincisi, bu modeli AB pazarında kendi adınıza sunuyor musunuz? Sunuyorsanız, en azından yaptığınız değişikliklere ilişkin kısmi dokümantasyon ve downstream bilgilendirme yükümlülükleri size geçebilir.

Pratik tavsiyem şu: fine-tune projelerinizde baştan bir "değişiklik günlüğü" tutun. Hangi temel modeli aldınız, ne kadar veriyle, hangi yöntemle (LoRA mı, tam fine-tune mu), ne kadar hesaplama harcayarak eğittiniz, hangi değerlendirmeleri yaptınız? Bu günlük hem AI Act denetiminde hem de KVKK tarafında sizi korur. Kayıt tutmayan ekip, bir yıl sonra "biz sadece kullanıcıydık" diyemez; çünkü kanıt yok.

## KVKK ile kesişim: iki katmanlı uyum

Türkiye'de faaliyet gösteriyorsanız, EU AI Act tek başına yeterli değil. KVKK'nın 2025 sonu ve 2026 başında yayımladığı üretken yapay zeka ve etken (agentic) yapay zeka rehberleri, kişisel veri boyutunu ekliyor. AI Act "model nasıl sağlanır" tarafına bakarken, KVKK "bu modelde kişisel veri nasıl işlenir" tarafına bakıyor.

İki rejim şu noktalarda kesişir: eğitim verisinde kişisel veri varsa, hem AI Act'in eğitim verisi özeti hem de KVKK'nın hukuki dayanak ve aydınlatma yükümlülüğü devreye girer. Model bir kişi hakkında karar üretiyorsa (kredi skoru, işe alım elemesi), KVKK'nın otomatik karar verme hükümleri ve AI Act'in yüksek riskli sistem yükümlülükleri üst üste biner. Bu iki katmanı ayrı ayrı yönetmeye çalışmak yerine, tek bir "AI yönetişim dosyası" altında birleştirmek çok daha sürdürülebilir.

> Sahada işe yarayan yaklaşım: Her AI projesi için tek bir uyum klasörü. İçinde veri işleme envanteri (KVKK), model dokümantasyonu (AI Act), risk değerlendirmesi (her ikisi), ve karar günlüğü. Denetim hangi kapıdan gelirse gelsin, aynı dosyayı açıyorsunuz.

## 90 günlük uyum planı: nereden başlamalı?

Uyumu bir "büyük proje" olarak görmek felç edici olabilir. Bunun yerine somut, sıralı adımlarla ilerleyin.

**İlk 30 gün — Envanter.** Hangi modelleri kullanıyorsunuz? Hangileri kendi geliştirdiğiniz/fine-tune ettiğiniz, hangileri üçüncü taraf API'si? Çıktılarınız AB pazarına ulaşıyor mu? Bu üç soruya net cevap veremeyen ekip, uyum planı yapamaz. Basit bir tabloyla başlayın: model adı, kaynağı, kullanım amacı, AB'ye dokunuyor mu, sizi sağlayıcı yapıyor mu.

**30–60 gün — Boşluk analizi.** Envanterdeki her "evet, kapsamdayız" satırı için dört yükümlülüğü (dokümantasyon, telif, veri özeti, downstream) tek tek işaretleyin: var mı, yok mu, kısmen mi? Eksikleri önceliklendirin. Genellikle en büyük boşluk teknik dokümantasyondur, çünkü kimse üretim koşuşturmasında bunu yazmaya vakit ayırmamıştır.

**60–90 gün — Doldurma ve süreçleştirme.** Eksik dokümantasyonu üretin, telif politikanızı yazın, eğitim verisi özetini hazırlayın. Ama daha önemlisi: bunu bir defalık iş değil, sürekli bir süreç haline getirin. Her yeni model sürümünde otomatik güncellenen bir dokümantasyon şablonu, bir yıl sonra sizi kurtarır.

## Yaygın hatalar ve bunlardan nasıl kaçınılır

**"Ceza kesilmez, ilk yıl sadece uyarı olur" varsayımı.** Doğru olabilir, ama üzerine strateji kurulacak bir zemin değil. Komisyon'un yaptırım yetkisi artık aktif; bir ciddi olay veya bir şikâyet, sizi hızla incelemenin odağına taşıyabilir. Uyumu "ceza gelirse yaparız" mantığıyla ertelemek, teknik dokümantasyonu geriye dönük üretmenin maliyetini göz ardı eder.

**Açık kaynak istisnasını abartmak.** Evet, belirli açık lisanslı modeller için dokümantasyon yükümlülükleri hafifler. Ama telif uyumu ve eğitim verisi özeti gibi çekirdek yükümlülükler açık kaynakta da kalabilir; ayrıca sistemik risk taşıyan modeller için istisna tümüyle geçerli değil. "Açık kaynak kullanıyoruz, o yüzden muafız" cümlesi tehlikeli bir basitleştirmedir.

**Uyumu hukuk ekibine tek başına yıkmak.** AI Act uyumu teknik ve hukuki bir kesişimdir. Teknik dokümantasyonu ancak modeli eğiten mühendis doğru yazabilir; hukuki yorumu ancak danışman yapabilir. İki taraf ayrı çalışırsa, dokümantasyon ya çok teknik ya çok yüzeysel olur. En iyi sonucu, mühendis ve hukukçunun aynı masada oturduğu ekiplerde gördüm.

## Gerçek bir denetim nasıl işler: adım adım senaryo

Soyut yükümlülükler yerine somut bir senaryo düşünelim. Diyelim ki Avrupa'daki bir kullanıcı, sizin modelinizin ürettiği bir çıktıdan zarar gördüğünü öne sürerek ulusal yetkili otoriteye şikâyette bulundu. Ya da bir sivil toplum kuruluşu, modelinizin eğitim verisinde telifli içerik kullanıldığını iddia etti. Bu, denetim zincirini tetikleyen tipik başlangıç noktasıdır.

İlk adım genellikle bir **bilgi talebidir**: Komisyon veya AI Office, sizden teknik dokümantasyonu, eğitim verisi özetini ve telif politikanızı belirli bir süre içinde iletmenizi ister. Bu talebe yanıt veremeyen ya da geç yanıt veren şirket, daha en baştan iş birliği yapmayan aktör konumuna düşer. Burada kritik olan şudur: dokümantasyon zaten hazırsa bu adım rutin bir dosya paylaşımıdır; hazır değilse, günler süren bir panik ve geriye dönük üretim maratonuna dönüşür.

İkinci adım bir **değerlendirme** olabilir. Modelinizin gerçekten iddia edildiği gibi davranıp davranmadığı bağımsız olarak test edilebilir. Sistemik risk taşıyan modellerde bu neredeyse kesindir; sıradan modellerde ise şikâyetin ciddiyetine bağlıdır. Değerlendirme sonucunda bir uyumsuzluk tespit edilirse, üçüncü adım **düzeltici önlem talebidir**: belirli bir süre içinde uyum sağlamanız, riski azaltmanız ya da gerekirse modeli pazardan çekmeniz istenir.

Para cezası bu zincirin sonundaki en ağır araçtır ve genellikle iş birliğinden kaçınan, tekrarlayan ya da ciddi ihlaller için saklanır. Ama şunu unutmayın: cezanın kesilip kesilmemesinden bağımsız olarak, bir denetimin kendisi bile ciddi bir zaman ve itibar maliyetidir. Denetimi "kazanmanın" en ucuz yolu, dosyanızın baştan hazır olmasıdır.

## Dokümantasyonu otomatikleştirmek: bir mühendislik pratiği

Uyumu sürdürülebilir kılan şey, dokümantasyonu insan iradesine bırakmamaktır. Sahada en iyi çalışan yaklaşım, model kartı (model card) üretimini eğitim ve dağıtım hattınıza (pipeline) gömmektir. Her yeni model sürümü çıktığında, sistem otomatik olarak şu bilgileri toplar: kullanılan temel model ve sürümü, eğitim veri kümesinin kaynağı ve boyutu, kullanılan hesaplama miktarı, değerlendirme metrikleri, ve bilinen sınırlamalar.

Bunu bir "model kaydı" (model registry) ile birleştirdiğinizde, her üretim modelinin arkasında izlenebilir bir soyağacı (lineage) oluşur. Bir denetçi "bu modeli nasıl eğittiniz?" diye sorduğunda, cevap manuel bir hatırlama çabası değil, sistemden çekilen bir rapordur. Bu aynı zamanda iyi MLOps pratiğidir; yani AI Act uyumu, zaten yapmanız gereken mühendislik disiplinini zorunlu kılmaktan başka bir şey yapmıyor.

Türkçe bağlamında ek bir incelik var: eğitim verinizde Türkçe kişisel veri bulunuyorsa, model kartınızın KVKK tarafını da beslemesi gerekir. Yani aynı otomatik kayıt, hem AI Act'in eğitim verisi özetini hem de KVKK'nın veri işleme envanterini besleyebilir. Tek kaynaktan iki uyum çıktısı üretmek, iki ayrı süreç yürütmekten çok daha ucuzdur.

## GPAI Uygulama Kuralları ve gönüllü uyum yolu

AI Act, GPAI sağlayıcılarına yükümlülüklerini yerine getirdiklerini göstermenin bir yolu olarak **Uygulama Kuralları'na (Code of Practice)** uymayı öneriyor. Bu kurallar, yasanın soyut hükümlerini pratik, denetlenebilir adımlara çeviren bir rehber niteliğinde. Uygulama Kuralları'na uyduğunuzu göstermek, uyumunuzu kanıtlamanın en pürüzsüz yoludur; çünkü otorite bu çerçeveyi zaten bir referans olarak kabul ediyor.

Gönüllü uyum yolunun bir başka avantajı, belirsizliği azaltmasıdır. Yasa metni "yeterince ayrıntılı özet" gibi yoruma açık ifadeler içerir; Uygulama Kuralları ise bunun pratikte ne anlama geldiğini somutlaştırır. Kendi başınıza yasa metnini yorumlamaya çalışmak yerine, bu çerçeveyi izlemek hem daha güvenli hem daha az emek gerektirir. Türkiye'deki ekiplere tavsiyem, bu kuralları erken benimsemek ve iç süreçlerini bu çerçeveye göre kurmaktır.

## Sözleşmelerinizi gözden geçirin: tedarikçi ve müşteri tarafı

Uyum yalnızca teknik bir mesele değil, aynı zamanda sözleşmesel bir meseledir. İki yönü var. Birincisi, **tedarikçi tarafı**: eğer üçüncü taraf bir GPAI modelini (bir API'yi ya da açık ağırlıklı bir modeli) kullanıyorsanız, sağlayıcının size gereken dokümantasyonu ve downstream bilgisini vermekle yükümlü olduğunu sözleşmede netleştirin. Sağlayıcının uyumsuzluğu, sizin de zincirde uyumsuz kalmanıza yol açabilir.

İkincisi, **müşteri tarafı**: eğer siz bir modeli başkalarına sunuyorsanız, kendi downstream yükümlülüklerinizi sözleşmeye yansıtın. Müşterileriniz modelinizi yüksek riskli bir uygulamada kullanacaksa, onlara gereken bilgiyi sağlamak sizin sorumluluğunuz. Bu bilgiyi vermeyi ihmal ederseniz, müşterinizin uyumsuzluğu size de geri döner.

Sahada gördüğüm en büyük sözleşmesel boşluk, "AI tedarik zinciri" kavramının hiç düşünülmemiş olması. Şirketler yıllardır yazılım lisanslama sözleşmeleri imzalıyor ama bu sözleşmelerin çoğu AI Act'in getirdiği bilgi akışı yükümlülüklerini hiç içermiyor. Mevcut sözleşmelerinizi bu gözle yeniden okumak, düşük maliyetli ama yüksek etkili bir uyum adımıdır.

## Sık sorulan sorular

**"Sadece ChatGPT API'si kullanıyoruz, biz sağlayıcı mıyız?"** Hayır, bir API'yi tükettiğinizde model sağlayıcısı OpenAI olur, siz değil. Ama siz bu API'yi kendi ürününüze gömüp AB'ye sunuyorsanız, "deployer" (devreye alan) sıfatıyla başka yükümlülükler size geçebilir — özellikle uygulamanız yüksek riskli bir kategoriye giriyorsa. Sağlayıcı olmamanız, kapsamın tümüyle dışında olduğunuz anlamına gelmez.

**"Modeli sadece iç kullanım için fine-tune ettik, AB'ye sunmuyoruz."** Bu durumda GPAI sağlayıcısı yükümlülükleri büyük ölçüde devreye girmez, çünkü modeli pazara sunmuyorsunuz. Ama modelin çıktısı dolaylı yoldan AB'deki bir kullanıcıya ulaşıyorsa (örneğin AB'deki bir müşteriye rapor üretiyorsa) bu değerlendirme değişebilir. "İç kullanım" tanımı göründüğünden daha kaygandır.

**"Küçük bir startup'ız, bu yük bizim için çok ağır."** AI Act, sağlayıcının büyüklüğüne göre bazı esneklikler ve orantılılık ilkeleri içeriyor; ama temel yükümlülükler küçük şirketler için de geçerli. İyi haber şu ki, iyi mühendislik pratiği zaten bu yükümlülüklerin çoğunu karşılıyor. Küçük bir ekip için en akıllıca yol, uyumu baştan hafif ve otomatik süreçlerle kurmak — büyüdükçe geriye dönük düzeltmenin maliyeti katlanarak artar.

## Somut eylem listesi

Bu düzenlemeyi bir tehdit değil, bir olgunluk fırsatı olarak görmenizi öneririm. Kaliteli teknik dokümantasyon, temiz eğitim verisi kaydı ve şeffaf bir model günlüğü zaten iyi mühendisliğin işaretleri. AI Act sadece bunları zorunlu hale getiriyor.

Bugün yapabileceğiniz üç şey: Birincisi, kullandığınız tüm modellerin bir envanterini çıkarın ve her biri için "AB'ye dokunuyor mu, beni sağlayıcı yapıyor mu?" sorusunu yanıtlayın. İkincisi, aktif fine-tune projelerinizde bugünden bir değişiklik günlüğü tutmaya başlayın — geriye dönük yazmak her zaman daha pahalıdır. Üçüncüsü, KVKK ve AI Act'i tek bir yönetişim dosyasında birleştirin; iki ayrı süreç yürütmek hem maliyetli hem hatalıdır. Bu üç adımı atan ekip, 2 Ağustos sonrası bir bilgi talebi geldiğinde panik yerine dosyayı açıp yanıt verebilir.


## Belge ve kanıt saklama: ne kadar süre, hangi formatta?

Uyum dokümantasyonunu üretmek kadar onu saklamak da önemli. AI Act, sağlayıcıların teknik dokümantasyonu belirli bir süre erişilebilir tutmasını bekliyor; bir denetim, modelin piyasaya sürülmesinden yıllar sonra bile gelebilir. Bu yüzden dokümantasyonu "üretip unutulan bir dosya" değil, sürümlenen ve arşivlenen canlı bir varlık olarak düşünmek gerekir.

Pratikte gördüğüm en sağlıklı yapı şu: her model sürümü için ayrı bir dokümantasyon anlık görüntüsü (snapshot). Yani modelinizin 1.0, 1.1, 2.0 sürümlerinin her biri kendi teknik dokümantasyonu, kendi eğitim verisi özeti ve kendi değerlendirme sonuçlarıyla birlikte arşivlenir. Bir denetçi "1.0 sürümünde ne yaptınız?" diye sorduğunda, o dönemin dosyasını açabilmelisiniz. Sadece en güncel sürümün dokümantasyonunu tutmak, geçmiş sürümlerle ilgili bir soru geldiğinde sizi savunmasız bırakır.

Format konusunda esneklik var ama tutarlılık şart. Dokümantasyonunuzu makine tarafından okunabilir ve aranabilir bir yapıda (örneğin yapılandırılmış metin ya da versiyon kontrolündeki dosyalar) tutarsanız, hem denetime yanıt vermek hem de iç ekiplerin bilgiye ulaşması kolaylaşır. Dağınık slaytlar ve e-posta ekleri, denetim anında en büyük düşmanınızdır.

## Rol ayrımı: sağlayıcı, devreye alan ve dağıtıcı

AI Act, aynı yapay zeka değer zincirinde birden fazla rol tanımlıyor ve her rolün yükümlülükleri farklı. Sağlayıcı (provider) modeli geliştiren ya da önemli ölçüde değiştirip pazara sunan aktör; devreye alan (deployer) modeli kendi sorumluluğu altında kullanan aktör; dağıtıcı ve ithalatçı ise modeli AB pazarına taşıyan aracılar. Türkiye'deki bir şirket, projeden projeye bu rollerin herhangi birine düşebilir — hatta aynı anda birden fazlasına.

Bu ayrımı erken netleştirmek, uyum yükünüzü doğru boyutlandırmanın anahtarı. Kendinizi otomatik olarak "sağlayıcı" varsayıp aşırı hazırlık yapmak kaynak israfıdır; ama "biz sadece kullanıcıyız" diyerek tüm yükümlülükleri görmezden gelmek riskli bir kumar. Doğru yol, her projede rolünüzü açıkça belirlemek ve yükümlülükleri o role göre haritalamak. Bir tabloya her AI projenizi yazın, karşısına rolünüzü ve bu rolün getirdiği somut yükümlülükleri işaretleyin — bu basit egzersiz, çoğu belirsizliği daha başlangıçta çözer.

## Türkiye'nin kendi düzenleme yolculuğu

EU AI Act'e odaklanırken Türkiye'nin kendi yapay zeka düzenleme çerçevesini de gözden kaçırmamak gerekiyor. KVKK'nın üretken ve etken yapay zeka rehberleri, ülke içindeki beklentileri şekillendiriyor; sektörel düzenleyiciler (bankacılıkta BDDK gibi) kendi çerçevelerini kuruyor. Uzun vadede, AB ile uyumlu ama yerel bağlama uyarlanmış bir Türk yapay zeka mevzuatının olgunlaşması muhtemel.

Bu ikili gerçeklik, Türkiye'de faaliyet gösteren ekipler için aslında bir avantaja çevrilebilir. AB standartlarına göre kurulan bir uyum altyapısı, yerel düzenlemelerin çoğunu da baştan karşılar; çünkü AB çerçevesi genellikle daha ayrıntılı ve katıdır. "AB için uyumlu ol, Türkiye için otomatik hazır ol" yaklaşımı, iki ayrı sistemi paralel yürütmekten çok daha verimli. Bu yüzden uyum altyapınızı en yüksek çıtaya göre kurmanızı, sonra yerel gereksinimleri o çatının altına yerleştirmenizi öneriyorum.

## Bütçe ve ekip: uyumun gerçek maliyeti

Uyumu planlarken sık atlanan bir kalem, gerçek insan ve zaman maliyeti. Teknik dokümantasyonu yazmak, eğitim verisi özetini hazırlamak, telif politikasını oluşturmak ve tüm bunları sürdürülebilir süreçlere bağlamak; bir ya da iki kişinin birkaç haftalık odaklı çalışmasını gerektirir. Bu maliyeti önceden bütçelemek, projenin ortasında sürpriz bir yükle karşılaşmaktan çok daha iyidir.

Sahada işe yarayan model şu: uyumu tek bir kişinin omuzlarına yüklemek yerine, mühendislik ve hukuk taraflarından birer sorumlu belirlemek ve onları düzenli bir ritimde (örneğin iki haftada bir) bir araya getirmek. Bu ikili, envanteri günceller, yeni model sürümlerinin dokümantasyonunu kontrol eder ve gelen düzenleme değişikliklerini takip eder. Uyum, bir defalık bir proje değil, düşük yoğunluklu ama sürekli bir bakım işidir. Bu bakışı erken benimseyen ekipler, düzenleme değiştiğinde panik yerine rutin bir güncellemeyle yanıt verir.

Küçük ekipler için iyi haber, bu maliyetin ölçeklenebilir olması. Tek bir modelle çalışan bir startup'ın uyum yükü, yüzlerce modeli yöneten bir kurumun yükünden çok daha hafiftir. Önemli olan, ne kadar küçük olursanız olun, süreci baştan hafif ve otomatik kurmak. Elle tutulan, dağınık bir uyum süreci büyüdükçe kırılır; sisteme gömülü, otomatik bir süreç ise sizinle birlikte ölçeklenir.

Son olarak şunu hatırlatmak isterim: 2 Ağustos 2026 bir bitiş değil, bir başlangıç çizgisidir. Düzenleyici çerçeve önümüzdeki yıllarda olgunlaşmaya, netleşmeye ve muhtemelen genişlemeye devam edecek. Bugün kuracağınız temiz, otomatik ve şeffaf uyum altyapısı, yalnızca bu tarihe değil, gelecek yıllardaki tüm düzenleme dalgalarına karşı sizi hazır tutacak. Erken hareket eden ekip, uyumu bir yük değil, güven inşa eden bir rekabet avantajına dönüştürür.