EU AI Act GPAI Yaptırımları 2 Ağustos 2026'da Başlıyor: Türk Şirketleri İçin Ne Değişiyor?

TL;DR — 2 Ağustos 2026, Avrupa Birliği Yapay Zekâ Yasası (EU AI Act) açısından kâğıt üzerindeki kuralların gerçek yaptırıma dönüştüğü tarih. O gün itibarıyla Avrupa Komisyonu bünyesindeki AI Office, genel amaçlı yapay zekâ (GPAI — general-purpose AI) modeli sağlayıcılarının yükümlülüklerini denetleme ve ceza kesme yetkisini fiilen kullanmaya başlıyor. Cezaların tavanı küçük değil: küresel yıllık cironun %3'ü ya da 15 milyon avro, hangisi yüksekse o. Türkiye'deki birçok yönetici bunu "bizi ilgilendirmez, biz AB'de değiliz" diye geçiştiriyor. Oysa GDPR'da olduğu gibi burada da belirleyici olan coğrafya değil, pazara erişim: AB'deki kullanıcıya, müşteriye ya da iş ortağına hizmet veren her Türk şirketi kapsam içinde. Bu yazıda sahadan gözlemlerimle, hangi yükümlülüğün kimi bağladığını, "sağlayıcı" ile "dağıtıcı" ayrımının neden kaderinizi belirlediğini ve KVKK altyapınızı nasıl kaldıraç olarak kullanabileceğinizi anlatıyorum.

Danışmanlık yaptığım şirketlerde son bir yıldır aynı sahneyi defalarca yaşadım. Toplantı odasına giriyorum, "EU AI Act" diyorum, masanın etrafında ya boş bakışlar ya da "o bir Avrupa meselesi, geçen sene çıktı, bizi bağlamaz" tavrı beliriyor. İşin acı tarafı, bu rahatlığın büyük kısmı bir yanlış anlamadan besleniyor: Yasa 2024'te yürürlüğe girdi diye herkes "iş bitti, ya uyduk ya uymadık" sanıyor. Gerçek şu ki AB, bu yasayı tek seferde değil, kademeli bir takvimle devreye alıyor. Ve o takvimin en kritik durağı, GPAI sağlayıcıları için 2 Ağustos 2026.

Şunu netleştirelim: GPAI sağlayıcı yükümlülükleri aslında 2 Ağustos 2025'te yürürlüğe girdi. Ama AB, sektöre bir yıllık bir nefes alma penceresi tanıdı. Yani 2 Ağustos 2025 ile 2 Ağustos 2026 arasındaki dönem, yükümlülüklerin var olduğu ama Komisyon'un ceza kesme yetkisini fiilen kullanmadığı bir "hazırlık" dönemiydi. 2 Ağustos 2026'da o hoşgörü penceresi kapanıyor ve AI Office'in yaptırım dişleri devreye giriyor. Bir de şu ayrıntı var ki sahada çok gözden kaçıyor: 2 Ağustos 2025'ten önce piyasaya sürülmüş modeller için uyum son tarihi 2 Ağustos 2027. Yani eski modeliniz varsa bir yıl daha zamanınız var, ama yeni çıkardığınız her şey doğrudan 2026 rejimine tabi.

Bu kademeli yapıyı anlamak önemli çünkü "yasa zaten yürürlükte, geç kaldık" paniği de yanlış, "daha çok zaman var" rehaveti de yanlış. Doğru pozisyon şu: elinizde, doğru kullanılırsa yeterli olan ama israf edilirse asla geri gelmeyecek bir hazırlık süresi var.

Rakamları soyut bırakırsak kimse ciddiye almıyor, o yüzden somutlaştıralım. AI Act, ihlal türüne göre kademeli bir ceza mimarisi kuruyor. Aklınızda kalması için tablo halinde koyuyorum:

