Chatbot verisini üçüncü taraf yapay zekâ sağlayıcısına göndermek ne demek?

💡 Özet: Ana Çıkarımlar

• Chatbot verisini kendi sisteminizde saklamamak, üçüncü taraf modele gönderilen veriyi ortadan kaldırmaz. Kullanıcı mesajı model sağlayıcısına gidiyorsa veri işleme ve çoğu durumda aktarım değerlendirmesi hâlâ gerekir.
• “Model eğitiminde kullanmıyoruz” vaadi tek başına yeterli değildir. Hukuki rol, işleme amacı, saklama süresi, alt işleyenler, güvenlik önlemleri, yurt dışı aktarım ve kullanıcı bilgilendirmesi ayrıca incelenmelidir.
• Maskeleme iyi bir kontrol olabilir; her zaman anonimleştirme değildir. Sohbet bağlamı kişiyi yeniden tanımlatabiliyorsa veri hâlâ kişisel veri sayılabilir.
• Sağlık, finans, çocuklar veya hassas talepler varsa eşik değişir. Aynı chatbot mimarisi otelde kabul edilebilirken sağlık turizminde çok daha ağır bir değerlendirme gerektirebilir.

Bir otelin web sitesindeki chatbotla konuşan misafir, önce oda tipini sorar. Sonra tarih verir. Ardından “eşimin glüten hassasiyeti var, kahvaltıda seçenek olur mu?” diye yazar. Bir sağlık turizmi şirketinin chatbotunda ise aynı yapı şu cümleyle karşılaşabilir: “Adım Ayşe, daha önce şu operasyonu geçirdim, fotoğraf gönderebilir miyim?”

Şirket kendi veritabanında bu konuşmaları hiç saklamıyor olabilir. Hatta kullanıcıya “mesajlarınızı sistemimizde tutmuyoruz” da diyebilir.

Bu cümle doğru olsa bile eksik kalır.

Çünkü chatbot cevabı üretmek için konuşmayı OpenAI, Anthropic, Gemini, bir Çin menşeli model servisi veya başka bir üçüncü taraf sağlayıcıya gönderiyorsa veri şirketin sisteminden çıkmıştır. Kullanıcının yazdığı ad, telefon, e-posta, rezervasyon bilgisi, seyahat planı, sağlık şikâyeti veya fotoğraf artık yalnız şirketin kendi uygulamasında değildir.

GDPR ve KVKK açısından mesele tam burada başlıyor: Veriyi saklayıp saklamadığınız da önemli. Fakat veriyi kendi sisteminizde saklamamanız, üçüncü taraf sağlayıcıya gönderdiğiniz gerçeğini ortadan kaldırmıyor. Verinin hangi amaçla, hangi sağlayıcıya, hangi koşullarda ve hangi korumalarla gönderildiği ayrıca değerlendirilmeli.

Bu yazı, AB Yapay Zekâ Yasası serisinin veri koruma halkası. Konu doğrudan AB Yapay Zekâ Yasası değil. Fakat önceki yazıda anlattığım gibi AB Yapay Zekâ Yasası açısından düşük riskli bir chatbot bile kişisel veri işlediğinde GDPR ve KVKK açısından ciddi sorular doğurabilir.

Önce veri akışını görün

Chatbot projesinde ilk hata genellikle model seçimiyle başlamak. Veri koruma tarafında da benzer bir hata var: “Hangi sağlayıcı daha güvenli?” sorusu, veri akışı çıkarılmadan erken kalıyor.

Önce konuşmanın nereden nereye gittiğini yazmak gerekir.

Kullanıcı hangi kanaldan geliyor? Web sitesi, landing page, WhatsApp, Instagram DM veya çağrı merkezi ekranı aynı şey değil. Mesaj önce şirketin sunucusuna mı düşüyor? Arada CRM, canlı destek aracı, otomasyon platformu veya mesajlaşma sağlayıcısı var mı? Sonra hangi model API'sine gidiyor? Model cevabı nerede loglanıyor? Hata ayıklama, kalite kontrol, güvenlik veya kötüye kullanım incelemesi için kimler erişebiliyor?

Bu harita olmadan “GDPR uyumluyuz” cümlesi boş kalır.

GDPR'ın temel ilkeleri hukuka uygunluk, şeffaflık, amaçla sınırlılık, veri minimizasyonu, doğruluk, saklama sınırlaması, güvenlik ve hesap verebilirlik üzerine kurulu. Bunlar yalnız veritabanında tutulan kayıtlar için değil, işleme faaliyeti için geçerli.

