Yapay zeka projelerinde tekrar eden bir sıra var. Önce bir pilot yapılır, sonuçlar iyi çıkar, sunum yapılır. Sunumdan sonra bilgi güvenliği ya da hukuk ekibinden bir soru gelir: bu veriler nerede işleniyor?
Cevap "yurt dışındaki bir serviste" olduğunda proje çoğu zaman başa döner. Kaybedilen sadece zaman değil; pilotta çıkan sonuçlar da geçerliliğini yitirir, çünkü mimari değişir.
Bu yüzden kurulum modeli kararı projenin sonunda değil başında verilmelidir ve bu karar teknik ekibin tek başına vereceği bir karar değildir.
Üç model, üç farklı sorumluluk dağılımı
Pratikte üç kurulum modeli var ve aralarındaki fark yalnızca sunucunun yeri değil, kimin neyi işlettiği.
Global SaaS. Platform, yurt dışındaki bulut ve GPU kaynakları üzerinde çalışır. En hızlı devreye alınan modeldir, kapasite ihtiyaca göre anında ölçeklenir ve altyapı işletme yükü kurumda değildir.
Local SaaS. Veriler Türkiye sınırları içinde işlenir ve saklanır. Altyapıyı hizmet sağlayıcı işletir, kurum yalnızca kullanır. Yurt dışına aktarım sorusu ortadan kalkar, işletme yükü kurumda oluşmaz.
Onpremise. Platform tamamen kurumun kendi veri merkezinde, kendi donanımı üzerinde çalışır. Veri kurum ağından hiç çıkmaz. Buna karşılık yama yönetimi, izleme, yedekleme ve kapasite planlaması kuruma geçer.
Bu üç modelin karşılaştırmasını ürün sayfalarımızdaki kurulum bölümünde adım adım görebilirsiniz. Aşağıda kararın hangi girdilerle verildiğine odaklanacağız.
Hukuki çerçeve 2024'te değişti ve karar mantığı da değişti
Kurulum modeli tartışmalarında sık duyulan cümle şu: "Açık rıza alırız, sorun kalmaz." Bu cümle 1 Haziran 2024'ten beri eskisi kadar doğru değil.
6698 sayılı Kanun'un yurt dışına aktarımı düzenleyen 9. maddesi, 7499 sayılı Kanun ile değiştirildi ve değişiklik 1 Haziran 2024'te yürürlüğe girdi. Yeni yapı, açık rıza merkezli bir yaklaşımdan kademeli bir sistematiğe geçiyor: önce yeterlilik kararı, yoksa uygun güvenceler, o da yoksa istisnai haller (kvkk.gov.tr).
Kritik nokta üçüncü kademede. İstisnai haller, aralarında ilgili kişinin bilgilendirilerek verdiği açık rıza da bulunmak üzere, yalnızca arızi nitelikteki aktarımlar için geçerli. Yani düzenli, sürekli ve tekrarlanan aktarımlarda açık rızaya dayanmak öngörülen kullanım biçimi değil.
Bunun voicebot ve chatbot projelerindeki karşılığı doğrudan: her gün binlerce görüşmenin analiz için yurt dışına gönderilmesi, tanımı gereği düzenli ve sürekli bir aktarımdır. Bu akış için uygun bir güvence yöntemi kurulması gerekir. Standart sözleşme bu yöntemlerden biri ve imzalanmasından itibaren beş iş günü içinde Kuruma bildirilmesi gerekiyor. Bağlayıcı şirket kuralları ise grup şirketleri arasındaki aktarımlar için kullanılıyor.
Karar toplantısında sorulacak soru bu yüzden "açık rıza alabilir miyiz" değil, "bu aktarım için hangi güvence yöntemini kuracağız ve bunu kim yürütecek" olmalı.
Hangi verinin çıktığını gerçekten biliyor musunuz
Kurulum modeli tartışması genellikle "veri yurt dışına çıkıyor mu" sorusu etrafında döner ama hangi verinin çıktığı nadiren ayrıştırılır. Oysa bir voicebot akışında birbirinden çok farklı veri türleri dolaşır:
- Ham ses kaydı
- Konuşma metni (transkript)
- Metinden çıkarılan özet ve etiketler
- Müşteri kimlik bilgileri ve hesap verileri
- Sistem kayıtları ve metrikler
Bu türlerin hepsinin aynı yerde işlenmesi zorunlu değil. Kimlik bilgilerini maskeleyip yalnızca metnin analiz edilmesi, ya da hassas alanların çıkarılıp geri kalanın işlenmesi gibi tasarımlar mümkün. Bu tür veri minimizasyonu, bazı iş yüklerini daha esnek modellerde çalıştırmayı hukuken savunulabilir hale getirebilir.
Buradaki uyarı şu: maskeleme, doğru kurulmadığında yanıltıcı bir güvenlik hissi verir. Bir görüşmede müşteri adını, adresini ve sipariş numarasını söylüyorsa, sadece veritabanı alanlarını maskelemek yeterli olmaz; metnin kendisinde geçen kişisel veriler de ele alınmalıdır. Bu işin doğruluğu ölçülmeli, varsayılmamalıdır.
Teknik tarafta belirleyici olan iki başlık
Gecikme
Yurt dışındaki bir kaynakta işlem yapmak, ağ üzerinde ek gidiş-dönüş süresi demektir. Yazılı kanallarda bu fark genellikle fark edilmez. Sesli kanalda ise doğrudan konuşma kalitesine yansır, çünkü sesli asistanda bütçe zaten dardır. Bu konuyu gecikme bütçesi yazımızda ayrıntılı ele aldık.
Pratik sonuç: sesli iş yüklerinde yurt içi kaynak kullanmanın uyumdan bağımsız bir performans gerekçesi de vardır. Yazılı iş yüklerinde bu gerekçe çok daha zayıftır.
İşletme yükü
Onpremise kurulumun maliyeti donanımla bitmez. Kurumun üstlenmesi gereken kalemler şunlar: kapasite planlaması, sürüm güncellemeleri, güvenlik yamaları, izleme ve alarm, yedekleme ve felaket kurtarma, olay müdahalesi.
Bu kalemleri yürütecek ekip ve süreç yoksa, kapalı ağda çalışan bir sistem yönetilen bir kurulumdan daha savunmasız hale gelebilir. "Bizim veri merkezimizde olduğu için güvenli" cümlesi, güncellenmemiş bir bileşen için geçerli değildir.
Bu yüzden karar verirken sorulması gereken soru "hangisi daha güvenli" değil, "hangi güvenlik sorumluluğunu hangi ekip taşıyacak" olmalı.
Tek bir model seçmek zorunda değilsiniz
Kurumların çoğu bu kararı tekil bir seçim olarak ele alıyor. Oysa iş yükleri birbirinden çok farklı hassasiyet seviyelerinde.
Aynı kurumda şu dağılım oldukça sık görülüyor: kamuya açık ürün sorularını yanıtlayan chatbot yönetilen bir kurulumda çalışıyor, çünkü işlediği veri zaten kamuya açık. İK asistanı ve iç mevzuat asistanı ise kurum ağı içinde çalışıyor, çünkü çalışan verisi ve iç dokümanlar dışarı çıkmamalı.
Bu ayrımı yapmak, her şeyi en katı gereksinime göre kurmaktan hem daha ucuz hem de daha hızlı. Kurulum modeli kararını iş yükü bazında vermek, kurum bazında vermekten daha doğru bir yaklaşım.
Kilitlenme ve çıkış planı
Modeller arası geçiş yapabilmek, sözleşme aşamasında sorulması gereken bir konu. Sonradan sorulduğunda pazarlık gücü kalmıyor.
Netleştirilmesi gereken başlıklar:
- Bilgi tabanı, indeksler ve konuşma kayıtları hangi formatta dışa aktarılabiliyor
- Akış ve senaryo tanımları taşınabilir mi, yoksa platforma mı gömülü
- Model değiştiğinde mevcut değerlendirme setiyle karşılaştırma yapılabiliyor mu
- Sözleşme sonunda verilerin silinmesi nasıl kanıtlanıyor
Dördüncü madde KVKK açısından da önemli; imha yükümlülüğünün nasıl yerine getirileceği sözleşmede yazılı olmalı.
Karar sürecinin adımları
Kurumlarla yaptığımız çalışmalarda işleyen sıra şu:
- İş yükünü tanımlayın: hangi veri, hangi hacimde, hangi sıklıkta işlenecek
- Veri türlerini ayrıştırın: hangisi gerçekten dışarı çıkmak zorunda
- Aktarım varsa hangi kademede olduğunuzu belirleyin (yeterlilik kararı, uygun güvence, istisnai hal)
- Aktarımın düzenli mi arızi mi olduğunu netleştirin
- Gecikme gereksinimini ölçün, varsayımla ilerlemeyin
- İşletme yükünü kimin taşıyacağını yazılı olarak belirleyin
- Çıkış ve veri taşınabilirliği koşullarını sözleşmeye yazın
- Kararı, gerekçesiyle birlikte dokümante edin
Son madde denetim açısından belirleyici. Bir yıl sonra "bu neden böyle kurulmuş" sorusu geldiğinde, kararın kim tarafından ve hangi gerekçeyle alındığını gösteren bir kayıt olması gerekiyor. ISO/IEC 42001 gibi yapay zeka yönetim sistemi standartları da tam olarak bu tür kayıtları arıyor (iso.org).
Kurulum modellerini ve karar ağacını kendi senaryonuz üzerinden görmek için Voicebot Platformu, Chatbot Platformu ve API Platformu sayfalarındaki kurulum bölümlerine bakabilirsiniz.
Bu yazı genel bilgilendirme amaçlıdır, hukuki görüş yerine geçmez. Uygulama öncesinde kendi hukuk ekibinizle değerlendirme yapmanızı öneririz.
Kaynaklar
- Kişisel Verileri Koruma Kurumu, Yurt Dışına Aktarım. kvkk.gov.tr
- Kişisel Verileri Koruma Kurumu, Kişisel Verilerin Yurt Dışına Aktarılması Rehberi (Yayın No: 48). kvkk.gov.tr
- Kişisel Verileri Koruma Kurumu, Standart Sözleşme Bildirim Modülü Duyurusu. kvkk.gov.tr
- ISO/IEC 42001:2023, AI management system. iso.org