Sağlık chatbot'u geliştirmenin zor kısmı dil modeli değil, ürününüzün hangi cümleyi kurduğunda tıbbi cihaz yazılımına dönüştüğünü bilmek. Sınır keskin: randevu alan, yol tarifi veren, hazırlık talimatı okuyan bir asistan mevzuat dışında; semptomu değerlendirip aciliyet sınıflandıran bir modül MDR Ek VIII Kural 11 kapsamına giriyor ve tipik olarak sınıf IIa'ya düşüyor. Bu tek karar, projenin maliyetini ve takvimini iki katına çıkarabiliyor. Aşağıda o sınırın nerede olduğu, KVKK tarafında 2024'te değişen rejim, ve hallüsinasyonu ürün seviyesinde sınırlamanın çalışan yolu var.
Önce sınırı çizin: hangi özellik sizi sınıflandırmaya sokuyor?
MDR (EU) 2017/745 md. 2(4) yazılımı aktif cihaz sayıyor. Sınıflandırmayı yapan Ek VIII Kural 11'in metni şöyle: teşhis veya tedavi amaçlı kararlar almak için kullanılan bilgi sağlamayı amaçlayan yazılım sınıf IIa; bu kararların etkisi ölüme veya geri döndürülemez sağlık bozulmasına yol açabiliyorsa sınıf III; ciddi bozulma veya cerrahi müdahale söz konusuysa sınıf IIb (bkz. MDR (EU) 2017/745, Ek VIII Kural 11). Türkiye'deki karşılığı 2 Haziran 2021 tarihli 31499 sayılı (1. Mükerrer) Resmî Gazete'de yayımlanan Tıbbi Cihaz Yönetmeliği; niteliklendirme için TİTCK, MDCG 2019-11 kılavuzunun Türkçe çevirisini yayımlamış durumda.
| Özellik | Sınıflandırma riski |
|---|---|
| Randevu alma, iptal, hatırlatma | Yok |
| Tetkik öncesi hazırlık talimatı okuma (aç karnına gelin, şu ilacı kesin) | Yok — kurumun yazdığı metni iletiyorsunuz |
| İlaç hatırlatma (dozu kullanıcı/hekim girmiş) | Düşük |
| Semptom değerlendirme, triyaj, aciliyet skoru | Yüksek — Kural 11 |
| Ölçüm yorumlama (kan şekeri yüksek, hekime başvurun) | Yüksek — Kural 11 |
| İlaç etkileşimi uyarısı | Yüksek |
Bir de ikinci katman var. MDR kapsamında sınıf IIa ve üzeri olup onaylanmış kuruluş değerlendirmesi gerektiren yapay zekâ içeren tıbbi cihaz yazılımları, AI Act'in 6(1). maddesi ve Ek I yoluyla yüksek riskli sayılıyor. Yani Kural 11 ile IIa'ya düşen bir chatbot, otomatik olarak AI Act'in yüksek risk rejimine de giriyor.
Takvim 2026'da değişti. (EU) 2024/1689 sayılı AI Act 1 Ağustos 2024'te yürürlüğe girmişti; 24 Temmuz 2026'da yayımlanan (EU) 2026/1744 sayılı düzenleme (Digital Omnibus on AI) yüksek risk tarihlerini erteledi: Ek III kapsamındaki bağımsız yüksek riskli sistemler için 2 Aralık 2027, düzenlenmiş ürünlere gömülü yapay zekâ (tıbbi cihazlar buraya giriyor) için 2 Ağustos 2028 (bkz. Regulation (EU) 2024/1689 ve (EU) 2026/1744).
Bu takvim size zaman kazandırıyor ama kapsam dışına çıkarmıyor. Bugün başlattığınız bir sağlık chatbot'u, ürün olgunlaştığında bu tarihlerin içinde olacak. Teknik dokümantasyon, risk yönetimi ve veri yönetişimi gereksinimlerini baştan kurmak, sonradan geri dönüp kurmaktan ucuz.
Kapsam dışında kalmanın çalışan yolu: kararı modele verdirmemek
Bir ürünü sınıflandırmadan çıkarmanın yolu, "biz tıbbi tavsiye vermiyoruz" yazmak değil. MDCG 2019-11'in mantığı beyan edilen kullanım amacına bakıyor, sorumluluk reddi metnine değil. Fiilen triyaj yapan bir ürün, altına ne yazarsanız yazın triyaj yapıyor.
Çalışan desen şu: modeli karar verici değil, yönlendirici ve metin üretici olarak konumlandırmak.
- Kararı kural motoruna verin. Aciliyet sınıflandırması gerekiyorsa bunu klinik ekibin onayladığı deterministik bir karar tablosuyla yapın; modelin işi kullanıcının anlattığını o tablonun girdilerine çevirmek olsun. Model karar üretmiyor, form dolduruyor.
- Serbest metin cevabı kısıtlayın. Model bilgi tabanındaki onaylı metinlerden alıntı yapsın; kendi cümlesini kurduğu her yer bir risk yüzeyi.
- Kapsam dışı soruyu devredin. "Bu soruya yanıt veremiyorum, sizi hemşire hattına aktarıyorum" akışını ilk günden kurun. Bu akış olmadığında model her soruya cevap verir, çünkü modelin varsayılan davranışı budur.
Sağlık verisi rejimi değişti: 2024 öncesi varsayımlarla tasarlamayın
6698 sayılı Kanun'un 6. maddesi, 12 Mart 2024 tarihli 32487 sayılı Resmî Gazete'de yayımlanan 7499 sayılı Kanun'la değişti; KVKK hükümleri 1 Haziran 2024'te yürürlüğe girdi. İki değişiklik doğrudan ürünü ilgilendiriyor: "sağlık ve cinsel hayat" ile diğer özel nitelikli veriler arasındaki ayrım kaldırıldı, ve "yalnızca açık rıza ile işlenebilir" kuralı yerini sayılı işleme şartlarına bıraktı.
Sağlık verisi için doğrudan kullanılabilir şart şu: sır saklama yükümlülüğü altındaki kişiler veya yetkili kurum ve kuruluşlarca; kamu sağlığının korunması, koruyucu hekimlik, tıbbî teşhis, tedavi ve bakım hizmetlerinin yürütülmesi ile sağlık hizmetlerinin planlanması, yönetimi ve finansmanı amacıyla gerekli olması. KVKK bu alanda 26 Şubat 2025'te "Özel Nitelikli Kişisel Verilerin İşlenmesine İlişkin Rehber"i yayımladı.
Chatbot bağlamında bunun üç somut karşılığı var. Birincisi, kullanıcının sohbete yazdığı serbest metin sağlık verisi içerebiliyor ve bu veri sohbet kaydında duruyor. İkincisi, dış bir model sağlayıcısına gönderim yurt dışına aktarım rejimini tetikliyor. Üçüncüsü, "sır saklama yükümlülüğü" şartına dayanacaksanız işleyen tarafın bu yükümlülük altında olması gerekiyor; yazılım firması tek başına bu sıfata sahip değil.
Model sağlayıcı seçimi: sözleşme tarafına bakın, benchmark'a değil
Sağlık verisi işleyecek bir chatbot'ta sağlayıcı seçimini model kalitesi değil, veri sözleşmesi belirliyor. 25 Eylül 2026 itibarıyla doğrulanmış tablo:
| Konu | OpenAI | Anthropic |
|---|---|---|
| Varsayılan saklama | Kötüye kullanım izleme logları 30 güne kadar; API verisi eğitimde kullanılmıyor | Kurumsal sözleşmeye bağlı |
| Sıfır veri saklama | ZDR var, ön onay gerekiyor. Uygun uçlar arasında /v1/responses, /v1/chat/completions, /v1/audio/transcriptions; uygun olmayanlar /v1/assistants, /v1/threads, /v1/vector_stores |
Claude Code için ZDR şartı aranıyor |
| Sağlık sözleşmesi (BAA) | Kurumsal görüşme gerektiriyor; canlı internet erişimli web arama kapsam dışı | Yalnızca birinci parti Claude API ve HIPAA-ready Claude Enterprise. Kapsam dışı: Batch API, Files API, Computer Use, Web Fetch, harici konnektörler |
Bu tablodaki en pratik bilgi son satırdaki kapsam dışı listeler. RAG kurmak için vector store kullanmayı planlıyorsanız, OpenAI tarafında bu uçların ZDR'ye uygun olmadığını baştan bilin; bilgi tabanını kendi altyapınızda tutup modele yalnızca bulunan pasajı göndermek gerekiyor (bkz. OpenAI, Your data).
Veriyi hiç dışarı çıkarmama seçeneği de masada. Açık ağırlıklı modellerle kendi altyapınızda çalışmanın pratiği için kurumsal yerel LLM kurulumu rehberine bakabilirsiniz; lisans tarafında Apache 2.0 ve MIT lisanslı modeller kurumsal kullanımda daha temiz.
Hallüsinasyon: model değiştirerek çözülmüyor, mimariyle sınırlanıyor
Dünya Sağlık Örgütü'nün 18 Ocak 2024 tarihli "Ethics and governance of artificial intelligence for health: Guidance on large multi-modal models" belgesi, büyük modellerin yanlış, hatalı, önyargılı veya eksik ifadeler üretebildiğini ve bunun sağlık kararlarında zarara yol açabileceğini kayda geçiriyor; belge kırktan fazla öneri içeriyor (bkz. WHO, Ethics and governance of AI for health: Guidance on LMMs).
Ürün tarafında işe yarayan dört kısıt:
- Kapalı bilgi tabanı. Model yalnızca kurumun onayladığı dokümanlardan cevap versin. Genel bilgi sorularını reddetmek bir eksiklik değil, tasarım kararı.
- Kaynak gösterme zorunluluğu. Her cevap hangi dokümanın hangi bölümünden geldiğini göstersin. Gösteremiyorsa cevap vermesin. Bu, hem kullanıcıya hem de denetime yarıyor.
- Yapılandırılmış çıktı. Serbest paragraf yerine şemaya bağlı alanlar üretin; şemada olmayan bir alan üretilemez.
- İnsan devri eşiği. Modelin güven skoru veya bilgi tabanı eşleşmesi zayıfsa konuşma insana aktarılsın. Eşiği ölçün ve zamanla ayarlayın.
Modelin tek başına hekim yerine geçmediğine dair doğrulanabilir bir veri de var. JAMA Network Open'da 2024'te yayımlanan randomize klinik çalışmada (Goh ve ark., 7(10):e2440969) hekimlere tanısal yardımcı olarak büyük dil modeli verilmesi, konvansiyonel kaynaklara göre klinik akıl yürütmeyi anlamlı biçimde iyileştirmedi: LLM grubunda medyan skor %76, kontrol grubunda %74, fark 2 puan ve istatistiksel olarak anlamlı değil. İlginç ayrıntı, modelin tek başına %92 skor almasıydı. Yani sorun modelin bilgisi değil, insanla modelin birlikte çalışma biçimi.
Prompt injection sağlık bağlamında farklı bir sorun
OWASP'ın LLM Uygulamaları için Top 10 listesinde LLM01:2025 Prompt Injection birinci sırada. Sağlık chatbot'unda bu maddenin özel bir yüzü var: saldırgan kullanıcı olmak zorunda değil. Bilgi tabanına yüklenen bir PDF'in içine gömülü talimat, hasta dosyasındaki bir not alanı veya laboratuvar sisteminden gelen serbest metin de enjeksiyon taşıyabiliyor.
Karşı önlem, kaynağı ne olursa olsun her metni veri olarak işaretlemek: sistem talimatı ile bağlam metnini ayrı bloklara koyun, bağlam bloğunun talimat içermediğini varsaymayın, ve modelin yan etkili bir araç çağırmasını (randevu iptali, e-posta gönderimi) insan onayına bağlayın.
Sırada ne var
Ürün kapsam belgenizi açın ve her özelliği yukarıdaki sınıflandırma tablosuyla eşleyin. "Yüksek" işaretlediğiniz tek bir satır varsa, proje planınıza uygunluk değerlendirmesi ve teknik dokümantasyon kalemlerini eklemeniz gerekiyor; yoksa o özelliği ilk sürümün dışına almak, ürünü aylar önce yayına çıkarıyor.
Sağlık tarafındaki veri entegrasyonları için e-Nabız entegrasyonu ve FHIR rehberlerimiz, KVKK kontrol listesi için özel nitelikli sağlık verisi yazısı başlangıç noktası. Sohbet ve yapay zekâ tarafındaki hizmet kapsamımız yapay zeka ve chatbot sayfasında, sağlık sektörü yaklaşımımız sağlık ve medikal yazılım sayfasında. Kapsam görüşmesi için iletişim sayfasına yazabilirsiniz.
Mevzuat ve kaynak atıfları 25 Eylül 2026 tarihinde doğrulanmıştır: MDR (EU) 2017/745 md. 2(4) ve Ek VIII Kural 11, Tıbbi Cihaz Yönetmeliği (RG 02.06.2021, sayı 31499 1. Mükerrer), TİTCK'nın yayımladığı MDCG 2019-11 Türkçe çevirisi, Regulation (EU) 2024/1689 ve (EU) 2026/1744 uygulama takvimi, 6698 sayılı Kanun md. 6'nın 7499 sayılı Kanun ile değişik hâli, KVKK Özel Nitelikli Kişisel Verilerin İşlenmesine İlişkin Rehber (26.02.2025), WHO LMM rehberi (18.01.2024), JAMA Network Open 2024;7(10):e2440969, OpenAI ve Anthropic'in kendi veri işleme dokümanları, OWASP GenAI Top 10 for LLM Applications 2025. Bu yazı hukuki görüş veya tıbbi tavsiye yerine geçmez.
