Khriss — Veri İşleme Eki (DPA) ve Alt İşleyen Listesi

Sürüm 1.0 · Yürürlük: 29 Temmuz 2026 · Son güncelleme: 29 Temmuz 2026

Bu Veri İşleme Eki (“Ek”), Khriss hizmetini ticari veya kurumsal amaçla kullanan müşteriler (“Müşteri”) ile hizmeti sunan RADONRAD Yazılım ve Elektronik Sistemleri Ticaret Limited Şirketi (“Khriss”) arasındaki kişisel veri işleme ilişkisini düzenler. Khriss Bulut sürümünde Müşteri veri sorumlusu (KVKK m.3/ı; GDPR m.4(7)), Khriss ise veri işleyendir (KVKK m.3/ğ; GDPR m.4(8)). Bu metin, sistemin gerçekte nasıl çalıştığını olduğu gibi anlatmak üzere yazılmıştır: hangi verinin nereye gittiğini, kimin şifre çözme yetkisi olduğunu ve henüz kurulmamış olan parçaları saklamaz.

1. Ekin Konusu, Kapsamı ve Ana Sözleşme ile İlişkisi

1. Konu. Bu Ek, Müşterinin Khriss Bulut hizmetini (cloud.khriss.com) kullanması kapsamında Khriss tarafından Müşteri adına yapılan kişisel veri işleme faaliyetlerinin şartlarını belirler. KVKK m.12, İyi Uygulama ilkeleri ve GDPR m.28(3)’te veri işleyen sözleşmesi için aranan asgari unsurları karşılamayı amaçlar.
2. Bütünlük. Bu Ek, Müşteri ile Khriss arasındaki Hizmet Sözleşmesi / Kullanım Koşulları’nın (“Ana Sözleşme”) ayrılmaz parçasıdır. Kişisel veri işlemeye ilişkin konularda bu Ek ile Ana Sözleşme arasında çelişki bulunursa bu Ek uygulanır; diğer tüm konularda (ücret, hizmet seviyesi, sorumluluk sınırı, fesih usulü) Ana Sözleşme geçerlidir.
3. Süre. Bu Ek, Ana Sözleşme yürürlükte kaldığı sürece ve Khriss’in Müşteri adına kişisel veri işlediği son ana kadar yürürlüktedir. 20. maddedeki silme yükümlülükleri Ana Sözleşme’nin sona ermesinden sonra da devam eder.
4. Yerel (masaüstü) sürüm kapsam dışıdır. Khriss’in Yerel/Masaüstü sürümü tamamen Müşterinin kendi cihazında çalışır; Müşterinin içeriği Khriss’e ulaşmaz. Lisans doğrulaması tamamen çevrimdışıdır (uygulamaya gömülü açık anahtarla Ed25519 imza kontrolü); telemetri, analitik veya “eve arama” (phone-home) yoktur. Bu nedenle Yerel sürümde Khriss, Müşterinin içeriği bakımından veri işleyen değildir ve bu Ek’in 6–20. maddeleri Yerel sürüme uygulanmaz. Yerel sürümde bulut yapay zekâ (egress) açıksa, o çağrının muhatabı Müşterinin kendi yapılandırdığı sağlayıcıdır ve sorumluluk Müşteride kalır.

2. Taraflar

2.1 Veri İşleyen (Khriss)

2.2 Veri Sorumlusu (Müşteri)

Müşteri, çalışma alanını (workspace) oluşturan hesapta yer alan e-posta adresini bildirim adresi olarak beyan etmiş sayılır; farklı bir adres bildirmek Müşterinin sorumluluğundadır.

3. Tanımlar

1. Kişisel veri, ilgili kişi, işleme, veri sorumlusu, veri işleyen, açık rıza terimleri KVKK m.3’teki; “personal data”, “data subject”, “processing”, “controller”, “processor” terimleri GDPR m.4’teki anlamlarıyla kullanılır.
2. Müşteri Verisi: Müşterinin bağladığı kaynaklardan (e-posta, takvim, dosya, sohbet, CRM vb.) Khriss Bulut’a alınan içerik ile bu içerikten türetilen dizinler, gömme vektörleri, varlık/ilişki grafiği, özetler ve kayıtlar.
3. Kiracı (tenant): Müşteriye tahsis edilen izole çalışma alanı; teknik olarak ayrı bir Postgres şeması (t_<hex>), ayrı bir Postgres rolü, ayrı bir Qdrant koleksiyonu ve ayrı bir ham dosya dizini.
4. Dışa aktarım / egress: Müşteri Verisi’nin bir bölümünün Kiracı sınırının dışına, üçüncü taraf bir yapay zekâ hizmetine gönderilmesi.
5. Egress defteri: Her dışa aktarım çağrısının Kiracı içinde tutulan kaydı (14. ve 13. maddeler).
6. Alt işleyen: Khriss’in bu Ek kapsamındaki işleme faaliyetinin bir kısmını yerine getirmek üzere kullandığı üçüncü taraf.
7. DEK / KEK: Kiracıya özgü veri şifreleme anahtarı (Data Encryption Key) ve bu anahtarı saran, operatörde bulunan ana anahtar (Key Encryption Key).

4. Rollerin Dağılımı: Veri Sorumlusu ve Veri İşleyen

1. Müşteri Verisi bakımından Müşteri veri sorumlusudur. Hangi kaynakların bağlanacağına, hangi verinin alınacağına, ne kadar süre saklanacağına, kimlerin erişeceğine ve yapay zekâ dışa aktarımının açık mı kapalı mı olacağına Müşteri karar verir.
2. Khriss veri işleyendir ve Müşteri Verisi’ni yalnızca Müşterinin talimatı doğrultusunda, hizmeti sunmak amacıyla işler.
3. Üçüncü kişilerin kişisel verileri. Müşteri kendi posta kutusunu, takvimini ve sohbetlerini bağladığında sisteme giren veri kaçınılmaz olarak Müşterinin muhataplarına, çalışanlarına, müşterilerine ve tedarikçilerine ait kişisel verileri içerir. Bu kişiler Khriss ile herhangi bir sözleşme ilişkisi kurmamıştır; onlara karşı aydınlatma ve hukuka uygunluk yükümlülüğü Müşteriye aittir (5. madde).
4. Khriss, kendi işletmesine ilişkin sınırlı bir alanda kendisi veri sorumlusudur: hesap ve kimlik doğrulama kayıtları, faturalama ve tahsilat kayıtları, sunucu güvenlik kayıtları, destek yazışmaları. Bu işlemeler bu Ek’in değil, Gizlilik Politikası’nın konusudur.
5. Khriss, Müşteri Verisi’ni kendi amaçları için kullanmaz; özellikle kendi modellerini eğitmek, ürün geliştirmek veya istatistik üretmek için Müşteri Verisi’ni işlemez. Ürün içi kullanım ölçümü, davranış analitiği ve üçüncü taraf izleme kodu Khriss Bulut’ta bulunmaz.

5. Müşterinin (Veri Sorumlusunun) Yükümlülükleri

1. Müşteri, sisteme aktardığı her veri kategorisi için KVKK m.5/m.6 veya GDPR m.6/m.9 kapsamında bir hukuki sebebi bulunduğunu; özel nitelikli (hassas) veri aktarıyorsa buna özgü şartların sağlandığını beyan eder.
2. Müşteri, ilgili kişileri aydınlatma yükümlülüğünü (KVKK m.10; GDPR m.13–14) kendi kanalları üzerinden yerine getirir. Khriss, Müşterinin muhataplarıyla doğrudan iletişime geçmez.
3. Müşteri, bir işleyici olarak Khriss’i ve alt işleyenleri kullanmasının kendi aydınlatma metinlerinde ve gerekiyorsa VERBİS kaydında yansıtılmasından sorumludur.
4. Müşteri, kendi kullanıcılarının rollerini ve yetkilerini (bkz. EK-A §3) veri minimizasyonu ilkesine uygun biçimde yapılandırır; özellikle view_pii ve view_audit yetkilerinin dağıtımından Müşteri sorumludur. Dürüst sınır: bu yetki dağıtımı denetim kaydı için geçerlidir; egress defteri bugün bir izin denetimine bağlı değildir ve Kiracının kimliği doğrulanmış her üyesi (görüntüleyici dâhil) hangi kaynaklardan buluta ne gittiğini kaynak adlarıyla okuyabilir. [[UYGULANMASI BEKLİYOR: egress defteri okuma uç noktasının view_audit iznine bağlanması]]
5. Müşteri, yapay zekâ dışa aktarımını açık bıraktığında, kendi içeriğinin bir bölümünün 13. maddede tanımlanan biçimde — yalnızca sorduğu sorularla sınırlı olmaksızın, alım anında ve kullanıcı yokken çalışan işlerde de — Microsoft’un Azure OpenAI hizmetine gönderileceğini bildiğini ve bunu talimat olarak verdiğini kabul eder. Müşteri, 13. maddeyi okumadan bu talimatın kapsamını değerlendirmiş sayılmaz.
6. Gerekiyorsa veri koruma etki değerlendirmesini (DPIA) Müşteri yapar; Khriss EK-A ve EK-B’deki bilgileri sağlayarak makul ölçüde destek olur.
7. Müşteri, sisteme hukuka aykırı biçimde elde edilmiş veri yüklemeyeceğini kabul eder.