İhlal türü	Ceza tavanı
Yasaklı uygulamalar (Madde 5)	Küresel yıllık cironun %7'si veya 35 milyon avro (yüksek olan)
Yüksek riskli sistem ihlalleri	Küresel yıllık cironun %3'ü veya 15 milyon avro (yüksek olan)
GPAI sağlayıcı yükümlülük ihlalleri	Küresel yıllık cironun %3'ü veya 15 milyon avro (yüksek olan)

Buradaki "hangisi yüksekse o" ifadesi kritik. Küçük bir şirket için 15 milyon avro astronomik bir rakam; büyük bir şirket için ise cironun %3'ü, 15 milyondan çok daha fazla tutabilir. Yani ceza mekanizması hem küçük hem büyük oyuncuyu acıtacak biçimde tasarlanmış. GDPR'ın %4 / 20 milyon avro mantığını hatırlayın; AB, aynı caydırıcılık felsefesini yapay zekâya taşıdı, hatta yasaklı uygulamalarda %7 ile daha da sertleştirdi.

Yasaklı uygulamalar tavanının (%7 / 35 milyon avro) GPAI yükümlülüklerinden ayrı ve daha yüksek olduğunu vurgulamak isterim. Çünkü sahada insanlar tüm cezaları tek bir torbaya koyuyor. Oysa AB'nin risk temelli yaklaşımı burada kendini gösteriyor: en tehlikeli görülen davranışlara (sosyal puanlama, manipülatif sistemler gibi) en ağır ceza, GPAI sağlayıcı yükümlülüklerine ise yüksek riskli sistemlerle aynı seviyede (%3 / 15 milyon avro) bir ceza biçilmiş. Bu hiyerarşiyi bilmek, kendi risk haritanızı çıkarırken önceliklendirmenizi sağlar.

İşin en çok kafa karıştıran ama en belirleyici kısmı burası. "GPAI sağlayıcısı" derken kastedilen, genel amaçlı bir yapay zekâ modelini geliştirip piyasaya süren taraf. Yani bir temel modeli (foundation model) eğiten, ona marka koyan, API ya da başka bir yolla erişime açan aktör. OpenAI, Google, Anthropic, Mistral gibi isimler klasik GPAI sağlayıcıları.

Buraya kadar çoğu Türk şirketi rahat: "Ben model eğitmiyorum ki, ben sadece ChatGPT'yi ya da bir açık kaynak modeli kullanıyorum." Doğru, ama tam da bu noktada tehlikeli bir sınır var ve pek çok yönetici bu sınırın hangi tarafında durduğunu bilmiyor.

Yasa, "sağlayıcı" (provider) ile "dağıtıcı/uygulayıcı" (deployer) arasında keskin bir ayrım yapıyor. Dağıtıcı, mevcut bir modeli alıp kendi iş süreçlerinde kullanan taraftır. Sağlayıcının yükümlülükleri çok daha ağırdır. Peki tehlike nerede? Şurada: eğer bir modeli alır, üzerinde esaslı (substantial) bir ince ayar (fine-tuning) yapar ve bunu kendi markanızla piyasaya sürerseniz, hukuken siz de "sağlayıcı" konumuna geçebilirsiniz.

Bunu bir örnekle somutlaştırayım. Diyelim ki İstanbul'da bir yazılım şirketisiniz. Açık ağırlıklı (open-weight) bir modeli aldınız, kendi sektör verinizle ciddi biçimde yeniden eğittiniz, adına "ŞirketAI" dediniz ve Avrupalı müşterilerinize sattınız. Kendi kafanızda "ben sadece bir uygulama geliştiriyorum" diyorsunuz. Ama AB'nin gözünde yaptığınız iş, esaslı ince ayar + kendi markayla piyasaya sürme kombinasyonu olduğu için sizi pekâlâ GPAI sağlayıcısı sayabilir. O anda teknik dokümantasyon tutma, eğitim verisi özeti yayımlama gibi yükümlülüklerin altına girersiniz.

"

Sahadan en net uyarım şu: "Ben sadece kullanıcıyım" cümlesini kurmadan önce, modelin üzerinde ne kadar oynadığınıza ve onu kendi markanızla mı yoksa olduğu gibi mi sunduğunuza bakın. Bu iki soru, hangi yükümlülük setinin sizi bağladığını belirleyen kırılma noktasıdır.

