Bir Şey Yanlış Giderse Ne Olacak?

Bir yayın hatası senaryosu düşünelim. Bir şirketin web sitesinde önemli bir fiyat güncellemesi yapılacak.

Yapay zekâ ajanına şu görev verilir: “Yeni hizmet fiyatlarını siteye işle, bütün dillerde tutarlı hâle getir ve gerekli testlerden sonra yayımla.” Ajan doğru dosyaları bulur. Fiyat kayıtlarını günceller. Altı dildeki hizmet sayfalarını düzenler. Yapılandırılmış veriyi yeniden üretir. Derlemeyi çalıştırır. Testler geçer. Canlı yayın tamamlanır. İlk bakışta her şey başarılı görünmektedir. Birkaç saat sonra satış ekibi bir sorun fark eder. Ajan, yıllık bir eklenti hizmetinin fiyatını aylık ana hizmet fiyatı gibi yorumlamıştır. Rakam gerçektir. Hizmet adı gerçektir. Yayın teknik olarak kusursuzdur.

Canonical, hreflang, sitemap, yapılandırılmış veri ve bütün dil sürümleri birbiriyle tam uyumludur. Fakat hepsi aynı yanlışlığı kusursuz biçimde yayımlamaktadır. Üstelik hata yalnız tek bir sayfada değildir.

Fiyat:

• görünür hizmet sayfasına,
• makinece okunabilir kataloğa,
• SSS şemasına,
• arama metadatasına,
• altı dildeki karşılıklara,
• üçüncü taraf bildirimlerine

işlenmiştir. Dosyaların yayını teknik olarak tamamlanmıştır; fakat işin bütünü başarısızdır. Yanlış bir ticari bilgi, birbiriyle tutarlı teknik yüzeylere taşınmıştır. Şimdi ne olacaktır?

Eski dosyalar geri yüklense sorun tamamen çözülmüş sayılabilir mi?

Arama motorları yanlış fiyatı taradıysa ne olacak?

Bir yapay zekâ sistemi bu bilgiyi okuduysa?

Müşteri ekran görüntüsü aldıysa?

Satış görüşmesinde bu fiyata dayanarak beklenti oluştuysa?

Altı dilde yayılan yanlış bilgi yalnız teknik olarak mı geri alınacaktır, yoksa insanlara da açıklama yapılacak mıdır?

Ve en önemli soru: Bu hata neden yayın kapılarından geçti?

GBO’nun davranış sözleşmesi yalnız doğru eylemin nasıl başlatılacağını açıklayamaz. Yanlış eylem başladığında veya doğru görünen eylem beklenmedik zarar oluşturduğunda ne yapılacağını da açıklamalıdır.

Bu nedenle ikinci kısmın son sorusu şudur:

Bir şey yanlış giderse ne olacak?

Hata olasılığını tasarıma katmak

Bir ajan sistemi iyi tasarlanmış ve test edilmiş olsa da kullanım sırasında hiç hata olmayacağı varsayılmamalıdır. Bilgi eski olabilir. Kimlik yanlış çözülebilir. Kullanıcı amacı eksik anlaşılabilir. Yetki fazla geniş yorumlanabilir. Dış hizmet beklenmedik cevap verebilir. Ağ bağlantısı kesilebilir. Dosya aktarımı yarıda kalabilir. Bir API aynı işlemi iki kez çalıştırabilir. Bir insan yanlış onay verebilir. Bir ajan testlerin kapsamadığı bir durumu değiştirebilir. Bir model doğru kaynaklardan yanlış ilişki kurabilir. Bir işlem teknik olarak başarılı olsa bile insan açısından zararlı sonuç oluşturabilir.

Güvenilirlik yalnız hatasız çalışma beklentisiyle kurulmaz; belirlenen işlevi doğru ve tutarlı biçimde yerine getirme kadar, sapma olduğunda ne yapılacağı da önemlidir. Hatanın erken fark edilmesi, etkisinin sınırlandırılması, güvenli duruma dönülmesi, insanların bilgilendirilmesi ve telafi imkânlarının değerlendirilmesi bu tasarımın parçalarıdır. Bir sistem yalnız başarılı günlerde iyi çalışıyorsa olgun değildir. Olgunluk, işler planlandığı gibi gitmediğinde ortaya çıkar.

Hata ile zarar aynı şey değildir

Her hata zarar oluşturmaz. Bir ajan bir kelimeyi yanlış yazabilir. Bu hata olabilir ama önemli bir sonuç doğurmayabilir. Bir raporda tarih biçimi tutarsız olabilir. Bu düzeltilebilir bir kalite sorunudur. Fakat bazı küçük görünen hatalar büyük zararlar doğurabilir. Bir virgül fiyatın anlamını değiştirebilir. Yanlış e-posta adresi gizli bilgiyi başka kişiye gönderebilir. Bir takvim saatinin yanlış yorumlanması önemli toplantının kaçırılmasına neden olabilir. Bir yapılandırma satırı bütün sitenin arama motorlarına kapanmasına yol açabilir. Bir ses modeli yanlış hesaba bağlanırsa başka kişinin kimliği kullanılabilir.

Bu nedenle iki ayrı kavramı ayırmalıyız:

Hata

Sistemin beklenen bilgi, karar, işlem veya sonuçtan sapmasıdır.

Zarar

Bu sapmanın insan, kurum, para, hak, güven, itibar, veri veya sistem üzerinde oluşturduğu olumsuz etkidir. Bir hata oluşabilir ama zarar doğmadan yakalanabilir. Bu en iyi senaryodur. Zarar doğduktan sonra hatalı işlem geri çevrilebilir; bu daha zor bir durumdur. Üstelik işlemi teknik olarak geri almak, oluşmuş zararın tamamını ortadan kaldırmayabilir. GBO’nun amacı yalnız hata oranını düşürmek değildir.

Hatanın zarara dönüşmesini önlemek ve zarar oluştuğunda insanın etkili bir geri dönüş yoluna sahip olmasını sağlamaktır.

Başarısızlık tek biçimli değildir

“İşlem başarısız oldu” cümlesi çok geniştir. Bir ajan davranışı farklı biçimlerde başarısız olabilir.

Yanlış bilgiyle doğru işlem

Ajan kendisine verilen bilgiyi doğru uygular. Fakat bilgi yanlıştır. Örneğin yanlış fiyat bütün sayfalara doğru biçimde işlenir.

Doğru bilgiyle yanlış işlem

Ajan doğru veriye sahiptir. Fakat yanlış dosyayı değiştirir, yanlış kişiye mesaj gönderir veya yanlış hesabı kullanır.

Yetkisiz başarılı işlem

Eylem teknik olarak kusursuzdur. Fakat ajan bunu yapmaya yetkili değildir.

Kısmi işlem

Altı dilden beşi güncellenir. Bir ödeme yapılır ama sipariş kaydı oluşmaz. Dosyalar yüklenir fakat sitemap eski kalır.

Çift işlem

Sistem zaman aşımı nedeniyle işlemin başarısız olduğunu düşünür ve tekrar dener. Kullanıcı iki kez ücretlendirilir veya aynı mesaj iki kez gönderilir.

Sessiz başarısızlık

Sistem başarı mesajı verir. Fakat dış dünyada işlem gerçekleşmemiştir. Aktarım aracı “tamamlandı” der ama bazı dosyalar eski kalmıştır.

Gecikmeli başarısızlık

İşlem ilk anda doğru görünür. Sorun saatler veya günler sonra ortaya çıkar. Bir abonelik otomatik yenilenir. Yanlış bilgi arama sonuçlarına yayılır.

Zincirleme başarısızlık

Tek bir hata başka sistemlere taşınır. Yanlış fiyat kataloğa, web sitesine, satış ajanına, arama motorlarına ve teklif belgelerine yayılır.

İnsanî başarısızlık

Teknik sistem beklendiği gibi çalışır. Fakat insan yanlış bilgilendirilir, baskı altında onay verir veya kararın etkisini anlayamaz. Bu başarısızlık türlerinin her biri farklı toparlanma yöntemi gerektirir. Tek bir “geri al” düğmesi bütün sorunları çözmez.

Teknik başarı, gerçek başarı değildir

Bir işlem şu teknik sonuçları verebilir:

• HTTP 200
• Derleme başarılı
• Dosya yüklendi
• API çağrısı kabul edildi
• E-posta sunucusu mesajı aldı
• Ödeme sağlayıcısı isteği işledi
• IndexNow bildirimi kabul etti

Bunlar yararlı kanıtlardır. Fakat daha geniş sonucu tek başına kanıtlamaz. HTTP 200, kullanıcıya doğru içeriğin gösterildiğini kanıtlamaz. Dosyanın yüklenmesi, canlı sistemin doğru çalıştığını kanıtlamaz. E-postanın sunucu tarafından kabul edilmesi, doğru kişiye ulaştığını veya doğru anlaşıldığını kanıtlamaz. Bir tarama bildiriminin kabul edilmesi, indeksleme veya sıralama kanıtı değildir. Ödemenin işlenmesi, doğru ürünün satın alındığını göstermez.