6. İşlemenin Konusu, Süresi, Niteliği ve Amacı

7. İlgili Kişi Grupları ve Veri Kategorileri

7.1 İlgili kişi grupları

• Müşterinin çalışanları ve çalışma alanına davet edilen kullanıcıları,
• Müşterinin müşterileri, potansiyel müşterileri ve tedarikçilerinin temsilcileri,
• Müşterinin posta, takvim ve sohbet kanallarındaki tüm muhatapları (üçüncü kişiler dâhil),
• Müşterinin bağladığı CRM/destek/muhasebe sistemlerinde kayıtlı kişiler.

7.2 Veri kategorileri

Khriss, gelen içeriği özel nitelikli veri bakımından otomatik olarak sınıflandırmaz veya ayıklamaz. Bu tür verinin sisteme girip girmeyeceği Müşterinin kaynak seçimine bağlıdır.

[[UYGULANMASI BEKLİYOR: özel nitelikli veri tespiti/maskeleme özelliği yoktur; talep hâlinde yol haritasına alınacaktır.]]

8. Khriss’in (Veri İşleyenin) Temel Yükümlülükleri

1. Yalnızca talimat üzerine işleme. Khriss, Müşteri Verisi’ni yalnızca bu Ek, Ana Sözleşme ve Müşterinin hizmet arayüzü üzerinden verdiği ayarlar/komutlar kapsamında işler.
2. Amaç dışı kullanmama. Khriss, Müşteri Verisi’ni kendi ticari amaçları, model eğitimi veya profilleme için kullanmaz, üçüncü kişilere satmaz veya kiralamaz.
3. Gizlilik. Khriss ve erişim yetkisi olan personeli, Müşteri Verisi’ni süresiz gizli tutar (10. madde).
4. Güvenlik. Khriss, EK-A’da somut olarak sayılan teknik ve idari tedbirleri uygular ve bu tedbirlerin seviyesini bu Ek yürürlükteyken düşürmez.
5. Alt işleyen disiplini. Khriss, alt işleyenleri 14. maddedeki usule uyarak kullanır ve alt işleyenlere bu Ek’tekiyle esasen aynı yükümlülükleri sözleşmeyle yansıtmayı taahhüt eder.
6. İlgili kişi taleplerine destek. Khriss, 16. maddede tanımlanan araç ve desteği sağlar.
7. İhlal bildirimi. Khriss, bir kişisel veri ihlalini öğrendiğinde 17. maddedeki usule göre gecikmeksizin Müşteriye bildirir.
8. Silme veya iade. Hizmet sona erdiğinde Khriss, 20. maddedeki takvim ve dürüst sınırlar çerçevesinde Müşteri Verisi’ni siler veya iade eder.
9. Bilgi verme. Khriss, Müşterinin bu Ek’teki uyum yükümlülüklerini yerine getirmesi için makul ölçüde bilgi sağlar (18. madde).
10. Kayıt tutma. Kiracı içindeki değiştirilmesi belli olan (hash-zincirli) denetim kaydı ve egress defteri, yapılan işlemenin kanıtı olarak tutulur. Müşteri denetim kaydını dışa aktarabilir; egress defterini hizmet içinde okuyabilir ancak [[UYGULANMASI BEKLİYOR: egress defteri için bir dışa aktarma uç noktası henüz yoktur; talep hâlinde operatör tarafından çıkarılır]]. Egress defteri ve denetim kaydı, Kiracının kendi şemasındaki tablolardır; değiştirilemez (immutable) değildir ve bağımsız bir üçüncü tarafça tasdik edilmemektedir — denetim kaydı için sunulan güvence, zincir kırılmasının tespit edilebilmesidir.

9. Talimatlar ve Talimat Dışı İşleme

1. Müşterinin talimatları; bu Ek, Ana Sözleşme, hizmet içindeki ayarlar (bağlanan kaynaklar, egress anahtarı, kaynak bazlı local_only işareti, saklama politikası, roller) ve [email protected] üzerinden yazılı olarak iletilen açık talimatlardan oluşur.
2. Khriss, bir talimatın kişisel verilerin korunmasına ilişkin mevzuata aykırı olduğu kanaatine varırsa Müşteriyi gecikmeksizin bilgilendirir ve söz konusu talimatın yerine getirilmesini askıya alabilir.
3. Khriss, Müşteri Verisi’ni yalnızca hukuken bağlayıcı bir talep (mahkeme kararı, savcılık veya yetkili idari otorite talebi) üzerine talimat dışında açıklayabilir. Bu hâlde Khriss, hukuken yasak olmadığı ölçüde, açıklamadan önce Müşteriyi bilgilendirir, talebin kapsamını daraltmak için makul adımları atar ve yalnızca talep edilen asgari veriyi verir. Böyle bir talep bugüne kadar alınmamıştır.
4. [[UYGULANMASI BEKLİYOR: kamu otoritesi taleplerinin sayısını dönemsel olarak yayımlayan bir şeffaflık raporu henüz oluşturulmadı.]]

10. Gizlilik ve Personel

1. Müşteri Verisi’ne erişimi, işini yapmak için gerçekten ihtiyaç duyan personelle sınırlıdır; bu personel yazılı gizlilik yükümlülüğü altındadır ve yükümlülük iş ilişkisinin bitmesinden sonra da sürer.
2. Khriss küçük bir ekiple çalışır. Bu, sorumluluğun izlenebilir olduğu kadar, görevler ayrılığının büyük bir kuruluştaki gibi kişi bazında dağıtılamadığı anlamına da gelir. Operatör düzeyindeki eylemler kontrol düzleminde ekleme-yalnızca (append-only) bir denetim kaydına yazılır.
3. [[UYGULANMASI BEKLİYOR: operatör personelinin kiracı verisine erişimi için tam-zamanında (just-in-time) onay akışı ve bu erişimlerin ilgili Müşteriye otomatik raporlanması henüz kurulmadı. Bugün operatör erişimi teknik olarak mümkündür ve kontrol düzlemi kaydına yazılır.]]
4. Personelin cihazlarında ve altyapı erişiminde çok faktörlü kimlik doğrulama zorunludur.

11. Güvenlik Tedbirleri

1. Khriss, KVKK m.12 ve GDPR m.32 uyarınca, işlemenin niteliğine uygun teknik ve idari tedbirleri uygular. Uygulanan tedbirlerin tam ve gerçek listesi EK-A’dadır.
2. Sertifikasyon beyanı. Khriss’in ISO/IEC 27001 belgesi, SOC 2 raporu veya benzeri bir bağımsız uyum sertifikası yoktur. Bağımsız bir sızma testi de henüz yapılmamıştır. EK-A, belgelendirilmiş değil, uygulanmış kontrolleri anlatır.
3. Müşteri, kendi tarafındaki tedbirlerden (kullanıcı cihaz güvenliği, parola ve MFA disiplini, rollerin doğru dağıtımı, ayrılan çalışanın erişiminin kaldırılması) sorumludur.

12. Şifreleme ve Anahtar Yönetimi — Operatör Erişimi Hakkında Açık Beyan

1. Şifrelemenin kapsamı — tam ve dar beyan. Uygulama düzeyinde, kiracıya özgü bir DEK ile AES-256-GCM kullanılarak şifrelenen tek bir alan vardır: chunk metni (dizinlenmiş içerik parçalarının gövdesi). Kiracı şemasındaki diğer her şey uygulama katmanında düz metindir: doküman başlıkları ve URI’leri, kişi/şirket adları ve özetleri, tanımlayıcılar (e-posta, telefon), takvim ve görev içerikleri, tam metin arama dizini (tsvector), Qdrant vektörleri ve yükleri, diskteki ham dosyalar ve denetim/egress kayıt satırları. Geri kalanı koruyan şey şifreleme değil, ayrı Postgres şeması + ayrı Postgres rolü (bir kiracının kimlik bilgisi diğerinin verisini okuyamaz), aktarım hâlinde TLS ve bulut sağlayıcı katmanındaki disk şifrelemesidir. Bağlantı sırları ve OAuth jetonları bundan ayrı olarak Fernet ile şifrelenir (7.2). DEK, kiracı kimliği ek doğrulama verisi (AAD) olarak bağlanarak operatörde bulunan bir ana anahtar (KEK) ile sarılır ve sarılmış hâliyle kontrol düzleminde saklanır.
2. Anahtar Müşteride değildir. KEK’i Khriss (operatör) elinde tutar. Bu, teknik gerçeğin doğrudan sonucudur: Khriss, gerektiğinde Müşteri Verisi’nin şifresini çözebilir. Kolon şifrelemesinin koruması kısmîdir: veritabanı dosyası, yedek veya disk anlık görüntüsü ele geçtiğinde chunk metni ciphertext olarak kalır, ancak aynı dökümün içindeki tam metin dizini tsvector’ü (leksemler ve konumlarıyla), üstveri kolonları, Qdrant yükleri ve ham dosya dizini açık durur. Kiracılar arası okumaya karşı asıl koruma rol/şema izolasyonudur. Operatöre karşı hiçbir koruma sağlamaz.
3. Bu beyan, pazarlama sayfalarında geçmişte oluşabilecek “yalnızca siz okuyabilirsiniz” izlenimini düzeltmek üzere bilinçli olarak bu Ek’e konulmuştur. Vendorun teknik olarak veriye erişemediği tek yapılandırma, hiçbir verinin Khriss’e ulaşmadığı Yerel/Masaüstü sürümdür.
4. KEK anahtar zinciri sürümlenir; eski sürümler yalnızca eski DEK’leri açmak için tutulur, yeni sarmalar etkin sürümle yapılır ve dönemsel rewrap ile döndürme yapılabilir. Anahtar zincirinin kaybı veya yanlış ortamdan yüklenmesi hâlinde verinin geri döndürülemez biçimde açılamaz hâle gelmesini önlemek için bir “canary” doğrulaması çalışır.
5. [[UYGULANMASI BEKLİYOR: Müşterinin kendi anahtarını getirdiği (BYOK/HYOK) veya anahtarı kendi tuttuğu bir mod yoktur.]]

