AI agent geliştirmenin ve işletmenin maliyeti ne kadar?

Bir AI agent için ne kadar bütçe gerekir diye sorulduğunda genellikle iki cevap duyulur. Biri, hangi varsayıma dayandığı belli olmayan kesin bir rakamdır. Diğeri “duruma göre değişir” diye başlar ve projede alınabilecek bütün teknik kararlarla devam eder. İkisi de bütçe hazırlamaya pek yardımcı olmaz.

2026’da yayımlanan tedarikçi tahminlerinde, tek ve dar kapsamlı bir görev yapan AI agent sistemi için 8.000-25.000 dolar aralığı sık görülüyor. Şirket verisi veya araçlarıyla çalışan bağlantılı sistemlerde rakam 25.000-80.000 dolara, birden fazla sisteme bağlı ya da büyük ölçüde otonom projelerde ise 80.000-250.000 dolara veya daha fazlasına çıkıyor. Aylık işletme giderleri de dar kapsamlı kurulumlarda birkaç yüz dolardan başlayıp daha karmaşık sistemlerde birkaç bin dolara ulaşabiliyor. Kurumsal projeler bu rakamları aşabilir.

Bunlar denetlenmiş piyasa ortalamaları değil. Projenin nerede geliştirildiği, sözleşme biçimi, güvenlik şartları ve şirketin hazır altyapısı fiyatı değiştirebilir. Dolayısıyla bu rakamlar teklif değil, bütçenin ölçeğini görmeye yarayan başlangıç aralıklarıdır. The Crunch Pharos Production

Aralıkların geniş olmasının basit bir nedeni var: “AI agent” tek başına ne kadar iş yapılacağını anlatmaz. Bir politikayı bulan, iadeyi onaya hazırlayan ve onay beklemeden gerçekleştiren üç sistem aynı modeli kullanabilir. Fakat modelin çevresinde kurulması gereken ürün aynı değildir.

Fiyatı modelin ne kadar zeki göründüğünden çok, sisteme ne yapma yetkisi verildiği belirler. Bağlanacağı sistemler, karşılaşacağı istisnalar ve kullanıma açılmadan önce ne kadar güven vermesi gerektiği de hesabı tamamlar.

---

AI agent geliştirme ve işletme bütçesi ne kadar?

İlk soru, AI agent sisteminin süreçte hangi işi üstleneceğidir. Prompt sayısı veya mimari şemadaki kutular bütçeyi açıklamaz.

Tablodaki aralıklar bilerek geniş tutuldu. Aylık rakamlar yayımlanmış piyasa rehberlerindeki model, altyapı, izleme ve rutin bakım giderlerine dayanıyor. İnsan incelemesi, istisnaların çözümü, güvenlik, mevzuata uyum ve ürün sorumluluğu için harcanan kurum içi zaman çoğu tahminde yer almıyor. Yüksek hacimde sürekli çalışan altyapı veya kapsamlı değerlendirme süreçleri de aylık gideri tablonun çok üzerine çıkarabilir.

Bu sınıfları olgunluk basamakları gibi okumamak gerekir. Kararın insanda kalması gereken bir süreçte yalnızca bilgi veren bir sistem, eksik değil tam olarak ihtiyaç duyulan ürün olabilir. Birden fazla agent kullanmak da ürünü kendiliğinden daha değerli yapmaz. OpenAI’ın uygulama rehberi, her yeni agent ek karmaşıklık ve yük getirdiği için önce tek agent ile ne kadar ilerlenebileceğine bakılmasını öneriyor. OpenAI

Tablo ölçeği gösterir. Projenin hangi aralığa girdiğini anlamak için model yanıt verdikten sonra sistemin ne yaptığına bakmak gerekir.

---

Yetki arttıkça maliyet de değişir

Aynı müşteri hizmetleri işi için üç ayrı AI agent sistemi düşünelim.

İlki güncel iade politikasını okur ve ilgili bölümü çalışana gösterir. Onaylanmış kaynağa erişmesi, doğru bölümü bulması ve dayandığı metni görünür biçimde sunması yeterlidir.

İkinci sistem siparişi de bulur, müşterinin koşulları karşılayıp karşılamadığını kontrol eder ve iadeyi onaya hazırlar. Bunun için kimliği doğrulanmış hesap erişimi, güvenilir araç tanımları ve yaptığı kontrolü inceleyecek kişiye gerekli bilgileri eksiksiz aktaran bir akış gerekir.

