6 Temmuz 2026'da arXiv'e konan bir değerlendirme, kalite denetiminden geçmiş 302 Kubernetes olayını retrieval-augmented modellerin önüne koydu ve iki yeteneği ayrı ayrı puanladı. Kök nedeni olan servisi adlandırmak: zamanın %91,4 ile %99,7'si arasında doğru. Az önce teşhis ettiği olay için geçerli bir kurtarma eylemi seçmek: %36,8 ile %60,3. Bu iki sütunun arasında kırk ila elli beş puan var ve bu mesafe, AIOps hakkında bu yıl yayımlanmış en kullanışlı sayı.

Bu, model kalitesi hakkında değil iş türleri hakkında bir iddia. Model iyi okuyor, kötü karar veriyor ve bu, pazarı iki yığına ayırıyor. Bazı operasyonel işler görünür şekilde, onu tutan kişinin gözünün önünde başarısız olur. Bazıları ise üretime karşı bir eyleme dönüşerek başarısız olur. AIOps parasını birinci türde kazanıyor, ikincisinde ise şu anda bir yükümlülük; bu pazardaki hayal kırıklığının çoğu da birincinin demosunu izleyip onu ikincisi için satın almaktan geliyor.

Alarm korelasyonu, tekilleştirme ve hikayenin ilk taslağı

PagerDuty, AIOps ürününü alarm gürültüsünü %91'e varan oranda kesen bir ürün olarak pazarlıyor. Bunu, NeuBird sponsorluğunda 1.039 SRE, DevOps ve BT operasyonları profesyoneliyle Şubat 2026'da yapılan ve katılımcıların %44'ünün geçen yıl bastırılmış ya da göz ardı edilmiş alarmlara bağlı bir kesinti bildirdiği anketin yanında okuyun. Kırk çağrıyı tek bir olaya katlayan korelasyon gerçek bir kazançtır. Hangi çağrıları hiç görmeyeceğinize sessizce karar veren korelasyon ise o %44'ün oluşma biçimidir; ikisini ayıran şey de gruplamanın incelenebilir olup olmadığıdır.

En güçlü vakalar, bir insanın saniyeler içinde kontrol edebildiği vakalar. Deploy geçmişini, metrik kaymasını ve üç log akışını okuyup olay anlatısının taslağını çıkaran bir model, aksi halde sabahın 3'ünde hafızası zayıf biri tarafından yapılacak bir işi yapıyor; yanıldığında ise kanıt, yazdığı paragrafın içinde duruyor. Bir faturanın neden hareket ettiğini açıklamak da aynı türden bir iş, bir insanın bir ay geç fark ettiği korelasyonlarla dolu; FinOps Foundation'ın 19 Şubat 2026'da yayımlanan, yıllık 83 milyar doların üzerinde harcama yöneten 1.192 katılımcıyı kapsayan State of FinOps 2026 raporu da bunların %98'inin artık yapay zeka harcaması yönettiğini buldu - iki yıl önce bu oran %31'di. Çözülmüş bir olayı yazılı bir runbook'a dönüştürmek daha da iyi: gerçekler yerine oturmuştur ve en kötü sonuç, bir insanın bir cümleyi düzeltmesidir.

Altyapıda AI code review bir hata sınıfını yakalar, bir başkasına kördür

Veracode'un 28 Temmuz 2026'da yayımlanan 2026 GenAI Code Security Report raporu 100'den fazla modeli test etti ve ortalama güvenlik geçme oranının %55'ten bir puan artışla %56'da takıldığını buldu. Kimse özellikle güvenlik için prompt yazmadığında üretim görevlerinin kabaca %44'ü riskli bir açık getirdi. En iyi performansı gösteren GPT-5.5 %68'e ulaştı ve yine de üç güvenlik görevinden birinde başarısız oldu.

