AI washing nedir? Otel yazılımı demosunda gerçek özelliği etiketten ayırmak

AI washing, işi sabit bir kuralın, sıradan bir raporun ya da bir insanın yaptığı bir yazılımı yapay zekâ diye tanımlamaktır. Bu bir teknoloji sorunu değil, bir etiketleme sorunudur. Demoda iddiayı sınayın: girdiyi değiştirin, hata yapmasını isteyin ve durumunu yazılı olarak isteyin.

Demo ortasında sunucu, sistemin oda fiyatını yapay zekâ ile belirlediğini söyler ve üzerinde bir eğri olan bir slayt belirir. Salonda kimse bu eğri, satmadığınız bir oda tipiyle karşılaştığında ne olacağını sormaz; toplantı bir sonraki slayta geçer. Bu yazıyı okuduktan sonra o anda soracağınız sorular, on dakikada yapacağınız testler ve gördüğünüzü tek sayfada puanlama yöntemine sahip olacaksınız.

AI washing nedir? İyi çalışan bir kural neden sorun değildir?#

AI washing, bir ürünün yaptığı iş ile etiketinin söylediği arasındaki uçurumda yaşar: ekranda yapay zekâ yazarken, perdenin arkasında sabit bir kural, standart bir rapor ya da bir insan çalışır. Sorun kuralda değil, etikettedir.

Bir demo size üç farklı şey gösterebilir ve bunlardan yalnızca ikisi odaya sınanabilir. Birincisi çalışan yazılımdır: kendi verilerinizle karşılaştırabileceğiniz bir hesaplama yapar. İkincisi kuraldır: koşulu bir insan yazmıştır ve görmesini isteyebilirsiniz. Üçüncüsü, gelecekteki bir sürüme verilen sözdür ve henüz mevcut değildir.

Kural, çoğu zaman daha iyi bir mühendislik tercihidir. "On oda ve üzeri rezervasyon satış müdürüne gider" diyen bir kural her seferinde aynı davranır, bir insan okuyabilir ve yeni personele anlatılabilir. Basit bir kuralın bir modelden daha iyi yaptığı otel işleri vardır; orada ayrıntısını bulabilirsiniz.

Kuralın çalışma biçimi basittir: bir koşul, bir eşik ve bir eylem; hepsi bir insan tarafından yazılır, hepsi incelenebilir. Kural hata yaptığında hatayı bir koşula kadar izlersiniz. Model hata yaptığında elinizde çoğu zaman yalnızca yanlış sonuç kalır.

Yanlış etiketin maliyeti somuttur. Bir yetenek için bütçe ayırırsınız, iş gücünüzü ona göre planlarsınız ve bir kabul testi yazamazsınız, çünkü kimse size o şeyin ne yapması gerektiğini söylememiştir. Bir etikete dayanan satın alma, teslimatta doğrulanamaz.

Genel çerçevesiyle hukuki bir boyut da vardır. Ticari Reklam ve Haksız Ticari Uygulamalar Yönetmeliği'nin "ispat külfeti" başlıklı 9. maddesi, 4 Ocak 2017 tarihli ve 29938 sayılı Resmî Gazete ile yeniden düzenlendi. Maddeye göre reklam verenler, doğrulanabilir olgulara ilişkin tanımlama, iddia ve örnekli anlatımları bilimsel geçerliliği olan bilgi ve belgelerle kanıtlamak zorundadır; karşılaştırmalı reklamlarda karşılaştırılan iddialar her hâlükârda akredite veya bağımsız araştırma, test ve değerlendirme kuruluşlarından alınmış belgelerle kanıtlanır. Yürürlükteki metni ve olası değişiklikleri mevzuat.gov.tr'deki birleşik metinden (yeni sekmede açılır) kontrol edin ve kendi durumunuzu bir hukuk müşaviriyle teyit edin.

Kaç otel ürününde yanlış etiketli özellik bulunduğuna ilişkin kamuya açık bir sayı yoktur; bu yazı uygulamanın ne kadar yaygın olduğu konusunda iddia ileri sürmez.

Demodan önce odaya ne götürmelisiniz?#

Kendi işletmenizden on soru ve bir dağınık dosya getirin; sunucu konuşmadan önce beklediğiniz yanıtı yazın. Satıcının temiz örnek verisiyle yapılan demo, o örnek veri hakkında bilgi verir.

