Build Buy Assemble: Kurumsal AI'da Doğru Karar Çerçevesi (Geliştir / Satın Al / Birleştir)

Build buy assemble nedir? Build buy assemble, kurumsal bir AI (yapay zeka) yeteneğini elde etmenin üç temel yolunu — geliştir (build), satın al (buy) ve birleştir (assemble) — tek bir karar çerçevesinde toplayan yaklaşımdır. Bu çerçeve, "kendi AI çözümümüzü mü kuralım, hazır olanı mı alalım?" sorusunu ikili bir seçimden çıkarıp, çoğu kurum için en gerçekçi üçüncü yolu — mevcut bileşenleri kendi verinizle birleştirmeyi — masaya koyar.

Bir kurum yeni bir AI yeteneğine ihtiyaç duyduğunda ilk refleks genellikle iki uçtan biridir: ya "bunu kendimiz geliştirelim, kontrol bizde olsun" ya da "hazır bir ürün alalım, hızlı başlayalım". Oysa build buy assemble çerçevesi gösterir ki bu ikili düşünce yanıltıcıdır; gerçek karar, üç seçeneği stratejik farklılaşma, toplam sahip olma maliyeti, hız, kontrol, veri egemenliği, yetenek ve bakım yükü boyutlarında tartmayı gerektirir. Bu rehber, build buy assemble kararını bir yönetim danışmanı titizliğiyle ele alıyor: üç yaklaşımın net tanımı ve avantaj-dezavantajları, karar kriterleri, karar matrisi ve karar ağacı, TCO karşılaştırması, assemble'ın neden bugünün normu olduğu, satıcı bağımlılığı ve veri egemenliği, örnek senaryolar, uygulama kontrol listesi ve yaygın hatalar.

Tanım

Build / Buy / Assemble (Geliştir / Satın Al / Birleştir)

