AI Altyapısı Kurmak: Teknik Kararların Patron Özeti

Şirketinize AI altyapısı kurmak, tek bir teknik seçim değil dört ayrı yönetim kararının toplamıdır: verinizle konuşan bir sistem mi kuruyorsunuz, otonom görev yürüten bir ajan mı, sistemlerinizi birbirine mi bağlıyorsunuz, yoksa kendi sunucunuzda mı çalıştırıyorsunuz. Bu dördünü karıştırmak, altı ay sonra neden hâlâ çalışmıyor diye sorduğunuz, parası harcanmış bir projeyle sonuçlanır.

Bu yazı, dört temel AI altyapı kararını (verinizle konuşan sistem, otonom görev yürüten ajan, sistemler arası bağlantı ve kendi sunucunuzda mı bulutta mı çalıştıracağınız) mühendislik jargonundan uzak bir dille, ne zaman hangisi, ne kadara, ne riskle sorularına odaklanarak anlatıyor. Amaç, ekibinizle veya bir tedarikçiyle konuşurken doğru soruları sorabilecek hale gelmeniz.

Kümenin ilk yazısı olarak bir çatı görevi görüyor; devamında RAG'ı patron diliyle anlatan bir yazı ve gerçek bir AI ajanı kurulum hikayesi bu kararların her birini derinlemesine ele alıyor; fine-tuning, halüsinasyon mühendisliği, açık kaynak modeller ve MCP entegrasyonu konularını da ayrı yazılarda işleyeceğiz.

Türkiye'de şirketler bu kararları nasıl veriyor?

Microsoft'un 2026 Küresel Yapay Zeka Yayılım Raporu'na göre Türkiye, 2026'nın ilk çeyreğinde AI kullanımını yüzde 30 artırarak dünyada en hızlı ivmelenen pazarlardan biri oldu. Ama bu ivme çoğunlukla deneme aşamasında kalıyor: ücretsiz araçlarla başlayan işletmeler, iş süreçlerine gerçekten oturan bir altyapı kurma noktasına geldiğinde teknik kararların önünde tıkanıyor.

Sahada gördüğümüz en yaygın hata, aracı önce seçip sonra soruna uydurmaya çalışmak. Bir işletme chatbot alalım diye başlıyor, üç ay sonra chatbot'un şirketin güncel fiyat listesini bilmediğini fark ediyor; ya da tam tersi, basit bir soru-cevap botu yeterliyken karmaşık bir ajan sistemine para yatırılıyor. Doğru sıra tam tersi işler: önce hangi sorunu çözdüğünüzü netleştirin, sonra o soruna uyan tekniği seçin. Bu sırayı tersine çevirmek, sektör genelinde en sık tekrarlanan bütçe kaybı nedenlerinden biri.

İkinci yaygın hata, kararı tek bir kişiye (genelde en meraklı çalışana) bırakmak. Teknik olmayan bir karar vericinin devrede olmadığı projelerde ya kimse veri erişimi ya da risk kararı veremediği için proje aylarca toplantıda kalıyor, ya da teknik ekip işe yarar ama iş akışına hiç uymayan etkileyici bir demo üretiyor. Altyapı kararı, en az bir teknik ve en az bir iş tarafı kişisinin birlikte verdiği bir karar olmalı.

Üçüncü bir hata da az konuşulur ama en pahalısıdır: kararı hiç vermemek. Bir toplantıda dört seçenek de masaya gelir, hiçbiri net bir sahiplenici bulamaz, proje aylarca beklemede kalır; bu sırada rakip firmalar aynı süreci otomatikleştirip müşteri kazanmaya devam eder. Karar vermemek de bir karardır; maliyeti gecikmiş fırsat olarak görünmez, sessizce birikir.

RAG mi, fine-tuning mi, sade bir prompt mu?

Şirket verinizle konuşan bir sistem kurmak istiyorsanız üç yol var: modele her seferinde bağlamı elle vermek (prompt engineering), modeli kendi verinizle yeniden eğitmek (fine-tuning) ya da modelin cevap üretmeden önce ilgili belgeleri otomatik getirmesini sağlamak (RAG, Retrieval-Augmented Generation). Veriniz sık değişiyorsa, yani fiyat listesi, stok durumu ya da güncel prosedür gibi canlı bilgilerden söz ediyorsak, RAG neredeyse her zaman doğru seçim; modelin ağırlıklarını değiştirmeden, güncel belgelere dayanarak cevap üretmesini sağlar.

