Blog Yazısı Özeti

Kurumsal yapay zeka asistanı artık yalnızca web sitesine eklenen basit bir sohbet kutusu değildir. Şirket dokümanlarını, prosedürleri, ürün bilgilerini, teknik servis kayıtlarını ve müşteri destek süreçlerini doğru kaynaklarla ilişkilendiren kontrollü bir bilgi erişim sistemi olarak tasarlanmalıdır.

Görsel kaynak: Unsplash

2026'da kurumların yapay zeka asistanlarından beklentisi değişti. İlk dönemlerde amaç, kullanıcının sorusuna akıcı bir cevap vermekti. Bugün ise asıl beklenti daha nettir: Asistan hangi kaynağa dayanarak cevap verdiğini gösterebilmeli, yetkisiz bilgiyi açığa çıkarmamalı, yanlış cevabı güvenle söylememeli ve canlı sistemlerle konuşurken sınırlarını bilmelidir.

Bu nedenle kurumsal yapay zeka asistanı projelerinde en kritik kavramlardan biri RAG mimarisidir. RAG, yani retrieval augmented generation, modelin yalnızca eğitim belleğine güvenmek yerine kurumun seçilmiş bilgi kaynaklarından ilgili parçaları bulup cevap üretmesi anlamına gelir. Fakat RAG tek başına güvenilirlik garantisi değildir. Kötü hazırlanmış dokümanlar, zayıf yetkilendirme, yanlış parçalara ayrılmış veri ve ölçülmeyen cevap kalitesi, iyi görünen bir asistanı operasyon riski haline getirebilir.

RAG neden kurumsal asistanların merkezinde?

Büyük dil modelleri genel bilgi üretmede güçlüdür; fakat bir şirketin fiyat listesi, bakım prosedürü, iç politika dokümanı veya proje notu gibi güncel ve kuruma özel bilgileri doğal olarak bilmez. Bu bilgiyi modele kalıcı olarak öğretmek çoğu zaman pahalı, yavaş ve veri yönetişimi açısından risklidir. RAG yaklaşımı burada daha pratik bir yol sunar.

Tipik bir RAG akışında dokümanlar önce temizlenir, bölümlere ayrılır, vektör temsillerine dönüştürülür ve arama yapılabilir bir indekse eklenir. Kullanıcı soru sorduğunda sistem önce ilgili doküman parçalarını bulur, sonra bu parçaları modelin cevap bağlamına verir. Böylece cevap, kurumun güncel ve kontrol edilmiş kaynaklarına dayanır.

Bu mimarinin değeri üç noktada ortaya çıkar:

  • Bilgi güncellendiğinde modeli yeniden eğitmeden doküman havuzu güncellenebilir.
  • Cevabın hangi kaynaklardan geldiği kullanıcıya gösterilebilir.
  • Farklı kullanıcı rolleri için farklı doküman kümeleri erişilebilir hale getirilebilir.

Ancak bu avantajlar yalnızca mimari doğru kurulursa geçerlidir. Bir asistan her kullanıcıya tüm dokümanları aratabiliyorsa RAG, bilgi güvenliği katmanı değil veri sızıntısı yüzeyi haline gelir.

Bilgi kaynağı seçimi model seçiminden önce gelir

Kurumsal yapay zeka asistanı projelerinde en sık yapılan hata, önce model seçip sonra dokümanları sisteme yüklemektir. Oysa başarılı bir asistanın ilk sorusu "hangi modeli kullanalım?" değil, "hangi bilgiyi kime, hangi bağlamda gösterebiliriz?" olmalıdır.

Başlangıçta dokümanlar en az dört gruba ayrılmalıdır:

  • Herkese açık bilgiler: web sitesi içerikleri, ürün tanıtımları, sık sorulan sorular.
  • Kurum içi operasyon bilgileri: prosedürler, bakım dokümanları, eğitim notları.
  • Sınırlı erişimli bilgiler: müşteri sözleşmeleri, teklif dosyaları, destek kayıtları.
  • Hassas bilgiler: kişisel veriler, sağlık verileri, finansal kayıtlar, gizli ticari bilgiler.

