Enterprise AI: Kurumsal Veri Güvenliği, Rol Tabanlı RAG Mimarisi ve Zero-Latency CDC Entegrasyonu
Yazar: Bahadır Hakan Yüksel
Merhaba! Ben Bahadır. Bu yazımda sizlere, kurumsal şirketlerin yapay zeka adaptasyonunda karşılaştığı en büyük iki sorun olan “Veri Gizliliği (Data Privacy)” ve “Yapay Zeka Halüsinasyonu” problemlerini kökünden çözen, baştan uca tasarlayıp geliştirdiğim Enterprise AI projesinin mimarisini ve mühendislik detaylarını anlatacağım. Keyifli okumalar!
1. Özet
Günümüzde birçok şirket, ChatGPT veya Claude gibi bulut tabanlı Büyük Dil Modellerini (LLM) kullanırken şirket içi hassas verilerini (maaş tabloları, ticari sırlar, gizli arıza kayıtları) dış sunuculara gönderme riskiyle karşı karşıya kalmaktadır. Üstelik bu modeller, bağlamı tam kavrayamadıklarında uydurma (Hallucination) cevaplar üreterek kurumsal güvenilirliği zedelemektedir.
Bu makale, %100 yerel (On-Premise) çalışan, veriyi dışarı sızdırmayan ve Rol Tabanlı RAG (Retrieval-Augmented Generation) mimarisiyle departmanlar arası veri izolasyonu sağlayan Enterprise AI sistemini detaylıca incelemektedir. Sistem, ağır mesaj kuyruklarına (Kafka/RabbitMQ) ihtiyaç duymadan, PostgreSQL’in yerleşik Pub/Sub (LISTEN/NOTIFY) mekanizmasını kullanarak sıfır gecikmeli (Zero-Latency) Change Data Capture (CDC) altyapısı kurmuş; hibrit arama (TF-IDF + Vektör) teknolojisiyle halüsinasyon ve çapraz veri kirliliğini (Cross-Contamination) tamamen ortadan kaldırmıştır.

