"Bu yazdığım nereye gidiyor?" sorusu

Bir yapay zekâ sohbet aracına bir e-posta taslağı, bir sözleşme maddesi ya da içinde isim, adres, telefon geçen bir mesaj yapıştırdığınızda akla gelen ilk soru masum görünür: bu metin tam olarak nereye gidiyor? Cevap, çoğu insanın sandığından hem daha basit hem daha incelikli. Basit kısmı şudur: yazdığınız metin neredeyse her zaman internet üzerinden, aracı sunan şirketin sunucularına gider, cevap orada üretilir ve size geri döner. Yani metniniz bir an için sizin cihazınızdan çıkar ve başka birinin bilgisayarında işlenir. Bu, yapay zekânın çalışma biçiminin kaçınılmaz bir parçasıdır, bir kusur değil.

İncelikli kısım ise "orada ne olduğu" ile ilgili. Sunucuya ulaşan metin, anlık bir cevap üretmek için kullanılır; bu beklenen ve doğal bir adımdır. Asıl gizlilik sorusu, bu metnin o cevap üretildikten sonra ne olduğudur. Dört temel ihtimal vardır: hemen silinir mi, bir süre kayıt altında tutulur mu, gerektiğinde bir insan tarafından incelenir mi, yoksa modelin gelecekteki sürümlerini eğitmek için mi kullanılır? Bu dördü birbirinden çok farklı sonuçlar doğurur ve hangisinin geçerli olduğunu belirleyen şey, kullandığınız aracın ayarları ile gizlilik sözleşmesidir.

Bu yazının amacı tam olarak bu zinciri görünür kılmaktır. Verinizin yolculuğunu durak durak izleyeceğiz: cihazınızdan çıkışı, ağ üzerinde taşınması, sunucuda işlenmesi, saklanması ve bazen modele "öğretilmesi". Ardından bu yolculuğu hukukun (KVKK ve GDPR) nasıl çerçevelediğine, verinin nasıl daha güvenli hâle getirilebileceğine ve hem birey hem kurum olarak alabileceğiniz somut önlemlere bakacağız. Amaç korkutmak değil; gözünüzü açık tutarak yapay zekâyı rahatça ve bilinçli kullanmanızı sağlamaktır.

Eğitim verisi mi, çıkarım verisi mi? En önemli ayrım

Yapay zekâ ve gizlilik konusunda akılda tutulacak tek bir kavram seçecek olsaydık, bu "eğitim" ile "çıkarım" arasındaki fark olurdu. Bir dil modelinin hayatını iki evreye ayırabiliriz. Birincisi eğitim (training): modelin devasa metin yığınlarını okuyarak dilin örüntülerini öğrendiği, haftalar ya da aylar süren, çok pahalı donanım gerektiren ağır bir süreç. İkincisi çıkarım (inference): artık eğitilmiş modelin hazır olduğu ve sizin sorunuza saniyeler içinde cevap ürettiği günlük kullanım anı. Bir benzetmeyle: eğitim, bir doktorun yıllarca süren tıp eğitimidir; çıkarım ise o doktora bir soru sorup cevap almanızdır. Siz bir araca her şey yazdığınızda yaptığınız şey çıkarımdır.

Bu ayrım gizlilik açısından kritiktir, çünkü riskin doğası iki durumda tamamen farklıdır. Çıkarım sırasında metniniz bir cevap üretmek için kullanılır ve kural olarak işi orada biter; metin modelin "beynine" kalıcı olarak yazılmaz. Bir sohbette yazdıklarınız, yeni bir konuşmaya geçtiğinizde modelin içinde durmaz; modelin bir konuşma boyunca "hatırlıyor" gibi görünmesinin tek nedeni, o ana kadarki yazışmanın her seferinde tekrar gönderilmesidir, kalıcı bir bellek değildir. Asıl kalıcı iz, metniniz eğitim verisine dâhil edildiğinde oluşur: o zaman söyledikleriniz, modelin gelecekteki davranışını şekillendiren milyarlarca örnekten biri hâline gelebilir.

