Neyi Devretmeli, Neyi Devretmemeli: İnsan + AI İş Bölümü

Otomasyon serimiz boyunca fatura okumadan n8n senaryolarına, otomatik raporlamadan satış teklifine kadar somut kurulumlar gördük. Bu son yazı, hepsinin ortak paydası olan bir soruyu ele alıyor: hangi işi AI'a gerçekten devredebilirsiniz, hangisinde mutlaka bir insan gözü olmalı? Bu soruyu birkaç otomasyon kurmadan soyut olarak cevaplamak zor; şimdi somut bir çerçeveyle cevaplayalım.

"İnsan döngüde" ne demek, neden önemli?

Human-in-the-loop (insan döngüde), otomasyonun işin büyük kısmını yapması ama önceden tanımlı kontrol noktalarında, özellikle geri döndürülemez veya yüksek riskli eylemlerden önce, açık bir insan onayı gerektirmesi anlamına geliyor. Kritik nokta şu: insan sadece yargı, yetki veya hesap verebilirlik gerektiren döngülerde bulunmalı, her döngüde değil. Burada gözden kaçan bir risk var: "otomasyon rehaveti". İnsanlar sisteme aşırı güvenip anormallikleri rasyonalize etmeye, çıktıları sorgulamayı bırakmaya başlıyor; sistem ne kadar güvenilir görünürse, gözetimci o kadar dikkatsizleşiyor. Çoğu kurum insanı "döngüye" koyuyor ama neyi onaylayacağı, ne zaman eskale edeceği konusunda hiç eğitmiyor. AB Yapay Zeka Yasası'nın 14. maddesi ve NIST'in AI Risk Yönetimi Çerçevesi bu yüzden insan gözetiminin "eğitilmiş, ölçülebilir ve kanıtlanabilir" olmasını şart koşuyor, sadece "biri izliyor" demek yetmiyor.

Somut bir örnek üzerinden gidelim: bir müşteri hizmetleri botu düşünün, ilk üç ayda kusursuz çalışıyor ve ekip artık çıktıları neredeyse hiç kontrol etmiyor. Dördüncü ayda bot bir konuda yanlış bilgi vermeye başlıyor ama kimse fark etmiyor, çünkü "zaten hep doğru çalışıyordu" varsayımı yerleşmiş durumda. Bu, otomasyon rehavetinin klasik bir örneği; çözüm karmaşık bir teknik önlem gerektirmiyor, düzenli aralıklarla (örneğin ayda bir) rastgele birkaç çıktıyı bağımsız birinin kontrol etmesi gibi basit bir alışkanlık yeterli oluyor.

Risk ve geri döndürülebilirlik çerçevesi

MindStudio'nun dört katmanlı risk çerçevesi somut bir başlangıç noktası: Katman 1 (sadece okuma, veritabanı sorgulama, e-posta okuma) tam otonom çalışabilir. Katman 2 (taslak e-posta, CRM'e kayıt ekleme, dosya taşıma gibi geri alınabilir işler) otonom olabilir ama kayıt tutulmalı. Katman 3 (e-posta gönderme, sosyal medya paylaşımı gibi dışarıya açık ve "bir kez kutuya düştü mü geri alınamaz" işler) inceleme veya hız sınırı gerektiriyor. Katman 4 (ödeme işlemleri, hesap/veri silme, üretime kod dağıtımı, erişim izni değişikliği) mutlaka insan onayı istiyor.

Amazon'un "tek yönlü kapı / çift yönlü kapı" ayrımı da devretme kararına uyarlanabiliyor: düşük risk + kolay geri döndürülebilir ise tamamen devredin (bir pazarlama A/B testi gibi); düşük risk + zor geri döndürülebilir ise gözetim altında devredin (marka renk değişikliği gibi); yüksek risk + kolay geri döndürülebilir ise ihtiyatlı devredin; yüksek risk + zor geri döndürülebilir ise (bir şirket satın alma kararı gibi) liderlik kontrolünde tutun.

Bu iki çerçeveyi (MindStudio'nun 4 katmanı ve Amazon'un kapı ayrımı) birlikte kullanmak, tek başına birinden daha güvenilir sonuç veriyor. Bir eylem MindStudio çerçevesinde "Katman 2" (geri alınabilir) görünse bile, Amazon çerçevesinde "zor geri döndürülebilir" çıkabiliyor; örneğin bir CRM kaydını güncellemek teknik olarak geri alınabilir ama o kayda dayanarak alınmış başka kararlar varsa gerçekte geri almak zorlaşıyor. İki çerçeveyi yan yana koyup her ikisinde de "düşük risk" çıkan işleri tam otonom bırakmak, herhangi birinde "yüksek risk" çıkanlara ise onay eklemek daha güvenli bir yaklaşım.