13. Yapay Zekâ İşlemesi ve Dışa Aktarım (Egress)

Bu madde, bu Ek’in en önemli açıklamasıdır: Kiracı sınırının dışına ne çıktığını tarif eder.

1. Ne çıkar. Dışa aktarım yalnızca Müşterinin sorduğu sorulardan doğmaz. Yapay zekâ dışa aktarımı açıkken içerik gönderen yollar şunlardır:
   • (a) Sorgu anında — Müşterinin sorusu ve o soruya cevap üretmek için getirilen içerik alıntıları. Her istekte yalnızca o istek için seçilen sınırlı sayıda parça gönderilir.
   • (b) Alım (ingest) anında, hiçbir soru sorulmamışken, varsayılan olarak AÇIK — varlık/ilişki (graph) çıkarımı, alınan her dokümanın ilk yaklaşık 6.000 karakterini Azure OpenAI’a gönderir. Bu yol iki anahtarla açıktır ve ikisinin de varsayılanı açıktır: kurulum düzeyinde graph_extract ve kaynak düzeyinde extract_graph. Özet üretimi de doküman metni gönderir.
   • (c) Görseller bütün hâlde çıkar — görsel açıklama (vision) yolu, görselden alınan bir alıntı değil, dosyanın kendisini base64 veri URL’i olarak gönderir.
   • (d) Kullanıcı yokken çalışan zamanlanmış işler — gecelik konsolidasyon (“dream”), gelen kutusu ayıklama/puanlama, uyarı taramaları ve takip merdivenleri. Bulut sürümünde bu işler bir zamanlayıcı (arq beat) tarafından kiracı başına dağıtılır; dolayısıyla Müşteri hiç oturum açmasa da çalışırlar.
   • (e) Web araması — etkinleştirilmişse, modelin ürettiği arama sorgusu metni (bkz. EK-B; varsayılan devre dışı).

   Müşterinin bilmesi gereken sonuç: Bulut sürümünde bir posta kutusunu bağlamak, zamanla o kutunun içeriğinin büyük ölçüde bulut yapay zekâsı tarafından işlenmesi anlamına gelir — yalnızca Müşterinin hakkında soru sorduğu bölümler değil. Bu nedenle “veritabanının tamamı gönderilmez” ifadesi tek başına yanıltıcı olur: tek bir istekte tamamı gönderilmez, ancak alım yolu zamanla arşivin kayda değer bir bölümünü kalem kalem geçirir. Bunu tümüyle durduran iki denetim vardır ve etkilidirler: kiracı ayarındaki ai_egress ana anahtarı kapatıldığında hiçbir şey çıkmaz (13/5), kaynak düzeyindeki local_only işareti ise o kaynağın içeriğini bütün yollarda keser. Kaynak düzeyinde extract_graph’ı kapatmak (b) yolunu o kaynak için sonlandırır, (a) yolunu etkilemez.

2. Nereye çıkar. Microsoft’un Azure OpenAI Service hizmetine (bkz. EK-B). Gömme (embedding) vektörleri buna dâhil değildir: gömme üretimi cihaz üstünde (Ollama) yapılır ve bu iş için hiçbir egress yoktur.
3. Tek nokta. Dışa aktarım tek bir kod yolundan (chokepoint) geçer. Bu noktada, kaynak düzeyinde local_only işaretlenmiş kaynakların içeriği tel üzerinde son kez süzülür; üst katmanlarda bir hata olsa bile bu kaynakların içeriği gönderilmez.
4. Kayıt ÖNCE yazılır. Her çağrı için, soket açılmadan önce Kiracı içindeki egress defterine pending (beklemede) durumunda bir satır yazılıp kesinleştirilir; yanıt geldiğinde satır ok, hata veya zaman aşımı hâlinde error olarak sonlandırılır. Ön yazma başarısız olursa çağrı yapılmaz — kaydı tutulamayan bir çağrının gönderilmemesi bilinçli bir tercihtir. Bunun sonucu: başarısız olan veya zaman aşımına düşen bir çağrı da deftere yansır. Deftere yazılanlar: model, amaç, hedef sunucu adı, istek boyutu (bayt), istek gövdesinin sha256 özetinin ön eki, istem/yanıt karakter sayıları, çağrıyı tetikleyen kullanıcı ve içeriği isteme giren kaynakların kimlikleri ile sayısı. Böylece “beynimden bugüne kadar buluta ne gitti, hangi kaynaklardan?” sorusu tahminle değil kayıtla yanıtlanır. Dürüst sınır: bu defter Kiracının kendi şemasındaki bir tablodur; değiştirilemez değildir ve bağımsız olarak tasdik edilmemektedir.
5. Kapatma hakkı. Müşteri, kendi Kiracısı için yapay zekâ dışa aktarımını tamamen kapatabilir (ayarlarda ai_egress). Kapalıyken bulut modeline hiçbir çağrı yapılmaz; hizmet arama ve dizinleme yetenekleriyle çalışmaya devam eder, üretken cevaplar devre dışı kalır. Aynı anahtar, varsa web araması yolunu da kapatır.
6. Görüntüleme ve dışa aktarım. Müşteri, egress defterini ve denetim kaydını hizmet içindeki uç noktalar üzerinden okuyabilir. İki dürüst sınır: (a) denetim kaydı okuma, zincir doğrulama ve dışa aktarma view_audit iznine bağlıdır; egress defteri bugün hiçbir izne bağlı değildir — Kiracının kimliği doğrulanmış her üyesi, görüntüleyici (viewer) rolü dâhil, hangi kaynaklardan buluta ne gittiğini kaynak adlarıyla çözümlenmiş hâlde okuyabilir; (b) egress defteri için bir dışa aktarma uç noktası yoktur. [[UYGULANMASI BEKLİYOR: egress defteri okuma uç noktasının view_audit iznine bağlanması ve bir egress defteri dışa aktarma uç noktası eklenmesi]]
7. Kota. Kiracı başına dışa aktarım hız/kota sınırları uygulanır; bu, komşu kiracıları tek bir hatalı döngüden korumak içindir.
8. Model eğitimi. Khriss, Müşteri Verisi’ni model eğitimi için kullanmaz ve bu amaçla üçüncü kişilere vermez. Azure OpenAI hizmetinin kendi sözleşmesel taahhütleri bakımından geçerli referanslar EK-B’de kaydedilecektir (bkz. AÇIK KARARLAR).
9. Cihaz üstü seçenek. Yerel sürümde, cihaz üzerinde çalışan bir model seçeneği (llama.cpp) vardır; bu modda hiçbir veri cihazdan çıkmaz. Bu seçenek Bulut sürümünde sunulmamaktadır.

14. Alt İşleyenler

1. Müşteri, bu Ek’i kabul etmekle EK-B’de listelenen alt işleyenlerin kullanılmasına genel yetki vermiş olur.
2. Bildirim. Khriss yeni bir alt işleyen eklemeyi veya mevcut bir alt işleyenin rolünü esaslı biçimde değiştirmeyi planladığında, değişiklikten en az 30 gün önce Müşteriyi bilgilendirir. Bildirim, bu sayfanın güncellenmesi ve Müşterinin bildirim adresine ileti gönderilmesi yoluyla yapılır.
3. İtiraz hakkı. Müşteri, bildirimden itibaren 15 gün içinde, kişisel verilerin korunmasına ilişkin gerekçeleri yazılı olarak belirterek itiraz edebilir. Taraflar öncelikle makul bir çözüm (alternatif yapılandırma, o alt işleyene bağlı özelliğin kapatılması) arar. Çözüm bulunamazsa Müşteri, etkilenen hizmeti cezai şart olmaksızın feshedebilir ve peşin ödenmiş, kullanılmamış döneme ilişkin bedeli oranlı olarak geri alır.
4. Zorunlu değişiklikler. Güvenlik veya hizmet sürekliliği için acil bir alt işleyen değişikliği gerekirse Khriss değişikliği yapıp Müşteriyi gecikmeksizin bilgilendirir; itiraz hakkı bu hâlde de geçerlidir.
5. Sorumluluk. Khriss, kullandığı alt işleyenlerin bu Ek’teki yükümlülüklere uygun davranmasından Müşteriye karşı sorumludur.
6. Alt işleyen olmayanlar. Müşterinin bağladığı kaynak sistemler (Google, Microsoft, Slack, Notion, Jira, HubSpot, Salesforce, Stripe, QuickBooks/Xero vb. — toplam 180’i aşan bağlayıcı) Khriss’in alt işleyeni değildir; bunlar Müşterinin kendi veri sorumlusu ilişkileridir. Khriss bu sistemlere yalnızca Müşterinin verdiği yetkiyle, veri çekmek için bağlanır. WhatsApp bağlayıcısı yalnızca okuma yapar.
7. [[UYGULANMASI BEKLİYOR: alt işleyen değişikliklerinin duyurulacağı sürümlenmiş kalıcı duyuru sayfası ve e-posta bildirim listesi henüz kurulmadı; e-posta gönderim katmanı (SMTP) yapılandırılmamıştır. Bu kurulana kadar bildirimler bu sayfanın güncellenmesi ve uygulama içi duyuru ile yapılır.]]