Buradaki yaygın korku şudur: "Yazdığım gizli cümle bir gün başka birinin ekranında çıkar mı?" Gerçek, mitten daha ölçülüdür. Modern modeller metni kelimesi kelimesine ezberlemez; örüntüleri ve istatistiksel ilişkileri öğrenir. Ancak nadir, çok sık tekrar eden ya da çok özgün veriler bazı koşullarda "ezberlenebilir" ve dolaylı olarak sızabilir; araştırmacılar bunun mümkün olduğunu gösteren örnekler bulmuştur. Bu yüzden ciddi gizlilik politikası olan kurumsal ve API tabanlı hizmetler, çoğunlukla "verinizi varsayılan olarak eğitime kullanmayız" taahhüdü verir. İşin püf noktası, kullandığınız aracın hangi kategoride olduğunu bilmektir.

Pratik çıkarım nettir: ücretsiz, tüketiciye yönelik bazı araçlar girdilerinizi hizmeti iyileştirmek veya eğitmek için kullanabilirken, ücretli kurumsal sürümler ve geliştirici API'leri genellikle kullanmaz. Dolayısıyla "hangi aracı" kullandığınız kadar "hangi sürümünde ve hangi modunda" kullandığınız da önemlidir. Aynı şirketin ücretsiz uygulaması ile kurumsal planı, gizlilik açısından iki ayrı dünya olabilir.

Verinizin yolculuğu: cihazdan sunucuya ve geri

Verinin nereye gittiğini somutlaştırmak için yolculuğu durak durak izleyelim. İlk durak cihazınızdır: yazdığınız metin tarayıcınızda veya uygulamada oluşur. İkinci durak ağdır: metin, modern web standartlarında şifreli bir bağlantı (TLS) üzerinden gönderilir. Bu şifreleme, internet bankacılığında da kullanılan kapalı bir zarf gibidir; hattın ortasındaki birinin metni okumasını engeller. Üçüncü durak sunucudur: metin, hizmeti sağlayan şirketin (ya da onun bulut sağlayıcısının) veri merkezinde işlenir, cevap üretilir ve aynı şifreli yoldan size geri döner.

Yolculuğun görünmeyen ama en önemli kısmı sunucuda başlar. Birçok hizmet, kötüye kullanımı önlemek, hataları gidermek veya hizmeti iyileştirmek için girdileri bir süre kayıtta tutar (logging/retention). Bu saklama süresi sıfırdan birkaç güne, oradan aylara kadar değişebilir ve genellikle ayarlanabilir. Bazı durumlarda, güvenlik politikası ihlali şüphesi varsa metinler bir insan moderatör tarafından da incelenebilir. Bunların hiçbiri otomatik olarak kötü niyet değildir; ancak gizlilik açısından "metnim cevaptan sonra ne kadar süreyle ve kim tarafından görülebilir hâlde duruyor" sorusunun cevabını işte burası belirler.

Önemli bir ayrıntı, şifrelemenin nerede bittiğidir. TLS, metni siz ile sunucu arasında yolda korur; ama metin sunucuya ulaştığında işlenmek için çözülmek zorundadır. Yani uçtan uca şifreli mesajlaşmanın aksine, hizmet sağlayıcının kendisi prensipte içeriği görebilir. Gizlilik taahhütleri tam da bu noktada devreye girer: "Görebiliriz ama görmüyoruz, saklamıyoruz, eğitime koymuyoruz" sözünün yazılı ve denetlenebilir olması bu yüzden değerlidir.

Ek bir katman da üçüncü taraf entegrasyonlarıdır. Bir uygulamanın içine gömülü yapay zekâ asistanı kullandığınızda, veri çoğu zaman önce o uygulamanın sunucusuna, oradan da modeli sağlayan firmanın API'sine gider. Yani zincirde tek değil, birden çok şirket olabilir. Verinizin gerçek yolculuğunu anlamak için "hangi araç" kadar "bu aracın arkasında hangi sağlayıcılar var" sorusunu da sormak gerekir; bunun cevabı genellikle gizlilik politikasında ve veri işleme sözleşmesinde yazılıdır.

Bulut, özel kurulum ve on-prem: kontrolün üç seviyesi

Verinin nereye gittiğini en çok belirleyen tasarım tercihi, modelin nerede çalıştığıdır. Üç temel seçenek vardır ve bunları bir kütüphane benzetmesiyle düşünmek işi kolaylaştırır. Birincisi paylaşımlı bulut hizmetidir: herkesin kullandığı büyük bir halk kütüphanesi gibi. Hızlı, güçlü ve görece ucuzdur; ama okumak istediğiniz kitabı (verinizi) o binaya getirmeniz gerekir. İkincisi özel (private) bulut kurulumudur: aynı bulut sağlayıcının size ayrılmış, izole bir bölümü; verinizin başka müşterilerinkiyle karışmadığı, sınırları sözleşmeyle çizilmiş kilitli bir okuma odası gibi.