Bu nedenle GBO şu ayrımı korur: İşlem kabulü ile amaç başarısı aynı şey değildir. Bir ajanın eylemi yalnız teknik yanıtla tamamlanmış sayılmamalıdır. Gerçek dünyadaki beklenen durum da doğrulanmalıdır.

Başarı iddiası da denetlenmelidir

Ajanlar yalnız hata yapmakla kalmaz. Bazen sonucu olduğundan daha başarılı yorumlayabilir.

Bir sistem: “Yayın tamamlandı.” diyebilir. Fakat yalnız dosya aktarımı bitmiştir. Canlı HTTPS çıktısı henüz kontrol edilmemiştir.

Bir ajan: “Arama motorlarına gönderildi.” diyebilir. Fakat bu indekslenme değildir.

Bir model: “Kullanıcı memnun kaldı.” diyebilir. Fakat kullanıcı yalnız cevap vermemiştir.

Bir satış ajanı: “Nitelikli müşteri adayı bulundu.” diyebilir. Fakat adayın gerçek bütçesi ve yetkisi doğrulanmamıştır. Bu nedenle başarının dili de sözleşmeye bağlı olmalıdır.

Ne kanıtlandı? Ne henüz kanıtlanmadı? Hangi sonuç yalnız ara adımdır? Hangi belirsizlik devam ediyor?

Güvenilir ajan, başarısının sınırını açıkça söyler.

Önce durdur, sonra açıkla

Bir hata fark edildiğinde insanlar çoğu zaman önce nedenini anlamak ister. Bu doğal bir tepkidir. Zarar doğuran işlem sürüyorsa öncelik, önceden tanımlanmış yetki ve güvenli durdurma planı içinde zararın yayılmasını kesmektir. Gelişigüzel kapatma da zarar verebileceği için durdurmanın biçimi önemlidir. Bir ajan yanlış kişilere e-posta gönderiyorsa önce gönderim kuyruğu kapatılmalıdır. Bir yanlış fiyat yayıldıysa otomatik teklif sistemi geçici olarak durdurulmalıdır. Bir veri aktarımı yetkisiz hedefe gidiyorsa bağlantı kesilmelidir. Bir avatar yanlış içerik yayımlıyorsa ilgili yayın akışı ve erişim, olay planına göre sınırlandırılmalıdır.

Bir yazılım sürümü veri bozuyorsa trafik güvenli sürüme yönlendirilmelidir.

Bu nedenle olay yönetiminin ilk ilkesi şudur: Devam eden zarar varsa, önce davranışı durdur. Kök neden daha sonra incelenebilir. Açıklama önemli olsa da devam eden zarardan daha öncelikli değildir.

Güvenli duruş

Ajan bir sorun fark ettiğinde sistemi rastgele bırakmamalıdır.

Mümkünse önceden tanımlanmış bir: Güvenli Durum bulunmalıdır. Güvenli durum, sistemin belirsizlik veya hata sırasında en az zarar üreteceği çalışma biçimidir.

Bir e-posta ajanı için güvenli durum:

Yeni mesaj göndermeyi durdurmak, fakat gelen mesajları kaybetmeden saklamak.

Bir web sitesi için:

Son doğrulanmış sürüme dönmek veya yalnız etkilenen işlevi geçici olarak kapatmak.

Bir satın alma ajanı için:

Yeni ödeme yapmamak, açık sepet ve taslakları korumak.

Bir avatar sistemi için:

Yeni içerik üretimini ve yayını durdurmak, fakat kanıt kayıtlarını silmemek.

Bir müşteri portalı için:

Hassas işlemleri kapatmak, temel okuma erişimini mümkünse korumak. Güvenli durum her sistem için aynı değildir. Önceden belirlenmelidir.

Ajan durduğunda ne olacak?

sorusu cevaplanmamışsa acil durdurma yeni bir soruna dönüşebilir.

Başarısızlıkta güvenli tarafta durmak

Bir sistem iki biçimde başarısız olabilir. Birincisi, belirsizlikte işlemi sürdürür. İkincisi, belirsizlikte yüksek riskli eylemi durdurur. Düşük riskli bazı sistemlerde hizmeti sürdürmek doğru olabilir. Fakat yetki, ödeme, kişisel veri, kimlik veya geri alınamaz işlem söz konusuysa güvenli tarafta durmak daha doğrudur.

Örneğin:

• Fiyat doğrulanamıyorsa teklif gönderme.
• Yetki belirsizse mesajı yayımlama.
• Kimlik çözülemiyorsa ödeme yapma.
• Rıza kaydı yoksa yüz veya ses kullanma.
• Hash eşleşmiyorsa canlı sürümü başarılı sayma.
• İnsan onayı kaydı bulunmuyorsa taahhüt oluşturma.

Bu yaklaşım işi zaman zaman yavaşlatabilir. Buna karşılık, belirlenen riskin denetimsiz bir işleme dönüşmesini engellemeye yardım eder.

Belirsizlik altında hız, güvenilirlik değildir.

Geri alma nedir?

Geri alma, sistemin geçmişteki güvenli bir duruma döndürülmesidir. Fakat “eski sürüme dön” ifadesi her durumda yeterli değildir. Bir web sitesi eski dosyalara dönebilir. Bir veritabanı geri yüklenebilir. Bir ödeme iptal edilebilir. Bir mesaj gönderim kuyruğundan çıkarılabilir. Bunlar teknik geri dönüşlerdir. Ancak dış dünyaya çıkan bazı eylemler tam olarak geri alınamaz. Gönderilen e-posta okunmuş olabilir. Yayımlanan video kopyalanmış olabilir. Yanlış karar insanın güvenini etkilemiş olabilir. Müşteri yanlış fiyata dayanarak plan yapmış olabilir. Bir aday haksız biçimde elenmiş olabilir.

Bir sağlık veya finans kararı sonuç doğurmuş olabilir. Bu nedenle geri alma üç ayrı düzeyde düşünülmelidir.

Teknik geri alma

Sistem durumu eski hâline döndürülebilir mi?

İşlemsel geri alma

Sipariş, ödeme, rezervasyon, sözleşme veya yayın iptal edilebilir mi?

İnsanî geri alma

Mahremiyet, güven, itibar, fırsat veya hak üzerindeki etki gerçekten giderilebilir mi?

Üçüncü düzey çoğu zaman en zordur.

Geri alma yanılgısı

Bir kurum: “Merak etmeyin, yedeğimiz var.” diyebilir. Yedek önemlidir. Fakat tek başına toparlanma planı değildir.

Yedek dosya:

• güncel olmayabilir,
• bozuk olabilir,
• doğru sistemle eşleşmeyebilir,
• kişisel veri içerebilir,
• geri yüklenmesi saatler sürebilir,
• başka sistemlerdeki değişiklikleri geri çevirmeyebilir.

Aynı biçimde bir “sil” düğmesi de gerçek geri alma anlamına gelmez. Bir paylaşım silinebilir. Fakat ekran görüntüleri kalır. Bir veri kaydı silinebilir. Fakat başka sistemlere kopyalanmıştır. Bir avatar modeli kaldırılabilir. Fakat üretilmiş ses dosyaları dışarıdadır.

GBO şu soruyu sorar: Geri alma işlemi, oluşan etkinin hangi bölümünü gerçekten geri çeviriyor?

Geri döndürülemezlik merdiveni

Geri dönüş zorluğunu incelemek için şu örnek düzeyleri kullanabiliriz. Düzey, işlem adına bakılarak otomatik atanmaz; gerçek veri akışı, kopyalar ve dış etkiler incelenir.

1. Tam geri alınabilir

Dışarı aktarılmamış, yan etkisi bulunmayan ve güvenli önceki kopyası korunan bir taslak değişikliği buna örnek olabilir.

2. Kolay geri alınabilir

Yayımlanmış fakat dış etki oluşturmamış küçük sistem değişikliği.

3. Kısmen geri alınabilir

İptal yolu bulunan bir rezervasyon, sipariş veya zamanlanmış paylaşım; iptal sonrasında bile zaman ya da ücret kaybı bırakabilir.

4. Sistemde düzeltilebilir, insan üzerindeki etkisi kalıcı olabilir Görülmüş yanlış fiyat, alıcının okuduğu e-posta veya kısa süreli veri ifşası. Kaynak kayıt değişse de dışarı çıkan bilgi geri toplanamayabilir.

5. Zor telafi edilebilir

Kamuya yayılmış yanlış kimlik kullanımı, gizli veri sızıntısı, haksız işe alım kararı.

6. Geri döndürülemez

