Rehber nedir, ne değildir

Kişisel veri düzenleyicisi, üretken yapay zeka ve kişisel verilerin korunmasına dair bir rehber yayımladı. Rehber, kurumun kendi Rehberler dizininde kvkk.gov.tr üzerinde yer alıyor; aynı sitede üretken yapay zeka başlığı altında on beş soruluk daha kısa bir sürümü de yayımlanmış durumda. Bu metin bağlayıcı bir düzenleme değil, rehberdir ve bazı ekipler bunu dosyalayıp geçmek için izin sayıyor. Bu, denetimin gerçekte nasıl işlediğinin yanlış okunmasıdır. Rehber, düzenleyicinin neyi makul saydığını size önceden söyler; bir inceleme ya da şikâyet masanıza geldiğinde ölçüleceğiniz ölçüt tam olarak makul olandır. Bu yüzden rehberi bir tavsiye metni değil, önceden yayımlanmış bir denetim ölçütü gibi okumak gerekir.

Neyin var olmadığı konusunda da net olmakta fayda var. Türkiye'de yürürlükte özel bir yapay zeka kanunu bulunmuyor. Sizi bağlayan metin 6698 sayılı Kişisel Verilerin Korunması Kanunu ile birlikte Türk Ceza Kanunu, internet yayınlarına ilişkin 5651 sayılı Kanun ve Türk Ticaret Kanunu'dur. 6698 sayılı Kanun'un beş maddesi bir yapay zeka projesinde günlük işin çoğunu görür: hukuki sebep için Madde 5, sağlık ve biyometrik veri gibi özel nitelikli veriler için Madde 6, aydınlatma yükümlülüğü için Madde 10, münhasıran otomatik analiz sonucu doğan sonuçlar için Madde 11(g) ve veri güvenliği için Madde 12. Geniş hukuki tablo Türkiye'de yapay zeka mevzuatının gerçekte nerede durduğu yazısında.

Bu yazı, hukuk bürosu özetlerinin yapmadığı bir şeyi yapıyor. Rehberdeki her temayı alıp ima ettiği mimari değişikliği söylüyor; çünkü şemaya, silme işine ya da erişim filtresine dönüşmemiş bir kişisel veri ilkesi uygulanmış sayılmaz. Aşağıdaki her bölüm somut bir yerde bitiyor: eklediğiniz bir alan, temizlediğiniz bir depo, sorgunun içine ittiğiniz bir filtre, izlediğiniz bir sinyal. Buradan tek bir şey alacaksanız şunu alın: üretken bir sistemde uyum yüzeyi model değil, modelin etrafındaki veri yoludur ve bu yolun neredeyse tamamı sıradan mühendisliktir. Bölüm başlıkları da bu yüzden hukuki temalar değil, mimari katmanlar olarak dizilmiş durumda.

Ayrıntıya girmeden bir not daha. Kurum, ajan sistemlere ilişkin bir belgeyi de kendi Türkçe terimiyle Etken Yapay Zekâ başlığıyla 12 Mart 2026'da yayımladı. Üretken yapay zeka materyali gibi bu da bağlayıcı düzenleme değil rehberdir; burada anmamızın nedeni, bir sistem yanıt vermenin ötesine geçip eylem yapabildiğinde bu yazıdaki her şeyin zorlaşmasıdır. Posta gönderen, kayda yazan ya da ödeme tetikleyen bir ajan, yanlış çıktıyı yanlış eyleme çevirir; sorular da modelin ne söylediğinden sistemin ne yaptığına ve kimin durdurabileceğine kayar. Ajan geliştiriyorsanız izin modelini o belge açıkken tasarlayın. Bir ajanın yetkilerini sonradan daraltmak her zaman daha pahalıya gelir.

RAG, hukuki sebep sorusunu veri kümesine taşır

