- Şirket içi yapay zeka asistanı, kendi dökümanınızla beslenen ve hassas veriyi dışarı sızdırmayan özel bir LLM uygulamasıdır.
- İki ana mimari vardır: bulut API (OpenAI, Anthropic) ve on-premise (Llama 3, Mistral). KVKK kapsamındaki kişisel veri için karma model en güvenli yoldur.
- Çekirdek bileşen RAG'dir: dökümanlar embedding'e dönüştürülüp vektör DB'ye (pgvector, Qdrant) yazılır; LLM yalnızca getirilen pasajdan cevap üretir.
- PoC için 3–6 hafta, prod-ready dağıtım için 8–14 hafta tipik bir süreçtir. İlk yıl toplam maliyet bulut tarafında token-bazlı, on-premise tarafında GPU CAPEX odaklıdır.
- Başarı ROI'si "soru başına ortalama yanıt süresi", "self-service çözüm oranı" ve "çalışan başına haftalık kazanılan saat" üzerinden ölçülür.
Şirket İçi AI Asistanı Nedir, Neden Önemli?
Şirket içi yapay zeka asistanı, çalışanların günlük iş sorularını, prosedür bilgilerini veya veri sorgularını yönelteceği, kuruluşun kendi verileriyle beslenmiş bir LLM (Large Language Model) uygulamasıdır. "Hangi müşterinin sözleşmesi bu ay bitiyor?", "İzin başvurusu için hangi formu kullanmalıyım?", "Bu ürünün teknik özellikleri ve rakipten farkı ne?" gibi sorulara — şirket dökümanlarınızdan beslenen — atıflı yanıtlar üretir.
Genel ChatGPT veya Claude.ai gibi tüketici arayüzlerinden temel farkları şudur:
- Bağlam farkındalığı: Şirkete özel dokümanlara, prosedürlere, ürün verilerine ve geçmiş kararlara erişir.
- Yetkilendirme: Hangi çalışanın hangi bilgiye erişebileceği rol bazlı tanımlanır; finans departmanına özel veriler satış ekibine görünmez.
- Veri sınırı: Hassas veri eğitim setine düşmez. Anthropic ve OpenAI'ın kurumsal API sözleşmelerinde "API üzerinden gönderilen veriler model eğitiminde kullanılmaz" maddesi standarttır (kaynak: Anthropic Commercial Terms ve OpenAI Enterprise Privacy).
- İzlenebilirlik: Hangi soru, hangi kullanıcıdan geldi, hangi kaynak pasajla yanıt verildi — tüm zincir kayıt altına alınır.
McKinsey'in The State of AI raporuna göre 2024 itibarıyla katılımcı kuruluşların yaklaşık üçte ikisi en az bir iş fonksiyonunda generatif yapay zekayı düzenli olarak kullanmaya başlamıştı; en yaygın benimsenme alanı bilgi yönetimi ve müşteri operasyonlarıdır (kaynak: McKinsey, The State of AI). Bu eğilim, şirket içi asistanı "deneme" kategorisinden çıkarıp "rekabet zorunluluğu" kategorisine taşıyor.
Self-Hosted vs Bulut API: Hangi Senaryoda Hangisi?
İlk mimari kararınız: modeli kendi sunucunuzda mı koşturacaksınız (on-premise / self-hosted), yoksa OpenAI / Anthropic / Azure OpenAI gibi sağlayıcının API'sini mi kullanacaksınız? Bu karar; veri hassasiyeti, ekip yetkinliği, başlangıç bütçesi ve operasyonel yük arasındaki dengeyi belirler.
| Kriter | Bulut LLM API | On-Premise / Self-Hosted |
|---|---|---|
| Model kalitesi | En üst düzey (Claude 3.5 Sonnet, GPT-4o, o1) | İyi (Llama 3.1 70B, Mistral Large, Qwen 2.5) |
| Veri gizliliği | Sağlayıcıya gider (sözleşmeyle no-train garantili) | Veri ağ sınırını terk etmez |
| Başlangıç maliyeti | Düşük (token başı pay-as-you-go) | Yüksek (GPU sunucu / kira) |
| İşletim yükü | Düşük (sağlayıcı yönetir) | Yüksek (model güncellemesi, monitoring) |
| Latency | İnternet bağlantısına bağlı | İç ağ — düşük gecikme |
| Uygunluk denetimi (ISO, KVKK) | Sağlayıcı sertifikasına güven | Kendi denetim sınırınız içinde |
| İdeal kullanım | Orta hassasiyet, hızlı pazara çıkış | Hukuk, sağlık, finans, savunma — kritik veri |
Pratikte gördüğümüz en sağlıklı yol karma mimaridir: hassas olmayan içerik (ürün katalogları, genel prosedürler, eğitim materyalleri) bulut LLM ile, hassas içerik (müşteri sözleşmeleri, kişisel veri, finansal veriler) ise on-premise küçük modelle işlenir. Yönlendirme katmanı (router LLM) gelen sorgunun hangi sınıfa düştüğüne karar verir.
Self-hosted senaryoda en yaygın yığın: Ollama veya vLLM üzerinde Llama 3.1 8B/70B veya Mistral, FastAPI tabanlı orkestrasyon, Qdrant veya pgvector tabanlı vektör DB ve OAuth/OIDC ile entegre kimlik katmanı. Bulut tarafında ise tipik yığın: Anthropic Messages API veya OpenAI Responses API + LangChain/LangGraph orkestrasyonu + yönetilen vektör DB (Pinecone, Azure AI Search) + uygulama gateway'i.
RAG: Şirket Verinizin LLM'e Entegrasyonu
Retrieval-Augmented Generation (RAG), LLM'in eğitim verisinde olmayan şirket bilgisine erişmesinin en pratik ve güvenli yoludur. Modeli yeniden eğitmeden, sorgu anında doğru pasajları getirip prompt'a iliştiren bir mimaridir. Anthropic'in Contextual Retrieval ve OpenAI'ın retrieval kılavuzları bu yaklaşımı standartlaştırmış durumda.
Tipik RAG akışı şu adımlardan oluşur:
- Belge toplama: SharePoint, Google Drive, Confluence, dosya sunucusu, ticket sistemi, e-posta arşivi, ERP/CRM verileri — kaynakları envanterleyin ve hangisinin asistana girmesine izin verildiğini belirleyin.
- Parçalama (chunking): Belgeler 300–800 token arası anlamlı bölümlere ayrılır. Bölüm sınırı paragraf veya başlık bazlı olmalı; cümle ortasından kesmek bağlamı bozar.
- Embedding: Her parça, embedding modeliyle (OpenAI text-embedding-3-large, Cohere embed-multilingual-v3, BGE-m3) yüksek boyutlu vektöre dönüştürülür.
- Vektör DB indeksleme: Vektörler pgvector, Qdrant, Milvus veya Pinecone'a yazılır. Metadata olarak departman, gizlilik seviyesi, kaynak URL ve son güncellenme tarihi saklanır.
- Sorgu zamanı retrieval: Kullanıcı sorusu da embed edilir, en yakın N parça getirilir. Re-ranker (Cohere Rerank, BGE-reranker) ile sıralama düzeltilir.
- Generation: LLM yalnızca getirilen pasajlardan cevap üretir; "bilmiyorsan uydurma, bilmiyorum de" talimatı sistem prompt'una yerleştirilir.
- Atıf: Yanıt altında kaynak parçaların başlığı ve linki gösterilir; kullanıcı doğrulayabilir.
İleri seviye iyileştirmeler: Anthropic'in önerdiği contextual chunking (her parçanın başına o parçanın hangi belge ve bölüm içinde olduğunu özetleyen bir cümle eklenir) retrieval doğruluğunu %30–50 aralığında artırabiliyor. Hybrid search (BM25 + dense vector) ise sadece anlamsal aramaya kıyasla edge-case sorgularda daha tutarlı sonuç veriyor.
KVKK Uyumluluğu: Kişisel Veri ve LLM
Türkiye'de faaliyet gösteren şirketler için 6698 sayılı KVKK kapsamında işlenen kişisel verilerin LLM süreçlerine dahil edilmesi açık bir hukuki çerçeve gerektirir. Kişisel Verileri Koruma Kurumu'nun yapay zeka ile ilgili rehberleri (kaynak: KVKK resmî sitesi) aşağıdaki ilkeleri pratikte zorunlu hale getiriyor:
- Hukuki sebep: Asistanın işleyeceği kişisel veriler için 5/2'deki hukuki sebepler (açık rıza, sözleşmenin kurulması, meşru menfaat vb.) önceden tespit edilmeli.
- Aydınlatma: Çalışanın asistana yazdığı her mesaj kişisel veri olarak işlenebileceği için, aydınlatma metni güncellenmelidir.
- Veri minimizasyonu: Yalnızca amaç için gerekli olan veri RAG indeksine girer. TC kimlik, banka hesap, sağlık verisi gibi özel nitelikli veriler maskelenir veya tamamen dışarıda tutulur.
- Yurt dışına aktarım: Bulut LLM kullanımı 9. madde kapsamında yurt dışına veri aktarımı sayılabilir; standart sözleşme veya açık rıza dayanağı gerekli olabilir.
- Saklama süresi: Sohbet logları ve embedding'ler için saklama süresi belirlenmeli; süre sonunda silinmeli.
- VERBİS: İşleme faaliyeti varolan VERBİS kaydına eklenmeli veya güncellenmeli.
Pratik öneri: PII maskeleme katmanı RAG'den önce devreye alınır. Presidio (Microsoft), regex tabanlı TC/IBAN tespiti veya küçük bir LLM ile NER kombinasyonu kullanılabilir. Maskelenmiş veri vektör DB'ye yazılır; orijinal veri sadece yetki seviyesi yüksek kullanıcı için dinamik olarak çözülür.
Maliyet Hesabı: Token, Altyapı, Geliştirme
Toplam sahip olma maliyeti (TCO) üç ana kalemden oluşur: model kullanım maliyeti, altyapı maliyeti, geliştirme ve operasyon maliyeti.
1) Model kullanım maliyeti (bulut senaryosu). Bulut LLM'ler token başına ücretlendirir. Güncel listeler için sağlayıcıların kendi fiyatlandırma sayfalarına bakılmalı (Anthropic pricing, OpenAI pricing). Tipik bir kurum içi asistanda bir sorgu — sistem prompt + getirilen 4–6 pasaj + soru + yanıt — toplamda 4.000–8.000 token civarına oturur. Yüz kişilik bir ekipte kişi başı günde 5 sorgu varsayımıyla aylık token tüketimi kabaca 600 milyon–1.2 milyar arasında hesaplanır; bu hacim için "yüksek model" (Claude Sonnet, GPT-4o) yerine "küçük model" (Claude Haiku, GPT-4o-mini) ile retrieval kalitesine yatırım yapmak çoğu zaman daha ekonomiktir.
2) Altyapı maliyeti (self-hosted senaryosu). Llama 3.1 70B modelini akıcı koşturabilmek için tipik olarak 2× NVIDIA A100 80GB veya 1× H100 80GB sınıfı GPU gerekir. Kiralanması Hetzner / Lambda / RunPod gibi sağlayıcılarda aylık binlerce dolar bandındadır; satın alma yüksek beş haneli dolar yatırımıdır. Llama 3.1 8B modeli ise tek bir L40S veya hatta uygun kuantizasyonla RTX 4090 üzerinde verimli çalışabilir; KOBİ ölçeği için daha gerçekçi başlangıç noktasıdır.
3) Geliştirme ve operasyon. PoC için 3–6 hafta (1 ML mühendisi + 1 backend), MVP için 8–12 hafta (ek bir frontend + DevOps), prod-ready için sürekli iyileştirme ekibi gerekir. Operasyonel maliyetin görünmeyen kalemleri: prompt regression testleri, eval harness, monitoring (LangSmith, Langfuse, Arize), insan değerlendirme döngüsü.
Hangi Modeli Seçmeli? (Llama 3, Mistral, Claude, GPT-4o)
2026 itibarıyla kurum içi asistan için en sık değerlendirilen model aileleri ve karakteristikleri:
- Anthropic Claude 3.5 / 3.7 Sonnet: Uzun bağlam (200K token), Türkçe dahil çok dilde güçlü ve tool-calling kararlılığı yüksek. Hukuki ve teknik metin yoğun süreçlerde retrieval cevaplarını sade ve atıflı tutması avantaj.
- OpenAI GPT-4o / GPT-4o-mini: Multimodal (görsel + ses + metin), geniş ekosistem desteği. Mini varyantı yüksek hacimli ucuz sorgular için ideal başlangıç.
- Meta Llama 3.1 (8B / 70B / 405B): Açık ağırlıklı; tamamen on-premise koşturulabilir. Türkçe performansı 8B varyantında orta, 70B'de güçlü. Lisansı ticari kullanıma açık (kaynak: Llama 3 license).
- Mistral Large / Mixtral: Avrupa kökenli, GDPR/KVKK uyum söylemine yatırım yapmış. Mixtral MoE mimarisi belleğe daha kibar.
- Alibaba Qwen 2.5 / DeepSeek: Açık ağırlıklı, kod ve mantık görevlerinde iddialı. Veri rezidans kısıtı olan kurumlar için on-premise alternatif.
Seçim kriteri özetle: "Yüksek hassasiyetli veri + denetim baskısı" ise on-premise Llama 3.1 70B veya Mistral; "hız, kalite, düşük operasyon yükü" ise Claude Sonnet veya GPT-4o; "yüksek hacim, makul kalite" ise Claude Haiku veya GPT-4o-mini. Tek modele kilitlenmek yerine LiteLLM, OpenRouter veya kendi gateway'inizle provider-agnostic bir mimari kurmak gelecekteki fiyat/performans değişimlerine karşı kuruluşunuzu korur.
Kurum İçi Asistan vs Müşteri Chatbot'u
İki kullanım alanı dışarıdan benzer görünse de mimari ve risk profili farklıdır.
| Boyut | Kurum İçi Asistan | Müşteri Chatbot'u |
|---|---|---|
| Kullanıcı | Çalışan (güven sınırı içi) | Anonim/yarı-anonim müşteri |
| Hata toleransı | Orta — çalışan doğrulayabilir | Düşük — marka hasarı riski |
| Bilgi yelpazesi | Geniş, departman bazlı | Dar — ürün/destek odaklı |
| Prompt injection riski | Düşük | Yüksek — dışarıya açık |
| Tipik LLM seçimi | Orta–büyük model | Küçük model + sıkı guardrail |
| İnsan devri (handoff) | İhtiyari | Zorunlu — canlı destek köprüsü |
Müşteri chatbot'unda guardrail, kişiselleştirme ve marka tonu daha kritik; kurum içi asistanda ise yetkilendirme, audit log ve bilgi tabanı yönetimi öne çıkar.
Uygulama Adımları: PoC → MVP → Prod
- Faz 0 — Hedef ve metrik tanımı (1 hafta): "Hangi soru sınıfını çözüyoruz?", "Bugün bu sorulara yanıt süresi nedir?", "Başarı eşiğimiz nedir?" sorularına yazılı cevap.
- Faz 1 — PoC (3–4 hafta): Sınırlı bir bilgi tabanı (örn. 200 doküman) ve 50 örnek soruyla retrieval + generation prototipi. Eval seti hazırlanır; insan değerlendirici accuracy/relevance/groundedness puanlar.
- Faz 2 — MVP (6–10 hafta): Yetkilendirme, audit log, UI (web + Slack/Teams), PII maskeleme, monitoring devreye girer. 5–10 pilot kullanıcıyla canlı.
- Faz 3 — Prod ölçeklendirme (8–12 hafta): Tüm hedef kullanıcı kitlesine açılma, caching, rate limit, fallback model, maliyet alarmları, sürekli iyileştirme döngüsü.
- Faz 4 — Sürekli iyileştirme: Kötü yanıtlanan soruların haftalık triyajı, eksik dökümanların eklenmesi, prompt regresyon testleri, model güncellemelerine karşı A/B kıyas.
Anti-pattern uyarısı: PoC'yi tüm dökümanlarla aynı anda kurmaya çalışmak. Küçük, temiz ve etiketlenmiş bir başlangıç seti yüksek dökümana göre çok daha hızlı sinyal verir.
Başarı Metrikleri ve ROI Ölçümü
- Yanıt doğruluğu (accuracy): İnsan değerlendirici ile haftalık örneklem değerlendirmesi. Hedef bandı genelde %85+.
- Kaynak temelinde olma (groundedness): Yanıtların atıflarla desteklenme oranı; "hallucination" izleme metriği.
- Self-service çözüm oranı: İnsan devrine gitmeden çözülen sorgu yüzdesi.
- Yanıt süresi: p50 ve p95 latency — kullanıcı deneyimi için kritik.
- Çalışan başına kazanılan saat: Asistan öncesi/sonrası ortalama sorgu çözüm süresinin farkından çalışan başına aylık saat kazancı.
- Sorgu başına maliyet: Token + altyapı + amortize edilmiş geliştirme maliyetinin toplam sorguya bölünmesi.
- NPS / iç memnuniyet anketi: Kullanıcıların asistana güveni ve tavsiye edebilirliği.
Gartner'ın AI hype cycle yayınları, başarılı kurumsal AI projelerinin tek bir vanity metric ("kullanım sayısı") yerine bağlanmış business KPI'lar üzerinden raporlandığını vurguluyor (kaynak: Gartner Hype Cycle 2024). Asistanı destek ticket sayısı, satış çağrı hazırlık süresi, onboarding süresi gibi mevcut süreç KPI'larına bağlamadan ROI hikâyesi kurmak zordur.
Nexsol Vakası: Üretim KOBİ'sinde RAG Asistanı
İzmir'de faaliyet gösteren bir üretim KOBİ'si için kurguladığımız asistan projesi, sektör dinamiklerini anlamak adına iyi bir referanstır. Müşteri talebi: satış öncesi teknik sorulara hızlı cevap (ürün spec, sertifikalar, geçmiş teklif bilgisi). Kapsam: yaklaşık 1.800 PDF (teknik föy, sertifika, müşteri yazışmaları), 12.000 satır CRM kaydı.
Mimari: Anthropic Claude Haiku (jeneratif katman) + Cohere embed-multilingual-v3 (embedding) + pgvector üzerinde Postgres (vektör DB) + FastAPI orkestrasyon + iç Slack kanalında bot arayüzü. PII maskeleme regex + Presidio karması. Audit log Postgres tarafında 12 ay saklama politikasıyla.
İlk 6 haftalık ölçümde gözlemlenen kalitatif sonuçlar:
- Satış mühendislerinin "müşteriye geri dönüş için doküman arama" süresinde belirgin azalma (özellikle sertifika ve geçmiş yazışma sorgularında).
- Yeni başlayan satış temsilcisinin ürün bilgisinde yetkinleşme süresinde belirgin kısalma — onboarding rehberi olarak kullanıldı.
- Yanlış yanıt vakalarının haftalık triyajı sayesinde bilgi tabanındaki eski/çakışan dökümanlar tespit edildi; sonuçta dokümantasyon hijyeni de iyileşti.
Önemli not: bu vakada somut rakamsal getiri figürü, müşteri gizliliği nedeniyle paylaşılmıyor; verilen sinyaller kalitatif ve sürece dayalıdır. Kendi kurumunuz için ROI tahmini, mevcut süreç sürelerinizi ölçmeden yapılamaz.
Nexsol ile Şirket İçi AI Asistanı
Nexsol Teknoloji olarak şirket içi yapay zeka asistanı projelerini ihtiyaç profiline göre hem bulut hem on-premise mimaride kuruyoruz. Süreç: keşif görüşmesi → veri envanteri ve risk değerlendirmesi → mimari seçim → RAG pipeline kurulumu → eval harness → UI ve entegrasyon → pilot → ölçeklendirme. LLM danışmanlığı, yapay zeka çözümleri ve ücretsiz proje analizi sayfalarımızdan başlayabilirsiniz. Konuyla yakın okumalar: ChatGPT API entegrasyonu rehberi ve AI ajan tasarımı.
Kaynaklar
- Anthropic — Contextual Retrieval
- OpenAI — Retrieval Guide · Enterprise Privacy
- Meta — Llama 3 Community License
- McKinsey — The State of AI
- Gartner — Hype Cycle for Emerging Technologies 2024
- KVKK — Kişisel Verileri Koruma Kurumu