Her grup için farklı saklama, maskeleme, erişim ve loglama kuralları gerekir. Özellikle kişisel veri içeren dokümanlar kullanılıyorsa KVKK'nın üretken yapay zeka ve kişisel verilerle ilgili rehberlerinde vurgulanan şeffaflık, veri minimizasyonu, hukuki sebep, güvenlik ve ilgili kişi hakları proje başında değerlendirilmelidir.

Bu aşama teknik bir hazırlık gibi görünse de aslında ürün kararının merkezidir. Çünkü asistanın yanlış kişiye doğru bilgiyi göstermesi de, doğru kişiye yanlış bilgiyi göstermesi de işletme açısından sorun yaratır.

Güvenilir cevap için kaynak gösterme şart

Kurumsal asistanlarda "cevap verdi" metriği yeterli değildir. Cevap hangi dokümandan geldi, doküman ne zaman güncellendi, kullanıcı cevaba ne kadar güvenebilir, cevapta belirsizlik var mı gibi sorular izlenmelidir.

İyi tasarlanmış bir RAG asistanı şu davranışları sergiler:

  • Cevapta kullanılan kaynakları başlık veya bağlantı olarak gösterir.
  • Kaynak bulunamadığında uydurma cevap üretmek yerine bunu açıkça söyler.
  • Eski veya taslak dokümanları ana kaynak gibi kullanmaz.
  • Aynı soruya farklı kullanıcı rolleri için farklı erişim sınırları uygular.
  • Kritik aksiyonlarda insan onayı ister.

Bu yaklaşım NIST'in üretken yapay zeka risk profiliyle de uyumludur. NIST, üretken yapay zeka sistemlerinde güvenilirlik, ölçülebilirlik, risk yönetimi ve yaşam döngüsü boyunca değerlendirme ihtiyacını öne çıkarır. Kurumsal asistanı bir "demo" olarak değil, yaşayan bir bilgi sistemi olarak ele almak gerekir.

Güvenlik riski yalnızca veri sızıntısı değildir

OWASP GenAI Security Project'in 2025 LLM riskleri, kurumsal asistanlar için pratik bir kontrol listesi sunar. Prompt injection, hassas bilgi ifşası, tedarik zinciri riski, vektör ve embedding zayıflıkları, aşırı yetki ve kontrolsüz kaynak tüketimi gibi riskler artık teorik değildir.

Örneğin bir kullanıcı asistanı "önceki talimatları yok say" gibi bir komutla yönlendirmeye çalışabilir. Daha karmaşık senaryoda, doküman havuzuna eklenen kötü niyetli bir metin, asistanın başka kullanıcılara yanlış yönlendirme yapmasına neden olabilir. Asistan e-posta gönderme, kayıt açma, ödeme başlatma veya cihaz komutu verme gibi araçlara bağlıysa risk daha da büyür.

Bu nedenle güvenlik yalnızca modelin sistem prompt'una bırakılmamalıdır. Güçlü mimaride şu katmanlar birlikte çalışır:

  • Kimlik doğrulama ve rol bazlı yetkilendirme.
  • Doküman seviyesinde erişim kontrolü.
  • Girdi ve çıktı doğrulama.
  • Araca erişimde en az yetki prensibi.
  • Hassas veri maskeleme.
  • Cevap ve aksiyon logları.
  • Test soruları ve kırmızı takım senaryoları.

Özellikle canlı sistemlere bağlanan asistanlarda "model izin verdi" mantığıyla işlem yapılmaz. Yetki kontrolü uygulama katmanında, API seviyesinde ve gerekiyorsa iş akışı motorunda ayrıca uygulanır.

Değerlendirme seti olmadan canlıya çıkılmamalı

