Veri kökeni ve amaç bağlama kaydı kurmak

Bu envanter bir sistem envanteri değil: hangi uygulamanın yapay zekâ kullandığını değil, hangi verinin modele girdiğini sayıyorsunuz. Ayrım önemli, çünkü tek bir uygulama beş farklı veri kümesinden besleniyor olabilir ve bunların dayanakları birbirinden tamamen farklıdır.

Dayanak alanının değeri, doldurulmasında değil boş bırakılamamasında. Alan isteğe bağlı olduğunda ilk yoğun haftada boş kalır ve altı ay sonra kimse o kümenin nereye dayandığını hatırlamaz. Zorunlu alan, kararın verilmiş olduğunu garanti eder — doğru verildiğini değil, ama en azından verildiğini.

• Kişisel veri içeren kümeler: hukuki işleme şartı; sınıflandırmayı hukuk muhatabınız yapmalı.
• Satın alınan veya lisanslanan kümeler: sözleşme numarası ve kullanım kısıtları.
• Açık veri kümeleri: lisans adı ve türev üretmeye izin verip vermediği.
• Kurum içi üretilen kümeler: hangi birimin sahibi olduğu ve iç politikaya atıf.
• Kullanıcıdan gelen içerik: hangi metinle bilgilendirildiği ve nereye onay verdiği.

Amaç alanının bozulması kademeli oluyor: küme önce tek bir iş için toplanıyor, sonra "zaten elimizde" denilerek ikinci bir işte kullanılıyor, üçüncüsünde artık amacı kimse sormuyor. Dar yazılmış bir amaç bu kaymayı sürtünmeli hâle getirir — yeni kullanım, yeni bir kayıt açmayı gerektirir ve o anda soru yeniden sorulur.

Karar ölçütü şu: amaç ifadesini okuyan biri, önerilen yeni bir kullanımın kapsam içinde olup olmadığını tartışmadan söyleyebiliyor mu? Söyleyemiyorsa ifade yeterince dar değildir. Kapsam genişletme talebi geldiğinde yapılacak şey alanı düzenlemek değil, yeni bir kayıt açıp dayanağı yeniden değerlendirmektir.

Köken kayıtlarının en büyük kör noktası burası. Bir belgeyi kaynak depodan silmek kolay; o belgeden üretilmiş vektörleri, arama dizinindeki parçaları, önbellekteki yanıtları ve eğitim sırasında ağırlıklara geçmiş etkiyi bulmak, önceden etiketlenmediyse neredeyse imkânsız. Türev etiketi, silme talebi geldiğinde değil türev üretilirken yazılmalı.

# Örnek kayıt; alan adları ve süreler kurumunuza göre belirlenir.
kayit_kimligi: destek-kayitlari-2026-h1
kaynak:
  sistem: <kaynak-sistem-adi>
  sahip_birim: Müşteri Operasyonları
dayanak:
  tur: sozlesme
  referans: <sozlesme-referansi>
amac: "Destek taleplerini kategoriye ayıran sınıflandırıcının eğitimi"
saklama:
  sure: "24 ay"
  baslangic_olayi: "talebin kapanma tarihi"
turevler:
  - tur: gomme_vektoru
    konum: <vektor-dizini-adi>
  - tur: arama_dizini
    konum: <dizin-adi>
  - tur: ince_ayar_agirligi
    konum: <model-kayit-defteri-girdisi>

Saklama süresi yazmak kolay, sürenin ne zaman başladığını yazmak atlanıyor. "24 ay" ifadesi tek başına uygulanamaz: kayıt tarihinden mi, son erişimden mi, ilişkinin bittiği andan mı? Başlangıç olayı belirtilmediğinde silme işini yapan hat, hangi tarihi okuyacağını bilemez ve genellikle hiçbir şey silinmez.

Süreyi hattın içine gömün. Takvime bağlanan bir saklama politikası, ilk yoğun çeyrekte unutulur; hattın içinde çalışan bir silme işi ise unutulmaz, yalnızca hata verir — ki bu da görülebilir bir durumdur.

Silme yeteneği, talep geldiğinde değil öncesinde denenmeli. Provayı gerçek bir kişinin verisiyle değil, hattın içine baştan yerleştirilmiş izlenebilir bir test kaydıyla yürütün; yanlış giden bir adım o zaman gerçek veriyi götürmez ve doğrulama sorgusunu istediğiniz kadar tekrarlayabilirsiniz. Denemenin amacı süreci onaylamak değil, kırıldığı yeri bulmak: hangi adım elle yapılıyor, hangi sistemde arama yapılamıyor, hangi türev listede yok. Bu üç sorunun cevabı ilk denemede çıkar ve genellikle rahatsız edicidir.

1. 1Talep açılır

   Gerçek bir talep gibi kaydedilir; süre ölçümü burada başlar.

2. 2Kaynak kayıtlar bulunur

   Test kaydının verisi hangi kümelerde geçiyor, köken kaydından çıkarılır.

3. 3Türevler taranır

   Vektör dizini, arama dizini, önbellek ve varsa ağırlıklar sırayla ele alınır.

4. 4Yedekler ele alınır

   Yedekten silmenin mümkün olup olmadığı ve alternatif yöntem yazılır.

5. 5Doğrulama yapılır

   Aynı sorgu tekrar koşturulur; veri hâlâ dönüyorsa talep tamamlanmamıştır.

Elektronik çizelgede tutulan köken kaydı üç ay içinde gerçeklikten kopar, çünkü onu güncellemek kimsenin işini kolaylaştırmaz. Kayıt hattın zorunlu adımı olduğunda denklem tersine döner: kaydı doldurmak, işi yapabilmenin ön koşuludur ve güncel kalması için ayrı bir disiplin gerekmez.

• Dizinleme işi başlamadan önce kayıt kimliği kontrolü.
• İnce ayar işi başlamadan önce dayanak ve amaç alanlarının dolu olması şartı.
• Yeni bir veri kaynağı bağlandığında otomatik açılan taslak kayıt.
• Amaç alanı değiştiğinde ikinci bir onay gerektiren akış.
• Saklama süresi dolduğunda tetiklenen silme işi.

Doğrulama adımı: kaydı olmayan bir test veri kümesiyle hattı koşturun. Hat kümeyi reddetmiyorsa kontrol yalnızca kâğıt üzerindedir ve ilk acele eden ekip tarafından atlanacaktır.

Prova, kayıt tasarımını test eden en ucuz yöntem. Soruları gerçek denetimdeki gibi sorun ve cevabı kimseye sormadan, yalnızca kayda bakarak üretmeye çalışın. Cevaplayamadığınız her soru, kayıtta açılması gereken bir alanı gösterir; provanın çıktısı rapor değil şema değişikliğidir.