Sapan Pandya, Kıdemli Yazılım Mühendisi ve IEEE Kıdemli Üyesi – Röportaj Dizisi

Sapan Pandya, New Jersey’de yaşayan, dayanıklı dağıtık işlem sistemlerinde on yılı aşkın deneyime sahip bir Kıdemli Yazılım Mühendisi ve IEEE Kıdemli Üyesidir. Çalışmaları; işlem bütünlüğü, yazılım ile fiziksel cihazların entegrasyonu, üretim ortamlarında sorun giderme ve düzenlemelere tabi ortamlarda dağıtım doğrulama konularını kapsıyor. Stevens Institute of Technology’den Bilgisayar Bilimleri alanında yüksek lisans derecesine sahip olan Pandya, akademik çalışmaları değerlendirme ve teknik araştırmalara da katkıda bulunuyor.

Pandya’nın araştırmaları kiosk siber güvenliği, uç yapay zekâ ve yapay zekâ destekli güvenilirlik mühendisliğine odaklanıyor. Üretim ortamındaki deneyimi ise kanıta, işlem sonuçlarına ve operasyonel hesap verebilirliğe verdiği önemi şekillendiriyor. Bu röportajda idempotentliği, çelişen işlem kayıtlarını, kurtarma sistemlerindeki belirsizliği ve yapay zekâ ajanlarının kritik görevler için kullanılan altyapılarda harekete geçmesinden önce gerekli olan denetimleri ele alıyor. Uygulamalı mühendislik deneyimini, literatür analiziyle ve kontrollü ya da sentetik testlerle yürütülen araştırmalardan ayrı tutuyor.

Kariyeriniz boyunca yazılım güvenilirliğine ve dağıtık işlem sistemlerine odaklandınız. Bu deneyim, güvenilirliğe bakışınızı nasıl şekillendirdi ve karmaşık sistemleri yönetmek için yapay zekâ kullanma konusundaki görüşlerinizi hangi zorluklar etkiledi?

Bakış açım, bir bileşenin çalışıp çalışmadığını sorgulamaktan müşterinin işleminin tamamlanıp tamamlanmadığını ve hesabının verilip verilemeyeceğini sorgulamaya doğru değişti.

Kariyerimin ilk dönemlerinde odağım büyük ölçüde uygulamanın davranışıydı: girdileri doğrulamak, yanıtları işlemek ve arayüzün amaçlanan iş akışını izlediğinden emin olmak. Sorumluluklarım sistem entegrasyonu, üretim ortamlarında sorun giderme ve dağıtım doğrulama alanlarına yayıldıkça tek tek bileşenlerin ötesine bakmam gerekti.

Bir hizmet işini tamamlamışken başka bir hizmet hâlâ onay bekliyor olabilir. Yazılım bir işlemi başarılı olarak kaydederken fiziksel bir cihaz beklenen sonucu sağlayamayabilir. Her bileşenin testleri geçmesi, tek başına etkileşimin tamamının doğru işleyeceğini göstermez.

Bu deneyim, sistemler arasındaki sınırlara özellikle ilgi duymamı sağladı. Her bileşen ne biliyor? Neyi varsayıyor? Bu varsayımlar artık geçerli olmadığında ne oluyor?

Bu deneyim, yapay zekâya bakışımı da şekillendiriyor. Mühendislerin kanıtları bir araya getirmesine, örüntüleri fark etmesine ve arızaları daha hızlı incelemesine yardımcı olmanın gerçek bir değeri var. Ancak muhtemelen ne olduğunu açıklamakla gerçekte ne olduğuna dair doğrulanmış bir kayıt sunmak aynı şey değil.

Yapay zekânın, bir sorunu çözmek için gereken kanıt standardını düşürmeden sorunu inceleme yükünü azaltmasını istiyorum.

