38  Yönetişim, Uyum ve FinOps

Bölüm durumu: çevrildi. Kaynak metin: İngilizce 38. bölüm. Tek bir ölçüm: Bölüm 35’teki aynı 100 maddelik bilgi çıkarma süiti, dört modelli bir merdiven boyunca 0 sıcaklıkla çalıştırıldı ve sonra bir cascade (kademeli yönlendirme: önce ucuz model cevaplar, gerekirse daha güçlü modele geçilir) olarak değerlendirildi. Daha güçlü modele yalnızca çalışma zamanı doğrulayıcısının reddettiği cevaplar aktarıldı (escalation). Bu ölçüm, çok önerilen ama nadiren ölçülen bir maliyet düşürme yöntemine sayı koymak için yapıldı. Aşağıdaki hukuki tarihler ezberden yazılmadı, Eylül 2026’da güncel mevzuattan okundu, çünkü birkaçı Temmuz 2026’da değişti. Yazılım: llama3.2:3b, qwen2.5:7b, qwen3.5:9b ve gemma3:27b modellerini ollama 0.24.0 servis ediyor; Python 3.14.5, Apple Silicon.

Bu bölüm, hukuku yazıldığı andaki hâliyle, ne inşa edeceğine karar veren mühendisler için özetliyor.

Öğrenme hedefleri. Bu bölümün sonunda:

Bu bölüm hukuku aktarır; hukuki tavsiye değildir. Buradaki tarihler ve yükümlülükler Eylül 2026’da kontrol edildi ve birkaçı iki ay önce değişmişti. Herhangi birine dayanmadan önce güncel mevzuata karşı doğrulayın ve önemli olan her şey için hukuk danışmanınızı işin içine katın.

38.1 Veri işleyen bir model olduğunda KVKK ve GDPR

Her iki rejim de aynı ilk soruyu soruyor ve bu, yapay zekâyla ilgili bir soru değil: bu kişisel veriyi hangi hukuki dayanakla işliyorsunuz? LLM bu sorunun cevabını üç açıdan zorlaştırıyor.

Burada uygun dayanak nadiren rızadır. Hukuki dayanağı alışkanlıkla değil, amaca ve koşullara göre seçin. Rıza (KVKK’nın deyişiyle açık rıza) ilke olarak kullanılabilir; ama belirli bir konuya ilişkin, bilgilendirmeye dayanan ve özgür iradeyle verilmiş olmalı ve verildiği kadar kolay geri alınabilmelidir. Bir destek konuşması bunu tek başına sağlamaz. Destek hattına yazan bir müşteri, bu sayede mesajının üçüncü taraf bir model sağlayıcısına gönderilmesine rıza göstermiş olmaz; bu rızayı kullanım koşullarının içine gömmek de iki düzenlemenin engellemek istediği örüntünün ta kendisidir. Çoğu üretim sistemi bunun yerine meşru menfaate ya da sözleşmenin ifasına dayanıyor. Sözleşmenin ifası yalnızca sözleşmenin onsuz gerçekten yerine getirilemeyeceği işlemeyi kapsar; meşru menfaat ise denge testini — sizin menfaatinize karşı kişinin haklarını — iddia etmek değil, yazıya dökmek demektir. Bir uyarı daha: destek konuşmaları sağlık gibi özel nitelikli kişisel veri de içerebilir ve bu veride işleme şartları ayrı ve daha dardır (KVKK 6. madde, 7499 sayılı Kanunla değişik; GDPR 9. madde).

LLM projeleri en çok amaçla sınırlılık ilkesinde tökezliyor. Bir siparişi yerine getirmek için toplanıp sonra bir modelin fine-tuning’inde (ince ayar) yeniden kullanılan veri yeni bir amaçtır ve yeni bir amacın kendi hukuki dayanağı gerekir. LLM ürünlerindeki en yaygın uyum ihlali bir sızıntı değil; başka bir şey için toplanmış veriyle eğitim yapmaktır.

İlgili kişi haklarının model katmanına ulaşması gerekiyor. Bir silme talebi vektör deposuna, iz arka ucuna (Bölüm 34), değerlendirme kümesine (Bölüm 35), önbelleğe ve Bölüm 37’nin token eşlemesine (kişisel verinin yerine konan yer tutucuları asıl değerlere geri çeviren eşleme tablosu) yayılmalı — bunların çoğunu kimse veri tabanı olarak düşünmedi. Belirli bir kişinin katkısını fine-tune edilmiş bir modelden güvenilir biçimde çıkarmak (literatürdeki adıyla machine unlearning, makine unutması) hâlâ zor ve yönteme bağlı. Pratik cevap, kişisel veriyi eğitim kümelerine hiç koymamaktır; bu da her seferinde yeniden ele alınan bir talep değil, bir kez verilen bir tasarım kararıdır.

Haklardan biri doğrudan ajanlara dokunuyor: otomatik karar. GDPR’ın 22. maddesi, kişiyi hukuki ya da benzer ölçüde önemli sonuç doğuran, yalnızca otomatik işlemeye dayalı kararlara karşı koruyor; KVKK’nın 11. maddesinin birinci fıkrasının (g) bendi de verilerin münhasıran otomatik sistemlerle analiz edilmesi sonucunda kişinin aleyhine bir sonuç çıkmasına itiraz hakkı tanıyor. İadeyi reddeden ya da bir talebi kapatan bir ajan bu duruma kolayca düşer; bu yüzden Bölüm 37’deki insan onayı yalnızca bir güvenlik önlemi değil, aynı zamanda bu hakkın mühendislikteki karşılığıdır.

38.1.1 Türkiye’ye özgü kısım

KVKK’nın, yani 6698 sayılı Kanunun, LLM işi için en önemli kısmı yakın zamanda yeniden yazıldı. 12 Mart 2024’te yayımlanan 7499 sayılı Kanun onu değiştirdi ve KVKK’yı değiştiren hükümler 1 Haziran 2024’te yürürlüğe girdi. Aşağıda iki ayrı yapı geçiyor: bildirimleri alan kurum olan Kişisel Verileri Koruma Kurumu (kısaca Kurum) ve Kurumun karar organı olan, yeterlilik kararlarını, izinleri, onayları ve standart sözleşme metinlerini belirleyen Kişisel Verileri Koruma Kurulu (kısaca Kurul). Değişiklik, yurt dışına aktarımı düzenleyen 9. maddeyi GDPR’ın yapısına çok yaklaştırdı:

Değişik hâliyle 9. madde, deneyeceğiniz sırayla
kademe ne olduğu ne yapmanız gerekir
Yeterlilik kararı Kurul bir ülkeyi, sektörü ya da uluslararası kuruluşu yeterli ilan etmiştir o dayanakla aktarın
Uygun güvenceler aşağıdaki dördü birini seçin ve koşullarını karşılayın
İstisnai hâller dar istisnalar bunların üzerine ürün kurmayın

Tek bir olgu o tabloyu çok daha kısa bir karara çeviriyor. Kurul hiçbir ülke, sektör ya da uluslararası kuruluş için yeterlilik kararı vermiş değil — Kurumun yurt dışına aktarım sayfası, “yeterli korumanın bulunduğu ülkeler” başlığı altında bu konuda henüz bir belirleme yapılmadığını söylüyor. Yani ilk kademe pratikte boş ve ABD’de barındırılan bir sağlayıcı kullanan bir şirket için gerçekçi yol, Kurulca ilan edilen standart sözleşme. Bağlayıcı şirket kuralları da var, ama Kurul onayı ve ortak ekonomik faaliyette bulunan bir teşebbüs grubu (şirketler topluluğu) gerektiriyor; çoğu ekipte ikisi de yok. Standart sözleşmeye ve onun beş iş günlük bildirim süresine göre planlayın; yeterlilik kararını şimdi bakılacak bir şey değil, ileride gelebilecek bir şey sayın.

Üçüncü kademeye kısaca değinmek gerekiyor, çünkü Türkiye’deki uygulama eskiden buna dayanıyordu. Haziran 2024’ten önce yurt dışına aktarımın olağan yolu ilgili kişinin açık rızasıydı; 7499 sayılı Kanunun geçiş hükmü (KVKK geçici 3. madde) bu yolu yeni hükümle birlikte 1 Eylül 2024’e kadar açık tuttu. Değişik 9. maddede açık rıza (muhtemel riskler hakkında bilgilendirildikten sonra verilen) istisnai hâllerden biri ve bu hâller yalnızca arızi aktarımlar için kullanılabiliyor: ara sıra, süreklilik taşımayan, olağan iş akışının dışında kalan aktarımlar. Her konuşmayı yurt dışındaki bir sağlayıcıya gönderen bir ürün, arızi olanın tam tersidir.