Bir kurumsal yapay zeka asistanı için en sağlıklı test yöntemi, gerçek kullanıcı sorularından oluşan bir değerlendirme seti hazırlamaktır. Bu sette kolay sorular kadar sınır durumları da bulunmalıdır.

Örnek test başlıkları:

  • Kaynağı net olan bilgi soruları.
  • Benzer dokümanlar arasında ayrım gerektiren sorular.
  • Yetkisiz bilgi talep eden kullanıcı soruları.
  • Kaynakta cevabı olmayan sorular.
  • Yanlış varsayım içeren sorular.
  • Çok adımlı süreç soruları.
  • Kişisel veri veya gizli bilgi içeren girdiler.

Her cevap doğruluk, kaynak uygunluğu, güvenlik, dil kalitesi ve aksiyon uygunluğu açısından puanlanmalıdır. Bu puanlama yalnızca ilk canlıya çıkıştan önce değil, doküman havuzu ve model değiştikçe tekrar edilmelidir.

Busana yaklaşımı

Busana için kurumsal yapay zeka asistanı, tek başına bir model entegrasyonu değildir. Doküman mimarisi, web paneli, API bağlantıları, yetkilendirme, loglama, kullanıcı deneyimi ve gerektiğinde mobil uygulama veya saha cihazlarıyla entegrasyon birlikte düşünülür.

Bir müşteri destek asistanı ile teknik servis asistanı aynı mimariye sahip olmak zorunda değildir. Klinik, laboratuvar, saha cihazı, kiosk veya spor merkezi gibi farklı sektörlerde bilgi kaynakları, hassasiyet seviyesi ve aksiyon riskleri değişir. Bu nedenle proje başlangıcında önce kullanım senaryosu, veri sınıflandırması ve karar sınırları netleştirilmelidir.

Doğru tasarlanmış bir yapay zeka asistanı, kurum içi bilgiyi daha erişilebilir hale getirir. Yanlış tasarlanmış bir asistan ise güvenilir görünerek hatalı kararları hızlandırır. Aradaki fark çoğu zaman model seçimi değil, mimari disiplindir.

Chunking, embedding ve arama stratejisi nasıl seçilmeli?

RAG mimarisinde dokümanları vektör veritabanına atmak tek başına yeterli değildir. Cevap kalitesini belirleyen en önemli kararlar doküman parçalama, metadata, embedding modeli ve arama stratejisidir.

Chunking için tek bir ideal boyut yoktur. Teknik prosedürler, fiyat listeleri, mevzuat metinleri, servis kayıtları ve sık sorulan sorular farklı parçalama mantığı ister. Çok küçük chunk, bağlamı koparır; çok büyük chunk, modelin gereksiz bilgiyle dolmasına neden olur. Başlangıç için paragrafa veya başlığa duyarlı chunking, her parçaya doküman adı, bölüm, tarih, versiyon ve erişim seviyesi metadata'sı eklemek iyi bir temeldir.

Arama tarafında yalnızca semantik vektör arama her zaman yeterli değildir. Kurumsal dokümanlarda ürün kodu, sözleşme numarası, cihaz seri numarası veya prosedür adı gibi kesin eşleşmeler önemlidir. Bu nedenle birçok projede hybrid search, yani anahtar kelime araması ile vektör aramasını birleştiren yaklaşım daha iyi sonuç verir. Sonuçları yeniden sıralamak için reranker kullanmak da özellikle benzer dokümanların çok olduğu kurumlarda kaliteyi artırır.

Pratik karar tablosu:

  • SSS ve kısa bilgi sayfaları: küçük/orta chunk, başlık metadata'sı, kaynak gösterme.
  • Teknik servis prosedürü: bölüm bazlı chunk, cihaz modeli metadata'sı, versiyon kontrolü.
  • Sözleşme ve politika dokümanı: madde bazlı chunk, geçerlilik tarihi, erişim seviyesi.
  • Ürün kataloğu: ürün kodu, kategori ve dil metadata'sı; hybrid search.
  • Destek kayıtları: müşteri ve kişisel veri maskeleme; rol bazlı erişim.

