Yapay Zeka Agent Geliştirme Teklifinde Kullanım Başına Maliyet Nasıl Öngörülür?

Agent geliştirme maliyetinde sabit ve değişken giderler

AI agent proje teklifinde ilk ayrım, sabit proje bedeli ile değişken kullanım giderini birbirinden ayırmaktır. Keşif, süreç analizi, mimari tasarım, entegrasyon geliştirme, güvenlik kontrolleri, test, kullanıcı kabul çalışmaları ve canlıya alma çoğunlukla proje kapsamına bağlı sabit veya faz bazlı kalemlerdir. Buna karşılık model çağrıları, üçüncü taraf API kullanımı, belge arama altyapısı, işlem gücü, veri saklama, loglama ve izleme tüketim arttıkça değişebilir.

Teklifi iki bütçe katmanına ayırın

Teklifte bu iki katman aynı toplam rakamın içine gizlenmemelidir. Şirket, hangi bedelin geliştirme teslimatına; hangi bedelin aylık veya kullanım bazlı işletmeye ait olduğunu görebilmelidir. Özellikle agent ve otonom sistemlerin temel yapısı birden fazla model, araç ve karar adımı içeriyorsa tek bir “agent ücreti” ifadesi gerçek maliyet davranışını açıklamaz.

• Keşif ve süreç tasarımı için proje bedeli
• Entegrasyon ve özel geliştirme çalışmaları
• Model ve API kullanımına bağlı değişken giderler
• Sunucu, veri tabanı ve arama altyapısı giderleri
• İzleme, destek ve bakım için sürekli hizmet kalemleri

Küçük harcamalara dikkat edin; küçük bir sızıntı büyük bir gemiyi batırır. - Benjamin Franklin

Kullanım başına maliyeti hangi agent görevleri artırır

Kullanım başına maliyeti en çok artıran görevler, uzun bağlam kullanan, çok adımlı karar veren, birden fazla aracı çağıran veya başarısız denemeler sonrasında tekrar çalışan görevlerdir. Basit bir sınıflandırma işlemi ile uzun belgeleri tarayıp CRM kaydı açan, harici veriyi doğrulayan ve insan onayı bekleyen çok adımlı bir görev aynı maliyet profilinde değildir. Bu nedenle “bir agent işlemi kaç liradır” sorusu, görev yapısı tanımlanmadan güvenilir biçimde cevaplanamaz.

Bir etkileşimi tüketim bileşenlerine ayırın

Maliyet modeli, ortalama görevin kaç model çağrısı yaptığı, giriş ve çıktı bağlamının ne kadar olduğu, hangi araçlara eriştiği ve başarısızlık halinde kaç kez yeniden denediği üzerinden kurulmalıdır. Görev başına ölçülebilir tüketim profili oluşturulduğunda küçük optimizasyonların bütçeye etkisi de görülebilir. Örneğin gereksiz uzun geçmiş taşımak, her adımda aynı belgeyi yeniden aramak veya düşük değerli görevlerde pahalı bir model kullanmak toplam tüketimi büyütebilir.

• Uzun istemler ve geniş konuşma geçmişi
• Bir görevde çok sayıda model çağrısı
• Harici araç ve API çağrılarının sıklığı
• Belge arama ve yeniden sıralama işlemleri
• Hata, zaman aşımı ve otomatik tekrar denemeleri
• Görsel, ses veya yüksek işlem gücü gerektiren görevler

Model ve altyapı giderlerini hangi taraf üstlenmelidir

Model ve altyapı giderlerini hangi tarafın ödeyeceği sözleşmede açıkça tanımlanmalıdır; tek bir doğru sahiplik modeli yoktur. Bazı projelerde şirket kendi bulut ve model hesaplarını kullanır, bazı projelerde sağlayıcı bu servisleri yönetip müşteriye yansıtır, bazı projelerde ise hibrit yapı kurulur. Kritik olan, değişken giderin kimin hesabından geçtiği, faturalama yönteminin ne olduğu ve hesap sahipliğinin proje sonunda kimde kalacağının belirsiz olmamasıdır.

Hesap sahipliği ile maliyet sorumluluğunu ayırın

Kurumsal ölçekte şirket adına açılmış model, bulut ve veri hizmeti hesapları maliyet görünürlüğünü artırabilir; sağlayıcı yönetimi ise operasyonu sadeleştirebilir. Her iki durumda da model, API, veri ve sunucu giderlerini birlikte planlamak gerekir. Değişken gider sahibi, teklif satırında ve sözleşmede açıkça yazılmalı; kur artışı, kota değişikliği veya üçüncü taraf fiyat güncellemesi gibi risklerin nasıl ele alınacağı tanımlanmalıdır.

• Model sağlayıcı hesabının sahibi
• Bulut ve veri tabanı hesabının sahibi
• Üçüncü taraf API faturalarının ödeme yöntemi
• Aylık kullanım raporuna erişim yetkisi
• Hesap ve anahtarların devir teslim koşulları
• Fiyat değişikliklerinin müşteriye yansıtılma yöntemi

