Süreç Otomasyonu: RPA mı, Yapay Zeka Ajanı mı?

RPA ile yapay zeka ajanı arasındaki fark nedir?

RPA (robotik süreç otomasyonu), ekranlar ve dosyalar üzerinde önceden tanımlanmış adımları her seferinde aynı şekilde tekrarlar; yapay zeka ajanı ise bir dil modeliyle, yol boyunca okuduğu bilgiye bakarak bir sonraki adımına kendisi karar verir. RPA'yı çok hızlı ve talimata harfiyen uyan bir memur gibi düşünebilirsiniz: uygulamayı açar, alanı bulur, değeri kopyalar, düğmeye basar. Microsoft, Power Automate masaüstü akışlarını "kurala dayalı görevler" için tasarlanmış bir otomasyon olarak tanımlar; bu akışlar arayüz öğeleri, görüntüler ya da ekran koordinatları üzerinden hem modern hem de terminal emülatörü gibi eski uygulamalarla çalışabilir. RPA'nın asıl gücü budur: API'si olmayan bir sisteme dokunmadan o sistemi otomatikleştirebilir.

Yapay zeka ajanı farklı çalışır. Bir hedef alır; e-posta, taranmış belge ya da serbest metinli bir şikâyet gibi yapılandırılmamış girdiyi okur ve hangi aracı çağıracağını kendisi seçer: siparişe bakmak, sözleşme maddesini okumak, yanıt taslağı hazırlamak. Anthropic'in etkili ajan geliştirme rehberi, model ve araçların önceden yazılmış kod yollarını izlediği iş akışlarını, sürecini kendisi yönlendiren ajanlardan ayırır. Aynı rehber işe yarayan en basit çözümü bulmayı ve karmaşıklığı yalnızca gerektiğinde artırmayı önerir; özerkliğin bedelini de açıkça yazar: daha yüksek maliyet ve birbirine eklenen hatalar.

İkisinin arasında, gerçek projelerin çoğunun sonunda vardığı bir yapı vardır: tek bir yapay zeka adımı içeren sabit iş akışı. Süreç hâlâ kodda ya da RPA aracında tanımlıdır; ancak e-postayı sınıflandırmak veya PDF'ten alan okumak gibi bir adım modele bırakılır. Bu ara seçeneği baştan adıyla anın; çünkü "RPA mı, yapay zeka mı?" sorusu çoğu zaman aslında "Yalnızca RPA mı, yoksa bir yapay zeka adımı eklenmiş RPA mı?" sorusudur.

Hangi süreçler RPA'ya uygundur?

RPA; girdisi yapılandırılmış, adımları her seferinde aynı olan ve ekranları nadiren değişen süreçlere uygundur. Onaylanmış kayıtları bir sistemden diğerine taşımak, her sabah banka ya da tedarikçi portalından ekstre indirmek, entegrasyon arayüzü olmayan eski bir masaüstü uygulamasına veri girmek tipik örneklerdir. Karar bir kural olarak yazılabiliyorsa ("tutar limitin altındaysa ve tedarikçi onaylı listedeyse kaydet"), RPA bu kuralı her seferinde aynı biçimde uygular ve ne yaptığının net bir kaydını bırakır.

Zayıf nokta ekranın kendisidir. Robot bir düğmeyi ya da alanı, kullanıcı arayüzünün saklanan özniteliklerinden bulur. UiPath'in seçiciler (selectors) belgesi bu özniteliklerin sabit değerli olması gerektiğini vurgular: değer uygulama her açıldığında değişiyorsa seçici öğeyi artık bulamaz; yerleşimi değişen uygulamalarda seçicilerin elle hazırlanması gerekir. Robotları gözetimsiz (unattended) çalıştırmanın da kendi koşulları vardır. Microsoft'un gözetimsiz masaüstü akışları belgesine göre makinede oturum açmış kullanıcı bulunmamalıdır, gözetimsiz çalıştırma belirli bir lisans planı gerektirir ve uzak oturumdaki farklı ekran çözünürlüğü robotun bir öğeyi bulamamasına ya da yanlış öğeye tıklamasına yol açabilir.