Teknik açıdan doğru kodun her zaman doğru işlem sonuçlarını garanti etmediğini vurguladınız. Zaman aşımı nedeniyle başarısız olmuş gibi görünen, ancak aslında tamamlanmış bir işleme dair somut bir örnek verebilir misiniz? Sistem işlemi otomatik olarak yeniden denediğinde ne gibi sorunlar çıkabilir ve mühendisler yinelenen işlemleri nasıl önlemeli?

Varsayımsal olarak 50 dolarlık bir ödemeyi ele alalım. Uygulama bir istek gönderir, ödeme hizmeti işlemi başarıyla kaydeder, ancak yanıt uygulamaya ulaşmadan kaybolur.

Ödeme yapılmış olmasına rağmen müşteri bir zaman aşımı mesajı görür. Uygulama yeni bir ödeme isteği gönderirse müşteriden ikinci kez ödeme alınabilir.

Zaman aşımı, yanıtın zamanında ulaşmadığını gösterir. Altta yatan işlemin başarılı olup olmadığını göstermez.

Yaygın güvenlik önlemlerinden biri idempotentliktir: aynı mantıksal isteğin, yeni bir mali etki yaratmadan yinelenebilmesini sağlamak. Uygulama, yeniden denemeler boyunca işlem tanımlayıcısını korur; isteği alan hizmet de bunu yeni bir satın alma işlemi olarak değil, ilk isteğin tekrarı olarak tanır.

Önemli olan yalnızca bir tanımlayıcı eklemek değildir. Hizmet, bu tanımlayıcıyı uygulamalı ve tamamlanmış bir işlemi hâlâ sürmekte olan bir işlemden ayırt etmeye yetecek bilgiyi saklamalıdır. Tanımlayıcı, onu dikkate almayan sonraki bir eylemi koruyamaz.

Sonuç belirsiz kaldığında kurtarma süreci, hemen yeni bir işlem başlatmak yerine mevcut işlemi kontrol etmeli ve ilgili kayıtları mutabık hâle getirmelidir.

Yeniden deneme sayısını da sınırlar, otomatik kurtarma işleminin sonucu belirleyemediği durumlarda ne olacağını tanımlardım. Müşteriye, tekrar tekrar ücret yansıtılması ya da sonsuza dek süren bir işlem ekranı yerine açık bir beklemede durumu ve çözüme ulaşabileceği bir yol sunulmalı.

Dağıtık sistemlerde bir veritabanı, arka uç hizmeti ve fiziksel kiosk aynı işlem hakkında birbiriyle çelişen bilgiler verebilir. Üretim ortamında bu tür tutarsızlıklarla karşılaştınız mı? Karşılaştıysanız bunlar nasıl incelenip çözüldü? Bu çelişen kayıtları uzlaştırmada yapay zekâ nasıl bir rol oynayabilir?

Evet, işlem durumlarındaki tutarsızlıkları incelemek üretim ortamındaki çalışmalarımın bir parçası oldu. Bir iş yeri olayını ele almadan bu konudaki yaklaşımı açıklamak için varsayımsal bir örnek kullanacağım.

Sıradan bir self servis ödeme noktasını düşünün. Ödeme hizmeti satın alma işleminin başarıyla gerçekleştiğini kaydeder, yazıcı fiş yazdırma işini kabul ettiğini bildirir ve ardından ekranda bir hata görüntülenir. Bu gözlemler, satın alma işleminin tümüyle başarısız olduğunu kanıtlamak yerine etkileşimin farklı aşamalarını anlatıyor olabilir.

Önce işlem kimliğini ve ilgili hizmet ile cihaz kayıtlarını kullanarak olayların sırasını yeniden oluştururdum. Ardından her bir gözlemin neyi kanıtladığını belirlerdim. Yazıcının bir işi kabul etmesi, fişin müşteriye ulaştığının kanıtı olmayabilir. Bir isteğin alınmış olması, mali etkisinin kayda geçirildiğini kanıtlamaz.