Fine-tuning ise farklı bir ihtiyaca cevap verir: markanızın tonunu, belirli bir sınıflandırma mantığını ya da çok spesifik bir uzmanlık dilini modele kalıcı olarak öğretmek istediğinizde işe yarar. Örneğin bir sigorta şirketi, hasar taleplerini standart bir formatta özetleyen ve şirket jargonunu doğru kullanan bir model istiyorsa, bu RAG'ın değil fine-tuning'in işi. 2025-2026'daki üretim projelerinin önemli bir kısmı aslında ikisini birlikte kullanıyor: güncel bilgi için RAG, tutarlı ton için hafif bir fine-tuning katmanı üstüne ekleniyor.

Sade prompt engineering'i (yani modele her seferinde ilgili bilgiyi elle veya otomatik olarak tam metin halinde vermeyi) küçümsemeyin; bilgi tabanınız görece küçükse ve sık değişmiyorsa, RAG kurmadan önce bunu deneyin. Bir avuç dokümanlık bir prosedür kitapçığı için RAG kurmak, çekiçle sinek öldürmeye benzer: fazladan mühendislik, fazladan maliyet. Ya RAG ya fine-tuning ikilemi çoğu zaman yanlış soru; gerçek soru hangi sorunu RAG çözer, hangisini fine-tuning çözer olmalı. Şirket verinizle konuşan bir asistan kurmayı düşünüyorsanız RAG'ın maliyetini ve 4 haftalık kurulum planını anlattığımız yazıya göz atmanızı öneririz.

AI ajanı mı, klasik chatbot mu?

Chatbot, sorulan soruya önceden tanımlanmış bir bilgi tabanından cevap üretir; pasiftir, sadece konuşur. AI ajanı ise bir görevi baştan sona yürütür: takviminize bakar, uygun saati bulur, toplantıyı ayarlar, davetiyeyi gönderir. Aradaki fark cevap vermek ile iş yapmak arasındaki farktır ve bu fark riski de büyütür; chatbot yanlış bilgi verdiğinde sadece yanlış cevap alırsınız, ajan o yanlış bilgiye göre bir aksiyon alırsa (yanlış siparişi onaylarsa, yanlış müşteriye indirim tanımlarsa) sonucu geri almanız gerekir.

Bu yüzden ajan kararı, chatbot kararından daha ağır bir sorumluluk taşır. Gartner'ın öngörüsüne göre 2026 sonunda kurumsal uygulamaların yüzde 40'ı görev odaklı bir AI ajanı barındıracak; 2025'te bu oran yüzde 5'in altındaydı. Hız yüksek ama olgunluk henüz düşük: sektör raporlarına göre otonom ajan kullanan kuruluşların ancak beşte biri güvenli ölçeklendirme için olgun bir yönetişim modeline sahip, geri kalanı büyük ölçüde denetimsiz ilerliyor.

Pratik bir ölçüt öneriyoruz: görev geri alınabilir mi diye sorun. Bir ajanın yanlış bir e-posta taslağı hazırlaması küçük bir risktir, siz onaylamadan gönderilmediği sürece. Aynı ajanın bir siparişi otomatik onaylaması ya da bir müşteriye para iadesi yapması geri alınması zor bir risktir ve mutlaka bir insan onay noktası ister. Bir ajan projesine başlamadan önce bu görevde bir insan onayı noktasına ihtiyacım var mı sorusunu mutlaka sorun; gerçek bir kurulum hikayesini anlattığımız yazıda bu kararın pratikte nasıl verildiğini görebilirsiniz.

MCP: Sistemlerinizi AI'a bağlamak

MCP (Model Context Protocol), bir AI modelinin şirket içi sistemlerinize (CRM, ERP, doküman deposu) standart bir yolla bağlanmasını sağlayan açık bir protokol. Kasım 2024'te Anthropic tarafından yayınlandı, kısa sürede OpenAI, Google, Microsoft ve Amazon dahil büyük oyuncular tarafından benimsendi; 2026 ortasında Fortune 500 şirketlerinin yaklaşık dörtte biri MCP'yi bir şekilde kurumsal kullanıma almış durumda, yazılım şirketlerinin ise yaklaşık iki-beşi üretimde ya da sınırlı üretimde bir MCP sunucusu çalıştırıyor.