Bunların hiçbiri RPA'yı kötü bir seçim yapmaz. Yalnızca şunu gösterir: RPA, sabit ekranlar için sağlam, sık değişen ekranlar için pahalı bir tercihtir. En başta sorulması gereken bir soru daha var: Hedef sistemin zaten bir API'si var mı? Varsa doğrudan entegrasyon, kullanıcıyı taklit eden bir robottan genellikle daha dayanıklıdır.

Hangi süreçler yapay zeka ajanı gerektirir?

Girdi yapılandırılmamışsa, bir sonraki adım az önce bulunan bilgiye bağlıysa ve birden fazla sistem işin içindeyse yapay zeka ajanı anlam kazanır. Müşteri şöyle yazıyor: "Teslimat hasarlı geldi, faturada da hâlâ eski adresimiz var." Doğru işlem sipariş kaydına, sevkiyat durumuna ve faturaya bağlıdır; bunlara hangi sırayla bakılacağı da sabit değildir. Her olasılık için kural yazmak pratik değildir; mesajı okuyup hangi kaydı açacağına karar veren bir model ise pratiktir.

Bu esneklik yeni riskler getirir. OWASP, dil modeli uygulamalarının başlıca riskleri arasında aşırı yetkiyi (excessive agency) sayar: işin gerektirdiğinden fazla işlevi olan araçlar, gereğinden geniş izinler ve insan doğrulaması olmadan yapılan yüksek etkili işlemler. Önerdiği önlemler dar kapsamlı araçlar, en az yetki ve yüksek etkili işlemlerden önce insan onayıdır. İkinci risk, ajanın dışarıdan gelen metni okumasıdır. OWASP'ın istem enjeksiyonu (prompt injection) maddesi, bir web sayfasındaki ya da dosyadaki içeriğin modelin davranışını nasıl değiştirebileceğini anlatır ve güvenilmeyen içeriğin ayrılıp açıkça işaretlenmesini önerir. E-postayı okuyan bir RPA robotu içindeki talimata uymaz; tasarım bunu engellemiyorsa bir ajan uyabilir.

Karar matrisi: hangi süreç tipine hangi yaklaşım?

Teknolojiden değil süreçten başlayın. Aşağıdaki matris sık karşılaşılan süreç tiplerini kapsar. Her satırı kesin bir hüküm olarak değil, kendi vakalarınızdan alacağınız bir örneklemle sınayacağınız bir başlangıç noktası olarak okuyun.

Süreç tipi	Girdi	İstisnalar	Önerilen yaklaşım	Dikkat edilecek nokta
Alanları sabit iki sistem arasında kayıt taşıma	Yapılandırılmış	Nadir, çoğu teknik	API varsa entegrasyon; yoksa RPA	Ekran değişikliği robotu durdurur; önce API sorun
Portallardan zamanlanmış indirme ve raporlama	Yapılandırılmış, sabit ekranlar	Giriş değişiklikleri, portal kesintileri	RPA veya zamanlanmış betik	Parola saklama, iki adımlı doğrulama, portal yenilemeleri
API'si olmayan eski bir uygulamaya veri girişi	Yapılandırılmış	Hedef sistemdeki doğrulama hataları	RPA	Eski uygulamanın sürüm güncellemeleri
Farklı düzenlerde PDF olarak gelen fatura ve formlar	Yarı yapılandırılmış	Eksik alanlar, kötü taramalar	Yapay zeka ile alan okuma, kural kontrolü, ardından RPA veya API ile kayıt	Düşük güvenli alanlar mutlaka bir kişiye gitmeli
Gelen e-posta ve talepleri ayırma	Yapılandırılmamış metin	Karışık veya belirsiz talepler	Yapay zeka ile sınıflandırma, sabit yönlendirme kuralları	E-postaya gizlenmiş talimatlar; iç içe geçen kategoriler
Birden fazla sistemde vaka araştırma	Yapılandırılmamış, çok kayıtlı	Sık; her vaka farklı	Salt okuma araçlarıyla sınırlandırılmış ajan; kararı kişi verir	Döngüler, vaka başına maliyet, yanlış kaydı açmak
Para, silme veya müşteriye mesaj içeren işlemler	Her tür	Hata pahalıya patlar	Zorunlu insan onaylı sabit iş akışı; ajan yalnızca öneri yapar	Onay istemde değil, sunucuda uygulanmalı
Hukuki veya mevzuata bağlı etkisi olan değerlendirmeler	Yapılandırılmamış	Yüksek	Yapay zeka kaynaklı taslak hazırlar; kararı uzman verir	Sorumluluk kişide kalır

