Şirket İçi Yapay Zekâ İçin Politika Zorlamalı RAG Sınırları

Özel RAG projeleri neden en çok sınır katmanında zorlanır

Şirket içi yapay zekâ projelerinde ilk refleks genellikle doğrudur: hassas veriyi kurum dışına çıkarmamak, belgeleri içeride indekslemek ve bunları retrieval-augmented generation yaklaşımıyla bir asistana kullandırmak. Sorun çoğu zaman bir sonraki adımda başlar. Bütün belgeler tek bir ortak bilgi havuzuna atılır ve sistemin yalnızca istem kurallarıyla güvenli davranması beklenir. İlk bakışta verimli görünen bu yaklaşım, aslında son derece kırılgan bir güven modelidir. Çünkü asistanın güvenliği, altında duran erişim ve retrieval sınırları kadar güçlüdür. Aynı vektör dizininde mühendislik çalışma notları, sözleşme revizyonları, bordro prosedürleri ve iç soruşturma kayıtları bir aradaysa, model zaten yanlış bilgiye fazla yaklaşmış demektir.

Daha sağlam yaklaşım, retrieval sınırlarını sadece arama problemi olarak değil, politika problemi olarak ele almaktır. Belgeler yalnızca alaka düzeyine göre sıralanmamalı; veri sınıfına, iş rolüne ve onaylı kullanım senaryosuna göre sisteme alınmalı, bölümlenmeli ve kullanıcıya sunulmalıdır. Örneğin bir kullanıcı “güncel eskalasyon sürecini göster” dediğinde, benzer embedding yapısı yüzünden hukuki arşivlerden ya da yetkili insan kaynakları klasörlerinden parça çekmemelidir. Düzenlemeye tabi ortamlarda asıl soru “model cevap verebilir mi?” değil, “bu kullanıcı, bu bağlamda, bu iş akışı için bu kaynakları gerçekten görmeye yetkili mi?” sorusudur.

Bu nedenle güçlü ekipler artık tek beyne sahip tek bir asistandan söz etmez. Bunun yerine açık bilgi bölgeleri, metadata standartları ve gerektiğinde varsayılan olarak erişimi kapatan politika kontrolleriyle çalışan bir retrieval dokusu tasarlar. Başlangıçta daha fazla emek ister; ancak ilk denetimde, ilk olay incelemesinde ya da ilk erişim itirazında bütün bilgi katmanının anlamlı biçimde ayrılmadığı ortaya çıktığında yaşanan pahalı yeniden tasarımı da önler.

İstemleri tasarlamadan önce bilgi bölgelerini tanımlayın

Pratik başlangıç noktası, kurumun bilgi riskini zaten nasıl düşündüğünü yansıtan üç ya da dört bilgi bölgesi tanımlamaktır. Sık görülen model herkese açık, kurum içi, kısıtlı ve gerekiyorsa düzenlemeye tabi katmanlarıdır. Herkese açık katman onaylı pazarlama materyallerini, ürün dokümantasyonunu ve kamuya açık politikaları içerebilir. Kurum içi katmanda operasyon prosedürleri, mimari standartlar ve ekip çalışma rehberleri yer alır. Kısıtlı alan genellikle sözleşme ayrıntıları, fiyatlandırma kuralları, inceleme kayıtları ve gizli proje malzemeleri içindir. Düzenlemeye tabi katman ise kişisel veri, ihracat kontrolü, güvenlik kritiklikleri veya sektörel yükümlülükler sebebiyle daha sert koruma gerektiren içerikleri barındırır.

Bu bölgeler yalnızca bir sunum slaytında veya Excel dosyasında kalmamalıdır. Alım hattını ve çalışma zamanındaki mimariyi gerçekten şekillendirmelidir. Bu da pratikte ayrı depolama konumları, ayrı vektör koleksiyonları ve iş sahibi, bölge, saklama kuralı, onay durumu, veri konusu kategorisi ve izin verilen kitle gibi açık metadata alanları anlamına gelir. Zorunlu metadata olmadan gelen belge, sessizce varsayılan dizine düşmek yerine karantinaya alınmalıdır. Sınıflandırılmamış içerik, yalnızca zamanı belli olmayan bir güvenlik olayıdır.

