Yapay Zeka Danışmanlığı ile Şirket İçi Bilgi Asistanı İçin Veri Yetkileri Nasıl Tasarlanır?

Bilgi Asistanında Veri Yetkileri Nereden Başlamalı?

Şirket içi bilgi asistanında veri yetkileri, model seçiminden önce kaynak ve erişim haritası çıkarılarak tasarlanmalıdır. Hangi belge havuzlarının bulunduğu, bu kaynakların kim tarafından yönetildiği, kimlerin hangi klasörlere veya kayıtlara erişebildiği ve izinlerin hangi sistemlerde tutulduğu netleşmeden güvenli bir asistan mimarisi kurulamaz. Çünkü asistanın verebileceği yanıt sınırı, kullanıcının mevcut bilgi sistemlerindeki gerçek erişim sınırıyla aynı olmalıdır.

İlk envanter hangi bilgileri içermeli?

Envanter çalışması yalnızca dosya adlarını listelemek değildir. Departman, belge sahibi, gizlilik sınıfı, güncelleme sıklığı, kullanıcı grubu ve mevcut yetkilendirme yöntemi birlikte kaydedilmelidir. Bu yaklaşım, kurumsal AI asistanlarının kullanım senaryolarını teknik erişim gerçekliğiyle eşleştirmeyi kolaylaştırır. Böylece proje ekibi hangi kaynakların pilota alınacağını, hangilerinin kapsam dışında tutulacağını ve hangi izin bilgilerinin entegrasyonla taşınacağını erken aşamada belirleyebilir.

• Belge kaynağı ve sistem sahibi
• Kullanıcı, grup ve rol yapısı
• Belgenin gizlilik veya sınıflandırma seviyesi
• Güncelleme ve arşivleme sorumluluğu
• Mevcut erişim kontrol mekanizması

Güvenlik bir süreçtir, bir ürün değil. - Bruce Schneier

Mevcut Belge İzinleri Bilgi Asistanına Nasıl Aktarılır?

Mevcut belge erişim izinleri asistana, mümkün olduğunca kaynak sistemdeki kimlik ve grup bilgisini yeniden kullanarak aktarılmalıdır. Dosyaları yeni bir depoya kopyalayıp ayrı bir yetki listesi oluşturmak, zamanla iki sistem arasında uyumsuzluk yaratabilir. Bunun yerine kullanıcı kimliği, grup üyeliği, klasör veya kayıt erişimi ve gerekirse belge seviyesindeki kurallar arama ve yanıt üretme katmanında kontrol edilmelidir.

Yetki senkronizasyonunda hangi katmanlar gerekir?

Kimlik sağlayıcı, belge kaynağı, arama dizini ve asistan servisi arasında tutarlı bir eşleme kurulması gerekir. Özellikle ERP, intranet, dosya sunucusu, SharePoint benzeri havuzlar veya özel uygulamalar bir arada kullanılıyorsa entegrasyon ve veri yönetimi yaklaşımı yetki bilgisini de kapsamalıdır. İzin değişikliklerinin ne kadar sürede yansıyacağı, silinen kullanıcıların erişiminin nasıl kesileceği ve geçici grupların nasıl ele alınacağı proje kapsamına yazılmalıdır.

• Tekil kullanıcı kimliğinin eşlenmesi
• Rol ve grup üyeliklerinin taşınması
• Belge veya klasör bazlı izinlerin korunması
• İzin değişikliklerinin düzenli senkronizasyonu
• Erişimi kaldırılan hesapların hızlı devre dışı bırakılması

Yetkisiz Kaynaklardan Yanıt Alınması Nasıl Önlenir?

Yetkisiz kaynaklardan yanıt alınmasını önlemek için erişim kontrolü yalnızca kullanıcı arayüzünde değil, arama ve getirme katmanında uygulanmalıdır. Kullanıcının sorusu sisteme geldiğinde önce kimliği doğrulanmalı, ardından yalnızca o kimliğin erişebildiği belge parçaları aday kaynak olarak seçilmelidir. Modelin daha sonra yasaklı içerikleri ayıklamasına güvenmek yeterli değildir; yetkisiz içerik mümkünse modele hiç gönderilmemelidir.