15. Yurt Dışına Aktarım

1. Fiili durum. Khriss Bulut, Microsoft Azure’un North Europe (İrlanda) bölgesinde çalışır; bu tespit 29 Temmuz 2026’da üretim sunucusundaki Azure metadata servisinden doğrulanmıştır ve kaydı REPORT/hosting-evidence.md dosyasındadır (barındırma yapılandırması kod olarak depoda tutulmadığı için kaynak koddan doğrulanamaz). Bu nedenle Türkiye’de bulunan ilgili kişilere ait kişisel veriler Türkiye dışında saklanır ve işlenir. Ayrıca: khriss.com ve cloud.khriss.com Cloudflare üzerinden yayınlanır ve TLS bağlantısı Cloudflare’in küresel uç ağında sonlanır (Cloudflare istek trafiğini görür); yapay zekâ çıkarımı Microsoft’un Azure OpenAI hizmetinde yapılır — [[UYGULANMASI BEKLİYOR: kullanılan Azure OpenAI kaynağının bölgesi henüz kayda geçirilmemiştir; yurt dışına aktarım beyanı bakımından belgelenmesi gerekir]]. Gömme vektörü üretimi cihaz üstünde yapılır, bu iş için yurt dışına aktarım yoktur.
2. KVKK m.9 bakımından durum. Yurt dışına aktarım için mevzuatta öngörülen yollar şunlardır: (a) Kurul tarafından ilan edilmiş yeterlilik kararı bulunan ülkeye aktarım; (b) taraflar arasında imzalanan ve imza tarihinden itibaren beş iş günü içinde Kurul’a bildirilen standart sözleşme; (c) grup şirketleri için Kurul onaylı bağlayıcı şirket kuralları; (d) belirli hâllerde ilgili kişinin açık rızası veya m.9/6’daki arızi istisnalar.
3. Açık beyan. Bu sürüm yayımlandığı tarihte bu mekanizmalardan hiçbirinin tamamlandığı iddia edilmemektedir. Taraflar, hangi mekanizmanın kullanılacağını seçmek, belgelemek ve gerekiyorsa Kurul’a bildirmek zorundadır. Seçim yapıldığında bu madde, mekanizmanın adı, tarafları ve tarihi yazılarak güncellenecektir.
4. GDPR bakımından. İrlanda AB üyesidir; AB/AEA içinde kalan işlemeler bakımından üçüncü ülkeye aktarım söz konusu olmaz. Cloudflare’in küresel ağı ve Microsoft’un destek süreçleri gibi AEA dışına çıkabilecek unsurlar için ilgili sağlayıcıların standart sözleşme hükümleri (SCC) referansları EK-B’ye kaydedilecektir.
5. Azaltıcı unsur. Müşteri, yapay zekâ dışa aktarımını kapatarak Azure OpenAI ayağını tamamen ortadan kaldırabilir (13/5). Barındırma ayağı (İrlanda) Bulut sürümünde kapatılamaz; verinin Türkiye’de kalması gereken hâller için Yerel/Masaüstü sürüm uygun seçenektir.
6. [[UYGULANMASI BEKLİYOR: Türkiye içinde barındırma bölgesi seçeneği sunulmamaktadır.]]

16. İlgili Kişi Taleplerine Destek

1. Bir ilgili kişi doğrudan Khriss’e başvurursa Khriss talebi yanıtlamaz; talebi gecikmeksizin ilgili Müşteriye yönlendirir ve bunu bildirir. Talebi değerlendirme ve yanıtlama yetkisi veri sorumlusu olarak Müşteriye aittir.
2. Khriss, Müşterinin KVKK m.11 ve GDPR m.15–22 kapsamındaki taleplere yanıt verebilmesi için şu araç ve desteği sağlar:
   • Erişim ve bilgi: hizmet içi arama ve kişi bazlı görünümler; işleme kayıt envanteri (ROPA) uç noktası.
   • Silme — gerçek kapsamıyla: kişi (veri öznesi) düzeyinde silme işlevi. Önce kuru çalışma (dry-run) tablo tablo neyin silineceğini sayı olarak gösterir; onaydan sonra silme uygulanır. Kaldırdıkları: varlık (entity) kaydı, tanımlayıcıları (e-posta/telefon/ad), kişi profili, o kişinin taraf olduğu tüm ilişki kenarları (edge) ve o kişi hakkındaki türetilmiş kayıtlar — epizodlar, taahhütler, delegasyonlar ve olayları, uyarılar, geri bildirimler. Kaldırmadıkları (bu sınır belirleyicidir): o kişinin adının, e-postasının ve yazışma içeriğinin geçtiği dokümanlar ve chunk’lar, Qdrant vektörleri ve vektör yükleri, ham dosya dizinindeki e-posta gövdeleri ve ekleri ve tam metin arama dizini (tsvector) yerinde kalır. Doküman düzeyinde redaksiyon ayrı ve daha ağır bir işlemdir ve bugün yoktur. [[UYGULANMASI BEKLİYOR: doküman/chunk düzeyinde redaksiyon, vektör ve ham dosya temizliği]] Bu nedenle Müşteri, bir KVKK m.7 / m.11 (GDPR m.17) silme talebini yalnızca bu işleve dayanarak “tamamen yerine getirildi” diye kapatırsa yanlış beyanda bulunmuş olur; kalan içerik için doküman/kaynak düzeyinde silme veya kaynağın tümüyle kaldırılması gerekir. Silme işleminin kendisi denetim kaydına yazılır.
   • Taşınabilirlik: Kiracının arşiv olarak dışa aktarılması — gerçek kapsamı ve sınırları için 19. madde.
   • Kanıt: hash-zincirli denetim kaydının dışa aktarımı ve zincir doğrulaması; egress defterinin hizmet içinde görüntülenmesi (dışa aktarımı için bkz. 13/6).
3. Khriss, kendi araçlarıyla karşılanamayan talepler için makul ölçüde teknik destek verir. Hizmet planında aksi öngörülmedikçe, olağan dışı yoğunlukta veya tekrarlayan talepler için makul bir hizmet bedeli talep edilebilir.
4. Dürüst sınırlar. (a) Kişi düzeyinde silme, yukarıda sayıldığı üzere yazışma içeriğini, vektörleri, ham dosyaları ve arama dizinini kaldırmaz; yalnızca varlık/ilişki grafiğini ve o kişi hakkındaki türetilmiş kayıtları kaldırır. (b) Silme, o kişinin geçmiş yedek jenerasyonlarındaki izlerini geriye dönük olarak yeniden yazmaz; yedekler 20/5 uyarınca yaşlanarak düşer.
5. [[UYGULANMASI BEKLİYOR: Müşterinin panelden tek tuşla tam arşiv indirmesi (self-servis dışa aktarım) henüz yoktur; dışa aktarım operatör tarafından çalıştırılır.]]

17. Veri İhlali Bildirimi

1. Khriss, Müşteri Verisi’ni etkileyen bir kişisel veri ihlalini öğrendiğinde gecikmeksizin ve her hâlde 48 saat içinde Müşterinin bildirim adresine bildirir. Bildirim, soruşturma tamamlanmasını beklemez; bilgi geldikçe güncellenir.
2. Khriss’in gerçekte söyleyebilecekleri. Bildirimde, elindeki teknik kayıtların elverdiği ölçüde şunlar yer alır:
   • ihlalin niteliği, tespit zamanı ve tahmini başlangıç zamanı;
   • etkilenen Kiracı(lar) ve etkilenen veri kategorileri;
   • hangi kayıtlara dokunulduğu ve kim tarafından — hash-zincirli denetim kaydı bu soruyu tahminle değil kayıtla yanıtlar; zincirin bütünlüğü doğrulanabilir;
   • sistemden dışarıya ne çıktığı — egress defteri hedef, boyut, özet ve kaynak kimlikleriyle kayıt tutar;
   • kimlik doğrulama ve oturum kayıtları (giriş başarı/başarısızlıkları, jeton üretimi, oturum iptalleri);
   • alınan ve alınacak önlemler, azaltıcı tedbirler ve iletişim noktası.
