Geçenlerde bir ekip toplantısında şu cümleyi duydum: “Dashboard’da harcama görünüyor, o zaman kontrol bizde.” Açık konuşayım, kulağa mantıklı geliyor. Ama işin aslı şu ki; görmek başka şey, durdurmak bambaşka şey (kendi tecrübem). Siz ne dersiniz? AI agent dünyasında da tam olarak bu ikisi birbirine karışıyor ve faturalar sessizce şişiyor.
Bence, Ben bu konuyu ilk kez 2024 sonbaharında, İstanbul’da küçük bir ürün ekibiyle konuşurken fark ettim. Üç kişilik ekip, bir müşteri destek ajanını test ediyordu; loglar temiz, metrikler güzel, her şey “idare eder” görünüyordu. Sonra ay sonunda bulut faturası geldi… kimse önce inanamadı. Çünkü sorun kullanımın fazla olması değildi; sorun, döngünün sınırının olmamasıydı. Hiç tavan yok. Sıfır.
Şimdi biraz daha sert söyleyeyim: AI tarafında çoğu ekip maliyeti izlemeyi öğrendi ama maliyeti gerçekten yönetmeyi henüz öğrenemedi. Aradaki fark küçük değil. Hatta bazen milyon dolarlık fark oluyor — lafın tam anlamıyla (bizzat test ettim)
Asıl mesele: Görünürlük var, fren yok
Hacker News’te dolaşan o kısa mesajı hatırlıyorum: “Production’da AI agent çalıştırırken 47 bin dolar yedik.” Mesaj tek satırdı. Ama altında yatan problem bayağı tanıdık geldi bana. Kimse “Bugün 47 bin dolar yakalım” dememişti — sadece bir döngü vardı ve o döngüye tavan koyan çıkmamıştı. Bu kadar basit, bu kadar acı.
İşin garibi, Bu noktada çoğu takımın yaptığı şey hep aynı oluyor: Bir FinOps paneli açılıyor, spend grafiğine bakılıyor, alarm threshold belirleniyor. Iş bitmiş sanılıyor. Hayır, bitmiyor. Çünkü bu araçlar size geçmişi anlatıyor; yani kasadan ne kadar para çıktığını gösteriyorlar, tabi gecikmeli olarak. Ama agent çalışırken cebinizden para akmasını anlık olarak kesmiyorsa… eh, orada biraz hayal kırıklığı var, diyelim.
Kritik ayrım şu: maliyet görünürlüğü size bilgi verir; maliyet kontrolü ise sistemin içine gömülü bir fren mekanizmasıdır. Biri muhasebe gibi davranır, diğeri güvenlik kemeri gibi. İkisini karıştırmayın.
AI agent ortamında “ne kadar harcadık?” sorusu yetmez. Asıl soru şudur: “Daha fazlasını harcamadan bunu nasıl durduruyoruz?”
Neden agent’lar klasik API çağrılarından daha tehlikeli?
Klasik API çağrısı basittir. İstek gider, cevap gelir, seans kapanır. Fatura da az çok bellidir. Agent ise öyle çalışmaz — kendi kendine karar verir, araç kullanır, sonucu okur, tekrar dener… yani biraz inatçı stajyer gibi davranır. İyi niyetli ama bazen fazla hevesli, bunu söyleyelim.
Yani, Geçen ay Ankara’da yaptığım küçük bir denemede bunu yeniden gördüm. Basit bir araştırma ajanı kurmuştum; amaç sadece üç kaynaktan özet çıkarmaktı, hepsi bu. İlk turda iyi gitti ama sonra tool response formatı bozuldu ve model aynı adımı defalarca denedi — dur durak bilmeden. On dakika içinde maliyet neredeyse planlanan bütçenin beş katına çıktı. Kötü haber şu ki sistem çökmedi, yani sorun daha geç fark edildi. Sessizce yandık.
Agent mimarisinde risk yaratan şey çoğu zaman büyük hata değil; ufak sapmaların zincirleme etkisi oluyor. Malformed output geliyor, context window tuhaflaşıyor, retry politikası gevşek kalıyor ya da tool çağrısı beklenmedik biçimde başarısız oluyor (buna dikkat edin). sonra hop, döngü uzuyor. Kısacası, ve uzuyor. Ve uzuyor.
Kağıt üstünde ucuz görünen senaryo
Diyelim ki ortalama step başına maliyetiniz 0,02 dolar olsun. On adımlık düzgün bir akışta bu iş komik derecede ucuz görünür: toplam 0,20 dolar civarı.
Bunu yaşayan biri olarak söyleyeyim, Ama aynı ajan retry loop’a girip 2 bin adım atarsa? O zaman rakam bir anda yaklaşık 40 dolara çıkar — ve artık “küçük deney” olmaktan çıkar, kötü sürpriz olur.
Bunu yüzlerce eşzamanlı session ile çarptığınızda tablo pek tatlı kalmıyor…
Kurumsalda neden daha hızlı büyüyor?
Küçük startup’larda zarar genelde hemen hissediliyor çünkü fatura can yakıyor. Biri masaya yumruğunu vuruyor (çoğunlukla kurucu). Kurumsalda ise dağıtılmış sahiplik yüzünden olay daha sinsi ilerliyor; ekipler ayrı ayrı optimize ettiğini sanıyor. Ortak havuz yanıyor. Kimse fark etmiyor. Fatura gelene kadar.
Bir de şu var: Enterprise ortamda gözler dashboard’a alışkın olduğu için herkes kendini güvende hissedebiliyor. Halbuki panelde kırmızı çizgi görmemek ile riskin olmaması arasında hiçbir bağ yok. Hiç. Sıfır bağ.
$400 milyonluk sızıntı bize ne anlatıyor?
Sektörde konuşulan kolektif sızıntının boyutu büyüdükçe mesele bireysel kötü yapılandırmadan çıkıp mimari probleme dönüşüyor. Analitik raporların söylediği şey kabaca şu: Büyük kurumlarda agent session’ları per-session limit olmadan çalışınca harcama sessizce şişiyor. Kimse bunu anlık olarak kesmiyor. Durum bu. Bu konuyla ilgili Yapay Zekâ Yığını: Geliştiricinin Gerçek Rehberi yazımıza da göz atmanızı tavsiye ederim.
| Konu | Maliyet görünürlüğü | Maliyet kontrolü |
|---|---|---|
| Ne yapar? | Tutarı raporlar | Harcamayı sınırlar veya durdurur |
| Zamanlama | Pozitif/negatif gecikmeli | Anlık ya da pre-execution |
| Nerede çalışır? | Bordro benzeri raporlama katmanı | Execution layer / runtime katmanı |
| Sorun çözer mi? | Kısmen | Evet, kökten olmasa da doğrudan müdahale eder |
Küçük bir detay: Bence en can alıcı eksik burada ortaya çıkıyor: Birçok ekip “budget alert” ile “budget enforcement” arasındaki farkı hafife alıyor — ya da hiç önemsemiyor bile diyebilirim. Uyarı almak faydalıdır elbette. Ama uyarının anlam kazanması için sistemin de buna kulak vermesi gerekiyor. Kulak vermiyor mu? O zaman uyarı sadece dekorasyon. Bu konuyla ilgili UTOPAI’den Dina’ya: Kişisel Yapay Zekânın Gerçek Hâli yazımıza da göz atmanızı tavsiye ederim. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Hmm, bunu nasıl anlatsamdı…
Peki çözüm ne? Tavan koymak şart mı?
Evet — kısa cevap bu kadar net aslında.
Ama işi sadece token sayısı üzerinden düşünmek de biraz kaba kaçabiliyor. Çünkü bazı workflow’lar token açısından hafif görünürken tool çağrıları yüzünden pahalılaşabiliyor; bazılarıysa tam tersi. Yani tek metriğe kilitlenmek çözüm değil, biraz daha bütünsel bakmak lazım.
Doğrusu, İyi tasarlanmış cost governance katmanı birkaç şeyi birlikte yapmalı: Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
- Her session için ayrı bütçe tanımlamalı;
- Cevap üretimi değil yürütme akışı üzerinde limit koymalı;
- Ajan kritik eşiğe gelince nazikçe kapatmalı;
- Dilerseniz farklı workflow türleri için farklı ceiling uygulamalı;
- Lojistik olarak loglama ve billing’i ayrı tutmalı ama birbirine bağlamalı. — bunu es geçmeyin
{
"session_budget": "5 USD",
"max_steps": 250,
"max_tool_calls": 40,
"on_limit": "terminate_session",
"fallback": "human_review"
}Böyle bakınca olay yazılım mühendisliği gibi görünüyor. Aslında finans disiplini de içeriyor — hani klasik anlamda sıkıcı olan kısım, evet o (ben de ilk duyduğumda şaşırmıştım). Yine de önemli çünkü bütçe yoksa inovasyon değil kaos büyüyor.
Küçük startup için pratik yaklaşım
Eğer on kişilik bir ekipseniz önce kaba koruma kurun. Session başına hard cap verin, en pahalı workflow’ları bulun ve onları gece gündüz izleyin. Geçen yıl Kadıköy’de konuştuğum iki kurucu aynısını yaptı; önce genel dashboard yerine tek tek akışları kısıtladılar ve ay sonunda sürpriz azaldı (buna dikkat edin). Bayağı azaldı, fark hissedilir düzeyde. Bu konuyla ilgili CoreWeave ile Anthropic’in Yeni Hamlesi: Nvidia Gücü Büyüyor yazımıza da göz atmanızı tavsiye ederim.
Küçük ekiplerin avantajı hızdır. Dezavantajı ise genelde disiplinin sonradan gelmesidir. Burada geciktirmeyin derim — ciddiyim.
Büyük kurum için yaklaşım farklı olmalı mı?
E tabi, bana kalırsa farklı olmalı. Kurumsalda policy engine gerekiyor; IAM mantığına benzer şekilde budget policy oluşturmak lazım. Tek seferde her şeyi değiştirmek yerine pilot uygulama yapmak daha sağlıklı olur — hem organizasyona hem de sinir sistemine iyi gelir.
Dürüst olmak gerekirse, Büyük organizasyonda asıl zorluk teknikten çok yönetişimdir. Her departman kendi hesabını masum görüyor ama ortak bulutta kimse gerçekten yalnız yaşamıyor. Bunu anlamak bazen yıllar alıyor, maalesef.
Nerede yanlış yapıyoruz?
Bence en yaygın hata “önce açalım sonra bakarız” yaklaşımı. Bu yaklaşım demo aşamasında tolere edilir ama production’da bedeli ağır olur. Benim Nisan 2026’da izlediğim bir iç testte ekip sadece prompt’u optimize etmişti; fakat retry politikasına dokunmadığı için tüketim yine patladı. Prompt iyi olsa bile çevre koşulları kötüyse sonuç değişmiyor. Bu kadar net.
Bir diğer problem de ölçümlemenin yanlış yerde yapılması. Model bazlı spend görmek güzel, ama session seviyesinde attribution yoksa hangi ajanın neden parladığını anlayamazsınız. Yani mutfağın sıcak olduğunu biliyorsunuz ama hangi ocak açık — onu bilmiyorsunuz. Yangını değil, ısıyı görüyorsunuz.
Dengeli bakarsak… iyi haber ne?
İyi haber şu ki çözüm mimari olarak mümkün. Çok karmaşık sihirlerden bahsetmiyoruz. Basit bütçe limitleri, iyi telemetry, run-time termination logic… bunlar gayet uygulanabilir şeyler. Rocket science değil.
Şunu fark ettim: Ama kötü haber de var: Bunları sonradan yamamak zor oluyor. En çok da üretime yayılmış onlarca ajan varsa geri dönüp düzenlemek can sıkabiliyor. Hatta biraz uğraştırıcı değil, bayağı uğraştırıcı — bunu yaşadım, biliyorum.
Sessiz faturalar devri bitmeli mi?
İşin garibi, Lafı gevelemeden söyleyeyim: Evet, bitmeli. Çünkü AI ajanlarını büyütmek istiyorsanız önce onların ekonomik davranmasını öğretmeniz gerekiyor. Yoksa modeller akıllanırken finans tablosu aptallaşıyor gibi garip bir manzara çıkıyor ortaya. Tam da öyle.
Neyse uzatmayayım: AI FinOps’un geleceği dashboard değil guardrail olacak. Dashboard gerekli, ama tek başına yeterli değil. Gerçek kontrol; execution layer’da, session düzeyinde, harcama limitiyle geliyor. İşte orada oyun değişiyor.
Sıkça Sorulan Sorular
AI FinOps ile cost governance aynı şey mi?
Hayır. AI FinOps genelde harcamayı izler ve raporlar; cost governance ise harcamayı önceden sınırlar veya gerektiğinde durdurur. Biri görünürlük sağlar,diğeri kontrol verir. (en azından benim deneyimim böyle)
Agent maliyetleri neden hızlı yükseliyor?
Çünkü agent’lar tek çağrı yapıp bitmiyor; loop içinde karar verip tekrar deniyorlar. Retry sayısı arttığında maliyet geometrik gibi şişebiliyor. Bilhassa tool hataları bu işi hızlandırıyor.
Küçük ekipler per-session budget kullanmalı mı?
Evet,kesinlikle kullanmalı. Küçük ekiplerde bile tek bir runaway loop bütçeyi bozabilir. Basit hard cap çoğu zaman büyük hasarı önlüyor.
Büyük şirketlerde hangi yöntem daha işe yarar?
Pilot bazlı policy enforcement daha mantıklı olur. Önce yüksek riskli workflow’lara limit koyup sonra kapsam genişletilebilir. Böylece operasyonu kilitlemeden kontrol sağlanır.
Kaynaklar ve İleri Okuma
Orijinal yazı — The $400M AI FinOps Gap: Why Cost Visibility Isn’t the Same as Cost Control
Microsoft Azure Cost Management Dokümantasyonu
FinOps Foundation — What is FinOps?
Bulutlar Arasında Agent Kurmak: ADK, ECS Express ve Gemini
`
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
