Gözetim yorgunluğunu tasarımla azalt

Bir ekip, faturaları muhasebe sistemine giren bir ajanı ilk kez gerçek veriyle çalıştırıyor. Ajan işi yapıyor, bir çalışan da ekranın başında oturup akan adımları izliyor, bir terslik görürse durdur düğmesine basacak. İlk on dakika her satırı okuyor. Yirminci dakikada ajan elli faturayı hatasız girmiş oluyor ve çalışan bir gözüyle e-postasına bakmaya başlıyor. Kırkıncı dakikada ajan bir tedarikçinin kayıtlı banka hesabını faturadaki yeni numarayla değiştiriyor. Bu satır da öteki satırlar gibi akıp gidiyor.

Çalışan ihmalkâr davranmadı. Ürün ona insanın iyi yapamadığı bir iş verdi. Neredeyse hiçbir şeyin olmadığı bir akışa uzun süre bakacak ve aradaki tek sapmayı yakalayacaktı. Ajan ne kadar iyi çalışırsa bakmak için o kadar az sebep kalıyor. Hata seyrekleştikçe gözden kaçma ihtimali artıyor.

Güvenlik planında “ajanı bir insan izliyor” diye bir satır duruyor. O satırın arkasında çoğu zaman dikkati çoktan başka yere kaymış bir insan oturuyor.

İzlemek kolay bir iş gibi görünüyor, ekipler de onu bu yüzden insana veriyor. Warm, Parasuraman ve Matthews'un derlemesi bu varsayımı tersine çeviriyor. Nöbet görevleri uzun süre az zihinsel çaba isteyen işler sayıldı¹, oysa davranış, beyin ve öz bildirim ölçümleri aynı sonuca varıyor. Dikkatli kalmak ağır zihinsel iş ve insanı strese sokuyor.

İkinci neden ürün baskısı. İnsan gözetimi ajanı canlıya almanın en ucuz katmanı gibi duruyor. Bir “izlemeye devam et” uyarısı, bir durdur düğmesi yetiyor. Gözetimin gerçekten yapılıp yapılmadığını ise kimse ölçmüyor. Uber ATG'nin test araçlarında içeriye bakan kameralar vardı. NTSB'nin raporuna göre süpervizörler bu kayıtları nadiren inceledi².

Üçüncü neden ajanın kendisinde. Ajan her adımı aynı tonla raporluyor. Rutin bir kayıt ile bir banka hesabını değiştiren kayıt ekranda aynı görünüyor ve ajan iş akarken kendi sapmasını işaretlemiyor. Üstelik ajan iyileştikçe sorun büyüyor. NTSB'nin özetiyle otomasyon ne kadar iyiyse operatörün gevşeyip hatayı kaçırma ihtimali o kadar yüksek².

İnsanı uzun süre izlemekle görevlendirme. Rutin denetimi sistem yapar, insanı kısa ve belirli anlarda bir karara çağırır. Aktif gözetim gereken bir kesit varsa onu dar tut ve orada insanın gerçekten bulunduğundan emin ol.

1. Sapmayı sistem yakalasın. Ajanın rutin adımlarını kod denetler: tutar kayıtla eşleşiyor mu, alıcı bilinen biri mi, değişen alan beklenen alan mı. Bainbridge 1983'te seyrek bir sapmayı izlemenin insanın yapabileceği bir iş olmadığını, bu işin bir alarm sistemine verilmesi gerektiğini³ yazdı.
2. İnsanı karara çağır. Sapma bulununca ajan o adımı ayırır ve kullanıcıya haber verir. Çağrı kararı vermek için gereken bilgiyi taşır, kullanıcı akışı geriye sarmak zorunda kalmaz.
3. Canlı gözetimi riskli kesite daralt. Bazı adımlarda insanın gerçekten başında olması gerekir, ödeme ya da dışarıya gönderim gibi. Gözetimi yalnız orada iste. Kullanıcı o kesitte ekrandan ayrılırsa ajan durur ve onu bekler.
4. Varlık sinyalini dikkat sayma. Açık kalan sekme, “hâlâ orada mısın” düğmesi ya da direksiyondaki el dikkatin kanıtı olmaz. Bainbridge'in örneğinde operatörün dikkatini korumak için ona günlük tutturuluyor, ama insanlar sayıları ne olduklarını fark etmeden yazabiliyor³. Kontrol gerekiyorsa içerikle ilgili olsun, kullanıcıya akıştan bir karar sor.
5. Süreyi böl. Uzun işi parçalara ayır. Her parçanın sonunda kısa bir özet ve bir karar noktası koy. Sürekli izleme şartsa nöbeti iki kişi arasında böl.
6. Gözetimin kendisini ölç. Kullanıcının ayrılan adımlara ne kadar sürede, nasıl cevap verdiğini kaydet ve bu kaydı biri düzenli olarak okusun.

