# LLM Loglama ve KVKK: Üretimde Kişisel Veri Nasıl Yönetilir? > Source: https://sukruyusufkaya.com/blog/llm-loglama-kvkk > Updated: 2026-07-12T07:24:40.874Z > Type: blog > Category: yapay-zeka **TLDR:** LLM loglama nedir, KVKK açısından neden riskli? Loglarda biriken kişisel veri, veri maskeleme, saklama süresi ve erişim kontrolü bu kapsamlı rehberde. LLM loglama ve KVKK birbiriyle gerilimli iki ihtiyacı aynı masaya koyar: bir yandan üretimdeki bir büyük dil modeli (LLM) sistemini güvenle işletmek için loglama zorunludur, diğer yandan bu loglar sessizce kişisel veri biriktirir. LLM loglama, üretim ortamındaki bir dil modeli uygulamasının aldığı istemleri (prompt), ürettiği yanıtları, model çağrılarını, token kullanımını, gecikme sürelerini ve hata olaylarını sistematik biçimde kayıt altına alma pratiğidir; ve bu kayıtların çok büyük bölümü, KVKK anlamında kişisel veri içerir. Bu rehber, LLM loglama konusunu hem bir mühendislik hem de bir uyum problemi olarak, bir yönetim ve teknik danışman titizliğiyle ele alıyor: loglama neden gerekli (gözlemlenebilirlik, hata ayıklama, denetim); loglarda hangi kişisel veriler birikir; KVKK açısından log verisinin statüsü nedir; loglarda veri minimizasyonu, veri maskeleme ve takma adlaştırma teknikleri; saklama süresi ve imha; erişim kontrolü; PII tespiti ve otomatik redaksiyon; üçüncü taraf gözlemlenebilirlik araçları ve yurt dışına veri aktarımı; uyum kontrol listesi; sektörel örnekler ve yaygın hatalar. Amaç, "log tutalım mı, tutmayalım mı?" ikilemini aşıp, hem gözlemlenebilir hem KVKK uyumlu bir LLM loglama düzeni kurabilmenizdir. Not: Buradaki hukuki çerçeveler bilgilendirme amaçlıdır ve hukuki tavsiye niteliği taşımaz; kurumunuza özel değerlendirme için hukuk danışmanınıza başvurun. ## LLM Loglama Neden Gerekli? Gözlemlenebilirlik, Hata Ayıklama ve Denetim Bir LLM uygulamasını üretime almak, onu bir kere yazıp bırakmak değildir; sürekli izlenmesi, anlaşılması ve iyileştirilmesi gereken canlı bir sistemdir. LLM loglama, bu izlemenin temel katmanıdır ve olmadığında sistem bir "kara kutu"ya dönüşür. Loglamanın gerekliliği üç ana ihtiyaçtan doğar: gözlemlenebilirlik, hata ayıklama ve denetim. Birincisi gözlemlenebilirliktir. Bir dil modeli olasılıksal davranır; aynı isteme farklı zamanlarda farklı yanıtlar verebilir, bağlam penceresi dolduğunda kalitesi düşebilir, maliyeti token kullanımıyla dalgalanabilir. Bu davranışı anlamak, ancak istem ve çıktıların, gecikmelerin ve token sayımlarının loglanmasıyla mümkündür. LLM loglama olmadan "sistem yavaşladı", "yanıtlar kötüleşti" veya "faturamız neden arttı?" sorularına cevap veremezsiniz. Bu konudaki daha geniş çerçeveyi LLM gözlemlenebilirliği nedir yazısında ele alıyoruz. İkincisi hata ayıklamadır. Bir kullanıcı "model bana yanlış cevap verdi" dediğinde, o etkileşimi yeniden üretebilmek için tam olarak hangi istemin gönderildiğini, hangi bağlamın eklendiğini ve modelin ne döndürdüğünü görmeniz gerekir. Prompt zincirleri, araç çağrıları ve RAG (bilgi getirimiyle üretim) bağlamı karmaşıklaştıkça, hata ayıklama tamamen loglara bağımlı hale gelir. Bir RAG sisteminde yanlış belge getirildiyse bunu ancak logdan görebilirsiniz; bir AI agent yanlış aracı çağırdıysa, bunu ancak izlerden anlarsınız. Üçüncüsü denetimdir. Kurumsal bir LLM sistemi, "modelin ne dediğini" hesap verebilir biçimde kanıtlayabilmelidir: bir yanlış tavsiye, bir uygunsuz çıktı veya bir güvenlik olayı sonrasında, olayın izini sürebilmek için loglar gerekir. Sorumlu yapay zeka ve AI governance çerçeveleri, kararların izlenebilirliğini ister; bu izlenebilirliğin ham maddesi LLM loglama ile üretilir. İşte tam bu noktada gerilim başlar: denetim için ne kadar çok loglarsak, o kadar çok kişisel veri biriktiririz. Üretimdeki bir LLM sistemini loglamadan işletmek, göstergesiz bir uçağı uçurmaya benzer. Soru "loglayalım mı?" değil, "kişisel veriyi riske atmadan nasıl loglayalım?" olmalıdır. Bu rehberin tamamı, işte bu ikinci sorunun cevabıdır. ## LLM Loglama Nedir ve Klasik Uygulama Loglamasından Farkı Nedir? Klasik uygulama loglaması onlarca yıldır bilinen bir disiplindir: bir web sunucusu istekleri, hataları ve olayları yapılandırılmış kayıtlar olarak tutar. LLM loglama bu geleneği miras alır ama üç kritik farkla ondan ayrılır; ve bu farklar, KVKK riskini klasik loglamaya göre çok daha ağır hale getirir. Birinci fark içeriğin doğasıdır. Klasik bir log satırı genellikle yapılandırılmış ve öngörülebilirdir: bir HTTP durum kodu, bir yanıt süresi, bir hata mesajı. LLM loglama ise doğası gereği serbest metin loglar: kullanıcının kendi kelimeleriyle yazdığı istem ve modelin ürettiği doğal dil yanıtı. Bu serbest metin, içine ne konulacağı önceden bilinemeyen bir kutudur; kullanıcı oraya adını, TC kimlik numarasını, sağlık durumunu veya bir başkasının kişisel verisini yazabilir. Yani LLM loglama, tasarımı gereği öngörülemez kişisel veri toplar. İkinci fark hacim ve derinliktir. Modern bir LLM boru hattı tek bir çağrı değildir; sistem promptu, kullanıcı promptu, RAG ile getirilen bağlam, ara akıl yürütme adımları, araç çağrıları ve nihai çıktı gibi çok katmanlıdır. Her katman loglanabilir ve her katman kişisel veri taşıyabilir. Prompt, sistem promptu ve bağlam penceresi kavramlarının nasıl birleştiğini anlamak, hangi katmanda hangi verinin biriktiğini görmek için önemlidir. Bir token düzeyinde loglama yaparsanız, verinin en granüler halini saklıyorsunuz demektir. Üçüncü fark çıkarım riskidir. Klasik loglar veriyi olduğu gibi kaydeder; LLM ise veriyi işler, birleştirir ve yeni çıkarımlar üretebilir. Model, kullanıcının doğrudan vermediği bir bilgiyi (örneğin bir sağlık durumunu veya bir mali durumu) bağlamdan çıkarımlayıp yanıtına koyabilir ve bu çıkarım da loglanır. Böylece log, kullanıcının hiç yazmadığı ama sistemin ürettiği hassas kişisel veriyi içerebilir. Bu, LLM loglamayı klasik loglamadan niteliksel olarak farklı ve daha riskli kılan en ince noktadır. ## Loglarda Hangi Kişisel Veriler Birikir? LLM loglama tasarlarken en kritik soru şudur: bu loglar tam olarak nerede ve hangi kişisel veriyi biriktiriyor? Riski yönetmek, önce onu haritalamayı gerektirir. Loglarda kişisel veri üç ana katmanda ve bir de meta veri katmanında birikir. ### Kullanıcı Girdisi (Prompt) Katmanı En görünür ve en yoğun kişisel veri kaynağı, kullanıcının doğrudan yazdığı istemdir. Bir müşteri destek asistanına "Benim TC 12345678901, siparişim nerede?" yazan kullanıcı, tek cümlede kimlik verisini loga sokar. Bir hukuk asistanına yapıştırılan sözleşme, bir sağlık uygulamasına anlatılan şikâyet, bir İK aracına girilen çalışan bilgisi — hepsi kullanıcı girdisi olarak loglanır. Bu katman öngörülemezdir çünkü kullanıcının ne yazacağını kontrol edemezsiniz; yalnızca yazdıktan sonra ne yapacağınızı kontrol edebilirsiniz. ### Bağlam ve Sistem Promptu Katmanı İkinci katman, uygulamanın modele beslediği bağlamdır. RAG sistemlerinde bir müşteri kaydı, CRM verisi veya iç belge, yanıtı zenginleştirmek için isteme eklenir; ve bu ekleme de loglanır. Burada tehlike, kişisel verinin kullanıcıdan değil, doğrudan kurumun veri tabanından geliyor olmasıdır — yani daha yapılandırılmış ve daha hassas olabilir. Kişisel veri tanımı, bu bağlam verisinin çoğunu kapsar; özellikle bir RAG boru hattında hangi belgelerin bağlama girdiği dikkatle yönetilmelidir. ### Model Çıktısı Katmanı Üçüncü katman modelin ürettiği yanıttır. Model, girdideki kişisel veriyi yanıtında tekrar edebilir ("Sayın Ahmet Yılmaz, siparişiniz...") veya bağlamdan yeni bir çıkarım üretebilir. Bu çıktı loglandığında, kişisel veri bir kez daha ve bazen zenginleşmiş biçimde kaydedilir. Halüsinasyon riski burada ikinci bir sorun ekler: model yanlış bir kişisel veri "uydurabilir" ve bu yanlış veri de loglanarak kalıcı hale gelir. ### Meta Veri Katmanı Son olarak, doğrudan istem/çıktı olmayan ama kişiyi belirlenebilir kılan meta veriler vardır: IP adresi, oturum kimliği, kullanıcı kimliği, cihaz bilgisi, zaman damgası. Tek başına masum görünen bu alanlar, birleştirildiğinde bir kişiyi tanımlayabilir ve bu yüzden KVKK açısından kişisel veri sayılabilir. İyi bir LLM log yönetimi, bu meta veri katmanını da kapsam içine alır. ## KVKK Açısından Log Verisinin Statüsü Nedir? LLM loglarının teknik doğasını anladıktan sonra, hukuki soruya geliyoruz: KVKK açısından bu loglar nedir? Kısa cevap, çoğu zaman kişisel veri oldukları ve dolayısıyla LLM loglamanın bir veri işleme faaliyeti sayıldığıdır. Bu bölüm bilgilendirme amaçlıdır ve hukuki tavsiye değildir. KVKK (Kişisel Verilerin Korunması Kanunu), kişisel veriyi "kimliği belirli veya belirlenebilir gerçek kişiye ilişkin her türlü bilgi" olarak tanımlar. Bir log kaydı, doğrudan (ad, TC kimlik numarası) veya dolaylı (IP, oturum kimliği ile birleştirilebilir bilgi) yoldan bir kişiyi belirlenebilir kılıyorsa, kişisel veridir. LLM loglarının büyük bölümü bu tanıma girer çünkü içerik doğrudan insan etkileşiminden gelir. KVKK nedir yazısı temel kavramları, kişisel veri nedir yazısı ise tanımın sınırlarını ele alır. Kritik bir ayrım anonimleştirme ile takma adlaştırma arasındadır. Bir log gerçekten anonim hale getirildiyse — yani hiçbir biçimde geri döndürülemez şekilde kimliksizleştirildiyse — KVKK kapsamı dışına çıkabilir. Ancak pratikte "maskeledik" denilen çoğu işlem aslında takma adlaştırmadır (pseudonymization): veri hâlâ bir eşleştirmeyle geri döndürülebilir, dolayısıyla hukuken kişisel veri olmaya devam eder. Bu ayrımı veri anonimleştirme nedir yazısında ayrıntılı ele alıyoruz; LLM loglama bağlamında en sık yapılan hata, takma adlaştırmayı anonimleştirme sanmaktır. Log verisi kişisel veri olduğunda, LLM loglama şu KVKK gerekliliklerine tabi olur: bir hukuki dayanağa sahip olmak (açık rıza veya meşru menfaat gibi), aydınlatma yükümlülüğünü yerine getirmek (kullanıcıya verisinin loglandığını bildirmek), veri güvenliği tedbirleri almak (şifreleme, erişim kontrolü), veri minimizasyonu ilkesine uymak ve sınırlı bir saklama süresi belirlemek. Özel nitelikli (hassas) kişisel veriler — sağlık, biyometrik, din, siyasi görüş — söz konusu olduğunda yükümlülükler daha da ağırlaşır. KVKK uyumlu bir yapay zeka mimarisinin genel çerçevesi için KVKK uyumlu yapay zeka nedir rehberine bakabilirsiniz. LLM loglamada en tehlikeli yanılgı, "kişisel veriyi bir token ile değiştirdik, artık anonim" varsayımıdır. Eğer o token'ı gerçek kişiye bağlayan bir eşleştirme (bir yerlerde) varsa, veri hâlâ kişisel veridir ve KVKK'ya tabidir. Gerçek anonimleştirme geri döndürülemez olmalıdır; bu, çoğu loglama senaryosunda pratik değildir. Bu yüzden çözüm genellikle takma adlaştırma + sıkı erişim kontrolü + kısa saklama süresi kombinasyonudur. ## Uyumlu LLM Loglama Mimarisinin Ana Çerçevesi Nasıl Kurulur? Şimdi rehberin kalbine geliyoruz: hem gözlemlenebilir hem KVKK uyumlu bir LLM loglama mimarisi pratikte nasıl kurulur? Cevap, loglamayı tek bir "aç/kapa" düğmesi değil, katmanlı bir boru hattı olarak tasarlamaktır. Bu boru hattında her katman, veriyi bir sonraki katmana geçmeden önce daha güvenli hale getirir. Sağlam bir LLM loglama mimarisi altı ilkeye dayanır ve bu ilkeler birlikte çalıştığında, kişisel veri riski kabul edilebilir bir düzeye iner. ### İlke 1: Kaynakta Minimizasyon En güçlü koruma, hiç toplanmayan veridir. Bu yüzden uyumlu bir LLM loglama tasarımı, "her şeyi logla, sonra temizleriz" yerine "yalnızca gerekeni topla" ilkesiyle başlar. Her log alanı için "bu alanı gerçekten neden saklıyoruz?" sorusu sorulmalı; bir hata ayıklama amacı yoksa ham istem/çıktının tamamını saklamak yerine yalnızca özet, hata sınıfı veya kimliksizleştirilmiş metrik saklanmalıdır. Kaynakta minimizasyon, sonraki tüm katmanların yükünü azaltır. ### İlke 2: Kayıttan Önce Redaksiyon İkinci ilke, PII tespiti ve otomatik redaksiyonun boru hattında konumudur: veri diske düşmeden önce çalışmalıdır. Ham istem/çıktı bir ön işleme katmanından geçer; burada kişisel veri tespit edilir ve maskelenir; ancak temizlenmiş sürüm loga yazılır. Bu sıralama kritiktir — eğer ham veri önce loglanıp sonra temizlenmeye çalışılırsa, ham kişisel veri en az bir kez diske yazılmış olur ve bu, çoğu uyum çerçevesi açısından zaten bir işleme (ve olası ihlal) noktasıdır. ### İlke 3: Katmanlı Ayrıştırma Tüm loglar aynı hassasiyette değildir. Uyumlu bir mimari, logları hassasiyet düzeyine göre ayrı akışlara böler: operasyonel metrikler (gecikme, token sayısı, hata kodu — kişisel veri içermez) bir katmanda; kimliksizleştirilmiş içerik örnekleri başka bir katmanda; ham/hassas içerik (gerçekten gerekiyorsa) en sıkı korunan ayrı bir katmanda tutulur. Bu ayrıştırma, erişim kontrolünü ve saklama süresini her katman için ayrı ayarlamayı mümkün kılar. ### İlke 4: Şifreleme ve Erişim Sınırı Kişisel veri içeren her log katmanı, hem aktarım sırasında hem de saklama sırasında şifrelenmelidir. Buna ek olarak, erişim en az yetki ilkesiyle sınırlanır: kimse "her ihtimale karşı" ham loglara erişememelidir. Bu ilke, güvenlik ve guardrail katmanlarıyla birlikte, bir veri ihlali durumunda etkiyi sınırlamanın temelidir. ### İlke 5: Yaşam Döngüsü ve İmha Her log kaydının bir doğum ve bir ölüm tarihi olmalıdır. Saklama süresi önceden tanımlanır ve süre dolduğunda kayıt otomatik olarak, güvenli biçimde imha edilir. Bu, hem veri minimizasyonu ilkesinin zaman boyutudur hem de saldırı yüzeyini küçük tutmanın yoludur. Süresiz saklanan log, zamanla büyüyen bir yükümlülüktür. ### İlke 6: İzlenebilirlik ve Hesap Verebilirlik Son ilke, loglama sisteminin kendisinin de hesap verebilir olmasıdır: kim hangi loga ne zaman eriştiği, hangi redaksiyon kuralının uygulandığı ve hangi kaydın ne zaman imha edildiği izlenebilmelidir. Bu "loglamanın loglanması", bir denetimde uyumu kanıtlamanın ve bir olayda kök nedeni bulmanın anahtarıdır. LLMOps ve MLOps disiplinleri, bu yaşam döngüsü yönetiminin operasyonel çerçevesini sağlar. Bu altı ilkenin ortak mantığı şudur: kişisel veri riskini tek bir noktada değil, boru hattının her aşamasında azaltmak. Hiçbir tek önlem kusursuz değildir — PII tespiti bazı verileri kaçırır, erişim kontrolü aşılabilir, maskeleme eksik uygulanabilir. Ama bu ilkeler birlikte, katmanlı bir savunma (defense in depth) oluşturur ve bir katman başarısız olduğunda diğerleri riski sınırlar. ## Veri Minimizasyonu: LLM Loglamada Ne Kadar Log Yeterli? Veri minimizasyonu, KVKK'nın temel ilkelerinden biridir ve LLM loglama bağlamında en güçlü koruma aracıdır: işlenen kişisel veri, amaç için gerekli olanla sınırlı olmalıdır. Pratikte bu, "toplayabildiğimiz her şeyi toplayalım" refleksine bilinçli olarak direnmek demektir. Çünkü toplanmayan veri, ne sızabilir, ne kötüye kullanılabilir, ne de bir denetimde sorun yaratır. Veri minimizasyonunu LLM loglamaya uygulamanın pratik yolu, her log akışı için amaç-veri eşleşmesi yapmaktır. Örneğin performans izleme amacı yalnızca gecikme ve token sayısını gerektirir; bunun için istem içeriğini saklamaya gerek yoktur. Kalite izleme, içerik örneği gerektirebilir ama tam metin yerine kimliksizleştirilmiş örnekler yeterli olabilir. Yalnızca aktif hata ayıklama, kısa süreli ve sıkı korunan ham log gerektirir. Amaç netleştiğinde, çoğu senaryonun ham kişisel veriye ihtiyaç duymadığı görülür. Bir başka minimizasyon tekniği örnekleme (sampling) ve toplama (aggregation) kullanmaktır. Her etkileşimi tam olarak loglamak yerine, temsili bir örneklem loglanabilir; ya da bireysel kayıtlar yerine toplu istatistikler tutulabilir. "Bu hafta 10.000 sorgunun %3'ünde şu hata türü görüldü" bilgisi, çoğu operasyonel karar için 10.000 ham istemi saklamaktan daha değerli ve çok daha az risklidir. Bu yaklaşım, gözlemlenebilirliği korurken kişisel veri ayak izini küçültür. Veri minimizasyonunun görünmeyen bir faydası da maliyettir: daha az log, daha az depolama, daha az işleme ve daha az güvenlik yükü demektir. Yani minimizasyon yalnızca bir uyum gerekliliği değil, aynı zamanda bir maliyet ve risk optimizasyonudur. LLM sistemlerinin toplam sahip olma maliyetini değerlendirirken bu bağlantı önemlidir; ilgili çerçeveyi yapay zeka ROI nasıl hesaplanır yazısında ele alıyoruz. Veri minimizasyonunun altın kuralı: bir alanı loglamadan önce "bunu saklamazsam ne kaybederim?" diye sorun. Cevap "somut bir şey değil" ise, o alanı loglamayın. Toplamadığınız kişisel veri, sıfır uyum riski taşır; oysa topladığınız her alan, korunması, maskelenmesi ve zamanında imha edilmesi gereken bir yükümlülüktür. ## Loglarda Veri Maskeleme ve Takma Adlaştırma Teknikleri Nelerdir? Veri minimizasyonu ne kadar iyi uygulanırsa uygulansın, bazı senaryolarda içerik loglamak kaçınılmazdır; işte o noktada devreye veri maskeleme ve takma adlaştırma girer. Bu teknikler, loga giren kişisel veriyi kimliksizleştirerek riski azaltır. LLM loglama bağlamında birkaç farklı yaklaşım vardır ve doğru seçim, verinin amacına bağlıdır. ### Maskeleme (Masking) En temel teknik veri maskelemedir: kişisel verinin bir kısmını veya tamamını gizlemek. Bir e-posta "ah***@***.com", bir telefon "05** *** ** 89", bir TC kimlik numarası "*******8901" biçiminde maskelenebilir. Maskelemenin iki değişkeni vardır: kısmi maskeleme (verinin tanınabilir bir parçası kalır, hata ayıklamaya yardımcı olur) ve tam maskeleme (veri tamamen bir yer tutucuyla değişir, en yüksek koruma). Kısmi maskeleme daha kullanışlı ama daha risklidir; çünkü kalan parça, başka verilerle birleştirildiğinde kimlik belirlemeye yardımcı olabilir. ### Takma Adlaştırma (Pseudonymization) Takma adlaştırma, kişisel veriyi tutarlı bir takma adla değiştirir: "Ahmet Yılmaz" her geçtiğinde "KULLANICI_7F3A" olur. Bu, verinin analitik değerini korur (aynı kullanıcının farklı loglardaki etkileşimlerini ilişkilendirebilirsiniz) ama doğrudan kimliği gizler. Kritik nokta, takma ad ile gerçek kimlik arasındaki eşleştirmenin ayrı, şifreli ve çok sıkı korunan bir yerde tutulmasıdır. Ancak unutmayın: bu eşleştirme var olduğu sürece, veri KVKK anlamında hâlâ kişisel veridir. Takma adlaştırma bir koruma katmanıdır, kapsam dışına çıkış değil. ### Tokenizasyon ve Hash Tokenizasyon, kişisel veriyi anlamsız bir token ile değiştirir ve orijinali ayrı bir kasada tutar. Hash'leme ise veriyi tek yönlü bir fonksiyonla geri döndürülemez bir değere çevirir; ancak düşük entropili veriler (örneğin TC kimlik numarası) için hash bile kaba kuvvetle çözülebildiğinden, tuzlama (salting) gibi ek önlemler gerekir. Bu teknikler, özellikle kullanıcı kimliği gibi meta verileri korumak için kullanışlıdır. ### Genelleştirme ve Bulanıklaştırma Bazı durumlarda kesin değer yerine bir aralık veya kategori saklamak yeterlidir: tam yaş yerine "30-40 yaş", tam konum yerine "İstanbul", tam zaman yerine "sabah". Bu genelleştirme, veriyi hem daha az tanımlayıcı yapar hem de çoğu analitik amaç için yeterli kalır. LLM loglamada bu yaklaşım, özellikle demografik veya davranışsal meta veriler için değerlidir. Pratikte bu teknikler tek başına değil, kombinasyon halinde kullanılır: bir log kaydında ad tam maskelenir, kullanıcı kimliği tokenize edilir, konum genelleştirilir ve serbest metindeki PII redaksiyondan geçirilir. Bu katmanlı yaklaşım, veri maskeleme stratejisini tek bir tekniğe bağımlı olmaktan kurtarır. Daha geniş anonimleştirme ve maskeleme çerçevesi için veri anonimleştirme nedir yazısı temel oluşturur. ## PII Tespiti ve Otomatik Redaksiyon Nasıl Yapılır? Veri maskeleme ancak maskelenecek veriyi bulabildiğiniz ölçüde işe yarar; işte bu tespit işini PII tespiti ve otomatik redaksiyon katmanı yapar. LLM loglamanın en teknik ama en kritik bileşenlerinden biri budur, çünkü serbest metindeki kişisel veriyi bulmak, yapılandırılmış bir alandaki veriyi bulmaktan çok daha zordur. PII tespiti tipik olarak üç yöntemin birleşimidir. Birincisi desen tabanlı kurallardır (regex): e-posta, telefon, TC kimlik numarası, kredi kartı gibi belirli formatlı veriler, düzenli ifadelerle yüksek doğrulukla yakalanabilir. İkincisi sözlük/liste tabanlı yaklaşımdır: bilinen ad listeleri, şehir adları veya kurum içi terimler. Üçüncüsü ve en güçlüsü, adlandırılmış varlık tanıma (NER) modelleridir: bir makine öğrenmesi modeli, bağlamdan "bu bir kişi adı", "bu bir adres" çıkarımı yapar. Doğal dil işleme ve makine öğrenmesi temelleri, bu NER katmanının nasıl çalıştığını anlamaya yardımcı olur. Otomatik redaksiyon, tespit edilen bu varlıkları maskeleyerek veya bir etiketle değiştirerek (örneğin "[AD]", "[E-POSTA]") loga temizlenmiş sürümü yazar. Bu boru hattının konumu hayatidir: kayıt yazılmadan önce, senkron biçimde çalışmalıdır. Eğer redaksiyon asenkron veya sonradan yapılırsa, ham kişisel veri en az bir kez ham log olarak var olur ve bu, bir ihlal durumunda açığa çıkabilir. Hiçbir otomatik PII tespiti kusursuz değildir; iki tür hata yapar. Yanlış negatif (kişisel veriyi kaçırma) en tehlikelisidir çünkü ham veri loga sızar; yanlış pozitif (kişisel olmayan veriyi maskeleme) ise logun kullanışlılığını azaltır ama güvenlik açısından zararsızdır. Bu yüzden iyi bir tasarım, tereddütte maskeleme yönünde hata yapacak biçimde ayarlanır (yanlış pozitife tolerans, yanlış negatife sıfır tolerans). Ve mükemmel olmadığı için, PII tespiti asla tek savunma olmamalı; veri minimizasyonu ve erişim kontrolü ile birlikte katmanlı çalışmalıdır. ## Log Saklama Süresi ve İmha: Ne Kadar Saklamalı? Bir kişisel veriyi ne kadar süre saklarsanız, o kadar uzun süre onu korumak, yönetmek ve bir ihlalde hesabını vermek zorunda kalırsınız. Bu yüzden saklama süresi, LLM loglamanın en önemli uyum parametrelerinden biridir. KVKK'nın veri minimizasyonu ilkesi zaman boyutunda da geçerlidir: veri, amaç için gereken süreden daha uzun tutulmamalıdır. Tek bir "doğru" saklama süresi yoktur; süre, logun amacına göre belirlenir. Pratik bir yaklaşım, logları amaca göre sınıflandırıp her sınıfa ayrı bir saklama süresi vermektir: ham hata ayıklama logları çok kısa (örneğin birkaç gün ile birkaç hafta), çünkü hata ayıklama ihtiyacı genellikle kısa vadelidir; kimliksizleştirilmiş kalite örnekleri orta vadeli; ve tamamen anonim toplu metrikler uzun vadeli saklanabilir. Kişisel veri içeren log ne kadar hassassa, saklama süresi o kadar kısa olmalıdır. Saklama süresi bir politika olarak yazılmakla kalmamalı, teknik olarak otomatik uygulanmalıdır. İmha, manuel bir "ara sıra temizlik" işi değil, TTL (time-to-live) mekanizmaları, otomatik yaşam döngüsü kuralları ve düzenli imha görevleriyle güvence altına alınmış bir süreç olmalıdır. Süre dolduğunda kayıt güvenli biçimde (geri getirilemez şekilde) silinmeli; yedeklerdeki kopyalar da bu politikaya dahil edilmelidir — çoğu kurum yedekleri unutur ve süresiz kişisel veri orada yaşamaya devam eder. İmha politikasında sık atlanan bir nokta da alt sistemlerdir: LLM logları yalnızca ana log deposunda değil, gözlemlenebilirlik araçlarında, veri ambarlarında, önbelleklerde ve üçüncü taraf hizmetlerinde de kopyalanmış olabilir. Bir kaydın gerçekten imha edilmesi, tüm bu kopyaların da imha edilmesi anlamına gelir. Bu yüzden saklama süresi ve imha, tek bir sistem değil, uçtan uca bir veri yaşam döngüsü meselesidir. Saklama süresi politikasının en sık kırıldığı yer yedeklerdir. Ana veritabanından bir logu silseniz de, aylık yedeklerde, veri ambarında veya gözlemlenebilirlik aracının deposunda kopyaları kalabilir. Gerçek imha, tüm kopyaları kapsamalıdır; aksi halde "sildik" demeniz teknik olarak doğru olmaz ve bir denetimde veya veri sahibi talebinde sorun yaratır. ## Loglara Erişim Kontrolü ve Log Yönetimi Nasıl Sıkılaştırılır? Kişisel veriyi maskeleseniz ve saklama süresini sınırlasanız bile, o loglara kimin eriştiği kritik bir sorudur. Erişim kontrolü, LLM log yönetiminin güvenlik omurgasıdır ve temeli en az yetki (least privilege) ilkesidir: her kişi ve sistem, yalnızca işini yapmak için gerçekten ihtiyaç duyduğu loglara, yalnızca ihtiyaç duyduğu ölçüde erişebilmelidir. Pratik bir erişim kontrolü mimarisi birkaç katmandan oluşur. Rol tabanlı erişim kontrolü (RBAC) ile roller tanımlanır: bir operasyon mühendisi metriklere erişebilir ama ham içeriğe erişemez; bir hata ayıklama yetkisi olan geliştirici, yalnızca gerekçeli ve süreli biçimde maskelenmiş loglara erişebilir; ham/hassas loglara erişim ise istisnai, onaylı ve tam denetim izli olmalıdır. Varsayılan görünüm her zaman maskelenmiş sürüm olmalı; ham veriye erişim özel bir yetki gerektirmelidir. Erişim kontrolünün ayrılmaz parçası denetim izidir: loglara her erişim, kimin, ne zaman, hangi kaydı görüntülediğiyle birlikte ayrıca loglanmalıdır. Bu "erişimin loglanması", hem caydırıcıdır (izlendiğini bilen kişi kötüye kullanmaz) hem de bir olay sonrası soruşturmanın temelidir. Çok faktörlü kimlik doğrulama, hassas log katmanlarına erişimde standart olmalıdır. Bu güvenlik disiplinini KVKK uyumlu yapay zeka çerçevesiyle birlikte kurmak, LLM log yönetimini bütünsel hale getirir. Log yönetimi, erişim kontrolünün ötesinde, logların tüm yaşam döngüsünü kapsayan bir disiplindir: nerede depolandıkları, nasıl şifrelendikleri, kimlerin eriştiği, ne kadar saklandıkları ve nasıl imha edildikleri. İyi bir log yönetimi, bu soruların hepsine yazılı bir politika ve teknik bir uygulama ile cevap verir. Kötü bir log yönetimi ise logları "bir yere yazıp unutmak"tır — ki bu, KVKK açısından en büyük gizli risklerden biridir. ## Üçüncü Taraf Gözlemlenebilirlik Araçları ve Yurt Dışına Veri Aktarımı Çoğu kurum, LLM gözlemlenebilirliği için hazır üçüncü taraf araçlar kullanır; bu araçlar güçlüdür ama önemli bir KVKK sorusunu beraberinde getirir: bu araç, kişisel veri içeren istem ve çıktıları nereye gönderiyor? Cevap çoğu zaman "yurt dışındaki sunuculara" olduğunda, KVKK'nın yurt dışına veri aktarımı rejimi devreye girer ve ayrı bir hukuki değerlendirme gerekir. Sorunun kökü şudur: bir gözlemlenebilirlik aracı, sisteminizi izlemek için istem ve çıktıları kendi platformuna aktarır. Eğer bu içerik maskelenmemiş kişisel veri içeriyorsa, kurumunuz o kişisel veriyi bir üçüncü tarafa ve muhtemelen başka bir ülkeye aktarmış olur. Bu, KVKK'nın en dikkat gerektiren alanlarından biridir; aktarımın hukuki dayanağı, alıcının güvenlik düzeyi ve veri işleyen ilişkisi ayrıca değerlendirilmelidir. Bulut ile yerinde barındırma arasındaki bu tercihi on-premises yapay zeka vs bulut (KVKK) yazısında ele alıyoruz. Riski azaltmanın birkaç pratik yolu vardır. En güçlüsü, veriyi hiç dışarı çıkarmamaktır: PII redaksiyonunu araca göndermeden önce uygulayarak, üçüncü tarafa yalnızca kimliksizleştirilmiş veri gitmesini sağlamak. İkincisi, verinin belirli bir bölgede kaldığı (veri ikametgâhı) veya kendi altyapınızda barındırılan bir çözüm seçmektir. Üçüncüsü, araç sağlayıcısıyla bir veri işleyen sözleşmesi (DPA) imzalamak ve yalnızca gerekli alanları aktarmaktır. Bu önlemler, gözlemlenebilirliğin faydasını korurken aktarım riskini yönetilebilir kılar. Üçüncü taraf bir gözlemlenebilirlik aracı kullanacaksanız, altın kural şudur: PII redaksiyonu, veri araca gönderilmeden önce, sizin kontrolünüzdeki bir katmanda çalışmalıdır. Böylece araca yalnızca temizlenmiş veri ulaşır ve yurt dışına veri aktarımı riski büyük ölçüde azalır. Redaksiyonu araca bırakmak, kişisel veriyi zaten dışarı çıkarmış olmak demektir. ## LLM Loglama ve KVKK Uyum Kontrol Listesi Aşağıdaki kontrol listesi, bir LLM loglama düzenini hem gözlemlenebilir hem KVKK uyumlu kurmak için pratik bir rehberdir. Her maddeyi karşılayabiliyorsanız, loglama düzeniniz savunulabilir demektir. Bu liste bir başlangıç noktasıdır; kurumunuzun özel koşulları için hukuk ve güvenlik ekiplerinizle birlikte uyarlanmalıdır. Bu kontrol listesini bir kez uygulamak yeterli değildir; loglama düzeni, model, kullanım senaryosu ve mevzuat değiştikçe düzenli olarak yeniden gözden geçirilmelidir. Kurumsal bir KVKK uyum çerçevesinin parçası olarak, bu listeyi daha geniş bir kontrol listesiyle birleştirmek için KVKK uyumlu yapay zeka kontrol listesi yazısına bakabilirsiniz. ## Türkiye, KVKK, EU AI Act ve ISO 42001 Bağlamında LLM Loglama LLM loglama bir mühendislik pratiği gibi görünse de, Türkiye ve uluslararası düzenleme bağlamında bir uyum meselesidir. Bu bölüm, ilgili çerçeveleri tanımsal ve bilgilendirici biçimde ele alır; hiçbiri hukuki tavsiye değildir ve kurumunuza özel değerlendirme için hukuk danışmanınıza başvurmalısınız. KVKK açısından, daha önce belirtildiği gibi, LLM loglama bir veri işleme faaliyetidir ve veri sorumlusunun genel yükümlülüklerine tabidir: hukuki dayanak, aydınlatma, veri güvenliği, minimizasyon ve sınırlı saklama süresi. VERBİS (Veri Sorumluları Sicil Bilgi Sistemi) kaydı ve veri işleme envanteri kapsamında, LLM loglarının da bir işleme faaliyeti olarak dikkate alınması gerekebilir. Özellikle özel nitelikli kişisel veri (sağlık, biyometrik vb.) loglara girme ihtimali varsa, ek tedbirler gündeme gelir. Türkiye'deki genel düzenleyici tabloyu Türkiye yapay zeka regülasyonu yazısında ele alıyoruz. EU AI Act (Avrupa Yapay Zeka Yasası) bağlamında ilginç bir nüans vardır: yasa, yüksek riskli yapay zeka sistemleri için kayıt tutmayı (logging) bir yükümlülük olarak öngörür — yani izlenebilirlik ve denetim için loglama beklenir. Ama aynı zamanda GDPR ile birlikte, bu logların kişisel veri korumasına uygun tutulması gerekir. Böylece iki yükümlülük bir arada var olur: "yeterince logla" (izlenebilirlik için) ve "fazla kişisel veri tutma" (veri koruması için). Bu dengeyi kurmak, tam da bu rehberin konusudur. EU AI Act'in kapsamını EU AI Act nedir ve Türk şirketlerine etkisini EU AI Act ve Türkiye şirketleri yazılarında bulabilirsiniz. ISO/IEC 42001 (yapay zeka yönetim sistemi standardı) ve NIST AI RMF (yapay zeka risk yönetimi çerçevesi), loglama ve izlenebilirliği yapay zeka yönetişiminin temel bileşenleri olarak konumlandırır. Bu çerçeveler, LLM loglamayı yalnızca teknik bir görev değil, bir yönetişim ve risk yönetimi süreci olarak ele almayı önerir. GDPR ile KVKK'nın paralel kavramlarını görmek için GDPR nedir yazısı, yönetişim çerçevesi için ise AI governance nedir ve sorumlu yapay zeka nedir yazıları yol gösterir. ## Sektörel LLM Loglama Örnekleri LLM loglamada kişisel veri riski, sektöre göre farklı ağırlıklar taşır; çünkü her sektörün topladığı veri türü ve tabi olduğu ek düzenlemeler farklıdır. Aşağıdaki örnekler, hangi sektörde hangi loglama riskinin öne çıktığını göstermek içindir. ### Finans ve Bankacılık Bankacılıkta LLM logları, hesap numaraları, işlem geçmişi, kimlik verileri ve mali durum gibi son derece hassas bilgiler içerebilir. Burada hem KVKK hem sektörel düzenlemeler (örneğin BDDK) devreye girer ve genellikle verinin yurt içinde kalması beklenir. Bu nedenle finansal LLM loglamada yerinde barındırma, güçlü maskeleme ve kısa saklama süresi öne çıkar. Bir müşteri temsilcisi asistanının logları, kart numarası veya bakiye gibi verileri asla ham biçimde tutmamalıdır. ### Sağlık Sağlıkta loglar, özel nitelikli kişisel veri olan sağlık bilgisini içerebilir ve bu, KVKK'da en ağır korumaya tabi kategoridir. Bir sağlık asistanına anlatılan semptomlar, teşhisler veya ilaç bilgileri loglandığında, hem hukuki hem etik risk çok yüksektir. Bu alanda veri minimizasyonu neredeyse zorunludur: ham içerik yerine kimliksizleştirilmiş örnekler ve toplu metrikler tercih edilmelidir. Computer vision tabanlı tıbbi görüntü sistemlerinde de benzer loglama hassasiyeti gerekir. ### E-ticaret ve Perakende E-ticarette LLM logları, sipariş bilgileri, adresler, iletişim verileri ve alışveriş davranışı içerir. Risk finansa göre daha düşük olsa da hacim çok yüksektir; milyonlarca etkileşim loglandığında, küçük bir redaksiyon açığı bile büyük miktarda kişisel veri sızıntısına dönüşebilir. Burada otomatik redaksiyonun ölçeklenebilirliği ve örneklemeyle minimizasyon kritik olur. Bir chatbot destek sisteminin logları, bu ölçek riskinin tipik örneğidir. ### Kamu ve İK Kamu hizmetlerinde ve insan kaynaklarında loglar, vatandaş veya çalışan verilerini içerir ve bunlar genellikle yüksek hassasiyetlidir. İK bağlamında çalışan performansı, özlük bilgileri veya sağlık raporları loglara girebilir; bu konuyu İK, çalışan verisi ve KVKK yazısında ele alıyoruz. Kamuda ise şeffaflık ve hesap verebilirlik ihtiyacı ile veri koruması arasındaki denge özellikle hassastır. ## LLM Loglamada Yaygın Hatalar Nelerdir? Deneyimli bir gözle bakıldığında, çoğu LLM loglama düzeni benzer hatalarla kişisel veri riskini artırır. Bu hataların ortak özelliği, hepsinin "loglama zaten teknik bir detay" varsayımından doğmasıdır. En sık görülenler şunlardır: - **Her şeyi loglamak:** "İhtiyaç olur belki" diye tüm ham istem ve çıktıları saklamak, en büyük ve en yaygın hatadır; veri minimizasyonuna aykırıdır ve devasa bir kişisel veri yığını üretir. - **Redaksiyonu kayıttan sonraya bırakmak:** PII'yi loga yazdıktan sonra temizlemeye çalışmak, ham kişisel verinin en az bir kez diske düşmesi demektir; redaksiyon her zaman kayıttan önce çalışmalıdır. - **Takma adlaştırmayı anonimleştirme sanmak:** Bir token ile değiştirilen ama geri döndürülebilen veriyi "anonim" kabul edip KVKK dışı saymak, hukuken yanlış ve risklidir. - **Saklama süresi tanımlamamak:** Logları "sonsuza kadar" tutmak, hem uyum riski hem büyüyen bir saldırı yüzeyidir; her log akışının bir imha tarihi olmalıdır. - **Yedekleri unutmak:** Ana sistemden silinen logun yedeklerde yaşamaya devam etmesi, imha politikasını sessizce çürütür. - **Üçüncü taraf araçlara ham veri göndermek:** Gözlemlenebilirlik aracına maskelenmemiş içerik aktarmak, farkında olmadan yurt dışına veri aktarımı ve üçüncü tarafa ifşa demektir. - **Erişimi sınırlamamak:** Ham loglara geniş erişim vermek, iç kaynaklı sızıntı riskini artırır; en az yetki ilkesi ihmal edilmemelidir. - **Model çıktısını masum saymak:** Yalnızca girdiyi korumak, modelin çıktısında tekrarladığı veya çıkarımladığı kişisel veriyi gözden kaçırır. Bu hataların hepsi tek bir kök nedenden çıkar: loglamayı sistemin tasarımında baştan düşünmek yerine, "önce çalıştıralım, loglamayı sonra hallederiz" demek. Oysa uyumlu LLM loglama, mimarinin başında tasarlanmalıdır; sonradan eklenen bir redaksiyon katmanı, çoktan diske düşmüş kişisel veriyi geri alamaz. Loglamayı bir sonradan-düşünce değil, bir tasarım kararı yapın. ## LLM Loglama Başarısı Nasıl Ölçülür? Uyumlu bir LLM loglama düzeni kurmak yeterli değildir; onun gerçekten çalıştığını ölçmek gerekir. Ölçüm olmadan, "uyumluyuz" iddiası bir varsayımdan ibaret kalır. Sağlam bir ölçüm çerçevesi, hem gözlemlenebilirlik hem uyum tarafını birlikte izler. Uyum tarafında birkaç temel gösterge izlenebilir: redaksiyon kapsama oranı (loglanan kayıtların ne kadarının redaksiyon boru hattından geçtiği), kalıntı PII oranı (temizlenmiş loglarda yapılan örnek denetimlerde kaçan kişisel veri oranı), saklama süresi uyumu (süresi dolan kayıtların zamanında imha edilme oranı) ve erişim uygunluğu (ham loglara erişimlerin ne kadarının gerekçeli ve yetkili olduğu). Bu göstergeler, uyumu bir kerelik bir iddiadan sürekli izlenen bir duruma çevirir. Gözlemlenebilirlik tarafında ise loglamanın asıl amacına ne kadar hizmet ettiği ölçülür: bir olay yaşandığında logların kök nedeni bulmaya ne kadar yettiği, hata ayıklama süresinin loglama sayesinde ne kadar kısaldığı ve kalite metriklerinin ne kadar güvenilir izlenebildiği. Buradaki denge önemlidir: aşırı minimizasyon, gözlemlenebilirliği zayıflatabilir; aşırı loglama ise uyumu bozar. İyi bir ölçüm çerçevesi, bu iki tarafı birlikte optimize eder. Ölçümün kendisi de bir yönetişim döngüsünün parçası olmalıdır: düzenli denetimler, kalıntı PII için örnek taramaları ve redaksiyon kurallarının güncellenmesi. Bir LLM sistemi zamanla değişir — yeni kullanım senaryoları, yeni veri türleri, yeni riskler ekler — ve loglama düzeni bu değişime ayak uydurmalıdır. LLM sistemlerinin kalitesini teknik olarak değerlendirme çerçevesini LLM değerlendirme nedir yazısında ele alıyoruz; loglama ölçümü, bu değerlendirmenin uyum boyutunu tamamlar. ## İstem Zincirleri, RAG ve Araç Çağrıları Nasıl Loglanır? Modern bir LLM uygulaması nadiren tek bir istem-yanıt çiftidir; genellikle çok adımlı bir boru hattıdır ve her adım ayrı bir loglama kararı gerektirir. Bu karmaşıklık, LLM loglama tasarımının en zorlu ama en önemli boyutudur, çünkü kişisel veri bu adımların herhangi birinde birikebilir. Boru hattını katman katman ele almak, hangi verinin nerede loglandığını görünür kılar. RAG (bilgi getirimiyle üretim) boru hatlarında, kullanıcının sorusu bir vektör veritabanında arama yapar ve getirilen belgeler isteme bağlam olarak eklenir. Bu getirilen bağlam, çoğu zaman kurumun iç belgelerinden gelir ve yoğun kişisel veri içerebilir. Eğer RAG bağlamını olduğu gibi loglarsanız, bir tek etkileşimde onlarca kişisel veri kaydını loga taşırsınız. Bu yüzden RAG boru hatlarında, getirilen belge kimliklerini (hangi belge getirildi) loglamak, belgelerin tam içeriğini loglamaktan çok daha güvenlidir. RAG, vektör veritabanı ve embedding kavramları, bu getirme katmanının nasıl çalıştığını anlamaya yardımcı olur. Ajan tabanlı sistemlerde durum daha da katmanlıdır: bir AI agent, bir hedefe ulaşmak için çok adımlı akıl yürütme yapar, araçlar çağırır ve ara sonuçlar üretir. Bu ara adımların her biri — akıl yürütme zinciri, araç girdileri ve çıktıları — loglanabilir ve her biri kişisel veri taşıyabilir. Örneğin bir ajan, kullanıcı adına bir CRM sorgusu çalıştırırsa, o sorgunun sonucu kişisel veri içerir ve loga girer. Agentic AI, function calling ve MCP gibi mekanizmalar, araçların modele nasıl bağlandığını ve dolayısıyla hangi verinin aktığını belirler. Ajan loglamasında altın kural, araç çıktılarını da tıpkı model çıktıları gibi redaksiyon boru hattından geçirmektir. Yapılandırılmış loglama (structured logging) ve izleme (tracing), bu karmaşıklığı yönetmenin teknik yoludur. Her adımı yapılandırılmış alanlar halinde (adım türü, süre, token, redakte edilmiş içerik) loglamak, hem hata ayıklamayı kolaylaştırır hem de redaksiyonu alan bazında hassas uygulamayı mümkün kılar. Serbest metni tek bir büyük string olarak loglamak yerine, boru hattını yapılandırılmış izlere bölmek, hangi alanın kişisel veri içerdiğini ve nasıl korunacağını netleştirir. Bu yaklaşım, prompt engineering disiplininin operasyonel karşılığıdır: nasıl ki iyi bir istem tasarımı çıktıyı iyileştirir, iyi bir loglama tasarımı da gözlemlenebilirliği ve uyumu birlikte iyileştirir. Çok adımlı boru hatlarında güçlü bir minimizasyon tekniği şudur: bir belgenin veya kaydın tam içeriğini loglamak yerine, ona işaret eden bir kimlik (belge no, kayıt no) loglayın. Böylece bir sorunu ayıklarken hangi belgenin kullanıldığını bilirsiniz ama kişisel veriyi loga taşımazsınız. İçerik, gerekirse ayrı ve korumalı kaynağından, yetkiyle çekilir. ## Veri Sahibi Hakları LLM Loglarını Nasıl Etkiler? KVKK, kişilere verileri üzerinde bir dizi hak tanır: verisine erişme, düzeltme, silme (unutulma) ve işlemeye itiraz etme gibi. Bu haklar, LLM loglama için sıkça gözden kaçan ama kritik bir yükümlülük doğurur: bir kişi verisinin silinmesini talep ettiğinde, bu talep loglardaki kişisel veriyi de kapsar. Loglarınız bu talebe cevap veremeyecek biçimde tasarlanmışsa, ciddi bir uyum boşluğunuz var demektir. Sorunun teknik zorluğu şudur: serbest metin loglarında bir kişinin verisini bulmak ve silmek, yapılandırılmış bir veritabanında bir satırı silmekten çok daha zordur. Bir kullanıcının adı, on binlerce log kaydının içine serbest metin olarak dağılmış olabilir. Eğer loglarınızı bir kullanıcı kimliğiyle ilişkilendirebiliyorsanız (takma adlaştırma ile), o kullanıcıya ait tüm kayıtları bulmak ve silmek mümkün olur. İşte bu, takma adlaştırmanın anonimleştirmeye göre bir avantajıdır: veri sahibi haklarını uygulanabilir kılar. Bu noktada bir denge vardır. Tamamen anonim loglar, veri sahibi haklarından muaf olabilir (çünkü artık kişisel veri değildir) ama silme talebine de "zaten anonim" cevabını verebilmek için gerçek anonimleştirme kanıtlanabilir olmalıdır. Takma adlaştırılmış loglar ise silme talebini karşılayabilir ama bu yeteneğin baştan tasarlanmış olması gerekir. Kısacası, veri sahibi haklarını hangi log tasarımının nasıl karşılayacağı, sistem kurulmadan önce düşünülmelidir; sonradan eklenmesi çok zordur. Pratik bir yaklaşım, saklama süresini kısa tutarak veri sahibi hakları yükünü azaltmaktır: eğer loglar zaten kısa sürede otomatik imha ediliyorsa, bir silme talebi geldiğinde silinecek veri miktarı ve süresi sınırlı olur. Bu, minimizasyon ve kısa saklamanın bir kez daha neden bu kadar değerli olduğunu gösterir. Kişisel veri kavramının hukuki sınırlarını kişisel veri nedir ve genel çerçeveyi KVKK nedir yazılarında bulabilirsiniz. ## LLM Loglama ile Güvenlik ve Prompt Injection İlişkisi Nedir? LLM loglama, kişisel veri riskinin ötesinde bir güvenlik boyutu da taşır; çünkü loglar hem bir güvenlik aracı hem de bir güvenlik hedefidir. Bir yandan loglar, saldırıları ve kötüye kullanımı tespit etmek için gereklidir; diğer yandan, kişisel veri içeren loglar bizzat değerli bir saldırı hedefidir. Bu ikili doğa, LLM loglamayı güvenlik tasarımının ayrılmaz parçası yapar. Güvenlik aracı olarak loglar, prompt injection (istem enjeksiyonu) gibi saldırıları tespit etmede kritiktir. Bir saldırgan, modeli kandırmak için özel hazırlanmış istemler gönderdiğinde, bu girişimler loglara yansır ve anormal desenler olarak yakalanabilir. Benzer biçimde, modelin sistem promptunu sızdırmaya çalışan girişimler veya guardrail'leri aşma denemeleri, ancak loglandıkları takdirde tespit edilebilir. Bu yüzden güvenlik açısından belirli olayları loglamak zorunludur; ama bu loglar da kişisel veri koruması ile dengelenmelidir. Saldırı hedefi olarak loglar, ciddi bir risk oluşturur. Kişisel veri içeren bir log deposu, bir veri ihlalinde saldırganın eline geçebilecek en değerli varlıklardan biridir; çünkü orada binlerce kullanıcının istemleri ve modelin yanıtları toplu halde durur. Bu yüzden loglar, ana veritabanı kadar (bazen daha fazla) korunmalıdır: şifreleme, erişim kontrolü, ağ izolasyonu ve düzenli güvenlik denetimi. Guardrail katmanları, hem çıktı güvenliğini sağlar hem de loglanacak olayları filtrelemede rol oynar. Bir başka incelik, güvenlik logları ile içerik logları arasındaki ayrımdır. Güvenlik amaçlı loglar (kimin ne zaman eriştiği, hangi anormal olayın yaşandığı) genellikle daha uzun saklanmalı ve daha az kişisel veri içermelidir; içerik logları (istem/çıktı) ise daha kısa saklanmalı ve daha yoğun redaksiyondan geçmelidir. Bu iki log türünü ayrı yönetmek, hem güvenliği hem uyumu güçlendirir. Yapay zeka güvenliğinin daha geniş çerçevesini sorumlu yapay zeka nedir yazısında ele alıyoruz. ## LLM Loglamayı Kendi Altyapında mı, Bulutta mı Yönetmeli? LLM loglama düzenini nerede barındıracağınız — kendi altyapınızda mı, bulutta mı — hem gözlemlenebilirliği hem KVKK uyumunu doğrudan etkileyen stratejik bir karardır. Bu karar, tek bir doğru cevabı olmayan bir ödünleşimdir; kurumun risk iştahı, veri hassasiyeti ve teknik kapasitesi belirleyicidir. Kendi altyapınızda (on-premises veya kendi bulut ortamınızda) loglama, en yüksek kontrolü sunar: kişisel veri hiç dışarı çıkmaz, yurt dışına veri aktarımı sorunu doğmaz ve tüm erişim sizin denetiminizdedir. Bunun bedeli, operasyonel yüktür — log altyapısını kurmak, ölçeklemek, güvenliğini sağlamak ve bakımını yapmak kaynak gerektirir. Yüksek hassasiyetli veri işleyen kurumlar (finans, sağlık, kamu) için bu kontrol, çoğu zaman ek yüke değer. Bu tercihi ayrıntılı olarak on-premises yapay zeka vs bulut (KVKK) yazısında ele alıyoruz. Bulut tabanlı veya üçüncü taraf loglama, düşük operasyonel yük ve hızlı kurulum sunar; ama daha önce ele aldığımız aktarım ve ifşa risklerini beraberinde getirir. Bulut kullanılıyorsa, verinin hangi bölgede saklandığı (veri ikametgâhı), sağlayıcıyla imzalanan veri işleyen sözleşmesi ve araca gönderilen verinin redaksiyon düzeyi kritik hale gelir. Bulutta bile, kişisel veriyi araca göndermeden önce redakte etmek, riski büyük ölçüde azaltır. Çoğu kurum için en pratik yaklaşım melez bir modeldir: kişisel veri içeren hassas içerik logları kendi kontrolünüzdeki bir katmanda tutulurken, kimliksizleştirilmiş operasyonel metrikler bulut tabanlı bir gözlemlenebilirlik aracında izlenir. Bu ayrım, bulutun kolaylığını korurken kişisel veriyi kendi sınırlarınızın içinde tutar. Kararı verirken, açık kaynak barındırma seçeneklerinin de değerlendirilmesi faydalıdır; açık kaynak LLM nedir ve Ollama nedir yazıları, verinin bölgede kaldığı barındırma seçeneklerine giriş sunar. ## LLM Loglama Politikası Nasıl Yazılır? Teknik önlemler kadar önemli olan bir şey, bunları bir arada tutan yazılı bir LLM loglama politikasıdır. Politika, "biz bu logları neden, nasıl ve ne kadar süre tutuyoruz?" sorusuna kurumsal ve tekrarlanabilir bir cevap verir; bir denetimde uyumun kanıtı, bir olayda ise başvuru kaynağıdır. Politikasız bir loglama düzeni, bireylerin kişisel tercihlerine bağlı, tutarsız ve savunulamaz bir hale gelir. İyi bir LLM loglama politikası birkaç temel bölümü kapsar. Amaç ve kapsam: hangi sistemlerin loglandığı ve neden. Veri envanteri: hangi log akışında hangi kişisel verinin biriktiği. Hukuki dayanak ve aydınlatma: işlemenin KVKK temeli ve kullanıcıların nasıl bilgilendirildiği. Minimizasyon ve redaksiyon kuralları: ne loglanır, ne loglanmaz, hangi PII maskelenir. Saklama ve imha: her akış için saklama süresi ve imha yöntemi. Erişim: kimin hangi loga hangi koşulda erişebileceği. Aktarım: üçüncü taraf araçlar ve yurt dışı aktarım değerlendirmesi. Ve gözden geçirme: politikanın ne sıklıkla güncelleneceği. Politikanın canlı bir belge olması kritiktir. Bir LLM sistemi değiştikçe — yeni bir kullanım senaryosu eklendiğinde, yeni bir veri türü işlendiğinde veya mevzuat güncellendiğinde — politika da güncellenmelidir. Politikayı bir kez yazıp rafa kaldırmak, onu gerçeklikten kopuk bir belgeye dönüştürür. Bu yüzden düzenli gözden geçirme ve gerçek uygulama ile politika arasındaki tutarlılık denetimi, politikanın ayrılmaz parçasıdır. Bu politikayı daha geniş kurumsal yapay zeka yönetişimine bağlamak için AI governance nedir yazısı yol gösterir. Politikanın uygulanabilir olması için sorumluluğun net dağıtılması gerekir: her maddeyi kimin sahiplendiği (mühendislik, güvenlik, hukuk, uyum) yazılı olmalıdır. Sorumluluğun belirsiz olduğu yerde, herkesin işi olan hiç kimsenin işi olmaz. Kurumsal düzeyde bir KVKK uyum programının parçası olarak, LLM loglama politikasını mevcut veri koruma politikalarınızla uyumlandırmak, tekrarı önler ve tutarlılık sağlar. ## LLM Loglamada Depolama ve Maliyet Nasıl Optimize Edilir? LLM loglama yalnızca bir uyum konusu değil, aynı zamanda bir maliyet kalemidir; ve ilginç biçimde, uyum-odaklı iyi tasarım genellikle maliyeti de düşürür. Ham istem ve çıktıları yüksek hacimde ve süresiz saklamak, hem büyük bir depolama faturası hem de büyük bir uyum riski üretir. Minimizasyon her iki sorunu birden çözer. Depolama maliyetini optimize etmenin birkaç yolu vardır. Katmanlı depolama: sık erişilen taze loglar hızlı ama pahalı depolamada, eski loglar yavaş ama ucuz arşiv katmanında tutulur; ve saklama süresi dolduğunda otomatik silinir. Örnekleme: her etkileşim yerine temsili bir örneklem loglanarak hacim düşürülür. Sıkıştırma ve toplama: bireysel kayıtlar yerine toplu metrikler saklanarak hem yer kazanılır hem kişisel veri ayak izi küçülür. Bu tekniklerin hepsi, aynı zamanda kişisel veri riskini de azaltır — çünkü daha az veri, daha az risk demektir. Maliyet ile gözlemlenebilirlik arasında bir denge vardır: çok az loglamak maliyeti düşürür ama kör noktalar yaratır; çok fazla loglamak ise hem pahalı hem risklidir. Doğru nokta, her log akışının değerini maliyetine karşı tartarak bulunur. "Bu logu tutmanın operasyonel değeri, depolama ve uyum maliyetini haklı çıkarıyor mu?" sorusu, her akış için sorulmalıdır. Bu değerlendirme, yapay zeka sistemlerinin toplam maliyetini yönetmenin bir parçasıdır; ilgili çerçeveyi yapay zeka ROI nasıl hesaplanır yazısında bulabilirsiniz. Uzun vadede, loglama maliyetini yönetmenin en sürdürülebilir yolu, onu baştan doğru tasarlamaktır. Sonradan "loglar çok büyüdü, temizleyelim" demek hem zor hem risklidir; oysa baştan minimizasyon, redaksiyon ve saklama süresi ile tasarlanmış bir düzen, hem maliyeti hem riski sürekli kontrol altında tutar. Bu, LLM loglamanın tekrar tekrar karşımıza çıkan temel dersidir: iyi tasarım, uyumu ve verimliliği aynı anda kazandırır. ## LLM Loglamada Ekip, Kültür ve Farkındalık Neden Önemli? En iyi teknik loglama mimarisi bile, onu işleten ekip kişisel veri duyarlılığını içselleştirmediyse riske açıktır. LLM loglama, salt bir mühendislik meselesi değil, aynı zamanda bir kültür ve farkındalık meselesidir; çünkü günlük kararlar — "şu alanı da loglayalım", "hata ayıklama için ham veriye bir bakayım" — çoğu zaman politikanın değil, alışkanlığın ürünüdür. Ekip kültürünü güçlendirmenin ilk adımı farkındalıktır: geliştiricilerin, veri bilimcilerin ve ürün ekiplerinin, bir istem loglandığında oraya hangi kişisel verinin girebileceğini ve bunun neden riskli olduğunu anlamaları gerekir. Bu farkındalık, soyut bir kural olarak değil, somut örneklerle (bir müşterinin TC kimlik numarasını yazdığı gerçek bir senaryo gibi) çok daha kalıcı olur. Yapay zeka okuryazarlığı ve ekiplerin doğru yetkinlik kazanması için kurumsal yapay zeka eğitimi yazıları, bu kültürel dönüşümün temelini oluşturur. İkinci adım, doğru olanı kolay yapmaktır: eğer uyumlu loglama, ekip için zahmetliyse, insanlar kestirme yollar bulur. Bu yüzden redaksiyon boru hattı, varsayılan olarak açık ve şeffaf olmalı; ham veriye erişim ise bilinçli bir çaba gerektirmelidir. Güvenli varsayılanlar (secure defaults), bir kültürü kurallardan daha etkili biçimde şekillendirir. Ekip bir yeni özellik eklerken loglamayı düşünmeyi bir refleks haline getirdiğinde, LLM loglama artık sonradan-düşünce değil, tasarımın doğal bir parçası olur. Son olarak, hesap verebilirlik kültürü önemlidir: loglama kararlarının sahibi belli olmalı, düzenli denetimler bir suçlama değil öğrenme fırsatı olarak görülmeli ve kişisel veri koruması bir kısıt değil, kullanıcıya duyulan saygının bir ifadesi olarak konumlanmalıdır. Bu kültürel zemin kurulduğunda, teknik önlemler gerçekten çalışır; kurulmadığında ise en gelişmiş mimari bile insan alışkanlıklarının açtığı gediklerden sızar. ## Sıkça Sorulan Sorular ### LLM loglama nedir? LLM loglama, üretim ortamında çalışan bir büyük dil modeli (LLM) uygulamasının aldığı istemleri (prompt), ürettiği yanıtları, model ve token kullanımını, gecikme sürelerini ve hata olaylarını sistematik biçimde kayıt altına alma pratiğidir. Amaç; sistemin gözlemlenebilirliğini sağlamak, hataları ayıklamak, kaliteyi izlemek ve denetim için kanıt üretmektir. Ancak bu kayıtlar istem ve çıktı içinde kişisel veri barındırabildiği için LLM loglama, aynı zamanda KVKK kapsamında dikkatle yönetilmesi gereken bir veri işleme faaliyetidir. ### LLM loglarında hangi kişisel veriler birikir? Loglarda üç ana yerde kişisel veri birikir: kullanıcı girdisi (kullanıcının serbest metin olarak yazdığı ad, e-posta, telefon, TC kimlik numarası, adres), prompt içeriği (sisteme bağlam olarak eklenen müşteri kaydı, sözleşme veya CRM verisi) ve model çıktısı (modelin yanıtında tekrar ürettiği veya çıkarımladığı kişisel bilgi). Buna ek olarak IP adresi, oturum kimliği, kullanıcı kimliği gibi meta veriler de kişisel veri sayılabilir. LLM loglama tasarlanırken bu üç katmanın her biri ayrı ayrı ele alınmalıdır. ### KVKK açısından LLM logları kişisel veri sayılır mı? Bir log kaydı, kimliği belirli veya belirlenebilir bir gerçek kişiye ilişkin bilgi içeriyorsa KVKK anlamında kişisel veridir; bu, LLM loglarının çok büyük bölümü için geçerlidir çünkü istem ve çıktı doğrudan kullanıcı etkileşiminden gelir. Log gerçekten anonim hale getirilmediyse (geri döndürülemez biçimde kimliksizleştirilmediyse) kişisel veri statüsü devam eder. Dolayısıyla LLM loglama; hukuki dayanak, aydınlatma yükümlülüğü, veri güvenliği tedbirleri ve saklama süresi sınırı gibi KVKK gerekliliklerine tabidir. Bu bir hukuki tavsiye değil, genel bir bilgilendirmedir; kurumunuza özel değerlendirme için hukuk danışmanınıza başvurun. ### LLM loglarında veri maskeleme nasıl yapılır? Loglarda veri maskeleme, kişisel veriyi kayıt anından önce tespit edip kısmen veya tamamen gizlemektir: örneğin bir e-postayı 'a***@***.com' biçimine getirmek, TC kimlik numarasını yıldızlamak veya adı bir token ile değiştirmek. İki temel yaklaşım vardır: geri döndürülemez maskeleme (veri tamamen silinir) ve takma adlaştırma (pseudonymization — veri tutarlı bir takma adla değiştirilir, ayrı ve korumalı bir eşleştirme ile gerektiğinde geri döndürülebilir). Veri maskeleme, PII tespiti yapan bir ön işleme katmanıyla otomatikleştirilmeli ve loga yazılmadan önce çalışmalıdır. ### LLM logları ne kadar süre saklanmalı? Tek bir doğru saklama süresi yoktur; süre, logun amacına ve veri minimizasyonu ilkesine göre belirlenir. Hata ayıklama için ayrıntılı istem/çıktı logları genellikle kısa tutulur (örneğin günler ile birkaç hafta), toplu ve kimliksizleştirilmiş metrikler ise daha uzun saklanabilir. Kritik olan, her log akışı için önceden tanımlı bir saklama süresi belirlemek, bu süreyi bir imha politikasıyla otomatik uygulamak ve süre dolduğunda kayıtları güvenli biçimde silmektir. Süresiz saklama, hem KVKK açısından risk hem de gereksiz bir saldırı yüzeyidir. ### Üçüncü taraf gözlemlenebilirlik araçları KVKK açısından risk oluşturur mu? Evet, dikkatle yönetilmezse oluşturabilir. LLM gözlemlenebilirliği için kullanılan birçok araç, istem ve çıktıları kendi sunucularına (çoğu zaman yurt dışında) gönderir; bu, KVKK'nın yurt dışına veri aktarımı rejimini devreye sokar ve ayrı bir hukuki değerlendirme gerektirir. Risk azaltmak için: araca gönderilmeden önce PII redaksiyonu uygulamak, mümkünse verinin bölgede kaldığı veya kendi altyapınızda barındırılan bir seçenek seçmek, veri işleyen sözleşmesi (DPA) imzalamak ve yalnızca gereken alanları aktarmak önerilir. Kişisel veriyi hiç dışarı çıkarmamak, en güvenli yaklaşımdır. ### LLM loglarında PII tespiti ve otomatik redaksiyon nasıl çalışır? PII tespiti, bir metin içindeki kişisel veriyi (ad, e-posta, telefon, TC kimlik numarası, kart numarası, adres) otomatik olarak bulan bir katmandır; genellikle desen tabanlı kurallar (regex), sözlükler ve makine öğrenmesi/NER modellerinin birleşiminden oluşur. Otomatik redaksiyon ise tespit edilen bu alanları maskeleyerek veya bir yer tutucuyla değiştirerek loga temizlenmiş bir sürüm yazar. Bu boru hattı, kayıt yazılmadan önce (yani veri diske düşmeden) çalışmalıdır; aksi halde ham kişisel veri loga girer ve redaksiyon anlamını yitirir. Hiçbir otomatik sistem kusursuz değildir, bu yüzden veri minimizasyonu ile birlikte kullanılmalıdır. ### LLM loglarına erişim kontrolü nasıl kurulur? Erişim kontrolünün temeli en az yetki (least privilege) ilkesidir: log kayıtlarına yalnızca işini yapmak için gerçekten ihtiyacı olan kişiler, yalnızca ihtiyaç duydukları ölçüde erişebilmelidir. Pratikte bu; rol tabanlı erişim (RBAC), kişisel veri içeren logların ayrı ve daha sıkı korumalı bir katmanda tutulması, tüm erişimlerin denetim iziyle kaydedilmesi, çok faktörlü kimlik doğrulama ve loglara erişimin de ayrıca loglanması anlamına gelir. Ayrıca ham (maskelenmemiş) loglara erişim istisnai ve gerekçeli olmalı, varsayılan görünüm her zaman maskelenmiş sürüm olmalıdır. ### LLM loglama ile LLM gözlemlenebilirliği arasındaki fark nedir? LLM loglama, ham olayları (istem, çıktı, hata, gecikme) kayıt altına alan temel katmandır; gözlemlenebilirlik ise bu loglar, metrikler ve izler (trace) üzerine kurulan, sistemin davranışını anlamayı ve sorunları teşhis etmeyi sağlayan daha geniş disiplindir. Başka bir deyişle loglama veriyi üretir, gözlemlenebilirlik o veriyi anlamlı içgörüye çevirir. İkisi de KVKK açısından aynı riski taşır çünkü ikisi de kişisel veri içerebilen istem ve çıktılara dayanır; bu yüzden veri maskeleme, saklama süresi ve erişim kontrolü her iki katmanda da uygulanmalıdır. ## Özetle: LLM Loglama ve KVKK Özetle LLM loglama, üretimdeki dil modeli sistemlerinin güvenle işletilmesi için zorunlu ama kişisel veri açısından riskli bir pratiktir. Doğru cevap "loglamayı kapatmak" değil, onu bilinçli tasarlamaktır: gözlemlenebilirlik, hata ayıklama ve denetim ihtiyacını karşılarken, kişisel veriyi veri minimizasyonu, loglarda veri maskeleme ve takma adlaştırma, tanımlı bir saklama süresi ve imha politikası, sıkı erişim kontrolü ve kayıttan önce çalışan PII tespiti ile otomatik redaksiyon yoluyla korumak. Üçüncü taraf gözlemlenebilirlik araçlarında yurt dışına veri aktarımını ayrıca değerlendirmek ve tüm bu düzeni bir kontrol listesiyle sürekli denetlemek, uyumlu bir LLM loglama düzeninin temelidir. En önemli mesaj şudur: LLM loglama bir sonradan-düşünce değil, bir tasarım kararıdır. Loglamayı sistemin başında, kişisel veriyi merkeze alarak tasarlayan kurumlar, hem gözlemlenebilirliği hem uyumu birlikte kazanır. Temel kavramlar için LLM nedir ve yapay zeka nedir rehberlerine, KVKK çerçevesi için KVKK uyumlu yapay zeka nedir yazısına göz atabilir; kurumunuza özel bir LLM loglama ve KVKK uyum mimarisi için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin yetkinliği için kurumsal eğitim seçeneklerini inceleyebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.