Dört uygun güvence şunlar: yurt dışındaki kamu kurum ve kuruluşları ya da uluslararası kuruluşlarla Türkiye’deki kamu kurum ve kuruluşları (ya da kamu kurumu niteliğindeki meslek kuruluşları) arasında yapılan, uluslararası sözleşme niteliğinde olmayan bir anlaşma ve Kurulun aktarıma izin vermesi; bir teşebbüs grubu içinde Kurulca onaylanmış bağlayıcı şirket kuralları; Kurulca ilan edilen standart sözleşme; ve yeterli korumayı sağlayan yazılı bir taahhütname ile Kurulun aktarıma izin vermesi. Birincisindeki olumsuzluğa dikkat edin, hükmün amacı da bu: tam bir uluslararası sözleşme TBMM onayı gerektirirdi; bu yol ise bilerek daha alt düzeyde bir düzenlemeye izin veriyor.

38.1.1.1 Önce devreye giren sektörel katman

Düzenlemeye tabi finans kuruluşları için 9. maddeye hiç sıra gelmeyebilir, çünkü ondan önce sektörel bir kural uygulanıyor. En açık örnek bankalar. BDDK’nın (Bankacılık Düzenleme ve Denetleme Kurumu) Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmeliği (Resmî Gazete, 15 Mart 2020, yürürlük 1 Temmuz 2020), bir bankanın birincil ve ikincil sistemlerinin Türkiye’de bulundurulmasını zorunlu kılıyor ve bu zorunluluğu, kapsamları içinde çalışan dış hizmet sağlayıcılarının bilgi sistemlerine ve yedeklerine de genişletiyor. Dolayısıyla birincil sistem kapsamındaki ABD merkezli bir model sağlayıcısı için soru “hangi güvenceyi seçelim” değildir; buna baştan izin yok. Pratik yollar: yerel olarak barındırılan açık ağırlıklı bir model, sağlayıcının sunduğu bir Türkiye bölgesi dağıtımı ya da iş yükünü birincil sistem kapsamının dışında tutmak — ve hangisinin geçerli olduğu, bir API’yi entegre eden ekibin değil kurumun kendi bilgi sistemleri uyum biriminin kararı. BDDK yönetmeliği bankaları kapsıyor; ödeme ve elektronik para kuruluşları Merkez Bankasına (TCMB), sigortacılar kendi denetim kurumuna, SEDDK’ya (Sigortacılık ve Özel Emeklilik Düzenleme ve Denetleme Kurumu) bağlı ve her birinin aynı biçimde kontrol edilmesi gereken kendi bilgi sistemleri kuralları var. 9. madde analizine girişmeden önce, işvereninizin KVKK’nın üstünde bir sektörel düzenleyiciye tabi olup olmadığını kontrol edin.

Mühendislerin en sık kaçırdığı işletme ayrıntısı: bir standart sözleşme, imzalanmasından itibaren beş iş günü içinde Kuruma bildirilmelidir (9. maddenin 5. fıkrası ve 10 Temmuz 2024 tarihli, 32598 sayılı Resmî Gazete’de yayımlanan Kişisel Verilerin Yurt Dışına Aktarılmasına İlişkin Usul ve Esaslar Hakkında Yönetmeliğin 14. maddesinin 5. fıkrası). Kurum, Ekim 2024’ten beri çevrimiçi bir Standart Sözleşme Bildirim Modülü işletiyor. Mühendislikteki ikinci somut sonuç: Yönetmelik, standart sözleşmenin Kurulun ilan ettiği metin değiştirilmeden kullanılmasını istiyor; sağlayıcının sunduğu AB standart sözleşme maddeleri (SCC) ya da kendi veri işleme sözleşmesi bunun yerine geçmiyor. Bu, bir satın alma kararına bağlı, süreli bir yükümlülüktür ve kaçırılır, çünkü sözleşmeyi imzalayan kişiyle modeli devreye alan kişi aynı kişi değildir.

Bu konu neden mühendisleri de ilgilendiriyor? Çünkü ABD’de barındırılan bir model sağlayıcısı seçmek yurt dışına aktarımın ta kendisidir. Bu bir platform ayrıntısı değil, doğrudan 9. madde sorusudur ve entegrasyon yazıldıktan sonra değil, yazılmadan önce cevaplanmalıdır.

LLM özelliğinin dokunması gereken, Türkiye’ye özgü bir belge daha var: kişisel veri işleme envanteri — hangi verinin hangi amaçla, hangi dayanakla işlendiğini, ne kadar saklandığını ve kime aktarıldığını gösteren liste. Birçok veri sorumlusu ayrıca Veri Sorumluları Siciline kayıt olmak zorunda (Kurulun belirlediği çalışan sayısı ve yıllık bilanço eşiklerinin altında kalan bazı veri sorumluları muaf; işvereninizin durumunu Kurul kararlarından kontrol edin); kayıt, bu envanter esas alınarak Veri Sorumluları Sicil Bilgi Sistemi (VERBİS) üzerinden yapılıyor. Yeni bir amaç ya da yurt dışında yeni bir alıcı — ikisi de bir LLM entegrasyonunda olağan — envanteri ve kayıtlıysanız VERBİS’teki sicil kaydını güncellemek demek.

38.2 Bir sağlayıcı sözleşmesinin gerçekte vaat ettikleri

Önce iki rol, çünkü sözleşme onların üzerine kurulu. Kuruluşunuz veri sorumlusudur (GDPR’da controller): kişisel verinin neden ve nasıl işleneceğine o karar verir ve yükümlülükleri o taşır. Model sağlayıcısı normalde veri işleyendir (processor): veriyi sizin adınıza ve talimatlarınızla işler. Bu talimatları sabitleyen sözleşmeye genellikle veri işleme sözleşmesi (data processing agreement, DPA) denir.

Satıcı sayfaları içinizi rahatlatmak için yazılıyor. Asıl belge sözleşmedir ve içindeki dört şey, dağıtımın hukuka uygun olup olmadığını belirler.

Çıkarımın (inference: modelin çalıştırılması) nerede yapıldığı ve arıza hâlinde nereye devredilebileceği. Sınırsız bir devretme (failover: arızada trafiği başka bir bölgeye ya da sağlayıcıya aktarma) maddesiyle gelen bir bölge taahhüdü, bölge taahhüdü değildir.

Verinizin onların modelini eğitip eğitmediği ve bunun nasıl kapatıldığı. Aynı satıcıda bile varsayılan ayar tüketici katmanında, API’de ve kurumsal sözleşmede farklıdır. Gerçekten üzerinde olduğunuz katmanı okuyun ve hangisi olduğunu entegrasyonun yanına kaydedin.

Saklama. “Girdileri kötüye kullanım izlemesi için 30 gün saklıyoruz” cümlesi, prompt’larınızın (istem) bir yerde 30 gün boyunca durduğunu söyler; bu, veri koruma etki değerlendirmenizin (DPIA: GDPR’ın 35. maddesinin yüksek riskli işlemeden önce istediği belgelenmiş risk analizi) ihtiyaç duyduğu ve çoğu entegrasyonun hiç kayda geçirmediği bir olgudur. KVKK bu değerlendirmeyi açıkça adlandırmıyor, ama aynı analiz onun sorularını da cevaplıyor.

Alt işleyenler (sub-processors). Model sağlayıcısının kendi altyapı tedarikçileri de kapsamdadır ve bu liste değişir; sözleşme, liste değiştiğinde size haber vermelerini zorunlu kılmalı.

Sonra bir diyagramın cevaplamayacağı silme sorusu: bir kullanıcı verilerinin silinmesini istediğinde, metninden türetilen embedding’lere (gömme), prompt önbelleklerine (Bölüm 31), izlere ve altın kümeye (golden set) gerçekte ne oluyor? Her biri bir kopya. Her depo için cevabı, ihtiyaç duymadan önce yazın, çünkü süre talep geldiği anda işlemeye başlıyor: GDPR’da bir ay (karmaşık taleplerde iki ay daha uzatılabilir), KVKK’da en geç otuz gün.

38.3 AB Yapay Zekâ Yasası ve kayan tarihler

Yasa risk kademesine göre uygulanıyor ve GDPR gibi AB sınırlarının ötesine uzanıyor, ama tetikleyicisi farklı. Bir Türk şirketi, AB’de bir yapay zekâ sistemini piyasaya sürüyorsa ya da sisteminin ürettiği çıktı AB’de kullanılıyorsa kapsamdadır.

Kademeler, kısaca. Yasak uygulamalar — sosyal puanlama, belirli biyometrik kategorilendirmeler, manipülatif teknikler — ne kadar özen gösterirseniz gösterin yasaktır. Yüksek riskli kademe, gerçek mühendislik sonuçları olan kademedir: risk yönetimi, veri yönetişimi, teknik dokümantasyon, kayıt tutma (logging), insan gözetimi, doğruluk ve sağlamlık ve bir uygunluk değerlendirmesi. Sınırlı risk şeffaflık yükümlülükleri getiriyor — insanlara bir makineyle konuştuklarını söylemek, sentetik içeriği işaretlemek. Asgari risk geri kalan her şeydir; ürünlerin çoğu da buraya düşer.