Dengesiz olan kısım, işe yarayan kısım. Bu modeller SQL injection görevlerini zamanın %83'ünde, kriptografiyi %87'sinde geçti; ama cross-site scripting'i yalnızca %15, log injection'ı %12 oranında geçti. Bir AI reviewer, bin kez etiketlenmiş halde gördüğü şeyde güçlüdür, başka yerde neredeyse kördür ve hangi modda olduğunu size söylemez. Bir infrastructure-as-code diff'inde onu, sonradan bakınca bariz olan hatalar için ikinci bir okuyucu olarak kullanın: 0.0.0.0/0'a açılmış security group, bir güncelleme değil bir değiştirme olan değişiklik. Onu geçit yapmayın: kaçırdığı sınıflar, kimsenin kural yazmadığı sınıflardır.

Otonom remediation, kanıtın sunumu desteklemeyi bıraktığı yer

Aynı çalışma, self-healing konuşmasını bir yıl daha bitirmesi gereken bulguyu da taşıyor. Model hem kök nedeni olan servisi hem de arıza tipini doğru tespit ettiğinde bile, doğru teşhis edilen bu olayların %39,5 ila %62,0'sinde geçersiz bir remediation seçti. Teşhis, eyleme taşınmıyor. Gartner'ın Haziran 2025'te agentic yapay zeka projelerinin %40'ından fazlasının 2027 sonuna kadar iptal edileceğine dair yaptığı tahmin, maliyetin yanında yetersiz risk kontrollerini de sayıyordu ve eksik olan tam da bu.

Kapasite planlaması da ilgili bir sebeple başarısız oluyor: model, zayıf kanıttan kendinden emin bir sayı üretiyor ve bir planlama toplantısının istediği şey de kendinden emin bir sayı. AB Yapay Zeka Yasası Madde 14 tam olarak buna karşı yazılmış; bir insan gözetmenin yüksek riskli bir sistemi kesintiye uğratabilmesini ve güvenli bir durumda durdurabilmesini şart koşuyor ve gözetimin direnmesi gereken şey olarak otomasyon yanlılığını adlandırıyor.

Harcama tavanı, sağlayıcının faturalama konsolunun üstünde durmalı

Mayıs 2026'da otonom bir ajana kısıtlamasız AWS credential'ları verildi ve bir hobi ağı olan DN42'yi port taramasından geçirmesi söylendi. Ajan, her biri 48 vCPU'lu beş m8g.12xlarge instance'ı, artı load balancer'lar ve Lambda fonksiyonları provision etti; sonra aynı CloudFormation template'ini yeniden uygulamayı sürdürdü. Operatör bunu yaklaşık 24 saat sonra, toplamı 6.531,30 dolar olan kredi kartı harcamalarından öğrendi - topluluğun aylık 5 dolarlık bir VPS'e sığacağını hesapladığı bir workload için. AWS faturayı sonradan 1.894 dolara indirdi. İşe yarayan koruma bir iyi niyet kredisiydi.

Büyük sağlayıcıların hiçbirinin bütçe araçları bunu durduramazdı ve üçü de bunu yazılı olarak söylüyor. Amazon, AWS Budgets'ın günde en fazla üç kez yenilendiğini ve her güncellemenin tipik olarak bir öncekinin 8 ila 12 saat gerisinde kaldığını belgeliyor - pahalı hatalarını teker teker yapan insanlar için kurulmuş bir tempo. Microsoft, aşılmış bir Azure bütçe eşiğinin kaynakları etkilemediğini veya tüketimi durdurmadığını, maliyet verisinin ise tipik olarak 8 ila 24 saat içinde hazır olduğunu belirtiyor. Google Cloud, yalnızca uyarı veren bir bütçenin kullanımı veya harcamayı otomatik olarak sınırlamadığını belirtiyor. AWS, bir bütçenin %90'ında devreye giren, tek bir region'da dört servisi kapsayan ve storage ile networking'in ücret tahakkuk ettirmeyi sürdürdüğünü kabul eden açık kaynaklı bir Budget Controls çözümü yayınlıyor. Temmuz 2026'da yazılan üç kişilik bir ajans ise, saldırganlar bir instance'tan statik anahtarları çekip bunları Bedrock model çağrılarına harcadıktan sonra, normalde aylık 10 ila 15 dolar olan faturasına karşılık tek günde 14.000 dolarlık bir AWS ücreti yedi.