Üçüncüsü iadeyi doğrudan gerçekleştirir. Artık işlemi kimin yetkilendirdiği, tutarın politikaya uyup uymadığı ve ödeme hizmeti zaman aşımına uğrarsa ne yapılacağı açık olmalıdır. Aynı iade iki kez yapılmamalı, insan kararı gerektiren durumlar önceden belirlenmeli ve daha sonra bütün işlem kayıtlardan izlenebilmelidir.

Model üçünde de aynı olabilir. Değişen, modelin çevresindeki ürün ve ona verilen yetkidir.

Bilgi veren bir asistana işlem yetkisi eklemek, yalnızca bir API çağrısı daha eklemek değildir. Yazma erişimi varsa kimlik doğrulama ve yetkilendirme gerekir. İşlemin sonucu önemliyse onay kuralları, denetim kayıtları, hata sonrası toparlanma ve insan müdahalesi de tasarlanmalıdır. Geri alınamayan işlemlerde çıta daha da yükselir. OpenAI’ın rehberi araç riskini; okuma veya yazma erişimi, işlemin geri alınabilirliği, yetkiler ve finansal sonuç gibi somut ölçütlerle ele alıyor. Anthropic’in gerçek kullanımdaki sistemleri inceleyen araştırması da otonomiyi yalnızca modelin özelliği saymıyor. Sonuç; model, ürün tasarımı ve insan gözetiminin birleşiminden doğuyor. OpenAI Anthropic

Daha fazla otonomi insan incelemesini azaltabilir. Yine de güvenilirlik için harcanan emek kaybolmaz; başka yere taşınır. İnsan onayının yerine daha sıkı yetkiler, otomatik kontroller, daha geniş bir değerlendirme kümesi, sürekli izleme veya güvenli bir toparlanma yolu gerekir. Buna değip değmeyeceğini işlemin değeri ve olası bir hatanın sonucu belirler.

---

Kapsamı süreç şemasından çok istisnalar belirler

Bir iş akışı şemasında beş kutu bulunabilir: talebi al, müşteriyi bul, politikayı kontrol et, iadeyi yap, müşteriye haber ver. Kutuları saymak güvenilir bir maliyet tahmini üretmez.

Asıl iş bu kutuların dışına çıkıldığında başlar. Müşteri yanlış sipariş numarası verir. İki politika belgesi birbiriyle çelişir. Hesap sorgusu çalışır, ödeme hizmeti zaman aşımına uğrar. Sistem iadeyi başarısız sanarken ödeme aslında gönderilmiş olabilir. Müşteri yalnızca bölge yöneticisinin onaylayabileceği bir istisna ister. Ya da sistem geçen ay doğru olan, fakat dün yürürlükten kaldırılan politikayı bulur.

Bu vakaların her biri için bir karar gerekir. Sistem yeni bir soru sorabilir, başka bir kaynağı deneyebilir, bekleyip yeniden çalışabilir, güvenli biçimde durabilir, işlemi geri alabilir veya işi bir çalışana devredebilir. Devir sırasında hangi bilgiler paylaşılacak? Çözülemeyen işler kimde toplanacak?

Kısa bir iş akışının pahalı, daha uzun bir akışın öngörülebilir olması bu yüzden mümkündür. Kararlı API’ler üzerinden yapılan, iyi belgelenmiş on okuma işlemi; hata durumları belirsiz bir legacy sistemdeki iki yazma işleminden daha kolay geliştirilebilir. Şemada adımlar görünür. Mühendislik süresini tüketen ise çoğu zaman istisnalardır.

Beklenen güvenilirlik düzeyi de hesabı değiştirir. Çalışana yardımcı olan bir sistem belirsizliği gösterebilir ve son kararı insana bırakabilir. İşi tek başına tamamlayacak sistemin nerede yanılabileceğini ise çok daha iyi bilmek gerekir. “Çoğu zaman işe yarıyor” ile “rutin inceleme olmadan işlem yapabilecek kadar güvenli” arasında yalnızca birkaç puanlık kalite farkı yoktur. Değerlendirme yöntemi, güvenlik önlemleri ve hata sonrası davranış baştan tasarlanır.

Bu yüzden tahminden önce normal akışın yanı sıra gerçek istisnaları da toplamak gerekir. Temsil gücü olan birkaç düzine vaka, bütçe hakkında özenle hazırlanmış bir mimari şemadan daha çok şey söyleyebilir.

---

Mevcut sistemler fiyatı değiştirir

Aynı AI agent sistemi iki şirkette iki farklı fiyata çıkabilir. Çünkü bağlanacağı çalışma ortamı aynı değildir.