Çoğu destek ajanı yüksek riskli değil; yüksek riskli olanlar da genellikle istihdama, krediye, eğitime ya da temel hizmetlere dokunduğu için öyle oldu. Yasanın dilinde bu kullanım alanları Ek III’te listeleniyor: biyometri, kritik altyapı, eğitim, istihdam, kredi puanlaması gibi temel hizmetlere erişim, kolluk, göç ve adalet. Ek I ise başka bir yoldur: makine, oyuncak, tıbbi cihaz gibi AB ürün mevzuatına zaten tabi ürünlerin güvenlik bileşeni olan (ya da ürünün kendisi olan) yapay zekâ sistemleri. Çoğu takım için sınıflandırma alıştırmasının tamamı bu paragraftan ibaret; yine de iki cevaptan birini varsaymak yerine alıştırmayı açıkça yapın ve gerekçesini yazın.

38.3.1 Takvim, şu anki hâliyle

Bu, ezberlenecek değil kontrol edilecek kısım, çünkü Temmuz 2026’da değişti. (AB) 2026/1744 sayılı Tüzük — Yapay Zekâya İlişkin Dijital Omnibus — 24 Temmuz 2026’da AB Resmî Gazetesi’nde yayımlandı ve 27 Temmuz 2026’da yürürlüğe girerek yüksek riskli yükümlülükleri erteledi ve başka birkaç hükmü değiştirdi:

(AB) 2026/1744 sayılı Tüzük’ten sonra AB Yapay Zekâ Yasası uygulama tarihleri (son kontrol: Eylül 2026)
yükümlülük ne zamandan itibaren 2026’da değişti mi?
Yasak uygulamalar 2 Şubat 2025 hayır — ama aşağıda iki yenisi eklendi
Yapay zekâ okuryazarlığı (4. madde) 2 Şubat 2025 içerik yumuşatıldı — yeterli okuryazarlık düzeyini “sağlamak” yerine onu “desteklemek için önlem almak”
Genel amaçlı yapay zekâ (GPAI) model yükümlülükleri 2 Ağustos 2025 hayır (Komisyonun para cezası verme yetkisi 2 Ağustos 2026’dan itibaren)
50. madde şeffaflık yükümlülükleri (aşağıdaki Madde 50(2) durumu dışında hepsi) 2 Ağustos 2026 hayır
Madde 50(2), yapay zekâ üretimi içeriğin işaretlenmesi (2 Ağustos 2026’dan önce piyasaya sürülen sistemler için) 2 Aralık 2026 evet — 2026’da eklenen bir geçiş süresi
İki yeni 5. madde yasağı (rızaya dayanmayan mahrem görüntüler, yapay zekâ üretimi CSAM) 2 Aralık 2026 evet — 2026’da eklendi
Ağustos 2025’ten önce piyasaya sürülen GPAI modelleri 2 Ağustos 2027 hayır
Ulusal düzenleyici kum havuzları (regulatory sandbox: yeni sistemlerin denetim altında sınandığı ortam) 2 Ağustos 2027 evet — ertelendi
Ek III kapsamında yüksek riskli (bağımsız) 2 Aralık 2027 evet — 2 Ağustos 2026’dan ertelendi
Ek I kapsamında yüksek riskli (düzenlenmiş ürünlerde) 2 Ağustos 2028 evet — ertelendi

Tablodan tarihlerin kendisinden çok iki ders çıkarılmalı. Birincisi: ertelemeler yüksek riskli kademelere ve ulusal kum havuzlarına uygulandı; yasaklar, GPAI yükümlülükleri ve yeni piyasaya sürülen sistemler için 50. madde tarihi yerinde kaldı. Dolayısıyla “Yapay Zekâ Yasası ertelendi” sözünü duyup çalışmayı durduran bir takım yanlış duymuş demektir. İkincisi: aynı tüzük yalnızca ertelemedi, yükümlülük de ekledi (Aralık 2026’dan itibaren iki yeni yasak uygulama); piyasada zaten bulunan sistemlere Madde 50(2) için bir geçiş süresi tanıdı ve yapay zekâ okuryazarlığı yükümlülüğünü, tarihine dokunmadan yumuşattı. “Yalnızca yüksek risk değişti” özetinden kaçının; tek satırlık bir özete (bu cümle dâhil) güvenmek yerine değiştiren maddelerin kendisini okuyun. Ve Aralık 2027 tarihi bir öneri değil, şu an bağlayıcı hukuk — onu yeniden değiştirmek başka bir yasama işlemi gerektirir.

GPAI satırları hakkında bir not, çünkü kolayca sizi bağlıyormuş gibi okunuyorlar. Bu yükümlülükler genel amaçlı bir modeli piyasaya süreni — onu eğiten şirketi — bağlar; o modeli bir API üzerinden çağıran takımı değil. Sizi iki yoldan ilgilendirirler. Modelin sağlayıcısı, modeli kendi sistemine entegre edenlere yeteneklerini ve sınırlarını anlatan belgeler vermek zorunda; bu tam da kendi risk değerlendirmenizin ihtiyaç duyduğu şey, o yüzden isteyin. Ayrıca bir modeli esaslı biçimde değiştirmek sizi onun sağlayıcısı yapabilir: Komisyonun GPAI kılavuzu (Temmuz 2025) gösterge eşik olarak, özgün modelin eğitim hesaplamasının üçte birinden fazlasını kullanan bir değişikliği alıyor. Tipik bir göreve özel fine-tuning bunun çok altında kalır.

Genel ders belirli tarihlerden uzun yaşıyor: düzenleyici takvimler kayıyor ve ezberlenmiş tarihlere dayanan bir uyum planı, bir noktada kimse fark etmeden yanlış hâle gelecek bir plandır. Mevzuatın URL’sini ve kontrol ettiğiniz tarihi planın yanına koyun; Bölüm 34’ün OpenTelemetry GenAI uzlaşımlarının (semantic conventions) sürümlerini sabitlemek için savunduğu gibi.

38.4 Belgelendirme değil, kontrol listesi olarak çerçeveler

Hiç sertifika peşine düşmeseniz de okunması gereken iki belge var, çünkü ikisi de esasen takımların unuttuğu şeylerin yapılandırılmış listeleri.

ISO/IEC 42001:2023, bir yapay zekâ yönetim sistemi için ilk uluslararası standart — ISO/IEC 27001 kalıbının yapay zekâya uygulanmış hâli: politika, roller, risk değerlendirmesi, yaşam döngüsü denetimleri, tedarikçi yönetimi, sürekli iyileştirme. Gönüllüdür, belgelendirilebilir ve kurumsal satın almalarda giderek daha çok isteniyor; bir mühendislik yol haritasına girmesinin nedeni de genellikle budur.

NIST Yapay Zekâ Risk Yönetimi Çerçevesi 1.0 (AI 100-1) işi dört işleve ayırıyor — Govern (yönetişim), Map (bağlamı ve riskleri belirleme), Measure (ölçme) ve Manage (riskleri yönetme) — ve Üretken Yapay Zekâ Profili (NIST AI 600-1, 26 Temmuz 2024’te yayımlandı) işe daha doğrudan yarayan belge: üretken yapay zekâya özgü ya da onun büyüttüğü on iki risk kategorisi ve iki yüzden fazla önerilen eylem. Bu çerçeve de sabit değil: NIST’in kendi sayfası, Eylül 2026 itibarıyla AI RMF 1.0’ın Beyaz Saray’ın Temmuz 2025 tarihli Yapay Zekâ Eylem Planı kapsamında revize edilmekte olduğunu söylüyor. Yeni sürüm yayımlanana kadar 1.0 ve AI 600-1 geçerli belgeler; kontrol listenizin yanına hangi sürümü kullandığınızı ve kontrol tarihini yazın.

Onları kullanmanın doğru yolu: risk kategorilerini, cevabınız olması gereken şeylerin bir listesi olarak okuyun ve takımınızın hangilerini hiç konuşmadığını fark edin. Bu alıştırma bir öğleden sonra sürüyor ve gerçek boşluklar buluyor. Belgelendirme ise ayrı ve çok daha büyük bir karar; onu müşterilerin talep edip etmediği belirler.

38.5 Denetim log’ları: kim, kimin verisine, kimin yetkisiyle ne yaptı

Bölüm 34’ün izlemesi teknik olarak ne olduğunu cevaplıyor. Bir denetim log’u farklı bir soruyu cevaplıyor — bunu kim yetkilendirdi — ve ikisinin saklama süreleri, erişim denetimleri ve okuyucuları farklı.

