Kısa cevap: "AI projesi ne kadar tutar?" sorusuna kapsamınızı görmeden rakam söyleyen herkese temkinli yaklaşın — biz de söylemiyoruz. Ama bundan daha faydalı bir şey yapılabilir: maliyetin hangi kalemlerden oluştuğunu, her kalemin hangi değişkenle büyüdüğünü ve bütçenin nasıl kurulacağını öğrenmek. Bu üçünü bilen bir yönetici, önüne gelen her teklifi kendi başına tartabilir. Bu yazının amacı size o terazi setini vermektir.
Neden şimdi önemli? Çünkü 2026'da AI maliyet yapısı iki yönde birden hareket ediyor. Model çağrısının birim fiyatı düşmeye devam ediyor — aynı iş, iki yıl öncesine göre kat kat ucuz. Ama kullanım hacmi ve beklenti daha hızlı büyüyor: dün bir özet isteyen ekip, bugün her müşteri etkileşimine model bağlamak istiyor. Sonuç, birim ucuzlarken toplamın şişebildiği bir dönem. Bu dönemde bütçe hatası çoğu zaman "pahalı teklif kabul etmek" değil, işletme maliyetini hiç hesaplamadan başlamaktır.
Maliyetin üç ana bileşeni
Her AI yatırımı üç kalemden oluşur ve bu üçü ayrı ayrı planlanmalıdır. **Bir: geliştirme** — tek seferlik iştir; kapsam, entegrasyon sayısı ve veri hazırlığının derinliğiyle büyür. **İki: işletme** — süreklidir; model çağrıları, barındırma ve bakımdan oluşur, kullanım hacmiyle büyür. **Üç: değişim yönetimi** — en sık unutulan kalemdir; ekibin eğitimi, sürecin yeniden tarifi ve ilk aylardaki verim düşüşünün maliyetidir. Sahada en sık gördüğümüz bütçe kazası, üçüncü kalemin sıfır sayılmasıdır: sistem kurulur, kimse kullanmaz, yatırım kâğıt üstünde kalır.
Bu üçlünün oranı projeye göre değişir; değişmeyen kural şudur: teklif yalnız birinci kalemi kapsıyorsa, toplam sahip olma maliyetiniz teklifte yazandan belirgin biçimde büyük olacaktır. Teklifi değerlendirirken "birinci yılın toplamı" sorusunu sorun: geliştirme + on iki ay işletme + eğitim. Kıyaslanabilir tek rakam budur.
Token ekonomisi: işletme maliyeti neyle büyür
Bulut modeli kullanan her sistemin işletme maliyeti aynı basit çarpımdan çıkar: aylık maliyet ≈ çağrı sayısı × çağrı başına ortalama token × tokenin birim fiyatı. Bu formülün gücü, üç kolun üçünün de yönetilebilir olmasındadır. Çağrı sayısını süreç tasarımı belirler: her tuş vuruşunda mı model çağrılıyor, günde bir kez toplu mu? Token miktarını istem tasarımı belirler: modele her seferinde tüm arşivi mi gönderiyorsunuz, yalnız ilgili parçayı mı? Birim fiyatı model seçimi belirler: her iş en güçlü modeli gerektirmez — basit sınıflandırma işi küçük ve ucuz modelle, karmaşık muhakeme işi güçlü modelle çalışır. Bu kademelendirme tek başına, işletme faturasını en çok oynatan karardır.
Açık kaynak mı, bulut API mi: TCO nasıl karşılaştırılır
"Açık kaynak model bedava" cümlesi yarım doğrudur. Model ağırlıkları bedavadır; onu çalıştıran donanım, bakan mühendis ve güncel tutan emek bedava değildir. Doğru karşılaştırma birim fiyat üzerinden değil toplam sahip olma maliyeti üzerinden yapılır: bulut tarafında ölçekle büyüyen değişken maliyet ödersiniz, kendi sunucunuzda büyük ölçüde sabit maliyet ödersiniz. Mekanizma şu: kullanım hacmi düşükken bulut neredeyse her zaman ucuzdur; hacim büyüdükçe bir kesişim noktası gelir ve sabit maliyetli yerel kurulum avantaja geçer. O kesişim noktası herkeste farklıdır — kendi çağrı hacminizle iki eğriyi çizip bakmadan karar vermeyin. Veri hassasiyeti ayrı bir boyuttur ve bazen ekonomiyi ezer: verinin dışarı çıkamadığı işlerde yerel model, maliyetinden bağımsız tek doğru olabilir. Bu değerlendirmenin çerçevesini [şirket verisi dışarı çıkmadan yapay zeka](/kaynaklar/sirket-verisi-disari-cikmadan-yapay-zeka) yazısında bulabilirsiniz.
Gizli kalemler: bütçeyi sessizce şişirenler
Teklif satırlarında görünmeyen ama faturada görünen dört kalem vardır. **Veri hazırlığı:** modelin okuyacağı verinin temizlenmesi, etiketlenmesi, yapılandırılması — çoğu projede öngörülenden fazla emek ister ve dışarıdan bakınca "görünmez" iştir. **Entegrasyon:** modelin kendisi değil, modelin ERP'nize, CRM'inize, e-posta sisteminize bağlanması; bağlantı sayısı arttıkça doğrusal değil, çarpımsal karmaşıklık üretir. **Değerlendirme ve test:** çıktının "yeterince iyi" olduğunu kim, neye göre söyleyecek? Kabul ölçüsünün kurulması ve düzenli ölçüm de bir maliyettir. **Bakım:** modeller ve API'ler değişir, performans zamanla kayar; sistemi yaşatan aylık emek baştan bütçelenmelidir.
Getiriyi düşünme çerçevesi: rakam vaadi değil, ölçüm düzeni
Geri ödeme hesabının iskeleti basittir: geri ödeme süresi = toplam yatırım ÷ aylık net etki. Zor olan paydadır — aylık net etki tahmin edilmez, ölçülür. Bunun için projeden ÖNCE taban çizgisi alın: otomatikleşecek iş bugün ayda kaç saat yiyor, hangi hata ne sıklıkla oluyor, hangi gecikme neye mal oluyor? Taban çizgisi olmadan yapılan her getiri hesabı, hangi yöne çekilmek istenirse o yöne çekilir. Etkinin tamamı da tek boyutta değildir: Üç-Boyutlu ROI (3DR) çerçevesi doğrudan finansal etkiyi, operasyonel hızlanmayı ve organizasyonun kazandığı kalıcı yeteneği ayrı sütunlarda izlemeyi önerir — çünkü üçü farklı hızda gerçekleşir ve tek sayıya sıkıştırıldığında karar bozulur.
Bütçe nasıl kurulur: pilot-önce yaklaşımı
Bütçeyi büyük hedefin üstünden değil, pilotun üstünden kurun. Mekanizma şudur: tek kullanım senaryosu, tek ölçülebilir hedef, sabit süre ve baştan yazılmış bir durdurma kriteri. Pilot iki soruyu cevaplamak için vardır: bu iş bizim verimizle gerçekten çalışıyor mu, ve çalıştığında birim ekonomisi ne? İkinci sorunun cevabı — pilotta ölçülen çağrı hacmi ve birim maliyet — ölçek bütçenizin tek güvenilir girdisidir. Pilotu atlayıp doğrudan büyük bütçe kuran projelerde rakamlar varsayımdan türetilir; varsayımdan türeyen bütçe de ilk temasla dağılır.
Sahada işe yarayan ipuçları
**1.** Her teklifi "birinci yıl toplamı"na çevirin: geliştirme + 12 ay işletme + eğitim. Yalnız bu rakamlar kıyaslanabilir. **2.** İşletme maliyeti için satıcıdan varsayım setini isteyin: hangi çağrı hacmi, hangi model, çağrı başına kaç token? Varsayımını vermeyen tahmine güvenmeyin. **3.** Model kademelendirmesini baştan isteyin: hangi iş ucuz modelle, hangi iş güçlü modelle çalışacak ve bu ayrımı kim, neye göre güncelleyecek? **4.** Projeden önce taban çizgisi ölçün — otomatikleşecek işin bugünkü saat ve hata maliyeti. Bu ölçüm bir haftanızı alır, getiri tartışmasını ömür boyu kurtarır. **5.** Bütçeye baştan bir durdurma kriteri yazın: "pilot şu tarihte şu eşiği geçmezse ölçeklemiyoruz." Bu cümle bütçe disiplininin tamamıdır. **6.** Değişim yönetimine ayrı satır açın: eğitim, süreç tarifi, ilk ayların verim düşüşü. Satırı sıfır olan bütçe, eksik bütçedir.
Sık yapılan hatalar
**Yalnız geliştirme bütçesi yapmak.** İşletme ve eğitim unutulur; ikinci yıl faturası sürpriz olur. **Kapsamı bütçeye sığdırmak yerine bütçeyi kapsama şişirmek.** Pilot küçük tutulmalı; "madem başlıyoruz, şunu da ekleyelim" cümlesi bütçelerin en pahalı cümlesidir. **En güçlü modeli her işe koşmak.** Çoğu iş için orta sınıf model yeterlidir; fark çıktıda görünmez, faturada görünür. **Getiriyi tahminle raporlamak.** Taban çizgisi olmadan yazılan yüzde, denetimde de yönetim kurulunda da savunulamaz. **Fiyat düşüşüne yaslanmak.** "Modeller nasılsa ucuzluyor" diye gevşek tasarlanan sistemlerde hacim artışı, birim ucuzlamasını her zaman yener.
Dürüstlük payı: bu yazıdaki hiçbir çerçeve, size özgü rakamın yerini tutmaz — ve o rakam ancak sizin çağrı hacminiz, veriniz ve süreçlerinizle kurulur. Ölçeğiniz küçükse ve ihtiyacınız hazır araçlarla karşılanıyorsa, özel geliştirme bütçesi açmak çoğu zaman gereksizdir; o durumda [KOBİ için kademeli yol haritası](/kaynaklar/kobi-ai-donusum) daha doğru başlangıçtır. Getiri hesabının en olgun örneğini görmek isterseniz [chatbot ROI hesaplama](/kaynaklar/chatbot-roi-hesaplama) yazısı aynı düşünce düzenini tek vaka üzerinde derinleştirir.