İçeriğe geç

AI otomasyonu dönüşüm değildir: Süreci gerçekten yeniden tasarlamak

Bir görevi hızlandırmak başka, işin nasıl sonuç ürettiğini değiştirmek başka. Süreç tasarımı, ölçüm, insan onayı ve hata toparlama üzerinden gerçek AI dönüşümü için pratik bir çerçeve.

Kaynakdoğrulandı
  1. [01]Anthropic — Building effective agents2026-09-18
  2. [02]OpenAI — A practical guide to building agents (PDF)2026-09-18
  3. [03]NIST — AI RMF Core2026-09-18

Bir e-postayı özetletmek, bir formu sınıflandırmak veya bir rapor taslağı üretmek otomasyondur. Bunlar değerli olabilir; fakat şirketin karar verme biçimi, sorumlulukları ve hata anındaki davranışı değişmiyorsa dönüşüm değildir. AI dönüşümü, mevcut sürecin üzerine bir model eklemekten çok sürecin kendisini yeniden tasarlama işidir.

Bu ayrım önemli çünkü başarılı bir demo ile güvenilir bir operasyon arasında büyük mesafe var. Demo, modelin mutlu yolda ne yapabildiğini gösterir. Operasyon ise istisnaları kimin yöneteceğini, hangi noktada insan onayı gerektiğini, hatanın nasıl fark edileceğini ve işin nasıl geri alınacağını tanımlar.

Önce işi değil, sonucu tanımla

Dönüşüm projesine “hangi modeli kullanalım?” sorusuyla başlamak ters yönden ilerlemektir. Önce müşteriye veya ekibe teslim edilen sonucu tanımlamak gerekir. Sonra o sonucun bugün hangi adımlarla üretildiği, nerede beklediği, hangi istisnalarda bozulduğu ve yeniden işleme maliyetinin nerede oluştuğu çıkarılır.

Örneğin “destek yanıtını otomatik yazmak” bir görev tanımıdır. “Doğru politikaya dayanan, gerekli bilgiyi toplayan, riskli işlemleri onaya gönderen ve müşteriye söz verilen sürede çözüm üreten destek akışı” ise sonuç tanımıdır. İkinci tanım, model çıktısını değil bütün sistemi ölçmeye zorlar.

Başlamadan önce şu dört ölçüyü mevcut süreç için kaydet:

  • Başarı ölçütünü geçen tamamlanmış işlem oranı.
  • İşlem başına toplam çevrim süresi ve insan bekleme süresi.
  • Yeniden işleme, düzeltme veya geri alma oranı.
  • Tamamlanmış başarılı işlem başına toplam maliyet.

Bu yaklaşım, daha önce yazdığım AI yatırımını başarılı işle ölçme fikrini süreç seviyesine taşır: token, çağrı sayısı veya üretilen metin miktarı tek başına iş sonucu değildir.

Her adımı ajana vermek zorunda değilsin

Anthropic, iyi tanımlanmış işler için öngörülebilir iş akışlarını; adım sayısının önceden kestirilemediği ve modelin karar vermesi gereken işler için ajanları ayırıyor. Ayrıca mümkün olan en basit çözümle başlamayı ve karmaşıklığı ancak sonuç belirgin biçimde iyileşiyorsa artırmayı öneriyor. OpenAI’ın pratik rehberi de benzer biçimde kademeli ilerlemeyi, çok ajanlı mimariye geçmeden önce tek ajanın kapasitesini tüketmeyi savunuyor.

Bu yüzden süreçte üç farklı motoru bilinçli biçimde ayırmak daha sağlıklı:

  • Deterministik yazılım: kurallar nettir, aynı girdinin aynı çıktıyı vermesi gerekir.
  • AI destekli iş akışı: adımlar bellidir, model sınıflandırma, çıkarım veya taslak üretme gibi sınırlı bir rol üstlenir.
  • Ajan: yol baştan tam belirlenemez; sistem araç kullanır, çevreden geri bildirim alır ve bir sonraki adımı seçer.

Gerçek dönüşüm çoğu zaman bu üçünü birlikte kullanır. Fatura toplamını hesaplamak için ajan gerekmez. Belirsiz bir müşteri talebini doğru uzmanlığa yönlendirmek için model yararlı olabilir. Para iadesini yürürlüğe koymak ise açık bir politika ve insan onayı isteyebilir.

İnsan onayını sona değil, kararın önüne koy

