ML Ekibi Olmadan: Kendi Sunucularınızdaki Destek Talepleri ve Belgeler için LLM Sistemini Devreye Alındıktan Sonra Kim İşletir

Kendi sunucularınızda destek taleplerini sınıflandıran ve belgeleri okuyan bir LLM sisteminin, devreye alındıktan sonra da onu işletecek birine ihtiyacı vardır. LLM, büyük dil modeli (large language model) demektir; ChatGPT'nin arkasındaki yapay zekâ türüdür. Makine öğrenmesi (ML) ekibi olmayan bir şirketin üç yolu vardır. Sistemi geliştiren firma, bir destek sözleşmesi kapsamında onu işletmeye devam edebilir. Bunun yerine bir devir tesliminin ardından BT ekibiniz sistemi devralabilir ya da işi firmayla paylaşabilir. Hangi yol seçilirse seçilsin, birinin yanıt kalitesini düzenli aralıklarla kontrol etmesi ve her model değişikliğini canlıya geçmeden önce onaylaması gerekir.

Bir LLM sistemini devreye aldıktan sonra işletmek neleri kapsar?

Devreye alındıktan sonra bir LLM sistemini işletmek, düzenli olarak tekrarlanan şu görevlerden oluşur:

• Çoğu zaman GPU'lar (dil modellerinin üzerinde çalıştığı çipler) barındıran sunucular ve modeli çalıştıran yazılımın güncellemeleri
• Kullanılan model sürümü ve bu sürümün ne zaman değiştirileceği kararı
• Yanıtların, kendi destek taleplerinizden ve belgelerinizden oluşan sabit bir örneklem üzerinde düzenli aralıklarla puanlanması
• İnceleme kuyruğu, yani yazılımın bir kişiye aktardığı kayıtlar ve bu kuyruğu ele alan personel
• Sizin tarafınızdaki değişiklikler: yeni bir form, destek talebi kategorisi ya da iş kuralı gibi
• Sistemin ne yaptığını kaydeden loglar ve destek taleplerine ve belgelere erişim yetkileri
• Gece yaşanan arızalar ve aranan kişi

vLLM, modelleri kendi sunucularınızda çalıştırmaya yarayan açık kaynaklı programlardan biridir. 20 Ekim 2026'da okunan GitHub güvenlik sayfası, 0.31.0 sürümünde giderilen bir açıkla ilgili 6 Ekim 2026 tarihli bir güvenlik bildirimini listeliyor. Bildirimin başlığı şöyle: “Tek bir istekteki aşırı büyük bir min_tokens değeri, /health yeşil kalırken vLLM motorunu kilitliyor”. Bu başlıkta min_tokens, yanıtın en az uzunluğunu belirleyen bir istek ayarıdır.

Bir izleme aracı, bir sunucunun ayakta olduğunu görmek için /health gibi bir adresi kontrol eder. vLLM bildiriminde anlatılan durumda sunucu, isteklere yanıt vermeyi bırakmışken sağlıklı görünür. Bir LLM sistemi için izleme, gerçek test istekleri göndermeli ve yanıtların geri geldiğini kontrol etmelidir.

Kendi sistemimizin, yapay zekâ yerleşik bir helpdesk aracından farkı nedir?

Hizmet olarak yazılım (SaaS), yani internet üzerinden kiraladığınız bir araç olarak satılan bir helpdesk aracında hizmeti tedarikçi işletir; model de tedarikçinin ya da birlikte çalıştığı şirketlerin sunucularında çalışır. Destek talepleriniz tedarikçiye ve bu şirketlere gider. Yapay zekâ destekli belge işleme yazılımı ile özel bir LLM pipeline'ı arasındaki seçimi anlatan yazı, böyle bir araçla kendi sisteminiz arasındaki tercihi de ele alıyor.

Bir helpdesk tedarikçisi olan Zendesk, aynı gün okunan üretken yapay zekâ sayfasında “Zendesk'in LLM'leri Hizmetlere iki şekilde entegre ettiğini” söylüyor. Bunlardan biri “AWS Bedrock, Microsoft Azure, Groq veya Fireworks AI gibi” platformlarda barındırılan modelleri kullanıyor ve Zendesk bu durumda “LLM sağlayıcısının Hizmet Verilerinize asla erişmediğini” söylüyor. Diğeri, OpenAI ve Google Gemini gibi “doğrudan model sağlayıcısı tarafından barındırılan” modelleri kullanıyor. Zendesk bunlar için modele gönderilen metnin ve modelin yanıtlarının “hiçbir loglama mekanizmasında kalıcı olarak saklanmadığını” söylüyor.