Kurumsal bir AI (yapay zeka) yeteneğini elde etmenin üç temel stratejisini tanımlayan karar çerçevesi: build (çözümü sıfırdan kendi geliştirmek), buy (hazır bir ürün veya hizmet satın almak) ve assemble (mevcut bileşenleri — hazır modeller, API'ler, açık kaynak — kurumun kendi verisi ve iş mantığıyla birleştirmek). Karar; stratejik farklılaşma, toplam sahip olma maliyeti (TCO), hız, kontrol, veri egemenliği, yetenek ve bakım yükü kriterlerine göre verilir ve modern pratikte çoğunlukla assemble (hibrit mimari) yönünde sonuçlanır.

Ayrıca: build vs buy, satın al mı geliştir mi, geliştir satın al birleştir, hibrit AI mimarisi, yapım-satın alma kararı

Kurumsal AI'da build buy assemble kararı, teknoloji seçimi gibi görünen ama aslında stratejik bir karardır. Yanlış verildiğinde, kurum ya farklılaştırmayan bir işe pahalı bir geliştirme bütçesi gömer, ya da rekabet avantajının kaynağı olabilecek bir yeteneği dışarıya emanet eder. Bu yüzden "geliştir mi, satın al mı, birleştir mi?" sorusu, CTO'nun teknik masasında değil, stratejinin masasında yanıtlanmalıdır.

Birinci neden kaynak tahsisidir. Her kurumun sınırlı mühendislik kapasitesi, sınırlı bütçesi ve sınırlı dikkati vardır. Build buy assemble çerçevesi, bu sınırlı kaynağı nereye yönlendireceğinizi belirler: kendi geliştirdiğiniz her şey, geliştirmediğiniz başka bir şeyin maliyetidir. Standart, farklılaştırmayan bir yeteneği build etmek, o mühendislik kapasitesini gerçek rekabet avantajı üretebilecek bir alandan çalar. Doğru karar, kaynağı en yüksek stratejik getiriyi ürettiği yere yönlendirir.

İkinci neden hızdır. AI ekosistemi hızla değişiyor; bugün sıfırdan geliştirmeye başladığınız bir yetenek, siz bitirmeden hazır bir üründe standart hâle gelebilir. Bu bağlamda time-to-market (pazara çıkış süresi), çoğu zaman mükemmellikten daha değerlidir. Satın al mı geliştir mi kararı, aslında büyük ölçüde bir hız kararıdır: buy en hızlı, build en yavaş, assemble ise ikisinin arasında kontrollü bir hız sunar. Yanlış seçim, kurumu ya çok yavaş (her şeyi build) ya da çok kontrolsüz (her şeyi buy) bir konuma iter.

Üçüncü neden farklılaşmadır. Bir kurumun rekabet avantajı, herkeste olan yeteneklerden değil, ona özgü olan yeteneklerden gelir. Eğer stratejik farklılaşmanızın kaynağı olan bir yeteneği satın alırsanız, aynı ürünü rakipleriniz de satın alabilir ve avantajınız buharlaşır. Bu yüzden build buy assemble kararının kalbinde şu soru yatar: "Bu yetenek beni gerçekten farklılaştırıyor mu, yoksa yalnızca çalışmam gereken standart bir bileşen mi?" Kurumsal AI stratejisinin bütününü görmek için kurumsal yapay zeka stratejisi nasıl oluşturulur rehberi iyi bir başlangıçtır.

Dördüncü neden geri döndürülebilirliktir. Bir build buy assemble kararı, verildiği anda kurumu belirli bir yola sokar; ve bazı yollardan dönmek diğerlerinden çok daha pahalıdır. Yanlış bir buy kararı, sizi öyle bir satıcı bağımlılığına kilitleyebilir ki geri dönüş neredeyse imkânsız hale gelir; yanlış bir build kararı ise, geri alınması güç bir teknik borç ve batık maliyet yaratır. Bu yüzden karar verilirken yalnızca "hangisi bugün doğru?" değil, "yanlış çıkarsa geri dönmek ne kadar pahalı?" sorusu da sorulmalıdır. Geri döndürülebilirliği yüksek kararlar (örneğin iyi müzakere edilmiş bir buy veya modüler bir assemble), belirsizlik altında daha güvenlidir çünkü hata durumunda düzeltme maliyeti düşüktür. Bu nedenle deneyimli kurumlar, belirsizliğin yüksek olduğu erken aşamalarda geri döndürülebilir kararları tercih eder ve ancak belirsizlik azaldıkça geri dönüşü zor kararlara (ağır build) yönelir.

Build, bir AI yeteneğini kendi ekibinizle, temel bileşenlerine kadar sıfırdan geliştirmektir. Bu, en uç yorumunda kendi temel modelinizi eğitmek, tüm altyapıyı özel yazmak ve çözümün her katmanını kurum içinde üretmek anlamına gelir. Pratikte tam anlamıyla saf build (kendi temel modelini sıfırdan eğitmek) çok az kurumun harcı olsa da, "özel geliştirme ağırlıklı" yaklaşımlar hâlâ belirli senaryolarda doğru seçimdir.

Build'in en büyük avantajı tam kontrol ve maksimum farklılaşmadır. Çözümü siz geliştirdiğinizde, onu tam olarak kendi ihtiyacınıza göre şekillendirir, hiçbir satıcıya bağımlı kalmaz ve rekabet avantajınızın kaynağı olan mantığı kurum sınırları içinde tutarsınız. Veri egemenliği ve KVKK açısından da build genellikle en güvenli yoldur: veri hiçbir zaman üçüncü taraf bir sunucuya çıkmaz. Ayrıca uzun vadede ve yüksek hacimde, build'in birim maliyeti abonelik tabanlı satın almanın altına inebilir.

Build'in dezavantajları ise ciddidir. Birincisi maliyet ve süre: sıfırdan geliştirme, yüksek başlangıç yatırımı ve uzun bir geliştirme takvimi gerektirir. İkincisi yetenek: build, nadir ve pahalı bir mühendislik/veri bilimi yetkinliği ister; bu yeteneği bulmak ve elde tutmak çoğu kurum için zordur. Üçüncüsü bakım yükü: kendi geliştirdiğiniz çözümü ayakta tutmak — izleme, güncelleme, güvenlik, yeniden eğitim — sürekli bir emek gerektirir ve bu operasyon disiplinini kurmak (LLMOps) başlı başına bir yatırımdır.

Build'in en sinsi dezavantajı ise fırsat maliyetidir. Bir yeteneği build etmek için harcadığınız mühendislik zamanı ve dikkat, başka bir yerde kullanılamayan bir kaynaktır. Standart bir yeteneği aylarca build eden bir ekip, o süre boyunca gerçekten farklılaştırıcı bir yeteneğe odaklanamaz. Bu görünmez maliyet — "keşke bu ekibi başka bir yere koysaydık" — çoğu build kararında hiç hesaba katılmaz, ama uzun vadede en pahalı kalem olabilir. Deneyimli kurumlar, build kararını verirken yalnızca "bunu build edebilir miyiz?" değil, "bu ekibi build'e ayırırsak, hangi daha değerli işten vazgeçmiş oluruz?" sorusunu da sorar. Bu fırsat maliyeti bilinci, build'in yalnızca gerçekten stratejik yeteneklere ayrılmasını sağlar.

Ayrıca build, teknik borç riskini de beraberinde getirir. Sıfırdan geliştirilen bir çözüm, zamanla bakımı zorlaşan, belgelenmemiş ve yalnızca birkaç kişinin anladığı bir sisteme dönüşebilir. O kişiler kurumdan ayrıldığında, build edilmiş sistem bir yükümlülüğe dönüşür. Buy ve assemble'da bu risk daha düşüktür çünkü temel bileşenleri satıcı sürdürür ve belgeler. Build kararı verirken, çözümün yalnızca bugününü değil, beş yıl sonraki sürdürülebilirliğini de düşünmek gerekir.

Build Ne Zaman Doğru Seçimdir?

Build, bir yetenek kurumun rekabet avantajının doğrudan kaynağıysa, hiçbir hazır ürünün karşılamadığı çok özgün bir ihtiyaç varsa, veri egemenliği mutlak bir zorunluluksa ve kurumun bu yeteneği geliştirip sürdürecek olgunluğu ve bütçesi varsa doğru seçimdir. Örneğin bir yapay zeka şirketi için modelin kendisi ürünse, onu build etmek kaçınılmazdır. Ancak çoğu kurum için "temel modeli sıfırdan build etmek" ile "hazır bir modeli kendi verisiyle birleştirmek" (assemble) arasındaki fark hayatidir; ilki nadiren, ikincisi sıklıkla doğrudur. Açık kaynak modellerin build/assemble ekseninde nasıl kullanıldığını açık kaynak LLM nedir yazısında ele alıyoruz.

Buy, hazır bir AI ürününü veya hizmetini — bir SaaS uygulaması, kurumsal bir yazılım, hazır bir API tabanlı asistan — satın almaktır. Bu yaklaşımda kurum, çözümü geliştirmez; bir satıcının ürettiği ve sürdürdüğü hazır bir çözümü lisanslar ve kullanır. Satın al mı geliştir mi tartışmasının "satın al" ucudur.

Buy'ın en büyük avantajı hız ve düşük başlangıç maliyetidir. Hazır bir ürünü günler veya haftalar içinde devreye alabilir, mühendislik kapasitesi harcamadan değer üretmeye başlayabilirsiniz. Bakım, güncelleme ve altyapı satıcının sorumluluğundadır; siz yalnızca kullanırsınız. Öngörülebilir bir abonelik maliyeti, bütçelemeyi kolaylaştırır. Standart, farklılaştırmayan ihtiyaçlar için (örneğin genel bir toplantı özetleme aracı, standart bir çeviri hizmeti) buy neredeyse her zaman en akılcı yoldur çünkü bu yeteneği kendiniz geliştirmenin size hiçbir stratejik getirisi yoktur.

Buy'ın dezavantajları ise kontrol kaybı ve satıcı bağımlılığında toplanır. Hazır bir ürün, tam olarak sizin ihtiyacınıza göre şekillenmez; satıcının yol haritasına, fiyatlandırmasına ve kararlarına bağımlı kalırsınız. Ölçekte, abonelik ücretleri beklenenden hızlı büyüyebilir. En kritiği: eğer satın aldığınız yetenek sizi farklılaştıran bir yetenekse, aynı ürünü rakipleriniz de alabileceği için rekabet avantajınızı dışarı vermiş olursunuz. Ayrıca veri hassasiyeti yüksek senaryolarda, verinin satıcının sunucularına gitmesi KVKK ve veri egemenliği açısından risk oluşturabilir.

Buy Ne Zaman Doğru Seçimdir?

Buy, bir yetenek standartsa ve sizi farklılaştırmıyorsa, hıza ihtiyaç varsa, kurumun o yeteneği geliştirecek yeteneği veya isteği yoksa ve veri hassasiyeti yönetilebilir düzeydeyse doğru seçimdir. Kural basittir: farklılaştırmayan her şeyi mümkün olduğunca satın alın ki, sınırlı mühendislik kapasitenizi gerçekten önemli olan yere ayırabilesiniz. Ancak buy kararında satıcı bağımlılığı ve çıkış maliyeti baştan değerlendirilmeli; "bu satıcıdan ayrılmam gerekirse maliyeti ne olur?" sorusu, sözleşme imzalanmadan sorulmalıdır.

Buy kararında sık atlanan bir nokta, sözleşmenin kendisinin bir stratejik araç olmasıdır. Bir hazır ürün satın alırken müzakere edilecek şeyler yalnızca fiyat değildir: veri sahipliği (verinizin satıcı tarafından model eğitiminde kullanılıp kullanılmayacağı), veri taşınabilirliği (ayrılırken verinizi hangi formatta geri alacağınız), hizmet seviyesi taahhütleri ve fiyat artış koşulları da en az fiyat kadar önemlidir. İyi müzakere edilmiş bir buy sözleşmesi, satıcı bağımlılığı riskinin önemli bir kısmını baştan sınırlar; kötü müzakere edilmiş bir sözleşme ise sizi ileride pahalı bir lock-in'e kilitler. Bu yüzden buy, "en ucuz ürünü seç" değil, "en iyi koşulları müzakere et" kararıdır.

Buy'ın bir başka ince avantajı, sürekli iyileşmedir: iyi bir SaaS satıcısı, ürününü siz hiçbir şey yapmadan sürekli geliştirir; yeni model sürümleri, yeni özellikler ve güvenlik iyileştirmeleri otomatik gelir. Build veya assemble'da bu iyileşmeyi kendiniz üretmek zorundasınız. Dolayısıyla hızla değişen ve sizi farklılaştırmayan bir alanda buy, yalnızca bugünkü ihtiyacı değil, gelecekteki iyileşmeyi de satın almaktır. Karar verirken "bu alan hızlı değişiyor mu ve ben bu değişimi kendim takip edebilir miyim?" sorusu, buy lehine güçlü bir argüman olabilir.

Assemble, mevcut hazır bileşenleri — güçlü API tabanlı modeller, açık kaynak modeller, hazır vektör veritabanları, orkestrasyon araçları, hazır kütüphaneler — kurumun kendi verisi, iş mantığı ve entegrasyonlarıyla birleştirerek özgün bir çözüm kurmaktır. Assemble'da "zeka" (temel model) hazır gelir; farklılaşma, o zekayı nasıl birleştirdiğinizden, hangi veriyle beslediğinizden ve iş süreçlerinize nasıl oturttuğunuzdan doğar. Bu, saf build ile saf buy arasındaki üçüncü ve bugün en yaygın yoldur.

Assemble'ı build'den ayıran temel fark, temel bileşenleri sıfırdan üretmemenizdir. Bir temel modeli eğitmek yerine hazır bir modeli alırsınız; bir vektör veritabanını sıfırdan yazmak yerine hazır bir tanesini kullanırsınız. Ama bu bileşenleri kendi verinizle ve iş mantığınızla birleştirdiğinizde, ortaya kurumunuza özgü ve farklılaştırıcı bir çözüm çıkar. Örneğin bir RAG (bilgi getirimiyle üretim) sistemi tipik bir assemble örneğidir: hazır bir dil modeli + hazır bir vektör veritabanı + kurumun kendi belgeleri = kimsede olmayan, kuruma özel bir bilgi erişim çözümü. Modelleri araçlara ve verilere bağlayan protokoller (örneğin MCP) assemble'ı daha da kolaylaştırır.

Assemble'ı buy'dan ayıran fark ise kontrol ve farklılaşmadır. Hazır bir ürünü olduğu gibi satın almak yerine, bileşenleri kendiniz birleştirdiğinizde çözümü kendi ihtiyacınıza göre şekillendirir, verinizi kendi sınırlarınızda tutabilir ve tek bir satıcıya tam bağımlı kalmazsınız. Doğru kurulmuş bir assemble mimarisi, bir model sağlayıcıdan diğerine geçmeyi tüm sistemi değiştirmeden mümkün kılar — bu da satıcı bağımlılığını azaltır.

Assemble'ın pratikte nasıl göründüğünü somutlaştırmak faydalı olur. Tipik bir kurumsal assemble mimarisi birkaç katmandan oluşur: en altta hazır bir temel model (API tabanlı veya kendi altyapınızda barındırılan açık kaynak), onun üstünde bir orkestrasyon katmanı (istekleri yöneten, araçları bağlayan), bir bilgi katmanı (kurumun kendi verisi, bir vektör veritabanı ve getirme mantığı), bir güvenlik/uyum katmanı (guardrail'ler, erişim kontrolü, denetim izi) ve en üstte kuruma özel iş mantığı ile kullanıcı arayüzü. Bu katmanların her biri ayrı ayrı satın alınabilir, birleştirilebilir veya geliştirilebilir; işte assemble'ın esnekliği tam da bu katmanlı yapıdan doğar. Bir katmanı değiştirmek diğerlerini bozmaz — bu, hem satıcı bağımlılığını azaltır hem de sistemi zamanla evriltmeyi kolaylaştırır.

Assemble'ın kurumsal AI'da bu kadar baskın hale gelmesinin somut bir nedeni de, farklılaşmanın artık "veri + entegrasyon + deneyim" üçlüsünde yoğunlaşmasıdır. Temel model herkese açık olduğu için, iki kurum aynı modeli kullanabilir; ama biri kendi kurumsal verisiyle, kendi iş süreçleriyle ve kendi kullanıcı deneyimiyle birleştirdiğinde, ortaya rakibinin kolayca kopyalayamayacağı bir çözüm çıkar. Bu yüzden assemble, "hazır zekayı al, kurumsal farkı ekle" formülüdür; ve bu formül, bugünün rekabet gerçekliğine build ve buy'dan daha iyi uyar.