Bu ayrım o kadar önemli ki, danışmanlık projelerinde ilk yaptığım şeylerden biri, şirketin yapay zekâ envanterindeki her bir kullanım için "biz burada sağlayıcı mıyız, dağıtıcı mıyız?" sorusunu tek tek cevaplatmaktır. Çünkü aynı şirket bir üründe dağıtıcı, başka bir üründe sağlayıcı olabilir. Tek bir etiketle kendinizi kategorize edip rahatlamak, en pahalı hatalardan biri.

Eğer yukarıdaki testten "evet, biz sağlayıcıyız" diye çıktıysanız, dört temel yükümlülüğü içselleştirmeniz gerekiyor. Bunları tek tek, ne anlama geldiğiyle birlikte açayım.

1. Teknik dokümantasyon tutmak. Modelinizin nasıl eğitildiğine, hangi mimariyi kullandığına, yeteneklerine ve sınırlarına dair düzenli, güncel bir teknik dosya tutmanız gerekiyor. Bu, "bir şeyler yazıp çekmeceye koyma" işi değil; hem AI Office hem de sizin modelinizi kullanan downstream (alt akış) sağlayıcılar bu bilgiye ihtiyaç duyabilir. Türk mühendislik kültüründe dokümantasyon çoğu zaman en son düşünülen şeydir; burada bu alışkanlığı tersine çevirmek gerekiyor.

2. Downstream sağlayıcılarla bilgi paylaşmak. Sizin modelinizi alıp kendi ürünlerine gömen şirketlerin, yasal yükümlülüklerini yerine getirebilmesi için sizden belirli bilgileri alması gerekiyor. Yani modelinizi bir kara kutu olarak satamazsınız; onu entegre eden tarafın yasaya uyabilmesi için gereken teknik ve yasal bilgiyi sağlamak zorundasınız. Bu, tedarik zinciri boyunca bir "sorumluluk aktarımı" değil, "sorumluluğun paylaşılmasıdır."

3. AB telif hakkı direktifine uyumlu bir telif politikası benimsemek. Modelinizi eğitirken kullandığınız verinin telif boyutu artık göz ardı edilebilecek bir konu değil. AB telif direktifiyle uyumlu, özellikle metin ve veri madenciliğine ilişkin hak sahiplerinin çekince (opt-out) haklarını gözeten bir politikanız olmalı. Bu, hukuk ekibiyle mühendislik ekibinin aynı masaya oturmasını gerektiren bir konu.

4. Eğitim verisine dair yeterince ayrıntılı, kamuya açık bir özet yayımlamak. Bu belki de en çok tartışılan yükümlülük. Modelinizi neyle eğittiğinize dair kamuya açık, "yeterince ayrıntılı" bir özet sunmanız isteniyor. Buradaki denge hassas: bir yandan ticari sırlarınızı ve rekabet avantajınızı korumak istiyorsunuz, diğer yandan şeffaflık yükümlülüğünü karşılamanız gerekiyor. AI Office bunun için şablonlar sağlıyor; ama işin ruhu, "modelin neyi öğrendiğine dair kamuoyunun ve hak sahiplerinin makul bir fikir edinebilmesi."

Bu dört yükümlülüğü okuyunca çoğu yöneticinin ilk tepkisi "bu çok iş" oluyor. Haklılar. Ama şunu da eklemek isterim: bu yükümlülüklerin büyük kısmı, aslında zaten iyi mühendislik ve iyi yönetişim pratiğinin parçası. Düzgün dokümantasyon, veri kaynaklarının izlenebilirliği, telif konusunda temiz bir vicdan — bunlar yasa olmasa da olması gereken şeyler. Yasa sadece bunları zorunlu hale getiriyor.