Desen gözetimi kaldırmaz. İnsanın dikkatini uzun bekleyişten alır ve tek bir karara harcar.

Aynı fatura işi, iki gözetim düzeniyle. Solda kullanıcıdan kırk dakika boyunca akan adımları izlemesi isteniyor ve banka hesabını değiştiren adım rutin satırların arasında geçiyor. Sağda ajan rutin adımları kendisi denetliyor, kayıttan sapan tek adımı ayırıyor ve kullanıcıyı o karara çağırıyor.

Tesla, Autopilot'un sürücü denetimlerini bir geri çağırmayla değiştirdi. NHTSA'ya verdiği raporda Autosteer açıkken denetimlerin kötüye kullanımı önlemeye yetmeyebileceğini⁴ kabul etti. Yazılım güncellemesi görsel uyarıları belirginleştirdi, otoyol dışında ve trafik ışıklarına yaklaşırken ek kontroller getirdi. Sürücü sorumluluğunu tekrar tekrar göstermezse Autosteer'i kullanması askıya alınıyor. Tesla aynı raporda NHTSA'nın analizine katılmadığını da yazdı.

OpenAI'ın Operator için yayımladığı sistem kartı gözetimi işin tamamına yaymıyor. Hatanın bedelinin yüksek olduğu sitelerde, örneğin e-posta servislerinde, kullanıcının Operator'un adımlarını izlemesi şart. Kullanıcı hareketsiz kalırsa ya da sayfadan ayrılırsa Operator duruyor⁵, kullanıcı dönünce devam ediyor.

Claude Code ters yönden geliyor. Uzaktan kontrol açıkken Claude, uzun bir iş bittiğinde ya da kullanıcıdan bir karar gerektiğinde telefona bildirim gönderebiliyor⁶. Kullanıcı ekranın başında beklemiyor, ajan onu gerektiğinde çağırıyor.

Uber ATG, Mart 2018. Tempe'de Uber'in geliştirme aşamasındaki otomatik sürüş sistemiyle giden bir test aracı, yaya geçidi olmayan bir yerden karşıya geçen bir yayaya çarptı. Yaya hayatını kaybetti. Araç yaklaşık 19 dakikadır otomatik moddaydı². NTSB'ye göre operatör, aracın hareket ettiği sürenin %34'ünde bakışını orta konsolun altına, telefonuna çevirmişti². Kurul bu uzun dikkat dağınıklığını otomasyona aşırı güvenin tipik bir etkisi² saydı. Şirketin bu riski tanımadığını, operatörün işten kopmasına karşı etkili önlem almadığını, ikinci operatörü kaldırarak tek kişinin yükünü artırdığını yazdı. Kazaya katkıda bulunan etkenler arasında yayanın yaya geçidi dışından geçmesini ve eyaletin test denetimindeki eksikliği de saydı. Uber ATG kazadan sonra iki operatöre döndü ve operatörün bakışı yoldan birkaç saniye ayrılınca hem ona hem süpervizöre haber veren bir sistem kurdu.

Tesla Autopilot, Nisan 2024. NHTSA, Autopilot incelemesini kapatırken 956 çarpışmayı⁷ analiz ettiğini yazdı. Kurumun bulgusuna göre Autopilot'un denetimleri sürücünün dikkatini yeterince sağlamıyordu ve zayıf sürücü katılım sistemi, Autopilot'un serbest bıraktığı kullanım alanına uymuyordu. Kurum, sürücünün öngörülebilir kötüye kullanımının rol oynadığı en az 13 ölümlü çarpışma⁷ saydı. Tesla'nın geri çağırması 2 milyonu aşkın aracı⁴ kapsadı ve NHTSA çözümün yeterliliğini ölçmek için ayrı bir inceleme açtı.

Araştırma aynı yönü gösteriyor. Bainbridge, en istekli insanın bile çok az şeyin olduğu bir bilgi kaynağına yaklaşık yarım saatten uzun süre etkili dikkat veremediğini³ yazdı. Parasuraman ve Manzey'in derlemesine göre otomasyona aşırı güven, elle yapılan işler insanın dikkati için otomasyonla yarıştığında ortaya çıkıyor. Hem acemide hem uzmanda görülüyor ve basit pratikle aşılamıyor⁸. Pratikle geçmeyen bir eğilimi “dikkatli ol” uyarısı da gidermez. İşin tasarımı değişmeli.