Patron için pratik anlamı şu: MCP olmadan her yeni sistemi AI'a bağlamak özel bir entegrasyon projesi demekti; her CRM, her ERP, her doküman deposu için ayrı bir köprü yazmak gerekiyordu. MCP ile bu bağlantı standart bir fiş haline geliyor, geliştirme süresi ve maliyeti düşüyor, tedarikçi bağımlılığı azalıyor. Cisco, MongoDB, PayPal gibi büyük şirketlerin yanında bir bankanın risk değerlendirme sürecinde yüzde 40'lık bir hız kazanımı raporladığı da biliniyor.

Türkçe kaynaklarda MCP hakkında tanım düzeyinde içerik var ama gerçek kurulum örnekleriyle anlatan pek yok; bu, KOBİ'ler için hem bir fırsat hem bir risk anlamına geliyor. Fırsat: standart bulunduğu için artık her entegrasyon sıfırdan yazılmıyor. Risk: standart yeni olduğu için hangi tedarikçinin MCP desteğinin olgun, hangisinin sadece pazarlama sloganı olduğunu ayırt etmek zor. Bu konuyu kümenin ilerleyen bir yazısında somut kurulum örnekleriyle ayrıca ele alacağız.

Pratikte MCP kararı genelde ikinci aşamada gündeme gelir: önce RAG ya da ajan projenizi tek bir veri kaynağıyla (örneğin bir doküman deposuyla) kurar, işe yaradığını görürsünüz; sonra bunu CRM'inize, muhasebe yazılımınıza ya da stok sisteminize bağlamak istediğinizde MCP devreye girer. İlk projede MCP genelde gerekmiyor; ikinci ve üçüncü sistemi bağlarken standart bir protokole sahip olmanın değeri katlanarak artıyor.

Kendi sunucunuzda mı, API ile mi?

Kendi sunucumuzda model çalıştırsak daha mı ucuz olur sorusu sıkça geliyor; cevap çoğu şirket için hayır. API üzerinden büyük sağlayıcıların modellerini kullanmak, günlük kullanım hacmi çok yüksek olmadığı sürece (günde on milyonlarca token gibi bir hacimden söz ediyoruz) neredeyse her zaman daha ucuza gelir. Ucuz açık model API'leri zaten mevcut sabit maliyetli kendi sunucunuza karşı avantajlı çıkıyor; kendi sunucunuzda bir model çalıştırmak sabit donanım maliyetinin yanında ayda onlarca saat bakım mühendisliği gerektirir, bu çoğu KOBİ için görünmeyen ama gerçek bir maliyet kalemi.

Kendi sunucunuzda çalıştırmayı gerçekten mantıklı kılan iki durum var: veri egemenliği zorunluluğu (verinin ülke dışına çıkmaması gereken bir sektördeyseniz, örneğin bazı finans ya da kamu ilişkili işler) ya da gerçekten çok yüksek ve istikrarlı bir kullanım hacmi. Türkiye'de son dönemde konuşulan egemen yapay zeka gündemi de bu ikinci gerekçeyi zamanla daha fazla şirket için gündeme getirebilir; ama bugün için çoğu KOBİ bu eşiğin çok altında.

Bu ikisi sizin durumunuz değilse, API ile başlamak ve gerektiğinde gözden geçirmek daha az riskli bir yol. API ile başlayıp sonradan belirli bir bileşeni kendi sunucunuza taşımak mümkün; tersini yapmak, yani baştan büyük bir sunucu yatırımı yapıp sonra bunun gereksiz olduğunu fark etmek, çok daha maliyetli bir geri dönüş.

Bu kararı verirken sık atlanan bir üçüncü seçenek daha var: hibrit yaklaşım. Bazı şirketler, hassas veriyle çalışan tek bir bileşeni (örneğin kişisel veri içeren bir belge arama katmanını) kendi altyapılarında tutup, geri kalan işlemler için bulut API'lerini kullanıyor. Bu, veri egemenliği kaygısı ile maliyet gerçekliği arasında orta bir yol sunuyor ve özellikle sağlık, finans gibi düzenlemeye tabi sektörlerde giderek daha sık tercih ediliyor.

Sık sorulan sorular