Üçüncüsü ve en yüksek kontrol seviyesi on-prem (yerinde) kurulumdur: modelin doğrudan kurumun kendi sunucularında, kendi binasında çalıştırılması. Burada veri, kurumun ağ sınırlarının dışına hiç çıkmaz; sanki kitaplığı kendi evinizde tutmak gibidir. Hassas veriyle çalışan hastaneler, bankalar, kamu kurumları ve hukuk büroları için bu çoğu zaman bir tercih değil zorunluluktur, çünkü mevzuat verinin belirli bir coğrafyada ya da belirli bir altyapı içinde kalmasını isteyebilir. Karşılığında daha fazla donanım, bakım ve uzmanlık maliyeti gelir; güç ile kolaylık arasında klasik bir denge söz konusudur.

Bu yelpazede son yıllarda öne çıkan bir orta yol da "veri ülkede kalsın" yaklaşımıdır: model güçlü bir bulutta çalışsa bile, verinin işlendiği veri merkezinin coğrafi olarak belirli bir ülkede tutulması (veri yerleşimi / data residency). KVKK'nın yurt dışına veri aktarımına getirdiği çerçeve düşünüldüğünde, Türkiye'de faaliyet gösteren kurumlar için bu detay çoğu zaman hayati önemdedir; verinin nerede durduğu, hangi ülkenin hukukuna tabi olacağını da belirler.

EcoFluxion'da geliştirdiğimiz İçtiHub gibi hukuk odaklı ürünlerde bu mimari kararlar baştan gizlilik ekseninde verilir: hassas dosyaların nerede işlendiği, hangi verinin sistemde kaldığı ve kurumsal müşterilerin verisinin modele "öğretilmeyeceği" gibi konular, sonradan eklenen bir özellik değil, tasarımın temelidir. Bu, soyut bir slogan olarak değil, somut mühendislik kararları olarak "gizlilik en baştan" (privacy by design) ilkesinin uygulanmış hâlidir.

KVKK ve GDPR: aynı melodinin iki düzenlemesi

Veri gizliliği yalnızca bir tercih değil, aynı zamanda hukuki bir yükümlülüktür; ve bu yükümlülüğü iki ana metin tanımlar. Avrupa Birliği'nin GDPR'ı (Genel Veri Koruma Tüzüğü) 2018'den beri dünya çapında bir referans hâline geldi. Türkiye'nin KVKK'sı (Kişisel Verilerin Korunması Kanunu, 6698 sayılı Kanun, 2016) ise büyük ölçüde aynı felsefeyi paylaşır: kişisel veri, ilgili kişinin açık rızası veya kanunda sayılı bir hukuki sebep olmadan işlenemez. İkisini aynı melodinin iki düzenlemesi gibi düşünebilirsiniz; ana tema aynıdır, bazı notalar ve uygulama ayrıntıları farklıdır.

Her iki çerçevenin de ortak kalbi birkaç temel ilkedir. Veriyi yalnızca belirli ve açık bir amaç için toplayın (amaç sınırlaması). O amaç için gerekenden fazlasını toplamayın (veri minimizasyonu). Gerektiğinden uzun saklamayın (saklama sınırı). Ve kişiye haklar tanıyın: verisine erişme, düzeltme, silme ("unutulma hakkı") ve işlemeye itiraz etme. Yapay zekâ bağlamında bu ilkeler doğrudan iş görür: bir araca gereğinden fazla kişisel veri yapıştırmak, tek başına veri minimizasyonu ilkesine aykırı düşebilir.

Yapay zekâ özelinde tabloya yeni bir oyuncu daha eklendi: AB Yapay Zekâ Yasası (AI Act). Bu düzenleme, GDPR'ın "veriyi nasıl işliyorsun" sorusunun yanına "bu yapay zekâ sistemi ne kadar riskli ve hangi şeffaflık kurallarına tabi" sorusunu koyar. Yüksek riskli kullanımlar için (örneğin işe alım, kredi değerlendirmesi, bazı kamusal kararlar) ek belgeleme, insan denetimi ve şeffaflık yükümlülükleri getirir. Kuralları 2026 itibarıyla kademeli olarak yürürlüğe girmektedir; bu nedenle yalnızca AB'deki şirketlerin değil, AB pazarına dokunan her kurumun radarında olmalıdır. Türkiye'de de bu yasanın bir referans çerçevesi olarak izlendiğini söylemek yanlış olmaz.

