"İnsan kontrolünde kalsın" cümlesi yapay zeka tartışmalarında en sık duyulan ifadelerden biridir. Ancak bu cümle tek başına bir süreç tarif etmez. Kontrol hangi anda yapılacak, kontrol eden kişi neye bakacak, onay verilmezse iş nereye dönecek? Bu sorular cevapsız kaldığında insan onayı ya bir formaliteye dönüşür ya da çalışanlar her çıktıyı baştan yazarak aracın faydasını ortadan kaldırır. Bu yazıda bir acentenin iş akışında insan onayının nerelere konabileceğini, kontrol ölçütlerinin nasıl tanımlanabileceğini ve onay adımının nasıl kayıt altına alınabileceğini ele alıyoruz.
Her çıktı aynı riski taşımaz
Kontrol noktalarını belirlemenin ilk adımı, yapay zeka çıktılarını risklerine göre ayırmaktır. Kurum içi bir toplantı notunun özeti ile müşteriye gidecek bir teminat açıklaması aynı dikkat seviyesini gerektirmez. Pratik bir ayrım şöyle yapılabilir:
- Düşük risk: Yalnızca ekip içinde kalan, kişisel veri içermeyen çıktılar. Örneğin bir eğitim dokümanının sadeleştirilmiş hali.
- Orta risk: Müşteri kaydına işlenecek ama müşteriye gönderilmeyecek çıktılar. Örneğin bir yazışmanın konusuna göre etiket önerisi.
- Yüksek risk: Müşteriye doğrudan ulaşan veya bir işlemi tetikleyen çıktılar. Örneğin teklif sonrası gönderilecek açıklama metni ya da eksik evrak bildirimi.
Düşük riskte hafif bir okuma yeterli olabilirken yüksek riskte iki aşamalı kontrol düşünülebilir. Bu ayrım yapılmadan konan tek tip onay adımı, ya gereksiz yük ya da yetersiz güvence üretir.
Kontrol noktalarının üç tipik yeri
Girdi aşaması
Çoğu hata çıktıda değil girdide başlar. Araca hangi bilginin verildiği, eksik ya da yanlış bir verinin modele aktarılıp aktarılmadığı ilk kontrol noktasıdır. Örneğin bir yazışma özetlenmeden önce müşteri kimliğini doğrudan tanımlayan alanların çıkarılıp çıkarılmadığına bakılır.
Çıktı aşaması
Üretilen metin veya öneri, kullanılmadan önce belirli ölçütlere göre okunur. Burada önemli olan kontrol edenin neye bakacağını bilmesidir. "Bir göz at" talimatı yerine kısa bir kontrol listesi daha tutarlı sonuç verir.
Etki aşaması
Çıktı bir işleme dönüştüğünde, yani müşteriye gönderildiğinde, kayda işlendiğinde veya bir görevi tetiklediğinde son bir onay adımı yer alır. Bu adım özellikle geri alınması zor işlemler için kritiktir.
Kontrol eden kişi neye bakmalı?
Yüksek riskli bir müşteri mesajı için kullanılabilecek örnek ölçütler:
- Metindeki her somut bilgi (tarih, branş, belge adı) müşteri kaydıyla örtüşüyor mu?
- Metin bir teminat, muafiyet veya prim konusunda kesin bir taahhüt içeriyor mu? İçeriyorsa kaynağı doğrulandı mı?
- Trafik, kasko ve DASK bilgileri birbirine karıştırılmış mı? Her branşın kendi süreci olduğu metinde korunuyor mu?
- Üslup acentenin müşteriyle kurduğu ilişkiye uygun mu?
- Metin gereksiz kişisel bilgi içeriyor mu?
Bu liste her acentenin kendi deneyimiyle genişletilebilir. Önemli olan, kontrolün kişiden kişiye değişen bir sezgiye değil, ortak ölçütlere dayanmasıdır.
Onay verilmediğinde ne olur?
Kontrol noktası tasarlanırken genellikle unutulan konu reddedilen çıktının akıbetidir. Üç seçenek tanımlanabilir:
- Düzelt ve devam et: Küçük hatalarda kontrol eden kişi metni düzeltip onaylar.
- Geri gönder: Girdi eksikse, örneğin müşteri kaydında güncel olmayan bilgi varsa, önce kayıt düzeltilir sonra süreç tekrar başlar.
- Elle yap: Bazı durumlarda aracın katkısı yoktur; iş baştan çalışan tarafından yürütülür ve bu durum not edilir.
Reddedilen çıktıların nedenleri düzenli olarak gözden geçirildiğinde, aracın hangi işlerde zorlandığı da görünür hale gelir.
Onay yorgunluğundan kaçınmak
Her adımda onay istemek, bir süre sonra çalışanların okumadan onaylamasına yol açabilir. Bunu önlemek için kontrol noktaları gerçekten risk taşıyan adımlarla sınırlandırılmalı, düşük riskli işlerde örnekleme yöntemiyle kontrol yapılabilir. Örneğin iç dokümanların tamamı yerine belirli bir kısmı haftalık olarak incelenir. Böylece dikkat, en çok gereken yere yönlendirilir.
Kayıt altına almak
Onayın kendisi de bir veridir. Hangi çıktının kim tarafından, ne zaman onaylandığı veya reddedildiği kayıt altına alındığında, hem iç denetim hem de müşteri sorularına cevap vermek kolaylaşır. Bu kaydın müşteri kartıyla ilişkili olması, dosyayı devralan bir çalışanın geçmişi anlamasını sağlar.
InsureHub'da müşteri kayıtları, teklif geçmişi ve poliçe bilgisi aynı yapıda tutulur; alt kullanıcılar kendi yetkileri çerçevesinde bu kayıtlar üzerinde çalışır. Anlattığımız onay modeli acentenin kendi süreç tasarımıdır ve yazılımda bir yapay zeka özelliği olarak sunulmaz; ancak onayların bağlanacağı müşteri ve işlem kaydını düzenli tutmak bu modelin ön şartıdır. Müşteri kartının nasıl kurgulandığını acente CRM sayfasında, teklif tarafındaki ayrı akışları ise sigorta teklif programı sayfasında görebilirsiniz.
Küçük ve büyük ekiplerde onay modeli
Onay modelinin biçimi ekip büyüklüğüne göre değişir. Üç dört kişilik bir acentede aynı kişi çoğu zaman hem taslağı hazırlar hem de son kontrolü yapar. Bu durumda en azından yüksek riskli mesajlar için kısa bir bekleme kuralı faydalıdır: Taslak hazırlandıktan sonra birkaç dakika ara verip metni yeniden okumak, ilk okumada gözden kaçan hatayı yakalatabilir. Şubeli ve kalabalık ekiplerde ise kontrol rolü branş bilgisine göre dağıtılabilir; kasko açıklamalarını teminat yapısını iyi bilen bir çalışan, DASK bilgilendirmelerini ise adres ve konut süreçlerine hakim bir çalışan onaylayabilir. Her iki modelde de onay ölçütlerinin aynı kalması, acentenin müşteriye karşı tutarlı bir kalite sunmasını sağlar.
Özet
İnsan onayı, yapay zekaya duyulan güvensizliğin değil, mesleki sorumluluğun bir parçasıdır. Çıktıları risk seviyesine göre ayırmak, kontrol noktalarını girdi, çıktı ve etki aşamalarına yerleştirmek, ölçütleri yazılı hale getirmek ve reddedilen çıktıların akıbetini tanımlamak bu sorumluluğu sürdürülebilir kılar. Bu yapının kendi verinizle nasıl işleyebileceğini görmek için demo talebi oluşturabilirsiniz.