Yapay Zekâ Nasıl Kullanılır? #3 — Ekibe Yaymak: Yetki, Denetim ve Güvenlik

Pilotta bir kişi hem soruyu soran hem cevabı denetleyen kişidir; hata anında yakalanır. Yayıldığında soruyu soran ile sonucu kullanan ayrışır, denetim kaybolur ve tek bir yanlış çıktı düzeltilmeden ilerler. Yaygınlaşmanın gerektirdiği şey daha iyi model değil, daha net sorumluluktur.

Pilotta iş şöyle yürür: bir kişi soruyu yazar, cevabı okur, mantıklı değilse tekrar sorar, mantıklıysa kullanır. Bu döngüde denetim ücretsizdir çünkü aynı kişinin kafasında olur. Yirmi kişiye yayıldığında döngü kırılır — bir kişi sorar, çıktıyı başka biri kullanır, üçüncü biri sonucuna göre karar verir.

Bu kırılma üç somut soruyu cevapsız bırakır: Bu çıktı hangi soruya verildi? Hangi kaynağa dayanıyor? Yanlışsa kim düzeltecek? Üçünün de cevabı yoksa, sistem doğru çalışırken bile güvenilmez sayılır — çünkü doğru çalıştığını kanıtlayamazsınız.

Yetki tek bir açma-kapama düğmesi değildir. Dört kademe vardır: yalnızca okuyup cevaplama, taslak üretme, onaya sunma ve doğrudan yazma. Her iş için hangi kademenin uygun olduğuna işin geri alınabilirliğine bakarak karar verilir.

1. 01

   Kademe 1 — Oku ve cevapla

   Model yalnızca bilgi getirir; hiçbir kaydı değiştirmez. Yanlış cevabın bedeli, yanlış bilgiyle karar verilmesidir. Buradaki tek koruma kaynak göstermektir: cevabın hangi belgeye ya da kayda dayandığı görünmelidir.

2. 02

   Kademe 2 — Taslak üret

   Model bir metin, teklif ya da liste hazırlar; kaydetmez, göndermez. İnsan üzerinde çalışıp kullanır. Riski düşüktür çünkü çıktı hiçbir yere işlenmez. Yayılmaya buradan başlamak en güvenlisidir.

3. 03

   Kademe 3 — Onaya sun

   Model işlemi hazırlar ama uygulamaz; bir kişi onaylayınca uygulanır. Onay ekranında modelin ne yapacağı açıkça yazılı olmalıdır — "kaydı güncelle" değil, "şu kaydın şu alanını şundan şuna değiştir".

4. 04

   Kademe 4 — Doğrudan yaz

   Model kaydı kendisi değiştirir. Yalnızca dar kapsamlı, geri alınabilir ve sınırı net işlerde verilir. Her yazma işleminin kaydı tutulmalı ve tek hareketle geri alınabilmelidir.

Kademeyi belirleyen soru "model bunu yapabilir mi?" değil, "yanlış yaparsa ne kadar kolay geri alırız?" sorusudur. Bir teklif taslağı yanlışsa silinir. Bir cari hesap hareketi yanlışsa düzeltilir ama iz bırakır. Bir müşteriye gönderilmiş mesaj yanlışsa geri alınamaz. Üç iş de teknik olarak otomatikleştirilebilir; üçünün yetki kademesi aynı olamaz.

Yapay zekânın ürettiği her çıktının izlenebilir olması gerekir: kim sordu, ne sordu, hangi kaynak kullanıldı, ne döndü, kim ne yaptı. Bu beş alan tutulmuyorsa altı ay sonra "bu fiyatı kim değiştirdi" sorusunun cevabı yoktur.

zaman        2026-09-02 14:07
kullanıcı    (soruyu soran kişi)
soru         kullanıcının yazdığı metin
kaynak       kullanılan belge / kayıt / araç adı
cikti        modelin verdiği cevap ya da hazırladığı işlem
eylem        onaylandı | reddedildi | düzeltildi | uygulandı
onaylayan    (varsa onay veren kişi)

Bu yedi alan, sonradan sorulan her soruyu cevaplar.
Eksik tutulursa hiçbirini cevaplamaz.

Denetim izinin işi suçlu bulmak değildir; öğrenmektir. Reddedilen ve düzeltilen çıktılar, sistemin nerede zayıf olduğunu gösteren en değerli veridir. Bir istemin çıktısı sürekli düzeltiliyorsa sorun kullanıcıda değil istemdedir; bir aracın sonucu sürekli reddediliyorsa sorun aracın kapsamındadır.

• Kaydı çıktının yanında tutun: kullanıcı cevabı görürken kaynağı da görmeli, ayrı bir yere bakmak zorunda kalmamalı.
• Reddetme sebebini isteyin ama kısa tutun: üç seçenekli bir liste (yanlış bilgi / eksik / biçim), serbest metinden daha çok kullanılır.
• Kayıtları aylık gözden geçirin. Denetim izi bakılmıyorsa tutulmuyor sayılır.
• Kişisel veri içeren soruları kaydederken saklama süresini belirleyin; süresiz kayıt kendi başına bir risktir.