KVKK tarafında da kişisel verilerin belirli, açık ve meşru amaçlarla işlenmesi, işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olması, ilgili mevzuatta öngörülen veya işlendikleri amaç için gerekli olan süre kadar muhafaza edilmesi gerekir. Üretken yapay zekâya ilişkin KVKK rehberi de veri sorumlularının yaşam döngüsü boyunca bu riskleri dikkate alması gerektiğini vurguluyor.

Pratik karşılığı şu: Chatbotun cevap verebilmesi için gerçekten hangi bilgiye ihtiyacı var? Kullanıcının yazdığı her şey modele gitmek zorunda mı? Sistem cevabı üretmek için rezervasyon numarasını, telefonun tamamını veya tıbbi geçmişi aynen kullanmalı mı? Bu sorular ürün tasarımının parçasıdır.

Model sağlayıcısı hangi rolde?

GDPR'da şirketin kişisel verinin amaçlarını ve araçlarını belirlediği yerde veri sorumlusu, onun adına işleme yapan taraf ise veri işleyen olabilir. İki taraf birlikte amaç ve araç belirliyorsa ortak sorumluluk gündeme gelebilir. KVKK'da da veri sorumlusu ve veri işleyen ayrımı benzer işletme sonucunu doğurur.

Bir şirket kendi müşterilerine hizmet vermek için model API'si kullanıyorsa çoğu pratik senaryoda şirket, chatbot hizmetinin amacını belirleyen taraftır. Model sağlayıcısı ise sözleşmeye, ürüne ve veri kullanım şartlarına göre veri işleyen konumunda olabilir.

Fakat bunu varsaymak yetmez. Sözleşme ve ürün ayarları okunmalıdır.

31 Ağustos 2026 itibarıyla OpenAI, kurumsal ve API verileri için varsayılan olarak müşteri verisini model eğitimi amacıyla kullanmadığını söylüyor. API girdileri ve çıktıları için, belirli istisnalar dışında, 30 güne kadar saklama ile uygun müşteriler için sıfır veri saklama seçeneğini açıklıyor.

Anthropic de ticari ürünler ve API için varsayılan olarak girdileri ve çıktıları model eğitiminde kullanmadığını belirtiyor. Claude API saklama dokümanı, sıfır veri saklama ile özellik ve model bazlı istisnaları ayrıca listeliyor.

Bu bilgiler değerli. Fakat iki şeyi tek başına çözmez.

Birincisi, sağlayıcının eğitimde kullanmaması verinin hiç işlenmediği anlamına gelmez. Güvenlik sınıflandırması, kötüye kullanım tespiti, teknik işletim, hata inceleme, destek veya yasal yükümlülükler için sınırlı işleme ve saklama olabilir.

İkincisi, her ürün ve her özellik aynı veri rejimine tabi olmayabilir. Chat arayüzü, API, dosya yükleme, batch işleme, araç kullanımı, kod çalıştırma, arama entegrasyonu veya fine-tuning aynı saklama ve erişim sonuçlarını doğurmayabilir.

Bu yüzden “OpenAI kullanıyoruz” veya “Anthropic kullanıyoruz” tek başına uyum bilgisi değildir. Hangi ürün, hangi sözleşme, hangi ayar, hangi endpoint, hangi bölgede işleme ve hangi veri kategorisi soruları cevaplanmalıdır.

Maskeleme anonimleştirme değildir

Kişisel veri göndermemek en temiz çözümdür. Fakat chatbotlarda bu her zaman kolay değil.

Kullanıcı adını yazar. Telefonunu verir. Otel örneğinde uçuş saatini, çocuklarının yaşını veya alerji bilgisini paylaşabilir. Sağlık turizminde daha da ileri gider: hastalık geçmişi, fotoğraf, ilaç, ameliyat bilgisi, doktor raporu, şikâyet ve beklenti aynı sohbet içinde gelebilir.

Bu durumda üç ayrı kavramı karıştırmamak gerekir.

Anonimleştirme, verinin artık kişiyle ilişkilendirilemeyecek hâle gelmesidir. Bu seviye gerçekten sağlanıyorsa veri koruma rejiminin dışına çıkabilir. Fakat sohbet metninde çok sayıda bağlamsal ipucu varsa bunu başarmak zorlaşır.

Takma adlandırma, yani kimliği doğrudan gösteren parçaları ayırma veya değiştirme, GDPR'da bir güvenlik ve risk azaltma önlemi olarak önemlidir. Ama tek başına veriyi kişisel veri olmaktan çıkarmaz. Avrupa Veri Koruma Kurulunun takma adlandırma yaklaşımı, ek bilgi kullanılarak kişiyle yeniden ilişkilendirilebilen verinin kişisel veri olarak kaldığını hatırlatıyor.

