Kurumsal AI güvenliği tartışması genellikle modelin ne söylediği üzerine kurulu. Pratikte asıl risk ters yönde akıyor: modele ne gönderildiği. Bir çalışan hata ayıklarken bir log parçasını, bir yapılandırma dosyasını, bir istek gövdesini olduğu gibi yapıştırır. İçinde ne olduğuna bakmaz, çünkü amacı hatayı çözmektir, veri sınıflandırmak değil.
Bunun en bilinen örneği Samsung. Mühendislerin dahili kaynak kodunu ChatGPT'ye yapıştırması üzerine şirketin 2023'te çalışanların ChatGPT kullanımını yasakladığı geniş biçimde haber oldu. Olayın öğrettiği şey yasak değil: kaynak kodu yapıştıran mühendislerin hiçbiri veri sızdırmaya çalışmıyordu. Sadece işlerini yapıyorlardı.
Kendi verimizle ölçtük
Temmuz 2026'da kendi Claude Code transkriptlerimizden 739 gerçek görevi taradık. Aynı içerik üzerinde iki yöntemi paralel çalıştırdık:
- Deterministik regex taraması — bilinen kimlik bilgisi kalıpları, önek imzaları, entropi eşikleri.
- LLM sınıflandırıcı — "bu içerikte hassas bilgi var mı" sorusunu bir modele soran yaklaşım.
Sonuç:
| Yöntem | Bulduğu sızmış kimlik bilgisi |
|---|---|
| Deterministik regex taraması | 7 |
| LLM sınıflandırıcı (aynı içerik) | 7 kaydın 4'ünü hassas olarak işaretledi |
Kaçırılan üç kayıt arasında aktif bir üretim API anahtarı vardı. Sınıflandırıcı onu sıradan iş metni olarak etiketledi.
Model anahtarı görmedi değil — gördü ve zararsız saydı. Bir sızıntı tespit hattının yüzde 43'lük bir kaçırma oranıyla çalışması, o hattın var olmaması ile aynı sonucu doğurur: güvenlik ekibi yeşil gösterge görür ve aramayı bırakır.
739 görev istatistiksel olarak büyük bir örneklem değil. Ama bu sonuç için büyük örnekleme ihtiyaç yok: sorun bir oran sorunu değil, bir yöntem sorunu. Bir kimlik bilgisinin sır olup olmaması, biçiminden belirlenebilen deterministik bir gerçektir. Bunu olasılıksal bir sisteme sormak, kesin cevabı olan bir soruyu tahmine çevirmektir.
Neden model kaçırıyor
Sınıflandırıcının davranışı aslında tutarlı. Model "hassas" kelimesini bağlamdan öğrenir; bağlam hassaslık sinyali vermiyorsa etiketi de vermez. Kaçırmayı kolaylaştıran tipik durumlar:
- Anahtar, çalışan koda gömülü. Etrafındaki her şey normal koda benzediği için parça da normal görünür.
- Anahtar bir örnek gibi duruyor.
test,example,demokelimelerinin yakınında geçen gerçek anahtarlar sistematik olarak zararsız sayılır. - Uzun içerik. Sekiz yüz satırlık bir logun ortasındaki tek satır, özet baskısı altında eriyip gider.
- Bilinmeyen önek. Modelin eğitiminde sık geçmeyen bir sağlayıcının anahtar formatı, kimlik bilgisi olarak tanınmaz.
Regex bunların hiçbirinden etkilenmez. AKIA ile başlayan 20 karakterlik bir dize, etrafında ne yazdığından bağımsız olarak AWS erişim anahtarı biçimindedir. Bu, modelin yapamadığı bir şeyi regex'in yapabildiği anlamına gelmez — sadece işin doğru aletini kullanmak anlamına gelir.
Ne yapıştırılıyor
Ölçümümüzde sayısal dağılım çıkarmaya yetecek hacim yok, o yüzden buradan sonrası gözlem ve muhakeme. Transkriptlerde tekrar eden içerik türleri şunlar:
- Hata ayıklama sırasında olduğu gibi kopyalanan log ve yığın izleri
.envbenzeri yapılandırma parçaları, bağlantı dizeleri- HTTP istek/yanıt gövdeleri,
Authorizationbaşlıkları dahil - CI çıktıları, dağıtım kayıtları
- Veritabanı sorgu sonuçları, örnek satırlar
Bu listenin ortak özelliği, hiçbirinin "belge" olmaması. Kurumsal veri sınıflandırma politikaları dosyalar üzerine kurgulanır: şu klasör gizli, şu etiket dahili. Yapıştırılan içerik dosya değildir; bir terminal çıktısının, bir tarayıcı konsolunun ya da bir hata ekranının parçasıdır. Sınıflandırma politikasının hiçbir zaman ulaşmadığı yerdir.
Dosya bazlı gizlilik etiketleri, pano üzerinden akan metni görmez. Çalışanın kopyaladığı şey bir dosya değil, bir dosyanın ekrandaki görüntüsüdür. Denetim, dosya envanterinde değil, istem içeriğinde yapılmalıdır.
Uygulanabilir kontrol seti
1. Tespit deterministik olsun
Kimlik bilgisi taraması regex, önek imza listesi ve entropi eşiği üzerine kurulmalı. Sağlayıcı listesi güncellenebilir bir yapılandırma olmalı; her yeni SaaS aracı yeni bir önek demek. Model bu hatta yardımcı olabilir, ama karar mercii olamaz. Ayrıntılı gerekçeyi Sır tespitini modele bırakmayın yazısında topladık.
2. Ölçüm istem katmanında yapılsın
Kaç oturum açıldığı değil, o oturumlarda ne gönderildiği ölçülmeli. Kullanım telemetrisi ile içerik taraması farklı şeylerdir; birincisi maliyet raporu, ikincisi güvenlik kontrolüdür.
3. Yasak yerine akış tasarlansın
Samsung örneğinin gösterdiği gibi, aracı yasaklamak ihtiyacı ortadan kaldırmaz. Yasaklanan araç kişisel hesaba, kişisel cihaza ve görünmez bir kanala taşınır. Bu kaymanın nasıl oluştuğunu Gölge AI nedir, farkı ne yazısında anlattık.
4. Bulgu, olaya bağlansın
Tarama bir anahtar bulduğunda süreç orada bitmez. O anahtarın hangi sistemde geçerli olduğu, ne zaman ve nasıl döndürüleceği önceden yazılmış olmalıdır. İlk bir saatin adım adım planı için API anahtarı sızdığında ilk 60 dakika yazısına bakın.
"Çalışanlarımız dikkatli olsun" bir hedef değil. Ölçülebilir hedef şudur: modele giden her istem, gönderilmeden önce deterministik bir kimlik bilgisi taramasından geçiyor ve tarama sonucu kaydediliyor. Bu ikisi varsa geri kalanı iyileştirme, yoksa geri kalanı temenni.
Kendi verimizde çıkan sonuç net: sızıntı, kötü niyetten değil sürtünmesizlikten doğuyor. Kopyalamak bir saniye sürüyor, sonucunu temizlemek günler.