(Görsel 1: Enterprise AI)
2. Giriş ve Temel Problemler
Kurumsal bir yapay zeka asistanı geliştirirken geleneksel “tak-çalıştır” (plug-and-play) RAG yaklaşımları yetersiz kalmaktadır. Projeye başlarken karşılaştığımız üç temel mühendislik problemi şunlardı:
-
Veri Sızıntısı ve İzolasyon: İnsan Kaynakları (İK) departmanına ait maaş verilerinin veya Teknik servise ait gizli onarım loglarının, Satış departmanındaki bir çalışanın sorduğu soruya cevap olarak dönmemesi gerekiyordu.
-
İkili Yazma (Dual-Write) ve Gecikme: Kurum içindeki eski (Legacy) muhasebe/ERP sistemlerinden veritabanına akan anlık verilerin, yapay zekanın belleğine (Vektör DB) gecikmesiz olarak aktarılması gerekiyordu. Aksi takdirde AI, güncel olmayan verilere dayanarak yanlış raporlar verebilirdi.
-
Cross-Contamination (Çapraz Veri Kirliliği): Yapay zekanın bağlam (Context) penceresine birden fazla belge girdiğinde (Örneğin; A şirketinin faturası ve B şirketinin arıza kaydı), modelin farklı belgelerdeki sayıları ve adları birbirine karıştırması (Halüsinasyon) büyük bir veri tutarsızlığına yol açıyordu.
(Görsel 2: Enterprise AI Genel Arayüz ve Sistem Tasarımı)
Bu bağlamda Enterprise AI, verinin yaratıldığı saniyede yapay zekaya öğretildiği, departman sınırlarının kriptografik token’larla (JWT) korunduğu ve arama katmanının donanımsal düzeyde izole edildiği kusursuz bir mimari sunmaktadır.
3. Dağıtık Sistem Teorisi ve Mimari Kararlar
Projenin temelini oluşturan olay güdümlü (Event-Driven) mimarinin arkasında keskin mühendislik tercihleri yatmaktadır.
3.1. Zero-Latency Native CDC (Change Data Capture)
Geleneksel mikroservis mimarilerinde veritabanı ile AI belleğinin (ElasticSearch, ChromaDB vb.) senkronizasyonu için genellikle Debezium ve Apache Kafka gibi ağır ara katmanlar (middleware) kullanılır. Ancak MVP (Minimum Viable Product) aşamasında hem sistem kompleksitesini düşürmek hem de veri gecikmesini (Latency) sıfıra indirmek için PostgreSQL Native LISTEN/NOTIFY mimarisi kullanılmıştır.
Veritabanı seviyesinde yazılan özel Trigger’lar, tabloya dışarıdan (psql, pgAdmin, veya eski bir ERP yazılımı üzerinden) saf SQL ile bir INSERT veya UPDATE geldiği saniye, bunu bir “Olay (Event)” olarak fırlatır.
-- PostgreSQL Trigger Örneği (Zero-Latency CDC)
CREATE OR REPLACE FUNCTION notify_crud_event() RETURNS TRIGGER AS $$
BEGIN
-- Sadece tablo adı ve işlem tipini (INSERT/UPDATE) fırlatıyoruz
PERFORM pg_notify(
'enterprise_updates',
TG_TABLE_NAME || ':' || TG_OP
);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
Spring Boot içerisindeki PostgresNotifyListenerService, bu asenkron sinyali JDBC kanalı üzerinden milisaniyeler içinde yakalar ve RAM üzerindeki RAG belleğini (In-Memory Search) anında günceller. Bu sayede “Polling” (her 5 saniyede bir veritabanını sorgulama) yükü tamamen ortadan kaldırılarak sunucu yorulmadan %100 Event-Driven bir CDC mimarisi kurulmuştur.
(Görsel 3: Veritabanına yeni bir kayıt eklendiğinde yönetici panelinde anında beliren “Live CDC” bildirimi)
3.2. Race Condition (Yarış Durumu) Optimizasyonu
Gerçek zamanlı senkronizasyon harika bir hız sunsa da, beraberinde “Çoklu İş Parçacığı (Multi-Threading)” sorunlarını getirir. Veritabanına aynı milisaniyede gelen yüzlerce isteğin (Örneğin bir toplu fatura aktarımı) RAM’i aynı anda şişirdiği ve Java’da ConcurrentModificationException hatasına yol açtığı tespit edilmiştir.
Bu yarış durumu (Race Condition), bellek yenileme metodunun synchronized bloklar ile (Thread-Safe) kapsüllenmesiyle çözülmüştür:
// Thread-Safe bellek yenileme metodu
public synchronized void reloadFromSql() {
log.info("Bellek içi arama motoru güncelleniyor...");
inMemoryDb.clear();
// Veritabanından en güncel verilerin RAM'e çekilmesi işlemi...
}
Bu ufak ama kritik mühendislik dokunuşu sayesinde, asenkron veritabanı olayları sırasında bellek taşmaları ve çakışmalar kalıcı olarak engellenmiştir.
3.3. Rol Tabanlı RAG (RBAC in Retrieval) ve Veri İzolasyonu
Geleneksel uygulamalarda güvenlik, veritabanı sorgularının (SELECT * FROM… WHERE user_id=?) sınırlandırılmasıyla sağlanır. Ancak RAG mimarisinde, tüm dokümanlar devasa bir Vektör Veritabanında (ChromaDB) karmaşık vektörler olarak durur.
Enterprise AI, veri güvenliğini “Uygulama Katmanı”nda değil, doğrudan “Arama Katmanı”nda (Retrieval Layer) çözer. Sistem, giriş yapan kullanıcının JWT (JSON Web Token) içerisindeki Rolünü (Örn: ROLE_SATIS) okur. Kullanıcı bir soru sorduğunda, ChromaDB’ye giden vektör arama sorgusunun içine metadata = { department: “ROLE_SATIS” } filtresi (Pre-Filtering) sert bir şekilde gömülür.
Satış Departmanı

Teknik Departmanı

İK Departmanı

