Sektör Rehberi

Otel Yapay Zekâ Asistanı Güvenliği: Turizm ve Konaklama

Otel yapay zekâ asistanı güvenliği: rezervasyon ve kart verisi, çok dilli istem riski, sahte Booking.com oltalaması, misafir verisi ve sezon kontrolleri.

Otel yapay zekâ asistanı; rezervasyon, ödeme ve misafir verisini çok dilli bir sohbet akışında işler. Risk, bu verilerin aynı akışta toplanmasından ve asistanın dışarıdan gelen metinle yönlendirilebilmesinden doğar. Güvenli kurulumda kart verisi asistandan ayrılır, rezervasyon sorgusu kimlik doğrulamasına bağlanır, her dil ayrıca test edilir ve misafir mesajları ile yorumlar güvenilmez veri olarak işlenir.

Otel yapay zekâ asistanı nerede kullanılır ve risk nerede toplanır?

Turizm ve konaklamada yapay zekâ dört yerde yoğunlaşır: web sitesi ve mesajlaşma kanallarındaki rezervasyon asistanı, çok dilli misafir destek asistanı, oda içi sesli asistan ve personelin kullandığı iç asistan. İç asistan genellikle misafir e-postalarını özetler, yorumlara yanıt taslağı yazar ve rezervasyon platformlarından gelen mesajları sınıflandırır.

Her bileşenin farklı bir veri akışı vardır. Rezervasyon asistanı ad, iletişim ve tarih bilgisi görür. Destek asistanı geçmiş konaklamaları ve özel istekleri bilir. İç asistan ise tamamen dışarıdan yazılmış, doğrulanmamış metinle çalışır. Sezon yoğunluğunda hızla devreye alınan sistemlerde güvenlik testi çoğu zaman atlanır. Genel test yöntemi için kurumsal chatbot güvenlik testi rehberi uygulanabilir. Perakendedeki benzer asistan riskleri için perakende chatbot güvenlik testi yazısına, müşteri hizmetleri asistanlarının yoğun kullanıldığı başka bir sektörün tehdit haritası için telekom sektöründe yapay zekâ güvenliği yazısına bakabilirsiniz. Bu yazı otel ve konaklama işletmelerine özgü veri akışlarına odaklanır.

Rezervasyon ve kart verisi asistandan nasıl ayrılır?

Kart verisi asistanın dışında tutulur. Asistan misafiri ayrı bir ödeme sayfasına yönlendirir ve işlemin yalnızca sonucunu, örneğin "ödeme alındı" bilgisini görür. Böylece sohbet kaydı sızsa bile kart verisi içermez.

Kart güvenliği standardı da bu ayrımı destekler. PCI Security Standards Council'in sık sorulan sorular sayfasına göre PCI DSS'in 3.3.1 gereksinimi, kart doğrulama kodu dahil hassas kimlik doğrulama verisinin yetkilendirmeden sonra şifrelenmiş olsa bile saklanmasını yasaklar. Aynı sayfa, bu verinin yetkilendirmeden sonra dijital ses kayıtlarında tutulmasının da bu gereksinimi ihlal ettiğini belirtir. Telefon ve sesli asistan kanallarında bu nedenle kart doğrulama kodu gibi hassas doğrulama verisi kayda alınmamalı, alınamıyorsa yetkilendirmeden hemen sonra güvenli biçimde silinmelidir.

Misafirler kolaylık için kart numarasını sohbete yazabilir. Bu durumda arayüz kart benzeri girdiyi tanıyıp uyarmalı ve maskelemeli, kayıt katmanı da bu girdiyi saklamamalıdır.

Veri türüAsistan erişimiÖnerilen kontrol
Kart numarası ve güvenlik koduYokAyrı ödeme sayfası, girdide maskeleme, kayıtta silme
Kimlik bilgisiYok ya da maskeliResepsiyon sisteminde sınırlı erişim
Rezervasyon tarihleri ve oda tipiYalnızca doğrulanmış oturum sahibiTek kullanımlık kodla doğrulama
Özel istekler ve sağlık notlarıGerekliyse sınırlıSaklama süresi, erişim kaydı
Diğer misafirlerin kayıtlarıHiçbir koşuldaSunucu tarafında oturum yalıtımı

Rezervasyon numarası ve soyadı tek başına kimlik kanıtı sayılmamalıdır, çünkü bu bilgiler onay e-postalarında ve platform mesajlarında dolaşır. Kayıtlı e-postaya gönderilen tek kullanımlık bir kod, başkasının rezervasyonunu sorgulamayı zorlaştırır. Sohbet kayıtlarında maskeleme için KVKK ve kişisel veri maskeleme yazısına bakabilirsiniz.

Çok dilli asistanlar neden ek test gerektirir?

Turizm doğası gereği çok dilli çalışır. Aynı rezervasyon sorusu birkaç dilde gelir ve misafir tek bir cümlede iki dili karıştırabilir. Güvenlik önlemleri ise her dilde aynı güçte çalışmayabilir.

