Demo bir ihtimaldir, pilot bir provadır

Üretime geçemeyen pilotların önemli bir kısmı aslında hiç pilot olmadı; uzatılmış birer demoydu. Demo, teknolojinin elverişli koşullarda neler yapabileceğini gösterir: seçilmiş örnekler, temiz veri ve sunumu yapan kişinin nereye tıklamaması gerektiğini bilmesi. Pilotun işi ise başkadır. Pilot, üretimin provasını yapar: gerçek kullanıcı grubu, eksiği ve mükerrer kayıtlarıyla gerçek veri, sistem kısıtları ve önceden düşünülmüş başarısızlık hâlleri.

Ayrım için basit bir karar kuralı var: sunumu yapan kişiyi sahneden çektiğinizde deneyim çöküyorsa elinizdeki bir demodur. Üretim koşullarında kurgulanmış pilot kimse izlemezken çalışır. Kullanıcı sıradan bir salı günü sisteme girer, bir istisnaya çarpar; sistem bunu ya çözer ya da planlanmış bir şekilde devreder. Elinizdekine dürüst bir etiket koymak bile yönetime verdiğiniz sözü ve ‘başarının’ ne anlama gelebileceğini değiştirir.

Başarıyı doğrulukla değil, davranışla ölçün

Model doğruluğu bir laboratuvar metriğidir; benimseme ise saha metriği. Bir pilot bütün doğruluk hedeflerini tuttursa da kullanılmayabilir, çünkü doğruluk, bir çalışanın yeni araçla zaten güvendiği eski yöntem arasında seçim yaptığı o birkaç saniye hakkında hiçbir şey söylemez.

Bu yüzden başarı kriterleri pilot başlamadan davranış diliyle yazılmalı. Hedef kullanıcılar hatırlatma almadan geri dönüyor mu? İnsan onayı hangi adımda darboğaza dönüşüyor, hangi adımda atlanıyor? İstisnaları kim, ne kadar sürede çözüyor? Karar süresi gerçekten kısalıyor mu? Çıktının ne kadarı kullanılmadan önce yeniden işleniyor? Ürünün işin bir parçası hâline gelip gelmediğini gösteren sinyaller bunlardır.

Benimsemeye değer bir kural: altıncı haftada kullanım hâlâ hatırlatma e-postasına muhtaçsa, model metrikleri ne derse desin pilot başarısızdır. Bakılacak yer model değil, iş akışının kendisidir.

Üretim yolunu pilottan önce çizin

Kurumsal AI'daki en pahalı cümle şudur: ‘Üretimi sonra düşünürüz.’ Erişim, entegrasyon, veri saklama, güvenlik incelemesi ve operasyon modeli kendi hızında ilerler; bu hız çoğu kurumda sprint'le değil komite döngüsüyle ölçülür. Bu bağımlılıkları son haftasında keşfeden pilot geç başarısız olmamıştır; kickoff'ta başarısız olmuş, bunu geç duyurmuştur.

İşe yarayan pilot brief'i, pilot ile üretim arasındaki her bağımlılığı listeler ve her satırın karşısına bir karar sahibinin adını yazar: kaynak sisteme üretim erişimini kim onaylıyor, veri saklama kuralına kim imza atıyor, ürünü canlıya çıktıktan sonra kim işletiyor, maliyet hangi bütçeye yazılıyor. Adı boş kalan satır, projenin gerçek risk kaydıdır.

Varsayımsal bir örnek: hasar özeti taslakları üreten bir pilot yürüten sigorta şirketini düşünün. Üretim, poliçe ana sistemine okuma erişimi gerektirsin ve bu erişim önünde uzun bir kuyruk bulunan güvenlik incelemesinden geçsin. İncelemeyi pilotun başında başlatmakla pilotun başarısından sonra başlatmak arasındaki fark, çoğu zaman lansman ile aylarca sürecek bir bekleme arasındaki farktır.

Üretimin proje ekibi değil, sahibi olur