Satırların çoğunu iki soru belirler. Birincisi: Girdi, dili anlamadan okunabiliyor mu? Okunabiliyorsa RPA ya da entegrasyon genellikle yeterlidir. İkincisi: Adımlar önceden sayılabiliyor mu? Sayılabiliyorsa, bir adım model gerektirse bile süreci sabit iş akışında tutun. Ajan, ancak iki sorunun cevabı da "hayır" olduğunda doğru cevaptır; o durumda bile çoğunlukla işlemi kendisi yapmak yerine önermelidir.

İstisnalar kararı nasıl değiştirir?

Bir otomasyonun kendini amorti edip etmeyeceğini istisnalar belirler; bu yüzden seçim yapmadan önce onları ölçün. UiPath'in orkestrasyon belgesi iki tür istisnayı ayırır. Uygulama istisnası, yanıt vermeyen bir uygulama gibi teknik bir sorundur; iş istisnası ise sürecin dayandığı verinin eksik ya da hatalı olduğu anlamına gelir. Kuyruk, varsayılan olarak iş istisnalarını yeniden denemez; çünkü yeniden denemek hatalı veriyi düzeltmez.

Bu ayrım hangi aracı seçerseniz seçin işe yarar. Uygulama istisnaları bir mühendislik sorunudur: yeniden deneme, izleme, daha kararlı bir arayüz. İş istisnaları bir süreç sorunudur: vakaya birinin bakması gerekir. Bir süreç çok sayıda iş istisnası üretiyorsa, tek başına RPA bunların çoğunu insanlara geri gönderir ve tasarruf küçülür. Yapay zeka burada robotun yerini alarak değil, çeşitliliğin bir kısmını üstlenerek yardımcı olur: tedarikçinin serbest metinli notunu okur, fatura satırını doğru satın alma siparişiyle eşleştirir ve yalnızca emin olamadığı vakaları bir kişiye gönderir.

Karar vermeden önce son haftalardan gerçek vakalardan bir örneklem alın ve üç gruba ayırın: kurala uyan vakalar, teknik nedenle takılan vakalar ve değerlendirme gerektiren vakalar. Üçüncü grubun büyüklüğü, doğru yaklaşım hakkında herhangi bir ürün tanıtımından daha fazlasını söyler.

Bakım yükü ikisinde nasıl farklılaşır?

İki yaklaşım da canlıya geçtikten sonra bir sahip ister; yalnızca farklı yerlerden bozulurlar.

Konu	RPA	Yapay zeka ajanı
Genellikle ne bozulur?	Ekran düzeni, alan adları, giriş akışı, ekran çözünürlüğü	Model sürümü, istemler, yeni girdi türleri, araç arayüzlerindeki değişiklikler
Nasıl fark edilir?	Robot "öğe bulunamadı" hatasıyla durur	Kalite sessizce düşer; yanıtlar makul görünür ama yanlıştır
Ne gerekir?	Seçici bakımı ve hedef sistemin her sürümünden sonra test çalıştırması	Gerçek vakalardan bir değerlendirme kümesi ve her değişiklikten sonra yeniden çalıştırılması
Ne kaydedilmeli?	Her adım, girdi kaydı, sonuç	Girdi ve çıktısıyla her araç çağrısı, model sürümü, onaylayan kişi
Sahibi kim?	Süreç sahibi ve otomasyon ekibi	Süreç sahibi ve yapay zeka mühendisliği ekibi

Bu asimetri önemlidir. RPA bozulduğunda genellikle açıkça hata verir ve durur. Modelin davranışı kaydığında ise süreç daha kötü sonuçlarla çalışmaya devam edebilir. Değerlendirme kümesi ve adım adım kaydı olmayan bir ajan projesi, tanıtım ne kadar ikna edici olursa olsun canlıya hazır değildir.

