Veri Saklama Politikası

Veri saklama politikası, farklı veri kategorilerinin daha ucuz depolamaya arşivlenmeden veya kalıcı olarak silinmeden önce ne kadar süre tutulacağını belirten, tipik olarak otomatikleştirilmiş, tanımlı bir kural setidir; verinin varsayılan olarak süresiz birikmesine izin vermek yerine bu kuralları uygular. AI/SaaS geliştiricileri için neden önemli: saklama politikası maliyet kontrolü, uyumluluk (compliance) ve ürün güveninin kesişiminde yer alır — sınırsız veri büyümesi zaman içinde depolama maliyetini ve (vektör embedding'ler gibi indekslenen her şey için) sorgu maliyetini sessizce şişirir; GDPR gibi düzenlemeler kullanıcılara kişisel verilerinin talep üzerine silinmesi konusunda yasal bir hak tanır ve bir ürünün bunu sadece vaat etmesi değil, teknik olarak yerine getirebilir olması gerekir; ve AI'ya özgü veri kategorileri — potansiyel olarak hassas kullanıcı girdisi içeren ham LLM prompt'ları/tamamlamaları, RAG pipeline'larına beslenen yüklenmiş belgeler, üretilen görseller/sesler — genellikle bir şirketin normal uygulama loglarından anlamlı ölçüde farklı saklama yükümlülükleri veya kullanıcı beklentileri taşır. Saklama politikasını sonradan, yıllarca birikmiş, net sahipliği olmayan onlarca sistemdeki yapılandırılmamış veri üzerine tasarlamak, başından itibaren tasarlamaktan çok daha zor bir problemdir. Nasıl çalışır: saklama kuralları tipik olarak object storage yaşam döngüsü politikalarının (N günden eski nesneleri otomatik silme veya otomatik katmanlandırma — Object Storage/S3 başlığı altında ele alınan mekanizma), tanımlı bir TTL'i geçen eski satırları temizleyen veya arşivleyen zamanlanmış veritabanı işlerinin ve — uyumluluk açısından kritik olarak — bir kullanıcının verisinin bir kopyasını tutan her sistemde bir silme talebini basamaklı şekilde (cascading) yayan tanımlı bir sürecin bileşimiyle uygulanır; buna kullanıcının belgelerinden üretilen vektör embedding'ler, kullanıcının girdisini içeren cache'lenmiş LLM yanıtları ve tüm yedekler gibi türetilmiş veri de dahildir. Yaygın ve önemli bir incelik: "kullanıcının satırını sil" ile "kullanıcının verisini sil" aynı şey değildir, çünkü vektör arama, caching ve yedeklerin hepsi orijinal içeriğin bağımsız kopyalarını veya türevlerini potansiyel olarak tutabilir bir sistemde — gerçekten GDPR uyumlu bir silme akışı bunların hepsini hesaba katmalıdır, yalnızca ana veritabanı kaydını değil. Somut örnek: bir AI SaaS'ı, ham yüklenmiş belgelerin bir abonelik iptal edildikten 30 gün sonra object storage'dan silindiği, üretilen AI çıktılarının müşteri referansı için 1 yıl saklandığı ve — kritik olarak — bir "hesabımı sil" talebinin kullanıcının satırını, S3'teki belgelerini, vektör deposunun namespace'indeki embedding'lerini kaldıran ve içeriğine bağlı önbelleğe alınmış her LLM yanıtını temizleyen basamaklı bir işi tetiklediği bir saklama politikası tanımlar; bu tüm basamak, yalnızca ana veritabanı tablosuna dokunan tek bir `DELETE` ifadesine güvenmek yerine, uyumluluk denetimi amaçları için loglanır.