İlk AI altyapı projesine ne kadar bütçe ayırmalıyım?

Kapsam çok belirleyici olsa da küçük bir pilot proje (tek bir bilgi tabanı, tek bir kullanım senaryosu) genellikle birkaç bin dolarlık bir aralıkta başlar; kurumsal ölçekte çok kaynaklı, çok kullanıcılı bir sistem ise bunun kat kat üzerine çıkar. Kesin rakam yerine küçük başlamayı ve ilk projeyi ölçülebilir tutmayı önceliklendirin.

Bir AI altyapı projesi ne kadar sürede sonuç verir?

Dar kapsamlı, tek veri kaynaklı bir pilot proje genellikle dört ila altı haftada canlıya alınabilir. Çok kaynaklı, kurumsal ölçekte bir entegrasyon ise veri kalitesine ve kaynak sistem sayısına göre iki-üç aya kadar uzayabilir. Hızlı sonuç istiyorsanız kapsamı daraltmak, süreyi kısaltmanın en güvenilir yolu.

Teknik ekibim yoksa bu kararları nasıl vereceğim?

Teknik ekibiniz yoksa bile bu yazıdaki dört soruyu (hangi sorunu çözüyoruz, veri ne sıklıkla değişiyor, görev geri alınabilir mi, veri nerede tutulmalı) tedarikçinize siz sorabilirsiniz. İyi bir tedarikçi bu sorulara net cevap verir; net cevap alamıyorsanız bu, kırmızı bir bayraktır.

Dört kararın maliyet mertebeleri

Kesin fiyat vermek yanıltıcı olur çünkü kapsam projeden projeye çok değişiyor; ama mertebeyi bilmek bile toplantıda sizi güçlü kılar. Global kaynaklara göre basit bir RAG prototipi genellikle birkaç bin dolarlık bir aralıkta başlar, üretim seviyesinde hibrit bir kurulum ise on binlerce dolara çıkabilir; aylık işletme maliyeti (vektör veritabanı, embedding, LLM API çağrıları) küçük ölçekte aylık birkaç yüz dolar civarında seyreder. Bu rakamlar ABD pazarından; Türkiye'de yerli bir yazılım ekibiyle çalışırsanız TL bazında genelde daha uygun bir toplam çıkar, ama oran olarak benzer bir sıralama (prototip < üretim < kurumsal ölçek) geçerliliğini korur.

Bir AI ajanı projesi de benzer bir merdiven izliyor: basit bir kavram kanıtlama birkaç bin dolar, tek bir görevi otonom yürüten reaktif bir ajan on binlerce dolar, çok adımlı kurumsal bir ajan sistemi ise yüz binlerce dolara kadar çıkabiliyor. Fine-tuning tarafında ise küçük bir açık kaynak modeli belirli bir görevle eğitmek görece ucuz (yüzlerce dolar mertebesinde bir çalıştırma), ama bu maliyetin üstüne mühendislik zamanı ve tekrar eğitim ihtiyacı da eklenir. Buradaki genel kural şu: kapsamı bir kademe küçültmek, maliyeti çoğu zaman bir kademeden fazla düşürür; bu yüzden ilk projeyi olabildiğince dar tutmak hem risk hem bütçe açısından mantıklı.

Bu kümede sırada ne var?

Bu yazı dört temel kararı özetliyor ama her biri kendi başına derinleşmeyi hak ediyor. Kümenin ilerleyen yazılarında şu konuları ayrı ayrı ele alacağız: fine-tuning, RAG ve iyi bir prompt arasında nasıl seçim yapılacağını gösteren bir karar ağacı; yapay zekanın neden kendinden emin yanlış bilgi ürettiğini ve bunu üretim sistemlerinde nasıl engelleyeceğinizi anlatan bir halüsinasyon mühendisliği rehberi; açık kaynak ve yerli modellerle kendi sunucunuzda AI çalıştırmanın gerçekten ne zaman mantıklı olduğunu somut maliyetlerle gösteren bir yazı; ve MCP standardıyla şirket sistemlerinizi AI'a bağlamanın pratik kurulum adımlarını anlatan bir rehber. Bu yazılar yayınlandıkça buradan da link vereceğiz.

Bu kararı dış kaynak kullanmadan kendi ekibimle verebilir miyim?