Bir denetçinin istediği ve hiçbiri geriye dönük eklenemeyen alanlar:

  ne zaman        zaman damgası ve hangi saat diliminde olduğu
  kim             yalnızca servis hesabı değil, işlemi başlatan insan
  kimin adına     verisi işlenen kullanıcı
  ne              eylem ve onu gerçekleştiren araç
  hangi veri      dokunulan tanımlayıcılar ya da kategoriler — içerik değil
  yetki           hukuki dayanak ya da izin veren onay
  nerede          işleme bölgesi ve model sağlayıcısı
  sonuç           başarılı, başarısız, reddedildi, aktarıldı

Bir denetim log’unu bir uygulama log’undan ayıran üç özellik. Yalnızca ekleme yapılabilir, çünkü bir işletmecinin düzenleyebildiği bir log hiçbir şeyi cevaplamaz. Yalnızca eylemi değil, yetkiyi kaydeder — “bir iade yaptı” bir olay; “kullanıcı X’in verdiği #4821 numaralı onayla bir iade yaptı” bir denetim kaydı. Ve kendi saklama takvimi vardır: genellikle izlerden uzun, iş kayıtlarından kısa süre saklanır; bu da ayrı politikası olan ayrı bir depo demektir.

Özellikle ajanlar için bir ekleme: eylemin yanı sıra eyleme geçme kararını da kaydedin. Ajan bir aracı seçtiğinde bağlamında ne vardı? Her olay incelemesi bu soruyu sorar; neden önemli olduğunu Bölüm 36 gösterdi: talimatın kullanıcınızdan mı yoksa bir belgeden mi geldiğini ancak bu cevapla öğrenebilirsiniz.

38.6 Birim ekonomisi: bir bütçe incelemesinin ihtiyaç duyduğu sayı

Bu bölümün başlığındaki FinOps (Financial Operations), bulut gibi değişken maliyetleri mühendislik, finans ve ürün ekiplerinin birlikte görünür kılıp eniyilediği disiplinin adıdır; üç evresi bilgilendir, eniyile ve işlet. LLM harcaması bu disiplinin yeni bir değişken maliyet kalemi ve ilk sorusu şu: hangi birimle ölçüyorsunuz?

İstek başına maliyet, elinizde hazır olan ama raporlanmaması gereken sayıdır. Üç düzey var ve bütçe sorumlusuyla yapılan bir toplantıdan yalnızca sonuncusu sağ çıkıyor:

Üç birim maliyet
metrik neyi olduğundan iyi gösterir ne zaman doğrudur
istek başına maliyet bir cevabı çok sayıda küçük çağrıya bölen sistemleri (her çağrı ucuz görünür) kapasite planlaması
oturum başına maliyet kimsenin tamamlamadığı bir özelliği özellik kullanımını karşılaştırmak
çözülen görev başına maliyet hiçbir şeyi — doğru birim bu herhangi bir bütçe konuşması

Üçüncüsünü eksiksiz hesaplamak, takımların rutin olarak dışarıda bıraktıklarını dâhil etmek demek: yeniden denenen çağrılar, bir tavana çarpan koşular (Bölüm 33), çevrimiçi değerlendirmedeki hakem çağrıları (Bölüm 35), embedding çağrıları ve insana aktarılan vakayı ele alan kişinin maliyeti. Sonuncusu genellikle en büyük tek kalemdir ve tam da başka bir bütçede durduğu için atlanır.

Asıl önemli olan, aynı “çözüldü” tanımıyla, yalnızca insanların çalıştığı baseline’la (karşılaştırma tabanı) yapılan karşılaştırmadır. Destek taleplerinin (ticket) %60’ını tanesi 0,08 avroya çözen ve geri kalanını 4,00 avroya bir insana aktaran bir ajan, talep başına $0{,}08 + 0{,}40 00 = $ 1,68 avroya mal oluyor; yalnızca insanla çalışan baseline ise 4,00 avro — %58 azalma. Ajanın parasını insana aktarılan taleplerde de ödediğinize dikkat edin: ajanın başarısız olduğunu ancak onu çalıştırınca öğreniyorsunuz ve bu kalemi sessizce düşürmek, tam da yukarıdaki paragrafın uyardığı ihmaldir. Aritmetiğin göremediği ikinci bir varsayım da var: aktarılan bir talep yeni bir talep gibi fiyatlanıyor, oysa aktarılan talepler tanımı gereği zor olanlar. Aktarılan talepleri 6,00 avrodan alıp yeniden hesaplayın: maliyet talep başına 2,48 avroya çıkıyor ve %58’lik azalma %38’e iniyor. İş gerekçesi bu aritmetiktir ve token fiyatına değil, neredeyse tümüyle çözüm oranına duyarlıdır. Bölüm 35’in ölçüm disiplininin aynı zamanda bir maliyet disiplini olmasının nedeni de bu.

38.7 Bir cascade gerçekte ne kazandırıyor

“Kolay istekleri daha küçük bir modele yönlendir”, bu alanda en çok önerilen ve en az ölçülen maliyet düşürme yöntemi. Öyleyse işte ölçülmüş hâli: Bölüm 35’in 100 maddelik Türkçe bilgi çıkarma süiti üzerinde, 0 sıcaklıkla, dört yerel modelle.

Önce yalnızca merdiven. Her maddenin beş alanı var; dolayısıyla field acc (alan doğruluğu) 500 tekil alan kararının doğru olan payı, exact (tam eşleşme) ise beş alanının beşi de doğru olan madde sayısı:

100 items, 500 field decisions, temperature 0

model            field acc   exact   passes validator   output tokens
llama3.2:3b         92.40%      65             80/100            4,205
qwen2.5:7b          95.20%      80             96/100            5,105
qwen3.5:9b          97.80%      90            100/100            6,173
gemma3:27b         100.00%     100            100/100            4,921

Cascade’den önce iki şey. gemma3:27b her maddenin her alanını doğru bildi — kusursuz 100/100 tam eşleşme. Bu önemli: %100 bu süitte modellerin yalnızca yaklaştığı bir sınır değil, ulaşılabilir bir değer. Ama madalyonun öbür yüzü de var: süit doymuş durumda (tavan etkisi) ve en büyük modeller arasında artık ayrım yapamıyor. Ve en büyük modelin 9B modelden daha az çıktı token’ı kullandığına dikkat edin: bir modelin ne kadar uzun yazdığı boyutuyla belirlenmiyor; dolayısıyla token tabanlı bir maliyet tahmini parametre sayısından türetilemez.

38.7.1 Cascade: ucuza cevapla, doğrulayıcı reddederse aktar

Yönlendirici bir zorluk öngörücüsü değil. Bölüm 18’in şema ve biçim kontrolü, küçük modelin çıktısı üzerinde çalışıyor: ayrıştırılıyor mu, beş alanın hepsi var mı, sipariş kodu örüntüsüne uyuyor mu, ay gerçek bir ay mı, tutar bir tutar gibi biçimlendirilmiş mi. Referans cevaplara (ground truth) hiç bakmıyor — yani üretimde olduğu gibi çalıştırabileceğiniz şey.

small -> big              escalated   field acc   exact
llama3.2:3b -> qwen2.5:7b       20%      96.20%      81
llama3.2:3b -> qwen3.5:9b       20%      96.20%      82
llama3.2:3b -> gemma3:27b       20%      97.00%      85
qwen2.5:7b  -> qwen3.5:9b        4%      96.20%      82
qwen2.5:7b  -> gemma3:27b        4%      96.60%      84
qwen3.5:9b  -> gemma3:27b         0%      97.80%      90

Asıl sonuç üçüncü satırda. İsteklerin %20’sini büyük modele göndermek kalite farkının çoğunu geri kazandırıyor: tek başına %92,40, cascade ile %97,00, her şey büyük modele gitseydi %100,00. Beşte bir istek karşılığında farkın %61’i kapanmış oluyor.

Ekonomik hesap aktarma oranından çıkıyor; varsayımsal fiyatlara gerek yok. Küçük modelin parasını her istekte, büyük modelinkini yalnızca aktarılan payda ödüyorsunuz; dolayısıyla büyük model istek başına küçüğün K katına mal oluyorsa cascade, her şeyi büyük modele göndermenin faturasının \((1 + 0{,}20K)/K\) kadarına mal oluyor:

  K = 10   ->  büyük model faturasının %30'u
  K = 30   ->  %23'ü

K, token başına liste fiyatlarının değil, istek başına maliyetlerin oranıdır. Modeller aynı uzunlukta cevap üretmiyorsa bu ikisi birbirinden ayrılır; yukarıdaki token sütunu da aynı uzunlukta üretmediklerini gösteriyor.