Zheng-Xin Yong, Cristina Menghini ve Stephen Bach'ın 2023 tarihli "Low-Resource Languages Jailbreak GPT-4" çalışması bu farkı ölçtü. Zararlı istekler düşük kaynaklı dillere çevrildiğinde GPT-4, AdvBench test setinde bu isteklerin yüzde 79'unda zararlı amaca yönelik uygulanabilir yanıt verdi. Yüksek ve orta kaynaklı dillerde başarı oranı belirgin biçimde daha düşüktü. Sonuç belirli bir model ve tarih içindir, ancak ilke geneldir: bir dilde test edilen kural, başka bir dilde aynı sonucu garanti etmez.

İkinci risk çeviridir. Model "ücretsiz iptal" koşulunu, otelin vermediği bir güvenceye çevirebilir. Bağlayıcı koşullar asistanın serbest çevirisinden değil, onaylı çevirilerden alınmalıdır.

Test için:

  1. Desteklediğiniz her dilde aynı saldırı ve politika sorusu setini çalıştırın.
  2. Bir cümlede iki dili karıştıran istekleri deneyin.
  3. Fiyat, iptal ve iade metinlerinin çevirisini insan gözüyle doğrulayın.
  4. Sonuçları dil bazında ayrı raporlayın.

Türkçe ile İngilizcenin karıştırıldığı istemlerin güvenlik etkisi için Türkçe İngilizce kod karıştırma yazısına bakabilirsiniz.

Sahte rezervasyon ve oltalama nasıl ortaya çıkar?

Konaklama sektöründe dolandırıcılık iki yönden gelir: misafiri hedef alan sahte ödeme mesajları ve personeli hedef alan sahte platform e-postaları.

Personel tarafının belgelenmiş bir örneği vardır. Microsoft Threat Intelligence'ın 13 Mart 2025 tarihli analizine göre Storm-1865 olarak izlenen grup, Aralık 2024'ten itibaren Booking.com'u taklit eden oltalama e-postalarıyla Kuzey Amerika, Okyanusya, Güney ve Güneydoğu Asya ile Avrupa'daki otelcilik kuruluşlarının çalışanlarını hedef aldı. E-postalar olumsuz misafir yorumu, olası misafir talebi, çevrim içi tanıtım fırsatı ve hesap doğrulama gibi konular kullanıyordu. Bağlantı, sahte bir doğrulama ekranı gösterip çalışana bir komut çalıştırtıyor ve finansal veri ile kimlik bilgisi çalan zararlı yazılımlar yüklüyordu. Microsoft, şüpheli mesajlarda sağlayıcıyla resmî kanaldan doğrudan iletişime geçilmesini ve oltalamaya dayanıklı çok faktörlü kimlik doğrulama kullanılmasını önerir.

Bu tablo yapay zekâ asistanları için bir uyarı taşır. Personelin iç asistanı aynı e-postaları özetliyorsa, e-postadaki metin asistan için de bir girdidir. İç asistanın bu içerikten sonra bağlantı açma, dosya indirme ya da komut önerme yetkisi olmamalıdır.

Sahte rezervasyon için izlenecek sinyaller:

  • Aynı cihazdan kısa sürede çok sayıda rezervasyon denemesi
  • Birbirine uzak ülkelerden aynı kartla gelen kayıtlar
  • Yeni hesaplardan gelen yüksek tutarlı ya da uzun süreli rezervasyonlar
  • Asistan üzerinden olağandışı sıklıkta iptal ve değişiklik talebi

Misafir mesajları ve yorumlar asistanı nasıl yönlendirebilir?

Yorumlar, platform mesajları ve misafir geri bildirim formları dışarıdan yazılır ve gizli talimat taşıyabilir. Asistan bu metni özetlerken içindeki bir cümleyi talimat sanabilir. OWASP'ın 2025 listesi bu riski, modelin web siteleri ve dosyalar gibi dış kaynaklardan aldığı içeriğin davranışını beklenmedik biçimde değiştirmesi olarak tanımlar.

Savunma basittir ama disiplin ister. Yorum özetleyen bileşen yalnızca metin üretir, hiçbir araç çağırmaz. Misafir mesajları sistem talimatlarından ayrı, açıkça işaretlenmiş veri olarak modele verilir. Yanıt taslaklarındaki bağlantılar izinli alan adlarıyla sınırlanır ve personel taslağı göndermeden önce onaylar.

Acenta ve kanal yöneticisi entegrasyonları da aynı kurala tabidir. Acentadan gelen rezervasyon notları ve özel istek alanları serbest metindir ve asistan bu metni okuyabilir. Entegrasyon verisini şemaya göre doğrulayın, serbest metin alanlarını veri olarak işaretleyin ve bu alanlardan gelen içerikle asistanın yetkisinin genişlemesine izin vermeyin. Her entegrasyon için ayrı ve dar yetkili bir erişim anahtarı kullanın. Aynı anahtarın asistanda, test ortamında ve acenta panelinde paylaşılması, tek bir sızıntının tüm zincire yayılmasına yol açar. Anahtarları düzenli olarak yenileyin ve kullanılmayan entegrasyonları kapatın.