RPA'nın ve yapay zeka ajanının maliyetini ne belirler?

İki yaklaşımın da tek bir fiyatı yoktur; ikisinin de teklif istemeden önce sıralayabileceğiniz maliyet kalemleri vardır.

• RPA platform lisansları: Çoğu zaman robot, gözetimsiz çalışma ortamı ya da kullanıcı başına fiyatlanır. Microsoft örneğinde olduğu gibi gözetimsiz otomasyon ayrı bir plan gerektirebilir.
• RPA makineleri: Robotların çalıştığı fiziksel veya sanal makineler ve kullanıcı oturumları.
• RPA geliştirme: Süreç başına emek; ekran, sistem ve dal sayısıyla büyür.
• RPA bakımı: Hedef uygulamalardaki her değişiklikten sonra yapılan iş.
• İstisna yönetimi: Her iki yaklaşımda da istisna kuyruğuna bakan çalışanlar.
• Model kullanımı: Barındırılan modelde görev başına token maliyeti; model kendi sunucunuzda çalışıyorsa donanım.
• Araçlar ve entegrasyonlar: Ajanın kullandığı bağlantılar ve bunların yetkileri.
• Değerlendirme: Gerçek vakalardan test kümesi oluşturmak ve güncel tutmak.
• İnsan incelemesi: Önerileri kontrol etmeye ve işlemleri onaylamaya ayrılan zaman.
• Kayıt, izleme ve güvenlik incelemesi: İkisinde de gerekir, ajanda daha ağırdır.

Teklifleri karşılaştırırken her tedarikçiden kaç süreç, sistem ve istisna yolunu fiyatladığını, hangi lisans modelini varsaydığını ve canlıya geçişten sonra otomasyonun bakımını kimin yapacağını yazmasını isteyin. Birbirinden çok farklı görünen iki teklif, yalnızca farklı kapsamları anlatıyor olabilir.

RPA ile yapay zekayı aynı süreçte nasıl birleştirirsiniz?

İkisini birleştirmek çoğu zaman işe yarayan cevaptır: Dilin işin içinde olduğu yerde yapay zeka okusun ve sınıflandırsın, adımların sabit olduğu yerde RPA ya da entegrasyon işlemi yapsın. Platform üreticileri de bu yöne gidiyor; örneğin Microsoft'un AI Builder özelliği, Power Automate akışlarına hazır ve özel yapay zeka modelleri ekler ve örnekleri arasında belge işlemeyi sayar. Tasarımların çoğu dört kalıptan birine oturur:

• Yapay zeka okur, robot yazar: Model belgeden alanları çıkarır, kurallar doğrular, robot ya da API bunları hedef sisteme girer.
• Robot toplar, yapay zeka ayırır: Robot ekleri veya talepleri belirli saatlerde indirir, model sınıflandırır, sabit kurallar her sınıfı yönlendirir.
• Yapay zeka istisna kuyruğuna bakar: Robot standart vakaları işler; işleyemediği vakalar, bir kişi için özet ve çözüm önerisi hazırlayan modele gider.
• Robot, ajanın aracıdır: Ajan belirli ve dar kapsamlı bir robotu ("bu hesabın ekstresini indir") tetikleyebilir; ekranda her şeyi yapabilen genel bir robotu asla.

Hangi kalıbı seçerseniz seçin, yapay zeka çıktısı ile robotun işlemi arasına bir doğrulama adımı koyun. Modelin okuduğu tutar, robot kaydı yapmadan önce satın alma siparişiyle karşılaştırılmalı; mali etkisi olan ya da müşteriye giden işlemler insan onayını beklemelidir.

Varsayımsal örnek: tedarikçi faturaları

Bu varsayımsal bir örnektir; rakamlar ölçüm değil, açıklama amaçlıdır. Bir şirketin ayda 1.000 tedarikçi faturası aldığını düşünelim. Bunların 600'ü yapılandırılmış e-fatura olarak, 300'ü bir düzine farklı düzende PDF olarak geliyor; 100'ünde ise sorun var: satın alma sipariş numarası eksik, fiyat siparişten farklı ya da tedarikçi kayıtlı değil. Bugün muhasebe ekibi hepsini, fatura kaydı için arayüzü olmayan bir ERP'ye elle giriyor.

