Loglama, Denetim İzi ve Kanıtlanabilirlik — Güvenlik ve Kurumsal Yönetişim

Kazanimlar:

Olayı yeniden kurmaya yetecek minimum denetim izi şeması tasarlayabilme
İstem/yanıtı maskeleyerek logu bir sızıntı kaynağı olmaktan çıkarabilme
Korelasyon kimliği, değiştirilemezlik ve saklama süresiyle kanıtlanabilir loglar kurabilme

Bir AI sisteminde bir gün mutlaka şu soru sorulur: "Bu karar neden böyle verildi, o gün tam olarak ne oldu?" Bu soruyu bir müşteri, bir denetçi, bir düzenleyici ya da bir mahkeme sorabilir. Cevabınız ya kanıtlanabilir bir denetim izi (audit trail) olur ya da "bilmiyoruz" olur. İkincisi kurumsal ortamda kabul edilemez. Bu ünitede AI'ya özgü ne loglanmalı, ne loglanmamalı, denetim izi nasıl kurulur ve loglar güvenlik ile gizlilik dengesinde nasıl tutulur öğreneceğiz.

Loglama Neden AI'da Farklıdır?

Klasik yazılımda "kim ne yaptı" loglanır. AI'da buna üç yeni boyut eklenir: hangi model/versiyon kullanıldı, hangi istem (prompt) gönderildi ve hangi yanıt üretildi. Bir hata veya şikâyet geldiğinde bu üçü olmadan olayı yeniden kuramazsınız. Ama tam da bu istem/yanıt, ünite 2'de gördüğümüz gibi PII içerebilir — yani logun kendisi bir sızıntı kaynağına dönüşebilir. Denge sanatı buradadır.

Dikkat: Loglama "her şeyi kaydet" değildir. Fazla loglama gizlilik riski, az loglama ise kanıtsızlık yaratır. Amaç, olayı yeniden kurmaya yetecek kadarını, PII'yi maskeleyerek tutmaktır.

Ne Loglanmalı? Denetim İzi Şeması

Sağlam bir AI denetim kaydı en az şunları içerir:

Kim: Kullanıcı kimliği ve rolü (veya servis kimliği).
Ne zaman: Zaman damgası (mümkünse değiştirilemez / append-only).
Ne: İstenen eylem ve çağrılan araçlar.
Hangi model: Model adı ve versiyonu (örneğin claude-opus-4-8), sıcaklık gibi kritik parametreler.
Girdi/çıktı özeti: İstem ve yanıtın maskelenmiş hali veya bir özeti/hash'i.
Karar: Otomatik mi işlendi, insana mı gitti, onaylandı mı reddedildi mi?
Sonuç: İşlem başarılı mı, hata mı, hangi kaynak etkilendi?

Adım Adım: Denetim İzi Kurmak

Amaç belirleyin. Bu logları kim, ne için okuyacak? (Olay müdahalesi, uyum denetimi, hata ayıklama.) Amaç, ne tutacağınızı belirler.
PII politikasını uygulayın. İstem/yanıtı loglamadan önce maskeleyin (ünite 2).
Değiştirilemezlik sağlayın. Kritik loglar append-only olsun; kimse geçmişi sessizce silememeli.
Saklama süresi tanımlayın. Yasal gereksinim ve gizlilik dengesine göre süre belirleyin; süre dolunca otomatik silin.
Erişimi sınırlayın. Loglara erişim de RBAC ile korunmalı; log okuma da loglanmalı.
Korelasyon kimliği (trace ID) ekleyin. Bir isteğin tüm adımlarını (girdi, araç çağrısı, doğrulama, çıktı) tek bir kimlikle birbirine bağlayın.

Dört Kopyalanabilir Şablon

Denetim kaydı şeması (JSON):

{ "trace_id": "...", "zaman": "YYYY-AA-GGThh:mm:ssZ", "kullanici": "...", "rol": "...", "model": "claude-opus-4-8", "parametreler": { "sicaklik": 0 }, "istem_ozeti": "<maskelenmiş>", "yanit_ozeti": "<maskelenmiş>", "araclar": ["arac_a", "arac_b"], "karar": "otomatik|insan_onayi", "onay": "onaylandi|reddedildi|yok", "sonuc": "basarili|hata", "etkilenen_kaynak": "..."}

Log PII denetim promptu:

Aşağıdaki log örneklerini incele. Denetim izi için gerekli olanalanlar (kim, ne zaman, model, karar, sonuç) tam mı? Aynı zamandaham PII sızmış mı? Her satır için: "yeterli / eksik alan: ... /PII sızıntısı: ..." biçiminde raporla.<loglar>{{ ornekler }}</loglar>

Olay yeniden kurma promptu:

Aşağıdaki denetim kayıtları tek bir trace_id'ye ait. Olayı zamansırasıyla bir anlatıya dönüştür: kullanıcı ne istedi, model neyaptı, hangi doğrulamalar çalıştı, karar nasıl verildi, sonuç neoldu? Eksik veya tutarsız adımları işaretle.<kayitlar>{{ trace_kayitlari }}</kayitlar>