Bir de bunun üzerine binen bir katman var. Eğer modeliniz "sistemik risk" taşıyan bir model olarak sınıflandırılırsa — yani sınır seviyesinde (frontier), çok yüksek hesaplama gücüyle eğitilmiş, potansiyel etkisi toplumsal ölçekte olan bir modelse — ek yükümlülükler devreye giriyor. Bunlar:

• Model değerlendirmesi, düşmanca test (adversarial testing / red-teaming) dahil: Modelin kötüye kullanım senaryolarına karşı sistematik olarak zorlanması.
• Sistemik risk dokümantasyonu ve azaltımı: Modelin doğurabileceği toplumsal ölçekli riskleri belgelemek ve bunları azaltacak önlemleri almak.
• Ciddi olay bildirimi (serious incident reporting): Modelle ilgili ciddi bir olay yaşandığında bunu yetkili mercilere raporlamak.
• Siber güvenlik: Modelin ve ağırlıklarının (weights) korunması için üst düzey güvenlik önlemleri.

Açık konuşayım: Türkiye'deki şirketlerin ezici çoğunluğu bu "sistemik risk" ligine girmeyecek. Bu kategori esasen dünyanın en büyük birkaç model geliştiricisini hedefliyor. Ama bu katmanın varlığını bilmek yine de değerli, çünkü AB'nin risk temelli düşünce yapısını gösteriyor: ne kadar güçlü ve yaygın etkili bir sistem kuruyorsanız, o kadar ağır sorumluluk taşıyorsunuz. Bu mantık, kendi iç yönetişiminizi tasarlarken de rehber alabileceğiniz bir ilke.

AB, bu sürecin sopadan ibaret olmadığını göstermek için bir de havuç sundu: gönüllü GPAI Uygulama Kuralları (Code of Practice). Bu, sağlayıcıların uyum yolunu netleştiren, imzaladığınızda size bir tür "güvenli liman" (safe harbor) benzeri avantaj sağlayan bir çerçeve. Yani kurallara uyduğunuzu bu çerçeve üzerinden gösterirseniz, hukuki belirsizliğiniz azalıyor ve iyi niyetinizi kanıtlamış oluyorsunuz.

Anthropic, Google, OpenAI ve Microsoft gibi büyük oyuncuların bu sürece dahil olması önemli bir sinyal. Çünkü bu, kuralların sadece Brüksel'de masabaşında yazılmış soyut metinler olmadığını, sektörün fiili liderlerinin de içinde olduğu bir uzlaşı olduğunu gösteriyor. Türk şirketleri açısından bunun pratik anlamı şu: uyum tarafında "kervan yolda düzülür" demek yerine, bu gönüllü çerçeveyi bir yol haritası olarak okuyabilirsiniz. Büyükler nasıl konumlanıyorsa, ekosistemin geri kalanı da o standarda doğru çekilecek.

Son aylarda Türkiye'deki yöneticilerden en çok duyduğum cümlelerden biri şu: "Duydum ki AB bu işi erteliyormuş, o zaman acele etmeye gerek yok." Bu konuyu netleştirmem lazım çünkü burada tehlikeli bir yanlış anlama var.

Evet, AB gündeminde "Digital Omnibus" adında bir düzenleme paketi var ve bu paket, bazı yüksek riskli sistem son tarihlerinin ertelenmesini öneriyor. Ama burada iki kritik ayrıntıya dikkat: Birincisi, bu bir öneri. Bir düzenleme önerisinin hukuki olarak yürürlüğe girmesi için AB Resmî Gazetesi'nde (Official Journal) yayımlanması gerekiyor. Yayımlanana kadar hiçbir tarih değişmiyor — hepsi tahminden ibaret. İkincisi, tartışılan erteleme esas olarak yüksek riskli sistem takvimini ilgilendiriyor; 2 Ağustos 2026 hâlâ aktif bir tarih olarak masada duruyor.

"

Sahadaki tavsiyem çok net: Bir düzenleme AB Resmî Gazetesi'nde yayımlanmadan, sanki yayımlanmış gibi plan yapmak, kurumsal risk yönetiminin en temel kuralına aykırıdır. 2 Ağustos 2026'yı sanki hiç erteleme ihtimali yokmuş gibi planlayın. Erteleme gelirse, elinizde hazır bir uyum altyapısı olması sizi zayıf değil, güçlü kılar.