Maskeleme ise pratik bir ürün kontrolüdür. “Ayşe Yılmaz” yerine “Müşteri 123”, telefonun tamamı yerine son dört hanesi, tam doğum tarihi yerine yaş aralığı, otel oda numarası yerine rezervasyon türü gönderilebilir. Bu, veri minimizasyonuna yardım eder. Yeniden tanımlama riskini ve veri ihlali etkisini azaltır.

Ama konuşmanın geri kalanı kişiyi tanıtıyorsa maskeleme anonimleştirme sayılmaz.

Örneğin “10 Eylül'de 2 gece kalacağım, saat 23.40'ta İstanbul'dan geleceğim, eşimin glüten hassasiyeti var” cümlesinde isim silinse bile rezervasyon sistemiyle eşleşme mümkün olabilir. Sağlık turizminde “üç yıl önce şu ameliyatı oldum, şu ülkeden geleceğim, şu doktora daha önce yazdım” gibi ifadeler kişiyi tanımlamaya yetebilir.

Bu nedenle maskeleme doğru soru değildir. Daha doğru soru şudur: Modelin işi yapması için hangi kişisel veri gerçekten gerekli ve gereksiz olanları sistematik olarak nasıl dışarıda bırakıyoruz?

Yerel bir modelle ön işlem yapmak işe yarar mı?

Evet, çoğu senaryoda işe yarayabilir. Fakat tek başına mucize değildir.

Şirket, üçüncü taraf sağlayıcıya göndermeden önce konuşmayı yerel bir model veya kural tabanlı bir katmandan geçirebilir. Bu katman ad, telefon, e-posta, kimlik numarası, rezervasyon numarası, sağlık terimleri veya fotoğraf gibi hassas parçaları yakalamaya çalışır. Sonra ana modele yalnız gerekli bağlamı gönderir.

Otel örneğinde modelin şu bilgiye ihtiyacı olabilir: “Misafir kahvaltıda glütensiz seçenek olup olmadığını soruyor.” Misafirin adı, telefonu ve rezervasyon kodu gerekmeyebilir.

Sağlık örneğinde ise durum daha zor. Bazı sağlık bilgileri cevabın kalitesi için gerekli olabilir. Hatta hasta adayı kendi kendine tanımlanabilir çok özel bir durum anlatabilir. Bu durumda yerel ön işlem yine faydalıdır; ancak “artık kişisel veri göndermiyoruz” demek riskli olur.

Yerel katmanın değeri üç yerde ortaya çıkar.

İlki, veri minimizasyonu. Ana modele yalnız gerekli bilgi gider.

İkincisi, politika uygulama. Çocuk verisi, ödeme bilgisi, kimlik numarası veya sağlık fotoğrafı gibi kategorilerde sohbet otomatik olarak durdurulabilir veya insana devredilebilir.

Üçüncüsü, kayıt kontrolü. Şirket hangi verinin dışarı çıkmadığını ve hangi durumda insan devrinin tetiklendiğini kanıtlayabilir.

Fakat bu katmanın kendisi de bir işleme faaliyetidir. Hata yapabilir. Kayıt tutabilir. Kişisel veriyi gözden kaçırabilir. Bu yüzden ürün mimarisinde bir mahremiyet geçidi olarak konumlandırılmalı ve test edilmelidir.

Yurt dışı aktarım sorusu kaçınılmaz olabilir

Üçüncü taraf model sağlayıcısı Türkiye veya AB dışında veri işliyorsa aktarım sorusu doğar.

GDPR'da üçüncü ülkelere veya uluslararası kuruluşlara kişisel veri aktarımı, GDPR Bölüm V şartlarına bağlıdır. Yeterlilik kararı, uygun güvenceler, standart sözleşme maddeleri ve gerekli durumlarda aktarım etki değerlendirmesi gibi araçlar gündeme gelir.

KVKK tarafında 1 Haziran 2024'te yürürlüğe giren değişiklikten sonra yurt dışına aktarım için yeterlilik kararı, uygun güvenceler, standart sözleşmeler, bağlayıcı şirket kuralları veya arızi hâller gibi daha ayrıntılı bir yapı var. Standart sözleşme yolu seçildiğinde sözleşmenin Kuruma beş iş günü içinde bildirilmesi de sürecin parçasıdır.

Bu noktada “sağlayıcı GDPR uyumlu” ifadesi yeterli değil. Şirket kendi aktarımının hukuki aracını, tarafların rolünü, veri kategorilerini, alt işleyenleri, teknik ve idari tedbirleri ve saklama süresini bilmek zorunda.

Bir de tedarik zinciri var. Model sağlayıcısı kendi altyapısını başka bulut sağlayıcılarında çalıştırabilir. Bazı özellikler farklı ülkelerde işlenebilir. Bazı ürünlerde veri yerleşimi veya bölge seçimi sunulabilir. Bazılarında sunulmayabilir.