Saklama politikası karar kuralı:

Her log türü için belirle:- Yasal saklama zorunluluğu var mı? (varsa asgari süre)- PII içeriyor mu? (içeriyorsa süreyi kısalt, erişimi darat)- Güvenlik olayı kanıtı mı? (ise değiştirilemez sakla)Sonuç: "sakla N gün + append-only mi + erişim seviyesi".

Zayıf Prompt / Güçlü Prompt

Zayıf yaklaşım

Güçlü yaklaşım

Hiç loglamamak ("gerekmez")

Olayı yeniden kuracak minimum seti loglamak

Ham istem/yanıtı olduğu gibi loglamak

Maskelenmiş özet + trace ID loglamak

Logları sınırsız saklamak

Yasal + gizlilik dengesiyle saklama süresi

Logları herkesin silebilmesi

Kritik loglar append-only, erişim denetimli

Üç Mini Vaka

Vaka 1 — Trace ID bir günlük araştırmayı 15 dakikaya indirdi. Bir bankanın kredi ön değerlendirme asistanında bir müşteri "başvurum haksız reddedildi" dedi. Korelasyon kimliği sayesinde ekip, o başvurunun girdisini, çalışan doğrulamaları ve kararı 15 dakikada yeniden kurdu; hatanın bir kural doğrulamasındaki yanlış eşikten kaynaklandığını gösterdi ve düzeltti.

Vaka 2 — Fazla loglama denetimde bulgu oldu. Bir e-ticaret firması, hata ayıklama için tüm istem/yanıtları ham loglara yazıyordu. Yıllık denetimde bu logların müşteri adres ve telefonlarını içerdiği ve 2 yıl saklandığı görüldü. Maskeleme + 90 gün saklama politikasına geçilerek bulgu kapatıldı; denetim izi işlevi ise korundu.

Vaka 3 — Append-only log bir iç suistimali ortaya çıkardı. Bir sağlayıcıda bir çalışan, yaptığı hatalı bir toplu işlemi gizlemek için logları silmeye çalıştı. Loglar append-only olduğu ve log okuma/silme denemeleri de kaydedildiği için girişim anında görünür oldu; olay disiplin ve süreç düzeltmesiyle sonuçlandı.

İpucu: Her isteğe bir korelasyon kimliği (trace ID) atayın ve tüm adımlarda taşıyın. Bir sorun geldiğinde "o istekle ilgili her şeyi" tek sorguyla toplayabilmek, olay müdahalesinin en büyük hızlandırıcısıdır.

Sık yapılan hatalar

Hiç loglamamak veya olayı yeniden kuramayacak kadar az loglamak.
Ham istem/yanıtı maskesiz loglayıp logu bir sızıntı kaynağına çevirmek.
Model adı/versiyonunu ve kararı (otomatik/insan) loglamamak.
Logları sınırsız süreyle saklayıp gizlilik riski biriktirmek.
Kritik logları değiştirilebilir bırakmak; log erişimini loglamamak.
Korelasyon kimliği (trace ID) kullanmadığı için adımları birbirine bağlayamamak.

Özetle

AI loglaması "kim ne yaptı"ya üç boyut ekler: hangi model/versiyon, hangi istem, hangi yanıt.
Amaç, olayı yeniden kurmaya yetecek minimumu, PII'yi maskeleyerek tutmaktır — ne fazla ne eksik.
Denetim izi kim/ne zaman/ne/hangi model/karar/sonuç alanlarını içermeli.
Kritik loglar değiştirilemez (append-only) olmalı, erişimi sınırlanmalı ve log erişimi de loglanmalı.
Korelasyon kimliği (trace ID) bir isteğin tüm adımlarını bağlar ve olay araştırmasını hızlandırır.

Uygulama görevi

Kendi AI akışınızdan bir istek seçin ve onun için ideal denetim kaydını yukarıdaki JSON şemasıyla yazın. Ardından iki test yapın: (1) Yalnızca bu kayıtla olayı baştan sona anlatabiliyor musunuz? (2) Kayıtta ham PII var mı? Eksik alan varsa ekleyin, PII varsa maskeleyin. Son olarak bir saklama süresi ve erişim seviyesi belirleyin.

Kontrol listesi

[ ] Denetim izi kim/ne zaman/ne/model/karar/sonuç alanlarını içeriyor.
[ ] İstem/yanıt loglardan önce maskeleniyor (PII yok).
[ ] Her isteğe korelasyon kimliği (trace ID) atanıyor.
[ ] Kritik loglar append-only ve erişimi denetimli.
[ ] Saklama süresi yasal + gizlilik dengesiyle tanımlı, süre sonunda siliniyor.
[ ] Loglarla bir olayı 30 dakikadan kısa sürede yeniden kurabiliyorum.