AI PoC'tan Üretime: Yayına Almadan Önce 12 Maddelik Kontrol Listesi

AI PoC'tan Üretime: Yayına Almadan Önce 12 Maddelik Kontrol Listesi

AI PoC'tan üretime kontrol listeniz, demonun demo olmaktan çıktığı gün başlar. Sorun şu: salı günü ekibi büyüleyen zarif bir prototip, sessizce 40.000 dolarlık bir OpenAI faturası açabilir, gerçek trafik altında donabilir ve kimsenin test etmediği girdilerde halüsinasyon görebilir. Gartner, Temmuz 2024'te üretken yapay zeka projelerinin en az %30'unun kavram kanıtlaması (PoC) sonrasında terk edileceğini öngördü. Bunun nedeni modelin zayıf olması değil. Yayın gününden önce kimsenin güvenlik önlemlerini kurmamış olması.

Bir demo, modelin bunu bir kez yapabildiğini kanıtlar. Üretim ise bunu 10.000 kez, bütçe dahilinde ve siz izlemeden yapabildiğini kanıtlar. Bu 12 kontrol, ikisi arasındaki geçiş kapısıdır.

Bir AI PoC Ne Zaman Üretime Hazırdır?

Bir AI PoC, onu geliştiren kişi olmadan başka bir ekip tarafından çalıştırılabildiğinde, izlenebildiğinde ve ödemesi yapılabildiğinde üretime hazır demektir. Bu; gerçek veriyle çalışma, bir değerlendirme (eval) temeli, maliyet kontrolleri, hız sınırlama ve yedek mantığı, gözlemlenebilirlik ve geri alma planlı kademeli bir yayın anlamına gelir. Sadece geliştiricisi izlerken çalışıyorsa, hâlâ bir demodur.

12 maddenin tamamı, fazlara göre gruplanmış şekilde tek bakışta aşağıdadır. Her biri altta ayrıntılı olarak ele alınıyor.

Çoğu AI PoC Neden Hiç Üretime Ulaşmıyor?

Çoğu AI proof of concept'ten üretime geçiş çabası, model kalitesinden değil operasyonel nedenlerden dolayı tıkanır. Demo, sorunsuz senaryoyu (happy path) yönetir; üretimde ise maliyet sıçramaları, hız sınırları, kesintiler ve geliştiricinin hiç hayal etmediği girdiler vardır. Bu boşlukları kapatın, aynı model sorunsuz şekilde yayına girer.

Gartner, Temmuz 2024'te üretken yapay zeka projelerinin en az %30'unun 2025 sonuna kadar kavram kanıtlaması sonrasında terk edileceğini öngördü; nedeni olarak zayıf veri kalitesini, yetersiz risk kontrollerini, artan maliyetleri ve belirsiz iş değerini gösterdi. Bunu kesin bir gerçek değil, bir tahmin olarak değerlendirin, ama başarısızlık nedenlerini isabetle ortaya koyuyor.

Ağustos 2025'te yayımlanan bir MIT raporu olan The GenAI Divide, üretken yapay zeka pilotlarının yaklaşık %95'inin ölçülebilir bir yatırım getirisi (ROI) sağlayamadığını ortaya koydu. Bu, dağıtım değil ROI ile ilgili bir bulgu; ama örüntü aynı: yayına giren pilotlar bile maliyet, güvenilirlik ve çıktı kalitesini kanıtlama konusunda tıkanıyor.

Çoğu AI PoC, model kötü olduğu için başarısız olmaz. Yayın gününden önce kimse güvenlik önlemlerini, maliyet limitlerini ya da yedek yolu kurmadığı için başarısız olur.

Faz 1 — Sağlamlaştırma: Temelleri Düzeltin (1-4. Maddeler)

Tek bir canlı kullanıcı özelliğe dokunmadan önce veriyi, evalleri, güvenliği ve maliyet modelini doğru şekilde kurun.

1. Gerçek Veri Hattı

