Dahili bir yapay zeka asistanı kurmak, popüler bir chatbot arayüzü eklemekten çok daha kapsamlı bir karardır. Hangi iş süreçlerinin otomasyona uygun olduğunu belirlemek, kurumsal verileri modele erişilebilir hale getirmek, gizlilik sınırlarını çizmek ve sistemi canlı ortamda sürdürülebilir kılmak arasında onlarca kritik tercih sizi bekler. Bu yazıda, bir şirketin kendi iç kullanıma yönelik bir AI asistanını sıfırdan nasıl planlayacağını, hangi aşamalarda hangi kararları alacağını ve yaygın hatalardan nasıl kaçınacağını adım adım ele alıyoruz. Model seçiminden veri mimarisine, güvenlik politikalarından izleme altyapısına kadar her aşamada somut örnekler ve pratik karar kuralları bulacaksınız.
1. Doğru Kullanım Alanlarını Seçmek: Her Süreç AI Asistanına Uygun Değil
AI asistanı projesinin en sık yapılan hatası, "her şeyi yapsın" beklentisiyle yola çıkmaktır. Oysa başarılı kurumsal uygulamalar, dar ve ölçülebilir bir kullanım alanıyla başlar. İnsan kaynakları politika sorgulama, BT destek biletlerinin ilk yönlendirmesi, satış ekibinin ürün bilgisi erişimi veya finans departmanının raporlama şablonu üretimi gibi alanlar, yüksek tekrar oranı ve net çıktı beklentisi sayesinde ilk adımda idealdir.
Uzman bakışı: Bir sürecin AI asistanına uygun olup olmadığını test etmenin pratik yolu şudur: O süreçteki soruların yüzde 70'inden fazlası halihazırda belgelenmiş bir bilgiye dayanıyorsa, bu süreç güçlü bir adaydır. Örneğin, IT helpdesk ekibinin aldığı soruların büyük çoğunluğu "şifre sıfırlama", "VPN kurulumu" ve "yazıcı bağlantısı" gibi tekrarlayan konulardaysa, bir asistan bu yükün önemli kısmını üstlenebilir.
Karar kuralı: İlk pilot için tek bir departman, tek bir soru tipi ve net bir başarı metriği belirleyin. "Destek biletlerinin yüzde 30'unu otomatik yanıtlamak" gibi somut bir hedef, "müşteri deneyimini iyileştirmek" gibi genel bir ifadeden çok daha işlevsel bir pusula görevi görür.
2. Kurumsal Bilgi Tabanını Yapılandırmak: Model Değil, Veri Kazanır
Bir AI asistanının kalitesi, erişebildiği bilginin kalitesiyle doğrudan orantılıdır. Çoğu şirkette kurumsal bilgi; SharePoint klasörleri, Confluence sayfaları, PDF politika dokümanları, Slack konuşmaları ve e-posta dizileri arasında dağınık haldedir. Bu verileri sisteme beslemeden önce temizlenmesi, parçalanması (chunking) ve indekslenmesi gerekir. Retrieval-Augmented Generation (RAG) mimarisi burada devreye girir: model, kendi genel bilgisi yerine şirketin özel dokümanlarından çekilen bağlamlı bilgiyle yanıt üretir.
Uzman bakışı: En sık karşılaşılan tuzak, "tüm dokümanları sisteme yükleyelim" yaklaşımıdır. Eski, çelişkili veya güncelliğini yitirmiş belgeler asistanın güvenilirliğini düşürür. Örneğin, 2021 tarihli bir yan haklar politikası ile 2024 güncellemesi aynı indekste yer alırsa, model hangisinin geçerli olduğunu bilemez ve tutarsız yanıtlar üretir.
Karar kuralı: Her doküman seti için bir "sorumlu editör" atayın ve belgelerin son güncelleme tarihini metadata olarak ekleyin. RAG sisteminde en güncel kaynaklara öncelik veren bir filtreleme katmanı kullanın. Ayrıca chunk boyutunu 300–500 token aralığında tutarak bağlam kaybını minimize edin.
3. Model Seçimi ve İnce Ayar: Her İhtiyaç İçin Farklı Bir Yol Haritası
Hangi dil modelini kullanacağınız, veri gizliliği gereksinimleriniz, bütçeniz ve kullanım senaryonuzla doğrudan ilgilidir. Üç ana yol vardır: büyük bulut tabanlı API'ler (GPT-4, Claude, Gemini), açık kaynaklı modeller (Llama, Mistral, Qwen) ve ince ayar (fine-tuning) uygulanmış özel modeller. Çoğu şirket için RAG destekli bir açık kaynak modeli, maliyet-gizlilik dengesi açısından en pragmatik başlangıç noktasıdır.
Uzman bakışı: Fine-tuning, her durumda gerekli değildir ve yanlış uygulandığında modelin genel yeteneklerini bozabilir. Eğer asistanınız belirli bir terminolojiyle çalışıyorsa (örneğin hukuk veya tıp), ince ayar anlamlıdır. Ancak çoğunlukla iyi yapılandırılmış bir RAG sistemi, fine-tuning olmadan da yüksek kalite sağlar. Küçük bir senaryo: bir e-ticaret şirketinin müşteri destek asistanı, ürün iade politikasını RAG ile %92 doğrulukla yanıtlarken, fine-tuning uygulandığında bu oran yalnızca %94'e çıktı — ancak bakım maliyeti üç katına çıktı.
Karar kuralı: Önce RAG ile başlayın. Yanıt kalitesi belirli bir alanda %85'in altında kalırsa ve bu alan yüksek hacimliyse, o spesifik alan için ince ayar düşünün. Model boyutu seçerken gecikme süresi (latency) ve token maliyeti karşılaştırması yapmadan karar vermeyin.
4. Güvenlik, Gizlilik ve Uyumluluk: Görünmeyen Riskler En Pahalı Olanlardır
Dahili bir asistan, şirketin hassas verilerine doğrudan temas eder. Maaş bilgileri, müşteri sözleşmeleri, strateji notları, kişisel veriler — tüm bu içerikler modele bağlam olarak sunulabilir. Bu noktada veri sızıntısı riski, uyumluluk yükümlülükleri (KVKK, GDPR) ve erişim kontrolü mekanizmaları projenin en kritik bileşenlerini oluşturur.
Uzman bakışı: Birçok ekip, asistanın "sadece dahili kullanımda" olduğunu varsayarak güvenlik katmanlarını sonraya bırakır. Oysa en tehlikeli senaryo tam da budur: satış temsilcisi asistana "Bu müşterinin sözleşme detaylarını özetle" dediğinde, model aynı veritabanına erişimi olan başka bir departmanın çalışanına da aynı bilgiyi sunabilir. Rol tabanlı erişim kontrolü (RBAC) RAG katmanında uygulanmadığında, asistan bir veri sızıntı aracına dönüşür.
Karar kuralı: Her doküman parçasına erişim etiketi (access tag) ekleyin ve RAG sorgusu sırasında kullanıcının rolüyle eşleştirin. Model çıktılarını kayıt altına alın (logging) ancak bu kayıtları şifreleyin ve erişimi sınırlandırın. Pilot aşamada bir güvenlik denetimi (security review) yapmadan canlıya çıkmayın.
5. Dağıtım, İzleme ve Sürekli İyileştirme Döngüsü
Asistanı geliştirmek projenin yalnızca yarısıdır; diğer yarısı onu canlı ortamda tutarlı ve güvenilir kılmaktır. Dağıtım aşamasında yanıt doğruluğu, kullanıcı memnuniyeti, yanıt süresi ve kullanım oranı gibi metriklerin sürekli izlenmesi gerekir. Ayrıca kullanıcıların asistanla nasıl etkileşime girdiğini analiz etmek, beklenmedik kullanım kalıplarını ve sistemin zayıf noktalarını ortaya çıkarır.
Uzman bakışı: İlk haftalarda kullanıcılar asistanı "test etmek" için sorular sorar; bu yanıtlar genel kaliteyi yansıtmaz. Gerçek sinyal, ikinci ve üçüncü haftadan itibaren gelir: kullanıcılar aynı soruyu tekrar tekrar soruyorsa veya "bunu bilmiyorum" yanıtını çok alıyorsa, bilgi tabanında bir boşluk vardır. Örneğin, bir üretim şirketinin iç asistanı "vardiya değişim prosedürü" sorularına %60 oranında "bilgi bulunamadı" yanıtı veriyordu — çünkü prosedür dokümanı PDF olarak yüklenmiş ancak OCR hataları nedeniyle düzgün indekslenmemişti.
Karar kuralı: Haftalık bir "yanıt kalitesi raporu" oluşturun. Kullanıcı geri bildirimi (thumbs up/down) toplayın ve olumsuz yanıtları kategorize edin. Her sprint döngüsünde en az bir bilgi boşluğunu kapatın ve en az bir yanlış yanıtı düzeltin. Asistanınız statik bir ürün değil, sürekli gelişen bir sistemdir.
Sonuç
Şirket içi bir AI asistanı kurmak, teknoloji seçiminden çok bir organizasyon dönüşümü projesidir. Doğru kullanım alanını seçmek, bilgi tabanını temiz ve güncel tutmak, model stratejisini ihtiyaca göre belirlemek, güvenlik katmanlarını baştan inşa etmek ve canlı ortamda sürekli izleme yapmak — bu beş bileşenden herhangi biri ihmal edildiğinde proje ya rafa kalkar ya da güven kaybeder. Küçük başlayın, ölçün, düzeltin ve ölçekleyin. Bir asistanın değeri, ilk demosunda değil, üçüncü ayında kullanıcıların onsuz çalışamadığı noktada ortaya çıkar.