Pilotu proje ekibi yürütür; üretimi ise kurum yaşar. Pilot başarıya ulaştığı gün proje yapısı dağılır ve cevapsız sorular ortaya çıkar. Prompt'ları ve kuralları kim iyileştirecek? İnsan onayı kuyruğundan çıkanları kim inceleyecek? Bağlı sistem API'sini değiştirdiğinde kim müdahale edecek? Çalıştırma ve destek maliyeti kimin bütçesinden çıkacak? Cevap ‘herhalde tedarikçi’ ya da ‘IT bakar’ ise pilot, tam hızlanması gereken anda durur.

Karar kuralı: canlıya geçiş tarihi konuşulmadan önce iş biriminin içinden, yalnızca IT'den değil, bir ürün sahibi atanmalı ve üç şey yazılı olarak netleşmeli: işletme bütçesi kalemi, hatalı çıktılar için eskalasyon yolu ve kullanım ile sonuç metriklerinin gözden geçirilme ritmi. Sahiplik, sonda yapılan bir devir teslim töreni değildir; pilotun ilk haftasından itibaren masada olması gereken bir roldür.

Entegrasyon ve erişim tuzağı

Pilotlara genellikle geçici ve istisnai erişim verilir: bir veri dökümü, bir sandbox, tek seferlik bir token. Hızlıdır; bu yüzden herkes bunu seçer. Üretim ise aynı erişimin sıkıcı, yönetişimli hâlini ister: servis hesapları, rol bazlı yetkiler, audit trail ve bağlanılan sistemlerin süreklilik taahhütleri. Bunlar farklı taleplerdir; farklı kişilerce, farklı takvimlerde onaylanır.

Başarısızlık mekanizması tahmin edilebilir. Pilot, istisnai erişim üzerinde değerini kanıtlar; ardından yönetişimli erişim talebi sıfırdan başlar ve kuyruktaki diğer bütün entegrasyonlarla yarışır. İvme bekleme odasında ölür. Çözüm, pilot erişimini mümkün olduğunca üretim güzergâhından geçirmektir: gerçek kimlik doğrulama deseni, gerçek yetki modeli, bilinçli olarak daraltılmış bir veri kesiti. Böylece pilotun başarısı, kendi onay süreçlerinin de provası olur.

Kontrol listesi kısadır. Ürünün dokunduğu her sistem için kickoff'ta üç soru sorun: üretim düzeyinde erişim neye benziyor, onayı kim veriyor, genellikle ne kadar sürüyor?

Kanıtla, küçültülmüş bir Geliştir adımı değil, risk azaltma aracıdır

Haritala → Önceliklendir → Kanıtla → Geliştir → Kuruma Yerleştir → Etkiyi Büyüt yöntemimizde Kanıtla adımının işi, en riskli varsayımları yeterli olan en ucuz kanıtla test etmektir. Kimi varsayım için tıklanabilir bir prototip yeter: ekip bu akışa güvenir mi? Kimi için teknik bir spike gerekir: bu sistemle kabul edilebilir gecikmeye ulaşabiliyor muyuz? Kontrollü bir pilotu hak eden varsayım sayısı sanıldığından azdır. Refleks hâlinde ‘pilot yapalım’ demek yerine kanıt aracını varsayıma göre seçmek, üretime geçiş riskinin büyük kısmını daha oluşmadan ortadan kaldırır.

Bu seçim yapıldığında üretim koşullarında kurgulanmış pilot dar ve dürüst bir provaya dönüşür: gerçek kullanıcılar, kapsamı belirlenmiş veri, üretim erişim deseni, davranışsal başarı kriterleri ve sahipleri baştan yazılmış bir üretim yolu. Pilot başarılı olursa Geliştir adımına sıçrama kısa sürer, çünkü sıçramanın büyük kısmı zaten yapılmıştır. Başarısız olursa ucuza ve net biçimde başarısız olur: hangi varsayımın yanlış çıktığını bilirsiniz.

Bugün bekleyen bir pilotunuz varsa teşhis tek bir çalışma oturumuna sığar. Bu bir pilot mu, yoksa pilot adı taşıyan bir demo mu? Başarı kriterleri davranışsal mı? Her üretim bağımlılığının karşısında bir isim ve işlemeye başlamış bir takvim var mı? Bu üç sorunun cevabı, ‘model hazır değil’ tartışmasını çoğu zaman somut bir karar listesine çevirir.