Önce demonun sentetik girdilerini gerçek üretim veri yoluyla değiştirin. Prototipler temiz, özenle seçilmiş veri alır; üretim ise bozuk satırlar, eski kayıtlar ve planlamadığınız kişisel verilerle (PII) karşılaşır. Özelliği canlı kaynağa bağlayın, şemayı doğrulayın ve hangi kişisel verinin aktığını teyit edin. AWS Prescriptive Guidance, bunu çalışan bir üretken yapay zeka yapısının temeli olarak tanımlıyor. Tamamlanma koşulu: özellik, manuel hazırlık olmadan üç veya daha fazla ardışık gün boyunca uçtan uca canlı veride çalışıyor.

2. Eval Temeli / Altın Veri Seti

Yayına girmeden önce "yeterince iyi"yi bir sayıyla tanımlayın. 30 ila 100 gerçek girdi alın, her biri için beklenen çıktıyı yazın; elinizde bir altın veri seti olur. Her derlemeyi bu sete karşı, dağıtımları kapıda tutan bir geçme eşiğiyle (örneğin %90 veya üzeri) puanlayın. Bu olmadan, regresyonlar bir test çalıştırması yerine bir destek talebinde ortaya çıkar. Bir eval paketi nasıl kurulur, işte burada. Tamamlanma koşulu: tekrarlanabilir bir eval, derlemeyi sabit bir eşiğe göre puanlıyor.

3. Güvenlik ve Gizlilik İncelemesi

Modelinizin nelere erişebildiğini denetleyin: API anahtarları, araçlar, veritabanları, kullanıcı verisi. Prompt enjeksiyonuna uğramış bir girdi, gizli bilgileri okuyabilmemeli veya erişmemesi gereken bir aracı çağıramamalı. Kişisel verileri (PII) sağlayıcıya ulaşmadan önce maskeleyin ve sağlayıcının veri saklama koşullarını kontrol edin (mümkün olduğunda eğitim verisi kullanımından çıkın). Tamamlanma koşulu: veri akışı ve erişim incelemesi onaylandı, prompt'larda gizli bilgi yok ve PII maskeleme her dış çağrıdan önce çalışıyor.

4. Maliyet Modeli ve Token Bütçesi

Çalıştırma başına maliyetinizi ve aylık üst sınırınızı, ilk ürkütücü faturadan öğrenmek yerine yayından önce bilin. Tipik bir isteğin token maliyetini beklenen hacimle çarpın, ardından kesin bir üst sınır ve uyarı belirleyin. Aşağıdaki kaldıraçlar, kaliteye dokunmadan bu rakamı düşürür.

Güncel fiyatlar için LLM API maliyetlerinizi nasıl düşüreceğinize bakın; sınırları ve yönlendirmeyi tek yerden uygulamak için bir LLM gateway üzerinden yönlendirin. Tamamlanma koşulu: çalıştırma başına maliyeti ve aylık üst sınırı biliyorsunuz; bütçenin %80'inde bir uyarı ve %100'de kesin bir durdurma var.

Faz 2 — Dengeleme: Gerçek Trafiğe Dayanacak mı? (5-9. Maddeler)

Model gayet iyi. Şimdi sırası, etrafındaki sistemin yükü, kesintileri ve kötü girdileri, kimseyi sabahın 3'ünde uyandırmadan atlatmasını sağlamakta.

5. Hız Sınırlama + Yeniden Deneme/Geri Çekilme

Tek bir kişinin tıkladığı bir demo her şeye dayanır; aynı kod gerçek trafik altında dakikalar içinde sağlayıcının hız sınırlarına çarpar. Kullanıcı başına istek limitleri belirleyin, üstel geri çekilme (exponential backoff) artı jitter ile yeniden deneyin ve sağlayıcıyı yormak yerine 429 ve Retry-After başlıklarına uyun. Birkaç ardışık başarısızlıktan sonra devreyi kesin (circuit-break) ki bir kesinti zincirleme yayılmasın.

call model
on 429 or timeout: wait (2 ^ attempt) seconds + jitter, retry up to 3x
after 5 consecutive failures: open circuit, use the fallback

Bunu kendiniz kurmak istemiyorsanız, bir LLM gateway yeniden denemeleri ve limitleri sizin yerinize halleder. Tamamlanma koşulu: kullanıcı başına limitler ayarlı ve yeniden denemeler sağlayıcının 429 yanıtlarında geri çekiliyor.