Yoğun dönem bütçesi ve maliyet sınırları nasıl kurulur

Yoğun dönem bütçesi, yalnızca normal ay ortalamasını belli bir oranla büyütmek yerine iş hacminin gerçekten nasıl yükseldiğini modelleyerek kurulmalıdır. Kampanya, kapanış dönemi, çağrı merkezi yoğunluğu, toplu belge işleme veya sezonluk talep agent kullanımını kısa sürede katlayabilir. Bu nedenle bütçe çalışmasında ortalama, yüksek ve olağanüstü kullanım senaryoları ayrı değerlendirilmeli; her senaryo için teknik ve mali sınırlar tanımlanmalıdır.

Limitleri operasyonel kurallara dönüştürün

Sadece parasal tavan koymak yeterli değildir. Günlük işlem sayısı, kullanıcı başına görev limiti, pahalı modellerin hangi koşulda devreye gireceği, başarısız görevlerin kaç kez tekrar edileceği ve hangi işlemlerin insan onayına düşeceği belirlenmelidir. Maliyet alarmı ve otomatik koruma kuralları, beklenmedik tüketimi erken görünür kılar; ancak kritik iş süreçlerinde limiti aşınca agentı sessizce durdurmak yerine kontrollü bir yedek akış tasarlanmalıdır.

• Normal kullanım için aylık referans bütçe
• Yoğun dönem için ayrı kapasite senaryosu
• Günlük ve kullanıcı bazlı işlem limitleri
• Model veya araç bazlı harcama eşikleri
• Tekrar deneme ve zaman aşımı sınırları
• Limit aşımında insan onayı veya alternatif akış

Pilot verileri tam ölçekli agent bütçesine nasıl çevrilir

Pilot sonuçlarını tam ölçekli bütçeye çevirmek için önce pilotta ölçülen görev başı tüketim ile gerçek operasyon hacmi eşleştirilmelidir. Pilot yalnızca birkaç uzman kullanıcıyla yürütüldüyse, canlı sistemdeki kullanıcı sayısı kadar doğrudan çarpma yapmak yanıltıcı olabilir. Farklı departmanların görev sıklığı, yoğun saatleri, başarısız işlem oranı, ortalama belge büyüklüğü ve insan onayı gerektiren durumlar ayrı ayrı hesaba katılmalıdır.

Pilot ortalaması yerine dağılımı ölçün

Tek bir ortalama değer yerine düşük, tipik ve yüksek tüketimli görev grupları oluşturmak daha sağlıklıdır. Böylece hangi senaryonun bütçeyi sürüklediği anlaşılır ve optimizasyon önceliği belirlenir. Sağlayıcı değerlendirmesinde pilot sonuçları ile canlı sistem desteğinin birlikte incelenmesi, yalnızca demo başarısına göre karar vermeyi önler. Pilot ölçümü teklifin varsayımı değil, ölçekleme modelinin veri kaynağı olmalıdır.

• Görev türüne göre ortalama model tüketimi
• Başarılı ve başarısız işlem oranlarının ayrılması
• Kullanıcı ve departman bazlı işlem hacmi
• Yoğun saatlerde eşzamanlı kullanım seviyesi
• Belge boyutu ve arama yükünün dağılımı
• Canlı kullanım için güvenlik ve kapasite payı

Araç çağrıları ve belge araması maliyeti nasıl değiştirir

Araç çağrıları ve belge araması, agentın yalnızca model tüketimini değil toplam işlem zincirini büyüttüğü için maliyeti doğrudan etkiler. CRM, ERP, e-posta, harita, ödeme, arama, belge yönetimi veya özel API gibi her harici sistem kendi kullanım ücreti, gecikme süresi ve hata olasılığına sahip olabilir. Aynı şekilde RAG tabanlı belge araması; veri hazırlama, indeksleme, vektör depolama, sorgu ve yeniden sıralama maliyetleri oluşturabilir.

Her entegrasyonu ayrı tüketim merkezi olarak izleyin

Agent mimarisinde hangi araçların gerçekten gerekli olduğu ve hangi çağrıların toplulaştırılabileceği tasarım aşamasında değerlendirilmelidir. ERP, CRM ve doküman süreçleri için agent mimarisi planlanırken görev zincirinin gereksiz yere uzaması hem performansı hem bütçeyi olumsuz etkileyebilir. Araç çağrısı maliyeti yalnızca API faturası değildir; hata yönetimi, kimlik doğrulama, loglama ve entegrasyon bakım yükü de toplam sahip olma maliyetine dahildir.

• Her görevde yapılan harici API çağrısı sayısı
• Arama indeksinin büyüklüğü ve sorgu yoğunluğu
• Yeniden sıralama veya ek model çağrıları
• Kimlik doğrulama ve güvenlik katmanları
• Entegrasyon hatalarında yeniden deneme davranışı
• Üçüncü taraf servislerin minimum paket ücretleri