(Görsel 4: Aynı sorunun Satış, Teknik ve İK rollerine göre filtrelenerek sadece kendi yetki alanlarındaki verilerle
cevaplanması – Role-Based)
Bu sayede yapay zeka modeli, diğer departmanların verilerini “okuyup elemeye” çalışmaz; o verileri arama uzayında (Vector Space) hiç görmez. Bu donanımsal düzeydeki körlük, veri sızıntısını matematiksel olarak imkansız hale getirir. Yönetici (Admin) hesabı ise bu filtreleri dinamik olarak “Bypass” ederek tüm şirketin melez (Hybrid) veri havuzuna erişim sağlar.
3.4. Katmanlı Şifreleme ve Veri Güvenliği (AES-256 & BCrypt)
Veri güvenliği sadece izole arama (RBAC) ile sınırlı kalmayıp, projenin temelini oluşturan Şifreleme (Encryption) mekanizmalarıyla da çift katmanlı hale getirilmiştir:
-
Kullanıcı Güvenliği: Sisteme kaydedilen tüm kullanıcı parolaları, veritabanına düz metin (plain-text) olarak değil, Spring Security entegrasyonu üzerinden endüstri standardı BCrypt algoritması ile tek yönlü (one-way) hash’lenerek kaydedilir.
-
Kurumsal Veri ve Mesaj Şifreleme: Eski sistemlerden (ERP vb.) akan hassas ticari veriler (fatura detayları, arıza logları vs.), vektör veritabanına (ChromaDB) veya yapay zekaya gönderilmeden önce backend tarafındaki özel bir
EncryptionServicearacılığıyla AES-256 standardında şifrelenir (Encryption at Rest). Vektör veri tabanına işlenen her bir “Document” kriptoludur. Yapay zeka modeli soruyu cevaplayacağı saniye, veriler sadece o milisaniyede RAM üzerinde deşifre edilir (Decrypt) ve LLM’e sunulur. Böylece veritabanı dışarıdan sızdırılsa bile, içindeki belgeler şifreli olduğu için okunamaz durumdadır.
4. Prompt Engineering ve Halüsinasyon Kontrolü
RAG sistemlerinin en büyük ve en tehlikeli dezavantajlarından biri “Çapraz Veri Kirliliği” (Cross-Contamination) problemidir. LLM, birden fazla farklı bağlamı (Context) okurken sayıları ve firmaları birbirine karıştırabilir. Örneğin; A firmasının sipariş adedi (18 adet), B firmasının garanti süresiyle (24 ay) birleşip yepyeni ve “uydurma” bir senaryo yaratabilir.
Bunu çözmek için sisteme hibrit arama (TF-IDF tabanlı kesin arama + Vector Similarity) entegre edilmiş ve modelin çekirdek prompt’una (System Prompt) Strict Isolation (Katı İzolasyon) kuralı yazılmıştır:
KURAL 6: ÇAPRAZ VERİ KARIŞTIRMA KESİNLİKLE YASAKTIR.
Birden fazla belge gelirse, sadece sorulan firma veya konu ile birebir eşleşen belgedeki bilgileri kullan. Farklı belgelerdeki (farklı şirketlere ait) sayıları, adetleri veya süreleri birbiriyle BİRLEŞTİRME!
Bu prompt mühendisliği dokunuşu sayesinde sistemin halüsinasyon üretme riski büyük ölçüde minimize edilmiş ve üretim ortamında (Production) kabul edilebilir yüksek bir doğruluk oranına ulaşılmıştır. AI, bağlamda olmayan veya yetkisi dışındaki bir soru geldiğinde “Bu bilgi yetki alanımda veya kurumsal kaynaklarımda bulunmamaktadır” diyerek profesyonelce reddetmeyi öğrenmiştir.