Bir şirkette müşteri kayıtlarına belgelenmiş bir API üzerinden erişilir. Her çalışanın yönetilen bir kimliği vardır. Politika arşivinin sahibi bellidir ve iade yetkileri operasyon kurallarına yazılmıştır. AI agent sisteminin ihtiyaç duyduğu yapı büyük ölçüde hazırdır.

Başka bir şirkette müşteri geçmişi eski bir CRM ile elektronik tablolar arasında dağılmıştır. Politikalar farklı klasörlerdedir. Çalışanlar ortak servis hesapları kullanır. İstisnalar özel mesajlarla, karar verme biçimi hiçbir yere yazılmamış kişiler tarafından çözülür. AI agent sistemi işe başlamadan önce şirketin henüz sahip olmadığı arayüzlerin bulunması veya geliştirilmesi gerekir.

Bütün bunlar “yapay zeka geliştirme” başlığı altında kolayca gözden kaçar. Oysa veri temizliği, API geliştirme, erişim kontrolü, süreçlerin yazılı hale getirilmesi ve hangi kaynağın geçerli olduğuna karar verilmesi gerekebilir. Bu işler dil modelini daha yetenekli yapmaz; ürünün o şirkette çalışmasını mümkün kılar.

Bu nedenle iki tedarikçi aynı mühendislik ücretleriyle çalışsa bile çok farklı teklifler verebilir. Biri temiz verinin, gerekli yetkilerin ve istisnalardan sorumlu kişilerin hazır olduğunu varsayar. Diğeri bunları oluşturacak çalışmayı da fiyatına ekler. Düşük teklif daha verimli bir yaklaşımdan kaynaklanabilir; daha dar bir sorumluluk üstleniyor da olabilir.

İyi bir tahmin bu varsayımları açıkça yazar: Hangi sistemlere erişilebiliyor? Veri ne kadar hazır? Yetkilere kim onay verecek? İş kurallarından ve istisnalardan kim sorumlu? Bunlar bilinmeden bir şirket için verilen fiyat, başka bir şirkete pek bir şey anlatmaz.

---

Geliştirme ve işletme maliyetleri farklı işleri karşılar

Geliştirme maliyeti sistemi kullanıma hazırlar. İşletme maliyeti, kullanıma açıldıktan sonra çalışır durumda tutar.

Geliştirme, iş akışının incelenmesi ve verinin hazırlanmasıyla başlar. Araçlar, arayüzler, yetkiler, değerlendirme vakaları, güvenlik önlemleri, deployment ve dokümantasyon da bu bütçeye girer. Bazı işler sistem açıldığında biter. Bazıları ise düzenli bakım isteyen parçalar bırakır.

İşletme bütçesinde model çağrıları, retrieval, harici araçlar, çalışma ortamı, depolama ve telemetri vardır. Sürekli değerlendirme, insan incelemesi, istisnaların çözümü, olaylara müdahale ve entegrasyon ya da politika değişiklikleri de aynı bütçenin parçasıdır. Yönetilen agent platformlarının fiyat sayfaları bu çeşitliliği açıkça gösteriyor. Örneğin AWS AgentCore; çalışma süresi, tarayıcı kullanımı, arama, araç geçidi çağrıları, kimlik istekleri, bellek, gözlemlenebilirlik, değerlendirme ve politika hizmetlerini ayrı ayrı ölçüyor. Başka bir platform kullanmak veya bu katmanları şirket içinde geliştirmek tabloyu değiştirmez: Model faturası, işletme giderlerinden yalnızca biridir. AWS

İlk geliştirme

İş akışını ve kabul koşulunu tanımlayın

Tamamlanmış işin ne olduğunu ve hangi kanıtla kabul edileceğini belirleyin.

Veriyi ve güvenilir kaynakları hazırlayın

Erişim, sahiplik, güncellik ve çelişen kayıt sorunlarını çözün.

Araçları ve entegrasyonları geliştirin

Bağlam sağlayan veya işlemleri alan sistemleri birbirine bağlayın.

Yetkileri, güvenlik önlemlerini ve kurtarma yolunu belirleyin

Neye izin verildiğini, kimin onay vereceğini ve hatanın nasıl sınırlandırılacağını tanımlayın.

Değerlendirme referansını oluşturup sistemi kullanıma açın

Temsil gücü olan vakaları test edin, sonuçları belgeleyin ve kullanıcıları hazırlayın.

İşletme boyunca

Model, araç, çalışma ortamı ve depolama kullanımı

Başarılı ve başarısız çalıştırmaların tükettiği kaynakları hesaba katın.