En sık gördüğümüz analiz hatası, istemi işleme faaliyetinin kendisi saymaktır. Ekip, kullanıcıların sohbet kutusuna yazdıklarına dair özenli bir aydınlatma metni yazar ve bu soruları yanıtlamak için dizine alınmış iki yüz bin belge hakkında hiçbir şey söylemez. RAG o veri kümesini sürekli işler: okunur, parçalanır, embedding'e dönüştürülür, vektör olarak saklanır, aranır ve yüzeye çıkarılır. Belgeler kişisel veri içeriyorsa bu adımların her biri 6698 sayılı Kanun anlamında işlemedir ve bir Türk kurumsal veri kümesinde neredeyse her zaman içerir. Sözleşmelerde imza, taleplerde isim, insan kaynakları dosyalarında her şey vardır. İstem, maruziyetin en küçük parçasıdır.

Dolayısıyla hukuki sebep analizi özellik başına değil veri kümesi başına yapılmalı ve öyle kaydedilmelidir. Dizine alınan her kaynak için özgün toplama amacını, bugünkü erişim amacını ve ikincisinin birincisiyle bağdaşıp bağdaşmadığını yazın. Projelerin çuvalladığı yer bu son sorudur. Destek taleplerini çözmek için toplanan destek talepleri genellikle bir destek asistanını gerekçelendirir. Aynı talepleri bir satış eğilim modeline vermek farklı bir amaçtır ve kendi analizini ister. Madde 6 bunu özel nitelikli veriler için daha da keskinleştirir: sağlık, biyometrik ve benzeri veriler, aynı klasörde durdukları için genel amaçlı bir dizine sızmamalıdır. Bunu dizinleme aşamasında bir filtreyle engelleyin.

Pratikte bu, dizinin yalnızca belge kimliğini değil, parça düzeyinde köken bilgisini taşıması demektir. Her vektörün yanında kaynak sistemi, özgün toplama amacını, hassasiyet sınıfını, saklama saatini ve kayıt sahibini saklayın. Birkaç ek sütuna mal olur ve sonraki her yükümlülüğü yanıtlanabilir kılan şey budur: hangi parçalar artık hukuki sebebiniz olmayan bir kaynaktan geldi, hangileri takvimle silinmeli, hangileri genel bir kitleye asla açılmamalı. Bunu atlayan ekipler sonradan bir alan eklemek için tüm veri kümesini yeniden dizine almak zorunda kalıyor; büyük bir koleksiyonda bu günlerce iş ve bir kesinti penceresi demek. Arkadaki erişim mimarisi vektör veritabanı ve anlamsal arama yazısında.

Neyi kaydetmeli, neyi asla kaydetmemeli

Kayıtlara ihtiyacınız var. Madde 12 güvenlik yükümlülükleri, olay müdahalesi, kalite değerlendirmesi ve gözetimin ileride kanıtlanması bunlara dayanır; ne ürettiğine dair kaydı olmayan bir sistem savunulamaz. Ne var ki naif uygulama, yani istemlerin ve yanıtların tamamını uygulama kayıtlarını tutan aynı gözlemlenebilirlik platformuna dökmek, en hassas verinizin ikinci bir kopyasını daha zayıf erişim kontrollü, daha uzun saklamalı ve çok daha geniş izleyicili bir sistemde yaratır. Şirketin en katı verisinin vektör veritabanında durduğu, düz metin kopyasının ise otuz mühendisin sorgulayabildiği bir kayıt dizininde bulunduğu projeler inceledik. Sızıntı riski o noktada modelden değil, kayıt altyapısından geliyordu.

Kayıt tutmayı iki düzleme ayırın. Telemetri düzlemi operasyonun ihtiyaç duyduğunu tutar ve içerik tutmaz: istek kimliği, kiracı, jetonlanmış kullanıcı kimliği, model ve sürüm, istem ve yanıt token sayıları, gecikme, erişilen belge kimlikleri, araç çağrıları, hata kodları ve maliyet. Panolarınızı ve alarmlarınızı çalıştıran budur, aylarca saklamak güvenlidir ve operasyonel değerin neredeyse tamamı buradadır. İçerik düzlemi ise gerçek istem metnini, erişilen pasajları ve üretilen yanıtı tutar. Ayrı saklanır, şifrelenir, adı belli bir gruba kısıtlanır, kısa süre tutulur ve istek kimliğiyle telemetri kaydına bağlanır. İki düzlemi ayırmak ilk kurulumda birkaç günlük iştir ve sonradan yapılması çok daha pahalıdır.