Oda içi ve telefon asistanları hangi riskleri getirir?

Oda içi sesli asistan ışık ve sıcaklık gibi işleri yönetebilir. Oda servisi siparişi, hesaba ekleme ya da rezervasyon değişikliği yapabiliyorsa, yanlış duyulan bir komut maddi sonuç doğurur. Para etkili işlemler ek onay istemeli ve oda ile misafir kimliği eşleşmesi doğrulanmalıdır.

Misafir, odadaki cihazın ne zaman dinlediğini, kayıt tutulup tutulmadığını ve kayıtların ne kadar saklandığını bilmelidir. Check-out sonrası cihazdaki oturum, tercih ve konuşma verisi silinmelidir. Aksi halde sonraki misafir öncekinin bilgisine ulaşabilir.

Telefon hattında ses tek başına kimlik kanıtı sayılmamalıdır. Oda numarası ya da rezervasyon ayrıntısı vermeden önce kayıtlı iletişim bilgisi üzerinden ek doğrulama yapılmalıdır.

Sezon öncesi kontrol listesi

  1. Asistanın eriştiği veri alanlarını gözden geçirin, gereksizleri kaldırın.
  2. Ödeme akışının asistandan ve kayıtlardan ayrı olduğunu doğrulayın.
  3. Her desteklenen dilde saldırı ve politika testlerini çalıştırın.
  4. İç asistanın e-posta ve yorum okurken araç yetkisi olmadığını kontrol edin.
  5. Personele sahte platform e-postalarını tanıma ve resmî kanaldan doğrulama eğitimi verin.
  6. Check-out sonrası oda cihazı temizliğini test edin.
  7. İhlal durumunda kimin kime haber vereceğini yazın. Kişisel Verileri Koruma Kurulu'nun 2019/10 sayılı kararına göre ihlal, öğrenilmesinden itibaren en geç 72 saat içinde Kurul'a bildirilir.

Sık Sorulan Sorular

Otel asistanı kart bilgisini görmeli mi?

Görmemelidir. Kart numarası ve güvenlik kodu asistanın istemine, sohbet kayıtlarına ya da araç çağrılarına girmemelidir. Ödeme ayrı bir ödeme sayfasında yürütülmeli, asistan yalnızca işlemin sonucunu bilmelidir. PCI SSC, kart doğrulama kodunun yetkilendirmeden sonra şifrelenmiş olsa bile saklanamayacağını ve bu kuralın ses kayıtlarını da kapsadığını belirtir.

Çok dilli asistanlar neden ek risk taşır?

Güvenlik önlemleri her dilde aynı güçte çalışmayabilir. Yong, Menghini ve Bach'ın 2023 çalışmasında, zararlı istekler düşük kaynaklı dillere çevrildiğinde GPT-4 bu isteklerin yüzde 79'unda uygulanabilir yanıt verdi. Ayrıca çeviri, iptal ve iade koşullarını yanlış aktarabilir. Her desteklenen dil ayrı test edilmeli, bağlayıcı koşullar onaylı çeviriden alınmalıdır.

Otel personelini hedef alan sahte rezervasyon platformu e-postaları nasıl işler?

Microsoft'un Mart 2025'te yayımladığı analize göre Storm-1865 olarak izlenen grup, Aralık 2024'ten itibaren Booking.com'u taklit eden e-postalarla otelcilik çalışanlarını hedef aldı. E-postalar olumsuz misafir yorumu ya da hesap doğrulama gibi konular kullanıyor, sahte bir doğrulama ekranıyla çalışana komut çalıştırtıp kimlik bilgisi çalan zararlı yazılım yüklüyordu.

Misafir verisi asistana nasıl sunulmalı?

Yalnızca işin gerektirdiği alanlarla ve yalnızca kimliği doğrulanmış misafire ait kayıtla sunulmalıdır. Rezervasyon numarası ve soyadı tek başına yeterli kimlik kanıtı sayılmamalıdır, çünkü bu bilgiler e-postalarda dolaşır. Kayıtlı e-postaya gönderilen tek kullanımlık kod gibi ek bir adım ekleyin. Sohbet kayıtlarında kimlik, telefon ve kart benzeri verileri maskeleyin.

Misafir verisi sızarsa ne yapılmalı?

Sızıntının kapsamını belirleyin, erişimi kapatın ve kayıtları saklayın. Kişisel Verileri Koruma Kurulu'nun 2019/10 sayılı kararına göre ihlal, öğrenilmesinden itibaren en geç 72 saat içinde Kurul'a bildirilir. Etkilenen misafirlere de makul en kısa sürede bilgi verilir. Kart verisi etkilendiyse ödeme kuruluşunuzu da hemen bilgilendirin ve hukuk birimini sürece dahil edin.

Kaynaklar

İlgili Yazılar