Kurumsal AI'da Yap mı, Satın Al mı? 2026 İçin CTO/CDO Karar Çerçevesi

TL;DR — Kurumsal yapay zekâda "yap mı, satın al mı?" sorusu artık eski formunda anlamını yitirdi. LLM çağında modeli kendiniz nadiren eğitirsiniz; gerçek inşaat satın aldığınız modellerin üzerine kurduğunuz orkestrasyon, retrieval, guardrail ve entegrasyon katmanında gerçekleşir. 2026'da gerçekçi varsayılan ne saf "satın al" ne saf "yap"tır; satın alınan bileşenleri farklılaştırıcı bir sisteme dönüştüren Compose / Hibrit yaklaşımdır. Bu yazıda CTO ve CDO'lar için bir karar çerçevesi, puanlanabilir bir karar matrisi, gerçek bir TCO (toplam sahip olma maliyeti) iskeleti ve Türkiye bağlamına özgü (KVKK, veri ikametgâhı, döviz maliyeti, yetenek kıtlığı, EU AI Act yükümlülükleri) uyarıları paylaşıyorum. Amacım PoC'den üretime geçemeyen projeler mezarlığına bir tane daha eklememeniz.

Yıllardır kurumlarla çalışırken en sık karşılaştığım yanlış anlama şu: yöneticiler "yapay zekâ inşa etmek" dediğinde zihinlerinde hâlâ kendi modelini sıfırdan eğiten bir mühendislik ekibi canlanıyor. Oysa bugün gerçeklik bambaşka. Bir bankanın, bir perakendecinin ya da bir üretim firmasının kendi temel dil modelini (foundation model) sıfırdan eğitmesi neredeyse hiçbir durumda mantıklı değil. Bunun için gereken sermaye, GPU erişimi, veri ölçeği ve araştırma yetkinliği sadece bir avuç küresel oyuncunun elinde. Dolayısıyla "yap mı, satın al mı?" sorusunu modelin kendisi üzerinden tartışmak baştan yanlış zeminde durmak demek.

Doğru çerçeve şu: Modeli satın alırsınız; değeri üzerine inşa ettiğiniz katmanda yaratırsınız. Bu katman dört ana parçadan oluşur ve farklılaşmanın gerçekte gerçekleştiği yer burasıdır:

• Orkestrasyon: Hangi modelin, hangi adımda, hangi araçla, hangi prompt'la çağrılacağını yöneten mantık. Ajan (agent) mimarileri, çok adımlı akışlar, fallback stratejileri burada yaşar.
• Retrieval (bilgi getirme): Kurumun kendi verisini modele bağlayan RAG katmanı. Vektör veritabanları, indeksleme, chunking stratejisi, hibrit arama. Modelin "sizin işinizi" bilmesini sağlayan şey budur.
• Guardrail (koruma bantları): Girdi ve çıktı denetimi, PII maskeleme, halüsinasyon azaltma, politika uyumu, jailbreak savunması. Düzenlenmiş sektörlerde bu katman müzakere edilemez.
• Entegrasyon: Modelin kurumun gerçek sistemlerine (ERP, CRM, çağrı merkezi, ticket sistemi, veri ambarı) bağlanması. Değerin iş süreçlerine aktığı boru hattı.

Bu yeniden çerçevelemeyi içselleştirmeden alınan her karar yanlış soruya verilmiş doğru cevaptan ibaret kalır. Bir yöneticiye "GPT sınıfı bir modeli kendiniz mi eğiteceksiniz?" diye sorduğunuzda cevap neredeyse her zaman "hayır" olur. Ama asıl soru bu değildir. Asıl soru şudur: "Sizi rakiplerinizden ayıracak retrieval, orkestrasyon ve guardrail katmanını kim, nasıl, hangi maliyetle ve hangi kontrol seviyesiyle inşa edecek?" İşte build vs. buy tartışması 2026'da bu cümlenin etrafında döner.

Eski ikili (yap/satın al) ayrımı modern AI yığınında fazla kaba kaçıyor. Ben kurumlara her zaman üç yollu bir çerçeve öneriyorum çünkü gerçek kararlar bu üçünün arasında bir yerde duruyor.

Buy — SaaS copilot'lar ve nokta çözümler

