TasarrufYap — Açık Rıza Metinleri

⚠️ BU METİN HUKUKİ TAVSİYE DEĞİLDİR — TASLAKTIR
Bu dosya, hangi işlemler için açık rıza gerektiğini ve gerekmediğini gerekçeleriyle
tespit eden bir çalışma belgesidir; içindeki rıza metinleri henüz kullanıma hazır değildir.
Avukat onayı alınmadan hiçbir rıza ekranı yayına alınmamalıdır.

0. Bu belgenin çıkış noktası: rıza son çaredir

KVKK'da açık rıza, işleme dayanaklarından biridir, birincisi değildir. Md.5/2'de sayılan bir dayanak (sözleşmenin ifası, hukuki yükümlülük, meşru menfaat vb.) varken ayrıca rıza istemek üç ayrı sorun üretir:

1. Yanıltıcıdır. Kullanıcı, rızasını geri çekerse işlemenin duracağını sanır; oysa dayanak

başka bir maddeyse işleme devam eder.

1. Geçersiz olabilir. Hizmetin alınabilmesi rızaya bağlanmışsa rıza "özgür irade" ile

verilmiş sayılmaz. Hizmetin ifası için zorunlu bir veriyi rızaya bağlamak tam olarak bu sakatlığı doğurur.

1. Yönetim yükü getirir. Her rıza; sürüm, zaman ve geri çekme kaydı tutmayı, geri çekme

hâlinde veriyi gerçekten silmeyi gerektirir.

Bu nedenle aşağıda önce rıza gerektirmeyenler ve gerekçeleri yazılmıştır.

A. Şu anda açık rıza İSTENMEYEN işlemler ve gerekçeleri

Sonuç: Uygulamanın bugünkü hâlinde kullanıcıdan alınması gereken zorunlu bir açık rıza YOKTUR. Kayıt akışında kullanıcıya gösterilmesi gereken şey bir rıza kutusu değil, aydınlatma metnidir (KVKK md.10) — bkz. KVKK-AYDINLATMA.md.

B. Avukat kararına bağlı tek nokta: hassas kategori (Sağlık)

Durum

Yeni kullanıcıya açılan hazır gider kategorilerinden "Sağlık" veritabanında is_sensitive = true işaretiyle tutulur. Kullanıcı bu kategoriye harcama girerse kayıt (tutar + tarih + kategori etiketi) sistemde saklanır.

Uygulamanın hâlihazırdaki koruması (kodda doğrulanmıştır)

• Hassas kategoriler hiçbir analiz/öneri/yapay zekâ yoluna varsayılan olarak girmez —

uygulamada zaten böyle bir yol bulunmamaktadır.

• Sağlık durumu, teşhis, ilaç veya tedavi çıkarımı yapılmaz.
• Kayıt yalnızca kullanıcının kendi defterinde tutulur; satır düzeyi güvenlik nedeniyle başka

hiçbir kullanıcı erişemez.

Karar sorusu

Kullanıcının kendi girdiği "Sağlık" etiketli bir harcama satırı, KVKK md.6 anlamında
sağlık verisi sayılır mı? Sayılırsa, yalnızca saklama amaçlı işleme için de açık rıza
gerekir mi?

Karar "gerekmez" çıkarsa

Yapılacak bir şey yoktur; mevcut durum korunur, KVKK-AYDINLATMA.md bölüm 3'teki açıklama yeterlidir.

Karar "gerekir" çıkarsa — hazır metin

Aşağıdaki metin ancak avukat onayından sonra kullanılabilir. Kullanıcı bu rızayı vermezse uygulama çalışmaya devam etmeli, yalnızca hassas kategori kapatılmalıdır (rızanın "özgür irade" niteliğini koruyabilmek için hizmet buna bağlanamaz).

Sağlık gibi hassas kategorilerde harcama kaydı tutulması

TasarrufYap'ta "Sağlık" kategorisine bir harcama girdiğinizde, bu kayıt (tutar, tarih
ve kategori adı) hesabınızda saklanır ve size geri gösterilir.