6. Yedek Mekanizma / Kademeli Düşüş

Model API'si yavaşladığında veya çöktüğünde kullanıcının ne göreceğine şimdiden karar verin, çünkü bu er ya da geç olacak. Bir yedek zinciri kurun: önbelleğe alınmış son bilinen iyi yanıt, daha ucuz veya ikincil bir model, ya da modeli tamamen atlayan deterministik bir yol. Zaman aşımını p95'inize bir pay ekleyerek belirleyin, çoğu senkron özellik için yaklaşık 8 saniye, sonra yedeği devreye sokun. Tamamlanma koşulu: test edilmiş bir düşüş yolu, zaman aşımında veya hatada devreye giriyor; böylece özellik hiçbir zaman öylece takılı kalmıyor.

7. Gecikme Hedefi + Yük Testi

Bir p95 gecikme hedefi belirleyin ve yük altında da bu hedefi tuttuğunuzu kanıtlayın. Senkron kullanıcı deneyimi için p95'in 3 saniyenin altında olmasını hedefleyin; daha uzun üretimlerde ise kullanıcının ilerlemeyi görmesi için token'ları akıtın (stream). Beklenen zirve eşzamanlılığın iki ila üç katında yük testi yapın. Sizde 900ms'de yanıt veren bir özellik, 50 kişi aynı anda geldiğinde 12 saniyeye çıkabilir. Tamamlanma koşulu: bir p95 hedefi belirlendi ve özellik gerçek eşzamanlılıkta yapılan bir yük testini geçti.

8. Gözlemlenebilirlik ve Loglama

Göremediğinizi düzeltemezsiniz; bu yüzden her çalıştırmayı loglayın: girdi, çıktı, gecikme, token sayısı ve çalıştırma başına maliyet. Bunları bir kontrol paneline yönlendirin ki durumu öfkeli bir kullanıcıdan değil, bir uyarıdan öğrenin. Tetikleyiciler belirleyin: hata oranı beş dakikada %2'yi aşarsa veya çalıştırma başına maliyet taban çizginin üzerine sıçrarsa uyarı verin. Bir AI gözlemlenebilirlik platformu size bunu kurmadan izler ve uyarılar sağlar. Tamamlanma koşulu: her çalıştırma loglanıyor, maliyet ve hata uyarıları bağlı.

9. İnsan Denetimi ve Güvenlik Önlemleri

Modele giren ve modelden çıkan her şeyi doğrulayın. Güvensiz içeriği engelleyin veya maskeleyin, yayından önce saldırgan (adversarial) ve uç durum girdilerini test edin, düşük güvenli veya yüksek riskli çıktıları bir kişiye yönlendirin. İnsan incelemesini tetikleyen bir güven eşiği belirleyin; bir iade onayı, modelin ilk tahminiyle doğrudan yayına girmemeli. Tamamlanma koşulu: girdi ve çıktı doğrulaması aktif, düşük güvenli sonuçlar bir kişiye yönlendiriliyor.

Faz 3 — Devreye Alma: Dramsız Yayın (10-12. Maddeler)

Yayın bir düğme değil, bir kadran gibidir. Yavaşça çevirin, rakamları izleyin ve geri dönüş yolunu açık tutun. Buradaki her madde, yayın öncesi verilmesi gereken bir karardır.

10. Kanarya / Kademeli Yayın

Önce kullanıcıların küçük bir dilimine yayınlayın ve kapıları tamamen açmadan önce rakamları izleyin. Önce %5'e, sonra %25'e, ardından %100'e kademeli yayınlayın; her aşamada eval geçme oranını, hata oranını, gecikmeyi ve maliyeti kontrol edin. Her aşamayı 24 ila 48 saat tutun ve yalnızca hata oranı %2'nin altında kalırsa ve maliyet bütçe dahilindeyse ilerleyin. Kanarya, önce %5'e yayınlamak ve tam olarak hangi hata oranının sizi geri almaya zorlayacağını bilmek demektir. Tamamlanma koşulu: yayın, yazılı ilerleme kriterleriyle kademelendirildi.