3. Khriss’in söyleyemeyecekleri. Kayıt kapsamı dışında kalan hususlarda (örneğin verinin ihlalden sonra üçüncü kişilerde nasıl kullanıldığı, ya da Müşterinin kendi cihaz/kullanıcı tarafındaki olaylar) Khriss kesin beyanda bulunamaz. Bilinmeyeni bilinen gibi sunmaz.
4. Bildirim yükümlülüğü Müşteridedir. Kurul’a (KVKK m.12/5 uyarınca kural olarak 72 saat içinde) ve ilgili kişilere ya da yetkili denetim otoritesine (GDPR m.33–34) bildirim yapmak veri sorumlusu olarak Müşterinin görevidir. Khriss, bu bildirimlerin içeriğini hazırlamak için gereken teknik bilgiyi sağlar; Müşteri adına Kurul’a bildirim yapmaz.
5. Müşterinin kendi kullanıcı hesaplarının ele geçirilmesi gibi Müşteri tarafındaki olaylar bu maddedeki Khriss yükümlülüğünü doğurmaz; Khriss tespit ettiğinde bilgi vermeye çalışır.
6. [[UYGULANMASI BEKLİYOR: 7/24 nöbet (on-call) düzeni ve otomatik e-posta bildirimi kurulmamıştır; SMTP katmanı gelene kadar bildirim manuel olarak yapılır. 48 saatlik sürenin operasyonel olarak taahhüt edilebilirliği AÇIK KARARLAR’da tartışmaya açılmıştır.]]

18. Denetim ve İnceleme Hakkı

1. Khriss, Müşterinin KVKK m.12 ve GDPR m.28(3)(h) kapsamındaki denetim hakkını, aşağıdaki kademeli yöntemle karşılar:
   1. Belge: bu Ek, EK-A (uygulanan tedbirler), EK-B (alt işleyenler), veri akış şeması ve ilgili kayıt/uç nokta çıktıları talep üzerine paylaşılır.
   2. Soru listesi: Müşterinin güvenlik anketleri (vendor assessment) makul sürede yazılı olarak yanıtlanır.
   3. Kendi kanıtı: Müşteri, kendi Kiracısına ait denetim kaydını, zincir doğrulamasını ve egress defterini kendisi dışa aktarıp inceleyebilir. Pek çok soruya (kim ne yaptı, dışarıya ne gitti) en güçlü cevap budur.
   4. Yerinde/uzaktan inceleme: Yukarıdakiler yeterli olmazsa Müşteri veya bağımsız denetçisi, en az 30 gün önce yazılı bildirimle, mesai saatleri içinde, yılda bir kez inceleme yapabilir.
2. Pratik sınırlar (dürüst beyan). Khriss küçük bir sağlayıcıdır. Bu nedenle: (a) çok kiracılı üretim ortamına canlı erişim verilemez — başka Müşterilerin verisi risk altına girer; (b) denetim, dokümantasyon, yapılandırma kanıtı ve kod/kontrol açıklaması düzeyinde yürütülür; (c) denetçinin gizlilik taahhüdü imzalaması ve Khriss’in ticari sırlarını korumayı kabul etmesi şarttır; (d) makul olağan destek dışında kalan denetim çalışmaları için Khriss makul bir bedel talep edebilir; (e) Khriss’in sunabileceği bağımsız üçüncü taraf güvence raporu (SOC 2, ISO 27001) yoktur.
3. Denetim faaliyeti, hizmetin sürekliliğini bozacak şekilde yürütülemez.
4. [[UYGULANMASI BEKLİYOR: bağımsız sızma testi yapılmamıştır; yapıldığında rapor özetinin Müşterilere sunulup sunulmayacağı AÇIK KARARLAR’da bekliyor.]]

19. Veri Taşınabilirliği ve Dışa Aktarım

1. Müşteri, sözleşme süresince ve fesihten sonra 20/2’deki süre içinde, Kiracısının taşınabilir bir arşivini talep edebilir. Arşivin gerçek içeriği üç şeydir: (a) kiracı Postgres şemasının dökümü, (b) Qdrant vektör noktaları (kimlik + vektör + yük), (c) kiracı üstverisini ve sarılmış DEK kaydını taşıyan bir manifest. Arşiv “kendi kendine yeterli” değildir: açılması operatörün KEK’ine ve bağlantı sırları bakımından ortak Fernet uygulama anahtarına bağlıdır.
2. Arşivde olmayan. Kiracıya özgü ham dosya dizini arşive dâhil değildir — e-posta gövdelerinin ve eklerinin ham hâli tam olarak orada durduğu için bu, taşınabilirlik bakımından esaslı bir eksiktir. [[UYGULANMASI BEKLİYOR: ham dosya dizininin dışa aktarıma ve yedeğe dâhil edilmesi — bugün ne yedeklenir ne de aktarılır]]
3. Chunk metninin açılabilmesi teknik olarak KEK’e bağlıdır (12. madde). Bu nedenle Müşteri, arşivin okunabilir hâlini talep ettiğinde Khriss açık metin dışa aktarımı hazırlar; salt ciphertext arşiv, Khriss’ten bağımsız olarak açılamaz.
4. Dışa aktarım, makul sıklıkta ücretsizdir; olağan dışı boyut veya sıklıkta makul bir bedel talep edilebilir.

20. Saklama, Silme ve Sözleşmenin Sona Ermesi

1. Saklama — motorun gerçek kapsamı. Kiracı içinde veri sınıfı bazlı bir saklama (retention) motoru vardır ve her sınıf için gün cinsinden bir üst sınır tanımlanabilir. Motorun kapsadığı sınıflar yalnızca şu altı kayıt-benzeri tablodur: denetim olayları (audit_event), egress defteri (cloudcall), eylem kaydı (actionlog), sohbet iletileri (chatmessage), epizodlar (episode) ve getirme geri bildirimleri (retrievalfeedback). Yazışma içeriği, dokümanlar, chunk’lar, varlıklar, kişi profilleri, takvim kayıtları, vektörler ve ham dosyalar saklama motoruna TABİ DEĞİLDİR ve süre bazlı otomatik imhaya hiç girmez; bu içerik yalnızca kaynak/doküman silme veya kiracı silme yoluyla kalkar. Varsayılan “süresiz”dir — Müşteri açıkça bir süre tanımlamadıkça hiçbir şey silinmez. Hukuki muhafaza (legal hold) anahtarı tüm silmeyi askıya alır. Her silme işleminin kendisi denetim kaydına yazılır. [[UYGULANMASI BEKLİYOR: saklama süresi uygulaması zamanlanmış bir işe bağlı değildir — tanımlanan pencere, uygulama uç noktası elle çağrılmadıkça hiçbir şey silmez]] [[UYGULANMASI BEKLİYOR: içerik sınıflarının (doküman, chunk, ham dosya, vektör) saklama motoruna eklenmesi]] Müşteri, kendi saklama ve imha politikasını bu ürünle bugün ancak kayıt sınıfları bakımından uygulayabilir; içerik bakımından uygulayamaz.
2. Fesih ve yumuşak silme. Müşterinin silme talebi veya sözleşmenin sona ermesi üzerine Kiracı “deleting” durumuna alınır ve 7 günlük geri dönüş (grace) süresi başlar (bugünkü yapılandırma; grace_days ile değiştirilebilir). Bu süre içinde veri el sürülmeden bekler; Müşteri kararından dönerse Kiracı yeniden etkinleştirilir. Bu pencere, kazara ve geri dönüşsüz silmeye karşı bilinçli bir tercihtir. Talebin bugünkü yolu: askıya alma, sürdürme, silme talebi ve geri alma işlemleri yalnızca operatörün yönetim uç noktalarında mevcuttur; Müşterinin kendi hesap ekranından iptal veya silme başlatabileceği bir uç nokta ve arayüz yoktur. Bu nedenle talep, [email protected] adresine yazılı olarak iletilir ve operatör tarafından uygulanır; işlem kontrol düzlemi denetim kaydına yazılır. [[UYGULANMASI BEKLİYOR: Müşterinin kendi panelinden aboneliği iptal etmesi ve Kiracı silme talebi başlatması için müşteriye açık uç nokta ve arayüz]]
3. Kalıcı silme. Geri dönüş süresi geçtikten sonra çalışan kalıcı silme işlemi (purge) şunları geri dönüşsüz olarak siler: kiracının Postgres şeması (CASCADE), kiracıya ait Postgres rolü, kiracının Qdrant vektör koleksiyonu, kiracının ham dosya dizini (posta gövdeleri ve ekler burada durur) ve kontrol düzlemindeki kiracı kayıtları — sarılmış DEK kaydı dâhil. DEK kaydının silinmesi, geride kalan herhangi bir ciphertext’in kriptografik olarak açılamaz hâle gelmesi anlamına gelir. [[UYGULANMASI BEKLİYOR: kurumsal tek oturum açma (SSO) yapılandırılmış Kiracılarda, kontrol düzlemi kayıtlarının (sarılmış DEK kaydı dâhil) silinmesi bilinen bir hata nedeniyle başarısız olabilir; şema, rol, Qdrant koleksiyonu ve ham dosya dizini o noktada silinmiş olsa da kimlik sağlayıcı yapılandırması ve sarılmış DEK kaydı kontrol düzleminde kalabilir. Bu Kiracılarda kalıcı silme, düzeltme yayımlanana kadar elle doğrulanır]]
4. İade. Müşteri, kalıcı silmeden önce 19. madde uyarınca dışa aktarım talep edebilir. Silme gerçekleştikten sonra iade teknik olarak mümkün değildir.
5. Yedekler (dürüst beyan). Gecelik yedek alınır ve 7 jenerasyon saklanır (bugünkü yapılandırma; MYBRAIN_BACKUP_KEEP ile değiştirilebilir); her jenerasyon doğrulanır, eski jenerasyonlar budanır ve haftalık geri yükleme tatbikatı yapılır. Bunun sonucu şudur: bir Kiracı kalıcı olarak silindikten sonra da o Kiracının verisi yaklaşık 7 gün daha yedek jenerasyonlarında kalır ve jenerasyonlar yaşlandıkça kendiliğinden düşer. Yedekler seçici olarak yeniden yazılmaz; tek tek kayıt silmek için yedeğe müdahale edilmez. Yedeklerin içindeki DEK’ler sarılmış hâlde durur. Yedeğin kapsam sınırı: gecelik yedek kiracı şeması dökümünü, Qdrant noktalarını ve sarılmış DEK kaydını alır; ham dosya dizini yedeklenmez, dolayısıyla bir felaket hâlinde ham e-posta gövdeleri ve ekleri geri getirilemez. Ayrıca bağlantı sırlarını açan ortak Fernet uygulama anahtarı da yedeğe girmez; geri yükleme bu anahtarın ayrıca elde tutulmasına bağlıdır. [[UYGULANMASI BEKLİYOR: ham dosya dizininin yedeklenmesi ve ortak uygulama anahtarının yedek/kurtarma prosedürüne alınması]]
6. Askıya alma. Ödeme aksaması veya idari sebeple hizmet askıya alındığında (suspended) veriye dokunulmaz; işler durur, erişim reddedilir, hizmet yeniden etkinleştirildiğinde veri olduğu gibi bulunur.
7. Mevzuattan doğan saklama. Khriss’in kendi veri sorumlusu sıfatıyla tuttuğu faturalama ve muhasebe kayıtları, vergi mevzuatındaki saklama süreleri boyunca saklanır; bu kayıtlar Müşteri Verisi içeriğini içermez.