Bu noktada şunu da eklemek isterim: erteleme haberleri her zaman bir rahatlama etkisi yaratır ve bu rahatlama, hazırlık momentumunu öldürür. Kariyerim boyunca gördüğüm en pahalı hatalardan biri, "nasılsa ertelenir" beklentisiyle işi son dakikaya bırakmaktır. Uyum, son dakikada satın alınabilecek bir ürün değil; aylara yayılan bir süreçtir. O yüzden erteleme spekülasyonlarını bir mola değil, olsa olsa bir bonus olarak görün.

Şimdi işin Türkiye boyutuna gelelim, çünkü bu yazının asıl derdi bu. "Biz AB üyesi değiliz, bu yasa bizi bağlamaz" itirazını çok duyuyorum ve her seferinde aynı cevabı veriyorum: GDPR'ı hatırlayın.

GDPR yürürlüğe girdiğinde de aynı rahatlık vardı. "Biz Türkiye'deyiz, Avrupa'nın veri kuralı bizi ne ilgilendirir?" Sonra ne oldu? AB'deki müşterisine hizmet veren, AB'li kullanıcının verisini işleyen her Türk şirketi kendini GDPR kapsamında buldu. Çünkü GDPR coğrafyayla değil, pazara erişimle tanımlanıyordu. AI Act de tam olarak aynı mantıkla kurulmuş.

Somut olarak kim kapsamda? Şu profillerden birine giriyorsanız, bu yasa sizi doğrudan ilgilendiriyor:

• AB'deki müşterilere yapay zekâ destekli bir yazılım/hizmet satan Türk teknoloji şirketleri.
• Ürünlerini Avrupa pazarına ihraç eden ve bu ürünlerde yapay zekâ bileşeni bulunan üreticiler.
• AB'li kullanıcıların erişebildiği bir yapay zekâ ürünü (uygulama, platform, API) işleten şirketler.
• Bir AB'li şirketin tedarik zincirinde yer alan ve ona yapay zekâ bileşeni ya da modeli sağlayan Türk firmaları.

Özellikle bu son madde çok kritik. Türkiye ihracat odaklı bir ekonomi ve pek çok şirketimiz, Avrupalı büyük markaların tedarik zincirinde yer alıyor. O Avrupalı marka yasaya uymak zorunda olduğu için, sizden de uyum kanıtı isteyecek. Yani doğrudan AB'ye satış yapmıyor olsanız bile, AB'ye satan bir müşterinizin tedarikçisiyseniz, uyum baskısı size sözleşme yoluyla akacak. Bunu sahada zaten görmeye başladık: Avrupalı alıcılar tedarikçi sözleşmelerine yapay zekâ uyum maddeleri eklemeye başladı.

Şimdi iyi habere geleyim, çünkü Türk şirketlerinin çoğu farkında olmadığı bir avantajın üzerinde oturuyor: KVKK.

Yıllardır KVKK uyumu için yatırım yapan şirketler, aslında AI Act uyumunun da temel taşlarından bazılarını çoktan döşemiş durumda. İki düzenleme arasında ciddi örtüşmeler var ve bu örtüşmeleri bilerek kullanırsanız, sıfırdan başlamak yerine mevcut altyapınızı genişletirsiniz.

En bariz örtüşme alanları şunlar:

• Veri envanteri: KVKK için hazırladığınız kişisel veri işleme envanteri, AI Act'in beklediği veri yönetişiminin iskeletini oluşturur. Hangi veriyi nereden aldığınızı, nasıl işlediğinizi zaten belgelediyseniz, eğitim verisi şeffaflığı yükümlülüğüne çok daha hazırsınız.
• DPIA (Veri Koruma Etki Değerlendirmesi): KVKK kapsamında yaptığınız etki değerlendirmesi metodolojisi, AI Act'in risk değerlendirme mantığıyla kavramsal olarak akraba. Risk tanımlama, olasılık-etki analizi, azaltıcı önlem belirleme kaslarınızı zaten çalıştırdınız.
• Yönetişim yapıları: KVKK için kurduğunuz veri sorumlusu / veri işleyen ayrımı, sorumluluk atama ve dokümantasyon disiplini, AI Act'in sağlayıcı/dağıtıcı ayrımına ve hesap verebilirlik beklentisine doğrudan aktarılabilir.