Bir başka helpdesk tedarikçisi olan Intercom, kendi adına veri işleyen şirketlerin, yani alt veri işleyenlerinin listesini yayımlıyor. 25 Haziran 2026'dan itibaren geçerli olan ve aynı gün okunan liste, “yapay zekâ işleme” için başkalarının yanı sıra OpenAI, Anthropic, Google ve Microsoft'u sayıyor. Sayfa, listelerin “Intercom tarafından zaman zaman güncellenebileceğini” söylüyor.

LLM sistemimizi geliştiren firma onu işletmeye devam edebilir mi?

Sistemi geliştiren firma bir destek sözleşmesi, yani sistemi devreye alındıktan sonra da çalışır durumda tutmayı üstlendiği bir sözleşme önerebilir. Sözleşmenin şu konularda ne dediğini kontrol edin:

• Sistemin durması ya da bir alanın birçok belgede yanlış okunması gibi neyin olay sayılacağı ve her olay türüne ne kadar hızlı yanıt verileceği
• Sunucularınıza kimin, hangi hesaplar üzerinden giriş yapabileceği ve bu erişimin nasıl kaydedileceği
• Sunucuların bedelini kimin ödeyeceği ve daha fazla kapasite gerektiğine kimin karar vereceği
• Yeni bir belge türü ya da destek talebi kategorisi eklemek gibi bir değişiklik talebinin ne olduğu ve nasıl fiyatlandırılacağı
• Kalite puanları, inceleme kuyruğu hacimleri ve olaylar gibi her ay hangi raporları alacağınız

Sistemin sorumluluğunu firmaya bırakmak, çalışanlarınızdan en az şeyi ister. Bu durumda iş bilgisi firmada kalır ve şirketiniz çoğu değişiklik için firmaya bağımlı olur. Firma ayrıldığında neyin sahibi olmanız gerektiği, bir COO'nun imzalamadan önce sorması gereken sorular üzerine yazıda ele alınıyor.

BT ekibimizin ML deneyimi yok. Sistemi devralabilir mi?

Şirketinizin sunucularını zaten işleten bir BT ekibi, LLM sisteminin sunucularını, erişim yetkilerini, yedeklemelerini ve izlemesini genellikle kendi işine ekleyebilir. Kalite puanlarını yorumlamak ve yeni bir model sürümünü test etmek gibi dil modellerine özgü görevler ise önce eğitim gerektirir.

Devir teslim için BT ekibinin runbook'lara, yani günlük görevler ve inceleme kuyruğunun dolması gibi bilinen her arıza için adım adım rehberlere ihtiyacı vardır. Ekibin ayrıca destek taleplerinizden ve belgelerinizden oluşan, doğru yanıtlarıyla birlikte test örneklemine ve sistemi bu örnekleme göre puanlayan betiğe ihtiyacı vardır. Kod ve model dosyaları, şirketinizin kontrol ettiği depolama alanında durmalıdır.

Sistemin, değişikliklerin gerçek destek taleplerine ulaşmadan önce denendiği bir kopyası olan test ortamı, devreye almadan önce hazır olmalıdır. Eğitim orada yapılabilir: ekibiniz rutin görevleri kopya üzerinde yapar, firmanın mühendisleri de işi kontrol eder.

Prompt ve kural değişikliklerinin bir sahibi olmalıdır. Prompt, modele ne yapacağını söyleyen metindir. Bir form değiştiğinde ya da yeni bir destek talebi kategorisi ortaya çıktığında birinin prompt'u ya da kuralları güncellemesi ve test örneklemini yeniden puanlaması gerekir. Bu kişinin BT'de mi, firmada mı, yoksa destek gibi sürecin sahibi olan ekipte mi olacağına karar verin.

BT ekibimiz ile firma arasında bir iş bölümü nasıl işler?

İş bölümünde sunucular ve erişim BT ekibinizde kalır; model değişiklikleri ve kalite sorunları için firma devreye çağrılır.

İş bölümü bir boşluk bırakabilir. Kalite düştüğünde BT modeli suçlarken firma sunucuları suçlayabilir; bu yüzden sözleşme kimin neye karar vereceğini yazılı olarak belirtmelidir.

Örneğin firma her yeni model sürümünü test örneklemi üzerinde puanladıktan sonra o sürümü şirketiniz onaylar. Bir kalite sorununu gidermek firmanın işidir; sunuculara erişim ise BT ekibinizin kararı olarak kalır. Gece bir uyarı geldiğinde ilk kimin bakacağını ve bu kişinin diğer tarafa nasıl ulaşacağını da belirleyin.