11. Geri Alma Planı + Nöbetçi Ekip

Özelliği saniyeler içinde kapatabilecek test edilmiş bir yönteminiz ve çağrı alacak bir kişiniz olsun. Bir özellik bayrağı (feature flag) veya sabitlenmiş önceki bir sürüm, geri alma yönteminizdir; kesin tetikleyicileri belgeleyin. Bunları somut şekilde belirleyin: hata oranı 10 dakika boyunca %5'i aşarsa veya çalıştırma başına maliyet üst sınırınızın iki katını geçerse otomatik geri alma yapın ve adı belirlenmiş bir nöbetçi sorumluyu çağırın. Test edilmemiş bir geri alma, geri alma sayılmaz. Tamamlanma koşulu: geri alma test edildi, tetikleyiciler açıkça belirlendi ve çağrı cihazının sorumlusu belli bir kişi.

12. Yayın Sonrası Sahiplik ve Ritim

Cuma günü yayına girmeden önce, pazartesi sabahı bu özelliğin sahibinin kim olduğunu belirleyin. Üretimdeki yapay zeka zamanla kayar: girdiler değişir, sağlayıcılar modelleri günceller ve geçen ayın eval puanı düşer. Eval tekrarlarını ve kayma (drift) kontrollerini planlayın (önce haftalık, sonra aylık) ve her prompt ile model sürümü için bir değişiklik günlüğü tutun. Tamamlanma koşulu: sorumlu bir runbook'ta belirlendi, ilk eval tekrarı planlandı ve bir sürüm günlüğü mevcut.

Techsy Bu Konuya Nasıl Yaklaşıyor

Teslimat sürecimiz de aynı üç fazla örtüşür. Keşif ve Tasarım aşamaları sağlamlaştırma işini kapsar: çok fazla kod yazmadan önce gerçek veriyi belirler, eval setini kurar, güvenlik incelemesini yapar ve maliyeti modelleriz. Geliştirme (Build) aşamasında dengeleme yaparız; yeniden denemeler, zaman aşımları, yedek zincirleri, gözlemlenebilirlik ve güvenlik önlemleri yayınla birlikte devreye girer. İşletme (Operate) ise devreye alma ve sonrasındaki her şeydir: kanarya yayını, test edilmiş geri alma, nöbetçi ekip ve eval tekrar ritmi.

Herhangi bir müşteri yapay zeka yapısı canlıya çıkmadan önce, aynı yayına-geçiş kapısını uygularız. Uyarılı kesin bir aylık maliyet üst sınırını, deterministik bir yedekle birlikte yeniden deneme ve zaman aşımı politikasını, bayrağı açmadan önce geçmesi gereken bir evali ve adı belirlenmiş bir nöbetçi sorumluyu doğrularız. Bir yapı bu dördünün tamamını geçemiyorsa, yayına girmez.

Bir özelliği zaten yayınladınız ve şimdi sağlamlaştırmak mı istiyorsunuz? Uygulamanıza yapay zeka özelliği ekleme rehberimiz geliştirme kısmını kapsıyor; bu kontrol listesi ise onu yayına hazır hale nasıl getireceğinizi gösteriyor. Yapay zeka özelliklerini üretime nasıl taşıdığımızı görmek için yapay zeka entegrasyonu çalışmalarımıza göz atın.

Sıkça Sorulan Sorular

Bir AI PoC ne zaman üretime hazırdır?

Onu geliştiren kişi olmadan başka bir ekip çalıştırabildiğinde, izleyebildiğinde ve ödemesini yapabildiğinde: gerçek üretim verisi, geçen bir eval, maliyet limitleri ve uyarılar, yeniden denemeler ve bir yedek mekanizma, test edilmiş geri almalı kademeli bir yayın. Sadece geliştiricisi izlerken çalışıyorsa, bu bir demodur.

Çoğu AI PoC neden hiç üretime ulaşmıyor?