İzleme ve örneklem üzerinden değerlendirme

Gerçek kullanımdaki sonuçların kabul koşulunu karşılayıp karşılamadığını düzenli olarak kontrol edin.

İnsan incelemesi ve istisnaların çözümü

AI agent sisteminin tek başına tamamlayamadığı veya tamamlamaması gereken vakaları yönetin.

Entegrasyon, politika ve veri değişiklikleri

API, kaynak, kural veya bağımlılıklar değiştiğinde sistemi uyarlayın.

Operasyon sorumluluğu ve olay müdahalesi

Canlı sistem için gerektiğinde müdahale edip sistemi toparlayabilecek bir sorumlu belirleyin.

Kullanıma açıldıktan sonra devam eden işler

Güvenilir kaynaklarPolitika ve veri değişiklikleri

Araçlar ve entegrasyonlarEntegrasyon bakımı

Yetkiler ve kurtarmaİnceleme ve olay müdahalesi

Değerlendirme referansıİzleme ve örneklem değerlendirmesi

İlk yıl maliyeti = ilk geliştirme + 12 aylık işletme + sistemin gerektirdiği kurum içi çalışma

Kalemlerin ağırlığı projeden projeye değişir. Yine de her birinin bir sorumlusu olmalıdır.

Bu iki maliyet grubunu ayırmayan şirketler sık sık aynı hataya düşer. Geliştirme için bütçe vardır; fakat gerçek kullanımı değerlendirecek, sistemin bıraktığı vakaları çözecek veya bağlı API değiştiğinde ürünü güncelleyecek kişi ve bütçe yoktur. Maliyet kaybolmaz. Arıza, plansız çalışan zamanı veya giderek düşen kullanım olarak geri döner.

Üretimdeki maliyet sabit kalmaz. Tüketim, altyapı, bakım, kullanım biçimi ve model değiştikçe hesap da değişir. AWS’in yaşam döngüsü rehberi bu nedenle finansal ölçüleri iş sonuçlarıyla birlikte izlemeyi, yatırım getirisini yalnızca sistem açılırken bir kez hesaplayıp bırakmamayı öneriyor. AWS Prescriptive Guidance

Basit bir ilk yıl hesabı bütün kalemleri görünür tutar:

İlk yıl maliyeti = keşif + geliştirme ve entegrasyon + güvenilirlik ve kullanıma alma + 12 × aylık işletme

Geliştirme ile bakım arasında her projeye uyacak tek bir oran yoktur. Düşük hacimli kurum içi asistan ile müşteriye dönük ve işlem yapabilen bir sistemin giderleri aynı şekilde dağılmaz. Yine de her iki projede de paranın nereye gideceği baştan yazılabilir.

---

İşe yarayan bir tahmin varsayımlarını gösterir

Bir rakamın kesin görünmesi, tahminin doğru olduğu anlamına gelmez. Ekip iş akışını, bağlı sistemleri, istisnaları ve kabul ölçütlerini incelemeden söylenen 47.500 doların son iki hanesi bilgiye değil, biçimlendirmeye dayanır.

Bu, erken tahminin işe yaramadığı anlamına gelmez. İyi bir ilk tahmin bir aralık verir, varsayımlarını açıklar, en büyük belirsizlikleri gösterir ve aralığı daraltmak için neyin öğrenilmesi gerektiğini söyler. Varsayımları belli geniş bir aralık, temeli bilinmeyen kesin bir rakamdan daha güvenilirdir. Keşif çalışmasının değeri de burada ortaya çıkar: Tahmin edilen işin bir bölümünü gözlenmiş işe çevirir.

Hesabın büyük bölümü altı bilgiyle şekillenir: Sistemin tamamlayacağı iş, sahip olacağı yetki, bağlanacağı sistemler, şirket ortamının hazırlığı, istisnaların çeşitliliği ve beklenen güvenilirlik düzeyi. Aylık hacim işletme giderini ciddi biçimde etkiler. Fakat ne yaptığı belli olmayan bir sistemi tanımlı hale getirmez.

Planlama aracı

AI agent kapsam ve bütçe tahmini

Yedi kısa soruyla geliştirme ve işletme bütçesi için ilk aralığı görün.

1 / 7

Soru 1

Sonraki soru

AI agent ne yapabilir?

Sistemin yapacağı en ciddi işlemi seçin.

ABilgi okur veya yanıt verirBÖneri veya taslak hazırlarCOnaydan sonra işlem yaparDBağımsız işlem yapar

Geri

