Şirketlerin AI hesap düzeni neredeyse her zaman aynı hikâyeyle başlar. Bir kişi denemek için hesap açar, işe yarar. İkinci kişi de kullanmak ister, parolayı paylaşırlar. Üçüncü kişi katılır. Altı ay sonra sekiz kişi tek bir hesabı ve tek bir API anahtarını kullanıyordur, fatura tek kalem gelir ve kimse bunu bir sorun olarak görmez.
Bu düzenin görünmez olmasının nedeni, sorun çıkarmıyor gibi durmasıdır. Sistem çalışır, işler yapılır, fatura ödenir. Sorun ancak bir şey ters gittiğinde ortaya çıkar ve o noktada geriye dönüp bakacak hiçbir kaydınız olmaz.
Neden bu kadar yaygın
Paylaşımlı hesap tembellikten değil, üç makul gerekçeden doğar.
Birincisi maliyet algısı: tek koltuk sekiz koltuktan ucuz görünür. İkincisi hız: yeni kişiye hesap açmak, onay almak, bütçe kalemi eklemek zaman alır; parola paylaşmak on saniye sürer. Üçüncüsü de sadece "geçici" olmasıdır. Hiçbir paylaşımlı hesap kalıcı olsun diye kurulmaz, hepsi geçici başlar.
Ama sonuç aynıdır: kimliğin silindiği bir kullanım katmanı.
Neden görünmez
Teknik olarak burada olan şey basittir. Kullanım raporunu api_key_id veya account_id alanına göre grupladığınızda sekiz kişilik ekip için tek bir satır dönerse, elinizdeki veri toplamdan ibarettir.
Kırılım isteseniz de veremezsiniz, çünkü kırılımı üretecek kimlik kaynakta yoktur. Rapor doğru çalışır, sorun raporda değil, hesap düzenindedir. Kullanım ve maliyet raporlarının nasıl çekildiğini Admin API rehberinde anlattık; ama en iyi rapor bile olmayan kimliği uyduramaz.
Bunun pratik sonucu şudur: paylaşımlı hesap düzeninde denetim yapamazsınız. Yapabileceğiniz tek şey toplam rakama bakıp tahmin yürütmektir.
Paylaşımlı hesapta bir çalışan ayrıldığında erişimini kapatmanın tek yolu parolayı değiştirip yeni parolayı kalan herkese dağıtmaktır. Pratikte bu neredeyse hiç yapılmaz. Sonuç: şirketten ayrılmış kişiler, şirketin ödediği hesaba ve o hesabın sohbet geçmişine aylarca erişmeye devam eder.
Dört somut risk
Harcama atfedilemez
Fatura yükseldiğinde nedenini bulamazsınız. Hangi ekip, hangi iş, hangi alışkanlık pahalı, göremezsiniz. Atfedilemeyen harcama optimize edilemez; bu yüzden paylaşımlı hesap düzeninde maliyet çalışması yapmak neredeyse imkânsızdır. Koltuk maliyetini düşürmenin yollarını anlattığımız yazının ilk maddesi ölçüm, çünkü kimlik olmadan geri kalan altı madde tahmine dayanır.
Sır sızıntısının sahibi yok
Prompt içine bir veritabanı bağlantı dizesi yapıştırıldığını tespit ettiniz. Paylaşımlı hesapta bunu kimin yaptığını bulamazsınız. Bulamadığınız için de tekrarını önleyemezsiniz; tek yapabileceğiniz herkese genel bir uyarı göndermektir ve genel uyarılar davranış değiştirmez.
Denetim izi yok
Bir müşteri, bir denetçi veya bir kurum "bu veriyi kim işledi" diye sorduğunda cevabınız "sekiz kişiden biri" olur. Bu, hiçbir denetim çerçevesinde kabul edilebilir bir cevap değildir. Kişisel veri işleniyorsa konu doğrudan yasal zemine taşınır; KVKK ve çalışan AI denetimi yazısında bu çerçeveyi ele aldık.
İş dışı kullanım tespit edilemez
Şirket parasıyla alınan koltuğun ne kadarının gerçekten işe gittiğini ölçmek isterseniz, ölçüm biriminiz kişi olmalıdır. Paylaşımlı hesapta iş dışı kullanım havuzun içinde erir. Ortalamalar herkesi masum gösterir.
Maliyetin "bilinmeyen" kovası
Paylaşımlı hesap, ölçüm kaybının yalnızca bir katmanı. İkinci katman sohbetin kendi içinde oluşur.
Temmuz 2026'da 739 gerçek görev üzerinde yaptığımız ölçümde, promptların yaklaşık yüzde 42'si bağlamsız devam ifadeleriydi: "devam", "evet" gibi tek kelimelik mesajlar. Bunlar token maliyetinin yaklaşık yüzde 35'ini oluşturuyordu.
Bu iki katman üst üste bindiğinde ortaya çıkan tablo şudur: kişi bilinmiyor, görevin üçte biri de kategorisiz. Yani faturanın anlamlı bir bölümü hiçbir sahibi ve hiçbir amacı olmayan bir kovaya düşer. Devam mesajlarının nasıl ait oldukları göreve bağlanacağını devam demenin faturası yazısında anlattık; ama o düzeltme de ancak kişi kimliği varsa işe yarar.
Paylaşımlı anahtarın meşru olduğu tek durum
Bu yazı, tüm paylaşımlı anahtarların kötü olduğunu iddia etmiyor. Meşru bir kullanım biçimi var: servis hesapları.
Bir uygulamanın arka planında çalışan, gece raporu üreten veya müşteri taleplerini sınıflandıran bir entegrasyonun kendi anahtarı olması normaldir. Bu anahtarı bir insan kullanmaz, bir sistem kullanır. Kullanım raporunda bu tür kullanımı service_account_id üzerinden ayrıştırabilir ve insan kullanımından temizce ayırabilirsiniz.
Kural nettir: insan trafiği kişiye bağlı, sistem trafiği servise bağlı olmalı. Sorun, insan trafiğinin servis hesabı gibi davrandığı durumdur.
Otuz günlük geçiş planı
Paylaşımlı hesaptan çıkmak sanıldığı kadar zahmetli değil. Aşağıdaki plan çoğu küçük ve orta ölçekli ekipte bir ay içinde tamamlanır.
- Gün 1-3. Hesabı fiilen kimlerin kullandığını listeleyin. Bu liste neredeyse her zaman beklenenden uzundur; unutulmuş kişiler çıkar.
- Gün 4-7. Kişi başına ayrı koltuk veya ayrı API anahtarı oluşturun. Anahtar ile kişi eşleşmesini tek bir tabloda tutun; rapor size isim değil kimlik verecek.
- Gün 8-10. Otomasyonları ve entegrasyonları ayrı servis hesaplarına taşıyın. İnsan anahtarlarıyla makine anahtarlarını asla karıştırmayın.
- Gün 11-14. Yeni anahtarları dağıtın, kullanımın yeni kimliklere geçtiğini kullanım raporundan doğrulayın.
- Gün 15. Eski paylaşımlı anahtarı iptal edin. Bu adımı ertelemeyin; ertelenen iptal hiç yapılmaz.
- Gün 16-30. İlk kırılım raporunu üretin ve ekiple paylaşın. İlk rapor genellikle beklentileri altüst eder, bu normaldir.
API tarafında kişi başına ayrı anahtar oluşturmak ek ücret getirmez; ödediğiniz şey anahtar sayısı değil kullanımdır. Koltuk tarafında ise ölü koltukları temizleyerek elde ettiğiniz tasarruf, genellikle yeni açılan koltukların maliyetini karşılar.
Sonuç
Paylaşımlı tek hesap bir tasarruf değil, ertelenmiş bir maliyettir. Fatura tarafında birkaç koltuk parası kazandırırken, görünürlük tarafında her şeyi kaybettirir: kim, ne, ne zaman, neden.
Bir şirketin AI yönetiminde atacağı ilk adım, gelişmiş bir denetim aracı satın almak değildir. Kimlik katmanını düzeltmektir. Onsuz kurulan her denetim, üzerinde tek satır veri olan bir tabloya bakmaktan ibaret kalır.