yapay-zeka

    KVKK Uyumlu Yapay Zekâ Rehberi: 5 Katmanda Pratik Mimari

    Kurumsal AI sistemlerinin KVKK ile uyumlu çalışması için 5 katmanlı mimari rehber: veri lokasyonu, açık rıza, anonimleştirme, yurt dışı API riski ve denetim izi. eCloud Tech mühendislik notu.

    Yayım: 25 Mayıs 20269 dk okuma
    kvkkyapay-zekaai-governanceaigency

    Yapay zekâ projelerinin önündeki en sık karşılaşılan engel, modelin teknik kalitesi değil; KVKK uyumunun sonradan eklenememesidir. Bir prototip iki haftada çalıştırılır, ama o prototipi kurumsal üretime almak için yapılan KVKK refactor'u çoğu zaman üç ay sürer. Bizim yapay zekâ yönetişim hizmetimizin son 18 ayda gözlemlediği şu: KVKK'yı projeye ne kadar erken dahil ederseniz toplam maliyet o kadar düşer. Gün bir KVKK mimarisi, eklenti mimariden 3-5 kat daha ucuza mal olur.

    Bu yazı, kurumsal yapay zekâ kurulumunun KVKK ile uyumlu yapılması için beş katmanlı pratik mimariyi anlatıyor. Hukuki çerçeve, teknik uygulama, ve denetim hazırlığı birlikte. Mühendislik ekibimizin AIGENCY V4 platformunu KVKK uyumlu olarak inşa ederken ve müşteri projelerinde uygularken edindiği yedi pratiği sırayla paylaşıyoruz.

    1. Veri lokasyonu — KVKK md.9'un teknik anlamı

    KVKK md.9, kişisel verinin yurt dışına aktarımı için iki yol tanımlar: ya veri sahibinin açık rızası, ya da Kurul'un izinli ülke listesindeki bir ülkeye aktarım. Şubat 2026 itibarıyla bu listede ABD yok, AB ülkeleri "yeterli koruma" çerçevesinde, Türkiye sınırları dışındaki çoğu cloud sağlayıcı (AWS US, Azure US, GCP US) ise her sorguda md.9 değerlendirmesi gerektirir.

    Pratik anlamı şudur: ChatGPT API'ye gönderilen her kullanıcı sorgusu, sorguyu yapanın açık rızası olmaksızın KVKK ihlali kapsamına girebilir. Bunu çözmenin üç yolu vardır:

    Yol 1: Kişisel veriyi hiç göndermeyin. Sorgudan kişiye ait alanları (ad, soyad, telefon, e-posta, TC kimlik, IP) çıkarın; AI sistemine yalnız anonim bağlam gönderin. Bu yaklaşım için ön-işleme katmanı (PII redaction) zorunludur ve yanlış konfigürasyon halinde sızıntıya açıktır.

    Yol 2: Her kullanıcıdan açık rıza alın. Sorgu öncesinde "Bu verim yurt dışı AI hizmetine gönderilebilir" onayı; rıza kaydı denetlenebilir log'da tutulur. Kurumsal müşteri için kullanıcı sürtünmesi yaratır.

    Yol 3: Türkiye'de işlenen alternatif kullanın. AIGENCY V4 gibi Türkiye'de hosted, KVKK ile gün bir uyumlu tasarlanmış platformlar md.9 problemini doğrudan ortadan kaldırır. Mimari karar olarak en sürdürülebilir yaklaşımdır.

    Hangi yolu seçtiğinizden bağımsız olarak, mimari kararın dokümante edilmiş gerekçesi olmalıdır. KVKK denetiminde "neden bu yolu seçtiniz" sorusuna cevabınız yazılı olmazsa, denetim sürecinde sıkışırsınız.

    2. Açık rıza ve meşru menfaat — hangisinin nerede kullanıldığı

    KVKK md.5 işleme şartı olarak altı temel sunar; yapay zekâ projelerinde en sık kullanılan ikisi açık rıza (md.5/1-a) ve meşru menfaat (md.5/2-f). İkisi arasındaki seçim teknik değil hukuki bir karardır; ama mimari sonuçları çoktur.

    Açık rıza spesifik, bilgilendirilmiş ve özgür iradeyle verilen onaydır. AI bağlamında zorlu yanı: kullanıcının "ne için rıza verdiğini" anlamasıdır. "Yapay zekâ sistemimizde verilerinizin işlenmesini onaylıyor musunuz?" gibi geniş ifadeli rıza KVKK Kurulu mütalaalarında geçersiz sayılır. Doğru rıza metni: "Sağlık verilerimin (kan tahlili, görüntüleme sonuçları) yalnız tanı destek amacıyla, sadece eCloud Tech tarafından yönetilen yapay zekâ modülünde, Türkiye sınırları içinde işlenmesini onaylıyorum." — amaç + veri türü + işleyici + lokasyon dört unsuru içerir.

    Meşru menfaat veri sorumlusunun veya üçüncü tarafın menfaatinin, veri sahibinin temel hak ve özgürlüklerine üstün geldiği denge testidir. AI bağlamında düşük riskli kullanımlar için uygundur — örneğin müşteri destek chatbot'u, içerik kişiselleştirme, dolandırıcılık tespiti. Üç adımlı denge testi (LIA — Legitimate Interest Assessment) yazılı olarak yapılmalıdır:

    1. Meşru menfaat var mı? İş hedefi, somut fayda tanımlı mı.
    2. Gereklilik testi: Aynı sonuç daha az veri ile alınamaz mı.
    3. Dengeleme: Kullanıcının beklenmedik bir kullanım hissi olur mu; itiraz etme hakkı uygulanabilir mi.

    Pratik kural: özel nitelikli kişisel veri (sağlık, biyometrik, ırk, dini görüş vb.) söz konusuysa md.6 gereği açık rıza zorunludur; meşru menfaat bu kategoride yetmez. Standart kişisel veri içinse meşru menfaat çoğu B2B AI projesinde yeterli ve operasyonel olarak uygulanabilirdir.

    3. Anonimleştirme — geri dönüşü mümkün olmayan dönüşüm

    KVKK md.7, silme hakkını düzenler; ama AI sistemlerinde silme teknik olarak zor bir işlemdir çünkü veri model parametrelerine gömülmüş olabilir. Bu sorunun mimari çözümü anonimleştirmedir.

    Anonimleştirme, geri dönüşü mümkün olmayan veri dönüşümüdür. Sözde-anonimleştirme (pseudonymization — örneğin TC kimliği hash'leme) KVKK md.28'e göre hâlâ kişisel veri sayılır; çünkü hash anahtarına sahip kişi geri çözümleyebilir. Gerçek anonimleştirme için üç teknik birlikte uygulanır:

    K-anonimleştirme: Her kayıt, en az k başka kayıtla aynı görünmelidir. Örnek: doğum yılı + posta kodu + cinsiyet kombinasyonu, en az 5 kişide aynı olmalı (k=5). Tek başına bir kişiye işaret eden veri seti, daha geniş aralıklara (yıl→on yıl, posta→şehir) yuvarlanır.

    Differential privacy: Veri setine kontrollü gürültü eklenir, bireysel kayıtlar görünmez, agregat istatistikler bozulmaz. Apple ve Google bunu yıllardır kullanır; AI eğitim setlerinde de uygulanır.

    Sentetik veri üretimi: Gerçek veriye benzer ama hiçbir gerçek kişiye ait olmayan veri seti üretilir. AI eğitim için en güvenli yaklaşımdır; orijinal veriyle istatistiksel olarak uyumlu, ama silme/itiraz hakkı için risk taşımaz.

    Bizim pratiğimiz: AIGENCY V4 platformunda fine-tuning hattı, üç tekniği birlikte uygular; eğitim öncesi otomatik bir "kişisel veri risk değerlendirmesi" çalıştırılır, geçemeyen veri eğitim setine alınmaz. Bu mimari karar, sonradan model güncelleme veya silme taleplerinde kurumumuzu koruyor.

    4. RAG mimarisi — silme hakkı ile AI yetkinliğini birleştirmek

    Son katmanın AI mimarisindeki en zarif çözümlerden biri RAG (Retrieval Augmented Generation) yaklaşımıdır. RAG, kullanıcı verisini model parametrelerine gömmek yerine arama anında retrieve eder.

    Çalışma mantığı şudur: model genel bilgi (Türkçe dil, akıl yürütme, yaygın kavramlar) ile eğitilir; kurumsal veri ise ayrı bir vector database'de tutulur. Sorgu geldiğinde sistem önce vector database'den ilgili belgeleri alır, sonra modele "bu belgeler bağlamında cevap üret" der.

    RAG'ın KVKK avantajı net: silme hakkı geldiğinde, modeli yeniden eğitmenize gerek yoktur. Vector database'den ilgili kaydı silersiniz; sonraki sorgularda o kayıt retrieve edilmez. Bu mimari, KVKK md.7 ile teknik olarak tam uyumludur.

    RAG sistemleri kurulum hizmetimizde standart yapı:

    1. Vector database katmanı (pgvector / Qdrant / Weaviate): kurumsal dokümanlar embedding'lenip burada tutulur. Her dokümanın kaynak referansı ve KVKK metadata'sı (veri sahibi, işleme amacı, saklama süresi) etiketlenir.
    2. Retrieval katmanı: kullanıcı sorgusu embedding'lenir, semantik olarak en yakın N doküman çekilir. Yetkilendirme katmanı burada uygulanır — kullanıcının erişim yetkisi olmayan dokümanlar filtrelenir.
    3. Generation katmanı: modele retrieve edilen dokümanlar + sorgu gönderilir; model bu bağlamda cevap üretir.
    4. Citation katmanı: cevap kaynak dokümanlara referansla birlikte gelir — kullanıcı doğrulayabilir, denetçi denetleyebilir.

    Bu mimari, hem teknik açıdan üstün (model hallucination riski düşük, cevaplar kanıtlanabilir) hem KVKK açısından sürdürülebilirdir. Mevcut müşteri projelerimizin %70'i bu mimariyi kullanıyor.

    5. Yetkilendirme ve audit log — KVKK md.12'nin teknik karşılığı

    KVKK md.12 "veri güvenliği önlemleri"ni tanımlar; AI sistemlerinde bu maddenin teknik karşılığı rol-bazlı erişim kontrolü ve değiştirilemez audit log'dur.

    Rol-bazlı erişim: Hangi rol hangi veriye, hangi koşullar altında erişebilir? AI sistemlerinde bu özellikle kritik çünkü bir kullanıcı sorgusu birden fazla veri kaynağını tetikleyebilir. Örnek: bir doktor kendi hastasının tıbbi geçmişine erişebilir, ama başka bir doktorun hastasına erişemez. AI sisteminin retrieval katmanı sorgu öncesinde kullanıcının rolünü kontrol etmeli; aksi takdirde RAG sistemi farkında olmadan yetkisiz veri ifşa eder.

    Audit log: Her sorgu için aşağıdaki alanlar otomatik kaydedilir:

    • Zaman damgası (mikrosaniye hassasiyetinde)
    • Kullanıcı kimliği + rol
    • Erişilen veri kaynağı + spesifik kayıt ID'leri
    • Sorgu metni (PII redaction sonrası)
    • Cevap özeti
    • Çağırılan model + versiyonu
    • Yetkilendirme kontrolünün sonucu

    Bu log append-only tutulur (üzerine yazılamaz, silinemez), şifrelenerek saklanır, en az 12 ay geriye dönük erişilebilir olmalıdır. KVKK Kurulu denetim talebinde 24-48 saat içinde dump üretilebilmelidir.

    Önemli bir pratik not: audit log'un kendisi de kişisel veri içerir (sorguyu yapan kullanıcının kimliği). Log saklama süresi sonsuz olamaz; tipik olarak 24 ay sonra kullanıcı kimliği anonimleştirilir, sadece operasyonel istatistikler kalır. Bu mimari karar, KVKK md.4/2-d (sınırlı sürede saklama) ile uyumludur.

    6. Yurt dışı LLM API entegrasyonu — risk transferi pratiği

    Birçok kurum, kendi AI platformunu sıfırdan kurmak yerine yurt dışı LLM API'lerini kullanmak ister; maliyet ve hız avantajları somuttur. Ancak bu tercihin KVKK riskleri yönetilmezse pahalı sonuçlar doğurabilir.

    Risk azaltma katmanı zorunludur:

    RiskMimari önlem
    Kişisel verinin yurt dışı API'ye sızmasıSorgu öncesi otomatik PII redaction (regex + ML tabanlı detection)
    Açık rıza eksikliğiKullanıcı kaydında AI sorgusu için ayrı rıza modülü; rıza yoksa fallback to Türkiye'de hosted model
    API sağlayıcısının veriyi saklamasıAPI sözleşmesinde "do not log" + "do not train" maddeleri zorunlu; OpenAI Enterprise/Anthropic Business bu seçenekleri sunar
    Aktarım sırasında veri gözetimiTLS 1.3 zorunlu + sertifika pinning
    Sağlayıcı ihlali (data breach)Olay sonrası 72 saat içinde KVKK Kurulu'na bildirim hazırlığı (md.12/5)

    Pratik bir vaka: 2025 başında danışmanlık verdiğimiz bir hukuk firması, GPT-4 ile dilekçe taslağı üretiyordu. Yaptığımız değerlendirme: müvekkil verileri açık rıza olmadan OpenAI'ye akıyordu, sözleşmede "do not train" maddesi yoktu, audit log eksikti. Üç haftalık refactor ile yapı şu hale geldi: PII redaction katmanı + müvekkil rızası + AIGENCY V4'e (Türkiye-hosted) fallback + her sorgunun kanıt zinciri kaydı. Refactor sonrası firma KVKK denetiminden sorunsuz geçti.

    Bizim önerimiz: kişisel veri içeren projelerde birincil AI platformu Türkiye-hosted olsun; yurt dışı API'leri yalnız anonim bağlamda veya ek rıza katmanıyla kullanın. Bu, "ya hep ya hiç" değil, dengeli bir yaklaşımdır.

    7. Denetim hazırlığı — proaktif yaklaşım

    KVKK denetimi geldiği gün başlamaz; gelmeden önce hazırlanmış olmalıdır. Bizim müşteri projelerimizde standart denetim hazırlık paketi şu beş bileşeni içerir:

    Bileşen 1: Veri akış diyagramı (DPIA — Veri Koruma Etki Değerlendirmesi). Kişisel verinin sistemde nereden girdiği, nerede işlendiği, nereye gittiği, ne kadar süreyle saklandığı; her okun üzerinde hukuki temel etiketli. Standart bir mimari diyagram değil; KVKK formatında hazırlanmış olmalı.

    Bileşen 2: Açık rıza envanteri. Hangi rıza türünden kaç tane var, ne zaman alınmış, hangi sürümüne dayalı. Rıza metni değiştiğinde eski rızalar geçersizleşir mi sorusunun cevabı yazılı olmalı.

    Bileşen 3: Audit log dump şablonu. Denetçi geldiğinde "şu kullanıcının son 6 ayındaki tüm AI sorgularını gösterin" talebinin cevabı kaç dakikada üretilebilir? 24 saatten uzunsa risk vardır.

    Bileşen 4: Veri ihlali müdahale planı. md.12/5 gereği 72 saatlik bildirim süresine uyabilmek için iç süreç yazılı olmalı; kimin haberdar edileceği, kararı kimin vereceği, bildirim metnini kimin yazacağı belli olmalı.

    Bileşen 5: Sürekli güncel kayıt (VERBİS — Veri Sorumluları Sicili). Kurum VERBİS kaydı varsa, AI sisteminin eklenmesi/güncellenmesi kayıtlı olmalı. VERBİS güncel değilse denetim ek soru getirir.

    Bu beş bileşeni başlangıçtan itibaren mimariye gömen kurum, denetimi sıradan bir gün gibi geçirir. Sonradan ekleyen kurum, denetimi kriz gibi yaşar.

    Bizim pratiğimizde bu beş bileşen her AI projesinin teslim paketinin parçasıdır; ayrı bir kalem değildir. Bir müşteri "denetim ne zaman gelirse hazır olsun" diye sipariş etmez — varsayılan davranıştır. Bu yaklaşımın somut faydası: son üç yılda yönettiğimiz altı KVKK denetiminin altısı da ek belge veya açıklama talebi olmadan kapandı. Denetim süresi ortalama dört iş gününde tamamlandı; benzer büyüklükteki sektör ortalaması iki ila üç haftadır.

    Karar matrisi: kurumunuza uygun yaklaşım

    Hangi mimari sizin için doğru? Üç soruyla pratik değerlendirme:

    SoruCevap → tavsiye
    AI sistemi özel nitelikli kişisel veri (sağlık, biyometrik, ırk vb.) işliyor mu?Evet → Türkiye-hosted (AIGENCY V4 sınıfı) zorunlu, açık rıza şart
    Kullanıcı verisinin model parametrelerine gömülmesi sorun yaratır mı (silme/itiraz hakkı)?Evet → RAG mimarisi zorunlu, fine-tuning yerine retrieval
    Yurt dışı LLM API kullanmak operasyonel zorunluluk mu?Evet → PII redaction + sözleşme maddeleri + rıza katmanı zorunlu

    Üç soruya "evet" cevabı veren bir kurum için tam KVKK uyumlu mimari kaçınılmazdır; iki "evet" ile hibrit yaklaşım mümkündür; bir "evet" ile standart kontrol seti yeterlidir.

    Bizim kurumsal AI platformu kurulum hizmetimiz, beş katmanı ve denetim hazırlığını standart paket olarak içerir — sonradan eklenti değil, gün bir mimari. Tipik proje süremiz 8-14 hafta; karmaşık çoklu sistem entegrasyonunda 20 haftaya uzayabilir.

    Sonraki adım

    KVKK uyumlu yapay zekâ kurulumu, "yapılır mı / yapılmaz mı" değil "hangi sınırlar içinde yapılır" sorusudur. Burada anlattığımız beş katman (veri lokasyonu, açık rıza, anonimleştirme, RAG mimarisi, yetkilendirme + audit) projenin tasarım aşamasında değerlendirilirse maliyet etkisi çoğu zaman %5-10 aralığında kalır; sonradan eklenirse aynı uyumu sağlamak %30-50 ek geliştirme süresi anlamına gelir.

    Kendi kurumunuzda AI kurulum planı yapıyorsanız, ekibimizle bir saatlik teknik görüşmeden önce yukarıdaki beş katmanı kendi cevaplarınızla doldurmanızı öneririz. Hangi katmanda boşluk olduğunu kendiniz fark etmek, sonraki adımları çok hızlandırır. İletişim sayfamız üzerinden ücretsiz ön görüşmeden talep alıyoruz; görüşmede beş katmanın sizin senaryonuza uyarlanmış değerlendirmesini birlikte yaparız.

    Bu konuda sıradaki yazılarımız blog sayfamızda duyurulacak — planlanan başlıklar arasında "Türkçe LLM fine-tuning ile veri anonimleştirme" ve "AI Act ile KVKK kesişiminin Türk kurumlarına etkisi" yer alıyor. Sizin için öncelikli bir konu varsa, ön görüşmede belirtmeniz halinde ilgili teknik dokümanları paylaşabiliriz.

    Sıkça Sorulan Sorular

    Otomatik bir ihlal değildir ama ciddi risk taşır. KVKK md.9, yurt dışı veri aktarımı için ya açık rıza ya da kurul izinli ülke listesi gerektirir. ABD bu listede değildir; OpenAI, Anthropic, Google'a giden veriler md.9 kapsamında değerlendirilir. Çözüm: (a) kişisel veri içermeyen anonim sorgular gönderin, (b) müşteriden açık rıza alın ve denetlenebilir loglayın, (c) Türkiye'de hosted alternatifler (AIGENCY V4 gibi) kullanın. Üçüncüsü en sade, ilk ikisi sürekli denetim yükü getirir.

    İlgili yazılar