Bazı şeyler iki düzleme de girmez. Bir kullanıcının isteme yapıştırdığı parolaları, jetonları veya API anahtarlarını asla kaydetmeyin; kullanıcıların yapmayacağına güvenmek yerine bunları tespit edip düşürün. Özetleyebiliyor, maskeleyebiliyor veya referans verebiliyorsanız ham özel nitelikli veriyi açık hâlde asla kaydetmeyin. Belge kimliği ve parça konumu kaynaktan yeniden kurmaya yetiyorken erişilen belgenin tam içeriğini asla kaydetmeyin. Kullanıcı kimliğini jetonlanamayacak bir biçimde asla kaydetmeyin. Ve içeriği telemetri düzlemine yükselten bir hata ayıklama bayrağının tek bir olayın ötesine geçmesine asla izin vermeyin: karşılaştığımız kazara uzun süreli saklamanın en yaygın nedeni bu bayraklardır. Bayrakları süreli açın ve kendiliğinden kapansınlar.

İstem ve yanıtlar için saklama süreleri

Hata ayıklama için her şeyi saklayalım bir saklama politikası değil, politikanın yokluğudur ve öyle okunur. İşleyen desen kademelidir. İçeriksiz telemetri tipik olarak altı ila on iki ay saklanabilir, çünkü kapasite planlamasını ve eğilim analizini destekler ve kimlikler jetonlandığında az kişisel veri taşır. İstem ve yanıt içeriği başka bir sınıftır: kurduğumuz sistemlerde bir olayı incelemek için genellikle yedi ila otuz gün yeterlidir ve daha uzunu için yazılı bir gerekçe gerekir. Bir insanın bir çıktıyı değerlendirdiği inceleme kayıtları kendi saatiyle saklanır, çünkü gözetimin kanıtı onlardır. Bu üç kademeyi tek bir tabloda yazın ve her satıra bir gerekçe iliştirin.

Önemli kelime uygulanan kelimesidir. Bir dokümanda var olup zamanlanmış bir işte var olmayan saklama politikası kontrol değil yükümlülüktür, çünkü kanıtlanabilir biçimde karşılayamadığınız bir beklenti yaratır. Silmeyi kod olarak yazın, günlük çalıştırın, ne sildiğini toplu olarak kaydedin ve başarısız olduğunda ya da hiçbir şey silmediğinde alarm üretin; ikincisi genellikle bir şema değişikliğinden sonra sorgunun eşleşmeyi bıraktığının işaretidir. Sonra test edin: içeriye bir işaret kaydı koyun, süreyi bekleyin ve belgelenmiş kurtarma süresi içinde yedekler dahil her depodan gittiğini doğrulayın. Bu testi yılda bir değil, saklama şemasını her değiştirdiğinizde tekrarlayın; şema değişikliği silme sorgusunu sessizce bozan en yaygın nedendir.

Rızaya veya tercihe dayalı saklamanın ayrı bir şeridi olmalı. Bir kullanıcı görüşmelerinin iyileştirme amacıyla saklanmasına itiraz ettiyse, bu karar aşağı akışta birinin uygulamayı hatırladığı bir filtre olarak değil, isteğin üstünde bir alan olarak yolculuk etmelidir. Biz bunu istek zarfının parçası yapıyoruz; böylece bayrak açıkken depolama katmanı içeriği yazmayı reddediyor, yazıp sonra temizlemeye çalışmıyor. Fark, temizleme işi bir hafta gecikene kadar akademik görünür; o noktada bir tasarım hiçbir şey saklamamıştır, diğerinin ise raporlayıp açıklaması gereken bir olayı vardır. Tercih bayrağının kendisini de kaydedin ki bir sonraki denetimde hangi isteklerin neden hiç yazılmadığını gösterebilesiniz.