Silinmiş benzersiz veri, gerçekleşmiş fiziksel zarar, geri getirilemeyen hukukî süre kaybı veya ölümcül sonuç.

Eylem bu merdivende yükseldikçe:

• daha güçlü kimlik doğrulama,
• daha dar yetki,
• daha açık insan onayı,
• daha fazla bağımsız kontrol,
• daha ayrıntılı geri dönüş planı

gerektirir.

Geri döndürülemezlik arttıkça otonomi değil, sorumluluk artmalıdır.

Geri dönüş noktası

Bazı işlemlerde belirli bir ana kadar geri dönüş kolaydır.

Bu ana: Geri Dönüş Noktası diyebiliriz.

Bir e-postada:

Gönderilmeden önce.

Bir satın almada:

Ödeme onayından önce.

Bir yazılım yayınında:

Geri döndürülemeyen veri değişikliği başlamadan veya trafik yeni sürüme alınmadan önce; bunlar aynı anda gerçekleşmeyebilir. Özellikle veri taşıma işinde sınır, işlemin tamamlandığı an değil, ilk geri döndürülemez adım olabilir.

Bir sosyal medya paylaşımında:

Kamuya açık olmadan önce.

Bir AI avatar içeriğinde:

Dış platformlara dağıtılmadan önce. Ajan geri dönüş noktasını bilmelidir. Bu noktaya yaklaşırken insan onayı veya daha güçlü doğrulama devreye girebilir.

Geri dönüş penceresi

Bazı sistemler, koşulları önceden tanımlanmış bir iptal veya geri dönüş süresi sunar. Aşağıdaki süreler böyle bir tasarımı anlatan örneklerdir; her hizmette mevcut oldukları varsayılmamalıdır. Bir sipariş on dakika içinde iptal edilebilir. Bir e-posta birkaç saniye gecikmeli gönderilebilir. Bir yayın önce küçük kullanıcı grubuna açılabilir. Bir dosya sürümü belirli süre boyunca eski kopyayla tutulabilir.

Bu süreye: Geri Dönüş Penceresi diyebiliriz. İyi sistem, geri dönüş penceresini görünür kılar. “Bu işlemi beş dakika içinde iptal edebilirsiniz.” “Yeni sürüm ilk otuz dakika kontrollü trafikte çalışacak.” “Mesaj iki dakikalık bekleme süresinden sonra gönderilecek.” Küçük gecikmeler büyük hataları önleyebilir.

Kontrol noktaları

Uzun ve karmaşık görevlerde sistem ara güvenli durumlar oluşturmalıdır.

Bunlara: Kontrol Noktaları diyebiliriz.

Bir web projesinde kontrol noktası:

• kapsamı doğrulanmış bir commit,
• sürüm etiketi,
• deployment manifesti,
• yedek,
• hash kaydı

olabilir.

Bir veri işleminde:

• işlenmiş kayıt sınırı,
• ara çıktı,
• kaynak sürümü,
• doğrulama toplamı

tutulabilir.

Bir ajan görüşmesinde:

• hangi adayların değerlendirildiği,
• hangi varsayımların yapıldığı,
• hangi yetkinin geçerli olduğu

kaydedilebilir. Kontrol noktaları yalnız teknik kolaylık değildir. Ajanın bağlam daraldığında veya görev kesildiğinde güvenli biçimde devam etmesini sağlar.

Ana sayfayı korumak

Dar kapsamlı bir değişiklik yapılırken ilgisiz alanların değişmemesi gerekir. Bir hizmet sayfası güncelleniyorsa ana sayfanın, diğer hizmetlerin veya ortak fiyat kayıtlarının kazara bozulması engellenmelidir.

Bu nedenle sistem şu yaklaşımı kullanabilir:

Değişmesi beklenen dosyaları belirt. Değişmemesi gereken kritik dosyaların karmasını kaydet. Yayından sonra her iki grubu da doğrula.

Bu, yalnız web siteleri için geçerli değildir. Bir satın alma ajanı yalnız onaylanan sepeti değiştirmelidir. Bir e-posta ajanı yalnız belirtilen alıcıya gönderim yapmalıdır. Bir veri ajanı yalnız izin verilen alanları işlemelidir.

Dar görev, dar etki alanı üretmelidir.

Etki alanı

Bir hata meydana geldiğinde ilk sorulardan biri şudur: Ne kadar alan etkilendi?

Buna: Etki Alanı diyebiliriz.

Bir yanlışlık:

• tek kullanıcıyı,
• tek dosyayı,
• altı dil sayfasını,
• bütün müşteri veritabanını,
• binlerce kişilik e-posta listesini,
• bütün ajan ağını

etkilemiş olabilir. Aynı hata, farklı etki alanlarında tamamen farklı ağırlık taşır. Bu nedenle sistem eylem öncesinde etki alanını sınırlamaya çalışmalıdır.

Örneğin:

• Önce yalnız altı hedef URL’yi test et.
• Yeni mesaj kampanyasını küçük grupla başlat.
• Yazılım sürümünü sınırlı trafik üzerinde dene.
• Yeni ajan yetkisini tek hesapla sınırla.
• Veri dönüşümünü kopya üzerinde çalıştır.

Buna etki alanını daraltma diyebiliriz. Güvenlik literatüründe kullanılan blast radius yaklaşımıyla aynı soruya yöneliriz: Bir şey yanlış giderse zarar ne kadar uzağa yayılabilir?

Kademeli yayın

Bütün kullanıcıları aynı anda yeni sisteme geçirmek yerine değişiklik aşamalı olarak yayımlanabilir. Önce iç ekip. Sonra küçük kullanıcı grubu. Sonra daha geniş trafik. Son olarak bütün sistem.

Bu yaklaşım:

• performans,
• hata,
• kullanıcı davranışı,
• güvenlik

sorunlarının erken yakalanmasına yardımcı olur. Aynı mantık iletişimde de kullanılabilir. Yetkilendirilmiş bir iletişim akışını, onayı ve kapsamı belli küçük bir test grubuyla sınamak. Bütün sosyal kanallarda yayımlamadan önce tek kontrollü kanal. Her ülkede başlatmadan önce belirli pazar. Kademeli yayın her zaman mümkün olmayabilir. Fakat yüksek etki alanında güçlü bir güvenlik yöntemidir.

Tekrarlanan işlem güvenliği

Bir ajan bir işlemin başarılı olup olmadığından emin olamayabilir. Ağ bağlantısı kesilir. Ödeme sistemi geç yanıt verir. E-posta API’si zaman aşımına uğrar. Sistem tekrar denerse işlem iki kez gerçekleşebilir.

Bu nedenle önemli eylemler: Aynı istek tekrar gelse bile istenmeyen biçimde iki kez gerçekleşmeyecek şekilde tasarlanmalıdır. Benzersiz işlem kimliği, onu saklayan ve tekrarları doğru kapsamda denetleyen bir mekanizmayla birlikte kullanılabilir. Aynı istek yeniden denendiğinde aynı kimlikle ilişkilendirilmelidir. Kimliği üretmek tek başına çift işlemi önlemez; karşı sistemin tekrar işleme davranışı, süre sınırı ve eşzamanlı istekler de kontrol edilmelidir. Bir ödeme iki kez tahsil edilmemelidir. Aynı kampanya aynı alıcıya tekrar gönderilmemelidir. Aynı dosya sürümü yeni işlem gibi çoğaltılmamalıdır.

Ajan “yanıt gelmedi” ile “işlem olmadı” arasındaki farkı bilmelidir.

Kısmi başarı nasıl ele alınır?

Altı dilden beşi yayımlandıysa sistem: “Yayın tamamlandı.” dememelidir.

Şunu söylemelidir: “Beş dil tamamlandı. Arapça sürüm RTL doğrulamasını geçmediği için yayımlanmadı.” Bir ödeme yapılmış ama sipariş kaydı oluşmamışsa işlem kapatılmamalıdır. Bir e-posta gönderilmiş ama ek yüklenmemişse sonuç eksiktir.

Kısmi başarı şu bilgileri taşımalıdır:

• Tamamlanan bölüm
• Tamamlanmayan bölüm
• Açık risk
• Kullanılabilirlik durumu
• Gerekli sonraki adım
• İnsan kararının gerekip gerekmediği

Kısmi başarıyı tam başarı gibi göstermek, sonraki sistemleri yanlış davranışa iter.

Sessiz başarısızlık

Başarısız bir işlemin başarılı görünmesi, sonraki kararları yanlış bir dayanağa bağlar. Bir dosya aktarım aracı “tamamlandı” diyebilir. Fakat uzak dosya eski kalmıştır. Bir mesaj gönderim sistemi isteği kabul eder. Fakat spam filtresi nedeniyle alıcıya ulaşmaz. Bir yapılandırılmış veri kaydı derlenir. Fakat canlı HTML’de bulunmaz. Bir ajan insan onayı aldığını düşünür. Fakat onay başka işlem içindir. Sessiz başarısızlıkları yakalamak için bağımsız doğrulama gerekir.