Yetkilendirme RAG katmanında değil, veri katmanında başlamalı

RAG asistanlarında sık yapılan hata, yetkilendirmeyi yalnızca prompt ile çözmeye çalışmaktır. "Kullanıcının yetkisi olmayan bilgiyi gösterme" talimatı faydalıdır; fakat güvenlik kontrolü değildir. Kullanıcıya hangi doküman parçalarının getirileceği, model çağrısından önce uygulama ve veri erişim katmanında sınırlandırılmalıdır.

Kurumsal mimaride her doküman parçasına şu metadata'lar eklenebilir:

  • erişim seviyesi,
  • departman,
  • müşteri veya proje kodu,
  • doküman türü,
  • geçerlilik tarihi,
  • kaynak sistem,
  • kişisel veri içerip içermediği.

Kullanıcı soru sorduğunda retrieval katmanı yalnızca kullanıcının rolüne, departmanına ve proje yetkisine uygun parçaları aramalıdır. Modelin hiç görmediği bilgiyi sızdırması çok daha zordur. Bu yaklaşım KVKK açısından da veri minimizasyonu ve amaçla sınırlılık ilkeleriyle daha uyumludur.

Değerlendirme yalnızca cevap doğruluğu değildir

Kurumsal RAG projelerinde değerlendirme seti en az beş boyutu ölçmelidir:

  • Retrieval kalitesi: Doğru kaynak parçaları getirildi mi?
  • Cevap doğruluğu: Cevap kaynakla uyumlu mu?
  • Kaynak sadakati: Model kaynakta olmayan bilgi uydurdu mu?
  • Güvenlik: Yetkisiz bilgi, kişisel veri veya hassas alan sızdı mı?
  • Kullanılabilirlik: Cevap kullanıcının iş akışında aksiyon alınabilir mi?

Bu nedenle test seti yalnızca "soru-cevap" listesi olmamalıdır. Her test sorusunda beklenen kaynak, kabul edilebilir cevap, reddedilmesi gereken durum ve güvenlik notu bulunmalıdır. Özellikle "kaynakta cevabı yok" soruları test setine eklenmelidir; çünkü iyi asistanın en önemli yeteneklerinden biri bilmediğini söyleyebilmesidir.

Canlı sonrası izleme de aynı derecede önemlidir. Kaynak bulunamayan sorular, düşük güvenli cevaplar, kullanıcı geri bildirimleri ve manuel düzeltmeler periyodik olarak incelenmelidir. Bu veriler doküman havuzunu, chunking stratejisini ve değerlendirme setini iyileştirmek için kullanılır.

Araç kullanan asistanlarda sınır daha sıkı olmalı

Bir asistan yalnızca cevap veriyorsa risk sınırlıdır. Fakat kayıt açıyor, e-posta gönderiyor, ödeme başlatıyor, stok güncelliyor, randevu oluşturuyor veya cihaz komutu veriyorsa artık agentic bir iş akışına yaklaşır. Bu durumda RAG güvenliği yeterli değildir; araç yetkileri ayrıca tasarlanmalıdır.

Güvenli araç kullanımı için şu kontroller gerekir:

  • Her araç için ayrı yetki kapsamı.
  • Kritik aksiyonlarda insan onayı.
  • Parametre doğrulama.
  • İşlem öncesi özet ve kullanıcı onayı.
  • Idempotency key ile tekrar işlem koruması.
  • Audit log.
  • Geri alma veya telafi akışı.

Örneğin teknik servis asistanı "bu müşteriye bakım kaydı aç" diyebilir; fakat kayıt açmadan önce müşteri, cihaz, arıza tipi ve yetkili kullanıcı doğrulanmalıdır. Kiosk veya saha cihazı gibi fiziksel sisteme komut veren asistanlarda bu kontrol daha da kritiktir.

Kaynaklar