Model metni görmeden önce maskeleme

İşin içinde barındırılan bir model varsa, elinizdeki en ucuz gizlilik kontrolü kişisel veriyi hiç göndermemektir. Bir maskeleme katmanı uygulamanızla model arasında durur, istemdeki ve erişilen pasajlardaki tanımlayıcıları tespit eder, bunları sabit yer tutucularla değiştirir, modeli çağırır ve yanıt kullanıcıya ulaşmadan önce yer tutucuları geri koyar. Model, adı belli bir kişi ve bir sözleşme numarası yerine KISI_1 ve SOZLESME_2 hakkında tutarlı bir belge görür; yanıt da genellikle aynı kalitededir, çünkü akıl yürütme tanımlayıcının kendisine bağlı değildir. Deneyimimizde kalite maliyeti küçüktür, maruziyet azalması küçük değildir. Maskeleme katmanını ayrı bir servis olarak kurmak, sonradan başka ürünlerde de kullanmayı kolaylaştırır.

Türkiye kurulumları Türkçe tespit ister. İngilizce üzerine kurulmuş genel bir tespit katmanı burada önemli olan tanımlayıcıları kaçırır: on bir haneli kimlik numarası, vergi ve ticaret sicil numaraları, Türkiye biçimindeki IBAN'lar, plakalar, Türkçe adres ve sokak yazımları ve Türkçe eklerle çekimlenip tek bir belgede beş ayrı yüzey biçiminde görünen kişi adları. Yalnızca düzenli ifadeye dayanan yaklaşım yapılandırılmış kalemleri yakalar, isimleri kaçırır. Yalnızca modele dayanan yaklaşım isimleri yakalar ama kayar. İşe yarayan katmanlı bir tespittir: önce doğrulama basamağıyla yapılandırılmış desenler, sonra bir varlık tanıma modeli, sonra kurumunuzun önemsediği terimler için bir yasak listesi.

Bir yanlış negatif bütçesi belirleyin ve ona karşı ölçün; çünkü kimsenin ölçmediği bir maskeleme katmanı yalnızca rahatlatıcı bir örtüdür. Kendi veri kümenizden birkaç yüz gerçek belgelik etiketli bir örneklem kurun, varlık türü başına duyarlılığı puanlayın ve eşiğin altına düşmeyi sürümü bloke eden bir olay sayın. Kesinliği bilinçli olarak duyarlılığa feda etmeyi bekleyin: fazla maskeleme kullanıcıyı rahatsız eder, eksik maskeleme bildirim gerektiren bir olaydır. Tipik istem boyutlarında tespit geçişi için istek başına kabaca yirmi ila seksen milisaniye ayırın ve maliyetin erişilen bağlamla büyüdüğünü unutmayın; ekiplerin top-k değerini büyütüp gecikmenin kaydığını görünce atladıkları kısım budur.

Maskelemenin geri döndürülebilir olup olmayacağına bilinçli karar verin. Bir isteğin ömrü boyunca kendi belleğinizde tutulan yer tutucu haritası geri döndürülebilirdir ve yanıtta isimleri geri koymanızı sağlar; kullanıcılar bunu bekler. Tek yönlü bir özet daha güvenlidir ama okuma deneyimini bozar ve aynı varlık hakkında takip sorularını destekleyemez. Biz varsayılan olarak istek içinde geri döndürülebilir, depolamada geri döndürülemez çalışırız: eşleme süreç belleğinde durur ve kayda ya da ize asla yazılmaz. Bu tek kural, bu tasarımdaki en yaygın sızıntıyı, yani kendisini üreten isteği aşan bir hata ayıklama dosyasında sessizce kalıcılaşan yer tutucu sözlüğünü engeller.