Kalite izleme ve bakım giderleri teklifte nasıl yer alır

Kalite izleme ve bakım, canlı agent hizmetinin ayrı bir maliyet kalemi olarak teklifte tanımlanmalıdır. Agent doğru yanıt verse bile model sürümleri, API değişiklikleri, veri kaynakları, erişim yetkileri ve iş kuralları zaman içinde değişebilir. Bu nedenle yalnızca “sistem çalışıyor mu” kontrolü yeterli değildir; görev başarısı, hata nedenleri, maliyet sapmaları, gecikme, insan müdahalesi ve güvenlik olayları düzenli olarak izlenmelidir.

Bakım kapsamını hizmet seviyelerine bölün

Teklifte izleme paneli, hata kaydı incelemesi, prompt ve akış iyileştirmeleri, model değişikliği testleri, entegrasyon güncellemeleri ve olay müdahalesinin hangilerinin dahil olduğu açıkça yazılmalıdır. Agent bakım maliyeti sabit aylık hizmet, belirli saat paketi veya kullanım ve olay hacmine bağlı hibrit modelle yapılandırılabilir. Önemli olan müşterinin hangi işi sürekli hizmet kapsamında, hangi işi yeni geliştirme talebi olarak satın alacağını önceden bilmesidir.

• Başarı ve hata oranlarının düzenli takibi
• Model ve prompt performansının kalite kontrolü
• Entegrasyon ve API değişikliklerinin yönetimi
• Güvenlik logları ve erişim kayıtlarının incelenmesi
• Maliyet sapmaları için alarm ve raporlama
• SLA kapsamındaki olay müdahalesi ve destek süresi

AI agent proje teklifinde hangi varsayımlar açık olmalıdır

AI agent proje teklifinin karşılaştırılabilir olması için kullanım varsayımlarının açık ve ölçülebilir şekilde yazılması gerekir. Aylık kullanıcı sayısı tek başına yeterli değildir; kullanıcı başına görev sıklığı, görev türleri, ortalama bağlam büyüklüğü, entegrasyon sayısı, belge hacmi, yoğun dönem davranışı ve insan onayı oranı gibi değişkenler belirtilmelidir. Bu varsayımlar yoksa iki sağlayıcının fiyatını yan yana koymak gerçek kapsam farklarını gizleyebilir.

Teklifte senaryo bazlı bütçe tablosu isteyin

İyi bir ticari teklif, kesin kullanım bedeli vaat etmek yerine belirlenmiş varsayımlara göre senaryolar sunmalıdır. yapay zekâ otomasyon tekliflerini kapsam ve entegrasyon açısından karşılaştırmak, sadece ilk geliştirme fiyatına odaklanmaktan daha sağlıklı bir satın alma çerçevesi oluşturur. Kurumsal agent fiyatlandırması için teklif belgesinde maliyet alarmı, sorumluluk matrisi, kullanım raporu ve varsayım değiştiğinde bütçenin nasıl güncelleneceği de bulunmalıdır.

• Aylık ve günlük beklenen görev hacmi
• Görev türlerine göre model ve araç kullanımı
• Yoğun dönem ve kapasite artışı varsayımları
• Model, bulut ve üçüncü taraf giderlerinin sahibi
• Maliyet alarmı ve raporlama yöntemi
• Bakım, izleme ve destek kapsamı

Kurumsal agent fiyatlandırması için karar çerçevesi

Kurumsal agent fiyatlandırması değerlendirilirken amaç tek bir düşük kullanım rakamı bulmak değil, bütçenin hangi koşullarda nasıl değiştiğini anlayabilmektir. Karar verici; geliştirme bedelini, değişken işletme giderini, yoğun dönem riskini, bakım sorumluluğunu ve hesap sahipliğini aynı çerçevede değerlendirmelidir. Böylece teklif, yalnızca başlangıç yatırımını değil canlı sistemin sürdürülebilir işletme modelini de gösterir.

Teklifi ölçülebilir işletme planına dönüştürün

Satın alma öncesinde sağlayıcıdan pilotta ölçülecek metrikleri, canlıya geçiş varsayımlarını ve maliyet sapması durumunda uygulanacak aksiyonları yazılı olarak istemek gerekir. En güvenilir bütçe yaklaşımı, güncel birim fiyatları sabit kabul etmek yerine tüketimi ölçmek ve fiyat katmanını gerektiğinde güncelleyebilecek bir model kurmaktır. Böyle bir yapı, farklı model veya altyapı seçenekleri değerlendirilirken de toplam bütçenin hangi bileşenden etkilendiğini görünür tutar.

• Sabit geliştirme ve değişken işletme bedelini ayırın
• Pilot sırasında görev başı tüketimi ölçün
• Ortalama ve yoğun dönem senaryolarını ayrı hesaplayın
• Maliyet sahibi ile hesap sahibini sözleşmede tanımlayın
• İzleme, bakım ve SLA kapsamını netleştirin
• Alarm eşikleri ve bütçe gözden geçirme periyodu belirleyin