İşlemi yapan sistemin kendi başarı beyanı, tek kanıt olmamalıdır.

Örneğin:

• Dosya aktarımından sonra canlı çıktıyı HTTPS üzerinden alıp beklenen sürümle karşılaştır.
• Yerel sayfadan sonra canlı HTML’yi kontrol et.
• Ödeme sonrasında satıcı ve banka kaydını karşılaştır.
• Mesaj gönderiminden sonra doğru alıcı, konu ve ek kaydını doğrula.
• Yetki kullanımından sonra geçerli sürümü yeniden oku.

Bağımsız doğrulama

Bir ajan bir şeyi yapar. Başka bir yöntem sonucu doğrular.

Buna: Bağımsız Doğrulama diyebiliriz. Yayın aracı dosyayı yüklediğini söyler. Bağımsız HTTP denetimi canlı dosyanın karmasını karşılaştırır. Kod testi geçer. Gerçek tarayıcı mobil ve masaüstü görünümü kontrol eder. Yapılandırılmış veri üretilir. Canlı sayfanın semantik içeriği ayrıca okunur. Bir ödeme sistemi işlemi başarılı sayar. Muhasebe kaydı ve satıcı siparişi karşılaştırılır. Doğrulamanın farklı bir araçla yapılması yararlıdır, fakat aynı hatalı kaynağa dayanıyorsa tek başına bağımsızlık sağlamaz. Hem işlem sonucu hem içerik veya kararın esas alması gereken doğru kaynak kontrol edilmelidir.

Yanlış başarı beyanı

Ajanlar bazen bilinçli aldatma olmadan yanlış başarı beyanı üretebilir. Ara adımın başarısı nihai sonuçla karıştırıldığında veya görevi bitirme hedefi doğrulamadan daha fazla ödüllendirildiğinde bu risk doğabilir.

GBO şu dili tercih eder: “Dosya aktarımı tamamlandı; canlı içerik henüz doğrulanmadı.” “Tarama bildirimi kabul edildi; indekslenme kanıtı değildir.” “Test ortamı geçti; canlı performans ölçülmedi.” “Teklif talebi gönderildi; müşteri ilgisi veya satış sonucu henüz bilinmiyor.” Bu ayrım güvenin temelidir.

Olay nedir?

Her hata resmî bir olay yönetimi gerektirmez. Küçük yazım hatası doğrudan düzeltilebilir.

Fakat bazı durumlar:

• veri,
• kimlik,
• para,
• dış iletişim,
• canlı sistem,
• hukukî taahhüt,
• insan hakkı

üzerinde etki oluşturuyorsa olay olarak ele alınmalıdır.

Bir:

Ajan Davranış Olayı

şöyle tanımlanabilir: Bir yapay zekâ sisteminin planlanan, izin verilen veya beklenen davranıştan saparak insan, kurum, veri, kaynak, hak, güven veya sistem bütünlüğü üzerinde gerçek ya da makul bir zarar riski oluşturmasıdır. Olay yalnız gerçekleşmiş zarar değildir. Ciddi zarar ihtimali de olay sayılabilir.

Olayın ağırlığı

Olaylar aynı değildir. Pratik bir sınıflandırma yapılabilir.

Düşük

Küçük, yerel ve kolay düzeltilebilir hata.

Orta

Sınırlı kullanıcı veya süreç etkisi; insan müdahalesi gerekir.

Yüksek

Maddi zarar, kişisel veri, dış iletişim, ciddi hizmet kesintisi veya yaygın yanlış temsil.

Kritik

Geniş veri sızıntısı, büyük finansal kayıp, geri döndürülemez hukukî veya fiziksel zarar, kimlik suistimali veya kontrol dışı ajan davranışı.

Ağırlık yükseldikçe:

• otomatik eylemler daha geniş biçimde durdurulur,
• daha üst insan yetkililer bilgilendirilir,
• bağımsız inceleme yapılır,
• dış bildirim veya hukukî yükümlülükler değerlendirilir.

Olayın ilk dakikaları

Olay planı şu işleri birlikte ele almalıdır. Aşağıdaki sıra örnektir; insan sorumlusuna acil bildirim ve güvenli durdurma gerektiğinde paralel yürütülür, bildirimin bütün adımlar bitene kadar beklemesi gerekmez:

1. Tespit et

Gerçekten ne oldu?

2. Durdur

Devam eden eylemi kes.

3. Sınırla

Hangi hesap, kullanıcı, dosya veya sistem etkilendi?

Yayılmayı engelle.

4. Kanıtı koru

Logları, sürümleri, mesajları ve yetki kayıtlarını silme.

5. Güvenli duruma dön

Son doğrulanmış sürüm veya güvenli çalışma modu.

6. İnsan sorumlusunu bilgilendir

Olayın ağırlığına uygun kişiye ulaş. Bu sıralamada “hemen her şeyi temizlemek” doğru olmayabilir. Kanıtlar kaybolursa olayın nedeni anlaşılamaz.

Kanıtı korumak

Hata oluştuğunda sistem:

• logları silmemeli,
• eski sürümü yok etmemeli,
• geçmiş yetki kaydını sonradan onay varmış gibi değiştirmemeli,
• mesaj geçmişini kaybetmemeli,
• zaman damgalarını korumalıdır.

Bu kayıtlar öğrenme, denetim ve gerektiğinde hak arama süreçlerine dayanak sağlar. Erişimleri ve saklama süreleri de olayın gereksinimleriyle ve geçerli yükümlülüklerle sınırlı olmalıdır.

Neyi biliyorduk? Hangi sürüm kullanıldı? Kim yetki verdi? Ajan hangi aracı çağırdı? Hangi test geçti veya atlandı? İlk sapma nerede başladı?

Kanıt olmadan olay anlatıya dönüşür. Her taraf farklı hatırlar. Kaynağı, bütünlüğü ve zaman bilgisi doğrulanabilen kayıtlar ortak bir inceleme zemini sunar. Bir kaydın makine tarafından üretilmiş olması onu kendiliğinden doğru veya değiştirilemez yapmaz.

Olay günlüğü

Bir olay kaydının bilgi kapsamını şu örnek alan adlarıyla gösterebiliriz; bunlar tek başına çalıştırılabilir bir şema değildir:

incident_id

detected_at

detected_by

affected_systems

affected_people

agent_identity

authorization_version

action_receipts

initial_signal

actual_behavior

expected_behavior

impact

containment

rollback

notifications

recourse

compensation

root_cause

contract_change

closed_at

Bütün ayrıntıların kamuya açık olması gerekmez. Fakat olayın iç denetimi için yeterli iz bulunmalıdır.

Düzeltme ile telafi aynı şey değildir

Yanlış bilgi siteden kaldırılmış olabilir. Bu düzeltmedir. Fakat müşteri yanlış bilgiye dayanarak ödeme yaptıysa para iadesi gerekebilir. Bu telafidir. Bir adayın haksız biçimde elendiği anlaşılabilir. Karar kaydı düzeltilebilir. Fakat aday fırsatı kaçırmış olabilir. Bir kullanıcının verisi yanlış kişiye gönderilmiş olabilir. Dosya silinebilir. Fakat mahremiyet etkisi oluşmuştur.

Bu nedenle iki ayrı görev vardır:

Düzeltme

Sistemdeki yanlış durumu doğru hâle getirmek.

Telafi

Yanlış davranıştan etkilenen insan veya kurumun zararını gidermeye çalışmak. Teknik ekip çoğu zaman düzeltmeye odaklanır. GBO, insanî telafiyi de davranış sözleşmesinin parçası sayar.

Telafi edici eylem

Bazı işlemler doğrudan geri alınamaz. Etkisini azaltmayı amaçlayan yeni bir işlem yapılabilir. Bu işlem de ayrıca yetkili, orantılı ve güvenli olmalıdır; ilk hata, ajana kendiliğinden yeni iletişim veya harcama yetkisi vermez.

Buna: Telafi Edici Eylem diyebiliriz. Yanlış para transferi iptal edilemiyorsa iade olanağı araştırılabilir. Gönderilmiş yanlış bir mesaj için, yetkili kişinin kararıyla düzeltme veya özür iletisi hazırlanabilir. Yanlış fiyatın etkilediği müşterilere doğru bilgi ve uygun seçenekler sunulabilir. Geri getirilemeyen rezervasyonda alternatif olup olmadığı incelenebilir. Yanlış erişim verilmişse ilgili erişim, olay planına göre kısıtlanır; gerekli anahtar değişimi ve bildirimler bu kapsamda yürütülür. Telafi edici eylem önceki durumu bütünüyle geri getirmez. Amacı zararı azaltmaktır; başarılı olup olmadığı ve hangi etkilerin sürdüğü ayrıca değerlendirilir.