Build, Buy ve Assemble yaklaşımlarının temel karşılaştırması

Boyut	Build (Geliştir)	Buy (Satın Al)	Assemble (Birleştir)
Kontrol	En yüksek	En düşük	Yüksek
Hız (time-to-market)	En yavaş	En hızlı	Hızlı
Başlangıç maliyeti	En yüksek	En düşük	Orta
Farklılaşma potansiyeli	En yüksek	En düşük	Yüksek
Yetenek gereksinimi	Çok yüksek	Düşük	Orta
Satıcı bağımlılığı	En düşük	En yüksek	Yönetilebilir

Build buy assemble kararı tek bir soruya değil, birbirini tamamlayan yedi kritere göre verilir. Bu kriterleri boyut boyut değerlendirmek, "içgüdüsel" bir karardan çıkıp savunulabilir bir karara geçmenizi sağlar. Hiçbir kriter tek başına belirleyici değildir; hepsi birlikte tartıldığında doğru yaklaşım ortaya çıkar. Kriterleri ayrı ayrı ele almanın bir başka faydası, örgüt içindeki farklı tarafların hangi kriteri önceliklendirdiğini görünür kılmasıdır: iş birimi hızı, güvenlik ekibi kontrolü, finans ise maliyeti öne çıkarır. Kriterleri açıkça masaya koymak, bu farklı önceliklerin çatışmasını yapıcı bir tartışmaya dönüştürür.

1. Stratejik Farklılaşma

En belirleyici kriter budur. Soru şudur: "Bu yetenek beni rakiplerimden ayırıyor mu, yoksa herkeste olan standart bir bileşen mi?" Eğer yetenek stratejik farklılaşmanızın kaynağıysa — yani rekabet avantajınız ona dayanıyorsa — onu dışarı vermek (buy) avantajınızı buharlaştırır; bu durumda build veya assemble tercih edilir. Eğer yetenek standartsa ve sizi farklılaştırmıyorsa, onu build etmek kaynak israfıdır; buy uygundur. Bu kriter, kararın kalbindedir ve diğer tüm kriterlerden önce yanıtlanmalıdır.

2. Toplam Sahip Olma Maliyeti (TCO)

İkinci kriter, çözümün ömrü boyunca gerçek maliyetidir. Toplam sahip olma maliyeti, yalnızca lisans veya geliştirme ücretini değil; entegrasyon, insan, bakım, altyapı ve çıkış maliyetlerini de kapsar. Build'in başlangıç maliyeti yüksek ama ölçekte birim maliyeti düşebilir; buy'ın başlangıcı ucuz ama ölçekte abonelik büyür; assemble ikisinin arasındadır. TCO'yu doğru hesaplamak, kararı "bugün hangisi ucuz?" sorusundan "üç yılda hangisi daha düşük toplam maliyet üretir?" sorusuna taşır. TCO'nun ROI ile ilişkisini yapay zeka ROI nasıl hesaplanır yazısında derinlemesine ele alıyoruz.

3. Hız ve Pazara Çıkış Süresi (Time-to-Market)

Üçüncü kriter zamandır. Bir yeteneğe ne kadar hızlı ihtiyacınız var? Buy en hızlı yoldur (günler/haftalar), assemble hızlıdır (haftalar/aylar), build en yavaştır (aylar/yıllar). Rekabetin hızlı hareket ettiği veya fırsat penceresinin dar olduğu durumlarda, hız çoğu zaman mükemmellikten daha değerlidir. "Altı ayda kusursuz build" ile "iki haftada iyi assemble" arasında, iş değeri genellikle ikincisindedir.

4. Kontrol

Dördüncü kriter, çözüm üzerindeki kontrol derecesidir. Çözümün nasıl çalıştığını, ne zaman güncellendiğini, hangi veriyle beslendiğini ne kadar kontrol etmeniz gerekiyor? Build en yüksek kontrolü, buy en düşüğünü verir; assemble yüksek ama tam olmayan bir kontrol sunar. Düzenlenmiş sektörlerde (finans, sağlık) veya kritik iş süreçlerinde kontrol ihtiyacı yüksektir ve kararı build/assemble yönüne kaydırır.

5. Veri Hassasiyeti ve Egemenliği

Beşinci kriter, işlenen verinin hassasiyetidir. Kişisel veri, ticari sır veya kritik kurumsal veri söz konusuysa; verinin nerede işlendiği, saklandığı ve kimin eriştiği hayati önem kazanır. Hazır bir SaaS (buy) veriyi yurt dışı sunuculara gönderiyorsa bu, KVKK ve veri egemenliği açısından risktir. Yüksek hassasiyette karar, veriyi kurum sınırları içinde tutan build veya assemble yönüne kayar. Bu boyutu KVKK nedir ve self-hosted LLM vs API (KVKK/BDDK) yazılarında somutlaştırıyoruz.

6. Yetenek (Talent)

Altıncı kriter, kurumun elindeki mühendislik ve veri bilimi yetkinliğidir. Build, nadir ve pahalı bir yetenek ister; bu yetenek yoksa, build kararı kâğıt üzerinde iyi ama pratikte başarısız olur. Assemble daha ılımlı bir yetenek gerektirir; buy neredeyse hiç. Kararı verirken "bu yolu yürütecek insan kaynağımız var mı?" sorusu dürüstçe yanıtlanmalıdır. Ekiplerin AI yetkinliğini geliştirmek için kurumsal eğitim seçenekleri bu kriteri güçlendirir.

7. Bakım Yükü

Yedinci kriter, çözümü ayakta tutmanın sürekli maliyetidir. Build ettiğiniz her şeyi siz sürdürürsünüz: izleme, güncelleme, güvenlik, yeniden eğitim. Buy'da bakım satıcıdadır. Assemble'da bakım paylaşılır: bileşenleri satıcı sürdürür, birleştirmeyi siz. Bakım yükü çoğu zaman TCO'nun en çok küçümsenen kalemidir; bir modeli üretime almak bir kere yapılan iş değil, sürekli bir operasyondur.

Yedi karar kriteri ve hangi yaklaşımı işaret ettiği

Kriter	Build'i işaret eder	Buy'ı işaret eder	Assemble'ı işaret eder
Stratejik farklılaşma	Yüksek (çekirdek avantaj)	Yok (standart)	Orta-yüksek
TCO önceliği	Yüksek hacim, uzun vade	Düşük başlangıç istiyorsanız	Dengeli maliyet
Hız ihtiyacı	Düşük (zaman var)	Çok yüksek	Yüksek
Kontrol ihtiyacı	Mutlak	Düşük	Yüksek
Veri hassasiyeti	Çok yüksek	Düşük	Yüksek (kontrollü)
Yetenek durumu	Güçlü ekip var	Ekip yok	Orta ekip

Yukarıdaki yedi kriteri pratik bir karara dönüştürmenin en etkili yolu, bir karar matrisi ve bir karar ağacı kullanmaktır. Karar matrisi, kriterleri ağırlıklandırıp her seçeneği puanlamanızı sağlar; karar ağacı ise sıralı sorularla sizi doğrudan doğru yaklaşıma yönlendirir.

Karar ağacı en basit haliyle şu mantıkla ilerler: Önce en belirleyici kriteri — stratejik farklılaşmayı — sorun. Yetenek sizi farklılaştırmıyorsa ve standartsa, cevap büyük olasılıkla buy'dır; kaynağınızı başka yere ayırın. Yetenek sizi farklılaştırıyorsa, ikinci soruyu sorun: hazır bileşenlerle bu farklılaşmayı kurabilir misiniz? Kurabiliyorsanız cevap assemble'dır (çoğu durumda böyledir). Ancak yetenek son derece özgünse, hiçbir hazır bileşen yetmiyorsa ve veri egemenliği mutlaksa, cevap build'dir. Bu üç dallı ağaç, kararların çoğunu isabetli biçimde yönlendirir.

Build buy assemble karar ağacı (sıralı sorular)

Adım	Soru	Evet ise	Hayır ise
1	Yetenek sizi farklılaştırıyor mu?	2. adıma geç	BUY (satın al)
2	Hazır bileşenlerle kurulabilir mi?	ASSEMBLE (birleştir)	3. adıma geç
3	Veri egemenliği + yetenek + bütçe var mı?	BUILD (geliştir)	ASSEMBLE'a geri dön / kapsamı daralt
4	Karar veri hassasiyetiyle çelişiyor mu?	Build/Assemble'a kaydır	Kararı koru

Karar matrisi ise daha nicel bir araçtır: yedi kriteri kurumunuza göre ağırlıklandırır (örneğin veri hassasiyeti yüksek bir bankada "veri egemenliği" ağırlığı büyük olur), her seçeneği (build/buy/assemble) her kriterde 1-5 arası puanlar ve ağırlıklı toplamı hesaplarsınız. En yüksek puanı alan yaklaşım, o özel yetenek için doğru yönü gösterir. Matrisin değeri, çıkan sayıdan çok, sizi her kriteri açıkça düşünmeye ve varsayımlarınızı yazılı hâle getirmeye zorlamasıdır.