Bizim cevabımız, limiti faturanın derlendiği yere değil credential'ların verildiği yere koymak. Sencai'de harcama, sağlayıcıya, projeye ve ortama göre gerçekleştiği anda izleniyor; limitler ve bütçeler 8 ila 24 saatlik bir faturalama döngüsünde değil, harcama tahakkuk ederken uyarıyor. Aşılan bir limit üzerine otomatik olarak harekete geçmek yol haritamızda var ama shiplenmiş değil; yani bugün credential'ı hâlâ bir insan çekiyor. Yapay zeka, önceden sınırlayabildiğimiz tek bütçe: kredi olarak satın alınıyor ve bir kredi, bir token sayısı değil sabit bir para tutarı; dolayısıyla bir model fiyat değişikliği, bir kredinin kaç token aldığını değiştirir, o kredinin ne değerde olduğunu asla değiştirmez. Her ücretli kişisel planın aylık bir ödeneği ve bunun bir katı olarak belirlenmiş katı bir tavanı var; böylece kontrolden çıkan bir script sınırsız bir fatura üretemez. Runbook'lar da aynı sebeple onay kapılı: model önerir, adı belli bir insan yürütür.

Bunu bir insanın mı yoksa bir modelin mi yaptığını söyleyebilen bir denetim izi

AB Yapay Zeka Yasası Madde 12(1), yüksek riskli sistemlerin, sistemin ömrü boyunca olayların otomatik kaydedilmesine teknik olarak izin vermesini şart koşuyor; Madde 26(6) ise başka bir hukuk daha uzun demedikçe uygulayıcıların bu logları en az altı ay saklamasını zorunlu kılıyor. Ağustos 2026 tarihine göre planlama yapıyorsanız, düzeltin. 27 Temmuz 2026'dan itibaren yürürlükte olan yapay zekaya ilişkin Dijital Omnibus, yani (AB) 2026/1744 sayılı Tüzük, Ek III bağımsız yüksek riskli sistemleri 2 Aralık 2027'ye, Ek I ürüne gömülü sistemleri ise 2 Ağustos 2028'e taşıdı. Tarihler taşındı; yükümlülükler taşınmadı.

Bunu inşa etmenin operasyonel sebebinin son tarihle hiçbir ilgisi yok. Bir olaydan altı ay sonra soru, değişikliği bir insanın mı yoksa bir modelin mi yaptığıdır; yapay zeka eylemlerini bir sistemde, insan eylemlerini başka bir sistemde kaydeden bir kurulum ise bunu kimsenin güvenmediği bir join olmadan cevaplayamaz. İki ayrı kayıt tutmayı reddettik: model eylemleri ve insan eylemleri tek bir yalnızca-ekleme izine düşüyor. Sencai bunu her satırda entry_hash ve prev_hash ile birlikte CSV olarak export ediyor; böylece sözümüze güvenmeyen bir okuyucu zinciri yeniden hesaplayabiliyor. Yerini hak eden alan ise actor'ün yanındaki o küçük alan: değişikliğin bir insandan mı, yoksa bir insanın ödeneğini harcayan bir modelden mi geldiğini söyleyen alan.

Kanıttan çıkan kural gösterişsiz ve tutuyor. Bir modelin her şeyi okumasına izin verin, kötü okuduğu şeyler dahil; çünkü kötü bir okuma, yazdığı paragrafta görünür. Yazmasına ise yalnızca adı belli bir kişinin değişikliği imzaladığı ve o kişi de yanılırsa diye altında bir credential limitinin durduğu yerde izin verin. 8 ila 24 saatlik bir döngüde gelen sağlayıcı bildirimi ile hafta içi e-posta okuyan biri arasında bir duman dedektörü vardır, yangın söndürme sistemi yoktur. DN42 operatörünün bir duman dedektörü vardı.