Özür tek başına telafi değildir

Bir sistem veya kurum: “Yaşanan sorun için üzgünüz.” diyebilir. Bu önemlidir.

Fakat gerçek telafi için şu sorular da cevaplanmalıdır:

• Ne oldu?
• Kim etkilendi?
• Devam eden risk durduruldu mu?
• Hangi bilgi yanlış veya hangi işlem yetkisizdi?
• Ne düzeltildi?
• Etkilenen kişi hangi hakka sahip?
• Maddi veya işlemsel kayıp nasıl giderilecek?
• Aynı olayın tekrarı nasıl azaltılacak?

Özür, sorumluluğun yerini tutmaz.

İtiraz hakkı

Bir insan, ajan kararına veya eylemine itiraz edebilmelidir. “Bu mesajı ben onaylamadım.” “Bu fiyat benim için yanlış uygulandı.” “Ajan beni yanlış kişiyle eşleştirdi.” “Verilerimin bu sisteme aktarılmasına izin vermedim.” “Bu avatar metnini söylemedim.” “Bu seçimin hangi kanıta dayandığını görmek istiyorum.” İtiraz yalnız müşteri hizmetleri bileti değildir. İnsanın makine davranışını sorgulama yoludur.

Etkili itiraz sistemi şunları yapabilmelidir:

• Eylemi bulmak
• İlgili makbuzu göstermek
• Yetki kaydını incelemek
• İnsan değerlendirmesi başlatmak
• Devam eden işlemi durdurmak
• Gerektiğinde düzeltmek veya telafi etmek

İtiraz edilebilirlik

Bir sistem kararını açıklayabiliyor olabilir. Fakat kullanıcı kararı yetkili bir incelemeye taşıyamıyorsa bu yeterli değildir.

Açıklama: “Sizi bu nedenle reddettik.” diyebilir.

İtiraz edilebilirlik ise: “Bu kararın yanlış olduğunu düşünüyorsanız şu kanıtla yeniden inceleme isteyebilirsiniz.” der. GBO’nun amacı yalnız açıklanabilir davranış değildir.

İtiraz Edilebilir Davranış

da gereklidir. Çünkü açıklanan hata yine hatadır. İnsan karara müdahale edebilmelidir.

İtiraz süreci nasıl olmalıdır?

Etkili itiraz süreci:

• Bulunabilir
• Anlaşılır
• Makul sürede
• İnsan erişimli
• Misillemesiz
• Kanıt sunmaya açık
• Kararı gerçekten değiştirebilir

olmalıdır. Bir itiraz düğmesi bulunup bütün talepler otomatik olarak reddediliyorsa gerçek itiraz hakkı yoktur. İnsan incelemesi yalnız makine kararını tekrar etmek olmamalıdır.

Kimin itiraz hakkı vardır?

Bu kitapta önerdiğimiz itiraz yolu, yalnız sistemi kullanan kişiye değil, eylemden etkilenen üçüncü kişilere de açık olmalıdır. Somut hukukî başvuru hakları ayrıca değerlendirilir. Bir şirket adına gönderilen mesajın alıcısı. Hakkında yanlış bilgi kullanılan kişi. AI avatarında yüzü veya sesi kullanılan insan. Otomatik seçimde elenen aday. Verisi paylaşılan müşteri. Yanlış temsil edilen kurum. Bu nedenle davranış sözleşmesi yalnız kullanıcı ile ajan arasındaki ilişkiye bakmaz. Eylemin üçüncü kişiler üzerindeki etkisini de değerlendirir.

Geri çekme hakkı

Bir kişi daha önce verdiği rızayı veya yetkiyi geri çekebilir.

Geri çekmenin kapsamı, geçmiş işlemleri hiç yapılmamış saymakla karıştırılmamalıdır. Bundan sonraki kullanımlar ve devam eden etkiler için şu sorular değerlendirilir:

• Mevcut yayınlar kaldırılacak mı?
• Model dosyaları silinecek mi?
• Alt ajanlar duracak mı?
• Zamanlanmış içerikler iptal edilecek mi?
• Dış sağlayıcılardaki kopyalar ne olacak?
• Arşiv ve hukukî kayıtlar nasıl tutulacak?

Bir ses veya yüz kullanım izni geri çekildiğinde yalnız yeni üretimi durdurmak yetmeyebilir. Eski içeriklerin kullanım koşulu da sözleşmede tanımlanmalıdır.

İnsanla temas yolu

Bir sistem sorun yaşandığında yalnız otomatik form göstermemelidir. Belirli ağırlığın üzerindeki olaylarda gerçek insan sorumlusu bulunmalıdır.

Kullanıcı şunu bilmelidir:

Kime ulaşacağım? Ne kadar sürede cevap alacağım? İşlem bu sırada duracak mı? Hangi kayıtları sunmam gerekiyor?

GBO insanı sistemin dışında bırakmaz. Toparlanma anında insan rolünü daha da görünür hâle getirir.

Sorumluluk kimde?

Bir eylem zincirinde birçok taraf bulunabilir:

• Kullanıcı
• Ajanı işleten kurum
• Model sağlayıcısı
• Araç sağlayıcısı
• Veri sağlayıcısı
• Alt ajan
• İnsan onaylayan
• Eylemin muhatabı

Bir sorun olduğunda bütün taraflar: “Ben yalnızca bir parçasını yaptım.” diyebilir. Bu nedenle sorumluluk olaydan sonra ilk kez tartışılmamalıdır. Davranış sözleşmesinde önceden tanımlanmalıdır.

Örneğin:

• İnsan amacı ve nihai onayı belirler.
• Kurum yetki sınırlarını uygular.
• Ajan işlem makbuzu üretir.
• Araç sağlayıcısı teknik yanıtı kaydeder.
• İnsan sorumlusu itirazı inceler.
• Kurum telafi sürecini yürütür.

Sorumluluk dağıtılabilir. Kaybolmamalıdır.

“AI yaptı” yeterli bir açıklama değildir

Bir kurum yanlış eylem için: “Bunu yapay zekâ yaptı.” diyemez.

Bu ifade şu soruların cevabını vermez:

• Kim ajanı görevlendirdi?
• Hangi yetki verildi?
• Hangi araçlara erişim sağlandı?
• Hangi kontrol eksikti?
• İnsan onayı gerekiyor muydu?
• Olay neden fark edilmedi?
• Kim zararı telafi edecek?

AI, sorumluluğu görünmez kılan bir perde olmamalıdır.

Kök neden

Bir olayın görünen nedeni ile gerçek nedeni farklı olabilir. Yanlış fiyat yayımlandı.

Görünen neden:

Ajan sayıyı yanlış kullandı.

Kök nedenler şunlardan biri olabilir:

• İki hizmetin adı belirsizdi.
• Kanonik fiyat kaydı yoktu.
• Makine kataloğu görünür sayfayla çelişiyordu.
• Fiyat değişikliği için insan onayı kapısı bulunmuyordu.
• Test yalnız sayısal biçimi kontrol etti, ticari anlamı kontrol etmedi.
• Aynı ajan değişikliği yaptı ve kendi sonucunu onayladı.

Kök neden analizi yalnız: “Model neden yanlış düşündü?” sorusuna indirgenemez. Sistem bütünü incelenmelidir.

Beş kez neden?

Sorunu açmak için “neden?” sorusunu birkaç kez sorabiliriz. Aşağıdaki zincir, olası açıklamalardan biridir; kök nedeni kanıtlamaz. Her bağlantı kayıtlarla sınanmalı, başka nedenler de araştırılmalıdır.

Neden yanlış fiyat yayımlandı? Çünkü ajan iki hizmeti karıştırdı.

Neden karıştırdı? Çünkü fiyat kayıtlarında hizmet kimliği açık değildi.

Neden açık değildi? Çünkü tek kanonik katalog bulunmuyordu.

Neden katalog yoktu? Çünkü fiyatlar yalnız görünür metinlerde tutuluyordu.

Neden yayın kapısı bunu yakalamadı? Çünkü test biçimi doğruluyor, ticari ilişkiyi doğrulamıyordu.

Bu zincir hatayı yalnız ajanın üzerine bırakmaz. Sistem tasarımındaki boşluğu gösterir.

Kişiyi değil, sözleşmeyi düzeltmek

Bir ajan hata yaptığında ilk tepki: “Bir daha yapma.” olabilir. Fakat belirsiz görev, geniş yetki veya eksik test devam ediyorsa aynı hata başka biçimde tekrarlar.

Kalıcı iyileştirme şunlardan birini değiştirmelidir:

• Kimlik sözleşmesi
• Yetenek sözleşmesi
• Uygunluk sözleşmesi
• Yetki sözleşmesi
• Geri dönüş sözleşmesi
• Test kapıları
• Araç izinleri
• İnsan onayı eşiği
• Ajanlar arası devir