Örnek karar matrisi yapısı (illüstratif ağırlık ve puanlar)

Kriter (ağırlık)	Build	Buy	Assemble
Stratejik farklılaşma (×3)	5	1	4
TCO (×2)	2	4	4
Hız (×2)	1	5	4
Kontrol (×2)	5	2	4
Veri egemenliği (×3)	5	2	4
Ağırlıklı toplam (illüstratif)	Yüksek kontrol/farklılaşma	Yüksek hız/düşük maliyet	En dengeli

Toplam sahip olma maliyeti (TCO), build buy assemble kararının en sık yanlış hesaplanan boyutudur çünkü her üç yaklaşımın maliyet profili zaman içinde farklı davranır. Kararı "bugün hangisi ucuz?" diye vermek, en yaygın ve en pahalı hatadır; doğru soru "çözümün ömrü boyunca hangisi daha düşük toplam maliyet üretir?" olmalıdır.

Buy'ın maliyet profili: düşük başlangıç, öngörülebilir ama ölçekle büyüyen abonelik. İlk yıl ucuz görünür; ama kullanım ve kullanıcı sayısı arttıkça abonelik ücretleri doğrusal (bazen üstel) büyür. Ayrıca çıkış maliyeti gizlidir: satıcıdan ayrılmak, veri taşıma ve yeniden entegrasyon maliyeti getirir. Buy'ın TCO'sunu hesaplarken, bugünkü fiyatı değil, ölçeklendiğinizdeki fiyatı ve olası çıkış maliyetini projekte etmek gerekir.

Build'in maliyet profili: yüksek başlangıç, düşük değişken. Geliştirme ve entegrasyon ağır bir ilk yatırım gerektirir; ama çözüm ayağa kalktıktan sonra, ölçekte birim maliyet düşük olabilir. Ancak build'in gizli maliyeti bakımdır: çözümü sürdürecek ekibin sürekli maliyeti, çoğu build TCO hesabında eksik kalır. Bir modeli üretimde tutmak — izleme, güncelleme, güvenlik — kalıcı bir operasyon giderdir.

Assemble'ın maliyet profili: orta başlangıç, orta değişken. Hazır bileşenleri satın aldığınız için build kadar ağır bir başlangıç yatırımı yapmazsınız; ama birleştirme ve entegrasyon emeği bir maliyettir. Değişken tarafta, kullandığınız API'lerin tüketim ücretleri ve barındırdığınız açık kaynak bileşenlerin altyapı maliyeti vardır. Assemble genellikle en dengeli TCO profilini sunar: buy kadar hızlı başlar, build kadar kontrollü ölçeklenir.

Üç yaklaşımın TCO profili (kavramsal, illüstratif)

Maliyet boyutu	Build	Buy	Assemble
Başlangıç maliyeti	Yüksek	Düşük	Orta
Ölçekte değişken maliyet	Düşük	Yüksek (abonelik)	Orta (API+altyapı)
Bakım/operasyon	Tamamı kurumda	Satıcıda	Paylaşılmış
Çıkış/geçiş maliyeti	Düşük (kontrol sizde)	Yüksek (lock-in)	Yönetilebilir
Gizli maliyet riski	Bakım eksik hesaplanır	Ölçek+çıkış eksik hesaplanır	Entegrasyon eksik hesaplanır

Türkiye bağlamında TCO hesabına bir de yüksek benimseme boyutu eklenir. We Are Social'ın "Digital 2026" verisine göre Türkiye, üretken yapay zeka araçlarından web'e yönlendirilen trafik payında dünya birincisidir; bu yüksek benimseme, doğru kurgulanmış AI projelerinin Türkiye'de hızla değer üretebileceğini gösterir. Ancak yüksek kullanım aynı zamanda ölçek maliyetini de büyütür — bu da build buy assemble kararında TCO'yu daha da kritik yapar.

Birkaç yıl öncesine kadar kurumsal AI kararı büyük ölçüde ikili bir seçimdi: ya pahalı ve yavaş bir build, ya da kontrolsüz bir buy. Bugün ise assemble — yani hibrit mimari — çoğu kurum için varsayılan yaklaşım hâline geldi. Bu değişimin arkasında somut nedenler var ve bunları anlamak, kararınızı bugünün gerçekliğine göre vermenizi sağlar.

Birinci neden, hazır bileşenlerin olgunlaşmasıdır. Güçlü API tabanlı modeller, kaliteli açık kaynak modeller, hazır vektör veritabanları, orkestrasyon çerçeveleri ve model-araç bağlantı protokolleri (MCP gibi) artık her kurumun erişimine açık. Bu ekosistemde "zeka" bir meta hâline geldi: onu sıfırdan üretmek (build) çoğu kurum için hem gereksiz hem irrasyonel. Assemble, bu hazır zekayı alıp kurumun kendi katmanını eklemesine izin verir.

İkinci neden, farklılaşmanın yerinin değişmesidir. Artık rekabet avantajı modelin kendisinden değil, modeli nasıl kullandığınızdan — hangi veriyle beslediğinizden, hangi iş sürecine oturttuğunuzdan, nasıl bir kullanıcı deneyimi kurduğunuzdan — geliyor. Herkes aynı temel modele erişebildiği için, farklılaşma "assemble katmanında" yoğunlaşıyor. Bu, stratejik farklılaşmayı build etmek isteyen kurumların bile temel modeli assemble etmesini mantıklı kılıyor.

Üçüncü neden, satıcı bağımlılığından kaçınma ihtiyacıdır. Her şeyi tek bir satıcıdan almak (saf buy) derin bir bağımlılık yaratır; sıfırdan geliştirmek (saf build) ise maliyetlidir. Assemble, doğru kurulduğunda ikisinin de tuzağından kaçar: bileşenleri modüler tutarak bir sağlayıcıdan diğerine geçebilir, hem hızlı hem taşınabilir kalırsınız. Açık kaynak modellerin bu esnekliğe katkısını açık kaynak LLM nedir yazısında ele alıyoruz.

Dördüncü neden, riskin bölünebilmesidir. Assemble, büyük bir "her şeyi build" veya "her şeyi buy" bahsi yerine, kararı yetenek yetenek bölmenize izin verir: bir bileşeni satın alırsınız, birini birleştirirsiniz, gerçekten kritik olan dar bir kısmı build edersiniz. Bu modülerlik, riski dağıtır ve bir bileşen yanlış giderse tüm sistemi değil, yalnızca o parçayı değiştirmenizi sağlar. İşte bu esneklik, assemble'ı bugünün kurumsal normunun merkezine yerleştiriyor.

Beşinci neden ise hızın ve kalitenin birlikte elde edilebilmesidir. Geçmişte hız (buy) ile kalite/kontrol (build) arasında keskin bir ödünleşim vardı; assemble bu ödünleşimi büyük ölçüde yumuşattı. Hazır bileşenler o kadar olgunlaştı ki, bir kurum artık haftalar içinde hem hızlı hem de kendi verisiyle farklılaşmış bir çözüm kurabiliyor. Bu, "ya hızlı ama sıradan, ya iyi ama yavaş" ikilemini "hem hızlı hem farklılaşmış" seçeneğine dönüştürdü. Assemble'ın bugünün normu olmasının en pratik nedeni belki de budur: eski ödünleşimleri geçersiz kıldı ve kurumlara daha önce imkânsız görünen bir dengeyi sundu.

Satıcı bağımlılığı (vendor lock-in), bir kurumun belirli bir satıcının ürününe, API'sine veya ekosistemine öyle bağlanmasıdır ki, başka bir sağlayıcıya geçmenin maliyeti — teknik, finansal ve operasyonel — caydırıcı hâle gelir. Build buy assemble kararında satıcı bağımlılığı, çoğu zaman yalnızca fiyatla ölçülen bir riskten çok daha derindir; stratejik esnekliğinizi doğrudan etkiler.

AI'da satıcı bağımlılığı özellikle sinsi bir risktir çünkü bağımlılık birden fazla katmanda birikir. Model katmanında, promptlarınız ve ince ayarlarınız belirli bir modele göre optimize edilmiş olabilir. Veri katmanında, verileriniz satıcıya özel bir formatta saklanıyor olabilir. Entegrasyon katmanında, sistemleriniz satıcının API'sine göre yazılmış olabilir. Bu katmanlar biriktiğinde, "başka bir sağlayıcıya geçelim" kararı, teoride kolay ama pratikte neredeyse imkânsız hâle gelir.

Satıcı bağımlılığının bir de finansal boyutu vardır: bir satıcıya derinlemesine bağlandığınızda, o satıcının fiyat artışlarına karşı pazarlık gücünüz azalır. Başka bir seçeneğiniz olmadığını bilen bir sağlayıcı, sözleşme yenileme dönemlerinde fiyatı yükseltebilir ve siz, geçiş maliyeti çok yüksek olduğu için bunu kabul etmek zorunda kalabilirsiniz. Bu "esir müşteri" dinamiği, satıcı bağımlılığının en pahalı yüzüdür ve genellikle karar anında değil, yıllar sonra fatura olarak görünür. Bu yüzden satıcı bağımlılığını yalnızca teknik bir geçiş zorluğu değil, uzun vadeli bir pazarlık gücü kaybı olarak da değerlendirmek gerekir. Assemble mimarisinin modülerliği, tam da bu pazarlık gücünü korur: her zaman "gerekirse geçebilirim" diyebilmek, en iyi fiyat kaldıracıdır.