Satın al yolu, hazır bir SaaS ürününü (bir kod copilot'u, bir müşteri hizmetleri botu, bir toplantı özetleyici, bir pazarlama metni aracı) lisanslayıp kullanmak demektir. Avantajları net: hızlı değer, düşük başlangıç eforu, sağlayıcının sürekli iyileştirdiği bir ürün, bakım yükünün dışarıda olması. Bir yetkinlik sizin için commodity ise, yani onu sizden iyi yapan onlarca firma varsa ve bu yetkinlik sizi rakiplerinizden ayırmıyorsa, satın almak neredeyse her zaman doğru karardır.

Buy'ın gizli maliyetleri ise genellikle göz ardı edilir: veri çıkışı (egress), vendor lock-in, fiyatlandırmanın koltuk (seat) başına büyümesi, sağlayıcının yol haritasına bağımlılık ve en kritiği — verinizin nereye gittiği. Düzenlenmiş bir sektördeyseniz, "satın al" kararının altında yatan veri akışını anlamadan imza atmak ileride çok pahalıya patlar.

Build — Tescilli veri üzerinde özel RAG ve ajanlar

Yap yolu, kurumun kendi tescilli verisi üzerinde özel RAG mimarileri, özel ajan akışları, hatta belirli niş görevler için ince ayarlanmış (fine-tuned) modeller inşa etmek demektir. Modeli yine satın alırsınız (API ya da açık ağırlıklı bir model olarak), ama etrafındaki her şey size aittir.

Build, stratejik farklılaşma sizin için yüksek olduğunda mantıklıdır. Eğer bir yetkinlik işinizin kalbindeyse, rakiplerinizin kopyalayamayacağı bir tescilli veri varlığına dayanıyorsa ve pazardaki hazır çözümler sizin ihtiyacınızı karşılamıyorsa, inşa etmek savunulabilir bir yatırımdır. Ancak Build'in maliyeti lisans ücretiyle bitmez; asıl yük yetenek, sürekli bakım, değerlendirme (eval) altyapısı ve operasyonlardadır. Birçok kurum bu yola girer, bir PoC çıkarır ve sonra onu üretimde ayakta tutmanın maliyeti altında ezilir.

Compose / Hibrit — satın alınanı farklılaştırıcı sisteme dönüştürmek

Compose yolu, satın alınan bileşenleri (temel model API'leri, vektör veritabanları, guardrail kütüphaneleri, gözlemlenebilirlik araçları) alıp bunları kurumun kendi verisi ve iş mantığı etrafında farklılaştırıcı bir sisteme dönüştürmektir. Modeli satın alırsınız, retrieval altyapısının bir kısmını satın alırsınız, ama orkestrasyonu, alan (domain) mantığını, guardrail politikalarını ve entegrasyonu siz inşa edersiniz.

2026'da gerçekçi varsayılan budur ve nedeni şu: Saf Buy size farklılaşma vermez, herkes aynı SaaS'ı kullanabilir. Saf Build çoğu kurum için sürdürülemez bir maliyet ve yetenek yüküdür. Compose ise her iki dünyanın da iyi yanlarını alır — altyapının zaten metalaşmış (commodity) kısmını satın alır, sadece sizi farklılaştıran ince katmanı inşa edersiniz. Sahada gördüğüm en başarılı kurumsal AI programları neredeyse istisnasız bu hibrit zihniyetle çalışıyor. Bunu bir yemek tarifi gibi düşünün: malzemeleri marketten alırsınız (model, vektör DB, araçlar), ama yemeği sizin mutfağınız, sizin tarifiniz farklı kılar.

Boyut	Buy	Build	Compose / Hibrit
Hız (time-to-value)	En hızlı	En yavaş	Orta-hızlı
Farklılaşma	Düşük	Yüksek	Yüksek
Başlangıç maliyeti	Düşük	Yüksek	Orta
Sürekli bakım yükü	Sağlayıcıda	Sizde (ağır)	Paylaşımlı
Kontrol & yol haritası	Düşük	Tam	Yüksek
Vendor lock-in riski	Yüksek	Düşük	Orta (yönetilebilir)
Yetenek ihtiyacı	Düşük	Yüksek	Orta
Veri kontrolü	Sağlayıcıya bağlı	Tam	Yüksek

Şimdi çerçevenin etini kemiğini konuşalım. Bir yetkinlik için Buy mı, Build mı, Compose mu sorusuna cevap verirken sekiz boyutu masaya koyuyorum. Bunları sırasıyla ele alalım çünkü her birinin kendine has tuzakları var.

1. Stratejik farklılaşma (core vs commodity). Bu boyut belirleyicidir. Kendinize sorun: bu yetkinlik bizi rakiplerimizden ayırıyor mu, yoksa herkesin sahip olduğu bir hijyen faktörü mü? Bir bankanın kredi risk değerlendirme mantığı çekirdektir — orada Build ya da Compose anlamlıdır. Aynı bankanın iç toplantı notlarını özetlemesi commodity'dir — orada Buy yeterlidir. En sık gördüğüm hata, commodity yetkinlikleri büyük bir tutkuyla inşa etmek ve çekirdek yetkinlikleri ucuz bir SaaS'a emanet etmek. Tam tersi olmalı.

2. Veri hassasiyeti ve egemenliği (KVKK, on-prem). Türkiye'de bu boyut çoğu zaman kararı tek başına belirliyor. KVKK kapsamındaki kişisel veriler, finansal veriler, sağlık verileri yurt dışındaki bir SaaS'a aktarılamıyorsa, saf Buy zaten masadan kalkıyor. Veri ikametgâhı (data residency) zorunlulukları bazı iş yüklerini on-prem'e ya da yerli bulut bölgelerine itiyor. Bu durumda Compose ya da Build'e doğru kayıyorsunuz — çünkü verinin nerede işlendiği üzerinde kontrol sahibi olmanız gerekiyor.

3. Toplam sahip olma maliyeti (TCO). Burada en büyük yanılgı maliyeti sadece lisans ücretinden ibaret görmek. Gerçek TCO; yetenek (maaşlar, işe alma, elde tutma), bakım, eval altyapısı, gözlemlenebilirlik, güvenlik, model çağrı (inference) maliyetleri ve operasyonel sürekliliği kapsar. Build'in lisans maliyeti düşük görünür ama insan ve operasyon maliyeti yüksektir. Buy'ın lisansı yüksek görünür ama gizli operasyon maliyeti düşüktür. Bu dengeyi görmeden karar vermek bütçeyi yanıltır.

4. Değere ulaşma süresi (time-to-value). Bazı durumlarda hız her şeyden değerlidir. Eğer bir fırsat penceresi varsa ve altı ay sonra değer yaratmaya başlamak çok geç olacaksa, Buy ya da hafif bir Compose yaklaşımı doğru olabilir. Mükemmel ama geç gelen bir Build çözümü, "yeterince iyi" ve zamanında gelen bir Buy çözümünden iş açısından daha değersizdir.

5. Vendor lock-in ve çıkış maliyeti. Bir sağlayıcıya bağlandığınızda, ondan ayrılmanın maliyetini de hesaplamalısınız. Veriniz onların formatına mı kilitlendi? Promptlarınız, ince ayarlarınız taşınabilir mi? Fiyat üç katına çıkarsa alternatifiniz var mı? Compose yaklaşımının en büyük avantajlarından biri, model katmanını soyutlayarak (abstraction) bir sağlayıcıdan diğerine geçişi mümkün kılmasıdır. Tek bir API'ye kilitlenmek 2026'da gereksiz bir risktir.

6. Yol haritası ve uyum üzerindeki kontrol. Düzenlemeler değiştiğinde (ve Türkiye'de, AB'de bunlar hızla değişiyor) sisteminizi ne kadar hızlı uyarlayabilirsiniz? Buy'da sağlayıcının önceliklerine tabisiniz. Build/Compose'da kontrol sizdedir. Düzenlenmiş sektörlerde bu kontrol genellikle ödenmeye değer bir prim taşır.

7. Yetenek erişilebilirliği. Bu, Türkiye'de acı bir gerçek. Nitelikli AI mühendisi, ML ops uzmanı, prompt ve eval mühendisi bulmak ve elde tutmak zor ve pahalı. Build yolunu seçtiğinizde, bu ekibi kurabilecek ve sürdürebilecek misiniz? Çoğu kurum için dürüst cevap "hayır" ya da "çok zor"dur. Bu da Compose'u — daha küçük bir ekiple yönetilebilir olduğu için — cazip kılar.

8. Güvenlik. Saldırı yüzeyi, prompt injection, veri sızıntısı, model çıktısının kötüye kullanımı. Build size daha fazla kontrol verir ama sorumluluğu da tamamen size yükler. Buy'da sağlayıcının güvenlik duruşuna güvenirsiniz — ki bu da titiz bir vendor due diligence gerektirir.

Soyut kalmamak adına, kurumlarla atölyelerde kullandığım puanlama yöntemini paylaşayım. Her yetkinlik için sekiz boyutu 1-5 arası puanlayın, sonra ağırlıklandırın. Yüksek farklılaşma + yüksek veri hassasiyeti = Build/Compose'a doğru; düşük farklılaşma + düşük hassasiyet = Buy'a doğru.

Boyut	Ağırlık	Buy'a işaret eden	Build/Compose'a işaret eden
Stratejik farklılaşma	Yüksek	Commodity yetkinlik	Çekirdek, ayırt edici yetkinlik
Veri hassasiyeti/egemenlik	Yüksek	Kamuya açık/düşük riskli veri	KVKK kapsamı, on-prem zorunluluğu
TCO	Orta	Düşük hacim, basit kullanım	Yüksek hacim, ölçek ekonomisi
Time-to-value	Orta	Acil ihtiyaç	Uzun vadeli stratejik yatırım
Vendor lock-in	Orta	Düşük geçiş maliyeti	Yüksek çıkış riski endişesi
Yol haritası kontrolü	Orta	Standart ihtiyaç yeterli	Sık değişen uyum gereksinimi
Yetenek erişimi	Yüksek	İç ekip yok/sınırlı	Güçlü iç mühendislik kapasitesi
Güvenlik	Yüksek	Sağlayıcıya güven kabul edilebilir	Tam kontrol gerekli

Pratik kural: Eğer bir yetkinlik hem yüksek farklılaşma hem yüksek veri hassasiyeti taşıyorsa, neredeyse her zaman Compose ya da Build'e gidersiniz. Eğer düşük farklılaşma ve düşük hassasiyet varsa, Buy'da inat etmeyin, hızı satın alın. Geri kalan tüm orta bölge — ki kurumsal portföyün büyük çoğunluğu burada — Compose'un yaşadığı yerdir.

Bir kurumsal AI girişiminin gerçek maliyetini görmek için lisans ücretinin çok ötesine geçmek gerekir. Atölyelerde kullandığım TCO iskeletini katman katman açayım. Bunları bir Excel'e dökmek, kararı duygusal olmaktan çıkarıp rakamsal hale getirir.

Doğrudan teknoloji maliyetleri:

• Model çağrı (inference) maliyetleri — token başına ya da koltuk başına. Hacim büyüdükçe bu kalem patlayabilir.
• Lisans ve abonelik ücretleri (Buy ve Compose bileşenleri için).
• Altyapı: vektör veritabanı, hesaplama (compute), depolama, ağ. On-prem'de ayrıca donanım amortismanı.

İnsan ve yetenek maliyetleri:

• Mühendislik (geliştirme + sürekli iyileştirme).
• ML/LLM ops, gözlemlenebilirlik ve izleme.
• Prompt ve eval mühendisliği — sıkça unutulur ama kritiktir.
• Yönetişim, hukuk, uyum gözden geçirmeleri.

Operasyonel ve gizli maliyetler:

• Değerlendirme (eval) altyapısı: modelin doğru çalıştığını sürekli ölçmek.
• Güvenlik testleri, kırmızı takım (red teaming), penetrasyon testleri.
• Model/sağlayıcı geçişleri ve sürüm yükseltmeleri.
• Eğitim ve değişim yönetimi — kullanıcılar aracı benimsemezse ROI sıfırdır.
• Döviz riski (Türkiye için): yabancı SaaS ve API'ler dolar/euro bazlı faturalanır; kur dalgalanması bütçeyi öngörülemez kılar.

Burada vurgulamak istediğim şey şu: Birçok yönetici Build'in maliyetini sadece geliştirme aşamasında düşünür ve "tek seferlik" bir yatırım sanır. Oysa kurumsal AI bir ürün değil, yaşayan bir sistemdir. Modeller eskir, sağlayıcılar fiyat değiştirir, düzenlemeler güncellenir, veriniz kayar (data drift). TCO'nun en büyük kalemi neredeyse her zaman ilk yıldan sonraki "işletme" maliyetidir. Bunu görmezden gelen her iş vakası (business case) yanıltıcıdır.

Sahada en çok gördüğüm trajedi şu: heyecan verici bir PoC, etkileyici bir demo, yönetim kurulu alkışları... ve sonra altı ay süren bir ölüm. Proje üretime hiç ulaşamaz ya da ulaşır ama kimse kullanmaz. Buna "PoC-to-production uçurumu" diyorum ve bu uçurum build vs. buy kararının doğrudan bir sonucudur.

PoC kolaydır çünkü PoC'de guardrail yoktur, ölçek yoktur, gerçek entegrasyon yoktur, uyum denetimi yoktur, kullanıcı benimsemesi yoktur. Üretim ise tam olarak bunların hepsidir. Bir kurum saf Build yoluna girer, PoC'yi parlatır, sonra üretim için gereken eval altyapısının, guardrail'lerin ve ops disiplininin maliyetiyle yüzleşince donar kalır. İşte Compose'un sessiz üstünlüğü burada ortaya çıkar: hazır, üretime hazır bileşenleri satın alarak bu uçurumun çoğunu baştan atlarsınız.

ROI'yi ölçerken birkaç ilkeye sadık kalmanızı öneririm. Birincisi, değeri baştan tanımlayın — hangi metrik, hangi süreç, ne kadar iyileşecek? "Verimlilik artacak" bir hedef değildir; "müşteri hizmetleri ilk yanıt süresi şu kadar düşecek" bir hedeftir. İkincisi, benimsemeyi (adoption) ROI'nin merkezine koyun. Mükemmel bir araç kullanılmıyorsa değeri sıfırdır. Üçüncüsü, değeri kademeli realize edin — büyük patlama (big bang) lansmanları yerine, dar bir kullanım senaryosunda değer kanıtlayıp genişletin. Compose yaklaşımı bu kademeli genişlemeye doğal olarak uygundur.

"

Bir demo herkesi heyecanlandırır; üretim ise kimsenin konuşmak istemediği guardrail, eval ve entegrasyon işidir. Build vs. buy kararını verirken kendinize sorun: bu yolda PoC'den üretime nasıl geçeceğim? Cevabınız yoksa, henüz karar vermeye hazır değilsiniz.

Küresel çerçeveler güzeldir ama Türkiye'de iş yaparken bazı yerel gerçekler kararı doğrudan şekillendirir. Bunları görmezden gelen her strateji kâğıt üzerinde kalır.

KVKK ve veri ikametgâhı. KVKK, kişisel verilerin yurt dışına aktarımını sıkı kurallara bağlar. Birçok kurumsal AI iş yükü kişisel veri içerir — müşteri kayıtları, çalışan verileri, sağlık ya da finansal bilgiler. Bu veriler yurt dışındaki bir SaaS'a aktarılamıyorsa, saf Buy seçeneği daralır. Sonuç: bazı iş yükleri zorunlu olarak on-prem'e ya da Türkiye'deki bulut bölgelerine kayar. Bu da kararı Compose ve Build'e doğru iter, çünkü verinin nerede işlendiği üzerinde kontrol gerekir.

Yetenek kıtlığı. Bunu acı tecrübeyle söylüyorum: Türkiye'de nitelikli AI mühendisi, MLOps uzmanı ve eval mühendisi bulmak ve elde tutmak zor. Küresel firmalar uzaktan çalışmayla bu yetenekleri çekiyor, dolar maaş teklif ediyor. Saf Build yolunu seçmeden önce dürüstçe sorun: bu ekibi kurabilir ve iki yıl elde tutabilir misiniz? Çoğu kurum için Compose, daha küçük ve yönetilebilir bir ekiple sürdürülebilir olduğu için daha gerçekçi.

Döviz maliyeti. Yabancı SaaS ve API'ler dolar/euro bazlı faturalanır. TL'nin değer kaybı, foreign-currency maliyetlerini öngörülemez ve giderek pahalı kılar. Bu, saf Buy'ın görünmeyen bir riskidir ve uzun vadeli TCO hesabına mutlaka katılmalıdır. Bazı durumlarda yerli bileşenler ya da açık ağırlıklı modellerle Compose, döviz maruziyetini azaltan stratejik bir hamledir.

EU AI Act ve sağlayıcı yükümlülükleri. AB pazarına dokunan ya da AB müşterilerine hizmet veren Türk firmaları için EU AI Act giderek önemli hale geliyor. Burada kritik nüans şu: yasa, "provider" (sağlayıcı) ve "deployer" (kullanan) için farklı yükümlülükler tanımlar. Eğer bir modeli Build ederseniz ya da önemli ölçüde değiştirirseniz, provider yükümlülüklerini üstlenebilirsiniz — bu da dokümantasyon, risk değerlendirmesi ve uyum yükü demektir. Saf Buy'da bu yükün çoğu sağlayıcıdadır. Yani build vs. buy kararınız, doğrudan hangi düzenleyici yükümlülükleri taşıyacağınızı belirler. Bu, çoğu yöneticinin gözden kaçırdığı ama maliyetli olabilecek bir boyuttur.

Build vs. buy kararının arkasında, çoğu zaman konuşulmayan ama belirleyici bir katman var: yönetişim. İyi bir karar çerçevesi, sağlam bir yönetişim olmadan kâğıt üzerinde kalır.

Shadow AI. Bu, bugün karşılaştığım en sinsi risk. Siz merkezi bir AI stratejisi tartışırken, departmanlarınız çoktan kredi kartıyla ChatGPT, Claude ya da onlarca niş SaaS aracını kullanmaya başladı bile. Bu "gölge AI", kontrolsüz veri sızıntısı, uyum ihlali ve dağınık maliyet demek. İronik olan şu: yönetimin Build vs. Buy kararını geciktirmesi, çalışanları kendi gölge çözümlerini bulmaya iter. Yani karar vermemek de bir karardır — ve genellikle en kötüsüdür. İyi yönetişim, shadow AI'ı görünür kılar, güvenli ve onaylı alternatifler sunar.

Satın alma disiplini. AI araçlarını satın alırken klasik yazılım satın alma süreçleri yetersiz kalır. Sormanız gereken yeni sorular var: Verim nereye gidiyor ve eğitime kullanılıyor mu? Model sürümleri nasıl yönetiliyor? Çıkış (exit) stratejim ne? Fiyatlandırma hacimle nasıl ölçekleniyor? SLA ve sorumluluk (liability) nasıl tanımlanmış? Bu disiplin olmadan, her departman kendi anlaşmasını yapar ve kurum parçalı, kontrolsüz bir AI yığınıyla baş başa kalır.

Vendor due diligence. Bir AI sağlayıcısını değerlendirmek, geleneksel bir yazılım satıcısını değerlendirmekten farklıdır. Güvenlik duruşu, veri işleme uygulamaları, modelin nerede barındırıldığı, alt-işleyiciler (sub-processors), uyum sertifikaları, model güncelleme politikası ve finansal sürdürülebilirlik — hepsi masaya yatırılmalı. Bir startup'ın parlak bir ürünü olabilir ama iki yıl sonra var olacak mı? Sağlayıcı battığında verinize ne olur? Bu soruları sormak paranoya değil, sorumluluktur.

Çerçeve soyut kalmasın diye, sıkça karşılaştığım iki tipik durumu paylaşmak istiyorum. İsim vermeden, çünkü mesele firmalar değil, karar mantığı.

Birincisi, orta ölçekli bir perakendecinin müşteri hizmetleri otomasyonu. Yönetim, gözünü kararttı ve "kendi botumuzu sıfırdan inşa edelim, fark yaratalım" dedi. Altı ayda parlak bir PoC çıktı. Ama üretime geçince işler değişti: çağrı merkezi sistemine entegrasyon, KVKK kapsamındaki müşteri verisinin maskeleme, halüsinasyon kontrolü, sürekli eval... Ekip, asıl maliyetin başlangıçta değil, sürdürmede olduğunu görünce tıkandı. Oysa müşteri hizmetleri yanıtı, bu firma için bir commodity yetkinlikti — onları rakiplerinden ayıran şey ürün gamı ve fiyatlamaydı, bot değil. Doğru karar, hazır bir konuşma altyapısını satın alıp (Buy/Compose) üzerine sadece kendi ürün kataloğu ve KVKK politikalarını giydirmekti. Farklılaşma sandıkları yerde aslında commodity vardı; enerjilerini yanlış yere harcadılar.

İkincisi, bir sigorta şirketinin hasar değerlendirme akışı. Burada durum tam tersiydi. Hasar dosyalarını okuyup ön değerlendirme yapan akış, firmanın yıllar içinde biriktirdiği tescilli verisine ve kendi iş kurallarına dayanıyordu — yani çekirdek, ayırt edici bir yetkinlikti. Üstelik veriler son derece hassastı ve yurt dışına çıkamazdı. Burada hazır bir SaaS satın almak hem farklılaşmayı kaybetmek hem de KVKK riskini almak demekti. Doğru karar, temel modeli (mümkünse on-prem barındırılabilen ya da yerli bölgede çalışan) satın alıp, retrieval ve karar mantığını kendileri inşa etmekti — yani Compose'a yakın bir Build. İki senaryonun ortak dersi şu: yetkinliği farklılaşma ve veri hassasiyeti eksenlerinde doğru konumlandırmazsanız, ne kadar yetenekli olursanız olun yanlış yere yatırım yaparsınız.

Yıllar içinde aynı hataların tekrarlandığını görüyorum. Karar çerçevenizi kurarken bunlara karşı uyanık olun.

• Farklılaşmayı yanlış okumak. Commodity bir işi tutkuyla inşa etmek, çekirdek bir işi ucuza satın almak. En pahalı hata budur çünkü hem para hem rekabet avantajı kaybedersiniz.
• TCO'yu lisansa indirgemek. Bakım, eval, ops, yetenek ve döviz riskini hesaba katmamak. İlk yıl ucuz görünen seçenek üç yılda en pahalısı çıkabilir.
• PoC'yi üretim sanmak. Demoda işe yarayan şeyin üretimde guardrail, ölçek ve entegrasyon gerektirdiğini unutmak. Uçurum tam buradadır.
• Lock-in'i göz ardı etmek. Bugün ucuz olan tek sağlayıcıya kilitlenmek, fiyat arttığında ya da sağlayıcı yön değiştirdiğinde çaresiz kalmak. Model katmanını soyutlamak ucuz bir sigortadır.
• Yönetişimi sona bırakmak. Shadow AI, satın alma disiplini ve vendor değerlendirmesini "sonra hallederiz" demek. Sonra geldiğinde iş işten geçmiş, veri çoktan dağılmış olur.

Tüm bu çerçeveyi bir eyleme dönüştürmek gerekirse, kurumlara önerdiğim yol şu. Önce yetkinlik portföyünüzü çıkarın: AI'dan değer bekleyen tüm kullanım senaryolarını listeleyin. Sonra her birini farklılaşma ve veri hassasiyeti eksenlerinde konumlandırın. Düşük-düşük olanları gönül rahatlığıyla satın alın; orada inşaata harcanan her saat israftır. Yüksek-yüksek olanlar için Build ya da Compose'a yatırım yapın; orası sizin rekabet avantajınızın yaşadığı yer. Geri kalan büyük orta bölge için Compose'u varsayılan kabul edin.

İkinci adım, bir referans mimarisi kurmaktır: model katmanını soyutlayan, retrieval'ı standartlaştıran, guardrail'leri merkezi kılan, gözlemlenebilirliği baştan dahil eden bir omurga. Bu omurga bir kez kurulduğunda, her yeni kullanım senaryosu sıfırdan başlamaz; var olan Compose altyapısının üzerine oturur. Bu, ölçeklenmenin sırrıdır — ve PoC mezarlığından kaçışın da.

Üçüncü adım, yönetişimi baştan kurmaktır, sonradan eklenen bir yama olarak değil. Bir AI kurulu (AI council), net bir satın alma politikası, shadow AI için bir keşif ve göçürme planı, ve bir vendor değerlendirme rubriği. Bunlar sıkıcı görünür ama farkı yaratan tam da bu disiplindir.

Son olarak şunu hatırlatmak isterim: Build vs. buy bir kerelik bir karar değil, sürekli yeniden değerlendirdiğiniz canlı bir denge. Bugün Build ettiğiniz bir yetkinlik, pazar olgunlaştıkça yarın commodity'leşebilir ve Buy'a kayabilir. Bugün satın aldığınız bir araç, stratejik hale geldikçe yarın Compose ile içselleştirilebilir. Bu çerçeveyi bir kez kullanıp rafa kaldırmayın; her büyük yatırım kararında, her bütçe döneminde tekrar masaya koyun. Çünkü değişen tek şey teknoloji değil — sizin stratejik konumunuz, verinizin değeri ve pazarın olgunluğu da değişiyor. Doğru soru "yap mı, satın al mı?" değil; "bu yetkinlik için, bugün, hangi bileşeni satın alıp hangi ince katmanı kendim inşa etmeliyim?" Bu soruyu disiplinli sorabilen CTO ve CDO'lar, 2026'da AI yatırımlarından gerçek değer çıkaranlar olacak.