Bu nedenle satın alma sorusu teknik özellik listesinden daha geniştir: Sağlayıcı, sizin veri koruma dosyanızı tamamlayacak bilgiyi ve sözleşmeyi verebiliyor mu?

Sağlık ve hassas veri eşiği başka

Otel chatbotu ile sağlık turizmi chatbotunu aynı veri koruma düzeyinde ele almak doğru olmaz.

KVKK'ya göre sağlık verisi özel nitelikli kişisel veridir. Kurumun özel nitelikli kişisel veri açıklaması bu verilerin daha sıkı korunması gerektiğini ve sınırlı işleme şartlarına tabi olduğunu açıkça söylüyor. GDPR'da da sağlık verisi özel kategorili kişisel veri olarak daha ağır bir rejime bağlı.

Sağlık turizmi tarafında kişi çoğu zaman yalnız iletişim bilgisi vermiyor. Şikâyetini, fotoğrafını, geçmiş operasyonunu, ilaç kullanımını, beklentisini ve bazen psikolojik durumunu yazıyor. Bu bilgiler satış sürecinin parçası gibi görünse bile veri koruma açısından hafif veri değildir.

Bu yüzden sağlık chatbotunda şu kararlar baştan verilmelidir:

• Hangi noktada kullanıcı sağlık verisi paylaşmadan genel bilgi alabilir?
• Hangi noktada açık ve ayrı bilgilendirme gerekir?
• Hangi veri ana modele hiç gitmemeli?
• Fotoğraf, rapor ve tıbbi geçmiş gibi bilgiler hangi kanaldan alınmalı?
• Hangi cevaplar yalnız genel bilgilendirme sayılır, hangileri sağlık çalışanı değerlendirmesine devredilmelidir?
• Model sağlayıcısı özel nitelikli veri ve sağlık verisi için gerekli sözleşme, güvenlik ve aktarım şartlarını karşılayabiliyor mu?

Bu sorular yalnız hukuki risk için değil, iş kalitesi için de önemli. Yanlış yönlendirme, yanlış umut, eksik devir veya gereksiz veri toplama hasta adayının güvenini de zedeler.

Serinin sonraki yazısında sağlıkta yapay zekâyı bu nedenle ayrı ele alıyorum. Orada konu yalnız veri koruma değil; tıbbi cihaz sınırı, triyaj, teşhis, tedavi, insan gözetimi ve sağlık turizmi operasyonu.

Kullanıcıya ne söylemek gerekir?

Şeffaflık metni “Bu chatbot yapay zekâ kullanır” cümlesinden ibaret olmamalı.

Kullanıcı şu bilgileri makul biçimde anlayabilmeli: Mesajları kim işliyor, hangi amaçla işleniyor, üçüncü taraf sağlayıcıya gidip gitmediği, hangi veri kategorilerinin paylaşılmaması gerektiği, verinin ne kadar tutulduğu veya tutulmadığı, haklarını nasıl kullanacağı ve gerektiğinde insanla nasıl devam edeceği.

Bu metni chatbotun en altına sıkıştırmak çoğu zaman yeterli bir ürün davranışı değildir. Kullanıcı kişisel veya hassas bilgi yazmadan önce uyarı görmelidir. Sistem ödeme kartı, kimlik numarası, sağlık fotoğrafı veya çocuk verisi gibi alanlarda kullanıcıyı yönlendirmeli ve gerekirse sohbeti durdurmalıdır.

Burada iyi ürün tasarımı ile veri koruma aynı yere çıkar. Kullanıcının neyi kime anlattığını bilmesi, hem güven hem de kalite meselesidir.

Şirketin yapması gereken pratik kontrol listesi

Bir chatbot üçüncü taraf yapay zekâ sağlayıcısına bağlanmadan önce şu soruların yanıtlanması faydalı olur:

Bu tablo mükemmel bir hukuk dosyası değildir. Fakat gerçek sistemi görünür kılar.

Chatbot projelerinde en tehlikeli cümlelerden biri şu: “Biz veriyi saklamıyoruz.”

Belki gerçekten saklamıyorsunuz. Fakat kullanıcı mesajı üçüncü taraf modele gidiyorsa şirketin veri koruma sorusu bitmiş olmuyor. Sadece başka bir yere taşınıyor.

Daha doğru başlangıç cümlesi şu olur:

Bu konuşmada hangi veri dışarı çıkıyor, gerçekten çıkması gerekiyor mu ve bunu hangi kanıtla yönetiyoruz?

Bu yazı genel bilgilendirme amacı taşır; somut bir sistem veya şirket için hukuki görüş yerine geçmez.