Satın al mı geliştir mi kararında bu risk şöyle işler: saf buy en yüksek satıcı bağımlılığını taşır çünkü çözümün her katmanı satıcıya aittir. Build en düşük bağımlılığı taşır çünkü kontrol sizdedir. Assemble ise ikisinin arasındadır ama burada kritik bir nüans vardır: assemble'ı yanlış kurmak, "hibrit" görünen ama aslında derin bağımlılık taşıyan bir mimariye yol açabilir. Örneğin tek bir satıcının hem modelini, hem orkestrasyonunu, hem de veri katmanını kullanırsanız, mimariniz kağıt üzerinde assemble olsa da pratikte buy kadar bağımlıdır.

Satıcı Bağımlılığını Azaltmanın Yolları

Satıcı bağımlılığını azaltmak, mimari bir karardan çok bir disiplin meselesidir. Birinci yol soyutlama katmanıdır: modeli koddan ayıran bir ara katman kurarsanız, model sağlayıcıyı değiştirmek tüm sistemi değil, yalnızca o katmanı etkiler. İkinci yol açık standartlardır: satıcıya özel formatlar yerine açık, taşınabilir standartları tercih etmek geçişi kolaylaştırır. Üçüncü yol veri taşınabilirliğidir: verilerinizin her zaman dışa aktarılabilir ve taşınabilir kalmasını sağlamak. Dördüncü yol çoklu-satıcı stratejisidir: kritik bileşenlerde tek bir sağlayıcıya bağlı kalmamak.

Satıcı bağımlılığı riski ve azaltma yolları

Yaklaşım	Bağımlılık düzeyi	Azaltma yolu
Buy (saf)	En yüksek	Çıkış planı + veri taşınabilirliği sözleşmede
Assemble (kötü kurulmuş)	Yüksek (gizli)	Soyutlama katmanı + modülerlik
Assemble (iyi kurulmuş)	Yönetilebilir	Çoklu-satıcı + açık standart
Build	En düşük	Kontrol zaten sizde; bakım maliyeti riski

Build buy assemble kararı finansal ve stratejik bir egzersiz gibi görünse de, Türkiye ve Avrupa bağlamında bir de uyum ve veri egemenliği boyutu vardır — ve bu boyut, veri hassasiyeti yüksek senaryolarda kararı doğrudan yönlendirir. Kararı verirken KVKK'yı sonradan düşünmek, en pahalı hatalardan biridir.

KVKK (Kişisel Verilerin Korunması Kanunu), kişisel verinin işlenmesine, saklanmasına ve aktarılmasına dair yükümlülükler getirir. Bir AI çözümü kişisel veri işliyorsa, verinin nerede işlendiği ve nereye aktarıldığı kritik hâle gelir. Hazır bir SaaS ürünü (buy) veriyi yurt dışındaki sunuculara gönderiyorsa, bu yurt dışı aktarım KVKK açısından ek yükümlülükler ve risk doğurabilir. Bu durumda karar, veriyi kurum sınırları içinde tutan build veya assemble yönüne kayar. KVKK yükümlülüklerini KVKK nedir yazısında ayrıntılı ele alıyoruz.

Veri egemenliği (data sovereignty), verinin hangi ülkenin hukuk düzenine tabi olduğu meselesidir. Kritik kurumsal veri veya düzenlenmiş sektör verisi (finans, sağlık) söz konusuysa, verinin ülke sınırları içinde ve kurum kontrolünde kalması stratejik ve yasal bir gereklilik olabilir. Bu senaryolarda, açık kaynak bir modeli kendi altyapınızda barındırmak (build/assemble) çoğu zaman tek uyumlu yoldur. Bu ödünleşimi bankacılık bağlamında self-hosted LLM vs API (KVKK/BDDK) yazısında somutlaştırıyoruz.

Burada dikkat edilmesi gereken bir nüans, "veri hassasiyeti hep en yüksek kısıtı dayatır" yanılgısıdır. Gerçekte bir kurumun işlediği verilerin hepsi aynı hassasiyette değildir; bir kısmı kamuya açık veya düşük hassasiyetli, bir kısmı ise kritik olabilir. Doğru yaklaşım, tüm veriyi en katı kısıta tabi tutmak yerine, veriyi hassasiyet seviyelerine ayırmak ve her seviye için uygun yaklaşımı seçmektir. Düşük hassasiyetli veri için hazır bir buy çözümü kullanılabilirken, yüksek hassasiyetli veri için self-hosted bir build/assemble mimarisi gerekebilir. Bu katmanlı yaklaşım, hem uyumu sağlar hem de her şeyi gereksiz yere en pahalı yola sokmaktan kaçınır. Veri sınıflandırması, bu yüzden build buy assemble kararının pratik bir ön adımıdır.

Avrupa'ya ürün veya hizmet sunan Türk kurumları için ek bir boyut EU AI Act'tir. Avrupa Yapay Zeka Yasası, AI sistemlerini risk seviyelerine göre sınıflandırır ve yüksek riskli sistemlere ciddi yükümlülükler getirir. Yüksek riskli bir kullanım senaryosunda, satın aldığınız hazır bir ürünün bu yükümlülükleri karşılayıp karşılamadığı sizin sorumluluğunuzdadır; bu da bazen daha fazla kontrol sağlayan build/assemble'ı zorunlu kılar. Yasanın kapsamını EU AI Act nedir yazısında ele alıyoruz. Uyum ve yönetişimi bütünsel kurmak için ise AI governance nedir yazısı çerçeve sunar.

Çerçeveyi soyut kalmaktan çıkarmak için, farklı yeteneklerin farklı yaklaşımları nasıl işaret ettiğini örneklerle görelim. Aşağıdaki senaryolar illüstratiftir; amaç rakam vermek değil, kriterlerin gerçek durumlarda nasıl işlediğini göstermektir.

Senaryo 1: Standart Toplantı Özetleme — Buy

Bir kurum, toplantı kayıtlarını otomatik özetlemek istiyor. Bu yetenek standarttır, kurumu rakiplerinden farklılaştırmaz ve piyasada olgun hazır ürünler mevcuttur. Veri hassasiyeti yönetilebilir düzeydeyse (örneğin toplantılar kritik kişisel veri içermiyorsa), doğru karar buy'dır: hazır bir araç al, hızlıca devreye gir, mühendislik kapasiteni farklılaştırıcı işlere ayır. Bunu build etmek, kaynak israfı olur.

Senaryo 2: Kuruma Özel Bilgi Erişimi — Assemble

Bir kurum, binlerce sayfalık iç dokümantasyonuna çalışanların doğal dilde soru sormasını ve kaynak gösterilmiş cevaplar almasını istiyor. Bu yetenek kurumu farklılaştırır (çünkü bilgi kuruma özeldir) ama temel model hazır alınabilir. Doğru karar assemble'dır: hazır bir dil modeli + hazır bir vektör veritabanı + kurumun kendi belgeleri ile bir RAG sistemi kurulur. Farklılaşma, modelin kendisinden değil, kurumun verisinden ve birleştirme biçiminden gelir. Bu, bugünün en yaygın kurumsal AI kalıbıdır.

Senaryo 3: Çekirdek Ürünün AI Motoru — Build (veya Ağırlıklı Assemble)

Bir yapay zeka girişimi için modelin kendisi ürünse — yani rekabet avantajının doğrudan kaynağı, herkeste olmayan özel bir AI yeteneğiyse — o zaman build (veya en azından çok ağır bir assemble, örneğin açık kaynak bir modeli kendi verinizle derinlemesine ince ayarlamak) mantıklıdır. Burada yeteneği satın almak, ürünü satın almak demektir; bu da işin kendisini dışarı vermek olur. Veri egemenliği ve tam kontrol mutlaksa, build kaçınılmaz olabilir.

Senaryo 4: Hassas Finansal Veri Üzerinde Analiz — Build/Assemble (Self-Hosted)

Bir banka, hassas müşteri finansal verisi üzerinde AI analizi yapmak istiyor. Veri egemenliği ve düzenleyici yükümlülükler (KVKK, BDDK) nedeniyle veri yurt dışı bir SaaS'a gönderilemez. Bu senaryoda buy baştan elenir; doğru karar, açık kaynak bir modeli kurum altyapısında barındıran bir build/assemble mimarisidir. Veri kurum sınırları içinde kalır, uyum sağlanır ve kontrol korunur.

Senaryo 5: Aynı Yeteneğin İki Farklı Kurumda Farklı Kararı

Aynı yeteneğin farklı kurumlarda nasıl farklı kararlara yol açtığını görmek, çerçevenin gücünü ortaya koyar. Örneğin "müşteri e-postalarını otomatik sınıflandırma ve yanıtlama" yeteneğini düşünelim. Küçük bir e-ticaret şirketi için bu yetenek standarttır ve hassas veri içermez; doğru karar buy'dır. Ancak büyük bir sigorta şirketi için aynı yetenek, hassas kişisel veri (sağlık, finans) işler ve şirketin müşteri ilişkileri stratejisinin merkezindedir; bu durumda karar assemble veya build'e kayar. Yetenek aynı, ama stratejik değer, veri hassasiyeti ve ölçek farklı olduğu için karar da farklıdır. Bu, build buy assemble kararının neden "yeteneğe" değil, "yetenek + kurum bağlamı" ikilisine bağlı olduğunu gösterir.