Çözüm, hangi aşamanın başarısız olduğuna bağlıdır. Yalnızca çıktı aşamasının ele alınması gerekiyorsa işlemin tamamını tekrarlamak uygun olmayabilir. Mevcut kanıtlar ne olduğunu ortaya koyamıyorsa, biri durumu araştırırken etkilenen işlem kontrol altında tutulmalıdır.

Kalıcı çözüm, yalnızca tek bir kaydı düzeltmekle kalmamalı, bu tutarsızlığın neden ortaya çıkabildiğini de ele almalıdır.

Yapay zekâ, olayları ilişkilendirmeye ve eksik bilgileri belirlemeye yardımcı olabilir. Ondan, birbiriyle yarışan açıklamaları ve her birini destekleyen kanıtları sunmasını isterdim. Yapay zekâ, en ikna edici görünen açıklamayı seçerek çelişkili kayıtlar arasında karar vermek yerine araştırmanın kapsamını daraltmaya yardımcı olmalıdır.

Yapay zekâ ajanları üretim ortamındaki olayları teşhis etmekten kurtarma eylemleri önermeye veya gerçekleştirmeye doğru ilerlerken, bir yapay zekâ sistemi işlemi yeniden deneyebilmeden, geri alabilmeden ya da değiştirebilmeden önce hangi güvenlik önlemleri alınmalıdır? İdempotency anahtarları, işlem günlükleri ve mutabakat mekanizmaları gibi deterministik kontroller, yapay zekânın ek arızalara yol açmasını nasıl önleyebilir?

Bir eylem önermeyi, o eyleme yetki vermekten ve onu gerçekleştirmekten ayrı tutardım.

Bir yapay zekâ ajanı işlemi yeniden denemeyi önerebilir; ancak bu yeniden denemeye izin verilip verilmeyeceğini ayrı bir kontrol belirlemelidir. Bu kontrol, işlemin mevcut durumunu, operasyonun kimliğini, ajanın izinlerini ve eylemin hangi koşullarda güvenli olduğunu denetlemelidir.

Bu kontrol yalnızca model olayı ilk incelediğinde değil, eylem gerçekleştirilirken de uygulanmalıdır. Bu arada başka bir süreç işlemi tamamlamış olabilir.

Ajanın erişebildiği araçların kapsamı da dar tutulmalıdır. İşlem durumunu sorgulama izni, ödemeyi geri alma veya bir finansal kaydı değiştirme izninden farklıdır. Ajan, tercih ettiği çözüm daha fazla erişim gerektiriyor diye kendi yetkisini genişletememelidir.

İdempotency, yinelenen etkileri sınırlar. Günlükler, araştırma için gereken geçmişi korur. Mutabakat, ilgili kayıtların birbiriyle uyuşup uyuşmadığını denetler. Bunların hiçbiri tek başına önerilen bir eylemin uygun olduğunu ortaya koymaz.

Kullanılan kanıtları, öneriyi, yetkilendirme kararını ve fiilî sonucu da kaydederdim. Böylece müdahale sonradan incelenebilir.

Bu kontroller, modelin dışında yer alan ve test edilebilen yazılımlar tarafından uygulanmalıdır. Ajanın dikkatli olmasını söyleyen talimatlar yararlı bir yönlendirme sağlar, ancak yetkilendirme mekanizması değildir.

Bir yapay zekâ izleme sisteminin görünürde bir işlem başarısızlığı tespit ettiğini ve işlemin otomatik olarak geri alınmasını önerdiğini düşünün. İşlem aslında başarılı olmuş, ancak onay gecikmişse bu müdahale yeni bir soruna yol açabilir. Mühendislik ekipleri, belirsizliği fark edebilen ve eksik bilgilere dayanarak düzeltici eylemlerde bulunmaktan kaçınan yapay zekâ destekli kurtarma sistemlerini nasıl tasarlamalıdır?