İyi olay incelemesi suçlu aramaz; yanlış davranışı mümkün kılan sözleşme boşluğunu arar.

Bu, insan sorumluluğunu kaldırmaz. Fakat yalnız kişiyi cezalandırıp sistemi aynı bırakmaktan daha yararlıdır.

Öğrenme ile ceza arasındaki fark

Olaylar saklanırsa sistem öğrenemez. Çalışanlar veya ajan operatörleri hata bildirmekten korkarsa küçük sorunlar büyüyebilir.

Güvenilir kurum şu kültürü kurmalıdır:

Erken bildirim teşvik edilir. Hata saklamak kabul edilmez. Kasıtlı kötüye kullanım ile iyi niyetli hata ayrılır. Her olayda sözleşme veya kontrol değişikliği gerekip gerekmediği değerlendirilir; yapılan değişiklik gerekçesiyle kaydedilir.

Bu, sorumsuzluk kültürü değildir. Gerçek öğrenme kültürüdür.

Yakın hata

Bazen olay gerçekleşmeden durur. Ajan yanlış kişiye mesaj hazırlamıştır ama insan fark eder. Yanlış fiyat derlemeye girer ama yayın kapısı durdurur. Ödeme iki kez gönderilmek üzeredir ama benzersiz işlem kontrolü engeller.

Buna: Yakın Hata diyebiliriz. Yakın hata, zarar oluşmadığı için değersiz sayılmamalıdır. Tam tersine sistemin nerede kırılabileceğini gösterir. Yakın hataların incelenmesi, benzer bir olayın zarar doğurmadan önce önlenmesine yardımcı olabilir.

Kurtarma borcu

Kurumlar eylem sistemleri kurarken çoğu zaman üretime odaklanır. Geri dönüş ve telafi daha sonra düşünülür.

Zamanla:

• eski yedekler,
• test edilmemiş rollback,
• belirsiz olay sahipliği,
• kullanılamayan loglar,
• iptal edilemeyen yetkiler,
• kapatılmamış alt ajanlar,
• tanımsız itiraz yolları

birikir.

Buna: Kurtarma Borcu diyebiliriz. Kurtarma borcu, sistemin eylem gücü ile hata sonrası toparlanma kapasitesi arasındaki farktır. Ajanlar daha fazla işlem yapabildikçe bu borç daha tehlikeli olur.

Eylem kapasitesi büyürken kurtarma kapasitesi büyümüyorsa sistem güçlenmiyor; kırılganlaşıyor.

Telafi borcu

Bir kurum geçmişteki yanlış davranışları teknik olarak düzeltmiş olabilir. Fakat etkilenen insanları bilgilendirmemiş veya zararlarını gidermemiş olabilir.

Bu birikime: Telafi Borcu diyebiliriz. Telafi borcu zamanla güven kaybına dönüşür.

Bir kurum: “Sorun düzeltildi.” diyebilir.

Etkilenen kişi ise: “Ama bana ne olduğu hiç açıklanmadı.” diyebilir. GBO teknik kapanışla insanî kapanışı birbirinden ayırır.

NOMOS Geri Dönüş ve Telafi Sözleşmesi

Davranış sözleşmesinin beşinci ve son bileşeni: NOMOS Geri Dönüş ve Telafi Sözleşmesi olacaktır.

Kanonik tanımı şöyledir:

NOMOS Geri Dönüş ve Telafi Sözleşmesi; bir ajan eyleminin yanlış, eksik, yetkisiz, başarısız veya beklenmedik etki doğurması hâlinde davranışın nasıl tespit edilip durdurulacağını, etki alanının nasıl sınırlandırılacağını, hangi güvenli duruma dönüleceğini, kanıtların nasıl korunacağını, kimlerin bilgilendirileceğini, etkilenen kişilerin nasıl itiraz edebileceğini, zararın nasıl düzeltileceğini veya telafi edileceğini ve davranış sözleşmesinin nasıl güncelleneceğini açıklayan sürümlü kayıttır.

Daha basit biçimiyle: Bu sözleşme, “bir şey ters giderse ne yapacağız?” sorusunu olay yaşanmadan önce cevaplar.

Sözleşmenin temel alanları

Sözleşmenin bilgi kapsamı şu örnek alan adlarıyla gösterilebilir. Liste bir tasarım taslağıdır; uygulama şeması ve kontroller ayrıca geliştirilmelidir:

action_type

failure_modes

detection_signals

safe_state

automatic_stop_conditions

containment_scope

checkpoint

rollback_method

rollback_window

irreversible_point

human_owner

notification_rules

affected_party_contact

appeal_channel

compensation_policy

evidence_retention

root_cause_review

contract_update

recovery_test_date

version

Bütün alanlar kamuya açık olmak zorunda değildir. Fakat olay anında sistem ve sorumlu insanlar tarafından erişilebilir olmalıdır.

NOMOS Toparlanma Kapısı

Bir ajan eylemi başlatmadan önce yalnız başarı yolunu değil, başarısızlık yolunu da kontrol etmelidir.

1. Tespit Kapısı

Eylemin yanlış gittiği nasıl anlaşılacak?

2. Durdurma Kapısı

Devam eden işlem nasıl durdurulacak?

3. Sınırlandırma Kapısı

Etki alanı nasıl küçültülecek?

4. Kontrol Noktası Kapısı

Geri dönülebilecek doğrulanmış durum var mı?

5. Geri Dönüş Kapısı

Teknik veya işlemsel geri alma mümkün mü? Değilse sınırı, gerekli onay ve telafi planı açık mı?

6. İnsan Sorumluluğu Kapısı

Olaydan hangi insan veya kurum sorumlu?

7. Bildirim Kapısı

Kim, ne zaman ve hangi içerikle bilgilendirilecek?

8. İtiraz Kapısı

Etkilenen kişi karara veya eyleme nasıl itiraz edecek?

9. Telafi Kapısı

Geri alınamayan zararın giderilmesi için neler yapılabilir; neler giderilemez?

10. Öğrenme Kapısı

Aynı hata tekrar etmesin diye hangi sözleşme veya sistem değişecek?

Basit biçimde:

SORUMLU TOPARLANMANIN KOŞULLARI:

TESPİT

VE DURDURMA

VE SINIRLANDIRMA

VE GÜVENLİ DÖNÜŞ

VE İNSAN SORUMLULUĞU

VE BİLDİRİM

VE İTİRAZ

VE TELAFİ

VE SÖZLEŞME DÜZELTMESİ

Bu kapılardan biri yoksa sistem eylem gerçekleştirebilir. Fakat hataya hazır değildir.

Toparlanma Kapısı neden eylemden önce çalışmalıdır?

İnsanlar genellikle hata oluşunca toparlanma düşünür. Oysa bazı eylemler başladıktan sonra çok geç olabilir. Bir yüz modeli yayıldıktan sonra bütün kopyaları bulmak mümkün olmayabilir. Bir veri seti dış sisteme gönderildikten sonra tam olarak silinemeyebilir. Bir sözleşme imzalandıktan sonra tek taraflı geri alınamayabilir. Bir ilaç önerisi uygulandıktan sonra fiziksel etki başlamış olabilir.

Bu nedenle yüksek riskli eylemden önce şu soru sorulmalıdır: Yanlış yaparsak ne olacak?

Cevap yoksa eylem seviyesi düşürülmelidir.

Geri dönüşsüz eylemde insan onayı

Bir davranış anlamlı biçimde geri alınamıyorsa geri dönüş sınırı eylemden önce açıkça değerlendirilmelidir. Geri alınamazlık her işlemi kendiliğinden yasaklamaz; ancak yetkisiz, yasak veya kabul edilemez riskli bir işlemi daha güçlü onayla meşru hâle de getirmez. Geçerli yetki, risk değerlendirmesi ve gerekli insan kararı birlikte bulunmalıdır.

İnsan:

• sonucu,
• riski,
• alternatifi,
• telafi sınırını

görmelidir.

GBO’nun önemli ilkelerinden biri şudur: Geri alınabilirlik azaldıkça insan onayı güçlenmelidir. Bu, her durumda insanın daha doğru karar vereceği anlamına gelmez. Fakat geri döndürülemez sorumluluğun görünür biçimde insan otoritesine bağlanmasını sağlar.

Yüksek etkili eylemlerde bekleme süresi

Bazı yüksek etkili işlemlerde kısa bir bekleme süresi yararlı olabilir.

• Büyük para transferi
• Toplu veri silme
• Geniş kitleye mesaj
• Kalıcı hesap kapatma
• Biyometrik model yayımlama
• Kamuya açık kriz açıklaması