Önemli bir uyarı: bu yazı genel bir bilgilendirmedir, hukuki tavsiye değildir. Somut bir veri işleme faaliyeti için mutlaka güncel mevzuata ve gerektiğinde bir hukuk uzmanına başvurmak gerekir. Özellikle yurt dışına veri aktarımı ve özel nitelikli (sağlık, biyometrik, din, cinsel hayat, ceza mahkûmiyeti gibi) veriler söz konusu olduğunda kurallar belirgin biçimde daha katıdır.

Anonimleştirme ve takma adlaştırma: ne işe yarar, nerede çuvallar

Verinin kimliği belirsiz hâle getirilmesi, gizlilik araç kutusundaki en güçlü tekniklerden biridir; ama sıkça birbirine karıştırılan iki kavramı ayırmak gerekir. Takma adlaştırma (pseudonymization), kişiyi doğrudan tanımlayan bilgileri (ad, TC kimlik numarası) bir kodla değiştirmektir; ancak bir yerde "kod ile gerçek kişi" eşleşmesini tutan bir anahtar bulunur. Yani teorik olarak geri döndürülebilir ve hukuken hâlâ kişisel veridir. Anonimleştirme (anonymization) ise bu bağı tamamen ve geri dönülmez biçimde koparmayı hedefler; doğru yapıldığında veri artık "kişisel veri" olmaktan çıkar ve KVKK/GDPR kapsamından büyük ölçüde sıyrılır.

Kritik nokta şudur: gerçek anonimleştirme göründüğünden çok daha zordur. İsmi silmek tek başına yetmez. "Şu ilçede oturan, 35 yaşında, şu çok nadir meslekten tek kişi" gibi dolaylı ipuçları, başka veri kümeleriyle birleştirildiğinde kişiyi yeniden tanımlanabilir hâle getirebilir; buna yeniden kimliklendirme (re-identification) denir. Akademik çalışmalar, doğum tarihi, cinsiyet ve posta kodu gibi yalnızca birkaç sıradan alanın bile çoğu insanı tek başına ayırt etmeye yetebildiğini göstermiştir. Bu yüzden ciddi sistemler tek bir hamleye değil, katmanlı tekniklere yaslanır.

Yapay zekâ akışlarında bunun pratik karşılığı nettir. Bir metni modele göndermeden önce kişisel tanımlayıcıları otomatik olarak maskelemek (örneğin isimleri ve numaraları [KİŞİ], [NUMARA] gibi yer tutucularla değiştirmek), hem veri minimizasyonu ilkesine hizmet eder hem de olası bir sızıntıda zararı azaltır. Hukuk teknolojisinde bu özellikle değerlidir: bir kararın hukuki örüntüsünü analiz etmek için çoğu zaman tarafların gerçek kimlik bilgilerine ihtiyaç yoktur. İçtiHub gibi ürünlerde amaç, hukukun özünü korurken gereksiz kişisel ayrıntıyı sistemin içine hiç taşımamaktır.

Yine de dürüst olmak gerekir: hiçbir anonimleştirme yüzde yüz garanti vermez ve fazla maskeleme verinin işe yararlığını düşürebilir; her şeyi karartırsanız geriye analiz edilecek bir şey kalmaz. Doğru denge, her seferinde "amacım için gerçekten hangi alanlara ihtiyacım var?" sorusunu sorarak bulunur.

Bireyler için pratik gizlilik rehberi

Kurumsal mimariler bir yana, çoğumuz yapay zekâyı her gün birey olarak kullanıyoruz; ve burada birkaç basit alışkanlık riskin büyük kısmını ortadan kaldırır. Birinci kural, "yapıştırmadan önce düşün": bir araca girdiğiniz her şeyin ekranınızdan çıkıp başka bir sunucuda işlendiğini varsayın. TC kimlik numaranızı, banka ve kart bilgilerinizi, şifrelerinizi, başkalarının size güvenerek emanet ettiği kişisel verileri ya da imzalı bir gizlilik sözleşmesi (NDA) kapsamındaki belgeleri, gerçekten gerekli olmadıkça yapıştırmayın. Basit bir test: "Bunu tanımadığım bir e-posta adresine gönderir miydim?" Cevap hayırsa, düşünmeden yapay zekâ aracına da yapıştırmayın.