Sistemde gerçekten bir “sonuç bilinmiyor” durumu bulunmalıdır. Aksi hâlde eksik bilgiyi yanlış bir başarısızlık kararına dönüştürmesi muhtemeldir.

Onayın gecikmesi, işlemi otomatik olarak geri almak için değil, araştırma başlatmak için bir nedendir. İşlemi geri almak da kendi sonuçları olan başka bir finansal işlemdir. Bunun için bağımsız olarak doğrulanmış bir gerekçe ve uygun yetkilendirme gerekir.

Yanıtı iki ayrı yola ayırırdım. Araştırma yolu; durum bilgisini sorgulayabilir, eksik olayları toplayabilir, kayıtları karşılaştırabilir ve sorumlu ekibe bildirimde bulunabilir. Finansal işlem yolu ise koşullar karşılanana kadar engellenmiş durumda kalır.

Bu yaklaşım, yapay zekânın güven puanının işlem kanıtının yerini almasını önler. Bir model, eksik bilgilerden oluşturulmuş bir açıklamadan son derece emin olabilir.

Ayrıca belirlenmiş bir üst mercie taşıma noktası da olmalıdır. Bir işlemi süresiz olarak beklemede tutmak müşteri açısından kabul edilebilir bir sonuç değildir. Çözümlenmemiş durumun sorumluluğunu biri üstlenmeli ve bir sonraki güvenli adımı belirleyebilmesi için yeterli bağlama sahip olmalıdır.

Bu nedenle kurtarma süreci hem “Bu işlemi değiştirmeyi henüz gerekçelendiremiyorum” hem de “Çözüm için yapılması gerekenler şunlar” diyebilmelidir.

Belirsizliği fark etmek, ancak sistemin bu belirsizliği yönetmek için uygulanabilir bir yolu varsa işe yarar.

Otonom yapay zekâyla ilgili en önemli sorulardan biri, insan onayının hangi durumlarda hâlâ gerekli olduğunu belirlemektir. Sizce üretim ortamındaki hangi kurtarma işlemlerini yapay zekânın bağımsız olarak yürütmesine izin verilmeli, hangileri için her zaman insan onayı alınmalıdır? Finansal işlemler, mevzuata uyum veya müşteri güveni söz konusu olduğunda kuruluşlar bu sınırları nasıl belirlemelidir?

Sınırı, bir eylemin “yapay zekâ” olarak adlandırılıp adlandırılmadığına göre değil, yanlış olmasının doğuracağı sonuçlara göre çizerdim.

Salt okunur inceleme, ajanın yalnızca erişim yetkisi verilmiş bilgilere ulaşabilmesi koşuluyla, makul bir başlangıç noktasıdır. Ajan, temel işlemi değiştirmesine izin verilmeden tanılama kayıtlarını toplayabilir, ilgili uyarıları gruplandırabilir ve olay özetini hazırlayabilir.

Koşulları bağımsız olarak doğrulanabiliyor ve etkileri sınırlı kalıyorsa, önceden tanımlanmış bazı kurtarma prosedürleri de otomasyona uygun olabilir.

Önerilen müdahale onaylı bir prosedürün dışına çıkıyorsa, kayıtlar çelişiyor ve finansal sonuç hâlâ netleşmemişse ya da işlem güvenlik denetimlerini veya ajanın kendi izinlerini değiştirecekse insan onayı isterdim. Ajanın kendi kendine yetki vermemesi gereken kararlar bunlardır.

Bu, her rutin finansal işlem için bir kişinin onayının gerektiği anlamına gelmez. Yerleşik kurallara dayalı işleme, bir modelin olay sırasında kendi başına düzeltme uydurmasına izin vermekten farklıdır.

İnsan incelemesi de anlamlı olmalıdır. Onay ekranında dayanak kanıtlar, geriye kalan belirsizlik, beklenen etki ve mevcut alternatifler gösterilmelidir. Bu bağlamı sunmadan birinden kendinden emin bir paragrafı onaylamasını istemek pek koruma sağlamaz.