Bu kaydı:
· sadece siz görürsünüz,
· hiçbir analiz, öneri veya yapay zekâ işlemine sokmayız,
· hiçbir üçüncü tarafla paylaşmayız,
· sağlık durumunuz hakkında hiçbir çıkarım yapmak için kullanmayız.

Bu kutuyu işaretlemezseniz uygulama normal şekilde çalışmaya devam eder; yalnızca
hassas kategoriler kapatılır ve bu harcamaları isterseniz "Diğer" kategorisine
girebilirsiniz.

Bu onayı istediğiniz zaman Ayarlar > Gizlilik bölümünden geri çekebilirsiniz. Geri
çektiğinizde, hassas kategorilerde daha önce girdiğiniz kayıtları silmenizi veya başka
bir kategoriye taşımanızı isteriz.

[ ] Hassas kategorilerde harcama kaydı tutulmasına açık rıza veriyorum.

• Rıza kaydı: consent_events tablosuna purpose = 'sensitive_categories', metin sürümü ve

zaman damgasıyla yazılır.

• Geri çekme: aynı tabloya granted = false kaydı yazılır ve kullanıcıya mevcut hassas

kayıtları için ne yapılacağı sorulur.

C. Bugün YOK olan, ileride açılırsa açık rıza gerektirecek işlemler

Aşağıdakilerin hiçbiri uygulamada mevcut değildir. Her biri devreye alınırken ayrı ayrı, paket hâlinde değil, kendi amacıyla rıza istenmelidir. "Tümünü kabul ediyorum" biçiminde tek bir kutu KVKK'ya aykırıdır.

C.1 Yapay zekâ destekli koçluk / öneri (v2)

Yapay zekâ destekli öneriler

Harcama ve ödeme kayıtlarınızın bir özetini, size kişisel öneri üretmesi için bir
yapay zekâ hizmetine göndermemize izin veriyor musunuz?

· Gönderilecek olan: kategori bazında toplamlar ve ödeme takvimi özeti.
· Gönderilmeyecek olan: e-posta adresiniz, serbest metin açıklamalarınız, hassas
  kategorilerdeki kayıtlarınız, kurum adları.
· Hizmet sağlayıcı: Henüz yapay zekâ özelliği YOK ve hiçbir veri bir yapay zekâ hizmetine gönderilmiyor. Bu bölüm, özellik eklenirse doldurulacaktır; o güne kadar bu rıza istenmez.
· Bu işlem yurt dışına veri aktarımı içerir: [DOLDURULACAK: KVKK md.9 dayanağı]

Bu onayı vermezseniz uygulamanın diğer tüm özellikleri aynen çalışır.
Onayınızı istediğiniz zaman geri çekebilirsiniz.

[ ] Yapay zekâ destekli öneriler için açık rıza veriyorum.

purpose = 'ai_coach'. Ön koşul: serbest metin açıklamaların ve is_sensitive işaretli kategorilerin gönderilen özete girmediğini kanıtlayan otomatik test.

C.2 Kullanım ölçümü / analitik

Kullanım istatistikleri

Uygulamayı geliştirebilmek için hangi ekranların ne sıklıkta kullanıldığını ölçmemize
izin veriyor musunuz?

· Ölçülecek olan: ekran açılışları, özellik kullanım sayıları, hata olayları.
· Ölçülmeyecek olan: tutarlar, açıklamalar, kurum adları, e-posta adresiniz.
· Araç: Henüz analitik aracı KULLANILMIYOR. Bu bölüm, analitik devreye alınırsa doldurulacaktır; o güne kadar bu rıza istenmez.

Bu onayı vermezseniz uygulama aynen çalışır.

[ ] Kullanım istatistiklerinin toplanmasına açık rıza veriyorum.

purpose = 'analytics'. Not: Meşru menfaat dayanağı tartışılabilir; ancak varsayılan kapalı, rızaya bağlı ve gövdesi kişisel veriden arındırılmış bir ölçüm hem daha güvenli hem de proje kuralına (log/telemetri gövdesinde tutar, açıklama, kurum adı, e-posta bulunmaz) uygundur.

C.3 Ticari elektronik ileti (pazarlama e-postası)