“İnsan döngüde” ifadesi tek başına güvenlik tasarımı değildir. Bir çalışanın tüm AI çıktısını sonradan gözden geçirmesi, otomasyonu yavaşlatır ama riski doğru yerde kesmeyebilir. Onay kapısı, etkisi yüksek veya geri döndürülmesi zor eylemin hemen önünde olmalıdır.

Onay gerektiren eşikleri baştan yaz:

  • Ödeme, iade, sözleşme, erişim yetkisi veya kalıcı veri değişikliği.
  • Model güveninin düşük olduğu ya da kaynakların çeliştiği kararlar.
  • Politika dışı istisnalar ve müşteri üzerinde yüksek etkili sonuçlar.
  • Belirlenen deneme, araç çağrısı, süre veya maliyet sınırının aşılması.

OpenAI rehberi, hata eşiği aşıldığında ve yüksek riskli eylemler söz konusu olduğunda insan müdahalesini iki temel tetikleyici olarak tanımlıyor. Anthropic de ajanların kontrol noktalarında veya engellerle karşılaştığında insan geri bildirimi için durabilmesini öneriyor. Bu, onayı genel bir bürokrasi olmaktan çıkarıp belirli bir risk kontrolüne dönüştürür.

Hata toparlama akışın bir parçası olmalı

Bir otomasyonun olgunluğu, yalnızca doğru çalıştığında ne yaptığıyla ölçülmez. Yanlış araç çağrısında, eksik veride, zaman aşımında veya politika çelişkisinde nasıl durduğu daha belirleyicidir. “Tekrar dene” tek başına hata stratejisi değildir; aynı belirsizliği daha hızlı çoğaltabilir.

Her otomasyon için en az şu toparlama sözleşmesini yaz:

  • Durdurma koşulu: kaç deneme, ne kadar süre ve ne kadar maliyet?
  • Güvenli durum: işlem yarıda kalırsa hangi veri veya eylem geri alınır?
  • Devir paketi: insana hangi bağlam, kanıt, araç sonucu ve hata geçmişi gönderilir?
  • Tekrar başlatma noktası: süreç baştan mı, son doğrulanmış adımdan mı devam eder?

Kod tarafında benzer mantığı kodlama ajanı çıktısını doğrulama kontrol listesinde ele almıştım. İş sürecinde de aynı ilke geçerli: ajanın kendi özetini doğrulama kanıtı sayma; sistem durumunu bağımsız olarak oku.

Dönüşümü bir gösterge tablosuyla değil, bir karşılaştırmayla kanıtla

Yeni akışı doğrudan tüm organizasyona açmak yerine dar bir işlem türünde, mevcut yöntemle karşılaştırmalı çalıştır. Aynı kalite eşiğini kullan; yalnızca hız veya model maliyetine bakma. İnsan inceleme süresi, istisna oranı, yeniden işleme, müşteri etkisi ve toplam maliyet aynı tabloda görünmeli.

NIST AI Risk Management Framework; yönetişim, bağlamı haritalama, ölçme ve yönetme işlevlerini yaşam döngüsü boyunca sürekli ve yinelemeli bir yapı olarak ele alıyor. Bu bakış, “pilot bitti, risk işi tamamlandı” yanılgısını engeller. Süreç değiştikçe veri, roller, eşikler ve kontroller de yeniden değerlendirilir.

Pratik karar kuralım şu: otomasyon aynı kaliteyi daha az toplam emekle üretiyorsa ölçeklenebilir. Kalite artıyor fakat maliyet de artıyorsa yalnızca yüksek değerli işlemlerde anlamlı olabilir. Hız artarken hata maliyeti veya insan düzeltmesi yükseliyorsa süreç henüz dönüşmemiş, sadece darboğaz başka yere taşınmıştır.

90 günlük sade dönüşüm planı

  • İlk 30 gün: tek bir sonuç seç, mevcut akışı ve istisnaları haritala, temel ölçümleri çıkar.
  • 31–60 gün: en basit yeterli mimariyle dar pilot kur; onay, durdurma ve geri alma kapılarını ekle.
  • 61–90 gün: mevcut yöntemle karşılaştır, başarısız örnekleri sınıflandır, yalnızca kanıtlanan parçaları ölçekle.

Bu planın sonunda elinde yalnızca çalışan bir AI özelliği değil; sahipliği, ölçüsü, risk sınırı ve toparlama yolu tanımlı yeni bir çalışma biçimi olmalı. Otomasyon bir adımı kısaltır. Dönüşüm ise işin doğru sonuca nasıl ulaştığını yeniden kurar.