Bir yapay zekâ demosunda her şey düzgün görünebilir. Seçilmiş bir belge yüklenir, beklenen soru sorulur, yanıt hızla gelir. Gerçek kullanımdaysa belgelerin bazıları eskidir, kullanıcı soruları eksiktir ve herkesin aynı bilgiye erişme yetkisi yoktur. Pilot ile çalışan bir hizmet arasındaki mesafe tam burada başlar.
Kısa cevap: Yapay zekâ PoC'si, bir fikrin belirli koşullarda uygulanabilirliğini sınar. Canlıya geçiş için ise temsil edici testler, risk bazlı kabul ölçütleri, erişim sınırları, insan onayı, işletim sorumlusu ve geri dönüş planı gerekir. Başarılı demo, bu kontrollerin yerine geçmez.
New Academy'nin yapay zekâ danışmanlığı kapsamında ele aldığı PoC ve uygulama çalışmaları, bu kararları kapsamla birlikte netleştirmeyi amaçlar. Bu yazı, araç kurulum rehberi değil; pilotun hangi kanıtlarla canlı kullanıma hazırlanabileceğine ilişkin bir değerlendirme rehberidir.
PoC hangi soruyu cevaplıyor?
PoC, “yapay zekâ bu işi yapabiliyor mu?” gibi geniş bir soruyla başlarsa bitiş noktası belirsiz olur. Daha dar bir soru seçin: Onaylı prosedürlerden kaynak gösteren yanıt hazırlanabilir mi? Gelen talepler mevcut sınıflara ayrılabilir mi? Uzman, taslağı düzelterek mevcut yöntemden daha az toplam emek harcıyor mu?
Bu sorunun cevabı olumsuz da olabilir. Belge kalitesi yetersizse veya hatanın etkisi kabul edilemeyecek düzeydeyse pilotun değeri, erken durdurma kararı vermek olabilir. Projeyi başarılı göstermek için hedefi test sonunda değiştirmeyin; değişiklik gerekiyorsa yeni değerlendirme turunu açıkça ayırın.
Test kümesini gerçek işin çeşitliliğiyle kurun
Yalnızca kolay örnekler, sorunun önemli bölümünü görünmez bırakır. Normal işler, istisnalar, eksik girdiler, çelişen kaynaklar ve yanıt verilmemesi gereken durumlar ayrı örneklenmeli. Geliştirme sırasında kullanılan örneklerle son değerlendirme örneklerinin ayrılması, aynı sorulara göre ayarlanmış çözümü yeniden sınama riskini azaltır.
Kurgusal bir kurum içi bilgi asistanını düşünelim. Testte doğru prosedürü bulma kadar şu durumlar da bulunmalı: eski ve yeni sürümün birlikte gelmesi, kaynakta cevap bulunmaması, başka departmanın kısıtlı belgesine ilişkin soru ve belgede asistana farklı görev vermeye çalışan bir metin.
Test verisinin kullanımı kurumca onaylanmalı. Gerçek kişilere ait bilgi gerekli değilse sentetik örnek veya uygun biçimde anonimleştirilmiş veri tercih edilmeli. Hukuki uygunluk ve bilgi güvenliği kararları ilgili kurum ekiplerine aittir.
Tek bir başarı yüzdesine sıkışmayın
Yanıtların büyük bölümünün iyi görünmesi, az sayıdaki kritik hatayı önemsiz yapmaz. Değerlendirmeyi işin riskine göre parçalara ayırın:
- Görev başarısı: İstenen iş tamamlanıyor mu, yoksa kullanıcı tekrar başlamak zorunda mı?
- Kaynak desteği: Önemli iddialar gerçekten erişilen belgeyle destekleniyor mu?
- Hata etkisi: Yanlışlık yalnızca bir yazım düzeltmesi mi, yoksa yanlış kişiye bilgi verme riski mi?
- Çekimser kalma: Kaynak yetersizken sistem bunu söyleyebiliyor mu?
- İnsan emeği: Kontrol ve düzeltme dahil toplam süre ne kadar?
- İşletim yükü: Yanıt süresi, kesinti ve kullanım maliyeti beklentiye uygun mu?
Her ölçüt için inceleme yöntemi ve karar sorumlusu yazılmalı. Bazı alanlarda otomatik kontrol kullanılabilir; işin anlamını ve hata etkisini değerlendirmek için süreç uzmanına ihtiyaç devam eder. Eşikler bu yüzden tüm projelere uygulanacak tek bir “yeterli doğruluk” oranından türetilmemeli.
Araç çağıran sistemlerde yetkiyi ayrıca sınayın
Bir asistanın yanıt taslağı üretmesiyle e-posta göndermesi veya müşteri kaydını değiştirmesi aynı risk düzeyi değildir. Araca erişim verildiğinde hangi işlemin hangi kullanıcı adına yapılabildiği açık olmalı. Salt okunur erişim yeterliyken yazma izni vermeyin; yüksek etkili işlem için insan onayı ve uygulama tarafında denetim kurun.
OWASP'ın Excessive Agency açıklaması, aşırı işlev, yetki ve özerkliğin risklerini ele alır. Sınırlı izinler ve etkili işlemlerde insan onayı önerir. Modelin bir talimata uymasını beklemek, erişim kontrolünün yerine geçmez; izinler bağlı sistemlerde de uygulanmalıdır.
Bu nedenle test listesinde “doğru işlemi yapıyor mu?” kadar “izin verilmeyen işlemi yapamıyor mu?” sorusu da bulunmalı. Yönetişim ve güvenlik danışmanlığı bu sınırları süreç ve sorumluluklarla birlikte değerlendirmeye yardımcı olur.
İnsan onayı görünür ve anlamlı olmalı
Onay düğmesi koymak tek başına yeterli değildir. Kullanıcı hangi verinin kullanılacağını, neyin değişeceğini ve işlemin geri alınabilir olup olmadığını görebilmeli. Kaynağı belirsiz bir öneriyi yalnızca “onaylıyor musunuz?” sorusuyla sunmak, kontrol yükünü kullanıcıya devretmekten öteye geçmeyebilir.
Örneğin kurgusal bir satış asistanı teklif e-postası hazırlıyorsa, alıcı, fiyatın dayandığı belge, indirim ve ek dosyalar gönderimden önce gösterilebilir. Gönderme yetkisi ayrı değerlendirilir. Pilot döneminde yalnızca taslak üretmek, tam otomasyona geçmeden önce davranışı gözlemlemek için uygun bir sınır olabilir.
Canlıya geçişi üç karardan biriyle sonuçlandırın
- Sınırlı kullanıma geç: Belirlenen kullanıcı grubu ve iş türleri için kabul koşulları karşılanmıştır; izleme ve destek hazırdır.
- Revize et ve yeniden test et: Veri, akış veya kontrollerde düzeltme gerekir. Yeniden testin kapsamı ve sorumlusu belirlenir.
- Durdur veya başka yönteme geç: Beklenen katkı gösterilememiştir ya da risk ve işletim koşulları uygun değildir.
Kararı yalnızca geliştirmeyi yapan ekip vermemeli. İş sahibi, teknik sorumlu ve gerekli kontrol ekipleri kendi alanlarını değerlendirmeli. Başarılı örnekler kadar başarısızlıklar da raporda korunmalı. Teslimat rehberinde bu kararın hangi belgelerle desteklenebileceğini bulabilirsiniz.
Devir dosyası ve geri dönüş planını hazırlayın
Canlıya alınan hizmetin sahibi belli olmalı. Veri kaynağı, model veya talimat değiştiğinde hangi testlerin tekrar çalıştırılacağı; hatalı yanıtı kimin inceleyeceği; kullanım maliyetinin kim tarafından izleneceği yazılmalı. Kayıtların içeriği ve saklanması kurum politikalarıyla uyumlu olmalı; izleme adına gereksiz hassas veri biriktirilmemeli.
Geri dönüş planı da somut olsun: Sistem nasıl durdurulacak, kullanıcı eski yönteme nasıl geçecek, yarım kalan işler nerede görülecek? Otomasyon durduğunda işin de tamamen durduğu bir düzen kurmamak gerekir. Devir, dosya tesliminden çok bu sorumlulukların kurumda karşılık bulmasıdır.
İlk kullanım bir bitiş değil, yeni bir gözlemdir
Pilot koşullarını geçen çözüm, kullanıcı davranışı ve veri değiştikçe farklı hatalar verebilir. Başlangıçta sınırlı kullanım, düzenli örnek incelemesi ve açık geri bildirim kanalı bu nedenle değerlidir. Ölçüm devam etmiyorsa birkaç hafta sonra hâlâ aynı kalitede çalıştığını bilmek güçleşir.
Kurumunuzun pilotu hazırsa ama işletim koşulları belirsizse, yeni bir araç aramadan önce kabul ölçütlerini ve devir sorumluluklarını netleştirin. New Academy ile iletişime geçerek mevcut durumu paylaşabilir, danışmanlık çalışmasının keşif, test ve canlıya geçiş hazırlığında hangi bölümlere odaklanacağını belirleyebilirsiniz.