Araç, yerel mühendislik ücretlerini bilmiyor ve şirketin sistemlerini görmüyor. Zaten amacı teklif vermek değil. Hangi koşulların fiyatı değiştirdiğini ve eldeki bilgilerden hangilerinin tahmini zayıflattığını görünür hale getiriyor.

Teklif aşamasında bu genel varsayımların yerini somut bilgiler almalıdır: bağlanacak sistemlerin adları, örnek vakalar, açık yetkiler, değerlendirme planı, sorumlular ve gözlenmiş görev hacmi. Fiyat değişiyorsa nedeni de teklifte görülmelidir.

---

Maliyeti tamamlanan işle karşılaştırın

20.000 dolara geliştirilen bir sistem ayda on saat kazandırıyor olsun. 100.000 dolarlık başka bir sistem ise geliri geciktiren, müşterileri bekleten ve birkaç uzmanın zamanını alan yoğun bir iş kuyruğunu ortadan kaldırsın. İlki daha ucuzdur. Fakat daha iyi yatırım olduğu buradan çıkmaz.

Fiyatı yatırım kararına çevirmek için karşılığında tamamlanan işe bakmak gerekir. Önce hangi sonucun kabul edileceği belirlenir. Ardından sistemin bu ölçüte göre kaç işi bitirdiği, geriye ne kadar insan emeği bıraktığı ve tamamlanan işin değeri ölçülür.

İşletme hesabının tamamı için şu formül kullanılabilir:

Kabul edilen görev başına maliyet = iş akışının toplam işletme maliyeti / kabul koşulunu karşılayan tamamlanmış görev sayısı

Hesaptaki payda önemlidir. Sürekli düzeltme isteyen veya zor vakaların çoğunu insanlara bırakan ucuz bir sistem, API faturasını düşürse bile iş sürecini pek değiştirmeyebilir. Daha pahalı bir sistem değerli işleri güvenilir biçimde tamamlıyor ve geride yönetilebilir bir istisna kuyruğu bırakıyorsa yaptığı harcamanın karşılığını verebilir.

Geliştirme kararının ayrıca bir zaman ufku olmalıdır:

Üç yıllık toplam maliyet = geliştirme maliyeti + 36 aylık işletme + kurum içi sorumluluk ve kalan işler

Üç yıllık rakam, aynı dönemde kabul edilen sonuçların değeriyle karşılaştırılmalıdır. Kullanım, istisna oranı ve işletme gideri için tek bir iyimser senaryo yerine aralıklarla çalışmak daha sağlıklıdır. TensorBundle’ın yapay zeka token ekonomisi yazısı yeniden denemeleri, araçları, insan incelemesini ve başarılı görev başına maliyeti daha ayrıntılı ele alıyor. Buradaki hesap daha geniştir; görev başına ekonomi, ürünü geliştirme ve ayakta tutma yatırımını da karşılamalıdır.

Teknik olarak basit bir sistem, geliştirme giderini karşılamayacak kadar küçük bir işi otomatikleştiriyor olabilir. Daha pahalı ve işlem yapabilen bir sistem ise sık tekrarlanan, sonucu önemli ve çözümsüz kalması pahalı bir işte doğru yatırım olabilir. Model seçimi veya teklifin toplamı bunu tek başına söylemez.

---

Bütçeden önce yetkiyi tanımlayın

AI agent bütçesi hazırlamak için önce eksiksiz bir mimari çizmek gerekmez. Yapılacak işi, sisteme verilecek yetkiyi, çalışacağı ortamı ve güvenmek için hangi kanıtların aranacağını bilmek yeterlidir.

Piyasa aralıkları bütçenin ölçeğini görmek için kullanılabilir. Sonra sistemin neyi okuyacağı, ne önereceği ve neyi değiştireceği yazılır. Süreç şemasında görünmeyen istisnalar toplanır; bağlı sistemler ve veri incelenir. İlk geliştirme bütçesi, şirketin sistem çalışırken üstleneceği giderlerden ayrılır. En sonunda toplam maliyet, gerçekçi bir dönem boyunca tamamlanacak işin değeriyle karşılaştırılır.

Bilgiler netleştikçe tahmin aralığı daralır. Ortadaki rakamın değişmesi sorun değildir. Artık geçerli olmayan varsayımlara dayanan ilk tahmini korumak, yalnızca düzeltmeyi geciktirir.

Bütün bu sorular yanıtlandığında model yine bütçedeki küçük kalemlerden biri olabilir. En azından eldeki tahmin artık şirketin gerçekten kurup çalıştıracağı sistemi anlatır.