Bilgi bölgelerini mevcut platform sınırlarıyla eşlemek de faydalıdır. Kubernetes namespace’leri, izole depolama alanları, ayrı arama kümeleri veya ayrılmış veritabanı şemaları aynı politika modelini teknik olarak güçlendirebilir. Buradaki amaç bürokrasi üretmek değildir. Amaç, gelecekteki kısa yol denemelerinin bu sınırları kolayca silememesidir. Eğer tek kontrol uygulama katmanındaki bir filtre ise, aceleyle yapılan tek bir kod değişikliği aylar süren yönetişimi etkisiz hale getirebilir. Sınırlar altyapıda ve erişim politikalarında da karşılık bulduğunda, hataları fark etmek kolaylaşır, yaymak zorlaşır.

Politika zorlamasını alım, retrieval ve yanıt üretimine yerleştirin

Bilgi bölgeleri tanımlandıktan sonra mimaride üç zorunlu kontrol noktası gerekir. Birincisi ingestion, yani içeriğin sisteme alınma aşamasıdır. Gelen her dosya zararlı yazılım taraması, belge sınıflandırması, metadata doğrulaması ve kaynak izlenebilirliğini koruyan parçalara ayırma kurallarından geçmelidir. Pek çok ekip embedding üretmeden önce Apache Tika benzeri belge işleme araçları, özel sınıflandırıcılar ve politika etiketleme adımları kullanır. Asıl kritik nokta, üretilen her parçanın belge sahibi ve sınıflandırma metadata’sına bağlı kalmasıdır. Aksi takdirde kısıtlı bir PDF’ten çıkan küçük bir metin parçası, bağlamını yitirmiş bir vektöre dönüşür.

İkinci kontrol noktası retrieval katmanıdır. Retrieval, alaka düzeyinden önce politikaya göre daraltılmalıdır. Başka bir deyişle aday kaynaklar; kullanıcı yetkisi, coğrafya, tenant, ortam ve iş akışı amacı gibi ölçütlere göre filtrelenmeden benzerlik araması yapılmamalıdır. Bu noktada nitelik tabanlı erişim kontrolü ve Open Policy Agent gibi politika motorları ciddi değer üretir. Finans analisti ile saha güvenilirlik mühendisi aynı “olay yönetimi” sorusunu sorabilir; ancak aynı koleksiyonlarda arama yapmamalıdır. Arama kapsamı da erişim kontrolünün bir parçasıdır.

Üçüncü kontrol noktası ise yanıt üretimi aşamasıdır. Politika filtreli retrieval sonrasında bile yanıt katmanı atıf kuralları, araç izinleri, redaksiyon kuralları ve gerektiğinde yanıt vermeme davranışını uygulamalıdır. Asistan, onaylı kaynaklardan yeterince temellendirilmiş bir cevap üretemiyorsa tahmin yürütmek yerine bunu söylemelidir. Bir sonraki aksiyon kısıtlı içeriği ifşa edecek veya dışa aktaracaksa süreç özet seviyesinde durmalı ya da onay adımına yönelmelidir. Çünkü tek bir kontrol mükemmel değildir. Güçlü şirket içi yapay zekâ sistemleri, sınıflandırma hatalarının, metadata boşluklarının ve istem istismarlarının yaşanacağını varsayar; sonra da etki alanını sınırlayacak çok katmanlı savunmayı kurar.

Karma hassasiyet düzeyleri için gerçekçi bir mimari örüntü

Diyelim ki bir üretim şirketi, fabrika operasyonları, satın alma, hukuk ve merkezi BT ekipleri için tek bir özel asistan deneyimi kurmak istiyor. Saf yaklaşım, her şeyi tek bir arama katmanına koyup rol bazlı arayüz kontrollerinin yeterli olacağını varsaymaktır. Daha kalıcı yaklaşım ise bakım prosedürlerini, onaylı arıza giderme rehberlerini ve makine kılavuzlarını kurum içi operasyon bölgesine; tedarikçi sözleşmelerini ve müzakere edilmiş hizmet koşullarını kısıtlı ticari bölgeye; çalışan kayıtlarını ve olay inceleme belgelerini ise ek onay gerektiren düzenlemeye tabi bölgeye yerleştirmektir. Aynı kullanıcı kimliği bu bölgelerde var olabilir; ancak asistan oturumu otomatik olarak hepsine erişmez.