7B→27B satırı aynı yöntemin farklı bir ayarı: %4 aktarmayla %96,60, tek başına 7B’ye göre 1,4 puanlık bir kazanç. Bunun neye mal olduğu yalnızca aktarma oranına değil, fiyat oranına da bağlı: \(K = 10\)’da cascade, yalnızca büyük model kullanmanın faturasının \((1 + 0{,}04 \times 10)/10 = \%14\)’ü, ama 7B’nin kendi faturasının \(1{,}4\) katı. “Neredeyse hiç ek harcama yok” büyük modele göre doğru, küçüğe göre yanlış; hangi baseline’ı kastettiğinizi söyleyin.

38.7.2 En çok öğreten satır sonuncusu

qwen3.5:9b -> gemma3:27b isteklerin %0’ını aktarıyor; dolayısıyla cascade 9B modelin kendisinden ibaret ve hiçbir şey kazandırmıyor. Bu, fikrin başarısızlığı değil; fikrin sınırının kesin biçimde dile getirilmiş hâli.

9B model, alanların yalnızca %97,80’inde doğru olmasına rağmen 100 maddenin 100’ünde doğrulayıcıyı geçiyor. Doğrulayıcı iyi biçimliliği kontrol ediyor ve model her zaman iyi biçimli olacak kadar iyi olduğu anda iyi biçimliliğin doğrulukla ilişkisi (korelasyonu) kalmıyor. İçinde yanlış şehir olan kusursuz biçimlendirilmiş bir JSON nesnesi, doğru cevabı bilmeyen her kontrol için görünmez.

Buradan üç sonuç çıkıyor:

Öngörülen zorluğu değil, aktarma oranını ölçün. Bölüm 12, bir LLM’in sözel olarak ifade ettiği güveni kendi hatalarının dedektörü olarak sınadı ve AUROC değerini 0,667 buldu: gerçek bir sinyal, ama yönlendirmeye yetmiyor. (AUROC burada, rastgele seçilmiş yanlış bir cevabın rastgele seçilmiş doğru bir cevaptan daha düşük güven alma olasılığı; 0,5 yazı tura demek.) Aynı görevde fine-tune edilmiş başka bir modelin, bir sınıflandırıcının (BERTurk) softmax olasılığı 0,843’e ulaştı. Ödünleşimin (trade-off) özeti şu: ne kadar emin olduğu sorulan bir model daha kötü cevap veriyor — kısmen, söylediği sayılar kaba ve neredeyse hep aynı değer olduğu için — bir modelin çıktı dağılımından okunan olasılık ise belirgin biçimde daha iyi cevap veriyor. İki sayı farklı modellerden geldiği için farkın bir kısmı da model farkıdır. Doğrulayıcı ise bambaşka bir şey: henüz çalıştırmadığınız bir istek hakkında bir öngörü değil, zaten elinizde olan bir çıktı hakkında bir olgu.

Cascade’in tavanı, yönlendiricinizin görebildiğidir. Tek sinyaliniz şema geçerliliğiyse yalnızca bozuk biçimli çıktıları aktarabilirsiniz. Yönlendiricinin görebildiği bir sinyal eklemek — bir güven puanı, erişilen belgelere dayalı bir temellendirme kontrolü, iki ucuz model arasındaki uyuşmazlık — tavanı yükselten şeydir ve her birinin bir bedeli vardır.

Tasarrufu kalite sütunu olmadan raporlamayın. 3B→27B cascade’i, yalnızca büyük modele göre alan doğruluğunda 3,0 puan, tam eşleşmede 15 puan geride. Bunun kabul edilebilir olup olmadığı bir ürün kararıdır ve ancak iki sayı da masadaysa verilebilir.

Wall-clock süreleri (gerçekte geçen süre) kaydedildi ama maliyet olarak raporlanmıyor: ölçüm, aynı işin süresinin koşudan koşuya on kat kadar değişebildiği, başka işlerle paylaşılan bir dizüstü bilgisayarda yapıldı. Asıl yükü taşıyan sayılar aktarma oranı ile token sayılarıdır; sizin fiyatlarınıza uyarlanabilen de onlardır.

38.7.3 Diğer yöntemler, deneme sırasıyla

Bölüm 31 sıralamayı kurdu ve bu bölümün ölçümü onu tamamlıyor. Önce prompt önbellekleme ve gerçekten gereksiz token’ları çıkarmak, çünkü kalite riski taşımıyorlar: önbellekleme aynı girdiyi daha ucuza işliyor. Bölüm 31, sıcak prefill’in 12–16 ms’de sabit kaldığını, bunun da 4.247 token’da isteğin tamamını 9,0 kat hızlandırdığını ölçtü; bu yerel bir modelde ölçülmüş bir gecikme kazancı. API faturasındaki tasarruf ise sağlayıcının önbellekli girdi token’ına uyguladığı indirime bağlı (bazı sağlayıcılar önbelleğe yazmayı ayrıca ücretlendirir). Modelin gerçekten kullandığı bağlamı kesmek ise farklı bir yöntem; kaliteyi düşürebilir, dolayısıyla değerlendirmede sınanmalı. Sonra gecikmenin kullanıcıya yansımadığı yerlerde batch (toplu işleme) API’leri. Sonra kalite riski taşıyan ve artık bir sayısı olan cascade. En son da bir ayar değil, başlı başına birer proje olan damıtma ve nicemleme.

38.8 Güvenli yolu hızlı yol yapmak

Bir inceleme kuyruğuna bağlı yönetişim her seferinde aynı noktada çöküyor: bir takımın yetiştirmesi gereken bir son tarih olduğunda. Alternatif, denetimleri varsayılan yola koymak.

Bir ajan kayıt defteri (agent registry; Bölüm 39, destek ajanı için örnek bir satırını veriyor): her ajan için araçlarını, veri erişimini, sahibini, hukuki dayanağını ve geri alınabilirlik profilini listeleyen bir satır. Her denetimin, her olay incelemesinin ve her maliyet incelemesinin ihtiyaç duyduğu belge budur ve olaydan sonra güvenilir biçimde yeniden kurulamaz: en fazla, ayakta kalan başka kayıtların (fatura, erişim log’ları) izin verdiği parçalar toplanabilir.

Bir golden path (gerekli kontrolleri hazır içeren, desteklenen standart yol): değerlendirme kapısının (Bölüm 35), maliyet boyutlarıyla izlemenin (Bölüm 34), kişisel veri sınırının (Bölüm 37) ve araç sınıflandırmasının hazır bağlandığı bir şablon depo. Başarının ölçüsü, kurallara uygun yolun aynı zamanda yayına almanın en hızlı yolu olması.

İlk ajandan itibaren maliyet atfı, çünkü Bölüm 34’ün boyutları geriye dönük güvenilir biçimde eklenemez ve yukarıdaki birim ekonomisi onlar olmadan imkânsız. Bunu, geçitte (Bölüm 32) uygulanan takım ya da API anahtarı başına token bütçeleriyle eşleştirin; böylece kontrolden çıkmış bir ajan döngüsü bir fatura değil bir alarm olur.

Sabitlenmiş sürümlerle bir model kayıt defteri (Bölüm 32); her sürümün yanında sağlayıcının model kartı ya da belgeleri saklanır. Bu aynı anda bir maliyet denetimi, bir kalite denetimi ve bir uyum belgesidir: Yapay Zekâ Yasası’nın yüksek riskli sistemler için getirdiği kayıt tutma ve dokümantasyon yükümlülükleri, bir çıktıyı hangi sistem sürümünün ürettiğinin izlenebilmesini istiyor.

38.9 Sezgi kontrolleri

Her birini açmadan önce cevaplayın. İlk üçü değişmiş ya da yaygın biçimde yanlış hatırlanan hukuki olgular; son üçü ölçümü taşıyor.

Yalnızca kısmen. Erteleme esas olarak yüksek riskli kademeler için geçerli ve onu genel bir erteleme gibi okumak yaygın ve pahalı bir hata.

27 Temmuz 2026’da yürürlüğe giren (AB) 2026/1744 sayılı Tüzük — Dijital Omnibus — Ek III kapsamındaki yüksek risk yükümlülüklerini 2 Ağustos 2026’dan 2 Aralık 2027’ye, Ek I kapsamındakileri 2 Ağustos 2028’e erteledi. Diğer tarihlerin çoğu korundu: 2 Şubat 2025’ten beri yasak uygulamalar ve yapay zekâ okuryazarlığı (okuryazarlık yükümlülüğünün içeriği yumuşatıldı), 2 Ağustos 2025’ten beri GPAI yükümlülükleri, 2 Ağustos 2026’dan itibaren 50. madde şeffaflık yükümlülükleri. Ama değişiklik belirli geçiş istisnaları da içeriyor; aralarında piyasada zaten bulunan bazı sistemler için Madde 50(2) kapsamında 2 Aralık 2026’ya kadar bir geçiş süresi var. Yukarıdaki takvim bunları listeliyor.