Model kalitesinden değil, operasyonel nedenlerden dolayı. Gartner, Temmuz 2024'te üretken yapay zeka projelerinin en az %30'unun 2025 sonuna kadar kavram kanıtlaması sonrasında terk edileceğini öngördü; nedeni olarak zayıf veri kalitesi, yetersiz risk kontrolleri, artan maliyetler ve belirsiz değeri gösterdi. Güvenlik önlemleri hiç kurulmadı.

Bir AI PoC'yi üretime taşımak ne kadar sürer?

Tek bir özellik için yaklaşık 4 ila 12 hafta, genellikle 90 günlük bir süreç planlayın: birinci ay sağlamlaştırma (veri, evaller, güvenlik, maliyet), ikinci ay dengeleme (yeniden denemeler, yedek, gözlemlenebilirlik), üçüncü ay devreye alma (kanarya, geri alma, sahiplik). Karmaşık ajanlar veya sıkı uyum gereksinimleri bu süreyi uzatır.

Bir AI demosunda üretimin ihtiyaç duyduğu ama eksik olan nedir?

Bir demo, sorunsuz senaryoyu (happy path) bir kez gösterir. Üretim ise atlanan her şeyi ekler: dağınık gerçek veri, maliyet kontrolleri, hız sınırlama ve yeniden denemeler, kesintiler için bir yedek, yük altında gecikme hedefleri, güvenlik önlemleri ve bir geri alma planı. Model çoğu zaman aynıdır; eksik olan etrafındaki iskelettir.

Yayından önce AI/LLM maliyetlerini nasıl kontrol ederim?

Tipik bir çalıştırmanın token maliyetini beklenen hacimle çarpın, ardından kesin bir üst sınır ve bütçenin %80'inde bir uyarı belirleyin. Bunu prompt önbellekleme, daha ucuz modele yönlendirme, maksimum token sınırları ve gruplama (batching) ile düşürün. Çalıştırma başına maliyeti bilmeden asla yayına girmeyin.

Eval temeli nedir ve gerçekten buna ihtiyacım var mı?

Beklenen çıktılarla birlikte 30 ila 100 gerçek girdiden oluşan ve dağıtımları kapıda tutan sayısal bir geçme eşiğiyle her derlemeyi puanladığınız bir altın veri setidir. Evet, buna ihtiyacınız var: bu olmadan, regresyonlar bir test çalıştırmasından değil, destek taleplerinden ortaya çıkar. Kontrol listesindeki en ucuz sigortadır.

Bir AI özelliği için kademeli düşüş (yedek mekanizma) nedir?

Model API'si yavaşladığında veya çöktüğünde özelliğinizin ne yaptığıdır. Takılıp kalmak yerine bir yedeğe geçer: önbelleğe alınmış bir yanıt, daha ucuz bir model ya da deterministik bir yol. Zaman aşımını p95'e bir pay ekleyerek belirleyin, sonra devreye sokun. Kullanıcı bir hata yerine biraz daha kötü bir yanıt alır.

Üretim sürümünü kendi ekibimle mi kurmalıyım, yoksa dışarıdan destek mi almalıyım?

Daha önce bir LLM özelliğini yayınlamış ve işletmiş mühendisleriniz ve nöbetçi ekip için zamanınız varsa, kendi ekibinizle kurun. İlk üretim yapay zeka sisteminizse, takvim sıkışıksa veya operasyonel yükü kimse üstlenmiyorsa dışarıdan destek alın. Techsy bunu yapıyor; ama ekibiniz yayına-geçiş kapısını iyi işletiyorsa, işi kendi bünyenizde tutun.

Özet

Üç çıkarım var. Çalışan bir demo, bir üretim sistemi değildir; sadece modelin görevi bir kez yapabildiğini kanıtlar. Tıkanan çoğu AI özelliği, model kalitesinden değil maliyet, hız sınırları ve yedek mekanizma gibi operasyonel boşluklardan dolayı ölür. Çözüm, bayrağı açmadan önce bu 12 maddeyi faz faz (sağlamlaştırma, dengeleme, devreye alma) çalışmaktır. Sıkıcı işi önce yapın, yayın günü sessiz geçsin. Bunu tek başınıza yapmak istemiyorsanız, ücretsiz bir üretime hazırlık danışmanlığı alın.