Bu sınırlar devreye almadan önce kararlaştırılmalıdır. Bir kesinti, otomatik bir sisteme ne kadar yetki verilmesi gerektiğine karar vermek için yanlış zamandır.

Hata toleranslı arka uç sistemleri, gözlemlenebilirlik araçları ve yazılım hizmetleriyle fiziksel donanım arasındaki entegrasyonlar üzerinde kapsamlı biçimde çalıştınız. Bir yapay zekâ ajanının üretim ortamındaki bir olayı güvenilir biçimde teşhis edebilmesi için ne tür telemetri verilerine ve kanıtlara ihtiyacı olur? Mühendislik ekipleri, yararlı yapay zekâ önerileriyle bir kesintiyi daha da kötüleştirebilecek, makul görünen ancak yanlış sonuçları nasıl ayırt edebilir?

İlgili sistemler boyunca müşterinin işlemini izlemeyi sağlayan kanıtlarla başlardım: işlem tanımlayıcıları, hizmet olayları, kalıcı durum değişiklikleri, cihaz yanıtları ve iletişim hataları.

Yazılım sürümleri ve yapılandırma değişiklikleri de önemlidir. Bir sürüm yayımlandıktan sonra başlayan bir arıza, inceleme yapan kişiye yararlı bir ipucu verir; ancak yalnızca zamanlama, nedenselliği kanıtlamaz.

Ajanın kanıtların sınırlarını da anlaması gerekir. Günlükler eksik olabilir, kayıtlar gecikmeli gelebilir ve saatler birbiriyle uyuşmayabilir. Bir onayın gelmemiş olması, hiçbir işlemin gerçekleşmediğinin kanıtı değildir.

Yararlı bir teşhis, gözlemleri yorumlardan ayırmalıdır. “İstemci bir zaman aşımı kaydetti” bir gözlemdir. “Arka uç kullanılamıyordu” ise ek kanıt gerektiren bir açıklamadır.

Bir önerinin, dayandığı kayıtları belirtmesini, bilinmeyen noktaları açıklamasını ve sonucunu doğrulamak ya da çürütmek için hangi ek kontrolün yapılması gerektiğini söylemesini beklerim.

Mühendisler, özellikle bir özet uzun veya çelişkili bir olay geçmişini sıkıştırarak aktarıyorsa, önemli sonuçlar doğurabilecek önerileri yalnızca ajanın özetine güvenmek yerine özgün kayıtlarla doğrulamalıdır.

Benim kullanacağım ölçüt basit: Başka bir mühendis kanıtları izleyip savunulabilir bir sonuca ulaşabiliyor mu? Açıklama bu sınamayı geçemiyorsa üretim ortamında bir değişikliğe yön vermeye hazır değildir.

Piyango ve bahis kiosklarında fidye yazılımlarına karşı dayanıklılık üzerine yayımlanmış araştırmanızda, 500 kiosku simüle eden sentetik bir ortam kullanarak yapay zekâ destekli bir güvenlik çerçevesini değerlendirdiniz. En önemli bulgular nelerdi ve okuyucular bu sonuçları yorumlarken hangi sınırlamaları göz önünde bulundurmalı? Önerilen mimariyi canlı bir üretim ortamında uygulamadan önce ne tür ek doğrulamalar yapılması gerekir?

Amacım, dayanıklılığı yalnızca tespit açısından değil; bir terminal ortamının saldırıyı nasıl sınırlayabileceği, fark edebileceği ve yaşananlara ilişkin kanıtları korurken nasıl kurtarılabileceği açısından da incelemekti.

Ortaya çıkan Resilient Security Framework; önleyici denetimleri, yapay zekâ destekli anomali tespitini ve tanımlanmış müdahale ve kurtarma mekanizmalarını bir araya getiriyordu. Yapay zekâ bileşeni, şüpheli davranışları tespit etmeye yönelikti. Bu çalışma, bir dil modeli ajanının finansal işlemleri bağımsız olarak değiştirmesine izin verilmesini inceleyen bir deney değildi.