İkinci kural, ayarları bir kez gerçekten okumaktır. Kullandığınız aracın gizlilik ayarlarına girin; çoğu modern araçta "sohbet geçmişini ve eğitimi kapat" benzeri bir seçenek vardır. Bunu kapattığınızda hem geçmişiniz saklanmaz hem de girdileriniz model eğitimine kullanılmaz. Ücretsiz tüketici sürümleri ile ücretli/kurumsal sürümlerin gizlilik taahhütleri farklı olabilir; hangi modda olduğunuzu bilmek değerlidir. Hesabınızda iki adımlı doğrulamayı (2FA) açmak da, hesabınız ele geçirilirse geçmiş sohbetlerinizi korur.

Üçüncü kural, gerektiğinde anonimleştirmektir. Bir e-postayı düzelttirmek istiyorsanız gerçek isimleri "X" ve "Y" ile değiştirin; bir tıbbi raporu anlamak istiyorsanız hasta kimliğini çıkarıp yalnızca tıbbi içeriği bırakın. Modelin işini yapması için çoğu zaman gerçek kimliklere ihtiyacı yoktur. Son olarak, içine yapay zekâ gömülü uygulamalarda "bu asistan verimi nereye gönderiyor?" diye sormayı alışkanlık hâline getirin; verdiğiniz izinleri ve gizlilik politikasını ara sıra gözden geçirin. Bu küçük adımlar, yapay zekâdan vazgeçmenizi gerektirmeden onu çok daha güvenli kullanmanızı sağlar.

Şirketler için: gizliliği bir ürün özelliği gibi tasarlamak

Bir şirket yapay zekâyı işine kattığında gizlilik artık bireysel bir alışkanlık değil, yasal yaptırımları olan kurumsal bir sorumluluktur. İlk adım envanter çıkarmaktır: hangi ekipler, hangi araçları, hangi veriyle kullanıyor? Çalışanların farkında olmadan müşteri verilerini ücretsiz araçlara yapıştırdığı "gölge yapay zekâ" (shadow AI) kullanımı, bugün kurumlar için en sık görülen sızıntı kaynaklarından biridir. Görmediğiniz riski yönetemezsiniz; bu yüzden önce net bir kullanım politikası ve onaylı araçlar listesi gerekir. Yasaklamak yerine güvenli bir alternatif sunmak, çoğu zaman gölge kullanımı azaltmanın en etkili yoludur.

İkinci adım, sözleşmeleri dikkatle okumaktır. Bir yapay zekâ sağlayıcısıyla çalışırken Veri İşleme Sözleşmesi (DPA) hayatidir: sağlayıcı verinizi eğitim için kullanıyor mu, ne kadar süre saklıyor, nerede (hangi ülkede) işliyor, alt yükleniciler (subprocessor) kimler ve bir ihlal durumunda sizi ne kadar sürede bilgilendiriyor? KVKK kapsamında veri sorumlusu olarak nihai sorumluluk çoğu zaman sizde kalır; sağlayıcı yalnızca veri işleyendir. Bu nedenle, özellikle özel nitelikli veriler ve yurt dışına aktarım söz konusu olduğunda, taahhütlerin sözlü değil yazılı ve doğrulanabilir olması gerekir.

Üçüncü adım, tasarımı baştan doğru kurmaktır: "gizlilik en baştan" (privacy by design) ve "varsayılan olarak gizlilik" (privacy by default). Bu pratikte veri minimizasyonu (modele yalnızca gereken alanı gönder), erişim kontrolü (kim hangi veriyi görebilir), kayıt tutma (kim ne zaman neye erişti) ve gerektiğinde özel/on-prem kurulum tercihleri demektir. Yüksek riskli kullanımlarda ise bir Veri Koruma Etki Değerlendirmesi (DPIA) yapmak hem iyi bir mühendislik pratiği hem de mevzuatın beklediği bir adımdır.

EcoFluxion'da İçtiHub'ı geliştirirken yaklaşımımız tam olarak budur: hassas hukuki verinin nerede durduğu, kimin gördüğü ve modele ne öğretildiği gibi sorular, ürün özelliklerinden önce gelen tasarım kararlarıdır. Gizlilik, sonradan üzerine yapıştırılan bir uyumluluk katmanı değildir; ürünün güvenilir olmasının ön koşuludur. Akıllı bir şirket için bu bir maliyet değil, müşteri güveni biçiminde geri dönen bir yatırımdır; çünkü hukuk gibi alanlarda güven, ürünün kendisidir.