Bu beş senaryonun ortak dersi şudur: doğru yaklaşım yeteneğin adından değil, o yeteneğin kurum için taşıdığı stratejik değerden, işlediği verinin hassasiyetinden ve kurumun yeteneğinden doğar. Bir danışman olarak sıkça gördüğüm hata, kurumların "başkası bunu build etmiş, biz de build edelim" veya "herkes bunu satın alıyor, biz de alalım" mantığıyla karar vermesidir. Oysa doğru karar, taklitle değil, kendi bağlamınızın dürüst analiziyle verilir. Aynı yetenek, sizin kurumunuzda başka bir kurumdakinden farklı bir karara yol açabilir — ve bu gayet normaldir.

Örnek senaryolar ve işaret ettikleri yaklaşım

Senaryo	Belirleyici kriter	Doğru yaklaşım
Toplantı özetleme	Standart, farklılaştırmaz	Buy
Kuruma özel bilgi erişimi	Veri farklılaştırıcı, model hazır	Assemble (RAG)
Çekirdek ürün motoru	Yetenek = rekabet avantajı	Build / ağır Assemble
Hassas finansal analiz	Veri egemenliği mutlak	Build/Assemble (self-hosted)

Aşağıdaki kontrol listesi, bir build buy assemble kararını baştan sona sağlıklı yürütmek için pratik bir rehberdir. Her maddeyi dürüstçe yanıtlayabiliyorsanız, kararınız savunulabilir demektir.

Nasıl Yapılır

Build buy assemble karar kontrol listesi

Bir AI yeteneği için build, buy veya assemble kararını baştan sona sağlam vermek için adım adım kontrol listesi.

1. 1

   Yeteneği net tanımla

   Geniş 'AI' yerine tek, somut bir yetenek/kullanım senaryosu tanımla.

2. 2

   Farklılaşma testini yap

   Bu yetenek beni rakiplerimden ayırıyor mu, yoksa standart mı? Dürüstçe yanıtla.

3. 3

   Veri hassasiyetini değerlendir

   İşlenen veri KVKK/egemenlik açısından hassas mı? Hassassa buy'ı ele.

4. 4

   TCO'yu çok yıllı hesapla

   Lisans/geliştirmenin ötesinde entegrasyon, insan, bakım ve çıkış maliyetini de topla.

5. 5

   Yetenek ve hız gerçeğini tart

   Bu yolu yürütecek ekibim var mı ve ne kadar hızlı ihtiyacım var?

6. 6

   Satıcı bağımlılığını planla

   Çıkış maliyeti, soyutlama katmanı ve veri taşınabilirliğini baştan kurgula.

7. 7

   Karar matrisini doldur

   Yedi kriteri ağırlıklandır, üç seçeneği puanla ve varsayımları yazılı hale getir.

8. 8

   Pilotla başla

   Kararı küçük, ölçülebilir bir pilotla test et; koşullar değişince yeniden gözden geçir.

Bu kontrol listesini bir pilot yetenek üzerinde uygulamak, tüm kurumu tek bir büyük kararla dönüştürmeye kalkışmaktan çok daha akıllıcadır. Küçük ve ölçülebilir bir başlangıç, hem doğru yaklaşımı test etmenizi hem de kurumun olgunluğunu artırmanızı sağlar. Kurumsal AI yatırımını bir bütün olarak planlamak için kurumsal AI bütçesi planlama yazısına, olgunluk seviyenizi görmek içinse kurumsal AI olgunluk modeli yazısına bakabilirsiniz.

Kontrol listesindeki maddelerin sırası da anlamlıdır. Farklılaşma testi ve veri hassasiyeti değerlendirmesi başta gelir çünkü bunlar seçenekleri eleyen filtrelerdir: farklılaştırmayan bir yetenekte build'i baştan eleyebilir, hassas veride buy'ı baştan çıkarabilirsiniz. TCO, yetenek ve hız değerlendirmeleri ortada gelir çünkü bunlar kalan seçenekler arasında tartıyı yapar. Satıcı bağımlılığı planı ve karar matrisi sona gelir çünkü bunlar kararı sağlamlaştırır ve belgeler. Bu sıra, kararı hem hızlandırır (erken elemeler) hem de sağlamlaştırır (geç doğrulamalar). Listeyi sırayla uygulamak, "önce karar ver, sonra gerekçe bul" tuzağından — ki bu en yaygın karar hatasıdır — kaçınmanızı sağlar.

Son olarak, kontrol listesinin çıktısı bir belge olmalıdır: hangi yaklaşımı neden seçtiğinizi, hangi varsayımlara dayandığınızı ve hangi koşullar değişirse kararı gözden geçireceğinizi yazan kısa bir karar notu. Bu belge iki işe yarar: birincisi, kararı örgüt içinde savunulabilir ve şeffaf kılar; ikincisi, gelecekte koşullar değiştiğinde "o zaman neden böyle karar vermiştik?" sorusuna cevap verir. Yazılı olmayan bir build buy assemble kararı, zamanla kurumsal hafızadan silinir ve kimse onu gözden geçirmez; yazılı bir karar ise yönetilebilir bir varlığa dönüşür.

Deneyimli bir gözle bakıldığında, çoğu build buy assemble kararı benzer hatalarla bozulur. Bu hataları önceden bilmek, kararınızı bu tuzaklardan korumanın en pratik yoludur.

• Her şeyi kendi geliştirmeye kalkmak: "Kontrol bizde olsun" hevesiyle farklılaştırmayan standart yetenekleri bile build etmek, sınırlı mühendislik kapasitesini ve bütçeyi israf eder. Build edilecek olan, yalnızca gerçekten farklılaştırıcı olan yetenektir.
• Farklılaştırıcı yeteneği satın alıp emanet etmek: Rekabet avantajınızın kaynağı olan bir yeteneği buy ile bir satıcıya devretmek, aynı ürünü rakipleriniz de alabileceği için avantajınızı buharlaştırır.
• TCO'yu yalnızca lisans/geliştirme ücretiyle ölçmek: Entegrasyon, insan, bakım ve çıkış maliyetini atlamak, en yaygın maliyet hatasıdır ve kararı sistematik olarak yanlış yönlendirir.
• Satıcı bağımlılığını görmezden gelmek: "Şimdilik çalışıyor" diye çıkış maliyetini düşünmemek, ilerde geçiş gerektiğinde caydırıcı bir lock-in olarak geri döner.
• KVKK ve veri egemenliğini karar sonrası düşünmek: Uyumu sonradan eklemek, çoğu zaman kararı baştan yanlış yapar; veri hassasiyeti en erken sorulacak sorulardan olmalıdır.
• Kararı bir kez verip sabit sanmak: Build buy assemble kararı koşullara bağlıdır; teknoloji, maliyet ve ihtiyaçlar değiştikçe yeniden gözden geçirilmelidir. Bugün doğru olan buy, yarın assemble'a; bugünkü assemble, yarın build'e evrilebilir.
• "Assemble" adını bağımsızlık sanmak: Tek bir satıcının tüm katmanlarını kullanan bir mimariye "hibrit" demek, gerçek bağımlılığı gizler. Assemble'ın değeri, adında değil, içindeki modülerlik ve soyutlama disiplinindedir.

Bu hatalardan kaçınmanın en pratik yolu, kararı bağımsız bir gözle gözden geçirmektir. Bir yapay zeka danışmanının katma değeri tam da buradadır: projeye duygusal olarak bağlı olmayan, çerçeveyi bilen bir gözün varsayımları sınaması. Danışmanlığın kapsamını ve fiyatlandırmasını yapay zeka danışmanlığı fiyatları yazısında ele alıyoruz.

Build buy assemble kararında en çok teorik kalan ama pratikte en belirleyici kriterlerden biri yetenektir. Bir kurum, kağıt üzerinde build'in en yüksek kontrolü ve farklılaşmayı sunduğunu görüp bu yönde karar verebilir; ama o kararı hayata geçirecek mühendislik ve veri bilimi yetkinliği yoksa, karar kâğıt üzerinde parlak, pratikte başarısız kalır. Bu yüzden yetenek, kararı hayalden gerçeğe indiren süzgeçtir; "yapabilir miyiz?" sorusu, "yapmalı mıyız?" sorusu kadar önemlidir.

Yetenek boyutunun üç katmanı vardır. Birincisi teknik yetkinlik: modeli seçme, entegre etme, ince ayarlama, izleme ve sürdürme becerisi. Build bu yetkinliğin en derinini ister; assemble ılımlı bir düzeyi; buy neredeyse hiç. İkincisi ürün ve süreç yetkinliği: AI'ı bir iş sürecine oturtma, kullanıcı deneyimini kurma ve benimsemeyi yönetme becerisi. Bu yetkinlik özellikle assemble'da kritiktir çünkü assemble'ın farklılaşması tam da bu katmanda doğar. Üçüncüsü yönetişim yetkinliği: kararı doğru verme, riski yönetme ve uyumu sağlama becerisi.