AI ajanlarının otonomi seviyeleri

Otomotivdeki SAE 0-5 otonom sürüş seviyelerinden esinlenen bir çerçeve, AI ajanlar için de kullanılıyor (resmi bir standart değil ama faydalı bir zihinsel model): Seviye 1, dar ve önceden tanımlı işlemler yapan "belirleyici görev botu" (parola sıfırlama gibi). Seviye 2, çok adımlı taslak hazırlayan ama üretim öncesi onay gerektiren "hazırlık ajanı" (sözleşme redline'ı gibi). Seviye 3, rutin bir iş akışını uçtan uca yöneten ama belirsizlikte insana yönlenen "dar operatör". Seviye 4, yaklaşık yüzde 98 doğrulukla çalışan ve sadece anormal durumda onay isteyen "yarı özerk uzman". Seviye 5, açık uçlu hedefleri olan "özerk problem çözücü"; çerçeveyi geliştirenler bunun çoğu kurumsal iş akışı için gereksiz ve güvensiz olduğunu özellikle vurguluyor. Bu seride kurduğumuz otomasyonların çoğu (fatura okuma, n8n senaryoları) Seviye 2-3 bandında kalıyor; bu genelde KOBİ'ler için doğru bir hedef.

Onay katmanı nasıl tasarlanır?

Velt'in dört seviyeli onay modeli pratik bir şablon sunuyor: Seviye 1'de onay yok (veri okuma, taslak oluşturma). Seviye 2'de "bildir ve devam et" (ajan hemen hareket ediyor ama insan geri alabiliyor, bir takvim daveti gibi). Seviye 3'te tek onaylayıcı (sözleşme oluşturma, müşteri iletişimi, bütçe değişikliği). Seviye 4'te çok paydaşlı onay (düzenleyici dosyalama, büyük işlemler).

İyi tasarlanmış bir onay akışının üç şartı var: bağlamsal entegrasyon (onay isteği zaten çalışılan aracın içinde görünmeli), tam bilgi (sadece "kayıt güncellenecek" demek yetmez, tam değişiklik detayı gösterilmeli) ve iz kaydı (onay kimliği, zaman damgası, yapılan düzenlemeler). Kötü tasarlanmış sistemlerin dört yaygın hatası: bağlam eksikliği (insan ne olacağını bilmeden onaylıyor), aşırı bildirim (düşük riskli kararlar için bile uyarı, gözetimi "tıklama ritüeline" indirgiyor), sonsuz bekleme (zaman aşımı mekanizması olmadan ajan tıkanıyor) ve parçalı görünürlük (onaylayan sadece kendi rolüne ait bilgiyi görüyorsa, örneğin tutarı görmeyen bir hukukçu, her iki taraf da bilgisiz karar veriyor).

Tam otomasyon ne zaman ters gider?

Gerçek, doğrulanmış örnekler var. Klarna, 700 çalışanın yerini alacağı iddia edilen bir AI ajanı kurdu ama müşteri memnuniyeti düştü; insana devretme seçeneği olmadığı için karmaşık durumlar çözülemedi, şirket geri adım atıp insan+AI işbirliğine döndü. Bir Chevrolet bayisinin chatbotu, bir kullanıcının "prompt injection" tekniğiyle aracı 1 dolara satmayı "kabul etmesi" sağlandı; girdi doğrulaması yoktu. Amazon Alexa+'nın ajan özellikleri onay olmadan istenmeyen satın alımlar yaptı, kullanıcılar özelliği kapattı. Bir finansal hizmetler şirketinin RAG ajanı yanlış düzenleyici alıntılar üretti; müşteriye teslim öncesi zorunlu insan incelemesi olmadığı için rapor geri çekilmek zorunda kaldı. Bir kurumsal kod ajanı, üretim ödeme sistemini bozan kodu, merge öncesi zorunlu bir onay kapısı olmadan yürürlüğe koydu. Sistemik bir veri de var: UC Berkeley'nin bir çalışması, 7 üretim çok-ajanlı sistemde yüzde 41-86,7 arasında başarısızlık oranı buldu; kuruluşların yüzde 65'i son bir yılda AI ajanlarının neden olduğu en az bir güvenlik olayı yaşadığını bildirdi.

Bu örneklerin ortak noktasına dikkat edin: hiçbiri "AI yeterince akıllı değildi" diye başarısız olmadı. Hepsinde eksik olan, bir onay noktasıydı; Chevrolet örneğinde girdi doğrulaması, finansal RAG örneğinde teslim öncesi inceleme, kod ajanı örneğinde merge öncesi onay kapısı. Bu aslında iyimser bir sonuç: sorun AI'ın kapasitesinden çok tasarımdaki bir boşluktan kaynaklanıyor, ve boşluklar kapatılabilir.

Bu seride öğrendiklerimiz

Serinin önceki yazılarına dönüp baktığımızda aynı prensip her seferinde farklı bir kılıkta karşımıza çıktı. Belge işleme yazısında çıkarılan veriyi doğrudan ERP'ye yazmadan önce bir onay adımı önermiştik, tam da MindStudio'nun Katman 4'ü. n8n senaryolarında hata yönetimi kurmamayı en büyük hata saymıştık; bu da aslında "sonsuz bekleme" ve "parçalı görünürlük" tuzaklarının bir başka biçimi. Satış teklif otomasyonunda Air Canada örneği, fiyat/şart üreten AI çıktısının insan onayı olmadan müşteriye gitmesinin gerçek hukuki bir riske dönüştüğünü gösterdi. Ortak ders şu: otomasyonun kendisi neredeyse hiçbir zaman sorun değil, sorun her zaman onay katmanının eksik ya da yanlış tasarlanmış olması.

Sık sorulan sorular

Küçük bir işletme için bu çerçeveyi uygulamak karmaşık değil mi?

Uygulamada oldukça basit bir soruya indirgenebilir: bu eylem geri alınabilir mi, dışarıya (müşteriye/kamuya) mı gidiyor, para veya veri silme içeriyor mu? Üçünden herhangi birine "evet" diyorsanız bir insan onayı ekleyin; üçüne de "hayır" diyorsanız otomasyona güvenle devam edebilirsiniz.

Onay katmanı otomasyonun hızını çok mu düşürür?

Doğru tasarlandığında hayır, çünkü onay sadece Katman 3-4 gibi gerçekten riskli işlemlerde devreye giriyor; günlük işlemlerin büyük kısmı (okuma, taslak, düşük riskli kayıt) hâlâ tam otonom çalışıyor. Yanlış tasarlandığında (her şeye onay istemek) hem yavaşlıyor hem de insanı "damga basar" moduna itiyor.

Ekibim AI'a görev devretmeye dirençliyse ne yapmalıyım?

Bu direnç genelde "işimi elimden alacak" korkusundan çok, "bir şey ters giderse kim sorumlu olacak" belirsizliğinden kaynaklanıyor. Onay katmanını net bir şekilde tanımlayıp "şu görevlerde son söz sende, şunlarda AI önerir sen onaylarsın" diye açıkça çizerseniz, direnç genelde yerini rahatlamaya bırakıyor; çünkü ekip artık kontrolü tamamen kaybetmediğini görüyor.

Peki siz ne yapmalısınız?

• Her otomasyon için üç soruyu sorun: geri alınabilir mi, dışarıya mı açık, para/veri silme içeriyor mu?
• Onay isteklerini tam bağlamla sunun; "onayla/reddet" butonu tek başına yeterli değil.
• Düşük riskli her işlemde onay istemeyin, bu insanı "damga basar" moduna itip gerçek gözetimi zayıflatıyor.
• Hataları yapılandırılmış şekilde kaydedin ve sık tekrarlayan hataları kural/prompt güncellemesine dönüştürün.
• Bu seride kurduğunuz her otomasyonu bir kez daha bu üç soruyla gözden geçirin; büyük ihtimalle en az birinde eksik bir onay adımı bulacaksınız.

Otomasyon serimizin başında Excel'den akıllı sistemlere geçişin bir proje değil bir alışkanlık olduğunu söylemiştik. Bu son yazı da aynı alışkanlığın bir parçası: otomasyonu kurmak kolay kısım, neyi insana bırakacağınıza doğru karar vermek asıl beceri. Bu beceriyi geliştirdikçe, hangi otomasyonun güvenle genişletilebileceğini de kendiniz görmeye başlıyorsunuz; zamanla onay katmanını nerede sıkılaştırıp nerede gevşetebileceğinize dair bir sezgi kazanıyorsunuz, bu da her yeni otomasyon projesini bir öncekinden biraz daha hızlı ve güvenli hale getiriyor.