1. Yapılandırılmış e-faturalar (600): Yapay zeka gerekmez. Yapılandırılmış veriyi okuyun, kurallarla satın alma siparişiyle eşleştirin ve kaydı robota bırakın. Kurala takılan her şey istisna kuyruğuna gider.
2. PDF faturalar (300): Model tedarikçiyi, tarihi, satırları ve toplamları çıkarır; kurallar toplamları kontrol edip siparişle karşılaştırır. 30 faturada düşük güvenli bir alan olduğunu varsayalım. Bunlar, ilgili alan işaretlenmiş olarak bir kişiye gider; kalan 270'i robot kaydeder.
3. Sorunlu faturalar (100): Bunlar değerlendirme ister. Salt okuma yetkisi olan bir ajan siparişi, irsaliyeyi ve tedarikçiyle önceki yazışmaları toplar, önerilen işlemle birlikte bir özet hazırlar. Kararı bir kişi verir ve onaylar.

Bu varsayımlarla çalışanlar 1.000 yerine 130 faturayla ilgilenir; en zor 100 vaka da kanıtları toplanmış olarak önlerine gelir. Örnek, nelerden kaçınılması gerektiğini de gösterir. 1.000 faturanın tamamını ajandan geçirmek, kuralların zaten işleyebildiği 600 faturaya model maliyeti ve yeni hata türleri ekler; yalnızca RPA kullanmak ise 300 PDF'i ve 100 sorunlu vakayı elle işlemeye bırakır. Bu rakamların herhangi bir versiyonuna güvenmeden önce aynı ayrımı kendi örnekleminizde yapın.

Tedarikçi veya araç seçmeden önce sorulacak sorular

1. Hangi adımlar otomatikleşecek, hangileri insanda kalacak?
2. Teklif, örneklemdeki vakaların ne kadarını standart kabul etti ve bu nasıl ölçüldü?
3. Hedef ekran ya da form değiştiğinde ne olur, kim düzeltir?
4. Yapay zeka çıktısı, bir sistemde değişiklik yapılmadan önce nerede doğrulanıyor?
5. Hangi işlemler insan onayı gerektiriyor ve bu onay sunucuda mı uygulanıyor?
6. Her vaka için ne kaydediliyor; tek bir vakayı baştan sona izleyebiliyor muyuz?
7. Teklif hangi lisansları, makineleri ve model kullanımını varsaydı?
8. Canlıya geçtikten sonra başarı neye göre ve hangi başlangıç değerine kıyasla ölçülecek?

Sık yapılan hatalar

• Bozuk bir süreci önce düzeltmek yerine olduğu gibi otomatikleştirmek.
• Birkaç haftada bir değişen ekranlar için RPA seçip sürekli onarıma para ödemek.
• Adımları sabit bir süreç için ajan seçip kimsenin ihtiyaç duymadığı esnekliğe para ödemek.
• Tasarruf hesabında istisna kuyruğunu unutmak.
• Model çıktısının doğrulama ya da onay olmadan bir sistemi değiştirmesine izin vermek.
• Zaten API sunan bir uygulamanın üzerine robot kurmak.

Hatson Tech bu soruya nasıl yaklaşıyor?

Yapay zeka ajanı geliştirme çalışmalarımızda ilk soru, işin gerçekten bir ajan gerektirip gerektirmediğidir. Tek bir yapay zeka adımı olan sabit bir iş akışı yetiyorsa ya da mevcut bir otomasyonun önüne yalnızca bir yapay zeka adımı eklemek yeterliyse, önerdiğimiz budur. Ajan ile iş akışı kararını yapay zeka ajanı mı, sabit iş akışı mı? yazımızda, onay tasarımını ise ajan eylemlerinden önce insan onayı yazımızda ayrıntılı anlattık. Aklınızda bir süreç varsa, gerçek vakalardan küçük bir örneklemle ilk görüşmeye gelin. İlk görüşme ücretsizdir ve bu vakaları birlikte ayırmak, hangi yaklaşımın uyduğunu görmenin genellikle hızlı bir yoludur.