Yani yükümlülüğünüz şeffaflıksa — insanlara bir makineyle konuştuklarını söylemek, sentetik içeriği işaretlemek — çoğu ertelenmedi ve istisnalar, varsaymak yerine takvimden kontrol edilecek kadar dar. Ve Aralık 2027 tarihi bir öneri değil, şu an bağlayıcı hukuk.

Sizin, hem de tasarım aşamasında. O sağlayıcıyı seçmek, KVKK 9. madde kapsamında kişisel verinin yurt dışına aktarılmasıdır; sonra halledilecek bir platform ayrıntısı değil.

7499 sayılı Kanunla yeniden yazılan ve 1 Haziran 2024’te yürürlüğe giren değişik 9. madde kademeli bir yapı veriyor: bir yeterlilik kararı ya da dört uygun güvenceden biri (kamu kurumları arasında uluslararası sözleşme niteliğinde olmayan bir anlaşma ve Kurul izni; Kurulca onaylanmış bağlayıcı şirket kuralları; Kurulca ilan edilen standart sözleşme; ya da yazılı bir taahhütname ve Kurul izni) ya da üzerine ürün kurmamanız gereken dar bir istisna. Açık rıza da dâhil olmak üzere istisnalar yalnızca arızi, tekrarlanmayan aktarımları kapsıyor.

Kaçırılan ayrıntı: bir standart sözleşme imzalanmasından itibaren beş iş günü içinde Kuruma bildirilmelidir. Bu, bir satın alma kararına bağlı, süreli bir yükümlülüktür ve sözleşmeyi imzalayan kişiyle entegrasyonu yapan kişi farklı kişiler olduğu için kaçırılır.

Satırı silmekten çok daha fazlası. Bu listenin uzunluğu, silme taleplerini geldikçe ele almak yerine sistemi baştan onlara göre tasarlamanın nedeni.

Verisi ayrıca vektör deposunda, iz arka ucunda (Bölüm 34), değerlendirme kümesinde (Bölüm 35), prompt önbelleğinde (Bölüm 31) ve Bölüm 37’nin token eşlemesinde duruyor; bunların hiçbirini kimse veri tabanı olarak düşünmüyor.

Veri fine-tune edilmiş bir modele ulaştıysa, o katkıyı güvenilir biçimde çıkarmak hâlâ zor ve yönteme bağlı. Model ağırlıklarının kişisel veri içerip içermediği bile tartışmalı ve somut olaya bağlı bir soru; bu sorunun ürününüz için gündeme gelmesini istememenizin sebebi de bu. Pratik cevap daha iyi bir silme hattı değil, kişisel veriyi eğitim kümelerine hiç koymamaktır; bu da tekrar tekrar gelen bir talep yerine tek bir tasarım kararıdır. Bilinmesi gereken iki sınır daha var. Silme hakkının istisnaları vardır: yasal bir saklama yükümlülüğü ya da bir hakkın tesisi, kullanılması veya korunması. Ayrıca gerçekten anonim hâle getirilmiş veri, veri koruma mevzuatının tümüyle dışında kalır; takma adlandırılmış (pseudonymised: kimliğe ancak ayrı tutulan ek bilgiyle bağlanabilen) veri ise kapsamda kalır. Sıkı bir incelemeden geçebilecek bir anonimleştirme, bariz tanımlayıcıları silmekten zordur. İlk talep gelmeden önce her depoda ne olacağını yazın, çünkü süre — GDPR’da bir ay, KVKK’da otuz gün — talep geldiği anda işlemeye başlar.

Dört yerel modelle 100 maddelik bir bilgi çıkarma süiti üzerinde ölçüldü: isteklerin %20’sini büyük modele göndermek alan doğruluğunu %92,40’tan (tek başına 3B) %97,00’a taşıdı; her şeyde büyük model için %100,00’a karşı — beşte bir istek karşılığında farkın %61’i.

Ekonomik hesap varsayımsal fiyatlar gerektirmiyor, ama sizin fiyatlarınızı gerektiriyor. Küçük modelin parasını her istekte, büyüğün parasını yalnızca aktarılan payda ödüyorsunuz; dolayısıyla K maliyet oranında cascade, yalnızca büyük model kullanmanın \((1 + 0{,}20K)/K\) kadarına mal oluyor: \(K = 10\)’da faturanın %30’u, \(K = 30\)’da %23’ü. Bunlar varsayılan bir orandan hesaplanmış senaryolar, ölçülmüş bir sağlayıcı faturası değil: doğruluk sütunu ölçüldü, yüzdeler aritmetik. Kendi \(K\)’nızı koyun ve onu hesaplarken girdi ile çıktı token fiyatlarının oranının farklı olduğunu hesaba katın.

Kalite sütununu da raporlayın: o cascade, yalnızca büyük model kullanmaya göre alan doğruluğunda 3,0 puan, tam eşleşmede 15 puan geride. Kalite sütunu olmadan verilen bir tasarruf rakamı sonuç değildir.

Bir öngörücü yerine bir doğrulayıcıyı tercih edin.

Bölüm 12, bir modelin sözel güvenini kendi hatalarının dedektörü olarak sınadı ve AUROC değerini 0,667 buldu (aynı görevde fine-tune edilmiş ayrı bir sınıflandırıcının, BERTurk’ün softmax olasılığı 0,843 aldı): gerçek bir sinyal, ama körlemesine yönlendirmeye yetmiyor. Buradaki cascade bunun yerine ucuz modeli çalıştırıyor ve çıktısını kontrol ediyor: ayrıştırılıyor mu, tüm alanlar var mı, her biri beklenen biçimine uyuyor mu. Bu, henüz çalıştırmadığınız bir istek hakkında bir tahmin değil, zaten elinizde olan bir çıktı hakkında bir olgudur; referans cevaplara da bakmıyor, dolayısıyla üretimde olduğu gibi çalışıyor.

Hayır — cascade’in hiçbir şey yapmadığı ve tekniğin tamamının sınırını gösterdiği anlamına geliyor.

Ölçüldü: qwen3.5:9b, alanların yalnızca %97,80’inde doğru olmasına rağmen biçim doğrulayıcısını 100 maddenin 100’ünde geçti. Dolayısıyla hiçbir şey aktarılmadı, cascade 9B modelden ibaret kaldı ve o modeli doğrudan kullanmaya göre hiçbir şey kazandırmadı.

Ders genelleşiyor. Bir doğrulayıcı iyi biçimliliği kontrol ediyor ve model güvenilir biçimde iyi biçimli olur olmaz iyi biçimliliğin doğrulukla ilişkisi kalmıyor — içinde yanlış şehir olan kusursuz biçimlendirilmiş bir JSON nesnesi, doğru cevabı bilmeyen hiçbir kontrol için görünmüyor. Tavanı yükseltmek, yönlendiricinin görebildiği bir sinyal eklemek demek: bir güven puanı, bir temellendirme kontrolü ya da iki ucuz model arasındaki uyuşmazlık. Her birinin bir bedeli var.

38.10 Mülakat soruları

Kaynak konusunda — Bölüm 2’deki çekincenin aynısı. Bu sorular, kitabın kullandığı iki güvenilir açık kaynakta tekrar tekrar geçiyor; bunlara bu bölümün kendi ölçümüyle cevaplanabilen sorular eklendi.

38.10.1 Yükümlülükleri anlayıp anlamadığınızı sınayanlar

S: Müşteri mesajlarını bir LLM sağlayıcısına göndermenin hukuki dayanağı nedir?

Bunun genellikle açık rıza olmadığını söyleyerek başlayın: destekle iletişime geçen bir müşteri, üçüncü tarafın verisini işlemesine rıza göstermiş değildir ve bu rızayı kullanım koşullarına gömmek, iki düzenlemenin de engellemek istediği örüntüdür. Çoğu sistem meşru menfaate ya da sözleşmenin ifasına dayanıyor; meşru menfaat için bu, denge testini belgelemek demek. Sonra iki tuzağı adlandırın: amaçla sınırlılık, çünkü sipariş verisini fine-tuning için yeniden kullanmak kendi dayanağını gerektiren yeni bir amaçtır; ve yurt dışına aktarım, çünkü ABD’de barındırılan bir sağlayıcı seçmek doğrudan 9. madde sorusudur ve entegrasyon yazılmadan önce cevaplanmalıdır.

S: Sisteminiz AB Yapay Zekâ Yasası kapsamında yüksek riskli mi?

Çoğu destek ajanı değil; yüksek riskli olanlar da genellikle istihdama, krediye, eğitime ya da temel hizmetlere dokunduğu için öyle oldu. Sonra takvimi taslak hâliyle değil, şu anki hâliyle bildiğinizi gösterin: (AB) 2026/1744 sayılı Tüzük, Ek III kapsamındaki yüksek risk yükümlülüklerini 2 Aralık 2027’ye, Ek I kapsamındakileri 2 Ağustos 2028’e erteledi; yasaklar, GPAI yükümlülükleri ve yeni piyasaya sürülen sistemler için 50. madde şeffaflığı ise özgün tarihlerini korudu. Tüzük ayrıca Aralık 2026’dan itibaren geçerli iki yeni yasak ekledi. Bu ayrımı yapmadan “Yasa ertelendi” demek yanlış cevaptır.