Kurumların en sık düştüğü tuzak, teknik yetkinliği abartıp ürün ve yönetişim yetkinliğini hafife almaktır. Güçlü bir mühendislik ekibi olan bir kurum bile, AI'ı iş süreçlerine oturtamıyorsa veya kararı stratejiyle hizalayamıyorsa, build veya assemble yatırımından beklenen değeri alamaz. Bu yüzden yetenek değerlendirmesi yalnızca "kaç mühendisimiz var?" değil, "bu yeteneği uçtan uca yürütecek bütünsel kapasitemiz var mı?" sorusuyla yapılmalıdır. Eksik olan yetkinlik satın alınabilir (danışmanlık, işe alım) veya geliştirilebilir (eğitim); ama bu da bir maliyettir ve TCO'ya girer.

Yetenek boyutu aynı zamanda kararın zaman içindeki evrimini de belirler. Bugün yeteneği olmayan bir kurum, ilk projelerini buy veya hafif assemble ile yürütüp yetkinlik biriktirdikçe, sonraki projelerde daha ağır assemble veya seçili build'e geçebilir. Bu, kararı statik değil dinamik yapar: kurum olgunlaştıkça build buy assemble dengesi kayar. Ekiplerin AI yetkinliğini geliştirmek, bu evrimi hızlandıran en doğrudan yatırımdır; kurumsal eğitim ve öğrenme merkezi bu kapasiteyi kurmanın pratik yollarıdır.

Bir build buy assemble kararının doğruluğu, yalnızca çerçeveye değil, onu kimin verdiğine de bağlıdır. Uygulamada sık görülen bir sorun, kararı tek bir tarafın — genellikle teknoloji ekibinin veya projeyi savunan bir sponsorun — tek başına vermesidir. Teknoloji ekibi doğal olarak build'e meyleder (ilginç bir mühendislik problemi); bir iş birimi doğal olarak buy'a meyleder (hızlı sonuç); her taraf kendi çıkarına yakın bir yaklaşımı savunur. Sonuç, çerçevenin değil, örgüt içi dengelerin belirlediği bir karardır.

Sağlam bir yönetişim, build buy assemble kararına en az üç bakış açısını dahil eder. İş birimi, yeteneğin stratejik değerini ve gerçek ihtiyacı bilir: "bu yetenek bizi gerçekten farklılaştırıyor mu?" Teknoloji ekibi, uygulanabilirliği ve teknik ödünleşimleri bilir: "hazır bileşenlerle kurulabilir mi, bakım yükü ne olur?" Finans ve risk, TCO'yu, satıcı bağımlılığını ve uyumu bilir: "üç yıllık maliyet ne, çıkış maliyeti ne, KVKK riski ne?" Bu üç bakış açısı bir masada buluştuğunda, karar hem daha doğru hem de örgüt içinde daha kabul edilebilir olur.

Kararın sahipliği de en az kararın kendisi kadar önemlidir. Bir build buy assemble kararı bir kez verilip rafa kaldırılırsa, koşullar değiştiğinde kimse onu gözden geçirmez ve zamanla yanlış bir karara dönüşür. Sağlıklı bir modelde, her önemli AI yeteneğinin bir "karar sahibi" vardır: kararı veren, gerçekleşmesini izleyen ve koşullar değiştiğinde yeniden değerlendirmekten sorumlu bir kişi veya ekip. Bu sorumluluk, kararı kağıt üzerinde bir tercihten, yönetilen bir stratejik varlığa dönüştürür. Kararı kurumsal bir yönetişim çerçevesine oturtmak için AI governance nedir yazısı yol gösterir.

Build buy assemble kararının en sık gözden kaçan gerçeği, onun bir kerelik bir seçim değil, sürekli gözden geçirilmesi gereken dinamik bir karar olmasıdır. Bugün doğru olan bir karar, teknoloji, maliyet, yetenek ve rekabet değiştikçe yarın yanlış hale gelebilir. Kararı "bir kez ver ve unut" muamelesi görmek, zamanla kurumu ya modası geçmiş bir çözüme ya da gereksiz bir bağımlılığa hapseder.

Kararın evrimi genellikle şu kalıbı izler. Erken aşamada, kurum henüz yetenek biriktirmemişken, çoğu yetenek için buy veya hafif assemble mantıklıdır: hızlı değer, düşük risk, öğrenme. Kurum olgunlaştıkça ve hangi yeteneklerin gerçekten farklılaştırıcı olduğu netleştikçe, bu farklılaştırıcı yetenekler için karar daha ağır assemble'a veya seçili build'e kayar. Yani doğal bir evrim vardır: buy ile başla, öğren, sonra farklılaştırıcı yerlerde assemble/build'e derinleş. Bu evrim, kurumsal AI olgunluğuyla doğrudan ilişkilidir; olgunluk seviyenizi kurumsal AI olgunluk modeli yazısında değerlendirebilirsiniz.

Kararı tetikleyen değişimler önceden izlenebilir. Bir satıcının fiyatını ölçekte katladığında, buy'ın TCO'su bozulur ve assemble daha cazip hale gelir. Yeni ve olgun bir açık kaynak model çıktığında, daha önce mantıksız olan bir assemble mümkün olur. Düzenleme değiştiğinde (örneğin yeni bir veri egemenliği yükümlülüğü), buy elenip build/assemble zorunlu hale gelebilir. Bu tetikleyicileri düzenli izlemek, kararı zamanında güncellemenizi sağlar. Bu yüzden olgun kurumlar, build buy assemble kararlarını periyodik olarak (örneğin yıllık) gözden geçiren bir ritim kurar.

Bu dinamizm, aynı zamanda "geri dönülemez" kararlardan kaçınmayı da gerektirir. Bir kararı verirken, gelecekte onu değiştirmenin maliyetini de düşünmelisiniz: bir buy kararı sizi öyle bir bağımlılığa sokuyor ki gelecekte assemble'a geçmek imkânsız hale geliyorsa, o buy kararı göründüğünden pahalıdır. Doğru yaklaşım, kararı bugünkü koşullara göre vermek ama mimariyi gelecekteki değişime açık (modüler, taşınabilir) tutmaktır. Böylece koşullar değiştiğinde, kararı da değiştirebilirsiniz.

Build buy assemble çerçevesini kurumsal düzeyde uygularken en güçlü zihinsel model, onu bir "portföy" olarak görmektir. Bir kurumun tek bir AI kararı yoktur; onlarca yeteneğin her biri için ayrı bir build/buy/assemble kararı vardır. Bu kararları tek tek, yeteneğin stratejik değerine göre vermek; ve tüm portföyü bir bütün olarak dengelemek, olgun bir AI stratejisinin işaretidir.

Portföy yaklaşımının temel içgörüsü şudur: aynı kurum, farklı yetenekler için farklı yaklaşımlar seçmelidir. Standart, farklılaştırmayan yeteneklerin çoğunu buy eder; birkaç farklılaştırıcı yeteneği assemble eder; ve belki bir tek çekirdek yeteneği build eder. Bu dağılım, kaynağı en yüksek stratejik getiriyi ürettiği yere yoğunlaştırır. Her şeyi build etmek kaynağı dağıtır; her şeyi buy etmek farklılaşmayı yok eder; doğru portföy ikisinin dengesidir.

Portföyü dengelerken iki soru yol gösterir. Birincisi: "Bu portföyde build/assemble'a ayırdığım kaynak, gerçekten farklılaştırıcı yeteneklere mi gidiyor, yoksa dağılmış mı?" İkincisi: "Buy ettiğim yetenekler arasında, aslında farklılaştırıcı olup dışarı verdiğim bir tane var mı?" Bu iki soru, portföyün hem verimli hem stratejik olmasını sağlar. Kurumsal AI bütçesini bu portföy mantığıyla dağıtmak için kurumsal AI bütçesi planlama yazısı, kaynağı önceliklendirmede pratik bir çerçeve sunar; genel strateji için ise kurumsal yapay zeka stratejisi yazısına bakabilirsiniz.

Portföy yaklaşımının bir başka faydası, riski dağıtmasıdır. Tek bir büyük "her şeyi build" bahsi, tek bir noktada büyük risk yoğunlaştırır; portföy ise riski onlarca küçük karara böler. Bir yetenekte yaptığınız yanlış karar (örneğin yanlış bir buy) tüm stratejinizi değil, yalnızca o yeteneği etkiler. Bu modülerlik, portföyü hem daha dayanıklı hem de daha öğrenebilir yapar: her karardan öğrenir, bir sonrakini daha iyi verirsiniz.

Portföy yaklaşımında yetenek türüne göre tipik karar

Yetenek türü	Tipik yaklaşım	Gerekçe
Standart destek/verimlilik araçları	Buy	Farklılaştırmaz, hız önemli
Kuruma özel bilgi/süreç	Assemble	Veri farklılaştırıcı, model hazır
Çekirdek rekabet avantajı	Build / ağır Assemble	Yetenek = stratejik kimlik
Hassas/düzenlenmiş veri	Build/Assemble (self-hosted)	Veri egemenliği zorunlu

