Pilot Uygulamadan Öteye Geçemeyen AI Projeleri: Nerede Tıkanıyoruz? 🚧
Geçen yazımda model seçerken parametre sayısına değil, kendi verinizle kurduğunuz test setine bakın demiştim. Diyelim ki bunu yaptınız: doğru modeli seçtiniz, pilot uygulamayı kurdunuz, toplantıda demoyu yaptınız ve herkes etkilendi.

Sonra ne oluyor?
Sahada gördüğüm tablo şu: AI projelerinin büyük kısmı teknik olarak başarısız olduğu için değil, pilot aşamasında sıkışıp kaldığı için ölüyor. Üstelik kimse “bu proje iptal” demiyor. Proje bir süre sonra sadece konuşulmaz oluyor; sunum klasörde kalıyor, süreç eskisi gibi elle yürümeye devam ediyor.
Bu yazıda pilotu canlıya taşırken tıkandığımız noktaları tek tek konuşalım. Çünkü hepsinin ortak bir özelliği var: hiçbiri modelle ilgili değil.
⚠️ Önce Şu Yanılgıyı Kıralım: “Ama Demoda Çalışıyordu”
Pilotta %85 doğruluk etkileyici bir rakamdır. Canlıda aynı %85, günde 200 evrak işleyen bir ekip için “her gün elle düzeltilecek 30 evrak” demektir.
Demo ile canlı arasındaki fark yüzde farkı değil; hacim ve sorumluluk farkıdır. Demoda hata bir anekdottur, canlıda hata bir maliyettir. Pilotun kolay görünmesinin sebebi de tam olarak budur: pilotu hep en temiz veriyle, en iyi senaryoyla ve en meraklı kullanıcıyla yaparız.
🚧 Tıkandığımız 6 Nokta
1. Yanlış soruyla başlamak. Çoğu proje “yapay zeka ile neler yapabiliriz?” sorusuyla başlıyor. Bu soru teknolojiyi merkeze koyar ve sonunda kimsenin ihtiyaç duymadığı şık bir demo üretir. Doğru soru şudur: “Bu ay ekibimin en çok zamanını hangi iş yiyor?” İlk yazımda anlattığım proforma → banka talimatı otomasyonu tam olarak böyle doğmuştu; teknolojiden değil, tekrar eden bir acıdan.
2. İstisnaları görmezden gelmek. Pilot “mutlu yolu” çözer, canlı ise istisnaları sorar. Gümrük evrakı örneğimi düşünün: pilotta hep düzgün taranmış, tek dilde, tam sayfalı PDF'ler vardır. Sahada ise ters taranmış sayfa, üzerine el yazısıyla not düşülmüş evrak, iki sayfası eksik dosya, aynı dosyanın içinde iki farklı beyanname çıkar. Bir sürecin %80'ini otomatikleştirip kalan %20'yi tanımsız bırakırsanız, ekip her seferinde “bu hangi gruba giriyor?” diye durmak zorunda kalır ve otomasyondan beklenen hız kazancı sıfırlanır. İstisnaları çözmek zorunda değilsiniz; ama sistemin onları tanıyıp “bunu insana yönlendir” diyebilmesi zorunludur.
3. Son 20 metre problemi. Model çıktıyı üretir, ekranda gayet güzel görünür. Peki oradan ERP'ye nasıl gidiyor? Cevap “kullanıcı kopyalayıp yapıştırıyor” ise o süreç otomatik değildir, sadece yer değiştirmiştir. Pilotların büyük kısmı burada takılır; çünkü zor sanılan model tarafı bitmiştir, geriye can sıkıcı olan kalmıştır: yetkiler, kayıt formatı, hata durumunda geri alma, log tutma. Bir projeyi canlıya taşıyan şey modelin zekası değil, çıktının gideceği yere kendi başına gidebilmesidir.
4. Sahibi olmayan proje. Pilotu genelde meraklı tek bir kişi yürütür. O kişi izne çıktığında proje de izne çıkar. Canlıya geçmek; sürecin bir sahibi, bir yedeği ve “bozulursa kimi arayacağız?” sorusuna net bir cevabı olması demektir. Bunlar yoksa ekip riski üstlenmez ve sessizce eski yönteme döner. Eski yöntem yavaştır ama tanıdıktır; belirsizlik karşısında insan her zaman tanıdık olanı seçer.
5. Ölçmediğiniz şeyi savunamazsınız. “Gerçekten çok iyi oldu” cümlesiyle iş yapılmaz. Pilotu başlatmadan önce mevcut durumu ölçmek gerekir: bu iş şu an kaç dakika sürüyor, ayda kaç kez yapılıyor, kaç hata çıkıyor, o hatanın maliyeti ne? Başlangıç ölçümü (baseline) yoksa, pilot bittiğinde elinizde sadece bir izlenim kalır. Varsa, elinizde “ayda 40 saat ve şu kadar hata” gibi savunulabilir bir sayı olur. Canlıya geçiş kararı çoğu zaman teknik bir karar değil, bu sayının olup olmamasıyla ilgili bir karardır.
6. Güven ve sorumluluk katmanının kurulmamış olması. Vizyon yazımda sorduğum soruya geri dönüyoruz: direksiyonda kim var? Sistem banka talimatındaki IBAN'ı yanlış okursa sorumlu kim? Bu sorunun net bir cevabı yoksa, sistem ne kadar iyi çalışırsa çalışsın kimse o “gönder” butonuna basmaz. Çözüm yapay zekayı kusursuzlaştırmaya çalışmak değil; kritik alanları belirleyip onları insan onayına bağlamaktır. Tutar, IBAN, vergi numarası, miktar gibi alanlar ekranda karşılaştırmalı gösterilip onaylanır, gerisi akar. Güven, modelin doğruluğundan değil, sürecin tasarımından gelir.
✅ Pilotu Canlıya Taşıyan 5 Kural
1️⃣ Pilotu en temiz değil, en kirli veriyle başlatın. Elinizdeki en kötü 20 örneği toplayın ve sistemi onlarla deneyin. Orayı geçerseniz gerisi zaten gelir.
2️⃣ İlk gün baseline ölçün. Süre, adet, hata oranı. Bunları sonradan geriye dönüp ölçemezsiniz.
3️⃣ Kapsamı “son 20 metre” dahil tanımlayın. Çıktı nereye yazılacaksa pilot oraya kadar gitmeli. Kopyala-yapıştır kalan her adım, projenin canlıya geçmeme sebebidir.
4️⃣ Kritik alan listesini önceden çıkarın. Neyin insan onayı gerektirdiğini baştan yazın. Bir hata olduktan sonra tartışmak güveni geri getirmez.
5️⃣ Dar ama uçtan uca seçin. Bir sürecin tamamını çözmek, beş sürecin yarısını çözmekten kıyaslanamayacak kadar değerlidir. Yarım kalan beş süreç, ekibe beş yeni takip işi demektir.
🎯 Son Söz
Pilot, bir şeyin mümkün olduğunu gösterir. Canlı ise o şeyin sürdürülebilir olduğunu gösterir. Aradaki mesafe neredeyse hiçbir zaman model kalitesiyle ilgili değildir; süreç, sahiplik, entegrasyon ve güvenle ilgilidir.
Bu yüzden bir AI projesine başlarken kendime sorduğum ilk soru artık “bunu yapabilir miyiz?” değil. Soru şu: “Bu çalışırsa yarın sabah kim kullanacak ve bozulduğunda kim düzeltecek?”