Soruları broşürden değil, geçen aydan alın: belirli bir oda tipinin bu gecelik fiyatı, belirli bir tarihte satılacak kalan oda sayısı, bir grup bloğundan kullanılan oda sayısı, bir hesabın neden düzeltildiği, kimlik bildirimi henüz yapılmamış rezervasyonlar, bir odanın kat hizmetlerinde bekleyen işleri, bir rezervasyon gelmediğinde ne olduğu, bölünmüş bir hesabın nasıl kapatıldığı, iadenin kayıtlarda nasıl göründüğü ve konaklama ortasında fiyat değiştiğinde sistemin ne gösterdiği.

Bir aylık rezervasyonlarınızı, düzenlemeden, gerçek sorunlarıyla birlikte dışa aktarın: iptal satırları, mükerrer misafir, Türkçe karakterler, boş sütunlar ve birinin hatalı yazdığı bir satır. Sunucunun sizin dosyanızı mı yoksa kendi dosyasını mı kullanacağını önceden, yazılı olarak sorun. Reddedilmesi de kaydedebileceğiniz bir yanıttır.

Her sorunun yanına beklediğiniz yanıtı toplantıdan önce yazın. Demo sırasında doğru, yanlış ya da gösterilmedi diye işaretlersiniz ve izlenimler üzerine tartışmayı bırakırsınız. Ekranı fiilen kullanacak kişiyi de getirin, yalnızca satın alanı değil; sunucunun atladığı adımları onlar fark eder.

Toplantıdan önce hangi şeyleri kanıt olarak kabul etmeyeceğinize karar verin: bir slayt, bir video, bir müşteri logosu ya da "diğer oteller" diye başlayan bir cümle.

Canlı mı kayıtlı mı: demonun gerçek olduğunu nasıl anlarsınız?#

Sunucudan girdiyi, senaryoda olmayan bir değerle, canlı olarak değiştirmesini isteyin. Bir kayıt, sizin yazdığınız bir değeri kabul edemez; senaryolaştırılmış bir yol da girdi tanıdık olmadığı anda çoğu zaman bozulur.

Hazırlanmış aralığın dışında bir tarih, satmadığınız bir oda tipi ya da Türkçe karakterli bir misafir adı isteyin ve ekranda ne olduğunu izleyin. Hikâyeyi değil mekanizmayı izleyin: sunucu mu yazıyor, yoksa ekran kendiliğinden mi ilerliyor? Bir şey hesaplanırken bir bekleme var mı, yoksa soru bitmeden yanıt mı geliyor?

Sistemin boş bir sonuçla ne yaptığını sorun. Kullanılmış bir yazılım bu soruya hızla yanıt verir; hazırlanmış bir yolun çoğu zaman yanıtı yoktur.

Tasarlanmış ama geliştirilmemiş bir özellik için kayıtlı bir anlatım meşrudur, öyle etiketlendiği sürece. Ancak bu, çalışan yazılımın kanıtı değildir. Kayıtta kimin olduğunu sorun: perdenin arkasında bir insan olması bir oteli yönetmenin geçerli bir yoludur, ama satın aldığınız bir özellik değildir. Sunucu girdi değişikliğini reddederse not alın ve geçin; o satır için sonucunuz elinizdedir.

Bir yapay zekâ özelliğini bilerek nasıl hataya zorlarsınız?#

Ona bilemeyeceği bir şey, reddetmesi gereken bir işlem verin, sonra son sayısının nereden geldiğini sorun. Çalışan bir sistem görünür biçimde hata yapar ve bunu söyler; bir etiket konuyu değiştirir.

Tesisinizde bulunmayan bir olanak, kapanmış bir restoran ya da envanteriniz dışındaki bir oda tipinin fiyatını sorun. Çalışan bir asistan bunun olmadığını söyler; bir kural ise yalnızca çalışmaz. Fiyat yüklenmemiş bir dönem ya da geçmişte bir tarih sorun; yanıtın bir red mi, boş bir durum mu, yoksa arkasında hiçbir şey olmayan kendinden emin bir sayı mı olduğuna bakın.

Sonra bir rezervasyonu iptal etmesini, para hareketi yapmasını ya da misafire mesaj göndermesini isteyin. Güvenlik seviyeleri olan bir sistem bir insanın onayını ister; olmayan bir sistem yapar ve asıl endişe verici olan budur. Ekrandaki sayının nereden geldiğini sorun: çalışan yazılım kayda ya da kurala işaret eder; senaryolaştırılmış demo sunucuya işaret eder.