Değerlendirmede, fiziksel 500 terminalin tamamında yapılan bir uygulama yerine, fidye yazılımı saldırılarının davranışsal olarak taklit edildiği ve 500 kiosku 72 saatlik bir simülasyon boyunca temsil eden sentetik bir ortam kullanıldı.

Çalışmada yalnızca antivirüs kullanılan temel senaryoyla karşılaştırıldığında, ortalama tespit süresi 52 dakikadan 31 dakikaya, ortalama kurtarma süresi ise 120 dakikadan 56 dakikaya düştü.

Bunlar, deney koşulları altında birleşik çerçeveyle elde edilen sonuçlardır. Yalnızca yapay zekâya atfedilmemeli veya canlı bir ortam için performans garantisi olarak değerlendirilmemelidir. Önemli bulgulardan biri, daha erken tespitin tek başına aynı düzeyde kurtarma iyileşmesi sağlamadığıydı. Saldırıyı sınırlama ve kurtarma tasarımı da önemliydi.

Sınırlamalar önemlidir. Simüle edilen iş yükleri, ağ koşulları, saldırı davranışları ve temel savunmalar her operasyonel ortamı temsil etmez. Farklı cihazlar ve uygulamalar için yeni doğrulamalar gerekir.

Üretimde kullanımdan önce temsili donanımlarda testler, bağımsız güvenlik değerlendirmesi, daha uzun süreli değerlendirmeler ve yanlış alarmların ve işlem yükünün dikkatle ölçülmesini isterdim.

Kurtarma sürecini meşru işlem faaliyetlerine karşı da test ederdim. Süreç tamamlanmış işlemleri muhasebeleştirmek için gereken bilgileri kaybediyorsa çalışan bir yazılım imajını geri yüklemek yeterli değildir.

Bu çalışma, daha ileri testler için bir temel sunuyor. Gerçek bir operasyonel ortamda güvenli davranış sergilendiğini göstermek ise ayrı bir adımdır.

Bakış açınız, yıllara dayanan üretim mühendisliği deneyimini yazılım güvenilirliği ve yapay zekâ odaklı güvenlik alanlarındaki akademik araştırmalarla bir araya getiriyor. Canlı üretim sistemlerinde bizzat uyguladığınız veya işlettiğiniz güvenilirlik mekanizmalarıyla araştırma ya da simüle edilmiş testler aracılığıyla incelediğiniz yaklaşımlar arasındaki farkı açıklayabilir misiniz? Yapay zekâ destekli kurtarma yeteneklerinden hangilerinin bugün zaten uygulanabilir, hangilerinin ise büyük ölçüde deneysel olduğunu düşünüyorsunuz?

Üretim çalışmalarım; yazılım geliştirme ve entegrasyonu, işlem doğrulama, sorun giderme, test ve sürüm doğrulamayı kapsadı.

Yayımlanmış araştırmalarım çalışmalarımın ayrı bir bölümünü oluşturuyor ve her araştırma, belirtilen yöntemleri ve sınırlamaları doğrultusunda değerlendirilmelidir.

Fidye yazılımı makalesi, önerilen bir güvenlik çerçevesini sentetik bir test ortamında değerlendiriyor. Uç yapay zekâ konulu makalem, cihaz üzerinde çalışan zekâ ve bunun işlem terminallerinde olası kullanımı üzerine literatüre dayalı bir analiz. IEEE FeedForward makalem ise izleme, üst kademeye iletme ve yedek davranış dâhil olmak üzere, yapay zekâ destekli bir güvenilirlik mimarisini kontrollü simülasyon yoluyla inceliyor.

Bu yayınların hiçbiri, canlı finansal işlemler üzerinde yetkisi olan otonom bir yapay zekâ ajanını devreye aldığımın kanıtı olarak değerlendirilmemelidir.