Bu bulgular yoldan, kokpitten ve kontrol odasından geliyor. Ajan ürünlerinde izleme süresiyle kaçırılan hata arasındaki ilişkiyi ölçen yayımlanmış bir çalışma bu sayfanın kaynakları arasında yok.

• 18 Mart 2018Uber'in otomatik sürüş test aracı Tempe'de karşıya geçen bir yayaya çarptı, yaya hayatını kaybetti
• 12 Aralık 2023Tesla, sürücü dikkat denetimleri yetersiz bulunan Autopilot için iki milyonu aşkın aracı geri çağırdı

• Aralıksız izleme süresi. Üründe kullanıcının bir ajanı ara vermeden izlemesinin beklendiği en uzun süre. Bainbridge'in yarım saatini hedef sayma, uyarı say.
• Tuzak adımı. Kontrollü bir denemede akışa bilerek bir sapma koy. Sapmayı sistem mi ayırdı, kullanıcı mı fark etti, kaçıncı dakikada? Desen yerindeyse sistem ayırır, kullanıcı karar verir.
• Çağrıya verilen cevap. Bildirimle karar arasındaki süre ve kararların ne kadarının değiştirme ya da ret olduğu. Hepsi tek tıkla onaysa çağrı da rutine dönmüş.
• Sistemin kaçırdığı sapma. Sonradan bulunan ama ajanın ayırmadığı hatalar. Her biri alarm kurallarında bir eksik demek.
• Gözetimsiz riskli adım. Gözetim isteyen kesitte kullanıcı yokken çalışmış adım sayısı. Sıfır olmalı.

Üç metin var. Denetim promptu ürününde bir insanın ajanı ya da otomasyonu izlemesinin beklendiği yerleri bulur, sapmaların kodla mı insan gözüyle mi yakalandığını ve gözetimin hangi sinyalle doğrulandığını raporlar. Hiçbir dosyayı değiştirmez. Uygulama promptu rutin adımları kodla denetleyen, sapan adımı ayırıp kullanıcıyı çağıran ve riskli kesitte kullanıcı yokken ajanı durduran düzeni kurar. Önce planı gösterir, onayınla uygular ve akışa bilerek bir sapma koyan bir test ekler. Kural kodlama ajanının kendi çalışması için. Senin ajanın da uzun bir işte seni ekran başında bekletmesin, karar gereken adımda çağırsın.

Bu depoda kullanıcı adına iş yapan bir AI ajanı ya da otomasyon var. Görevin, bir insanın bu ajanı ne kadar ve nasıl izlemesinin beklendiğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. İnsanın ajanı izlemesinin beklendiği yerleri bul: canlı adım akışı, "izlemeye devam et" uyarıları, durdur düğmesi, ekran kaydı, gözetim gerektiren mod ya da sayfa. Bunların hangi işlerde ve ne kadar süreyle açık kaldığını yaz.
2. Ajanın adımlarındaki sapmaları kim yakalıyor? Kodda kayıtla karşılaştırma, eşik, beklenen alan listesi ya da kural var mı, yoksa sapmayı yakalamak insanın gözüne mi bırakılmış? Rutin adımla olağandışı adım arayüzde ayrı görünüyor mu?
3. Sapma bulunduğunda ne oluyor? Ajan o adımı ayırıp bekliyor mu, kullanıcıya bildirim gidiyor mu, bildirim kararı vermek için gereken bilgiyi taşıyor mu? Yoksa ajan devam edip yalnız günlüğe mi yazıyor?
4. Gözetim gerektiren riskli adımlar (ödeme, dışarıya gönderim, kalıcı silme, hesap bilgisi değişikliği) için bak: kullanıcı ekranda değilken bu adımlar çalışabiliyor mu? Kullanıcının varlığı neyle anlaşılıyor (sekme odağı, fare hareketi, "hâlâ orada mısın" düğmesi)? Bu sinyal dikkat hakkında bir şey söylüyor mu?
5. Uzun işler parçalara bölünmüş mü? Ara özet ve karar noktası var mı?
6. Gözetimin kendisi kaydediliyor mu: kullanıcının ayrılan adımlara cevap süresi, verdiği kararlar, gözetimsiz çalışan riskli adımlar. Bu kayıtları okuyan biri var mı?