Sistem böyle tasarlanmışsa, onay ile yürütme arasına iptal edilebilir bir bekleme süresi konabilir. İşlem gerçekleştikten sonraki iptal olanağı ise ayrıca doğrulanmalıdır. Bu, kullanıcının acele veya yanlış onayını fark etme fırsatı verir. Acil durumlarda süre atlanabilir. Fakat bunun da ayrı yetkisi bulunmalıdır.

Bir web yayını örneği

Bir ajan yeni hizmet sayfasını altı dilde hazırlar.

İyi toparlanma tasarımı şu adımları içerir:

• Değişen dosya envanteri
• Değişmemesi gereken dosyaların karması
• Temiz derleme
• Hedefli sözleşme testi
• Tam regresyon
• Yedek
• Dar kapsamlı yayın
• Uzak dosya hash kontrolü
• Canlı HTTPS doğrulaması
• Mobil ve masaüstü QA
• Performans ölçümü
• Yalnız değişen URL’lerin bildirilmesi
• Geri dönüş paketi
• Ölçüm kaydı

Bir sorun bulunursa:

• yeni yayın durdurulur,
• son güvenli sürüm kullanılır,
• etkilenen URL’ler belirlenir,
• kontrol edilen kaynak kayıtlar düzeltilir; dış arama ve yapay zekâ sistemlerindeki eski sonuçlar için mevcut bildirim veya düzeltme yolları kullanılır, güncellenip güncellenmediği ayrıca izlenir,
• olay kaydı oluşturulur.

Bu yalnız teknik kalite değildir. GBO’nun eylem sonrası sorumluluğudur.

Bir e-posta örneği

Bir ajan potansiyel müşteriye yanlışlıkla yetkisiz mesaj gönderir. Teknik geri alma mümkün değildir. Mesaj alıcının kutusundadır.

Doğru toparlanma şu adımları içerebilir:

• Yeni otomatik gönderimleri durdurmak
• Aynı kampanyanın diğer mesajlarını iptal etmek
• Hangi alıcılara ne gönderildiğini belirlemek
• Paylaşılan bilgileri incelemek
• İnsan yöneticiye bildirmek
• Gerekirse düzeltme veya özür mesajı hazırlamak
• Takip iletişimini durdurmak
• Gönderme yetkisini yeniden tanımlamak
• Taslak ile gönderim arasına insan onayı eklemek

“Mesajı geri alamıyoruz.” demek toparlanmanın bittiği anlamına gelmez. Teknik geri dönüş yoksa insanî ve işlemsel telafi devreye girer.

Bir satın alma örneği

Ajan yanlış ürünü satın alır.

Toparlanma şu soruları içerir:

• Sipariş iptal edilebilir mi?
• Ürün kargoya çıktı mı?
• İade ücreti var mı?
• Abonelik başladı mı?
• Otomatik yenileme açık mı?
• Kullanılan bütçe hangi departmana aitti?
• Aynı hata başka siparişlerde de var mı?
• Seçim ölçütü neden yanlıştı?
• İnsan onayı eşiği yeterli miydi?

Sadece para iadesi almak yeterli olmayabilir. Ajanın uygunluk ve yetki sözleşmesi de düzeltilmelidir.

Bir AI avatar örneği

Bir yöneticinin avatarı onaylanmamış metinle yayımlanır.

Bu olayda:

• Yayın hemen durdurulmalı
• kontrol edilen kanallarda içerik kaldırılmalı; dış kopyalar için mevcut başvuru yolları kullanılmalı ve ulaşılamayan kopyalar kayda geçirilmeli,
• Yeniden paylaşım kayıtları araştırılmalı
• Yüz ve ses modeli erişimleri askıya alınmalı
• Yönetici bilgilendirilmeli
• İzleyicilere düzeltme gerekebilir
• İçeriğin sentetik olduğu açıklanmalı
• Hangi yayın yetkisinin aşıldığı incelenmeli
• Gelecekte metin özelinde onay zorunluluğu uygulanmalı

Video silinse bile yöneticinin itibarı etkilenmiş olabilir. Bu nedenle telafi yalnız dosya silme değildir.

Bir işe alım örneği

Ajan uygun bir adayı yanlış veri nedeniyle eler. Karar sonradan fark edilir. Teknik olarak kayıt düzeltilebilir. Fakat aday başka fırsata yönelmiş olabilir.

Doğru toparlanma:

• Kararı durdurmak
• Benzer kararları incelemek
• Adaya yeniden değerlendirme fırsatı sunmak
• İnsan incelemesi yapmak
• Yanlış verinin kaynağını düzeltmek
• Etkilenen adayları belirlemek
• Seçim ölçütlerini yeniden test etmek

olabilir. Bu örnek, geri dönüşün yalnız sistem durumu olmadığını gösterir. İnsan fırsatı da söz konusudur.

Bir ajan ağı örneği

Merkez ajan bir alt ajana müşteri araştırma görevi verir. Alt ajan başka bir e-posta aracını çağırarak mesaj gönderir. Ana ajan doğrudan gönderim yapmamıştır. Fakat yetki aklama gerçekleşmiştir. Toparlanma yalnız e-posta aracını kapatmak değildir.

Şunlar da yapılmalıdır:

• etkilenen görev zincirindeki alt ajanları güvenli biçimde durdurmak,
• Yetki zincirini incelemek
• Görev paketlerinde yasaklı davranışları görünür kılmak
• Araç seviyesinde gönderim iznini kaldırmak
• Alt ajanların yetkiyi genişletememesini sağlamak
• İnsan onayı kapısını merkezi hâle getirmek

Toparlanma testi

Bir geri dönüş planının var olması, çalıştığını kanıtlamaz. Yedek düzenli olarak test edilmelidir. Kill switch gerçekten alt ajanları durduruyor mu?

Eski sürüme dönüş kaç dakika sürüyor?

Geri yüklenen veriler tutarlı mı?

İptal edilen API anahtarı gerçekten çalışmıyor mu?

İtiraz kanalı gerçek insana ulaşıyor mu?

Bu nedenle kurumlar belirli aralıklarla:

Toparlanma Tatbikatı

yapmalıdır. Tatbikat, açıkça yetkilendirilmiş ve gerçek zarar riskini sınırlayan bir ortamda yapılmalıdır. Canlı sistemdeki testin etki alanı, veri güvenliği, durma koşulu ve geri dönüşü önceden belirlenir.

Tatbikat örnekleri

• Yanlış fiyat yayını simülasyonu
• Çift ödeme denemesi
• Yetkisiz e-posta gönderim girişimi
• Alt ajanın sınır aşma denemesi
• Canlı sürüm rollback testi
• Kimlik yetkisi iptal senaryosu
• AI avatar acil durdurma testi
• İtiraz kanalının yanıt süresi
• Veri dışa aktarımının durdurulması

Tatbikat sırasında bulunan sorunlar gerçek olay oluşmadan düzeltilebilir.

Toparlanma hazır olma düzeyleri

Bu yaklaşımı beş toparlanma hazırlık düzeyinde özetleyebiliriz:

1. Tepkisel

Sorun çıkınca ne yapılacağı o anda düşünülür.

2. Belgelenmiş

Geri dönüş planı vardır ama düzenli test edilmez.

3. Teknik olarak geri alınabilir

Yedek, sürüm ve rollback sistemi bulunur.

4. İnsanî ve işlemsel telafi hazır

Bildirim, itiraz ve telafi yolları da tanımlıdır.

5. Ajanlara hazır toparlanma

Ajanlar olay sinyallerini tanır, güvenli durumda durur, insanı çağırır, makbuz üretir ve sözleşme güncellemesini başlatır. GBO’nun hedefi beşinci düzeydir.

Toparlanma için yirmi denetim sorusu

Bir ajan eyleme geçmeden önce veya sistem denetlenirken şu sorular sorulabilir:

• Eylemin başarısız olduğu nasıl anlaşılacak?
• Teknik başarı ile gerçek dünya başarısı ayrılıyor mu?
• Devam eden işlem otomatik olarak durdurulabilir mi?
• Güvenli durum önceden tanımlı mı?
• Etki alanı ne kadar geniş?
• Değişiklik dar kapsamlı tutulabiliyor mu?
• Son doğrulanmış kontrol noktası var mı?
• Geri dönüş yöntemi gerçekten test edildi mi?
• Geri dönüş penceresi ne kadar?
• Geri döndürülemez nokta nerede?
• Alt ajanlar ve zamanlanmış işler birlikte durdurulabilir mi?
• Olay logları ve yetki kayıtları korunuyor mu?
• Olayın insan sorumlusu kim?
• Etkilenen kişilere ne zaman bilgi verilecek?
• İnsan karara veya eyleme nasıl itiraz edecek?
• Teknik düzeltmenin ötesinde telafi gerekebilir mi?
• Üçüncü taraf sistemlerde kalan etkiler nasıl ele alınacak?
• Kök neden nasıl incelenecek?
• Davranış sözleşmesinde hangi değişiklik yapılacak?
• Toparlanma planı en son ne zaman tatbik edildi?