Çıkarım nerede çalışıyor ve aktarım açısından bu ne demek

Çıkarımın fiziksel konumu, altyapı kararından önce bir kişisel veri kararıdır ve öyle kaydedilmelidir. Kabaca üç duruş var. Kendi altyapınızda ya da Türkiye'deki bir sağlayıcıda tamamen kurum içi çalışan çıkarım, veriyi kontrol sınırınızın içinde tutar ve aktarım sorusunu tümüyle ortadan kaldırır. Bölgesel kurulumu ve sözleşmesel garantileri olan barındırılan bir model, analizi aktarım şartlarına ve alt işleyici yönetimine taşır. Varsayılan koşullarla genel bir kamuya açık API uç noktası ise savunulması en çok emek isteyen seçenektir ve çoğu ekibin kazara başladığı seçenektir; genellikle sessizce üretime dönüşen bir prototip sırasında. Üçünden hangisinde olduğunuzu envanter satırına yazın.

Hangisini seçerseniz seçin, dört soruyu yazılı olarak yanıtlayabilmeniz gerekir. İstek fiziksel olarak nereye gidiyor. Yol boyunca hangi kuruluşlar onu işliyor, sağlayıcınızın arkasındakiler dahil. İstemler ve çıktılarla sözleşmeye göre ne yapabiliyorlar ve özellikle bunlardan herhangi biri model eğitiminde kullanılıyor mu. Ne kadar süre saklıyorlar ve bu süreyi aşağı çekecek bir ayar var mı. Sağlayıcılar bunları yayımlar ve zamanla değiştirir; bu yüzden yanıtları tarihiyle kaydedin ve on sekiz ay önce satın alma sırasında alınmış bir ekran görüntüsüne güvenmek yerine belirli bir tempoda yeniden doğrulayın. Üç ayda bir yapılan kısa bir kontrol, çoğu ekip için yeterli ve sürdürülebilir bir tempodur.

Düzenlemeye tabi Türk müşterilerle en sık vardığımız mimari sonuç bir ayrımdır. Hassas yolu, yani kimliği belirli müşteri kayıtlarına, sağlık verisine veya özel nitelikli verilere dokunan her şeyi, sınırın içinde kurum içi açık ağırlıklı modellerde çalıştırın. Genel yolu, yani kamuya açık materyalin özetlenmesini, kod yardımını ve taslak yazımını barındırılan güçlü bir modelde çalıştırın. İkisi arasındaki yönlendirme, ekip tercihi değil, veri sınıflandırmasından istek başına türetilen bir politika kararıdır. İki yolu işletmek daha pahalıdır, tipik olarak başlangıçta birkaç ek mühendis haftası ve kurum içi taraf için sürekli kapasite demektir; ama denetim görüşmesinden sağ çıkan tasarım budur.

Yetki kontrolü erişim katmanına taşınmalı

Kurumsal RAG'de en sık gördüğümüz hata budur ve sonuçları en ağır olan da budur. Ekip paylaşılan bir sürücüyü dizine alır, güzel bir asistan kurar ve sonra fark eder ki genç bir çalışan bir maaş bandını, bir disiplin dosyasını veya duyurulmamış bir satın almayı sorup kaynak sistemde asla açamayacağı belgelerden derlenmiş akıcı bir yanıt alabiliyor. Hiçbir şey hacklenmedi. Dizin, kaynak sistemin yıllardır uyguladığı yetki modelini düzleştirdi ve asistan, kendisine verilen veriyle tam olarak yapmak üzere kurulduğu şeyi yaptı. Böyle bir olayın ardından asistanı kapatmak kolaydır; dizini yeniden kurmak ve kimin neyi gördüğünü geriye dönük çıkarmak değildir.