Rapor biçimi: her bulgu için dosya ve satır, insanın hangi işi ne kadar süre izlemesinin beklendiği, hangi sapmanın yalnız insan gözüyle yakalanabildiği, olası sonuç (örnek: uzun bir işin ortasındaki hesap değişikliği rutin satırlar arasında geçer) ve önerdiğin düzeltme. Bulguları geri dönüşü olmayan işlerden başlayarak sırala.

Bu depodaki AI ajanına "gözetim yorgunluğunu tasarımla azalt" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Ajanın rutin adımlarını kod denetlesin. Her adım türü için beklenen durumu yaz (tutar kayıtla eşleşir, alıcı bilinen biridir, yalnız beklenen alanlar değişir) ve her adımı buna karşı kontrol et.
2. Beklenenden sapan adımı ajan ayırsın ve beklemeye alsın. Öteki bağımsız adımlara devam edebilir.
3. Ayrılan adım için kullanıcıya bir bildirim gitsin. Bildirim neyin saptığını, karar için gereken bilgiyi (eski ve yeni değer, kaynak) ve en çok üç seçeneği taşısın. Kullanıcının akışı geriye sarması gerekmesin.
4. Riskli kesitler (ödeme, dışarıya gönderim, kalıcı silme, hesap bilgisi değişikliği) kodda bir listede dursun. Bu adımlar kullanıcı onlara açıkça karar vermeden çalışmasın. Kullanıcı ekrandan ayrılırsa ajan o kesitte dursun ve döndüğünde kaldığı yeri söylesin.
5. Uzun işi parçalara böl. Her parçanın sonunda kısa bir özet üret: kaç adım geçti, kaç adım ayrıldı, ne bekliyor.
6. Gözetimi kaydet: ayrılan adımlar, bildirim ile karar arasındaki süre, verilen karar, gözetimsiz çalışan riskli adım sayısı.

Uygularken:
- Sapma kurallarını modelin yorumuna bırakma, kodla yaz. Model yalnız ayrılan adımı kullanıcıya açıklasın.
- "Hâlâ orada mısın" gibi bir varlık düğmesini dikkat kontrolü sayma. Kontrol gerekiyorsa içerikle ilgili bir karar sor.
- Değişikliği küçük adımlarla yap, her adımdan sonra mevcut testleri çalıştır.
- Bir test ekle: uzun bir işin ortasına bilerek bir sapma koy (örnek: bir kaydın banka hesabını değiştir) ve ajanın o adımı ayırıp bildirim gönderdiğini, sapmalı adımı çalıştırmadığını doğrula. İkinci bir test riskli kesitte kullanıcı yokken ajanın durduğunu doğrulasın.

## Kullanıcıyı karar anında çağır
- Uzun bir işte kullanıcının her adımı izleyeceğini varsayma. Rutin adımları kendin kontrol et ve beklenenden sapanı ayır.
- Sapan bir adımı fark edersen onu çalıştırma. Neyin neden farklı olduğunu, eski ve yeni değeri ve seçenekleri tek bir mesajda yaz.
- Ödeme, dışarıya gönderim, kalıcı silme ve hesap bilgisi değişikliğini kullanıcı açıkça karar vermeden yapma.
- Uzun işi parçalara böl, her parçanın sonunda kısa bir özet ver: kaç adım geçti, kaç adım bekliyor.
- Her adımı aynı tonla raporlama. Olağandışı olanı rutin satırların arasına gömme, başa yaz.

Kısa işte gerekmez. Ajan birkaç dakikalık bir işi kullanıcının gözü önünde yapıyorsa izlemek zaten işin parçası. Bu desen dakikalarca, saatlerce süren işler için.

Alarm kuralları da yanılır. Sistemin tanımadığı bir sapma ayrılmaz ve kullanıcı artık akışa bakmıyor. Bainbridge aynı soruyu 1983'te sordu. Alarm sistemi düzgün çalışmadığında bunu kim fark edecek? Kuralları gerçek hatalarla düzenli olarak sına, sonradan bulunan her sapmayı kurala çevir.

Çağrıyı çoğaltmak deseni bozar. Her küçük farkta kullanıcıyı çağıran sistem onay yorgunluğunun aynısını üretir. Çağrı seyrek gelmeli ve nedenini söylemeli.

Dikkati izlemenin de bedeli var. Kamera, bakış takibi ve etkinlik sinyali kişisel veri. Gözetim gereken kesiti dar tut ve kullanıcıya neyi neden izlediğini söyle. Uzun vadede insanın işi elle yapma becerisini kaybetmesi ayrı bir desenin konusu.