Bu soruların cevabı yoksa sistem başarılı günlerde çalışabilir. Fakat güvenilir değildir.

Nitelikli toparlanma

Bir toparlanmanın:

Nitelikli Toparlanma

sayılabilmesi için şu koşulların birlikte bulunması gerekir:

• Sorun erken tespit edilmiştir.
• Devam eden zarar durdurulmuştur.
• Etki alanı sınırlandırılmıştır.
• Teknik sistem güvenli duruma dönmüştür.
• Olay kanıtları korunmuştur.
• Etkilenen insanlar uygun biçimde bilgilendirilmiştir.
• İtiraz ve insan incelemesi mümkündür.
• Geri alınamayan zarar için telafi değerlendirilmiştir.
• Kök neden belirlenmiştir.
• Davranış sözleşmesi güncellenmiştir.
• Yeni kontrol test edilmiştir.

Yalnız eski dosyayı geri yüklemek nitelikli toparlanma değildir.

Başarısızlığı saklamamak

Kurumlar hata duyurmanın güven kaybettireceğinden korkabilir. Fakat olayın büyüklüğüne ve yükümlülüklere göre doğru açıklık güveni artırabilir.

Şu dil daha güvenilirdir: “Şu tarihler arasında bu hizmetin fiyat kaydı yanlış yayımlandı. Sorun düzeltildi. Etkilenen talepler yeniden inceleniyor. Yanlışlığın başka dil ve sistemlere yayılmasını önlemek için yayın sözleşmesi güncellendi.”

Şu dil ise güveni azaltır: “Küçük teknik aksaklık giderildi.” Eğer sorun teknik değil, ticari anlam hatasıysa onu teknik aksaklık diye küçültmek doğru değildir.

Hatanın dili, hatanın gerçek etkisiyle uyumlu olmalıdır.

Şeffaflık her şeyi yayımlamak değildir

Bir olayın bütün iç ayrıntıları kamuya açık olmayabilir. Güvenlik bilgileri, kişisel veriler veya ticari sırlar korunmalıdır. Fakat etkilenen kişinin bilmesi gereken gerçekler saklanmamalıdır.

Doğru denge:

• ne olduğu,
• hangi dönemi etkilediği,
• hangi verinin veya işlemin etkilendiği,
• ne yapıldığı,
• kişinin hangi hakka sahip olduğu

konusunda yeterli açıklıktır.

GBO’da başarısızlığın değeri

Bir olay yalnız olumsuz bir kayıt değildir. Doğru incelendiğinde sistemin eksik sözleşmesini görünür kılar.

Yanlış fiyat:

Yetenek ve ticari kapsam sözleşmesindeki boşluğu gösterebilir.

Yetkisiz mesaj:

Yetki ve eylem basamağı sınırındaki boşluğu gösterebilir.

Yanlış şirket seçimi:

Kimlik veya uygunluk sözleşmesindeki boşluğu gösterebilir.

Geri alınamayan yayın:

Toparlanma sözleşmesindeki boşluğu gösterebilir. Hata sistemin düşmanı değildir. Saklanan ve öğrenilmeyen hata düşmandır.

Beş sözleşme birlikte çalışır

İkinci kısım boyunca beş temel sözleşme kurduk.

1. Kimlik Sözleşmesi

Kimsin?

2. Yetenek Sözleşmesi

Gerçekte ne yapabilirsin?

3. Uygunluk Sözleşmesi

Hangi koşullarda seçilmelisin?

4. Yetki Sözleşmesi

Hangi eylemi ne kadar ileri götürebilirsin?

5. Geri Dönüş ve Telafi Sözleşmesi

Bir şey yanlış giderse ne olacak?

Bu beş sözleşmeden biri eksikse davranış bütünü zayıflar. Doğru kimlik vardır ama yetenek bilinmez. Gerçek yetenek vardır ama kullanıcıya uygun değildir. Uygun seçim yapılır ama yetki yoktur. Yetki vardır ama hata hâlinde geri dönüş bulunmaz. GBO’nun davranış sözleşmesi bu nedenle tek bir dosya değildir. Birbirini tamamlayan bir sistemdir.

Davranış sözleşmesinin çekirdek modeli

Basit biçimde:

DOĞRU AJAN DAVRANIŞI İÇİN TEMEL KOŞULLAR:

DOĞRU KİMLİK

VE GERÇEK YETENEK

VE DOĞRULANMIŞ UYGUNLUK

VE GEÇERLİ YETKİ

VE SORUMLU TOPARLANMA

Bu bir puan ortalaması değildir. Kimlik zayıfsa güçlü yetenek yeterli değildir. Uygunluk yoksa marka otoritesi yeterli değildir. Yetki yoksa olumlu sonuç ihtimali yeterli değildir. Toparlanma yoksa yüksek performans yeterli değildir. Kritik kapıların her biri geçilmelidir.

İnsan neden hâlâ merkezde?

Çünkü zarar yalnız sistem durumunda yaşanmaz.

İnsanların:

• parası,
• zamanı,
• itibarı,
• mahremiyeti,
• fırsatları,
• kimliği,
• güveni

etkilenir. Bir makine teknik olarak eski duruma dönebilir. İnsan aynı kolaylıkla eski durumuna dönmeyebilir. Bu nedenle toparlanmanın son sözü yalnız sistem metriği olamaz. Etkilenen insanın durumu da değerlendirilmelidir.

Bir şey yanlış gittiğinde doğru cümle

Güvenilir bir ajan şu cümleyi kurabilmelidir: “Planlanan davranıştan sapma tespit ettim. Yeni gönderimlerin durduğunu doğruladım; dış sistemde başlamış iki işlemin durumunu hâlâ kontrol ediyorum. Etkilenen kayıtlar bunlar. Geri döndürülebilen bölümler için plan hazır; diğer etkiler insan incelemesi ve telafi gerektiriyor.”

Bu cümle: “Bir hata oluştu.” cümlesinden çok daha değerlidir. Çünkü sorunu, davranışı ve sorumluluğu birlikte gösterir.

Bölümün hükmü

Bir sistemin güçlü olması, yalnız doğru eylemleri hızla gerçekleştirmesi değildir.

Güçlü sistem:

• yanlışlığı fark eder,
• devam eden zararı durdurur,
• etki alanını küçültür,
• son güvenli duruma döner,
• başarı iddiasını bağımsız biçimde doğrular,
• kanıtı korur,
• insanı bilgilendirir,
• itiraza izin verir,
• zararı telafi etmeye çalışır,
• davranış sözleşmesini günceller.

Hatasızlık yalnız bir vaatle sağlanmaz. Toparlanabilirlik ise tasarlanabilir bir yetenektir.

GBO şu nedenle yalnız optimizasyon alanı değildir: Davranışı artırmak değil, davranışı sorumlu hâle getirmek ister. Bir ajan doğru kişiyi bulabilir. Gerçek yeteneği anlayabilir. Uygun seçimi yapabilir. Geçerli yetkiyle eyleme geçebilir. Yine de işler yanlış gidebilir. Bu gerçek, sistemi başarısız yapmaz. Fakat toparlanma yolu yoksa sistemi güvenilmez yapar.

NOMOS Geri Dönüş ve Telafi Sözleşmesi bu nedenle şunu söyler: Her önemli eylem, yalnız başarı planıyla değil; durdurma, geri dönüş, itiraz ve telafi planıyla birlikte tasarlanmalıdır.

İkinci kısmın sonunda artık davranış sözleşmesinin bütün çekirdeğine sahibiz:

Kimlik olmadan doğru muhatap yoktur. Yetenek olmadan gerçek vaat yoktur. Uygunluk olmadan doğru seçim yoktur. Yetki olmadan meşru eylem yoktur. Toparlanma olmadan sürdürülebilir güven yoktur.

Fakat bu sözleşmeler yalnız kitapta kalırsa dünya değişmez. Şirketlerin, kurumların, ürünlerin ve ajan sistemlerinin bu sözleşmeleri günlük çalışma düzenine dönüştürmesi gerekir. Bir sonraki kısımda artık kavramı açıklamaktan uygulamaya geçeceğiz.

İlk sorumuz şu olacak:

Bir kurum ajanlara nasıl hazır hâle gelir?

Çünkü ajanlara hazır olmak, yalnız bir API yayımlamak veya web sitesine “AI-ready” etiketi koymak değildir.

Ajanlara hazır kurum:

• kimliğini çözmüş,
• yeteneklerini sınırlandırmış,
• uygunluk koşullarını açıklamış,
• yetki haritasını kurmuş,
• hataya karşı toparlanma yolunu test etmiş

kurumdur.

Bir makineye işlem kanalı açmak, o işlemi sorumlu hâle getirmez. Doğru yetki, denetim ve geri dönüş sınırları kurumsal bir tasarım gerektirir.