(Görsel 5: AI asistanın kurumsal veri seti dışındaki soruları profesyonelce reddetmesi)
5. Yönetici Paneli (Admin Dashboard) ve Operasyonel Gözetim
Kurumsal bir sistem, sadece iyi bir yapay zeka sunmaktan öte; maliyetleri, güvenliği ve kullanıcı etkileşimlerini denetleyebilecek güçlü bir operasyonel arayüze ihtiyaç duyar. Enterprise AI, tam donanımlı bir Admin Dashboard ile yöneticilere tam kontrol sağlar:
-
Token Optimizasyonu ve Tüketim Takibi: LLM kullanımının en büyük maliyeti (donanımsal veya API bazlı) tüketilen “Token” miktarıdır. Arka planda context (bağlam) penceresini daraltarak ve RAG parçalarını (Chunking) optimize ederek token kullanımını minimize edecek mimariler kurguladık. Hem yönetici hem de normal kullanıcılar, kendi profillerinde veya admin panelinde anlık olarak ne kadar token harcadıklarını istatistiksel olarak takip edebilirler.
-
Rol (RBAC) Yönetimi: Sisteme yeni kayıt olan kullanıcıların rolleri (Satış, İK, Teknik) yönetici tarafından atanır ve değiştirilir. Bu atama yapıldığı an RAG filtreleri o kullanıcı için otomatik olarak şekillenir.
-
Sohbet Geçmişi Gözetimi (Chat History): Şirket veri güvenliğini korumak adına, yöneticiler sistemdeki kullanıcıların yapay zeka ile olan tüm sohbet geçmişlerine erişebilir. Böylece AI’ın amacı dışında kullanılıp kullanılmadığı denetlenebilir.
-
Sistem Logları (Audit Logs): Giren çıkan sorgular, hata kodları ve sistem genelindeki hareketler, “System Logs” sekmesi altında canlı olarak izlenebilir.
(Görsel 6: JWT tabanlı güvenli giriş ekranı)
(Görsel 7: Kullanıcı profili ve anlık token tüketim istatistikleri)
(Görsel 8: Admin Paneli)
(Görsel 9: Yöneticilerin sistemdeki kullanıcı sohbet geçmişini denetleme ekranı)
6. Frontend Mimarisi: Modern, Hızlı ve Akıcı
Kullanıcı deneyimi (UX), böyle güçlü bir altyapının vitrinidir. Next.js 14, React ve Tailwind CSS ile geliştirilen arayüzde şu prensipler benimsenmiştir:
-
Glassmorphism & Koyu Tema (Dark Mode): Kurumsal ciddiyeti yansıtan, göz yormayan karanlık tema ve yarı saydam “blur” efektleri kullanıldı.
-
Akıllı Durdurma (AbortController & doFinally): Yapay zeka cevap üretirken (SSE Streaming) kullanıcı “Durdur” butonuna basarsa, Next.js bağlantıyı anında keserek GPU’yu rahatlatır. Spring Boot ise bu ağ kesintisini yakalayarak (WebFlux
doFinally), o ana kadar üretilen yarım cevabı ziyan etmeden anında veritabanındaki sohbet geçmişine kaydeder. -
Canlı Bildirimler (Toast): Arka planda PostgreSQL’den gelen CDC güncellemeleri tamamlandığında, yönetici panelinde anında yeşil bir “Canlı Veri Algılandı” bildirimi gösterilir.
-
Responsive Tasarım: Mobil, tablet ve masaüstü uyumlu, akıcı (Fluid) bir kullanıcı deneyimi sağlandı.
7. Sonuç
Enterprise AI projesi, kurumsal şirketlerin “Veri Gizliliği” endişesi duymadan yapay zekayı kendi iç sistemlerine nasıl güvenle entegre edebileceklerinin canlı bir kanıtıdır.
-
Veriler şirketin yerel ağından (Localhost / Intranet) dışarı çıkmaz (Ollama).
-
Kullanıcılar sadece yetkileri olan departmanın verisiyle konuşur (JWT tabanlı RBAC).
-
Yapay zeka, ERP/CRM sistemlerindeki değişiklikleri sıfır gecikmeyle (Native CDC) saniyeler içinde öğrenir ve yanıtlar.
Özetle; Spring Boot, Next.js ve PostgreSQL üçgeninde geliştirilen bu modern mimari, geleneksel yazılım çözümleri ile geleceğin yapay zeka teknolojileri arasında köprü kuran, ölçeklenebilir ve güvenilir bir kurumsal temel (Enterprise Foundation) sunmaktadır.