Hizmete dair zorunlu iletiler (doğrulama, parola sıfırlama, güvenlik uyarısı) rıza gerektirmez. Bunun dışında kalan tanıtım, kampanya ve duyuru e-postaları için:

• KVKK açık rızası ve
• 6563 sayılı Kanun kapsamında ayrıca onay ve İYS (İleti Yönetim Sistemi) kaydı

gerekir. [DOLDURULACAK: İYS kaydı yapılacak mı — pazarlama iletisi gönderilmeyecekse bu madde tümüyle kaldırılır]

purpose = 'marketing_email'.

C.4 Otomatik harcama yakalama (SMS / bildirim okuma) — v2, yalnız Android

Bu özellik devreye alınırsa hem KVKK açık rızası hem Android çalışma-zamanı izni hem de Google Play'in özel SMS izin politikası kapsamında ayrı beyan gerekir. Metin, özellik tasarlandığında yazılacaktır.

D. Yurt dışına aktarım için NEDEN açık rıza kullanılamaz

Bu bölüm, ileride "kullanıcıya sorup Moldova'da tutmaya devam edelim" fikri gündeme gelirse diye bilerek yazılmıştır.

• KVKK md.9, yurt dışına aktarım için sıralı bir çerçeve kurar: önce yeterlilik kararı,

yoksa uygun güvenceler (standart sözleşme + Kurul'a bildirim, bağlayıcı şirket kuralları, taahhütname), bunlar da yoksa yalnızca arızi hâllerde sayılan istisnalar.

• Açık rıza, bu üçüncü grupta yer alır ve "arızi olmak" şartına bağlıdır. Uygulamanın

tüm verisinin sürekli olarak yurt dışındaki bir sunucuda barındırılması arızi değil, rutin ve kesintisiz bir aktarımdır.

• Bu nedenle üretim veritabanının yurt dışında tutulması açık rızayla meşrulaştırılamaz.

İki geçerli yol vardır:

1. Veriyi Türkiye'ye taşımak (projenin verdiği karar — docs/adr/0002-veri-barindirma.md), ya da
2. Yurt dışında kalınacaksa uygun güvenceyi kurmak: standart sözleşme imzalamak ve

imza tarihinden itibaren Kurul'a bildirimde bulunmak.

• Aynı değerlendirme e-posta gönderim sağlayıcısı için de geçerlidir: sağlayıcı yurt

dışındaysa aktarım rutindir, açık rızaya değil uygun güvenceye bağlanmalıdır. [BEKLEMEDE: SMTP sağlayıcısı seçilince md.9 dayanağı belirlenecek]

Bu değerlendirme bir hukukçu tarafından teyit edilmelidir; md.9 çerçevesi ve Kurul
uygulaması güncel hâliyle kontrol edilmelidir.

E. Rıza tasarımı kuralları (uygulanacak)

Bir rıza devreye alındığında aşağıdakiler zorunludur:

1. Varsayılan işaretli kutu yasak. Kutu boş gelir; kullanıcı işaretler.
2. Paket rıza yasak. Her amaç için ayrı kutu; "hepsini kabul et" tek kutusu olmaz.
3. Hizmet rızaya bağlanamaz. Rıza verilmediğinde uygulama çalışmaya devam eder.
4. Geri çekme, vermek kadar kolay olur. Ayarlar içinde tek dokunuşla ulaşılabilir.
5. Kayıt tutulur. consent_events tablosuna amaç, metin sürümü, onay/ret ve zaman

yazılır. Metin değişirse sürüm artar ve rıza yeniden alınır.

1. Geri çekme sonucu gerçekten uygulanır. Rıza geri çekildiğinde ilgili işleme durur ve

yalnızca o rızaya dayanılarak toplanmış veri silinir.

1. Aydınlatma rızadan önce gelir. Rıza ekranı, aydınlatma metninin yerine geçmez.

Uyarı — kodda eksik: consent_events tablosu vardır ancak **bu tabloya yazan hiçbir
uygulama kodu yoktur**. Herhangi bir rıza devreye alınmadan önce yazma, okuma ve geri
çekme akışı yazılmalı ve testle korunmalıdır.