Kural mutlaktır ve bir test gibi ifade edilmeye değer: kullanıcı, kayıt sisteminde açamayacağı bir pasajı asla almamalıdır. Bunu son filtre olarak değil ön filtre olarak uygulayın. Ön filtreleme, kimliği ve grup üyeliklerini vektör sorgusunun içine iter; böylece arama yalnızca izinli parçaları değerlendirir. Son filtreleme ise en iyi eşleşmeleri getirip kullanıcının göremeyeceklerini çıkarır ve bu iki yönden yanlıştır. Sonuç sayıları, gecikme ve dönenin biçimi üzerinden sızdırır ve kaliteyi sessizce düşürür; çünkü dar yetkili bir kullanıcı, sistem yirmi sonuç için ayarlanmışken filtrelemeden sonra elinde üç sonuçla kalabilir. Ön filtre bu sorunu tasarım gereği ortadan kaldırır.

Bu, her parçanın yazma anında bir erişim listesi taşıması demektir; liste varsayılmaz, kaynak sistemden çözülür. Grup genişletmesi önbelleğe alınmalıdır, çünkü iç içe grupları sorgu başına çözmek yavaştır; yetkiler değiştiğinde de önbellek geçersizleştirilmelidir. İhmal edilen kısım yetki yayılımıdır: biri pazartesi bir projeden ayrılır ve cuma günü hâlâ o projenin belgelerini getirebilir, çünkü dizin tazelenmemiştir. Savunabileceğiniz azami bayatlık süresi belirleyin, hassas veri kümeleri için dakikalar ve genel olanlar için saatler, ve bunu ummak yerine bir hizmet seviyesi gibi izleyin. Alana özgü desenler Türkçe hukuk verisiyle RAG yazısında tartışılıyor. Bayatlık süresini panoda görünür bir metrik yapın.

Düşmanca test edin ve testleri saklayın. Temsili kullanıcılar ve belgelerden bir yetki matrisi kurun, yasak içeriği yandan çekmek için tasarlanmış sorgular üretin ve tüm paketi her dizin değişikliğinde CI içinde çalıştırın. Adı geçen bir çalışanın maaşını sorun. Geçen çeyreğin yönetim kurulu dosyasının özetini isteyin. Dolaylı sorun: herhangi bir ücret belgesinde geçen en yüksek rakamı isteyin; naif filtreleri yenen ifade budur. Seksen ila iki yüz vakalık bir erişim yetkisi test paketinin bakımı ucuzdur ve kurumsal bir RAG kurulumundaki en değerli güvenlik testi tek başına budur. Vakaları bir kez yazın ve her yeni kaynak eklendiğinde genişletin.

Gölge yapay zeka: insanların zaten kullandığını bulmak

Gölge yapay zeka, onaylanmamış yapay zeka araçlarının şirket verisiyle kullanılmasıdır ve baktığımız her kurumda, kurumu yönetenleri şaşırtacak bir ölçekte zaten yaşanıyor. Kötü niyetli de değil. Birinin teslim tarihi vardır, kamuya açık bir sohbet botu bir sekme uzaktadır ve sözleşme, müşteri listesi ya da olay raporu oraya yapıştırılır. 6698 sayılı Kanun açısından şirket hâlâ veri sorumlusudur: hiç yetkilendirmediğiniz, tarif edemediğiniz ve kaydetmediğiniz bir aktarımdan sorumlu olursunuz ki biri size ne olduğunu sorduğunda bulunabileceğiniz en kötü konum budur. Üstelik bunu genellikle kendi izlemenizden değil bir müşteri sorduğunda öğrenirsiniz; bu da yanıt süresini günlerden haftalara çıkarır.

Tespit gösterişsizdir ve çoğunlukla elinizde zaten olan telemetriyi kullanır. Web vekil sunucusu ve DNS kayıtları hangi yapay zeka alan adlarına ne sıklıkla gidildiğini gösterir. O alan adlarına giden trafik hacmi, gündelik okumayı toplu yapıştırmadan ayırır; birkaç kilobayt bir sorudur, birkaç megabayt bir belge setidir. Yönetilen cihazlardaki tarayıcı eklentisi envanteri, geniş sayfa erişimiyle kurulmuş yapay zeka asistanlarını yakalar. Masraf formları kişisel kartlara faturalanan bireysel abonelikleri gösterir. Kimlik sağlayıcınızdaki uygulama keşfi araçları ise kullanıcıların hangi üçüncü taraf uygulamalara kurumsal hesap erişimi verdiğini gösterir; en sessiz ve en sonuç doğuran kategori budur. Bu listeyi ayda bir gözden geçirin.