Güvenlik testleri hangi senaryoları kapsamalı?

Testler normal kullanım kadar sınır ihlali denemelerini de içermelidir. Farklı departman kullanıcılarının aynı soruya verdiği yanıtların kaynak bazında ayrışması, bağlantıyla erişilemeyen belgelerin sonuçlara sızmaması ve rol değişikliğinin yeni oturumda doğru uygulanması kontrol edilmelidir. güvenlik hizmetlerinin yönetim mantığında olduğu gibi loglama, izleme ve periyodik kontrol burada da tek seferlik kurulumdan daha önemlidir.

• Yetkili ve yetkisiz kullanıcı karşılaştırma testleri
• Doğrudan belge bağlantısı üzerinden erişim kontrolleri
• Rol değişikliği sonrası izin doğrulaması
• Kaynak filtrelerinin atlatılmasına yönelik negatif testler
• Şüpheli sorgu ve erişim olaylarının kayıt altına alınması

Eski ve Çelişkili Belgeler Bilgi Asistanında Nasıl Yönetilir?

Eski veya çelişkili belgeler, asistanın güvenilirliğini doğrudan etkilediği için içerik yaşam döngüsü kurallarıyla yönetilmelidir. Modelin hangi belgenin güncel olduğunu kendi başına tahmin etmesi beklenmemelidir. Yayın tarihi, sürüm, belge sahibi, geçerlilik durumu ve öncelik bilgisi mümkün olduğunca metadata olarak tutulmalı; yürürlükten kaldırılan içerikler arama kapsamından çıkarılmalı veya açık biçimde arşiv statüsüne alınmalıdır.

Belge yönetişimi proje kapsamına nasıl girer?

Teknik ekip indeksleme ve erişim katmanını kurabilir; ancak hangi belgenin doğru veya güncel olduğuna iş birimi karar vermelidir. Bu nedenle AI destekli doküman yönetimi yaklaşımında içerik sahipliği, sürümleme ve güncelleme sorumluluğu açıkça tanımlanmalıdır. Çelişkili iki kaynak aynı anda geçerliyse asistanın tek bir kesin cevap vermek yerine kaynakları belirtmesi ve belirsizliği kullanıcıya göstermesi daha güvenli bir davranış olabilir.

• Belge sahibi ve onay sorumlusunun tanımlanması
• Geçerlilik tarihi ve sürüm bilgisinin tutulması
• Arşiv içeriklerinin aktif sonuçlardan ayrılması
• Çelişkili kaynaklarda öncelik kuralı belirlenmesi
• Yanıtlarda kaynak ve tarih bilgisinin gösterilmesi

Kimlik Sistemi Entegrasyonu Teklifte Nasıl Yer Almalı?

Kimlik sistemi entegrasyonu, kurumsal bilgi asistanı teklifinde ayrı ve görünür bir iş paketi olmalıdır; çünkü oturum açma ile yetkilendirme aynı şey değildir. Tek oturum açma kullanıcıyı tanır, ancak hangi belgeye erişebileceğini belirlemek için grup, rol ve kaynak izinlerinin ayrıca taşınması gerekir. Teklifte desteklenecek kimlik sağlayıcı, entegrasyon yöntemi, test ortamı, oturum davranışı ve kullanıcı yaşam döngüsü açıkça tanımlanmalıdır.

Teklif kalemi hangi teknik ayrıntıları içermeli?

Kuruluşta Microsoft Entra ID, LDAP, özel SSO veya başka bir kimlik altyapısı kullanılıyor olabilir. Danışmanlık sürecinde mevcut yapı incelenmeli ve entegrasyonun hangi protokol veya API üzerinden yapılacağı belirlenmelidir. Ayrıca yeni çalışan, departman değiştiren kullanıcı ve işten ayrılan hesap gibi senaryolar için beklenti yazılı hale getirilmelidir. Böylece teklif yalnızca giriş ekranı entegrasyonunu değil, erişim kararının uçtan uca nasıl uygulanacağını kapsar.