S: Bir denetim log’una bir izde olmayan ne girer?

Yetki. Bir iz bir iade yapıldığını söyler; bir denetim kaydı bunun bu kullanıcı adına, bu onayla, bu yetkili kişi tarafından, bu bölgede, bu hukuki dayanakla yapıldığını söyler. Yalnızca ekleme yapılabilir, kendi saklama takvimi vardır ve ajanlar için eylemin yanı sıra eyleme geçme kararını da kaydetmelidir — ajan bir aracı seçtiğinde bağlamında ne olduğu, her olay incelemesinin sorduğu sorudur (Bölüm 36).

38.10.2 Bir sistemi gerçekten işletip işletmediğinizi sınayanlar

S: CFO’nuz yapay zekâ özelliğinin neye mal olduğunu soruyor. Ne raporlarsınız?

İstek ya da oturum başına değil, çözülen görev başına maliyet — birincisi cevabı çok sayıda küçük çağrıya bölen sistemleri, ikincisi kimsenin tamamlamadığı özellikleri olduğundan iyi gösteriyor. Takımların dışarıda bıraktıklarını dâhil edin: yeniden denemeler, tavana çarpmalar, çevrimiçi hakem çağrıları, embedding’ler ve insana aktarılan vakaları ele alan kişinin maliyeti; sonuncusu genellikle en büyük kalemdir ve başkasının bütçesinde durur. Sonra bunu bir iş gerekçesine dönüştüren karşılaştırmayı verin: aynı “çözüldü” tanımıyla, yalnızca insanların çalıştığı baseline. Aritmetik, token fiyatından çok çözüm oranına duyarlıdır.

S: Kaliteyi yitirmeden çıkarım maliyetini nasıl yarıya indirirsiniz?

Kalite riski sırasıyla. Önce prompt önbellekleme ve gerçekten gereksiz token’ları çıkarmak, çünkü hiç risk taşımıyorlar — önbellekleme aynı girdiyi işliyor ve Bölüm 31’de sıcak prefill 12–16 ms’de sabit kaldı ve 4.247 token’da isteğin tamamını 9,0 kat hızlandırdı. Bu bir gecikme kazancı; faturadaki karşılığı sağlayıcının önbellekli girdi token’ına uyguladığı indirime bağlı. Modelin kullandığı bağlamı kesmek bedava değil; değerlendirmede verilecek bir kalite kararı. Sonra gecikmenin kullanıcıya yansımadığı yerlerde batch API’leri. Sonra sayısı bilinen bir cascade: isteklerin %20’sini aktarmak burada kalite farkının %61’ini geri kazandırdı ve 10 katlık fiyat oranında büyük model faturasının %30’una mal oldu. En son da başlı başına birer proje olan nicemleme ve damıtma.

S: Cascade’inizin yönlendiricisi bir şema doğrulayıcısı. Neye körsünüz?

İyi biçimli olan ve yanlış olan her şeye. Burada ölçüldü: 9B model, alanların %97,80’inde doğru olmasına rağmen doğrulayıcıyı 100 maddenin 100’ünde geçti; dolayısıyla cascade hiçbir şey aktarmadı ve hiçbir şey kazandırmadı. Genel ifade şu: bir doğrulayıcının tavanı görebildiğidir ve modeller iyileştikçe iyi biçimlilik doğruluktan ayrışır. Daha ileri gitmek için doğruluk hakkında bir sinyale ihtiyacınız var — güven, temellendirme ya da iki ucuz model arasındaki uyuşmazlık — ve bunların her birinin, benimsemeden önce ölçmeniz gereken bir bedeli var.

38.11 2026 alet çantası

Ölçüm için dört model ve Python’un standart kütüphanesi yetti. İkinci tablodaki araçlar iki gruba ayrılıyor: maliyeti ölçenler (litellm, tiktoken, langfuse) ve uyumu destekleyen presidio-analyzer.

Bu sayıları üreten yazılım yığını (Apple Silicon üzerinde)
kütüphane kullanılan sürüm burada ne işe yarıyor
ollama 0.24.0 cascade merdiveninin dört modelinin tamamını servis ediyor
Python standart kütüphanesi 3.14.5 düzenek ve doğrulayıcı; bağımlılık yok

Yukarıda kullanılmayan ama bilinmesi gereken araçlar:

Daha geniş ekosistem, yazım anındaki sürümler
proje sürüm ne zaman başvurursunuz
litellm 1.99.0 Bölüm 32’nin geçidi; birim ekonomisini hesaplanabilir kılan şey API anahtarı başına bütçeler ve harcama atfı
tiktoken 0.14.0 token’ları göndermeden önce saymak; maliyet tahmini böylece gönderim öncesi bir kontrole dönüşüyor
langfuse 4.15.1 maliyeti ekli izler; böylece çözülen görev başına maliyet bir hesap tablosu değil bir sorgu oluyor
presidio-analyzer 2.2.364 veri bir sağlayıcıya ulaşmadan önce var olması gereken kişisel veri sınırı (Bölüm 37)

38.12 Lab: uyum ve maliyet geçişi

38.12.1 Adım 1 — kopyalar dâhil veri akışını yazın

Bir sayfa: hangi kişisel veri giriyor, hangi depolar tutuyor, hangileri bölgenizden çıkıyor ve her biri ne kadar saklıyor. İz arka ucunu, değerlendirme kümesini, önbelleği ve token eşlemesini dâhil edin. İnsanların unuttuğu kopyalar bulgunun kendisi.

38.12.2 Adım 2 — aktarım sorusunu cevaplayın

Her sağlayıcı için 9. maddenin hangi yoluna dayandığınızı yazın. Bu bir standart sözleşmeyse, beş iş günü içinde Kuruma bildirilip bildirilmediğini öğrenin; kimse bilmiyorsa teslim edeceğiniz bulgu budur.

38.12.3 Adım 3 — sisteminizi Yapay Zekâ Yasası kapsamında sınıflandırın

Yasak, yüksek riskli, sınırlı ya da asgari; gerekçesiyle birlikte yazın. Sonra güncel tarihleri bu bölümden değil, mevzuatın kendisinden kontrol edin ve kontrol ettiğiniz tarihi kaydedin.

38.12.4 Adım 4 — bir silme talebini bütün depolarda baştan sona izleyin

Bir test kullanıcısı oluşturun (ya da izinle gerçek bir kimlik seçin) ve adım 1’deki her depoda ne olması gerektiğini izleyin. Süre tutun. Cevaplayamadığınız her şey bir süreç boşluğu değil, bir tasarım görevidir.

38.12.5 Adım 5 — çözülen görev başına maliyeti hesaplayın

Yeniden denemeleri, tavana çarpmaları, hakem çağrılarını, embedding’leri ve insana aktarma maliyetini dâhil edin. Aynı “çözüldü” tanımıyla, yalnızca insanların çalıştığı baseline’la karşılaştırın. Sonra sonucun çözüm oranına ne kadar duyarlı olduğunu hesaplayın.

38.12.6 Adım 6 — kendi cascade’inizi ölçün

Süitinizi iki modelde çalıştırın, referans cevaplara hiç bakmayan bir çalışma zamanı doğrulayıcısı kurun, aktarma oranını ve ortaya çıkan kaliteyi ölçün. Tasarrufu kendi fiyat oranınızın bir fonksiyonu olarak raporlayın ve kalite düşüşünü yanına koyun.

38.12.7 Adım 7 — doğrulayıcınızın kör noktasını bulun

Doğrulayıcınızın kabul ettiği maddeleri alın ve kaçının gerçekten yanlış olduğunu sayın. O sayı, bir cascade’in sizin için yapabileceğinin tavanı ve daha iyi bir sinyale yatırım yapıp yapmayacağınıza karar veren sayı.

38.12.8 Teslim edilecekler

Her kopyanın listelendiği veri akışı sayfası; sağlayıcı başına 9. madde dayanağı ve bildirim durumu; tarihleri kontrol ettiğiniz tarihle birlikte Yapay Zekâ Yasası sınıflandırmanız; silme talebinin depo depo izlenmesi ve bulunan boşluklar; yalnızca insanla çalışan baseline’a karşı çözülen görev başına maliyet; ve cascade’inizin aktarma oranı, kalite düşüşü ve doğrulayıcınızın kör nokta sayısı.