Yani mesajım şu: KVKK'yı bir "bitmiş proje" olarak arşive kaldırmayın. Onu AI Act uyumunun sıçrama tahtası olarak yeniden konumlandırın. Bunu iyi yapan Türk şirketleri, hiçbir KVKK altyapısı olmayan bir Avrupalı rakibe göre bile avantajlı başlayabilir. Bu, savunmacı bir zorunluluğu rekabetçi bir üstünlüğe çevirmenin somut yoludur.

GPAI yükümlülükleri bir tarafta dursun, AI Act'in bir de "yüksek riskli sistemler" kategorisi var ve pek çok Türk şirketi kullanım senaryosu itibarıyla tam da buraya düşüyor. Yasa, Ek III'te (Annex III) yüksek riskli sayılan uygulama alanlarını sıralıyor. Sizi doğrudan ilgilendirebilecek başlıcaları:

• İşe alım ve istihdam kararları: CV eleyen, aday sıralayan, terfi ya da işten çıkarma önerisi üreten yapay zekâ sistemleri. İK teknolojisi kullanan ya da geliştiren herkesi ilgilendiriyor.
• Kredi puanlama: Bireylerin kredi değerliliğini belirleyen sistemler. Fintech ve bankacılık tarafındaki dostlarımın çok dikkat etmesi gereken alan.
• Biyometrik kimlik tespiti: Yüz tanıma ve benzeri biyometrik tanımlama sistemleri.
• Kritik altyapı: Enerji, su, ulaşım gibi kritik altyapıların yönetiminde kullanılan yapay zekâ.
• Kolluk kuvvetleri (law enforcement): Güvenlik ve adalet uygulamalarında kullanılan sistemler.

Bu listeye bakıp "bunlardan biri bizde var" diyorsanız, GPAI tarafından bağımsız olarak, yüksek riskli sistem yükümlülüklerini de gündeminize almanız gerekiyor. Özellikle İK teknolojileri ve fintech, Türkiye'de hızla büyüyen iki alan ve ikisi de bu listede. Bir işe alım algoritması geliştiriyor ya da kullanıyorsanız, Avrupalı bir müşteriye sattığınız anda yüksek riskli sistem rejimine girersiniz.

Sahadaki konuşmalarda dönüp dolaşıp aynı üç itirazla karşılaşıyorum. Bunları burada tek tek ele almak istiyorum, çünkü büyük ihtimalle sizin ya da yönetim kurulunuzun aklında da bunlar var.

"Biz zaten ABD'li bir sağlayıcının modelini kullanıyoruz, sorumluluk onların." Kısmen doğru ama tehlikeli bir şekilde eksik. Evet, temel modeli eğiten ABD'li sağlayıcının kendi yükümlülükleri var. Ama siz o modeli alıp esaslı biçimde ince ayar yapıp kendi markanızla sunduğunuz anda, kendi başınıza bir sağlayıcı yükümlülüğü doğuyor. Üstelik dağıtıcı olarak kaldığınız durumlarda bile, yüksek riskli bir kullanım senaryonuz varsa kendi yükümlülükleriniz devam ediyor. "Sorumluluk tümüyle onlarda" demek, çoğu zaman gerçeği yansıtmıyor.