21. Sorumluluk, Ücret ve Vergi Konularının Kapsamı

1. Bu Ek, ücret, fiyatlandırma, vergi veya fatura hükmü içermez; bu konular Ana Sözleşme ve Ön Bilgilendirme Formu / Mesafeli Satış Sözleşmesi (tüketici satışlarında) ile düzenlenir.
2. Varsayım: Bu Ek, fiyatların KDV hariç mi dâhil mi gösterileceği ve faturanın nasıl düzenleneceği konusunda hiçbir varsayımda bulunmaz.
3. [[UYGULANMASI BEKLİYOR: %20 KDV hesaplaması ve e-Arşiv fatura düzenleme akışı henüz uygulanmamıştır (Dalga 4). Kurumsal Müşteriler için fatura süreci bu tamamlanana kadar manuel yürütülür.]]
4. Tarafların birbirine karşı sorumluluğunun sınırı Ana Sözleşme’deki sorumluluk hükümlerine tabidir; ancak bu sınır, kişisel verilerin korunması mevzuatının emredici hükümlerinden doğan üçüncü kişilere karşı sorumluluğu ortadan kaldırmaz.
5. Müşteri, 5. maddedeki yükümlülüklerine aykırılığı nedeniyle Khriss’e yöneltilen talep, ceza ve zararlardan sorumludur; Khriss, bu Ek’teki veri işleyen yükümlülüklerine aykırılığı nedeniyle Müşteriye yöneltilen talep, ceza ve zararlardan sorumludur.

22. Uygulanacak Hukuk, Bildirimler ve Yürürlük

1. Bu Ek, 6698 sayılı Kişisel Verilerin Korunması Kanunu ve — Müşterinin veya ilgili kişilerin AB/AEA’de bulunması hâlinde — GDPR hükümleri dikkate alınarak yorumlanır. Uygulanacak hukuk ve yetkili mahkeme, Ana Sözleşme’deki hükme tabidir.
2. Bildirimler; Khriss tarafına [email protected] ve gerektiğinde [belirlenecek: KEP adresi] üzerinden, Müşteri tarafına ise 2.2’de beyan edilen adres üzerinden yapılır. [[UYGULANMASI BEKLİYOR: sistemde e-posta gönderim katmanı (SMTP) yapılandırılmamıştır; Khriss bugün hiçbir otomatik e-posta göndermez — parola sıfırlama ve doğrulama bağlantıları, davetler, faturalar ve sözleşme kopyaları dâhil. Bu Ek kapsamındaki bildirimler, katman kurulana kadar bu sayfanın güncellenmesi, uygulama içi duyuru ve elle gönderilen ileti ile yapılır.]]
3. Khriss bu Ek’i, Müşteri aleyhine esaslı bir değişiklik hâlinde en az 30 gün önce bildirmek kaydıyla güncelleyebilir. Müşteri, esaslı değişikliği kabul etmezse hizmeti bu süre içinde feshedebilir. Fesih ve iptal bildirimi bugün [email protected] adresine yazılı olarak yapılır; panelden self-servis iptal veya silme akışı bulunmamaktadır (bkz. 20/2).
4. Bu Ek, 29 Temmuz 2026 tarihinde yürürlüğe girer ve Müşterinin hizmeti kullanmaya devam etmesiyle kabul edilmiş sayılır.

AÇIK KARARLAR — YAYIN ÖNCESİ SAHİBİ TARAFINDAN KARARA BAĞLANMASI GEREKENLER

Bu blok bilinçli olarak metinde bırakılmıştır. Aşağıdaki maddeler karara bağlanıp metne işlenmeden bu Ek imzaya sunulmamalıdır. Hiçbiri hakkında bu belgede varsayım yapılmamıştır.

1. KVKK m.9 yurt dışına aktarım mekanizması. Veri İrlanda’da. Yeterlilik kararı mı, imzadan sonra 5 iş günü içinde Kurul’a bildirilecek standart sözleşme mi, bağlayıcı şirket kuralları mı, yoksa açık rıza mı kullanılacak? Seçim yapılmalı, belge hazırlanmalı, bildirim yapılmalı ve 15. madde bu bilgiyle güncellenmelidir. Bugün hiçbiri yürürlükte değildir.
2. VERBİS. RADONRAD Yazılım ve Elektronik Sistemleri Ticaret Limited Şirketi bakımından çalışan sayısı ve yıllık mali bilanço eşikleri karşısında kayıt yükümlülüğü var mı? Veri işleyen sıfatıyla yapılacak bir kayıt/açıklama gerekiyor mu? Ayrıca Müşteri sözleşmelerinde, Müşterinin kendi VERBİS kaydından sorumlu olduğunun teyidi.
3. Microsoft sözleşme tarafı ve belgeleri. Azure aboneliğinin hangi Microsoft tüzel kişiliğiyle kurulduğu, uygulanan Microsoft Ürünleri ve Hizmetleri Veri Koruma Eki (DPA) sürümü, SCC referansları ve Azure OpenAI için kötüye kullanım izleme (abuse monitoring) muafiyeti başvurusunun yapılıp yapılacağı — belgelenip EK-B’ye işlenmeli.
4. Cloudflare kararı. TLS’in uç ağda sonlanması kabul edilecek mi, yoksa cloud.khriss.com için proxy’siz/uçtan uca bir yapılandırmaya mı geçilecek? Cloudflare DPA/SCC referansları ve önbelleklemenin API yollarında kapalı olduğunun teyidi EK-B’ye eklenmeli.
5. Alt işleyen bildirim ve itiraz süreleri. Metinde 30 gün bildirim / 15 gün itiraz yazıldı. Bu süreler operasyonel olarak taahhüt edilebilir mi; itiraz hâlinde oranlı iade ticari olarak kabul mü?
6. İhlal bildirimi SLA’sı. Metinde “gecikmeksizin ve her hâlde 48 saat” yazıldı. Nöbet düzeni olmayan bir ekipte bu taahhüt sürdürülebilir mi, yoksa “gecikmeksizin, en geç 72 saat” mi yazılmalı?
7. Denetim hakkının sınırları. Yılda bir inceleme, masrafın kime ait olduğu, bağımsız sızma testinin yaptırılıp yaptırılmayacağı ve raporun özetinin Müşterilerle paylaşılıp paylaşılmayacağı.
8. Operatörün şifre çözebilmesi karşısında sunulacak taahhüt. Müşterinin anahtarı kendisinin tuttuğu bir mod (BYOK/HYOK) yol haritasına alınacak mı? Alınmayacaksa, kurumsal alıcıya verilecek yazılı gerekçe ne olacak?
9. Yedeklerin ikinci bölge/hesap kopyası. Off-site kopya alınacak mı? Alınacaksa hedef bölge veri yerleşimi beyanını (6. ve 15. maddeler) değiştirir ve EK-B’ye yeni bir satır ekler.
10. Şirket kimlik alanları. Metinde çift süslü parantezle işaretlenmiş tüm şirket alanları doldurulmalıdır: unvan, hukuki form, adres, ticaret sicil no, MERSİS, vergi dairesi + VKN/TCKN, KEP adresi, telefon, destek e-postası, kişisel veri bildirim e-postası.
11. Tüketici satışı belgeleri (bu Ek’in kapsamı dışında ama satışın ön koşulu). Ön Bilgilendirme Formu ile Mesafeli Satış Sözleşmesi ayrı ve ikisi de zorunlu belgelerdir ve ödemeden önce sunulmalıdır. Anında ifa edilen dijital içerikte 14 günlük cayma hakkının kullanılamaması, ancak tüketicinin ön onayı ve cayma hakkını yitirdiğini kabul ettiğine dair beyanı alınmışsa mümkündür; ödeme akışının bu onayı ayrı bir kutu olarak kayıt altına alması gerekir. Bu onay akışı henüz kurulmadı.
12. KDV ve fatura. Fiyatların KDV dâhil mi hariç mi gösterileceği ve e-Arşiv fatura entegrasyonunun ne zaman devreye alınacağı (bugün uygulanmamıştır).
13. Saklama motorunun kapsamı. Mesele yalnızca varsayılan süre seçmek değildir: motor bugün altı kayıt sınıfını kapsıyor ve içerik sınıflarını (doküman, chunk, ham dosya, vektör) hiç kapsamıyor; ayrıca uygulaması zamanlanmış bir işe bağlı değil, elle tetikleniyor. Karar: (a) içerik sınıfları motora eklenecek mi ve hangi silme semantiğiyle (chunk + vektör + ham dosya + dizin birlikte)? (b) uygulama gecelik bir işe bağlanacak mı? (c) ancak bunlardan sonra kurumsal Müşterilere önerilecek varsayılan süreler (denetim kaydı, egress defteri, sohbet geçmişi) belirlenebilir. Bugünkü hâliyle Müşteri, kendi saklama-imha politikasını içerik bakımından bu ürünle uygulayamaz.
14. Alım anındaki egress varsayılanı. Varlık/ilişki çıkarımı hem kurulum hem kaynak düzeyinde varsayılan açık ve her yeni dokümanın ilk ~6.000 karakterini buluta gönderiyor. Bulut sürümünde bu varsayılan kapalıya çevrilip Müşterinin açık tercihine mi bağlanacak, yoksa açık kalıp kayıt (onboarding) akışında ayrıca onaylatılacak mı? Bu karar 13/1 ve EK-B’yi doğrudan etkiler.
15. Müşteriye açık iptal ve silme. Askıya alma/silme/geri getirme bugün yalnızca operatör uç noktalarında. Müşteriye açık bir “aboneliği iptal et / çalışma alanını sil” akışı ne zaman yapılacak? Yapılana kadar destek adresi üzerinden yürüyen usul, tüketici mevzuatı ve GDPR m.17 bakımından yeterli sayılıyor mu?
16. Egress defterinin erişim denetimi. Defter bugün Kiracının her üyesine açık. Bu bilinçli bir şeffaflık tercihi olarak korunacak mı, yoksa view_audit iznine mi bağlanacak? Bir dışa aktarma uç noktası eklenecek mi?
17. E-posta gönderim sağlayıcısı (SMTP). Sağlayıcı seçildiğinde: EK-B’ye alt işleyen olarak eklenmeli, 14/2 bildirim süreci başlatılmalı ve 17. maddedeki manuel bildirim istisnası kaldırılmalıdır.
18. KVKK idari para cezalarının taraflar arasındaki dağılımı ve toplam sorumluluk sınırının bu Ek bakımından ayrıca belirlenip belirlenmeyeceği.