38.13 Alıştırmalar

  1. Kopyalar envanteri. Sisteminizde kullanıcı metninin bir kopyasını tutan her depoyu listeleyin. Bir silme talebinin şu anda onlara ulaşıp ulaşmadığına göre sıralayın.

  2. Bir sözleşme okuyun. Model sağlayıcınızın gerçek koşullarını alın — pazarlama sayfasını değil, üzerinde olduğunuz katmanı — ve dört olgu çıkarın: işleme bölgesi ve devretme, verinizle eğitim, saklama süresi, alt işleyen bildirimi. Hangisini bulamadığınızı not edin.

  3. Dürüstçe sınıflandırın. Yapay Zekâ Yasası sınıflandırmanızı yazın ve sonra bir paragrafta karşı savı savunun. Karşı savı savunmak kolaysa hukuki görüş alın.

  4. Çözülen görev başına maliyet. İnsana aktarma maliyetini dâhil ederek hesaplayın, sonra çözüm oranını 10 puan artırıp 10 puan azaltarak yeniden hesaplayın. İş gerekçesinin hangi girdiye en duyarlı olduğunu raporlayın.

  5. Kendi aktarma oranınız. Kendi çıktınız için bir şema doğrulayıcısı kurun ve küçük bir modelin cevaplarının yüzde kaçını reddettiğini ölçün. Bunu kendi fiyat oranınızda bir tasarrufa çevirin.

  6. Kör nokta. Doğrulayıcınızın kabul ettiği çıktılardan ellisini doğruluk için elle kontrol edin. Oranı raporlayın ve daha iyi bir yönlendirici kurmaya değip değmeyeceğini söyleyin.

  7. Tarih kayması. Uyum planınızın dayandığı üç düzenleyici tarihi alın ve her birini güncel mevzuata karşı doğrulayın. URL’yi ve kontrol ettiğiniz tarihi kaydedin, sonra bunu yeniden yapmak için bir hatırlatıcı kurun.

38.14 Daha derine

Okumadan önce: ürününüzün hangi hukuki dayanağa dayandığını ve verisinin nerede işlendiğini ezberden yazın. Sonra kontrol edin. İkisi arasındaki boşluk bu bölümün konusu.

Bu bölüm makale kaynakçası içermediği için yalnızca bir okuma tablosu var. Aşağıdaki kaynakların çoğu birincil bir mevzuat ya da onun resmî rehberi, çünkü bu malzemede ikincil özetler sessizce bayatlıyor — Temmuz 2026 değişikliğinin gösterdiği gibi. İlk satırdaki takvim izleyicisi iyi bakılan ikincil bir kaynak ve elinizin altında bulunsun; bir tarihe dayanmadan önce AB Resmî Gazetesi metniyle karşılaştırın.

Bu bölümün ötesi
kaynak ne olduğu
AB Yapay Zekâ Yasası uygulama takvimi 2026 değişiklikleri dâhil güncel tutulan ikincil bir izleyici; kullanışlı ama bağlayıcı kaynak değil
(AB) 2026/1744 sayılı Tüzük — EUR-Lex Yapay Zekâ Dijital Omnibus’un kendisi — yürürlükteki değişiklik maddeleri; geçiş hükümlerinin tam metnini bulabileceğiniz tek yer
KVKK — yurt dışına aktarım Kurumun değişik 9. madde hakkındaki kendi sayfası; standart sözleşmeler ve bildirim modülü ile birlikte
KVKK — Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda) Kurumun Kasım 2025’te yayımladığı rehber; bu bölümün KVKK kısmına Türkçe yazılmış en doğrudan birincil kaynak
NIST Yapay Zekâ Risk Yönetimi Çerçevesi AI RMF 1.0 (Eylül 2026 itibarıyla revizyonda) ve Üretken Yapay Zekâ Profili (AI 600-1); on iki risk kategorisi bu bölümdeki en yararlı kontrol listesi
ISO/IEC 42001:2023 yapay zekâ yönetim sistemi standardı; gönüllü ve belgelendirilebilir, kurumsal satın almalarda giderek daha çok isteniyor
FinOps Çerçevesi bu bölümün ödünç aldığı maliyet yönetimi sözlüğü — bilgilendir, eniyile, işlet — yeni bir tür değişken maliyete uygulanmış
litellm API anahtarı başına bütçeler ve harcama atfı; Bölüm 32’nin tek geçiş noktasından (choke point) birim ekonomisine pratik yol

38.15 Akılda kalması gerekenler

  • Hukuki dayanak nadiren açık rızadır ve LLM projeleri en çok amaçla sınırlılıkta tökezler. Bir siparişi yerine getirmek için toplanıp fine-tuning için yeniden kullanılan veri, kendi dayanağını gerektiren yeni bir amaçtır. LLM ürünlerindeki en yaygın uyum ihlali bir sızıntı değil; başka bir şey için toplanmış veriyle eğitim yapmaktır.

  • Model sağlayıcısı seçmek, tasarım zamanında verilen bir aktarım kararıdır. 7499 sayılı Kanunla yeniden yazılan (1 Haziran 2024’te yürürlükte) KVKK 9. maddesi önce yeterliliği, sonra dört uygun güvenceyi, sonra dar istisnaları veriyor. Bir standart sözleşme imzalanmasından itibaren beş iş günü içinde Kuruma bildirilmelidir — bir satın alma kararına bağlı, süreli bir yükümlülük.

  • Yapay Zekâ Yasası’nın yüksek risk tarihleri ertelendi; tek değişiklik bu değildi. 27 Temmuz 2026’da yürürlüğe giren (AB) 2026/1744 sayılı Tüzük, Ek III’ü 2 Aralık 2027’ye, Ek I’i 2 Ağustos 2028’e ve ulusal kum havuzlarını Ağustos 2027’ye erteledi. Ayrıca 2 Aralık 2026’dan itibaren geçerli iki yeni yasak ekledi, piyasada zaten bulunan sistemlere Madde 50(2) için o tarihe kadar süre tanıdı ve yapay zekâ okuryazarlığı yükümlülüğünü yumuşattı. Yasaklar (Şubat 2025), GPAI yükümlülükleri (Ağustos 2025) ve yeni piyasaya sürülen sistemler için 50. madde şeffaflığı (Ağustos 2026) tarihlerini korudu. “Yasa ertelendi” özeti, çoğu takımın gerçek yükümlülükleri için yanlış.

  • Silme, kimsenin listelediğinden daha fazla depoya ulaşır. Vektör deposu, izler, değerlendirme kümesi, prompt önbelleği, token eşlemesi — ve bir kişinin katkısını güvenilir biçimde çıkarmanın hâlâ zor olduğu, fine-tune edilmiş bir model. Talep geldikçe ele almak yerine sistemi bir kez buna göre tasarlayın.

  • Bir denetim log’u yalnızca eylemi değil yetkiyi kaydeder, yalnızca ekleme yapılabilir, kendi saklama takvimini tutar ve ajanlar için eylemin yanı sıra eyleme geçme kararını da yakalamalıdır.

  • Çözülen görev başına maliyeti raporlayın; yeniden denemeler, tavana çarpmalar, hakem çağrıları ve insana aktarma maliyeti dâhil. Sonuncusu genellikle en büyük kalemdir ve başkasının bütçesinde durur. İş gerekçesi, token fiyatından çok çözüm oranına duyarlıdır.

  • Cascade, etkisi ölçülmüş gerçek bir maliyet düşürme yöntemidir. İsteklerin %20’sini büyük modele aktarmak alan doğruluğunu %92,40’tan %97,00’a taşıdı; yalnızca büyük model kullanıldığında %100,00. Bu, beşte bir istek karşılığında farkın %61’ini kapatıyor ve büyük model faturasının \((1+0{,}2K)/K\) kadarına, yani 10 katlık fiyat oranında %30’una mal oluyor. Kalite düşüşünü de yanında raporlayın: alan doğruluğunda 3,0 puan, tam eşleşmede 15 puan.

  • Öngörülen zorlukla değil, bir doğrulayıcıyla yönlendirin. Bölüm 12’de sözel güven, bir modelin kendi hatalarının dedektörü olarak yalnızca 0,667 AUROC aldı; fine-tune edilmiş ayrı bir sınıflandırıcının (BERTurk) softmax olasılığı ise 0,843’e ulaştı. Bir şema ve biçim kontrolü ise zaten elinizde olan bir çıktı hakkında bir olgudur, referans cevaplara bakmaz ve üretimde olduğu gibi çalışır.

  • Bir doğrulayıcının tavanı görebildiğidir. 9B model, alanların yalnızca %97,80’inde doğru olmasına rağmen biçim kontrolünü 100 maddenin 100’ünde geçti; dolayısıyla onunla kurulan cascade isteklerin %0’ını aktardı ve hiçbir şey kazandırmadı. Model güvenilir biçimde iyi biçimli olur olmaz iyi biçimliliğin doğrulukla ilişkisi kalmaz — daha ileri gitmek doğruluk hakkında bir sinyal gerektiriyor ve böyle her sinyalin bir bedeli var.