Build buy assemble ne demek?

Build buy assemble, kurumsal bir AI yeteneğini elde etmenin üç temel yolunu tanımlar. Build, çözümü sıfırdan kendi ekibinizle geliştirmek; buy, hazır bir ürünü veya hizmeti (SaaS, kurumsal yazılım) satın almak; assemble ise mevcut bileşenleri — hazır modeller, API'ler, açık kaynak kütüphaneler, hazır araçlar — kendi verinizle ve iş mantığınızla birleştirerek bir çözüm kurmaktır. Assemble, saf build ile saf buy arasındaki üçüncü ve bugün en yaygın yoldur.

Satın al mı geliştir mi: hangisini seçmeliyim?

Satın al mı geliştir mi sorusunun tek bir doğru cevabı yoktur; karar yeteneğin stratejik değerine ve kurumun koşullarına bağlıdır. Genel kural şudur: bir yetenek sizi rakiplerinizden ayırıyorsa (stratejik farklılaşma) ve rekabet avantajınızın kaynağıysa geliştir (build); yetenek standartsa, herkeste aynıysa ve sizi farklılaştırmıyorsa satın al (buy). İkisinin arasında kalan çoğu durumda ise birleştir (assemble) en dengeli yoldur.

Assemble (birleştir) yaklaşımı neden bugünün normu oldu?

Assemble bugünün normu oldu çünkü olgun hazır bileşenler (güçlü API tabanlı modeller, kaliteli açık kaynak modeller, hazır vektör veritabanları, orkestrasyon araçları) her kurumun erişimine açıldı. Bu ekosistemde sıfırdan bir temel model geliştirmek çoğu kurum için mantıksız; her şeyi tek bir satıcıdan satın almak ise kontrol ve farklılaşma kaybettirir. Assemble, bu iki ucun arasında hız ile kontrolü dengeler ve hibrit mimari, bugünün varsayılan kurumsal yaklaşımıdır.

Toplam sahip olma maliyeti (TCO) build buy assemble kararını nasıl etkiler?

Toplam sahip olma maliyeti (TCO), bir çözümün ömrü boyunca doğrudan ve dolaylı tüm maliyetlerini kapsar ve build buy assemble kararının en sık yanlış hesaplanan boyutudur. Buy tarafında görünür maliyet düşük başlar ama ölçekte abonelik ücretleri büyür; build tarafında başlangıç maliyeti yüksektir ama ölçekte birim maliyet düşebilir; assemble ise ikisinin arasında bir profil çizer. TCO'yu yalnızca lisans veya API ücretiyle ölçmek en yaygın hatadır; entegrasyon, insan, bakım ve çıkış maliyetleri de hesaba katılmalıdır.

Satıcı bağımlılığı (vendor lock-in) nedir ve nasıl azaltılır?

Satıcı bağımlılığı (vendor lock-in), bir kurumun belirli bir satıcının ürününe, API'sine veya ekosistemine öyle bağlanması ki, başka bir sağlayıcıya geçmenin maliyeti caydırıcı hâle gelmesidir. AI'da bu risk özellikle yüksektir çünkü modeller, promptlar, veri formatları ve entegrasyonlar satıcıya özel olabilir. Riski azaltmanın yolları: soyutlama katmanı kullanmak, açık standartları tercih etmek, verinin taşınabilir kalmasını sağlamak ve mümkün olduğunda çoklu-satıcı stratejisi izlemektir.

KVKK ve veri egemenliği build buy assemble kararını nasıl değiştirir?

KVKK ve veri egemenliği, veri hassasiyeti yüksek senaryolarda kararı doğrudan etkiler. Kişisel veri veya kritik kurumsal veri işleniyorsa, verinin nerede işlendiği, saklandığı ve kimin eriştiği önem kazanır. Hazır bir SaaS ürünü (buy) veriyi yurt dışındaki bir sunucuya gönderiyorsa, bu KVKK ve egemenlik açısından risk oluşturabilir. Bu durumlarda karar build veya assemble yönüne kayar: açık kaynak bir modeli kendi altyapınızda barındırmak veya veriyi kurum sınırları içinde tutan bir hibrit mimari kurmak, uyum ve kontrol sağlar.

Küçük veya orta ölçekli bir kurum build buy assemble kararını nasıl vermeli?

Küçük ve orta ölçekli kurumlar için pratik kural, mümkün olduğunca satın almak (buy) ve yalnızca gerçekten farklılaştırıcı olan dar bir alanda birleştirmektir (assemble). Sıfırdan build, çoğu KOBİ için ne maliyet ne yetenek açısından mantıklıdır. Doğru yol genellikle şudur: standart ihtiyaçlar için hazır SaaS al, farklılaştırıcı bir kullanım senaryosu için hazır bir modeli kendi verinle birleştir ve tüm bunları küçük, ölçülebilir bir pilotla başlat.

Build ile assemble arasındaki fark tam olarak nedir?

Build, çözümün temel bileşenlerini de (örneğin bir temel modeli sıfırdan eğitmek, tüm altyapıyı özel yazmak) kendiniz üretmektir; en yüksek kontrol ama en yüksek maliyet ve süredir. Assemble ise temel bileşenleri (hazır modeller, API'ler, açık kaynak kütüphaneler) hazır alıp, bunları kendi verinizle, iş mantığınızla ve entegrasyonlarınızla birleştirerek özgün bir çözüm kurmaktır. Assemble'da zeka hazır gelir, farklılaşma birleştirme biçiminizden ve verinizden doğar. Pratikte modern kurumsal AI'ın büyük çoğunluğu saf build değil assemble'dır.

Hibrit mimari (assemble) satıcı bağımlılığını gerçekten azaltır mı?

Doğru kurulduğunda evet, ama otomatik değildir. Assemble/hibrit mimari, bileşenleri modüler tuttuğu ve aralarına soyutlama katmanları koyduğu için tek bir satıcıya tam bağımlılığı azaltabilir. Ancak assemble'ı yanlış kurmak mümkündür; örneğin tek bir satıcının hem modelini hem orkestrasyonunu hem de veri katmanını kullanırsanız, hibrit görünen bir mimari aslında derin bir bağımlılık taşıyabilir. Bağımlılığı azaltmanın anahtarı mimari değil, o mimarideki soyutlama ve taşınabilirlik disiplinidir.

Build buy assemble kararında en sık yapılan hatalar nelerdir?

En sık hatalar: her şeyi kendi geliştirmeye kalkmak; farklılaştırıcı, stratejik bir yeteneği satın alıp bir satıcıya emanet etmek; TCO'yu yalnızca lisans veya API ücretiyle ölçüp entegrasyon, bakım ve çıkış maliyetlerini atlamak; satıcı bağımlılığını görmezden gelmek; KVKK ve veri egemenliğini karar sonrası düşünmek; ve kararı bir kez verip sabit sanmak. Build buy assemble kararı, koşullar değiştikçe yeniden gözden geçirilmelidir.

Özetle build buy assemble kararının cevabı şudur: farklılaştırıcı ve stratejik yetenekleri build (geliştir), standart ve farklılaştırmayan yetenekleri buy (satın al), ikisinin arasında kalan çoğu durumu ise assemble (birleştir) ile çöz. Kararı tek bir kriterle değil; stratejik farklılaşma, toplam sahip olma maliyeti (TCO), hız, kontrol, veri egemenliği, yetenek ve bakım yükünü birlikte tartarak ver. Bugünün kurumsal pratiğinde çoğu başarılı çözüm, saf build veya saf buy değil, iyi tasarlanmış bir assemble — yani hibrit mimari — olarak sonuçlanır.

En önemli mesaj şudur: build buy assemble bir teknoloji değil, bir strateji kararıdır. Onu strateji masasında, farklılaşma testiyle başlatan; TCO'yu dürüstçe hesaplayan; satıcı bağımlılığını ve veri egemenliğini baştan planlayan kurumlar, AI kaynağını en yüksek getiriyi ürettiği yere yönlendirir.

Bu rehberde ele aldığımız çerçeveyi tek bir cümlede özetlemek gerekirse: farklılaştırmayan her şeyi mümkün olduğunca satın alın, farklılaştıran çoğu şeyi hazır bileşenlerle birleştirin ve yalnızca gerçekten çekirdek olan az sayıda yeteneği sıfırdan geliştirin. Bu üçlü denge, kaynağınızı en verimli, riskinizi en dağıtılmış ve farklılaşmanızı en korunaklı biçimde konumlandırır. Kararı bir kez verip unutmak yerine, koşullar değiştikçe yeniden gözden geçiren bir ritim kurmak ise, çerçeveyi statik bir tercihten dinamik bir stratejik yeteneğe dönüştürür. Nihayetinde build buy assemble, "hangi aracı seçelim?" sorusunun değil, "kurumumuzu hangi yeteneklerle tanımlamak istiyoruz?" sorusunun cevabıdır — ve bu, teknolojiden çok kimlikle ilgili bir karardır. Temel kavramlar için kurumsal yapay zeka stratejisi ve açık kaynak LLM nedir rehberlerine göz atabilir; kurumunuza özel bir build buy assemble analizi ve yol haritası için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin bu kararı yürütecek yetkinliği için kurumsal eğitim seçeneklerini inceleyebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.