EK-A — Teknik ve İdari Tedbirler

Bu ek, yalnızca hâlihazırda uygulanmakta olan tedbirleri sayar. Planlanan ama kurulmamış olanlar açıkça işaretlenmiştir. Bir sertifikasyon beyanı değildir.

A.1 Kiracı izolasyonu (üst üste binen dört mekanizma)

• Her kiracı için ayrı Postgres şeması (t_<hex>).
• Her kiracı için ayrı Postgres rolü; bağlantılar o rolle açılır, dolayısıyla veritabanı düzeyinde de yetki sınırı vardır.
• Her kiracı için ayrı Qdrant vektör koleksiyonu.
• Uygulama düzeyinde kiracıya özgü DEK ile kolon şifrelemesi; DEK sarmalarında kiracı kimliği AAD olarak bağlıdır, böylece bir kiracının sarılmış anahtarı başka kiracı bağlamında açılamaz. Bu kripto izolasyonunun kapsamı chunk metnidir (bkz. A.2); bağlantı sırları ve OAuth jetonları kiracıya özgü DEK ile değil, tüm kurulum için ortak tek bir uygulama anahtarı (Fernet) ile korunur — bu veri sınıfı bakımından kriptografik kiracı izolasyonu yoktur, izolasyon şema ve rol düzeyinde kalır.
• Bu izolasyon, kod deposundaki bir isolation proof testiyle doğrulanır: veri izolasyonu, erişim izolasyonu ve kripto izolasyonu ayrı ayrı sınanır.

A.2 Şifreleme

• Aktarım hâlinde: HTTPS/TLS. TLS, Cloudflare uç ağında sonlanır (bkz. 15/1 ve EK-B).
• Durağan hâlde: chunk metni için AES-256-GCM uygulama düzeyi şifreleme — domain modelinde uygulama düzeyinde şifrelenen tek alan budur; kiracı DEK’i operatör KEK’i ile sarılı.
• Şifrelenmeyenler (dürüst kapsam). Doküman başlıkları ve URI’leri, kişi/şirket adları ve özetleri, tanımlayıcılar, takvim ve görev içerikleri, tam metin arama dizini (chunk_fts tsvector — leksemler ve konumlarıyla, ve pg_dump’a dâhil), Qdrant vektörleri ve yükleri, diskteki ham dosyalar ve denetim/egress kayıt satırları uygulama katmanında düz metindir. Bu nedenle disk imajı veya yedek ele geçirilmesine karşı koruma kısmîdir; geri kalanı koruyan tedbirler şema/rol izolasyonu, TLS ve bulut sağlayıcı katmanındaki disk şifrelemesidir.
• KEK arka uçları: dosya tabanlı (AES-256-GCM), Azure Key Vault (RSA-OAEP-256 ile sarma) veya HashiCorp Vault Transit. Her sarılmış DEK, kendisini saran KEK sürümünü kaydeder; böylece döndürme sonrası eski anahtarlar açılabilir kalır.
• KEK anahtar zinciri için “canary” doğrulaması: yanlış veya yeni üretilmiş bir anahtar zinciriyle açılış, verinin sessizce açılamaz hâle gelmesinden önce tespit edilir.
• Anahtar döndürme: yeni etkin KEK sürümü üretimi + kiracı DEK’lerinin yeniden sarılması (rewrap) için ayrı bir işlem vardır.

A.3 Kimlik doğrulama, yetkilendirme ve oturum

• Sunucu tarafında izlenen oturumlar; her yenilemede döndürülen refresh jetonu ve yeniden kullanım tespitinde jeton ailesinin iptali (böylece çalınmış jeton fark edilir ve oturum gerçekten kapatılabilir).
• Çok faktörlü kimlik doğrulama (TOTP, RFC 6238) ve tek kullanımlık kurtarma kodları (yalnızca tuzlanmış SHA-256 özeti saklanır).
• OIDC ile kurumsal tek oturum açma (SSO) ve SCIM 2.0 ile kullanıcı sağlama/geri alma (kiracıya özgü SCIM jetonu; jetonun yalnızca SHA-256 özeti saklanır).
• Reddet-öncelikli (deny-by-default) RBAC: sabit izin kataloğu (okuma, yazma, kaynak silme, onay, görev çalıştırma, ayarlar, egress yönetimi, bağlayıcılar, PII görüntüleme, denetim görüntüleme, üye yönetimi, faturalama) ve sabit rol seti (owner, admin, member, viewer, operator, system).
• Hesap bazlı başarısız giriş kilitlemesi.
• Hız sınırlama: kimlik doğrulanmamış ve sağlama yüzeyinde (giriş, kayıt, parola sıfırlama, doğrulama, koltuk talebi, çalışma alanı oluşturma, ödeme) Redis tabanlı sabit pencere sayacı; işçiler arasında paylaşımlıdır. Dürüst not: Redis erişilemediğinde limitleyici açık devre kalır — bu, tüm müşterilerin girişini kilitlememek için bilinçli bir erişilebilirlik tercihidir.

A.4 Kayıt ve izlenebilirlik

• Hash-zincirli, ekleme-yalnızca denetim kaydı (her kiracının kendi şeması içinde): kim, neyi, hangi nesne üzerinde, ne zaman; satırın özeti önceki satırın özetini içerir, dolayısıyla bir satırın değiştirilmesi veya silinmesi zinciri kırar ve doğrulama bunu tespit eder.
• Egress defteri (yazma çağrıdan önce): her bulut yapay zekâ çağrısı için, soket açılmadan önce pending durumunda bir satır yazılır ve kesinleştirilir; yanıt geldiğinde ok, hata/zaman aşımında error olarak sonlandırılır. Ön yazma başarısız olursa çağrı reddedilir. Kaydedilenler: model, amaç, hedef sunucu, istek boyutu, istek gövdesi özetinin sha256 ön eki, karakter sayıları, tetikleyen kullanıcı ve içeriği isteme giren kaynak kimlikleri.
• Kontrol düzleminde ekleme-yalnızca güvenlik kaydı: giriş başarı/başarısızlıkları, jeton üretimi, kiracı yaşam döngüsü olayları, operatör eylemleri.
• Denetim kaydı Müşteri tarafından dışa aktarılabilir ve zincir doğrulama işlevi vardır. Egress defteri hizmet içinde okunabilir ancak dışa aktarılamaz ve okuması bugün bir izne bağlı değildir (bkz. 13/6). Her iki kayıt da Kiracının kendi şemasındaki tablolardır; değiştirilemez değildirler ve bağımsız olarak tasdik edilmemişlerdir.