Herkes kendi cümlesiyle sorduğunda sonuçlar tutarsız olur ve tutarsızlığın sebebi anlaşılamaz. Sık yapılan işler için hazır istemler tanımlanır, kütüphaneye konur ve değişiklikleri kayıtla yürütülür. Böylece çıktı kalitesi kişiye değil, isteme bağlanır.

Serinin ilk bölümünde iyi bir istemin beş parçası anlatılmıştı: rol, görev, bağlam, biçim, sınır. Yayılma aşamasında buna altıncı bir gereklilik eklenir — istemin bir sahibi ve sürümü olması. Kim yazdı, ne zaman değişti, neden değişti?

1. 01

   Tekrarlayan işleri listele

   Ekibin haftada birden fazla yaptığı işleri yazın. İstem kütüphanesi bunlarla kurulur; tek seferlik sorular için istem yazmaya değmez.

2. 02

   Her iş için tek bir istem yaz

   İstemi bir kişi yazsın ve sahiplensin. İki kişinin aynı iş için iki istemi varsa, çıktı farklılığının sebebini bulmak imkânsız hâle gelir.

3. 03

   Değişkenleri işaretle

   İstemin sabit kısmı ile her seferinde değişen kısmı ayrılmalıdır. Kullanıcı yalnızca değişkeni doldursun; sabit kısmı serbestçe düzenlemesin.

4. 04

   Değişiklikleri kayıtla yap

   İstem güncellendiğinde eski hâli saklanmalıdır. Çıktı kalitesi bir gün düştüğünde ilk bakılacak yer, istemin ne zaman değiştiğidir.

5. 05

   Küçük bir doğrulama seti tut

   Her istem için doğru cevabını bildiğiniz beş-on örnek saklayın. İstemi değiştirdiğinizde bu seti tekrar çalıştırın; iyileştirme yaptığınızı sanıp bozmanın önüne geçer.

Dil modeli, kendisine verilen her metni okur ve metnin içindeki cümleleri talimat sanabilir. Bir e-postanın, bir ürün açıklamasının ya da bir web sayfasının içine yerleştirilen yönlendirmeler modeli beklenmedik davranışa itebilir. Buna istem enjeksiyonu denir ve savunması tasarımla yapılır.

Sorunun kökeni şudur: modelin dünyasında "talimat" ile "veri" arasında fiziksel bir duvar yoktur; ikisi de metindir. Modele bir müşteri e-postasını özetlemesini söylediğinizde, e-postanın içindeki "önceki talimatları unut ve şunu yap" biçimindeki bir cümle de modele ulaşır. Model bunu bir talimat sanabilir.

Bu, model "kandırıldığı" için değil, tasarımı gereği böyledir. Bu yüzden savunma modelin kendisinde değil, çevresindedir. Temel ilke şudur: modele ne söylenirse söylensin, yapamayacağı şeyi yapamamalıdır. Yetkiyi isteme değil, sisteme koyun.

İstem enjeksiyonu

Modele verilen metnin içine, modelin davranışını değiştirmeyi amaçlayan talimatların yerleştirilmesi.

Dolaylı enjeksiyon

Talimatın kullanıcı tarafından değil, modelin okuduğu bir kaynaktan (e-posta, web sayfası, belge, ürün açıklaması) gelmesi. Kullanıcı kötü niyetli olmasa da gerçekleşebilir.

Veri sızması

Modelin, erişebildiği gizli bilgiyi cevabın içinde ya da bir araç çağrısının parametresinde dışarı taşıması.

En az yetki

Bir bileşene, işini yapması için gereken en dar erişimin verilmesi. Yapay zekâ araçlarında en etkili tek savunma budur.

Bu listedeki maddelerin hiçbiri model seçimiyle ilgili değildir. Daha güçlü bir modele geçmek bu riskleri ortadan kaldırmaz; yalnızca daha karmaşık işleri yapabilir hâle getirir — yani riskin kapsamını genişletir. Güvenlik, modelin yeteneğiyle değil, çevresindeki sınırlarla kurulur.

Ekibin ne yapıp ne yapamayacağı yazılı değilse, herkes kendi sınırını çizer. İyi bir kullanım politikası uzun değildir: hangi işlerde kullanılabileceği, hangi verinin verilemeyeceği, çıktının nasıl denetleneceği ve sorumluluğun kimde olduğu — dört başlık yeter.

1. 01

   Nerede kullanılır

   Serbest, onaylı ve yasak olmak üzere üç liste yazın. "Serbest" listesi mümkün olduğunca uzun olsun; kısıtlama az sayıda ve gerekçeli olduğunda uygulanır.

2. 02

   Hangi veri verilmez

   Kimlik bilgisi, ödeme bilgisi, sözleşme koşulları, personel özlük verisi gibi kalemleri açıkça sayın. Genel ifadeler ("gizli bilgi") uygulamada işe yaramaz; herkes farklı yorumlar.