• Kimlik sağlayıcı ve entegrasyon yöntemi
• Rol ve grup bilgisinin kaynağı
• Oturum ve token yaşam döngüsü
• Kullanıcı ekleme, taşıma ve kapatma senaryoları
• Test ortamı ve kabul kriterleri

Yanıtların Kaynak Göstermesi Neden Zorunlu Olmalı?

Şirket içi bilgi asistanında kaynak gösterme, yalnızca kullanıcı deneyimi özelliği değil, doğrulanabilirlik ve erişim denetimi için temel bir kontroldür. Kullanıcı yanıtın hangi belgeye, bölüme veya kayıt tarihine dayandığını görebildiğinde bilgiyi kontrol edebilir. Aynı zamanda proje ekibi hatalı bir cevabın model davranışından mı, yanlış indekslenmiş içerikten mi yoksa güncel olmayan kaynaktan mı doğduğunu daha hızlı teşhis edebilir.

Yanıt verilemeyen durumda sistem ne yapmalı?

Asistan yeterli ve yetkili kaynak bulamadığında bunu açıkça söylemelidir. Benzer görünen fakat erişim dışı bir belgeden tahminde bulunmak veya genel model bilgisini kurumsal gerçek gibi sunmak özellikle iç süreçlerde risk yaratır. Projede “yanıt yok”, “kaynak yetersiz” ve “birden fazla çelişkili kaynak var” davranışları ayrı senaryo olarak tanımlanmalı; kullanıcıya gerekirse belge sahibine veya ilgili birime yönlendirme yapılmalıdır.

• Her önemli iddia için görünür kaynak bağlantısı
• Belge adı, sürüm veya tarih bilgisinin gösterimi
• Kaynak bulunamadığında açık belirsizlik mesajı
• Genel model bilgisi ile kurum içi bilginin ayrılması
• Hatalı kaynakları bildirmek için geri bildirim mekanizması

Kullanım Kayıtları ve Denetim İzleri Nasıl Tasarlanmalı?

Kullanım kayıtları, hangi kullanıcının hangi soruyu sorduğunu kaydetmekten daha geniş bir denetim izi yaklaşımıyla tasarlanmalıdır. Özellikle hangi kaynakların getirildiği, hangi izin filtresinin uygulandığı, hangi yanıtın üretildiği ve kullanıcıya hangi bağlantıların gösterildiği gerektiğinde incelenebilmelidir. Bununla birlikte loglama kapsamı şirketin gizlilik, veri saklama ve çalışan verisi politikalarıyla uyumlu biçimde sınırlandırılmalıdır.

Loglar hangi amaçlarla kullanılmalıdır?

Operasyon ekibi logları erişim hatalarını araştırmak, içerik ekibi güncel olmayan kaynakları tespit etmek ve proje yöneticileri sık sorulan ancak karşılanamayan bilgi ihtiyaçlarını görmek için kullanabilir. Her veriyi süresiz saklamak yerine amaç, saklama süresi ve erişim yetkisi belirlenmelidir. Hassas sorguların maskeleme veya sınırlı erişim gerektirip gerektirmediği de proje gereksinimleri hazırlanırken hukuk, bilgi güvenliği ve insan kaynakları gibi ilgili ekiplerle değerlendirilmelidir.

• Kullanıcı ve oturum olaylarının izlenmesi
• Getirilen kaynakların denetim kaydı
• Yetki filtresi sonucunun kaydedilmesi
• Log erişimi ve saklama süresinin tanımlanması
• Hassas veriler için maskeleme kurallarının belirlenmesi

Pilot Departman ve Kabul Testleri Nasıl Seçilmelidir?

Pilot, en çok belgesi olan departmanda değil, ölçülebilir bilgi ihtiyaçları ve yönetilebilir risk sunan bir alanda başlatılmalıdır. Seçilen ekipte sık tekrarlanan sorular, erişim seviyeleri, belge sahipleri ve beklenen yanıt türleri önceden tanımlanabiliyorsa kabul testleri daha nesnel yapılabilir. Pilotun amacı yalnızca çalışanların sistemi beğenmesi değil, doğru kullanıcıya doğru kaynaktan güvenilir yanıt üretildiğini kanıtlamaktır.

Kabul testlerini hangi ekipler birlikte yapmalı?