A.5 Veri minimizasyonu ve egress kontrolü

• Tek çıkış noktası (chokepoint) mimarisi; kaynak bazlı local_only işareti tel üzerinde son kez uygulanır.
• Kiracı bazlı egress ana anahtarı: kapatıldığında bulut modeline ve web aramasına hiçbir çağrı yapılmaz.
• Kiracı bazlı egress kotası/hız sınırı.
• Bağlayıcılar yalnızca Müşterinin yetkilendirdiği kaynaklardan çekme yapar; WhatsApp bağlayıcısı yalnızca okuma yapar.
• Dürüst not (veri minimizasyonu bakımından belirleyicidir): alım anındaki varlık/ilişki çıkarımı varsayılan olarak açıktır ve her yeni dokümanın ilk yaklaşık 6.000 karakterini buluta gönderir; gecelik konsolidasyon, gelen kutusu puanlama, uyarı taraması ve takip işleri kullanıcı yokken de çalışır. Bu yolların hepsi tek çıkış noktasından geçer ve deftere yazılır, ancak “yalnızca sorulan soru çıkar” doğru değildir (bkz. 13/1). Minimizasyon isteyen Müşteri, kaynak bazlı extract_graph’ı kapatmalı, gerekiyorsa kaynağı local_only işaretlemeli veya egress ana anahtarını kapatmalıdır.

A.6 Saklama, silme ve erişilebilirlik

• Veri sınıfı bazlı saklama motoru (varsayılan: süresiz), hukuki muhafaza anahtarı, kuru çalışma modu ve her silmenin denetim kaydına yazılması. Kapsam yalnızca altı kayıt sınıfıdır (denetim olayları, egress defteri, eylem kaydı, sohbet iletileri, epizodlar, getirme geri bildirimleri); yazışma içeriği, dokümanlar, chunk’lar, varlıklar, vektörler ve ham dosyalar bu motora tabi değildir (bkz. 20/1). Uygulama bugün elle tetiklenir; zamanlanmış bir iş yoktur.
• Kişi (veri öznesi) düzeyinde silme: önce tablo bazlı sayım, sonra onaylı uygulama. Kapsam: varlık, tanımlayıcılar, kişi profili, ilişki kenarları ve o kişi hakkındaki türetilmiş kayıtlar. Kapsam dışı: dokümanlar ve chunk’lar, Qdrant vektörleri ve yükleri, ham dosyalar, tam metin dizini (bkz. 16/2).
• Kiracı düzeyinde silme: 7 günlük geri dönüş penceresi, sonra şema + rol + Qdrant koleksiyonu + ham dosya dizini + sarılmış DEK kaydının kalıcı silinmesi. Silme talebi bugün yalnızca operatör uç noktalarından başlatılabilir (bkz. 20/2).
• Gecelik yedek: kontrol düzlemi ve her canlı kiracı tek bir tarihli jenerasyona alınır, her bileşen doğrulanır, doğrulama başarısızsa iyi bir jenerasyon budanmaz; 7 jenerasyon saklanır. Kapsam: kiracı şeması dökümü, Qdrant noktaları ve sarılmış DEK kaydı ile kontrol düzlemi dökümü ve KEK anahtar zinciri. Kapsam dışı: ham dosya dizini ve ortak Fernet uygulama anahtarı yedeklenmez — yani gecelik yedek tam kapsamlı bir yedek değildir.
• Haftalık geri yükleme tatbikatı: yedek, canlı veritabanına dokunmadan ayrı bir çalışma alanına geri yüklenerek sınanır; sonuç iş durumu kaydına yazılır.
• Yedek dosyaları kısıtlı izinlerle (umask 0077) yazılır; yedeklerin içindeki DEK’ler sarılmış hâlde kalır.

A.7 Uygulanmayanlar (dürüst boşluk listesi)

• [[UYGULANMASI BEKLİYOR: ISO/IEC 27001 sertifikasyonu — yoktur.]]
• [[UYGULANMASI BEKLİYOR: SOC 2 Tip I/II raporu — yoktur.]]
• [[UYGULANMASI BEKLİYOR: bağımsız sızma testi — yapılmamıştır.]]
• [[UYGULANMASI BEKLİYOR: yedeklerin ikinci bir bölgeye/hesaba off-site kopyalanması — yedekler barındırma bölgesindeki dosya sisteminde tutulur.]]
• [[UYGULANMASI BEKLİYOR: operatör erişimi için tam-zamanında onay ve müşteriye erişim raporlaması.]]
• [[UYGULANMASI BEKLİYOR: e-posta gönderim katmanı (SMTP) — otomatik güvenlik/uyum bildirimleri gönderilemiyor.]]
• [[UYGULANMASI BEKLİYOR: 7/24 nöbet (on-call) düzeni.]]
• [[UYGULANMASI BEKLİYOR: müşteri tarafından tutulan anahtar (BYOK/HYOK) modu.]]
• [[UYGULANMASI BEKLİYOR: Türkiye içinde barındırma bölgesi seçeneği.]]
• [[UYGULANMASI BEKLİYOR: özel nitelikli veri otomatik tespiti/maskeleme.]]
• [[UYGULANMASI BEKLİYOR: ham dosya dizininin şifrelenmesi ve tam metin dizini (tsvector) ile Qdrant yükleri gibi içerik türevlerinin korunması — bugün düz metindir.]]
• [[UYGULANMASI BEKLİYOR: ham dosya dizininin gecelik yedeğe ve dışa aktarıma dâhil edilmesi — bugün yedeklenmiyor ve arşive girmiyor.]]
• [[UYGULANMASI BEKLİYOR: bağlantı sırlarının ortak Fernet uygulama anahtarından kiracıya özgü DEK’e taşınması ve bu anahtarın yedek/kurtarma prosedürüne alınması.]]
• [[UYGULANMASI BEKLİYOR: doküman/chunk düzeyinde redaksiyon ile vektör ve ham dosya temizliği — kişi düzeyinde silme bunları kapsamıyor.]]
• [[UYGULANMASI BEKLİYOR: saklama motorunun içerik sınıflarını kapsaması ve zamanlanmış bir işe bağlanması — bugün yalnızca altı kayıt sınıfı ve elle tetikleme.]]
• [[UYGULANMASI BEKLİYOR: egress defteri okumasının view_audit iznine bağlanması ve dışa aktarma uç noktası.]]
• [[UYGULANMASI BEKLİYOR: Müşteriye açık abonelik iptali ve Kiracı silme talebi uç noktası/arayüzü — bugün yalnızca operatör uç noktaları var.]]
• [[UYGULANMASI BEKLİYOR: SSO yapılandırılmış Kiracılarda kalıcı silmenin kontrol düzlemi kayıtlarını (sarılmış DEK dâhil) da güvenilir biçimde silmesi — bilinen hata, bkz. 20/3.]]
• [[UYGULANMASI BEKLİYOR: altyapının kod olarak tanımlanması (IaC) — barındırma yapılandırması bugün depoda değil, kaydı REPORT/hosting-evidence.md’dedir.]]

EK-B — Alt İşleyen Listesi

Aşağıdaki liste, Khriss Bulut sürümü için tam alt işleyen listesidir. Khriss Bulut’ta analitik, ürün içi kullanım izleme, hata raporlama veya reklam amaçlı üçüncü taraf hizmet kullanılmaz. Yerel/Masaüstü sürümde, bulut yapay zekâ kapalıyken alt işleyen sayısı sıfırdır.

B.1 Alt işleyen olmayan taraflar

Müşterinin bağladığı kaynak sistemler (Gmail, IMAP sunucuları, Google Takvim/Drive/Kişiler, Outlook, Slack, Teams, WhatsApp, Telegram, Notion, Jira, HubSpot, Salesforce, Stripe, QuickBooks, Xero ve diğerleri; toplam 180’i aşan bağlayıcı) Khriss’in alt işleyeni değildir. Bunlar Müşterinin kendi hizmet sağlayıcılarıdır; Khriss bu sistemlere yalnızca Müşterinin verdiği yetkiyle bağlanarak veri çeker. Bu sistemlerle olan veri koruma ilişkisi Müşteriye aittir.

B.2 Khriss’in kendi işlettiği bileşenler

Postgres 16, Qdrant ve Redis üçüncü taraf hizmetler olarak satın alınmaz; Khriss tarafından yukarıdaki Azure altyapısı üzerinde işletilen yazılımlardır. Bu nedenle ayrı alt işleyen olarak listelenmemişlerdir; verinin bulunduğu yer Azure North Europe’dur. Redis yalnızca kuyruk, kota ve kilit gibi geçici durum bilgisi tutar.

B.3 Değişiklik kaydı

Bu liste değiştiğinde sürüm numarası ve tarih güncellenir; 14. maddedeki bildirim ve itiraz usulü uygulanır. Yürürlükteki sürüm her zaman bu sayfada yayımlanır.