"AB bizi nasıl denetleyecek, biz Türkiye'deyiz?" Denetim mekanizması doğrudan kapınızı çalan bir müfettişle işlemiyor; asıl baskı ticari ilişki üzerinden geliyor. Avrupalı müşteriniz, kendi uyumunu güvence altına almak için sizden sözleşmeyle uyum kanıtı, dokümantasyon ve taahhüt isteyecek. Yani sizi "denetleyen" çoğu zaman bir AB kurumu değil, sizinle çalışmaya devam edip etmeyeceğine karar veren müşteriniz olacak. Bu, para cezasından bile daha hızlı hisseceğiniz bir baskı.

"Küçük bir şirketiz, bizi kimse takmaz." Ceza mimarisinin "ciro ya da sabit tutar, hangisi yüksekse" mantığını hatırlayın. Küçük olmak sizi cezadan korumaz, çünkü sabit tavan (15 milyon avro) zaten küçük şirketi bitirecek büyüklükte. Ama daha önemlisi, küçük ve çevik olmak burada bir avantaja çevrilebilir: büyük bir kurumun aylar süren uyum bürokrasisine kıyasla, siz envanterinizi ve rollerinizi haftalar içinde netleştirip Avrupalı müşteriye "biz hazırız" diyebilirsiniz.

Bu üç itirazın ortak paydası şu: hepsi kısa vadede rahatlatıcı, uzun vadede pahalı. Sahadaki işim tam da bu rahatlatıcı hikâyeleri, gerçekle yüzleştirmek.

Bir örnekle bağlayayım, çünkü soyut kalırsa akılda kalmıyor. Bursa'da otomotiv yan sanayisine çözüm üreten orta ölçekli bir yazılım şirketi düşünün. Avrupalı bir ana sanayi markasına, üretim hattındaki kusurları tespit eden yapay zekâ destekli bir görüntü işleme sistemi satıyorlar. Kendi kafalarında bu "sadece bir kalite kontrol yazılımı." Ama gelin bakalım: sistem bir karar veriyor, o karar üretim akışını etkiliyor, ürün Avrupa'ya gidiyor ve müşteri AI Act'e tabi. Müşteri, kendi uyumu için tedarikçisinden — yani bu Bursa'daki şirketten — teknik dokümantasyon, sistemin sınırlarına dair bilgi ve uyum taahhüdü istiyor.

Şimdi bu şirket iki yoldan birini seçebilir. Ya "biz bunları hiç düşünmemiştik" deyip son dakikada telaşa kapılır ve belki de sözleşmeyi kaybeder; ya da envanterini çoktan çıkarmış, rolünü netleştirmiş, dokümantasyonunu hazırlamış olarak "buyurun, hepsi burada" der. İkinci şirketin müşteri gözündeki değeri, birincisinden kat kat yüksektir. İşte AI Act'in Türk şirketleri için asıl anlamı bu: teknik bir uyum zorunluluğu değil, bir güvenilirlik sınavı.

Teoriyi bir kenara bırakıp, sahada uyguladığım pratik adımlara geçelim. Eğer bugün, 2026'nın ortasında bu yazıyı okuyorsanız ve henüz başlamadıysanız, panik yapmadan ama vakit kaybetmeden şu adımları atmanızı öneririm.

Birinci adım — Yapay zekâ envanteri çıkarın. Şirketinizde kullanılan, geliştirilen ya da entegre edilen her yapay zekâ sistemini tek bir listede toplayın. Gölge kullanımları (shadow AI) da dahil edin; departmanların habersiz kullandığı araçlar en büyük kör noktadır. Bu envanter olmadan hiçbir uyum çalışması gerçekçi olamaz.

İkinci adım — Her sistem için rol belirleyin. Envanterdeki her kalem için "biz burada sağlayıcı mıyız, dağıtıcı mıyız?" sorusunu cevaplayın. Özellikle ince ayar yaptığınız ve kendi markanızla sunduğunuz sistemlere dikkat edin; bunlar sizi sağlayıcı konumuna taşıyan kırmızı bayraklardır.

Üçüncü adım — Risk sınıflandırması yapın. Her sistemi AI Act kategorileriyle eşleştirin: yasaklı mı, yüksek riskli mi, GPAI mı, sınırlı riskli mi? Ek III listesini elinizde tutun ve İK, kredi, biyometri gibi alanlara özellikle bakın.