Bu örüntüde ön yüz, kullanıcı jetonunu, iş bağlamını ve görev tipini bir orkestrasyon servisine iletir. Orkestrasyon katmanı, hangi retrieval bölgelerinin bu istek için uygun olduğunu çözer. Paketleme hattında sorun gideren bir mühendis, tesis prosedürlerinde, bilinen sorun özetlerinde ve onaylı satıcı kılavuzlarında arama yapabilir; ancak satıcıyla yürüyen hukuki yazışmaları veya insan kaynaklarının olay notlarını göremez. Soru bir sınırı aşıyorsa iş akışı dallanır: kullanıcıdan soruyu daraltması istenir, daha güçlü kontrollere sahip ayrı bir asistana yönlendirilir ya da insan inceleme kuyruğu tetiklenir.

Bu mimari denetimi de daha güvenilir hale getirir. Güvenlik ve uyum ekipleri hangi bölgelerde arama yapıldığını, hangi parçaların döndüğünü ve kullanıcıya hangi atıfların gösterildiğini inceleyebilir. Pek çok sektörde beklenti yalnızca modelin kurum içinde çalışması değildir; bilgi erişiminin kasıtlı olarak sınırlandığını ve izlenebilir olduğunu gösterebilmektir. Sadece on-prem dağıtım bunu tek başına sağlamaz. Bunu sağlayan şey iyi retrieval mimarisidir.

Sınırların zamanla bozulmaması için gerekli işletim alışkanlıkları

Sınır tasarımı bir defalık mimari egzersiz değildir. Düzenli işletim disiplini gerektirir. İlk adım, erişim haklarını periyodik gözden geçirmek ve bölge erişimlerinin gerçekten güncel sorumluluklarla uyumlu kalmasını sağlamaktır. Buna, metadata’sız yüklenen, yanlış sınıflanan veya karantinaya alınan içerikleri görünür kılan ingestion istisna raporlarını eklemek gerekir. Ayrıca kısıtlı bir kaynağın herkese açık bağlamdaki cevaba sızması gibi yasak kombinasyonları deneyen otomatik testler yayın kapılarına bağlanmalıdır. Aksi halde teslim baskısı yükseldiğinde ilk atlanan kontroller bunlar olur.

Yapay zekâya özgü hata senaryoları için masa başı tatbikatları da son derece değerlidir. Kısıtlı bir belge yanlışlıkla kurum içi olarak etiketlenirse ne olacak? Bir servis hesabına arıza sırasında geniş arama yetkisi verilip sonra bu yetki geri alınmazsa ne olacak? Asistan özetleri e-posta ile gönderebilen bir araca bağlandıysa, dışa aktarma sınırları nasıl korunacak? Olgun ekipler bu senaryoları dokümante eder, telafi edici kontroller tanımlar ve logların, alarmların ve geri alma prosedürlerinin gerçekten çalıştığını doğrular. Cevap hiçbir zaman “ekip zaten dikkat eder” olmamalıdır.

Çoğu kurum için en büyük iyileşme, bakış açısındaki küçük ama kritik değişimden gelir: RAG’i yalnızca özel altyapıya eklenmiş bir kolaylık özelliği olarak görmekten vazgeçmek. Onu kurumun bilgi kontrol düzleminin bir parçası olarak ele almak gerekir. Bilgi bölgeleri, metadata, politika ve çalışma zamanı zorlaması birlikte tasarlandığında, şirket içi yapay zekâ hem daha faydalı hem de daha savunulabilir hale gelir. Özellikle iş birimi tek bir asistan deneyimi isterken bilgi katmanının güvenlik riski haline gelmesini istemiyorsanız, sürdürülebilir yol budur.

Kapak görseli, Fabio Sasso tarafından çekilmiş ve Unsplash üzerinde yayımlanmıştır.