Yanıt kalitesi devreye almanın ardından neden bazen düşer?

Doğruluk kayabilir; yani hiçbir hata mesajı vermeden yavaş yavaş değişebilir. Bir ürün lansmanının ardından gelen yeni destek talebi konuları, değişen bir form ya da yeni bir model sürümü tek başına bu kaymaya yol açabilir. Sunucular eskisi gibi çalışmaya devam eder; bu yüzden sunucu izleme düşüşü göstermez.

Kayma, destek taleplerinizden ve belgelerinizden oluşan, doğru yanıtları belli aynı örneklem yeniden puanlandığında ortaya çıkar. Bu, düzenli aralıklarla, örneğin ayda bir ve modelde, prompt'ta ya da kurallarda yapılan her değişiklikten sonra yapılmalıdır. Her puanı devreye alma sırasında kaydedilen puanla karşılaştırın.

Takılıp kalan bir yapay zekâ pilotu ve bir COO'nun soruları üzerine yazılar, test örnekleminin nasıl oluşturulacağını anlatıyor. Hangi yolu seçerseniz seçin, sözleşme yeniden puanlamayı yürütecek kişiyi belirtmeli ve sonuçları kimin göreceğini söylemelidir.

Modelin ne zaman değişeceğine kim karar verir?

Kendi sunucularınızda açık ağırlıklı bir model kullanıyorsanız, ne zaman geçiş yapılacağına şirketiniz karar verir. Açık ağırlıklı model, geliştiricisinin model dosyalarını herkes kendi lisansı altında indirip çalıştırabilsin diye yayımladığı modeldir. Lisans yine geçerlidir ve daha yeni bir sürüm farklı bir lisansla gelebilir.

Google'ın Gemma modelleri bunun bir örneğidir. Hugging Face model sitesindeki, aynı gün okunan Gemma 3 sayfası, bir Yasaklı Kullanım Politikası'nı (Prohibited Use Policy) da kapsayan Gemma Kullanım Koşulları'na (Gemma Terms of Use) yönlendiriyor. Google'ın açık kaynak blogu 2 Nisan 2026'da “Gemma 4 modellerinin, Gemmaverse'te OSI onaylı Apache 2.0 lisansıyla yayımlanan ilk modeller olduğunu” söyledi. Bu yüzden Gemma 3'ten Gemma 4'e geçiş, avukatlarınızın okuduğu lisansı da Google'ın kendi koşullarından açık kaynaklı bir lisans olan Apache 2.0'a değiştirir.

Kendi sunucularınızdaki bir sistem yine de barındırılan bir API, yani başka bir şirketin sunucularına internet üzerinden kurulan bir bağlantı aracılığıyla bir modeli çağırıyor olabilir. Bu model, o şirketin takvimine göre kullanımdan kaldırılır. Anthropic'in aynı gün okunan model kullanımdan kaldırma (model deprecations) sayfası şöyle diyor: “Kullanımdan kaldırma tarihini geçmiş modellere yapılan istekler başarısız olur.” Anthropic, aktif dağıtımları olan müşterilere “herkese açık olarak yayımlanan modeller için, model kullanımdan kaldırılmadan en az 60 gün önce bildirim” verdiğini söylüyor. Sayfa, tarihlerinin Anthropic'in kendi platformları için geçerli olduğunu, Amazon Bedrock ve Google Cloud'un ise “kendi kullanımdan kaldırma takvimlerini belirlediğini” ekliyor.

Her geçiş, yeni sürümün canlıya geçmeden önce örnekleminiz üzerinde puanlanması ve puanlar düşerse diye eski sürümün hazır tutulması demektir. Anthropic'in sayfası “uygulamalarınızın yeni modellerle, kullanımdan kaldırma tarihinden çok önce kapsamlı biçimde test edilmesini” öneriyor.

Bir destek talebi sistemi kandırabilir mi?

Prompt injection, sisteme gönderilen metnin modele yönelik talimatlar taşıdığı bir saldırıdır. Destek talepleri şirketinizin dışından gelir; bu yüzden onları okuyan bir sistem çalıştığı sürece bu saldırıya açık kalır. OWASP güvenlik projesinin yayımladığı ve aynı gün okunan bir risk listesi olan OWASP Top 10 for LLM Applications 2025, prompt injection'ı ilk sıraya koyar. Örneklerden biri şöyle: “Bir saldırgan bir müşteri destek sohbet botuna bir prompt enjekte ederek ona önceki yönergeleri yok saymasını, özel veri depolarını sorgulamasını ve e-posta göndermesini söyler; bu da yetkisiz erişime ve yetki yükseltmeye yol açar.”