İşe yarayan yanıt yasak değildir. Yasaklar faaliyeti hiç telemetriniz olmayan kişisel cihazlara taşır ve yönetilebilir bir sorunu görünmez bir soruna çevirir. Gerçekten iyi olan onaylı bir araç sağlayın, onu en az dirençli yol hâline getirin ve hiçbir yere yapıştırılmaması gerekenleri sade bir dille açıkça söyleyin. Sonra ölçmeye devam edin: onaylı kullanım yükselmeli, onaysız trafik düşmelidir; olmuyorsa aracınız yeterince iyi değildir ya da insanlar varlığını bilmiyordur. Bu oranı iç platform için bir ürün metriği sayıyoruz, ayda bir gözden geçiriyoruz ve herhangi bir politika beyanından çok daha iyi bir gösterge olduğunu görüyoruz.

İlgili kişi hakları ve tam değerlendirmenin tetiklendiği anlar

Üretken mimarilerin kırıldığı yer silmedir, çünkü veri bir silme komutunun asla ulaşmadığı yerlere kopyalanmıştır. Kaynak veritabanından bir satırı silmek, geçen ay kurulan vektör dizininden, embedding önbelleğinden, yeniden sıralama önbelleğinden, istem ve yanıt kayıtlarından, gerçek trafikten derlenmiş değerlendirme veri kümesinden veya analitik ambardan o veriyi kaldırmaz. Bunların her biri 6698 sayılı Kanun anlamında bir kişisel veri kopyasıdır. Bir ekibin bunu ilk kez dürüstçe haritalaması genellikle rahatsız edicidir, çünkü tek bir müşteri kaydının altı sisteme yayıldığı, bunların yalnızca ikisinin orada olduğunu bilen bir sahibi olduğu ortaya çıkar. Haritayı bir kez çıkarın ve mimari dokümanın içinde güncel tutun.

Silmeyi, hedef listesi belgelenmiş ve tamamlanma makbuzu üreten bir dağıtım işi olarak kurun. Kaynak kayıt silinir, vektör parçaları belge kimliğiyle silinir, önbellekler anahtar önekiyle geçersizleştirilir, kayıtlar ilgili kişi referansıyla temizlenir, değerlendirme vakaları kaldırılır veya yeniden anonimleştirilir, ambar satırları işaretlenir. Vektör veritabanları silmeyi farklı destekler: bazıları anında kaldırır, bazıları işaretleyip sıkıştırma sırasında geri kazanır, birkaçı ise etkilenen bölümün yeniden kurulmasını gerektirir. Bir müşteri sözleşmesinde silme süresi taahhüt etmeden önce hangisine sahip olduğunuzu bilin; bazı mimariler için dürüst yanıt anında silme değil, haftalık zamanlanmış yeniden kurulumdur. Bu farkı sözleşme görüşmesinden önce ölçün ve yazılı hâle getirin.

Diğer haklar da tesisat ister ve genellikle unutulur. Erişim hakkı, bir kişi hakkında elinizde olanı yalnızca kaynak sistemde değil bütün bu depolarda üretebilmek demektir. Düzeltme hakkı, düzeltilmiş kaydın dizinde bayat bırakılmak yerine yeniden embedding'e sokulması demektir; veri hattının bu yüzden tam yeniden kurulum dışında belge başına yeniden dizinleme yoluna ihtiyacı vardır. Madde 11(g) ise münhasıran otomatik analiz sonucu aleyhine bir sonuçla karşılaşan kişinin itiraz edebilmesi demektir; bu, sayfa altındaki bir e-posta kutusu değil, kuyruğu, hizmet seviyesi, geçersiz kılma yetkisi ve kimin kullandığına dair kaydı olan gerçek bir iş akışıdır. Bu akışı ürünün parçası sayın.

