1. Chatbot ve Voicebot Nedir? KVKK Açısından “Veri Toplama Yüzeyi” Olarak Bot
Chatbot; metin tabanlı, voicebot ise ses tabanlı konuşma arayüzüdür. KVKK açısından botu “kanal” değil, veri toplama yüzeyi olarak görmeniz gerekir: form yerine sohbet, çağrı merkezi yerine voice akışı… Bu yüzden bot tasarımında en kritik şey, botun kullanıcıdan neyi hangi noktada isteyeceğini ve bunu nereye kaydedeceğini önceden belirlemektir.
Chatbot ve voicebot tasarlarken KVKK açısından nelere dikkat etmeliyim?
Net cevap: botu minimum veri ile tasarla, hassas adımları güvenli kanala taşı, konuşma loglarını maskele/anonimleştir, 3rd party servislere giden veriyi sınırla ve her adımı log/audit ile denetlenebilir yap.
Mini örnek (otel)
Bot “rezervasyon teklifi” alırken sadece tarih aralığı ve kişi sayısını sorar; kimlik/iletişim gerekiyorsa güvenli form/üyelik ekranına yönlendirir.
☑ Mini Check
- •Botun amaçları net mi? (rezervasyon / SSS / destek)
- •Botun isteyeceği veri alanları whitelist şeklinde yazılı mı?
- •Hassas adımlar güvenli kanala taşınıyor mu?
- •Konuşmaların nerede saklandığı ve kimlerin eriştiği belli mi?
- •3rd party NLP servisi kullanılıyorsa veri paylaşımı sınırları tanımlı mı?
Ne yapmalıyım?
- • Bot amaçlarını ve “veri whitelist” listesini çıkarın.
- • Hassas işlemler için güvenli kanal akışını tasarlayın.
- • Bot log şemasını ve retention planını yazın.
- • Vendor/NLP servis envanterini ekleyin.
- • KVKK veri güvenliği sayfasıyla hizalayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
2. Bot Konuşmalarında Hangi Kişisel Veriler Risklidir? “Gereksiz İsteme” Kuralı
Bot konuşmalarında risk, iki yerden gelir: (1) botun sorduğu sorular, (2) kullanıcının serbest metinle kendi yazdığı bilgiler. Bu yüzden KVKK uyumlu bot tasarımında ilk kural gereksiz kişisel veri istememek ve serbest metni “PII mıknatısı” olarak yönetmektir.
Bot konuşmalarında hangi kişisel veriler risklidir?
Net cevap: isim/soyisim, e-posta, telefon, kimlik benzeri alanlar; rezervasyon/odaya bağlanan bilgiler; serbest metinde geçen sağlık/özel durum gibi hassas içerikler; ayrıca cihaz/oturum tanımlayıcıları ve konuşma metninin tamamı risk taşıyabilir.
Riskli veri örnekleri
- •İletişim: e-posta/telefon (özellikle WhatsApp/chat kanallarında)
- •Rezervasyon ilişkisi: rezervasyon no, oda no, kimlik doğrulama bilgileri
- •Serbest metin: “pasaport numaram…”, “sağlık durumum…” gibi kullanıcı beyanı
- •Voice: ses kaydı/konuşma transkripti (özellikle ham saklanırsa)
☑ Mini Check
- •Bot soru setinde e-posta/telefon “varsayılan” mı, gerçekten gerekli mi?
- •Serbest metin alanları kısıtlı mı (uzunluk/uyarı)?
- •Hassas veri uyarısı var mı (“kimlik/ödeme bilgisi yazmayın”)?
- •Voicebot transkriptleri maskeleme/redaction’dan geçiyor mu?
- •Konuşma metni training set’e otomatik giriyor mu? (risk!)
Ne yapmalıyım?
- • Bot soru setini “minimum veri”yle yeniden yazın (chatbot kvkk uyumlu tasarim).
- • Serbest metin alanlarını sınırlayın ve uyarı metni ekleyin.
- • Voicebot transkriptlerinde redaction/PII maskeleme uygulayın (voicebot konusma loglari kvkk).
- • Kimlik doğrulamayı bot içinde değil, güvenli kanalda yapın.
- • DSR/başvuru süreçleriyle uyumlu log tutun (DSR bağlantısı): https://dgtlface.com/tr/yazilim/blog/veri-sahibi-basvuru-sureci-icin-teknik-akis-ve-raporlama
3. KVKK’ya Uygun Soru Seti ve “Ne Yapmamalı?”lar: Güvenli Kanal Tasarımı
Bot, kullanıcıyı hızlandıran bir arayüzdür; ama kimlik doğrulama ve hassas işlem içeren adımlar bot içinde kontrolsüz kalırsa risk büyür. Bu yüzden bot tasarımında temel prensip: “hassas iş → güvenli kanal”. Güvenli kanal; doğrulanmış oturum, güvenli form, müşteri portalı veya kontrollü call center prosedürü olabilir.
Otel rezervasyon botu ve B2B destek botu için KVKK uyumlu akış nasıl olmalı?
Net cevap: bot “bilgi toplama ve yönlendirme” yapar; hassas doğrulama/işlem güvenli kanala taşınır; konuşma logları maskeleme+TTL ile tutulur; 3rd party servislere minimal veri gider.
“Yap / Yapma” prensipleri (özet)
- •Yap: tarih aralığı, kişi sayısı, konu seçimi gibi kimliksiz alanlarla ilerle
- •Yap: iletişim gerekiyorsa “güvenli form linki” ver
- •Yapma: kimlik/ödeme bilgisi iste
- •Yapma: ham konuşmayı debug için sınırsız sakla
- •Yapma: 3rd party NLP servise ham PII gönder
☑ Mini Check
- •Bot “hassas işlem” listesini biliyor mu? (rezervasyon iptali, ödeme, profil silme)
- •Bu işlemler için güvenli kanal yönlendirmesi var mı?
- •Bot konuşmasında PII tespit/maskeleme kuralı var mı?
- •Bot “ne yapmamalı” listesi ürün dokümanına girdi mi?
- •Call center/mesaj yönetimi süreçleriyle uyum var mı?
Ne yapmalıyım?
- • Hassas işlemler listesini çıkarın ve botu “yönlendirici” yapın.
- • Güvenli kanal UX’i tasarlayın (login, token, form).
- • Bot konuşma metninde PII redaction uygulayın.
- • Otel/B2B destek süreçleriyle bağlayın: https://dgtlface.com/tr/cagri-merkezi-hizmetleri ve https://dgtlface.com/tr/cagri-merkezi/mesaj-yonetimi
- • KVKK uyum hizmet sayfasıyla bağlayın: https://dgtlface.com/tr/yazilim/kvkk-uyum-hizmeti
4. “Yap / Yapma” Bot Tasarım İlkeleri
| İlke | Yap | Yapma | Teknik not |
|---|---|---|---|
| Veri minimizasyonu | Tarih aralığı, kişi sayısı, konu seçimi gibi minimum alanlarla ilerle | Gereksiz isim, telefon, e-posta veya kimlik bilgisi isteme | Diyalog veri whitelist’i önceden tanımlı olmalı |
| Hassas işlem | Doğrulanmış portal/form veya kontrollü kanala yönlendir | Ödeme, kimlik doğrulama veya kritik hesap işlemini kontrolsüz chat içinde yapma | Hassas işlem listesi ürün dokümanında tutulmalı |
| Serbest metin | Uzunluk sınırı ve hassas veri uyarısı kullan | Sınırsız serbest metni doğrudan kalıcı loglama | PII tespit/redaction katmanı uygulanmalı |
| Konuşma logları | Minimal log + redaction + TTL uygula | Ham konuşmaları süresiz saklama | Erişim RBAC + audit ile sınırlandırılmalı |
| NLP/AI vendor | Payload’u minimum alanlarla gönder | Ham PII içeren tüm konuşmayı varsayılan olarak paylaşma | Vendor veri akışı ve erişim modeli dokümante edilmeli |
| Training data | Temizlenmiş/pseudo dataset kullan | Ham production konuşmalarını otomatik training set’e alma | Training dataset ayrı politika ve erişim kontrolüne sahip olmalı |
5. Loglama, Eğitim ve Üçüncü Taraf NLP/AI Servisleri: Konuşma Log Hijyeni
Bot projelerinde “en sessiz risk”, konuşma loglarıdır. Destek ekipleri “kalite için”, ML ekipleri “eğitim için”, ürün ekipleri “iyileştirme için” log tutmak ister. Bu meşru; ama KVKK uyumu için log tasarımı “minimum veri + minimum süre + minimum erişim” prensibinde olmalıdır.
Konuşma loglarını nasıl saklamalı ve anonimleştirmeliyim?
Net cevap: log şemasını minimuma indir, PII redaction/maskeleme ekle, TTL/retention uygula, erişimi RBAC+audit ile kısıtla ve 3rd party NLP servisine giden payload’u sınırla.
Loglama için pratik tasarım
- •PII redaction: e-posta/telefon/isim maskele
- •Sampling: her konuşmayı değil, örneklemeyi logla
- •TTL/retention: loglar sonsuza kalmasın (180 gün döngüsüyle gözden geçir)
- •Access control: loglara erişim sınırlı ve loglanan olmalı
- •Training data: ham konuşma yerine temizlenmiş/pseudo dataset
☑ Mini Check
- •Konuşma loglarında ham PII tutulmuyor mu?
- •Redaction/maskeleme kuralı aktif mi?
- •Retention/TTL tanımlı mı? (Refresh: 180 gün)
- •Log erişimi RBAC ile kısıtlı ve audit’li mi?
- •3rd party NLP servislerine giden veri minimum mu ve dokümante mi?
Ne yapmalıyım?
- • Log şemasını yazın: hangi alanlar, neden var?
- • Redaction’ı zorunlu hale getirin (prod’da).
- • Retention/TTL ve erişim politikasını uygulayın.
- • 3rd party NLP/AI servisleri için payload minimizasyonu yapın.
- • KVKK veri güvenliğiyle bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
6. Otel Rezervasyon Botu ve B2B Destek Botu: KVKK Uyumlu Örnek Akışlar
Bu bölümde iki örnek akışla “tasarımın sahaya inişini” gösteriyoruz.
Otel rezervasyon/chat bot (örnek)
- •Bot, tarih aralığı + kişi sayısı + oda tipi gibi kimliksiz bilgi toplar
- •İletişim gerekiyorsa güvenli form/portal bağlantısı verir
- •Rezervasyon değiştirme/iptal gibi işlemleri “doğrulama kanalına” taşır
- •Loglar: PII redaction + TTL + erişim kısıtı
Mini örnek: “Otel rezervasyon chatbot kvkk riskleri” en çok ödeme/iptal ve konuşma loglarında çıkar; bu yüzden hassas adımlar güvenli kanala yönlendirilmelidir.
B2B destek/SSS bot (örnek)
- •Bot, konu seçimi ve ürün sürümü gibi kimliksiz bilgilerle triage yapar
- •Hesap/doğrulama gerekiyorsa ticket portalına yönlendirir
- •Serbest metin kısıtlı; hassas veri uyarısı var
- •Loglar: redaction + sampling + TTL; ticket ID üzerinden izlenebilirlik
Key Data Point (yumuşatılmış)
KVKK odaklı bot tasarımı yapan kurumlarda kullanıcı güveni ve şikâyet oranlarında olumlu etki görülürken; log ve veri saklama tarafında daha yönetilebilir bir risk profili oluşabiliyor.
☑ Mini Check
- •Otel botunda hassas işlemler güvenli kanala taşınıyor
- •B2B botunda serbest metin kontrolü ve uyarılar var
- •Konuşma logları redaction + TTL ile yönetiliyor
- •3rd party NLP servisi veri minimizasyonu ile kullanılıyor
- •180 gün refresh ve periyodik review planı var
Ne yapmalıyım?
- • Bot akışını “veri toplama noktaları” ile birlikte diyagramlayın.
- • Hassas adımlar için güvenli kanal UX’i tanımlayın.
- • Log hijyeni (redaction/TTL/RBAC) kurallarını standardize edin.
- • Vendor/NLP servis değerlendirmesini süreçleştirin.
- • İlgili iç linklerle birlikte yürütün: https://dgtlface.com/tr/cagri-merkezi-hizmetleri, https://dgtlface.com/tr/cagri-merkezi/mesaj-yonetimi, https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi, https://dgtlface.com/tr/yazilim/kvkk-uyum-hizmeti
Teknik not: Bot projelerinde kullanılan üçüncü taraf NLP/AI servislerinin veri işleme politikaları dikkatle okunmalı ve hukuk/KVKK ekibiyle değerlendirilmelidir. Bu içerik hukuki yorum değil, teknik/operasyonel tasarım rehberidir. Refresh cycle: 180 gün.
7. Chatbot/Voicebot Diyalog & Log KVKK Checklist Şablonunu İndir
Chatbot/Voicebot Diyalog & Log KVKK Checklist Şablonunu İndir — Yazılım / Bot KVKK (v1.0)
Bu asset, chatbot/voicebot projelerinde KVKK riskini azaltmak için diyalog tasarımı (minimum veri), hassas işlemleri güvenli kanala taşıma, konuşma loglarında maskeleme/anonim-pseudo stratejisi ve 3rd party NLP veri paylaşım sınırlarını tek checklist altında toplar. Otel rezervasyon botu ve B2B destek botu gibi senaryolarda hızlı uygulanabilir bir standart sunar.
Kim Kullanır?
Ürün + destek/rezervasyon + IT/BT + KVKK/uyum ekipleri.
Nasıl Kullanılır?
- Bot “veri whitelist”ini doldur (sorulacak/sorulmayacak alanlar).
- Hassas işlemleri güvenli kanala yönlendiren akışı işaretle.
- Log şeması, redaction/TTL ve vendor paylaşım sınırlarını yaz; 180 gün refresh ekle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Bot amaçları net (rezervasyon/SSS/destek)
- ▢ ✅ Diyalog veri whitelist hazır (sorulacak alanlar)
- ▢ ✅ Yasaklı alanlar listesi var (kimlik/ödeme vb.)
- ▢ ✅ Serbest metin limit + “hassas veri yazmayın” uyarısı var
- ▢ ✅ Hassas işlemler (iptal/ödeme/profil) güvenli kanala taşınıyor
- ▢ ✅ Kimlik doğrulama bot içinde yapılmıyor (güvenli kanal)
- ▢ ✅ Konuşma loglarında PII redaction aktif
- ▢ ✅ Log retention/TTL tanımlı
- ▢ ✅ Log erişimi RBAC + audit ile kısıtlı
- ▢ ✅ 3rd party NLP servisine giden payload minimal
- ▢ ✅ Vendor/panel erişimleri MFA ile korunuyor
- ▢ ✅ 180 gün refresh planı var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Bot diyaloglarını, veri toplama noktalarını, loglama ve 3rd party NLP entegrasyonlarını KVKK risk azaltma modeline göre değerlendirir.
Sık Sorulan Sorular
Chatbot ve voicebot tasarlarken KVKK açısından nelere dikkat etmeliyim?▾
Bot konuşmalarında hangi kişisel veriler risklidir?▾
Konuşma loglarını nasıl saklamalı ve anonimleştirmeliyim?▾
Otel rezervasyon botu ve B2B destek botu için KVKK uyumlu akış nasıl olmalı?▾
Üçüncü taraf NLP servisi kullanmak riski artırır mı?▾
En sık yapılan hata nedir?▾
İlgili İçerikler