Sonra neyin kayda geçtiğini sorun. Asistanın yaptıklarına ilişkin bir kayıt var mı, siz görebiliyor musunuz, geri alabiliyor musunuz, kaydı sonradan biri değiştirebiliyor mu? Sessizliği de veri sayın: bir testi çalıştırmak istemeyen sunucu, tek kelime etmeden o özelliğin durumunu size söylemiştir. Personel ya da misafir dokunmadan önce yapay zekâ asistanını nasıl test edeceğinizi anlatan yazıda bu soruları yanıtlandırabileceğiniz bir test planı bulabilirsiniz.

On dakikada yapabileceğiniz üç test#

Sözcükler ne anlama geliyor: yapay zekâ destekli, geliştirildi, tasarlandı, yakında?#

"Yapay zekâ destekli" bir durum bildirimi değildir, bir sıfattır. Yazılı olarak dört durumdan birini isteyin: otellerde kullanımda, geliştirildi ancak lansman öncesi, tasarlandı ya da planlanıyor.

Her durum alıcıya farklı bir şey söyler: onu şimdi sınayabilir misiniz, geçişi ona göre planlayabilir misiniz, yoksa bir tarih mi satın alıyorsunuz. Özelliğin hangi bölümünün model, hangi bölümünün kural olduğunu sorun ve sınırı ekranda göstermelerini isteyin. Bunu yanıtlayabilen satıcı kendi sistemini anlatıyor demektir; yanıtlayamayan bir kategoriyi anlatıyor demektir.

Kaydı sorun: sistem neyi kaydediyor, siz okuyabiliyor musunuz, hassas adımlarda bir insan onaylıyor mu, bir değişiklik geri alınabiliyor mu. İncelenemeyen bir özellik sonradan denetlenemez. Özellik yanlış olduğunda ne olacağını sorun: kural, hatayı bir koşula kadar izleyebileceğiniz biçimde yanlıştır; model ise yalnızca bir kayıtla yakalayabileceğiniz biçimde yanlıştır.

Bir yol haritası maddesi için imza atmayın, iş gücünüzü ona göre planlamayın. Gelirse o zaman, kendi verinizle, aynı üç testle sınarsınız. Yanıtı zaten kullandığınız sözleşme diline yerleştirin: iddia, durum sözcüğü ve satıcının verdiği tarih.

Demodan sonra gördüklerinizi nasıl puanlarsınız?#

Tek bir sayfa doldurun: her iddia için ne iddia edildiğini, gözlerinizle ne gördüğünüzü ve satıcının yazılı olarak vereceği durum sözcüğünü yazın. Geri gönderin ve düzeltmelerini isteyin.

Her iddiayı üç düzeyde puanlayın: sizin verinizle gösterildi, onların verisiyle gösterildi, yalnızca anlatıldı. Orta düzey değersiz değildir ama birincisiyle aynı değildir. On soruyu ve beklenen yanıtları aynı sayfada tutun ki puan, sunucunun üslubu hakkında değil, sizin işletmeniz hakkında olsun.

Sayfayı satıcıya gönderin ve yazılı düzeltme isteyin. Sayfayı düzelten satıcı size yararlı bir şey söylemiştir; görmezden gelen de bir şey söylemiştir. Gördüğünüz her satıcı için aynı sayfayı kullanın ki teklifler izlenimle değil, satır satır karşılaştırılabilsin. Sağlayıcıya önceden gönderilecek soru listesi ve teklifleri karşılaştırılabilir kılan bir ihtiyaç dosyası bu aşamada işinizi kolaylaştırır.

Satın alma kararını etiketleme kararından ayırın. Etiketi abartılmış bir ürünü, altındaki kural ihtiyacınız olan işi yapıyorsa yine satın alabilirsiniz. Sayfayı saklayın: özellik geldiğinde aynı üç test ve aynı on soruyla sınarsınız.

Şimdi ne yapmalı#

Bir sonraki demoya tek bir sayfa götürün: beklediğiniz yanıtlarla on sorunuz, kendi sisteminizden bir dağınık dışa aktarım ve iddia, gördüğüm, yazılı durum sözcüğü sütunları. Bu yazının bölümleri tek bir alışkanlık oluşturur: şeyin ne olduğunu adlandırın, çalıştığını görmek için girdiyi değiştirin, bir kez hataya zorlayın, sonra imzalamadan önce gördüğünüzü yazın. İyi çalışan bir kural iyi bir alışveriştir; test edemediğiniz bir etiket değildir.