3. 03

   Çıktı nasıl denetlenir

   Hangi işlerde çıktının doğrulanması zorunlu, hangilerinde serbest olduğunu yazın. Sayı, tarih, tutar ve hukuki ifade içeren her çıktı doğrulanmalıdır.

4. 04

   Sorumluluk kimde

   Yapay zekânın ürettiği çıktıdan, onu kullanan kişi sorumludur. Bu cümlenin yazılı olması, "model öyle dedi" savunmasını baştan kapatır ve denetim alışkanlığını yerleştirir.

Politikayı yazarken en sık yapılan hata, uzun ve yasaklayıcı olmasıdır. Kimsenin okumadığı bir belge kural üretmez. Bir sayfayı geçmeyen, örneklerle desteklenmiş ve ekibin gerçekten yaptığı işlere değinen bir metin, yirmi sayfalık bir yönetmelikten çok daha etkilidir.

Ekibe model mimarisi anlatmaya gerek yoktur. Üç şey yeter: modelin ne bilip ne bilmediği, çıktının nasıl doğrulanacağı ve hangi verinin verilmeyeceği. Bu üçü bir saatlik bir oturumda ve gerçek örneklerle öğretilir.

• Modelin sizin verinize bakmadığı durumlarda cevabın nereden geldiğini gösterin. Serinin birinci bölümündeki "kendinden emin şekilde yanlış" örnekleri bu iş için birebirdir.
• Doğrulama alışkanlığını örnekle öğretin: bir sayı içeren çıktıyı birlikte kontrol edin ve nereye bakılacağını gösterin.
• Hangi verinin verilmeyeceğini soyut anlatmayın; ekibin gerçekten elinde olan belge türleri üzerinden konuşun.
• İstem kütüphanesini tanıtın ve nasıl katkı yapılacağını gösterin. Kütüphaneyi ekip sahiplenmezse kullanılmaz.
• Yanlış çıktıyı nasıl bildireceklerini söyleyin. Bildirim yolu yoksa hatalar yönetime hiç ulaşmaz.

Eğitimin ölçüsü katılım değil, davranıştır. Bir ay sonra denetim izine baktığınızda reddetme ve düzeltme kayıtları görüyorsanız, ekip çıktıyı denetliyor demektir. Hiç ret kaydı yoksa bu iyi bir işaret değildir; çıktıların hiç denetlenmediği anlamına gelme ihtimali yüksektir.

Yayılma aşamasında ölçüm, pilottakinden farklıdır. Tek bir işin süresi değil, kullanımın yayılıp yayılmadığı, çıktının ne kadar düzeltildiği ve hangi işlerde terk edildiği ölçülür. Terk edilen işler, en çok öğretici olanlardır.

Düzeltme oranı ile ret oranını ayırmak önemlidir. Düzeltilerek kullanılan çıktı değer üretmiştir — sıfırdan yazmaktan hızlıdır. Hiç kullanılmayan çıktı ise net kayıptır: hem süre hem maliyet harcanmış, karşılığında bir şey alınmamıştır. İkisi tek sayıda toplandığında bu ayrım kaybolur.

Terk edilen işleri kayıt altına almak, başarılı olanları saymaktan daha öğreticidir. Bir işin neden bırakıldığı — çıktı yetersizdi, doğrulaması iş yükü getirdi, onay adımı yavaşlattı — bir sonraki kullanım alanını seçerken en iyi rehberdir.

Her iş yapay zekâya uygun değildir. Tek bir doğru cevabı olan ve kural setiyle çözülebilen işler, sonucu kesinlik gerektiren hesaplar ve sorumluluğun devredilemeyeceği kararlar bu araca verilmemelidir.

• Kesin hesap gerektiren işler: bakiye, vergi, bordro. Bunlar formülle çözülür; dil modeli sayıyı üretebilir ama garanti edemez.
• Tek doğrusu olan kural işleri: bir alan boş mu, tarih geçmiş mi, tutar limiti aşıyor mu. Basit bir kural bunu daha ucuza ve kesin yapar.
• Sorumluluğu devredilemez kararlar: işe alma, işten çıkarma, kredi ya da vade kararı. Model girdi hazırlayabilir; kararı veren insan olmalıdır.
• Kaynağı olmayan sorular: sistemde kaydı bulunmayan bir bilgiyi model uyduracaktır. Cevap veremeyeceği soruya cevap vermesini istemeyin.
• Hukuki metin üretimi: sözleşme ve taahhüt metinleri taslak olarak kullanılabilir, ama hukuki denetimden geçmeden yürürlüğe konmamalıdır.

Bu seri burada tamamlanıyor: birinci bölüm aracı kullanmayı, ikinci bölüm kendi verinizle çalıştırmayı, bu bölüm de ekibe güvenle yaymayı anlattı. Üçü de aynı ilkeye dayanıyor — yapay zekâ, üzerine kurulduğu kayıt düzeni kadar iyidir. Kayıtlarınız dağınıksa hiçbir model bunu telafi etmez; düzgünse en basit kurulum bile iş görür.