Her proje için resmî bir etki değerlendirmesi gerekmez ve gerekiyormuş gibi davranmak itibar yakar. Otomatik saydığımız tetikleyiciler şunlardır: Madde 6 kapsamındaki özel nitelikli verinin hatta girmesi; istihdam, kredi veya bir hizmete erişim gibi kişinin haklarını esaslı biçimde etkileyen bir karar; müşteri verisinin yeni bir amaçla büyük ölçekli işlenmesi; çalışanların veya kamunun sistematik izlenmesi; yeni bir sınır ötesi aktarım yolu; ya da insan onayı olmadan geri döndürülemez eylem yapabilen bir ajan. Değerlendirmeyi pilottan sonra değil yapımdan önce çalıştırın ve mühendislerin gerçekten işlettiği yönetişim artefaktları yazısında anlatıldığı gibi sistemin envanter satırıyla birlikte saklayın.

HatsonTech olarak bunu nasıl kuruyoruz

Biz bir mühendislik şirketiyiz, hukuk bürosu değiliz. Belirli bir işlemenin hukuka uygun olup olmadığına dair görüş vermiyoruz; müşterinin kendi hukukçusunun bu soruyu yanıtlamasını ve sonraki sürümden sonra da yanıtlamaya devam etmesini mümkün kılan sistemleri kuruyoruz. Bir RAG kurulumunda bu şu demek: parça düzeyinde köken ve hassasiyet üstverisi, barındırılan çıkarımın önünde katmanlı bir Türkçe maskeleme geçişi, farklı saklama saatleriyle ayrılmış telemetri ve içerik kayıtları, kaynak sistem yetkilerini uygulayan ön filtreli erişim, makbuz üreten bir silme dağıtımı ve her dizin değişikliğinde koşan düşmanca bir yetki test paketi. Bu altı parçayı tek bir teslimat kalemi olarak planlıyoruz.

En sık karşılaştığımız desen, veri yolu olmayan iyi bir pilottur. Erişim kalitesi yerindedir, demo ikna edicidir ve hangi belgelerin dizine alındığını, kimin neyi görebildiğini, istemlerin ne kadar saklandığını ya da bir müşteri silinmek istediğinde ne olduğunu kimse söyleyemez. Bu kontrolleri yayına aldıktan sonra eklemek, baştan kurmaktan tipik olarak daha pahalıya gelir; çünkü ilk alım koşusundan itibaren orada olması gereken alanları eklemek için dizinin yeniden kurulması gerekir. Tavsiyemiz sevilmez ama değişmez: yeniden sıralamayı ayarlamadan önce alım üstverisine bir hafta daha harcayın. O bir hafta, ilerideki yeniden dizinleme işini ve onunla gelen kesinti penceresini tümüyle ortadan kaldırıyor.

Avrupa yükümlülükleri çoğu zaman aynı sisteme bir müşteri üzerinden geldiği için ikisini iki kez değil aynı anda kuruyoruz; bunun konusu omnibus sonrası AB Yapay Zeka Yasası yazısı. Kurum içi ve hibrit seçenekler dahil daha geniş gizlilik mimarisi ise veri gizliliği yazımızda anlatılıyor. Üretimde bir RAG sisteminiz varsa ve silme sorusunu uçtan uca yanıtlayamıyorsanız başlanacak yer orasıdır; RAG ve anlamsal arama pratiğimiz üstlendiğimiz neredeyse her işte ilk olarak bunu yapar. Mevcut sisteminizin mimari şemasını ve dizine aldığınız kaynakların listesini gönderirseniz, veri yolundaki eksikleri ve her birinin kabaca ne kadar süreceğini yazılı olarak çıkarıyoruz.