Bir ürünün ne yaptığını anlatmanın en dürüst yolu onu kendi verinizde çalıştırmaktır. Temmuz 2026'da shadowprompting'in sınıflandırma boru hattını kendi Claude Code kayıtlarımızda çalıştırdık: 739 görev, 5,68 milyar token.
Beklediğimiz sonuç "şu kadarı iş dışıydı" cümlesiydi. Çıkan sonuç bambaşka bir şey oldu.
Ölçüm nasıl yapıldı
Girdi, diskteki Claude Code oturum kayıtlarıydı. Bu, ürünün desteklediği en zengin veri kaynağı: her kullanıcı istemi, onu yanıtlamak için harcanan token ve zaman damgası birlikte duruyor.
Boru hattı şu adımlardan geçti:
- Kayıtlar görevlere ayrıldı. Bir görev, bir kullanıcı istemi artı onu yanıtlamak için harcanan tüm tokenlar demek.
- Her görev, şirketin faaliyet alanı tanımıyla birlikte sınıflandırıcıya verildi.
- Bağlamsız devam istemleri bir önceki görevin kategorisini miras aldı.
- Ham metinler ayrıca deterministik desen taramasından geçirildi.
739 görevin tamamının sınıflandırılması 0,41 dolar tuttu. Bu rakam ürünün ekonomisini belirliyor: koltuk başına aylık maliyet, satış fiyatının yanında ihmal edilebilir kalıyor.
Birinci bulgu: oturum yanlış birimdir
İlk denemede oturum bazında sınıflandırdık. 8 oturum bulduk. Sekiz veri noktasıyla rapor çıkmaz.
Ama asıl sorun sayı değildi. Uzun bir yapay zeka oturumu tek bir konu değildir. Aynı oturumda önce fatura modülü hatası ayıklanıyor, sonra bir tatil planı soruluyor, sonra tekrar koda dönülüyor. Oturuma tek etiket vermek bu ayrımı imkânsız kılıyor.
Görev bazına indiğimizde 739 veri noktası çıktı ve karışık oturumlar doğru parçalandı.
Kurumsal AI kullanımını ölçen herhangi bir araç size oturum veya konuşma sayısı raporluyorsa, karışık oturumları kaçırıyor demektir. Doğru birim istemdir.
İkinci bulgu: "devam" demek faturanın üçte biri
Görevlerin %42'si bağlamsız devam istemiydi: "devam", "evet", "tamam", "peki". Bunlar tek başlarına hiçbir konu sinyali taşımıyor. Ama token yakıyorlar — hem de çok.
Bu görevler ayrı sınıflandırıldığında maliyetin %35'i "belirsiz" kovasına düştü. Yani faturanın üçte biri "ne olduğunu bilmiyoruz" diye raporlanacaktı.
Çözüm, bu istemlere aynı oturumdaki bir önceki sınıflandırılmış görevin kategorisini miras vermek oldu. Belirsiz oranı %42'den %1,4'e indi.
Bu konuyu ayrı bir yazıda ayrıntılandırdık: "devam" demenin faturası.
Üçüncü bulgu: şirket tanımı her şeyi belirliyor
İlk çalıştırmada şirketi dar tanımladık. 16 iş dışı işaret çıktı.
Her birinin gerçek metnine tek tek baktık. Yaklaşık 13'ü yanlış pozitifti. Sınıflandırıcı rakip ürün analizini "kişisel proje", pazaryeri entegrasyonunu "freelance iş", kendi geliştirme araçlarımızı yine "kişisel proje" sanmıştı.
Tanımı genişletip rakip analizini, satış kanallarını ve iç araçları açıkça şirket işi olarak yazdığımızda işaret sayısı 1'e düştü. Aynı veri, aynı model, aynı boru hattı.
| Dar tanım | Geniş tanım | |
|---|---|---|
| İş dışı işaret | 16 | 1 |
| Yanlış pozitif | ~13 | 0 |
| Kabaca isabet | %19 | — |
Bu, ürünün en kırılgan noktası ve dürüstçe söylenmesi gereken şey: doğruluğun tek en büyük belirleyicisi modelin kalitesi değil, şirket tanımının kalitesidir. Ayrıntısı şirket tanımı ve yanlış pozitifler yazısında.
Dördüncü ve en önemli bulgu: sızmış anahtarlar
Asıl bulgu iş dışı kullanımda değildi.
Deterministik desen taraması, istemlere yapıştırılmış 7 kimlik bilgisi buldu:
- İki Anthropic API anahtarı — biri hâlâ üretimde aktif
- Bir Google Cloud servis hesabı özel anahtarı (iki kez yapıştırılmış)
- Bir PEM formatında özel anahtar
- Bir üçüncü taraf servis anahtarı
Aynı görevleri sınıflandıran dil modeli bunların yalnızca 4'ünü "hassas" kategorisine koydu. Aktif üretim anahtarını içeren görevi sıradan "şirket işi" olarak etiketledi — çünkü çevresindeki metin gerçekten şirket işiydi.
Bir dil modeli bağlamı yorumlar. Sır tespiti ise yorum işi değil, eşleşme işidir. Boru hattımızda desen taraması sınıflandırıcıdan tamamen bağımsız çalışır ve onun kararını beklemez. Ayrıntı: sır tespitini modele bırakmayın.
Sonuçlar tablosu
Düzeltilmiş boru hattıyla son dağılım:
| Kategori | Görev | Bedel payı |
|---|---|---|
| Şirket işi | 653 | %92,0 |
| İşe yönelik öğrenme | 67 | %7,2 |
| Hassas kişisel | 8 | %0,5 |
| Kişisel proje | 1 | %0,1 |
| Belirsiz | 10 | %0,2 |
İş dışı kullanım %0,1 çıktı. Bu bizim için beklenen bir sonuçtu: ölçülen hesap şirket sahibinin kendi hesabıydı ve tüm işler kendi ürünleri içindi.
Bu, ürünün "hiçbir şey bulamadı" anlamına gelmiyor. Tam tersine, yanlış yere suçlama yapmadığını gösteriyor — ki bir denetim aracında bu, bulgu üretmekten daha önemli bir özelliktir.
Metodolojiye dair dürüst notlar
Bu ölçümün sınırlarını da yazmak gerekiyor:
- Tek hesap. 739 görev tek bir kullanıcıya ait. Çok kullanıcılı bir organizasyonda dağılım farklı çıkar.
- Dolar rakamı nosyoneldir. Ölçülen kullanım abonelik kapsamındaydı, token başına faturalanmıyordu. API fiyatlarıyla çevirdik; abonelik koltuklarında anlamlı metrik kota payıdır.
- Yanlış pozitif sayımı elle yapıldı. 16 işaretin her birine biz baktık. Bu, bağımsız bir doğrulama değil, üreticinin kendi denetimi.
- Yanlış negatifi ölçemedik. Kaçırılan iş dışı görev olup olmadığını bilmiyoruz; bunun için etiketli bir referans küme gerekir.
Ne öğrendik
Ölçmeden önce iş dışı kullanımın ana hikâye olacağını sanıyorduk. Ölçtükten sonra gördük ki bir yöneticinin gerçekten harekete geçeceği bulgu şu cümle:
Çalışanınız üretim API anahtarınızı yapay zekaya yapıştırdı ve o metin on yıl saklanacak bir kayıt dosyasında duruyor.
İş dışı kullanım bir bütçe kalemidir. Sızmış üretim anahtarı bir olaydır. İkisi aynı boru hattından çıkıyor, ama ikincisi bugün rotasyon yapmanızı gerektiriyor.
Kendi verinizde ölçmek isterseniz claude.ai export dosyasıyla denetim adımları yazısı süreci baştan sona anlatıyor.