Sisteme görevinin gerektirdiğinden fazla erişim vermemek gibi prompt injection'a karşı tasarım kuralları, takılıp kalan pilot yazısında yer alıyor. OWASP ayrıca sistem çalışırken tekrarlanacak bir önlemi de sayar: “Modeli güvenilmeyen bir kullanıcı gibi ele alarak düzenli sızma testleri ve ihlal simülasyonları yapın”. Sızma testi, test uzmanlarının sizin izninizle bilerek sisteme girmeye çalışması demektir.

Sızma testleri işletme görevleri takviminde yer almalıdır; sözleşme de bunları hangi tarafın yaptıracağını ve bulunanları kimin düzelteceğini belirtmelidir. Loglar destek taleplerinin tam metnini tutabilir; bu yüzden onları kimin okuyabileceğine ve ne kadar süre saklanacaklarına karar verin.

Sistemi işletmenin aylık maliyeti ne olacak ve imzalamadan önce neler sormalıyız?

Kendi sunucularınızda aylık maliyetler, satın alınan ya da kiralanan sunucular ve GPU'larıyla, inceleme kuyruğunda harcanan personel zamanıyla başlar. Firma bir rol üstlenmeye devam ediyorsa bunlara bir destek sözleşmesi, her değişiklikten sonraki yeniden testler de eklenir. Burada rakam verilmiyor, çünkü her biri hacimlerinize ve kurulumunuza bağlıdır.

Maliyetlerin dağılımı seçtiğiniz yola bağlıdır. Sistemi firma işletiyorsa maliyetin büyük kısmı destek sözleşmesindedir. Devir tesliminden sonra ise maliyetin daha büyük kısmı, eğitim de dahil olmak üzere kendi çalışanlarınızın zamanıdır.

Sistemi geliştirmeyi ve işletmeyi teklif eden her firmaya aynı soruları yöneltin:

• Devreye almanın ardından hangi işletme görevlerini siz üstleneceksiniz, hangilerini BT ekibimiz yapacak?
• Sistemi test örneklemimiz üzerinde ne sıklıkla puanlayacaksınız?
• Kullandığımız bir model sürümü kullanımdan kaldırıldığında yeniden testlerin bedelini kim öder?
• Devir teslimde BT ekibimiz neler alacak ve ekibin sistemi tek başına işletebildiğini nasıl kontrol edeceksiniz?

Lisans koşulları modelden modele, veri koruma kuralları ise ülkeden ülkeye değişir. Bu yazı hukuki tavsiye değildir; bu yüzden size uygulanan koşulları bir avukatla kontrol edin.

amBrain nerede devreye girer?

amBrain'in kamuya açık olarak anlattığı tek dil modeli projesi şu: “Bir müşterinin FinTech perimetresi içinde bir LLM entegrasyonunu üretime aldık: yapılandırılmamış broker ve işlem yeri bildirimlerinin — kurumsal işlemler (corporate actions), enstrüman ve teminat değişiklikleri — çıkarılıp normalize edilerek trading sisteminin tükettiği yapılandırılmış kayıtlara dönüştürülmesi.”

Bu yazı bir vaka çalışması değildir ve hiçbir müşteri çalışmasını anlatmaz. Alıntılanan satır, o sistemi bugün kimin işlettiğini, modelinin nerede çalıştığını ya da bu yazıdaki adımlardan hangilerini içerdiğini söylemez. Bu yazıdaki destek talepleri, belgeler ve işletme yolları genel örneklerdir; o projeden ya da amBrain'in başka herhangi bir çalışmasından alınmamıştır.

Burada adı geçen tedarikçiler, model geliştiricileri ve yazılım projeleri yayımlanmış sayfalardan alınmış örneklerdir ve yazı amBrain ile bunların herhangi biri arasında bir ilişki iddia etmez. Yazı amBrain'e ait fiyat, takvim ya da koşul vermez.

amBrain 2019'dan bu yana yazılım geliştiriyor. Üç formatta çalışıyor: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler. Mülkiyet konusundaki satırı ise şöyle: “Müşteri, yeniden kullanılabilir bileşenlerimiz dışında ürünün ve kodun tam mülkiyetini elinde tutar.” amBrain kısa listenizdeyse, ona da diğer her firmaya yönelttiğiniz soruların aynısını yöneltin.