Bir çalışan, performans değerlendirme tablosunu bir sohbet penceresine yapıştırıp "bunu özetler misin" diyor. Tabloda isimler, maaş bantları ve sağlık izni notları var. Bu tek hareket, kurumun veri işleme envanterinde yer almayan bir aktarımı, çoğu zaman yurt dışına, hiçbir kaydı tutulmadan gerçekleştiriyor.
Bu yazı bu problemi hukuk metni yazarak değil, sistem kurarak çözmekle ilgili. KVKK'nın ne olduğunu anlatmayacağım; onu yapan çok kaynak var. Buradaki soru daha dar ve daha teknik: kurumsal veriyi büyük dil modellerine verirken hangi kontrolleri mimariye gömerseniz, uyum bir politika belgesi olmaktan çıkıp sistemin davranışına dönüşür.
Aşağıdaki yedi kontrolün ortak mantığı şu: çalışanın doğru davranmasına bel bağlamayın. Bir kontrol yalnızca eğitimle sağlanıyorsa, o kontrol yoktur — er ya da geç yoğun bir gün gelir. Bu kararların çoğu aslında mimari kararlardır ve kurumsal yapay zekâ projelerinde yapay zekâ danışmanlığı tarafının en çok vakit harcadığı yer burasıdır.
Bu yazı mühendislik perspektifiyle yazılmış teknik bir çerçevedir, hukuki görüş değildir. Kurumunuzun özel durumu için hukuk ve uyum ekibinizle birlikte değerlendirin.
Yasak listesi neden işe yaramıyor
Çoğu kurumun ilk refleksi bir yasak yayımlamak oluyor: "kişisel veri içeren belgeleri yapay zekâ araçlarına yüklemek yasaktır." Bu cümle gerekli ama tek başına iki sebeple yetersiz.
Birincisi, çalışan bir belgenin kişisel veri içerip içermediğini her zaman bilemez. Bir hata kaydının içine düşmüş bir e-posta adresi, bir ekran görüntüsünün köşesinde kalan müşteri adı, bir CSV'nin on beşinci sütunu — hepsi kişisel veridir ve hiçbiri "kişisel veri belgesi" gibi görünmez.
İkincisi ve daha önemlisi: yasak, ihtiyacı ortadan kaldırmaz. Çalışan o özeti gerçekten istiyor. Kanal kapatıldığında iş kaybolmaz, görünmezleşir — kişisel cihaza, kişisel hesaba, kurumun hiç göremeyeceği bir yere taşınır. Uyum açısından en kötü senaryo budur, çünkü artık ne kaydı vardır ne de sınırı.
İşleyen yaklaşım, yasak yerine kanal tasarımı: çalışanın ihtiyacını karşılayan, ama verinin nereye gittiği kurum tarafından belirlenmiş bir yol açmak. Yedi kontrol bu yolu tarif ediyor.
Kontrol 1 — Veri sınıfını çalışana değil sisteme sorun
Başlangıç noktası, "hangi veri gidebilir" sorusunun cevabını insan yargısından çıkarmaktır. Üç kategori pratikte yeterli oluyor:
- Serbest: kamuya açık veya kurum içi genel bilgi. Ürün dokümanı, mevzuat metni, pazarlama içeriği. Doğrudan modele gidebilir.
- Şartlı: kişisel veri içerebilir ama iş için gerekli. Müşteri yazışması, destek kaydı, sözleşme taslağı. Ancak Kontrol 2'deki ayıklamadan geçerek gidebilir.
- Gitmez: özel nitelikli kişisel veri (sağlık, biyometrik, sendika, din), kimlik numarası, kart bilgisi, kimlik doğrulama sırları. Hiçbir koşulda, hiçbir sağlayıcıya.
Bu sınıflandırmanın değeri listenin kendisinde değil, nerede uygulandığında. Sınıf bilgisi belgenin bulunduğu sistemde (belge yönetimi, CRM, veri ambarı) etiket olarak duruyorsa, aktarım kararını sistem verebilir. Yalnızca politikada duruyorsa, kararı yorgun bir insan verir.
Kontrol 2 — Sınırda ayıklama: veri çıkmadan önce temizlensin
Şartlı sınıftaki veri için tek geçerli mekanizma, modele gitmeden önce kişisel tanımlayıcıların ayıklanmasıdır. Bunu uygulama katmanında, aktarımın gerçekleştiği yerde yapın — kullanıcıdan önce, sağlayıcıdan önce.
Pratikte iki seviye var. Maskeleme, tanımlayıcıyı tamamen kaldırır: ad, e-posta, telefon, TCKN, IBAN yerine sabit bir yer tutucu geçer. Model için çoğu görev bu haliyle bozulmaz — bir talebi sınıflandırmak veya bir yazışmayı özetlemek için müşterinin adına ihtiyaç yoktur. Takma adlaştırma ise tanımlayıcıyı tutarlı bir jetonla değiştirir (MUSTERI_17), böylece metin içindeki ilişkiler korunur ve çıktı geri eşleştirilebilir. Aynı kişinin metnin üç yerinde geçtiğini modelin görmesi gerekiyorsa bu ikincisi gerekir.
Kritik ayrım şu: ayıklama geri döndürülebilir olmalıysa, eşleştirme tablosu asla modelin gördüğü tarafta durmaz. Tablo sizin sisteminizde kalır; modele giden metinde yalnızca jeton bulunur.
Kontrol 3 — Sağlayıcı katmanını bilerek seçin
Aynı markanın ücretsiz arayüzü ile kurumsal sözleşmeli sürümü, veri açısından farklı iki üründür. Fark tek bir noktada toplanır: girdiğiniz veri model eğitiminde kullanılıyor mu, kullanılmıyor mu. Kurumsal katmanlar tipik olarak kullanılmayacağını taahhüt eder; tüketici katmanları çoğu zaman etmez.
Karar verirken sözleşmede aranacak dört şey var: eğitimde kullanılmama taahhüdü, veri saklama süresi (ve sıfırlanabiliyor mu), işleme yapılan coğrafi bölge, ve alt işleyen listesi. Bunlar pazarlama sayfasında değil, veri işleme ekinde yazar. Ekin bulunamadığı bir sağlayıcı, kurumsal kullanım için değerlendirme dışıdır.
Üçüncü bir seçenek de var ve hafife alınıyor: modeli kendi altyapınızda çalıştırmak. Açık ağırlıklı modellerin son iki yıldaki gelişimi, birçok sınıflandırma ve özetleme işini kurum içinde çözülebilir hale getirdi. Veri hiç çıkmıyorsa, aktarım tartışmasının tamamı ortadan kalkar. Aynı mantık otomasyon tarafında da geçerli — n8n ile otomasyon akışlarını kendi sunucunuzda çalıştırmayı önermemin sebebi tam olarak budur.
Kontrol 4 — Aktarım kararını mimariye yazın, politikaya değil
Yurt dışına veri aktarımı hukuki bir konu; ama sonucu teknik bir kısıttır. Kurum "bu veri yurt dışına çıkmayacak" dediğinde, bu cümlenin karşılığı bir eğitim slaytı değil, bir yapılandırma olmalıdır: hangi uç noktaya gidileceği, hangi bölgenin seçildiği, ağ seviyesinde başka nereye çıkılamayacağı.
Pratik uygulama şöyle görünür: yapay zekâ çağrıları uygulamalardan doğrudan değil, tek bir geçit üzerinden yapılır. Geçit; sınıflandırmayı kontrol eder, ayıklamayı uygular, sağlayıcıyı ve bölgeyi belirler, kaydı tutar. Tek çıkış noktası olması, denetlenebilir olmasının da ön koşuludur. Onlarca uygulamanın kendi anahtarıyla kendi başına çağrı yaptığı bir kurumda, hangi verinin nereye gittiğini kimse söyleyemez.
Kontrol 5 — Kim ne sordu: kayıt ve saklama
Bir veri ihlali şüphesi doğduğunda ilk sorulacak soru şu olur: bu veri sisteme girdi mi, girdiyse ne zaman ve kim tarafından. Cevabı olmayan kurum, ihlalin kapsamını belirleyemez ve bu belirsizlik tek başına ciddi bir sorundur.
Bu yüzden geçit katmanı en azından şunları kaydetmeli: istek zamanı, isteği yapan kullanıcı veya servis, kullanılan model ve sağlayıcı, sınıflandırma sonucu ve ayıklamanın uygulanıp uygulanmadığı. Dikkat: kaydın kendisi de kişisel veri barındırır ve kendi saklama süresine tabidir. Uyum adına tuttuğunuz kayıt, süresiz saklandığında yeni bir risk kalemine dönüşür.
Kayıtta ham girdi metnini saklamak cazip gelir — hata ayıklamayı kolaylaştırır. Ama bu, ayıklama yaparak dışarı çıkarmadığınız veriyi kendi loglarınızda biriktirmek anlamına gelir. Ham metin saklanacaksa, saklama süresi kısa ve erişimi dar olmalıdır.
Kontrol 6 — Çıktıyı da siz işlersiniz
Kontrollerin neredeyse tamamı girdi tarafına odaklanır; çıktı tarafı düzenli olarak atlanır. Oysa modelin ürettiği metin kurumun sistemine yazıldığı anda, o metin de kurumun işlediği veridir.
İki somut risk var. Birincisi, model bir kişi hakkında gerçek olmayan bir ifade üretebilir ve bu ifade bir müşteri kaydına ya da bir değerlendirme notuna yazılırsa, kurum yanlış kişisel veri işlemiş olur. İkincisi, takma adlaştırma kullanıyorsanız çıktıdaki jetonların geri eşleştirilmesi de bir işleme adımıdır ve aynı yetki kontrollerine tabidir.
Pratik önlem basit: model çıktısının doğrudan kalıcı bir alana yazılmadığı, en az bir doğrulama adımından geçtiği bir akış kurun. Kritik alanlarda bu doğrulama insan onayı olur; düşük riskli alanlarda makine tarafından kontrol edilebilir bir biçim şartı (beklenen alan seti, geçerli değer listesi) yeterlidir.
Kontrol 7 — Silme talebi geldiğinde nereleri açacaksınız?
Bu, tasarım aşamasında en çok atlanan ve sonradan en pahalıya mal olan kontrol. Bir silme talebi geldiğinde veritabanındaki kaydı silmek kolaydır. Zor olan, aynı verinin türev kopyalarıdır:
- Vektör veritabanındaki gömme (embedding) kayıtları ve bunların metin parçaları
- Önbellekteki yanıtlar
- Geçit katmanının istek kayıtları
- Sağlayıcı tarafındaki saklama penceresi
- Yedekler
Bu listeyi sistem kurulurken çıkarmak birkaç saatlik iştir; ilk silme talebi geldikten sonra çıkarmak haftalar sürer. Özellikle vektör deposu sinsi bir yerdir: kaynak belge silinse bile, ondan üretilmiş parçalar ayrı bir sistemde yaşamaya devam eder ve arama sonuçlarında görünmeye devam eder.
Bu yüzden gömme üreten her kayıtta kaynak kimliğini saklayın. Kaynak kimliği yoksa, silme yalnızca tüm indeksi baştan kurarak yapılabilir.
Karar tablosu: hangi veri hangi kanaldan gider?
Yukarıdaki yedi kontrolü tek bir tabloya indirdiğinizde, çalışanın ve geliştiricinin bakacağı şey şu hale geliyor. Bu tabloyu kurum içi politikanızın ilk sayfası yapmanızı öneriyorum — çünkü okunması otuz saniye sürüyor.
| Veri türü | Kanal | Zorunlu kontrol |
|---|---|---|
| Ürün dokümanı, mevzuat, pazarlama metni | Kurumsal sağlayıcı, doğrudan | Kayıt (Kontrol 5) |
| Müşteri yazışması, destek kaydı | Kurumsal sağlayıcı, geçit üzerinden | Maskeleme + kayıt |
| Sözleşme, teklif, fiyat bilgisi | Kurumsal sağlayıcı, geçit üzerinden | Maskeleme + erişim kısıtı |
| İK belgesi, performans, özlük | Kurum içi model | Takma adlaştırma + dar erişim |
| Sağlık, biyometrik, kimlik no, kart | Gitmez | Geçitte engel |
| Kimlik doğrulama sırları, anahtarlar | Gitmez | Geçitte engel + uyarı |
Tablodaki en önemli sütun üçüncüsü. "Gitmez" satırlarındaki kontrolün geçitte olması, bu kararın çalışanın dikkatine bırakılmadığı anlamına gelir. Politikada yazan ama geçitte karşılığı olmayan her satır, aslında bir temenni.
Sık yapılan üç teknik hata
API anahtarını uygulamaya gömmek. Her uygulamanın kendi anahtarıyla doğrudan sağlayıcıya çıkması, Kontrol 4 ve 5'i aynı anda imkânsız hale getirir. Anahtar tek bir geçitte durmalı; uygulamalar geçide, geçit sağlayıcıya konuşmalı.
Sistem talimatına gerçek veri koymak. Modele verilen sabit talimat metnine örnek olsun diye gerçek müşteri kayıtları yazılıyor. Bu metin her istekte gönderilir, çoğu zaman kimse fark etmez ve hiçbir maskelemeden geçmez. Örnekler sentetik olmalı.
Hata ayıklama loglarını unutmak. Geliştirme sırasında açılan ayrıntılı log, ham girdiyi olduğu gibi yazar ve üretime alınırken kapatılması unutulur. Ayıklayarak dışarı çıkarmadığınız veri, kendi disklerinizde birikmeye başlar. Kontrol 5'teki kayıt tasarımı bunu baştan sınırlamalı.
Yedi kontrolü nereden başlatmalı
Hepsini aynı anda kurmak gerekmiyor; sıralama şöyle işe yarıyor. Önce Kontrol 1 ve 4 — sınıflandırma ve tek çıkış geçidi. Bu ikisi olmadan diğerlerinin uygulanacağı bir yer yoktur. Sonra Kontrol 2 ve 5 — ayıklama ve kayıt; bunlar geçidin içine yazılır. Kontrol 3 sözleşme tarafıyla paralel yürür. Kontrol 6 ve 7 ise ilk gerçek kullanım senaryosu netleştiğinde eklenir.
Bu sıralama, yapay zekâ projelerinde genel olarak önerdiğim eleme mantığının bir uygulaması: önce kararın nerede verildiğini belirle, sonra teknolojiyi seç. Aynı çerçevenin proje seçimi tarafını şirkette yapay zekâya nereden başlanır yazısında altı adımda ele aldım.
Sık sorulan sorular
Çalışanlar ChatGPT'ye şirket verisi yapıştırıyor. Ne yapmalıyız?
Yasaklamak tek başına işe yaramıyor; ihtiyaç ortadan kalkmadığı için kullanım kişisel cihaza kayıyor ve kurumun görüş alanından çıkıyor. İşleyen yol, kurumsal sözleşmeli bir sürümü tek çıkış geçidi üzerinden açmak ve o geçide sınıflandırma, kişisel veri ayıklama ve kayıt koymaktır. Yani kanalı kapatmak değil, kurumun belirlediği bir kanal açmak.
Kurumsal sürüm almak KVKK uyumu için yeterli mi?
Hayır, gerekli ama yeterli değil. Kurumsal katman genellikle "verinizi model eğitiminde kullanmayız" taahhüdünü getirir — bu önemli bir kalem ama tek kalem değil. Saklama süresi, işlemenin yapıldığı coğrafi bölge, alt işleyen listesi ve kurum içindeki erişim kontrolü ayrıca ele alınmalıdır. Bunların hepsi pazarlama sayfasında değil veri işleme ekinde yazar.
Veriyi maskelemek yeterli mi, yoksa modeli kendi sunucumuzda mı çalıştırmalıyız?
Veri sınıfına bağlı. Şartlı sınıftaki veri için sınırda maskeleme çoğu senaryoda yeterli olur ve çok daha ucuzdur. Özel nitelikli kişisel veri söz konusuysa ya da sektörünüz aktarım konusunda katıysa, modeli kendi altyapınızda çalıştırmak tartışmayı tümden ortadan kaldırır. Sınıflandırma, özetleme ve yönlendirme gibi işlerin çoğu bugün kurum içinde çalıştırılabilen modellerle karşılanabiliyor.
Silme talebi geldiğinde vektör veritabanını nasıl temizleriz?
Ancak her gömme kaydında kaynak belge kimliğini sakladıysanız kolayca. Kaynak kimliği yoksa tek yol tüm indeksi yeniden kurmaktır — bu da veri hacmine göre saatler veya günler sürer. Bu yüzden kaynak kimliği alanını sistem kurulurken eklemek, sonradan eklemekten kat kat ucuzdur. Aynı gözden geçirme önbellek, istek kayıtları ve yedekler için de yapılmalıdır.
Model çıktısı da kişisel veri sayılır mı?
Çıktı belirli veya belirlenebilir bir gerçek kişiye ilişkinse, o metni sisteminize yazdığınız anda siz de kişisel veri işlemiş olursunuz. Buradaki ek risk, modelin gerçek olmayan bir ifade üretip bunun bir müşteri kaydına ya da değerlendirme notuna yazılmasıdır. Pratik önlem, çıktının doğrudan kalıcı alana yazılmadığı, en az bir doğrulama adımından geçtiği bir akış kurmaktır.
Nereden başlamalıyız — politika mı, teknik kurulum mu?
İkisi paralel yürür ama teknik tarafta sıralama nettir: önce veri sınıflandırması, sonra tek çıkış geçidi. Bu ikisi olmadan diğer kontrollerin uygulanacağı bir yer yoktur; politika da uygulanamayan bir metin olarak kalır. Geçit kurulduktan sonra ayıklama ve kayıt onun içine yazılır, sözleşme tarafı paralel ilerler.
Sonuç: uyum bir belge değil, bir davranıştır
Bu yedi kontrolün hiçbiri tek başına "KVKK uyumu" sağlamaz — böyle bir düğme yok. Ama hepsinin ortak bir etkisi var: kurumun kişisel veriyle yapay zekâ arasındaki ilişkisini yazılı ve denetlenebilir hale getiriyorlar. Bir denetimde ya da bir ihlal şüphesinde fark yaratan şey, elinizde bir politika belgesi olması değil, hangi verinin nereye gittiğini gösterebilmenizdir.
Ekibinizin bu araçları günlük işinde güvenli kullanması için kurum içi bir çerçeve kurmak isterseniz, kurumsal yapay zekâ eğitimi programının çıktılarından biri tam olarak bu yazılı kullanım politikasıdır. Yapay zekâ destekli kod üretiminde aynı sınırların nasıl kurulduğunu merak ediyorsanız vibe coding ve mühendislik disiplini yazısına bakabilirsiniz.
Bu yazıyı, telekomünikasyon, havacılık ve e-ticaret sektörlerinde kurumsal veriyle çalışan sistemler kurarken edindiğim mühendislik deneyimiyle yazdım; hukuki görüş içermez. Hakkımda daha fazlası: Ufuk Aytaş kimdir.