İş birimi beklenen cevabı ve kaynak doğruluğunu; IT kimlik, entegrasyon ve performansı; bilgi güvenliği ise yetki sınırlarını test etmelidir. Gerekirse hukuk veya uyum ekibi de hassas içerik senaryolarına katılabilir. yapay zekâ tabanlı otomasyon altyapısının hazırlanmasında olduğu gibi pilot kriterlerinin üretim öncesinde yazılılaştırılması, teknik başarının kullanım başarısıyla karıştırılmasını önler.

• İş birimi tarafından doğrulanan örnek sorular
• Yetkili ve yetkisiz erişim testleri
• Kaynak doğruluğu ve güncellik kontrolleri
• Kimlik ve entegrasyon hata senaryoları
• Üretime geçiş için ortak kabul tutanağı

Kurumsal AI Veri Mimarisi Teklifte Nasıl Ayrıştırılır?

Kurumsal AI veri mimarisi teklifi, tek bir “asistan geliştirme” kalemi yerine ayrı teslimat ve sorumluluk paketlerine bölünmelidir. Veri kaynaklarının bağlanması, belge hazırlığı, kimlik entegrasyonu, indeksleme, yetki filtreleri, model veya servis entegrasyonu, loglama, test ve içerik operasyonu farklı risklere sahiptir. Bu ayrım hem tekliflerin karşılaştırılmasını kolaylaştırır hem de proje sonrasında hangi bileşenin kim tarafından işletileceğini görünür hale getirir.

Teklif karşılaştırırken hangi sorular sorulmalı?

İki sağlayıcının aynı “kurumsal bilgi asistanı” ifadesini kullanması aynı kapsamı sundukları anlamına gelmez. Bir teklif mevcut erişim izinlerini dinamik olarak kullanırken diğeri manuel rol listeleri önerebilir; biri kaynak güncellemesini otomatikleştirirken diğeri müşteri ekibine bırakabilir. Bu nedenle lisans, geliştirme, entegrasyon, bakım, içerik sorumluluğu ve güvenlik testleri birbirinden ayrılmalı; sahiplik ve devir teslim koşulları sözleşmede açıkça belirtilmelidir.

• Veri kaynağı ve içerik hazırlığı kapsamı
• Kimlik ve yetkilendirme entegrasyonu
• Arama, model ve uygulama katmanı
• Test, loglama ve izleme sorumlulukları
• Bakım, güncelleme ve devir teslim modeli

Danışmanlık Görüşmesine Hangi Gereksinimlerle Gidilmeli?

Yapay zeka danışmanlığı görüşmesine hazırlanırken şirketin tüm teknik ayrıntıları çözmüş olması gerekmez; ancak kaynaklar, kullanıcı rolleri ve risk sınırları hakkında başlangıç verisi sunması gerekir. En değerli ön hazırlık, hangi ekiplerin hangi bilgilere eriştiğini, hangi kaynakların kritik olduğunu, hangi soruların sık sorulduğunu ve yanlış bir yanıtın ne tür operasyonel sonuç doğuracağını belirlemektir. Bu çerçeve, iç bilgi asistanı teklifinin gerçek ihtiyaca göre kapsamlandırılmasını sağlar.

İlk değerlendirme dosyasında neler bulunmalı?

IT ve iş birimleri birlikte belge sistemlerini, kullanıcı gruplarını, örnek soruları, mevcut kimlik altyapısını ve içerik sahiplerini listelemelidir. Mümkünse pilotta kullanılacak sınırlı bir kaynak seti ve kabul senaryoları da eklenmelidir. Böylece danışmanlık görüşmesi soyut ürün özelliklerinden ziyade veri erişimi, güvenlik, entegrasyon ve işletim sorumlulukları üzerinden ilerler; teklifin karşılaştırılabilir ve uygulanabilir hale gelmesi kolaylaşır.

• Belge kaynakları ve sorumlu ekipler
• Kullanıcı rolleri ve erişim grupları
• Örnek sorular ve beklenen kaynaklar
• Kimlik altyapısı ve entegrasyon noktaları
• Pilot kapsamı ve kabul ölçütleri