Dördüncü adım — Boşluk analizi (gap analysis). Sağlayıcı olduğunuz sistemler için dört temel yükümlülüğü (dokümantasyon, downstream bilgi paylaşımı, telif politikası, eğitim verisi özeti) tek tek kontrol edin. Nerede eksiğiniz varsa listeleyin.

Beşinci adım — KVKK altyapınızı kaldıraç olarak bağlayın. Mevcut veri envanteri, DPIA ve yönetişim yapılarınızı AI Act gereksinimleriyle eşleştirin. Yeniden icat etmeyin; genişletin.

Altıncı adım — Gönüllü Uygulama Kuralları'nı yol haritası olarak okuyun. Sağlayıcıysanız, Code of Practice'i inceleyin ve kendi uyum yaklaşımınızı buna göre kalibre edin.

Yedinci adım — Sözleşmelerinizi gözden geçirin. Avrupalı müşteri ve tedarikçilerinizle olan sözleşmelerdeki yapay zekâ uyum maddelerini kontrol edin. Bu maddeler gelmeye başladı; hazırlıksız yakalanmayın.

Bu yedi adımı disiplinli biçimde uygularsanız, 2 Ağustos 2026'ya "acaba ceza yer miyiz" korkusuyla değil, "biz hazırız" güveniyle girersiniz.

Son bölümü bir analizle bağlayayım, çünkü buraya kadar okuyan birine sadece "yapılacaklar listesi" bırakmak istemem. Bu konuya nasıl baktığınız, işin sonucunu belirliyor.

Türkiye'deki çoğu şirket AI Act'i bir maliyet kalemi, bir yük, "Avrupalıların bize dayattığı bir bürokrasi" olarak görüyor. Bu bakış açısı anlaşılır ama stratejik olarak zayıf. Çünkü bu yasa, aynı GDPR gibi, fiili bir küresel standarda dönüşecek. Avrupa pazarı yeterince büyük olduğu için, oraya satmak isteyen herkes bu kurallara uymak zorunda kalacak; bu da kuralları otomatik olarak küresel bir norm haline getiriyor.

Şöyle düşünün: uyum çalışmasını erken ve düzgün yapan bir Türk şirketi, iki somut avantaj kazanır. Birincisi, Avrupalı müşteri karşısında "biz uyumluyuz, bizimle çalışmak sizin için risk değil" diyebilme gücü. Bu, satış masasında doğrudan rekabet üstünlüğüdür. İkincisi, uyum sürecinin şirkete zorla dayattığı disiplin — düzgün dokümantasyon, temiz veri yönetişimi, izlenebilir süreçler — aslında yapay zekâ operasyonlarınızı olgunlaştırır. Yani yasaya uyarken, bir yandan da daha iyi bir yapay zekâ organizasyonu inşa etmiş olursunuz.

Öte yandan, bu işi ihmal eden bir şirket iki yönlü kaybeder: Hem yaptırım riskiyle (%3 / 15 milyon avro) karşı karşıya kalır, hem de uyumlu rakipleri Avrupa pazarında pay kaparken geride kalır. En kötü senaryo, bir Avrupalı müşterinin sizinle olan ilişkisini "uyum riski" gerekçesiyle askıya alması ki bunu sahada yaşanırken görmeye başladık bile.

Benim sahadan net kanaatim şu: 2 Ağustos 2026, Türk şirketleri için bir tehdit değil, bir ayrışma noktası. Bu tarihe hazırlıklı gelenler, Avrupa pazarında "güvenilir yapay zekâ tedarikçisi" konumunu erkenden kapacak. Geç kalanlar ise hem cezayla hem de kaybedilen sözleşmelerle uğraşacak. Elinizdeki hazırlık penceresi hâlâ açık; ama her geçen hafta o pencereden biraz daha az ışık giriyor. Bugün atacağınız envanter ve rol belirleme adımı, bir yıl sonra hangi tarafta duracağınızı belirleyecek.