Küçük ölçekte evet, ama iki taraflı bir bakış şart: teknolojiyi bilen biri ile iş sürecini bilen biri aynı odada olmalı. Sadece teknik ekibe bırakılan kararlar iş akışına uymayan çözümler üretiyor; sadece iş tarafına bırakılan kararlar ise gerçekçi olmayan beklentiler yaratıyor. Orta ve büyük ölçekli projelerde bağımsız bir danışman gözünün, tedarikçinin önerdiği çözümün gerçekten ihtiyaca uygun olup olmadığını denetlemesi faydalı olur.

Somut senaryo: 40 kişilik bir mühendislik firması

Bir taahhüt/mühendislik firması düşünün: teklif hazırlama süreci, eski projelerin teknik şartnamelerini, birim fiyat listelerini ve geçmiş revizyonları tarayan bir ekip tarafından elle yürütülüyor. Bir teklif hazırlamak ortalama bir gün sürüyor, çünkü doğru referans dokümanı bulmak arşivde kaybolmak anlamına geliyor. Şirket önce bir chatbot alalım, sorularımızı cevaplasın diye düşünüyor ama asıl ihtiyaç farklı çıkıyor: şirketin sekiz yıllık doküman arşivini bilen, güncel birim fiyatları anlayan bir sistem.

Doğru karar burada net bir RAG kurulumu: arşivi indeksleyen ve teklif hazırlarken ilgili geçmiş dokümanı öneren bir asistan. Fine-tuning'e gerek yok çünkü burada ton sorunu yok, güncel ve spesifik bilgiye erişim sorunu var. Ajan mimarisine de henüz gerek yok; sistem sadece bilgi getirsin yeterli, otomatik teklif göndermesin, çünkü fiyatlama kararı hâlâ mühendisin elinde kalmalı. Kendi sunucusunda model çalıştırmaya da gerek yok, çünkü hacim küçük ve veri egemenliği zorunluluğu bulunmuyor.

Sonuç: dört karar noktasının üçünde en basit seçenek (API, RAG, insan onaylı süreç) doğru seçenek çıkıyor. Bu, altyapı kararlarında sık unutulan bir gerçeği gösteriyor: en gösterişli teknoloji genelde en doğru teknoloji değil, en dar kapsamlı çözüm çoğu zaman en hızlı geri dönüşü sağlıyor.

Firmanın kendi anlattığına göre pilot projeden altı hafta sonra teklif hazırlama süresi ortalama bir günden birkaç saate inmiş; en büyük kazanım hız değil doğruluk olmuş, çünkü sistem artık hangi geçmiş projede benzer bir kalem kullanıldığını hatırlıyor ve mühendis onu elle aramak zorunda kalmıyor. İkinci ayda ekip, aynı altyapıyı satış sonrası garanti sorularını cevaplayan ikinci bir kullanım alanına genişletmeyi planlıyor; bu da altyapı kararlarının bir başka özelliğini gösteriyor: doğru kurulan ilk pilot, ikinci ve üçüncü kullanım alanına genişlemenin maliyetini büyük ölçüde düşürüyor.

Peki siz ne yapmalısınız?

• Karara önce sorunu tanımlayarak başlayın, araç seçimini sona bırakın: hangi bilgiye erişim eksik, hangi görev otomatik yürütülmeli, bu ikisini birbirinden ayırın.
• Veriniz sık değişiyorsa RAG, ton veya tutarlılık sorunu varsa fine-tuning düşünün; ikisini birbirine alternatif değil tamamlayıcı görün.
• Bir ajan kuracaksanız, geri alınması zor her aksiyon için mutlaka bir insan onay noktası tanımlayın; bu, projenin en ucuz sigortasıdır.
• Kendi sunucunuzda model çalıştırma kararını sadece veri egemenliği zorunluluğu ya da gerçekten çok yüksek hacim varsa değerlendirin; aksi halde API ile başlayın.
• İlk projeyi küçük ve ölçülebilir tutun; net bir başarı ölçütü belirlemeden büyük bütçeye geçmeyin.

Bu dört karar birbirine sıkı sıkıya bağlı; birini yanlış verirseniz diğerleri de sağlam bir zeminde durmaz. Kümenin devamındaki yazılarda her birini ayrı ayrı, gerçek rakamlar ve kurulum adımlarıyla derinleştireceğiz.