Pratik kullanımda mühendislerin inceleyebileceği desteklere öncelik verirdim: kaynak kayıtlarına bağlanan olay özetleri, uyarılar arasındaki korelasyonlar ve önerilen tanılama kontrolleri. Bunların yararlılığı yine de kullanılacakları ortamda ölçülmelidir.

Daha zor olan sorun, modelin öngörülmemiş koşullar altında değişiklikleri seçip uyguladığı açık uçlu kurtarmadır. Bunun için, yararlı bir tanılama önerisinden çok daha yüksek düzeyde kanıt gerekir.

Üretim deneyimimi ve araştırmalarımı birbirini tamamlayan çalışmalar olarak görüyorum: İlki, anladığım operasyonel sorunları ortaya koyarken ikincisi, doğrulama yoluyla yerini hak etmesi gereken yaklaşımları araştırıyor.

Geleceğe baktığımızda, yapay zekâ ajanları anormallikleri tespit etme, arızaları teşhis etme ve dağıtık sistemlerde kurtarma çalışmalarını koordine etme konusunda daha yetkin hâle geldikçe, otonom sistemlerle insan mühendisler arasındaki ilişkinin nasıl gelişeceğini öngörüyorsunuz? Kuruluşların görev açısından kritik üretim altyapısı üzerinde yapay zekâya daha fazla yetkiyi güvenle verebilmesi için hangi teknik güvenlik önlemleri, operasyonel kanıtlar ve hesap verebilirlik mekanizmaları gerekir?

Yapay zekânın olaylara ilişkin genel bir tablo oluşturma işinin daha büyük bir bölümünü üstleneceğini düşünüyorum. Mühendisler, bu bilgileri elle toplamak için çok zaman harcamak yerine; yararlı bir zaman çizelgesi, etkilenen bileşenler, birbiriyle yarışan açıklamalar ve eksik kanıtlarla çalışmaya başlayabilir.

Böylece insanlar, sistemin yükümlülüklerini ve sistemde değişiklik yapmanın sonuçlarını anlamayı gerektiren kararlara daha fazla zaman ayırabilir.

Uygulama yetkisini kademeli olarak artırırdım. Bir ajan önce gölge modunda çalışarak öneriler sunabilir, ancak bunları uygulamayabilir. Ekipler bu önerileri incelenmiş sonuçlarla karşılaştırabilir ve bilgi eksik, çelişkili veya güncelliğini yitirmiş olduğunda ajanın nasıl davrandığını test edebilir.

Değerlendirme; hatalı müdahaleleri, gözden kaçırılan sorunları, gereksiz üst kademeye iletmeyi ve ajanın kendi hatalarından kurtulmasını kapsamalıdır. Müdahale ekibini yanlış yöne sevk ediyorsa hızlı bir önerinin değeri yoktur.

Daha geniş yetkiler de koşullara bağlı olmalıdır. Bir model güncellemesi veya sistemdeki büyük bir değişiklik, önceki testleri geçersiz kılabilir. Ajanın davranışı artık gerekli standardı karşılamadığında ekiplerin yetkilerini azaltabilmesi veya geri alabilmesi gerekir.

Otomasyon geliştikçe insanların sorumluluğu ortadan kalkmaz. İşletim kurallarının, bir değişiklik için gereken kanıtların ve arızaları araştırma sürecinin sorumluluğunu birileri üstlenmelidir.

Mühendislerin bilgi toplamak için daha az, otomatik eylemin hangi koşullarda gerekçelendirilebileceğini tanımlamak, test etmek ve bu koşulları sürdürmek için daha fazla zaman harcayacağını düşünüyorum.

Harika röportaj için teşekkür ederiz. Dağıtık işlem güvenilirliği ve sorumlu yapay zekâ destekli kurtarma konusundaki çalışmalarını takip etmek isteyen okurlar, Sapan Pandya ile iletişime geçebilir.