Copilot Studio: ajanlara kendi hesabı, süreç hafızası ve tetikleyiciler

Microsoft Copilot Blog · 15 Ekim 2026

Microsoft, Copilot Studio’da üç özelliği Frontier programı üzerinden kullanıma açmaya başladı. Ajan hesaplarıyla ajan, bir kullanıcının ya da onu yapanın kimliğini ödünç almak yerine kendi kimlik bilgileri ve kapsamı belirlenmiş izinlerle çalışıyor; Teams ve Outlook’ta çağrılabiliyor, Word, Excel ve PowerPoint yorumlarında etiketlenebiliyor. İş süreci hafızası, kullanıcı tercihlerini ve süreç bağlamını bir sonraki döngüye taşıyor; hafızayı yapımcı açıyor, kullanıcı kaydedilenleri görüp silebiliyor. Tetikleyiciler ise ajanın döngüsünü bir e-posta gibi dış bir sinyalle ya da belirli bir takvimle, ayrıca istem beklemeden başlatıyor. Yöneticiler erişimi Power Platform yönetim merkezinden sınırlayıp ajanın yaşam döngüsünü yönetebiliyor. Ek erişim politikaları, maliyet yönetimi ve yaşam döngüsü kontrolleri “önümüzdeki aylarda” planlanıyor. Yazıda genel kullanılabilirlik tarihi, lisans ya da fiyat bilgisi yok.

Neden önemli. RPA’da yıllardır tartıştığımız robot hesabı sorusu artık ofis uygulamalarının içine girdi. Ajanın kendi kimliğiyle çalışması denetim izi için doğru yön; işi kimin yaptığı ayrışıyor. Benim okumam şu: posta kutusu ve Teams varlığı olan bir ajan, geçen sayıdaki KVKK ilke kararının tam kapsamında. Hafıza özelliği de saklama süresi ve aydınlatma sorusunu beraberinde getiriyor. Maliyet ve yaşam döngüsü kontrolleri gelmeden bu hesapları üretimde çoğaltmazdım. Pilot için ilk adım basit: hesap başına bir sahip, bir amaç ve okuyabileceği kanalların listesi.

AB Yapay Zekâ Yasası için ilk uyumlaştırılmış standart: EN 18286

Avrupa Komisyonu · Karar 12 Ekim, AB Resmî Gazetesi 14 Ekim 2026

Komisyon’un 2026/2274 sayılı Uygulama Kararı, CEN ve CENELEC’in hazırladığı EN 18286:2026 “yapay zekâ kalite yönetim sistemi” standardının referansını AB Resmî Gazetesi’nde yayımladı. Komisyon’a göre bu standardı uygulayan yüksek riskli yapay zekâ sağlayıcıları, standardın karşıladığı ölçüde Yasanın 17. maddesindeki kalite yönetim sistemi şartlarına uygun sayılıyor (uygunluk karinesi). Standart kuruma değil yapay zekâ sisteminin yaşam döngüsüne göre kurgulanmış ve ISO/IEC 42001, ISO 9001 ya da sektörel sistemlerin üzerine oturacak şekilde tasarlanmış. 42001’i olmayan kurumlar mevcut kalite sistemini genişletmek ya da yenisini kurmak için kullanabiliyor. Komisyon başka uyumlaştırılmış standartların da geleceğini söylüyor.

Neden önemli. Yüksek riskli yükümlülükler için şimdiye kadar elimizde metin ve taslak kılavuz vardı; denetçinin “neye göre?” sorusuna verilecek somut bir cevap yoktu. EN 18286 ilk cevap. Avrupa’ya yapay zekâ içeren ürün ya da hizmet satan Türk şirketleri için ISO 9001 ya da 27001 altyapısı olan kalite ekiplerini bu konuşmaya şimdiden katmak mantıklı. Bir uyarı: bu madde yalnızca 17. maddeyi kapsıyor. Kendi sisteminizin yüksek riskli sayılıp sayılmadığı sorusu ayrı ve önce o cevaplanmalı.

VUK 596: e-Tebligat’ta 30 Kasım ve şifreyi kimse ile paylaşmama yükümlülüğü

Resmî Gazete · 11 Ekim 2026 (Sayı 33397)

596 Sıra No.lu VUK Genel Tebliği, 7587 sayılı Kanunla değişen VUK 107/A’ya göre elektronik tebligatın usulünü yeniden düzenledi ve 456 Sıra No.lu tebliği yürürlükten kaldırdı. Kurumlar vergisi mükellefleri, gerçek usulde vergilendirilen ticari, zirai ve mesleki kazanç sahipleri ile kollektif ve adi komandit şirketler sisteme dahil olmak zorunda. Henüz dahil olmayanlar için süre, tebliğin yayımını izleyen ayın sonu, yani 30 Kasım 2026. Yeni mükellefler işe başlamayı izleyen 15 gün içinde katılmalı. Tebliğ, sisteme ulaştığı tarihi izleyen beşinci günün sonunda tebliğ edilmiş sayılıyor; olay kayıtları zaman damgasıyla otuz yıl saklanıyor. Muhatap, kullanıcı kodu ve şifresini korumak, üçüncü kişilerle paylaşmamak ve başkasının kullanımına bırakmamakla yükümlü. 1 Temmuz 2026’dan önce dahil olanlar mevcut bilgileriyle devam ediyor.

Neden önemli. e-Tebligat kutusunu her sabah tarayıp tebliğleri ilgili ekibe dağıtan robotlar, finans otomasyonunda en sık kurulan işlerden. Beş günlük tebliğ kuralı, robotun bir gün çalışmamasının süre kaybı demek olduğunu hatırlatıyor; izleme ve alarm bu süreçte lüks değil. Daha hassas nokta şifre: robotun Dijital Vergi Dairesi’ne hangi kimlikle, kimin yetkisiyle girdiğini yazılı hale getirin. Tebliğin şifre paylaşımına dair hükmünün robot hesaplarına nasıl uygulanacağını mali müşavir ve hukuk ekibinizle konuşun; bu bir hukuki görüş değil. Grubunuzda henüz dahil olmayan bir şirket varsa, son gün 30 Kasım.

UiPath: yapay zekâ denetim kaydı varsayılanı değişti, Claude Sonnet 4 kalktı

UiPath Documentation · 13, 14 ve 16 Ekim 2026

16 Ekim’den itibaren yeni oluşturulan AI Trust Layer politikalarında istem girdileri ve modelin ürettiği yanıtlar denetim kayıtlarına varsayılan olarak yazılmıyor; kaydetme açılana kadar bu alanlar “Blocked by Policy” olarak görünüyor. Mevcut politikalar kendi ayarını koruyor. 13 Ekim’de Amazon Bedrock’un kaldırmasıyla Claude Sonnet 4 UiPath platformundan çıktı; UiPath’in yönettiği modeller Claude Sonnet 4.6’ya kendiliğinden taşındı. Sonnet 4’e işaret eden kendi model (BYO) yapılandırmaları ise geçersiz oluyor ve güncellenmezse UiPath’in yönettiği modellere düşüyor. Model Hub artık BYO yapılandırmalarının durumunu gösteriyor. Ayrıca Relay, 26.4.4 ve üzeri istemciyle Snowflake ve SQL Server bağlantılarını kurum içinden taşıyabiliyor.

Neden önemli. Denetim kaydının varsayılan olarak kapalı olması veri koruma açısından makul, ama bir ajanın yanlış kararını sonradan incelemeniz gerekirse elinizde istem ve yanıt olmayabilir. Bence bu bir varsayılan değil, politika kararı olmalı: hangi süreçte içerik kaydı tutulacak, ne kadar süre ve kim görecek. Sonnet 4 notu daha sinsi. Kendi modelini getiren kurumlarda ajan, siz fark etmeden başka bir modele düşmüş olabilir; bu hem kalite hem veri yerleşimi sorusu. Bu hafta Model Hub’daki BYO durumlarına bir bakın.

Maestro: Flow artık önizleme değil, BPMN süreci kodlama ajanıyla kurulabiliyor

UiPath Documentation · 7 ve 13 Ekim 2026

13 Ekim notlarında tuvallerin adları Maestro BPMN, Maestro Case ve Maestro Flow olarak birleştirildi ve Maestro Flow’dan önizleme etiketi kaldırıldı. Maestro Case’te vakayı bitirebilecek aşamalar rozetle gösteriliyor, başarısız ya da sonlandırılmış aşamalar artık “devam ediyor” görünmüyor; bir vaka üzerinde tetiklenebilecek ad-hoc görevleri listeleyen yeni bir API ucu ve rol tanımlarında doğrulama geldi. Flow’da kurumun kendi guardrail yapılandırması adıyla ve sağlayıcısıyla görünüyor. 7 Ekim’de önizlemeye giren özellikle ise bir Maestro BPMN süreci, süreç tanımından, süreç haritasından, PDD’den ya da BPMN modelinden yola çıkarak Claude Code, Codex, GitHub Copilot, Cursor veya Jules gibi bir kodlama ajanıyla kurulabiliyor. Ajan önce plan öneriyor, onaydan sonra kurup hata ayıklıyor ve yayımlıyor.

Neden önemli. PDD’den çalışan sürece giden yolun bir kısmını kodlama ajanına bırakmak cazip; ama çıktının kalitesi PDD’nin kalitesini geçemez. Eksik bir PDD artık daha hızlı yanlış bir sürece dönüşür. Benim önerim, ajanın önerdiği planı bir tasarım incelemesi gibi ele almak ve onayı kayıt altına almak. Flow’un önizlemeden çıkması ise üretim kararını kolaylaştırıyor, yine de destek ve sürüm koşullarını kendi sözleşmenizde kontrol edin.

Gartner: 3,5 trilyon doları aşan yapay zekâ altyapı harcaması değer düşüklüğü riskiyle karşı karşıya kalabilir

Gartner · 14 Ekim 2026

Gartner’ın 14 Ekim tarihli duyurusunun başlığına göre 3,5 trilyon doları aşan yapay zekâ altyapı harcaması 2030 sonuna kadar değer düşüklüğüne maruz kalabilir. Gartner’ın sayfası otomatik erişime kapalı olduğu için bu madde yalnızca başlığa dayanıyor; arama özetlerinde görünen diğer oranları birincil kaynakta okuyamadığım için almadım.

Neden önemli. Analist tahmini bir altyapı yatırımcısı uyarısı gibi duruyor, ama kurumsal alıcıya da dokunuyor. Model ve GPU sağlayıcıları arasında konsolidasyon olursa, çok yıllık bir yapay zekâ sözleşmesinin karşısındaki şirket ya da fiyat değişebilir. Benim kuralım: modeli değiştirilebilir tutan bir mimari (soyutlama katmanı, kendi değerlendirme setiniz) ve çıkış maddesi olan sözleşme. Bu haftaki Sonnet 4 notu, model değişikliğinin ne kadar sessiz olabileceğinin küçük bir örneği.

Önümüzdeki hafta iki şeye bakacağım: Microsoft’un ajan hesapları için lisans ve maliyet kontrollerini açıklayıp açıklamadığı ve EN 18286’nın ardından hangi uyumlaştırılmış standartların sıraya girdiği.

KVKK: kurumsal e-posta ve iletişim kanallarının denetimine ilke kararı

Resmî Gazete · 8 Ekim 2026 (Kurul kararı 16 Eylül 2026, No. 2026/2035)

Kişisel Verileri Koruma Kurulu, işverenin çalışana tahsis ettiği kurumsal e-posta başta olmak üzere iş için kullanılan iletişim kanallarının denetimine 16 maddelik bir ilke kararı yayımladı. Kapsam yalnızca e-posta değil; kurum içi mesajlaşma, müşteri ilişkileri ve talep yönetim sistemleri, toplantı platformlarındaki sohbet ve kayıt alanları da sayılıyor. İçeriğe dokunmadan yalnızca trafik ve log kaydı işlemek de kişisel veri işleme sayılıyor. Genel bir “e-postanız denetlenebilir” bildirimi aydınlatma yükümlülüğünü karşılamıyor; aydınlatmanın amacı, log mu içerik mi inceleneceğini, içeriğe hangi hallerde erişileceğini ve saklama süresini somut olarak anlatması gerekiyor. Çalışanın tüm işlemlerini ayrım gözetmeden kaydeden araçlarla yapılan denetim ise hukuka aykırı sayılıyor. Verilere erişim yetkili ve sınırlı personelle kısıtlanmalı, erişimler kayıt altına alınmalı.

Neden önemli. Karar bir denetim politikası metni gibi okunuyor, ama otomasyon ekiplerini de doğrudan ilgilendiriyor. Paylaşılan posta kutusunu okuyan bir robot, Teams kanallarını izleyen bir ajan ya da masaüstünde her tıklamayı kaydeden bir görev madenciliği (task mining) aracı tam bu kanallarda çalışıyor. Benim okumam: “her şeyi kaydet, sonra filtreleriz” yaklaşımı artık savunulamaz. Bu hafta iki şeyi kontrol ederdim. Robotların ve ajanların okuduğu posta kutularının ve kanalların listesi, bir de bu araçların ürettiği log ve kayıtları kimin gördüğü. Liste yoksa, aydınlatma metni de büyük ihtimalle eksiktir. Bu bir hukuki görüş değil; metni hukuk ekibinizle birlikte okuyun.

UiPath Agents: Autopilot ile ajan incelemesi ve kendi guardrail aboneliğiniz

UiPath Documentation · 1 ve 8 Ekim 2026

8 Ekim’de önizlemeye giren ajan incelemesi, eski Agent score’un yerini alıyor. Autopilot ajanı inceleyip kritik sorunları, uyarıları ve iyileştirme önerilerini listeliyor, sorunların sayısına ve ağırlığına göre A’dan F’ye bir not veriyor ve aynı konuşmada düzeltmeleri uygulayabiliyor. 1 Ekim’de ise yine önizlemede, kurumun kendi güvenlik sağlayıcısı aboneliğini AI Trust Layer’a ekleyip ajan guardrail’i olarak kullanması mümkün oldu. Önizlemede desteklenen sağlayıcılar Azure AI Language, Azure Content Safety ve Noma. Her tespit, onu üreten sağlayıcıyla birlikte ajan izinde (trace) görünüyor; sağlayıcıya ulaşılamazsa guardrail UiPath’in yönettiği karşılığına düşebiliyor.

Neden önemli. Kendi guardrail aboneliğinizi kullanabilmek, güvenlik ekibinin zaten onayladığı içerik filtrelerini ajanlara taşımak demek. Bu, onay sürecini kısaltabilir. Yalnız düşüş (fallback) davranışına dikkat: sağlayıcı erişilemezken hangi kuralın devrede olduğu, denetimde sorulacak ilk sorulardan biri olur ve bunu politika olarak yazılı kararlaştırmak gerekir. A–F notunu ise bence bir kalite kapısı değil, kod incelemesine hazırlık listesi olarak kullanmak doğru. Not iyiyse inceleme kısalır, ama yerine geçmez.

Orchestrator: kiracı düzeyinde zorunlu şifreleme ve Maestro Flow kimliği

UiPath Documentation · 7 ve 12 Ekim 2026

7 Ekim’den itibaren Orchestrator kiracılarında zorunlu şifreleme açılabiliyor: iş, iş olayı, robot logu, kuyruk öğesi ve depolama kovası verileri bir KMS anahtarıyla şifreleniyor. Etkinleştirmek için teknik hesap yöneticisine ya da destek ekibine başvurmak gerekiyor ve şifreli alanlarda arama yapılamıyor. 12 Ekim notlarında ise robot kimlik bilgisini alamadığında iz kimliğinin (trace ID) iş hata ayrıntılarına yazılması ve robot belirtilmemiş Maestro Flow düğüm işlerinin çağıranın kimliğiyle çalışması var. Ayrıca Automation Cloud notlarına göre 6 Ekim itibarıyla Cloudflare’in 104.16.0.0/13 aralığının allowlist’e alınması yalnızca Document Understanding için değil, herhangi bir UiPath servisi için gerekebilir; UiPath mümkünse DNS tabanlı izin listesini öneriyor.

Neden önemli. Şifreleme bankacılık ve sigorta tarafında bulut Orchestrator’a itirazların en sık dile getirilenlerinden birine somut bir cevap. Bedeli de net: şifreli alanlarda arama gidiyor. Kuyruk öğesi referansıyla arama yapan operasyon ekipleriniz varsa açmadan önce o alışkanlığı konuşun. Maestro Flow’daki kimlik değişikliği ise küçük görünse de yetki modelini değiştiriyor; işi kimin kimliğiyle yaptığı denetim izinde artık farklı görünecek. Giden trafiği kısıtlı bir ağdaysanız, Cloudflare notu bu haftanın en pratik maddesi olabilir.

Google Cloud: Gemini agent, “iş için tek ajan”

Google Cloud Blog · 8 Ekim 2026

Google Cloud, Gemini at Work 2026’da soru yanıtlayan, bilgi işi yapan, görsel üreten ve kod yazıp çalıştıran tek bir ajan tanıttı. Ajan bulutta kalıcı çalışıyor, uzun işleri kullanıcı bilgisayarını kapattıktan sonra da sürdürüyor ve Gemini ile Anthropic’in Claude modellerini yönetebiliyor. Her ajana kriptografik olarak doğrulanan bir kimlik ve en az yetki ilkesine göre izinler veriliyor; eylemler kişiye değil ajana yazılan bir denetim izine düşüyor, trafik Agent Gateway üzerinden geçiyor ve proje bazında harcama tavanı konulabiliyor. Kurum içindeki ya da dışındaki MCP sunucularına bağlanabiliyor. Finans ve hukuk sektör sürümleri önizlemede; ajanın genelinin kullanılabilirlik tarihi, sürümü ve fiyatı yazıda yer almıyor.

Neden önemli. Kendi kimliği, e-postası ve harcama tavanı olan bir “ajan çalışan” fikri, RPA’daki robot hesabı tartışmasının yeni hali. Kimlik ve denetim izi tarafı doğru yönde. Benim sorum başka: aynı süreçte bir UiPath robotu, bir Copilot akışı ve bir Gemini ajanı çalışıyorsa uçtan uca izi kim tutacak? Kullanılabilirlik tarihi ve veri yerleşimi bilgisi gelmeden bütçe kalemi açmazdım. MCP desteğini ise iyi haber sayarım; araçlarınızı bir kez MCP sunucusu olarak yayımlamak, platform değiştirme maliyetini düşürür.

Automation Anywhere, Boost.ai’yi satın alıyor

Automation Anywhere · 7 Ekim 2026

Automation Anywhere, Norveçli sohbet ve sesli yapay zekâ şirketi Boost.ai’yi Nordic Capital’den almak için kesin anlaşma imzaladığını duyurdu. Satın almanın, olağan düzenleyici onaylara bağlı olarak 2026’nın son çeyreğinde tamamlanması bekleniyor; bedel açıklanmadı. Duyuruya göre Boost.ai platformu 36’dan fazla dili destekliyor ve en güçlü olduğu alanlar finansal hizmetler, telekom ve sigorta gibi düzenlemeye tabi sektörler. Şirket bunu, müşteriyle yapılan konuşmayı arka ofisteki işe bağlama hamlesi olarak anlatıyor.

Neden önemli. Platform satıcıları ön yüzü (sohbet, ses) ve arka ofisi (robot, ajan) tek pakette satmaya yöneliyor. Automation Anywhere kullanan ve ayrı bir sohbet botu sözleşmesi olan kurumlar için yenileme konuşması değişecek. Duyuru desteklenen dilleri tek tek saymıyor; Türkçenin üretimde ne kadar iyi çalıştığını ve verinin nerede işlendiğini sormadan bir konsolidasyon planı yapmazdım. Tek satıcı entegrasyonu kolaylaştırır, ama çıkış maliyetini de yükseltir.

Gartner: satın alma liderleri yapay zekâ için rolleri yeniden tasarlamakta geç kalıyor

Gartner · 8 Ekim 2026

Gartner’ın 8 Ekim tarihli anket duyurusunun başlığına göre satın alma liderleri (CPO), yapay zekânın gerektirdiği rol ve iş tanımı yeniden tasarımında duraksıyor. Gartner’ın sayfası otomatik erişime kapalı olduğu için bu madde yalnızca duyurunun başlığına dayanıyor; anketteki oranları birincil kaynakta doğrulayamadığım için buraya almadım.

Neden önemli. Satın almadan ödemeye (procure-to-pay) süreci, otomasyonun en olgun olduğu alanlardan biri. Robot ve ajan işi aldıkça geriye kalan insan rolünün tanımı genellikle güncellenmiyor ve istisna kuyrukları sahipsiz kalıyor. İş vakasına kapasite kazanımı yazıyorsanız, aynı sayfaya o kapasitenin hangi yeni role ya da işe gideceğini de yazın. Yazamıyorsanız kazanım kâğıtta kalır.

Önümüzdeki hafta iki şeye bakacağım: KVKK kararından sonra hukuk bürolarının ve kurumların aydınlatma metinlerini nasıl güncellediği ve UiPath’in önizlemedeki guardrail ile ajan inceleme özellikleri için bir genel kullanım tarihi verip vermediği.

Neden şimdi

31 Aralık 2025 tarihli Resmî Gazete’de yayımlanan 589 Sıra No.lu VUK Genel Tebliği, e-Fatura ve e-Arşiv uygulamasına dahil olmayan mükelleflerden basit usulde ve işletme hesabı esasında olanlara bir yıl ek süre verdi. TÜRMOB’un sirkülerine göre bu gruptakiler 31 Aralık 2026’ya kadar vergiler dahil 3 bin TL’yi aşmayan faturaları kâğıtta düzenleyebiliyor. 1 Ocak 2027’den itibaren ise tutarına bakılmaksızın bütün faturalarını GİB’in e-Belge portalından düzenlemek zorundalar. Diğer mükellefler için aynı kural 1 Ocak 2026’dan beri geçerli.

Alıcı tarafından bakınca anlamı şu: esnaftan ve küçük tedarikçiden alım yapan bir şirketin borç hesaplarına giren kâğıt fatura kanalı 2027’de büyük ölçüde kapanıyor. Gelen faturaların neredeyse tamamı ya e-Fatura ya e-Arşiv olacak. Bunu ilk radarda kısaca not etmiştim. Buradaki soru daha pratik: elinizdeki robot bu değişikliğe hazır mı?

Teslim ettiğimiz şey

Kurduğumuz e-Fatura robotu, bir ERP platformunu ulusal e-fatura altyapısıyla uçtan uca bağlıyor ve mutabakat raporu üretiyor. Bu tür entegrasyonları Logo Tiger 3 ve başka ERP sistemleriyle kurduk. Müşteri adını, hacimleri ve iç detayları paylaşmıyorum. Aşağıdaki tasarım notlarının bir kısmı bu teslimatın omurgasından, bir kısmı bugün benzerini kursam ekleyeceğim şeylerden geliyor. Akıştaki etiket ikisini ayırıyor.

GİB’in açıklaması temel kuralı net koyuyor: e-Fatura uygulamasına kayıtlı iki mükellef birbirine düzenlediği faturaları e-Fatura olarak göndermek ve almak zorunda. Kayıtlı olmayan alıcıya giden fatura ise kâğıt ya da e-Arşiv oluyor. Yani bir şirketin gelen fatura akışı en az iki ayrı biçimden besleniyor. Robotun ilk işi de bu ayrımı kaynağında etiketlemek.

Mutabakat neden ayrı bir iş

Entegrasyon “gelen belgeyi kaydet” der. Mutabakat ise “kaydettiğinin eksiksiz ve tek olduğunu göster” der. İkisi aynı kod içinde yaşayabilir ama farklı soruları cevaplar ve farklı kişiler okur.

Mutabakat raporunda benim görmek istediğim üç liste var:

• e-Belge tarafında görünen ama ERP’de karşılığı olmayan faturalar. Bunlar genellikle bekleyen, reddedilmiş ya da robotun bir hata yüzünden atladığı belgelerdir.
• ERP’de kaydı olan ama bir elektronik belgeye bağlanamayan faturalar. Elle girilmiş kayıtlar ve kâğıt kanalın kalıntıları burada çıkar.
• İki tarafta da olan ama tutarı ya da vergisi uyuşmayan faturalar.

İlk iki liste boşsa robot işini yapıyor demektir. Doluysa bunu ay sonu kapanışında değil, ertesi sabah görmek istersiniz. Bence mutabakat raporunun asıl değeri de bu: hatayı kapanış haftasından günlük işe taşıması.

Kural, model ve insan nerede

Bu akışta kuralın payı yüksek ve öyle kalmalı. Elektronik faturanın yapısal verisi zaten var. Tutarı, vergiyi ve tedarikçiyi bir dil modeline okutmak için bir neden göremiyorum. Mükerrer kontrolü, sipariş ile mal kabul eşleştirmesi ve tolerans kuralları belirlenimci olmalı; denetçi sorduğunda tek cümleyle açıklanabilmeli.

Model, yapısal verisi olmayan belgede devreye girer. 2027’ye kadar bu, küçük tedarikçiden gelen kâğıt fatura demek. Sonrasında da tamamen kaybolacağını sanmıyorum. Elektronik belgenin size hangi biçimde ulaştığı tedarikçinin seçimine bağlı olabiliyor ve bazı faturalar yine yalnızca PDF olarak gelecektir. Bu yüzden okuma yolunu kaldırmazdım; onu istisna yolunun parçası olarak kurardım.

İnsan ise farkın gerekçesini bilen tek taraf. Fiyat farkı anlaşmadan mı geliyor, kısmi teslimattan mı, yanlış siparişten mi? Robottan beklediğim, soruyu doğru kişiye doğru bilgiyle götürmesi. Cevap uydurması değil.

2027 için ayarlanacak dört şey

1. Hacim tahminini yeniden yapın. Kâğıt fatura okuyan bir OCR akışınız varsa 2027 hacmi büyük olasılıkla düşecek. Lisans ve kapasite planını bu yılın rakamıyla yenilemeyin; tedarikçi listenizi basit usul ve işletme hesabındakiler açısından ayırıp tahmini oradan yapın.
2. Kanal etiketini zorunlu tutun. Her faturanın hangi kanaldan geldiği kayıtta dursun. Yoksa kâğıt kanalın gerçekten kapanıp kapanmadığını ölçemezsiniz.
3. e-Arşiv için ayrı bir alım yolu düşünün. e-Arşiv faturanın size hangi biçimde ulaştığı tedarikçiye göre değişebilir. Ocak ayından önce küçük tedarikçilerinizden örnek toplayıp gerçekte ne geldiğine bakın; varsayımla tasarlamayın.
4. Mutabakat raporuna kanal kırılımı ekleyin. Eşleşmeyen faturaların hangi kanaldan geldiğini görmek, sorunun robotta mı yoksa tedarikçi tarafında mı olduğunu çoğu zaman tek bakışta gösterir.

Ne zaman robot yanlış seçim

Dürüst olmak gerekirse bu iş her zaman robot gerektirmiyor. ERP’nizin kendi e-Fatura modülü ya da özel entegratörünüzün hazır bağlantısı ihtiyacınızı karşılıyorsa önce onu kullanın. GİB de e-Fatura’dan yararlanma yöntemi olarak portal, entegrasyon ve özel entegrasyon seçeneklerini ayrı ayrı tanımlıyor. Robot, bu bağlantının kapatmadığı boşlukta değer üretir: birden fazla ERP, eşleştirme kurallarının özel olduğu süreçler ya da kimsenin sahiplenmediği bir mutabakat işi.

Bir de bakım maliyeti var. Ekran üzerinden çalışan bir robot, ERP’nin her sürüm değişikliğinde kontrol ister. Mümkün olan her adımda ekran yerine servis ya da veri tabanı arayüzünü tercih ederim. Ekranı yalnızca başka yol olmadığında kullanırım.

Kopyalamadan önce

Benzer bir akış kurmayı düşünüyorsanız pazartesi şu soruyu sorun: bugün e-Belge tarafında görünen bir faturanın ERP’de olmadığını kaç gün sonra fark ediyoruz? Cevap “ay sonu kapanışında” ise önceliğiniz entegrasyon değil, mutabakat. 2027 takvimi de bu işe başlamak için iyi bir tarih.

UiPath FUSION 2026: Maestro artık iki ürün

UiPath · 23 Eylül 2026

UiPath, FUSION 2026’da Maestro’yu ikiye böldü. Maestro Orchestrate ekipler ve sistemler arasında uzun süre açık kalan süreçler için, Maestro Automate ise yüksek hacimli, kısa işler için. Aynı duyuruda genel kullanıma açılanlar da var: süreç bilgisini dokümanlardan, sistemlerden ve insanlardan derleyip “Map of Work” adlı bir şartnamede tutan Cartographer, geliştiricilerin istedikleri kodlama ajanıyla çalışmasını sağlayan UiPath for Coding Agents ve masaüstü ajanı Delegate. Dark Testing Factory önizlemede, Map of Work ise yol haritasında.

Neden önemli. Bu ayrım, sahada zaten verilen bir kararı ürüne dönüştürüyor. Haftalarca açık kalıp insan onayı bekleyen bir vaka ile saniyeler içinde biten bir kuyruk işi aynı kurallarla yönetilmez. Mimari dokümanlarınızda bu ayrımı şimdiden yapın: hangi süreç durum tutuyor, hangisi yalnızca hacim taşıyor? Cartographer’ı ise PDD’yi güncel tutmanın bir yolu olarak düşünürdüm; PDD yazımının yerini alacağını sanmıyorum. Ben önce dokümanı zaten olan küçük bir süreçte, çıktıyı elimdekiyle karşılaştırarak denerdim.

Gartner: satıcının kurduğu ajanların çoğu bırakılacak

Gartner · 29 Eylül 2026

Gartner’ın 29 Eylül tarihli duyurusuna göre kurumların %70’i, satıcının sahaya gönderdiği mühendislerin (forward-deployed engineering) kurduğu ajan tabanlı yapay zekâ çözümlerini 2028’e kadar bırakacak. Duyurunun özetinde gerekçe olarak artan maliyetler ve kurumların bu sistemleri kendi başına geliştirememesi gösteriliyor. Gartner’ın sayfası otomatik erişime kapalı olduğu için buradaki bilgi duyurunun başlığına ve yayımlanan özetine dayanıyor.

Neden önemli. Ajan projesini dışarıya yaptırmak tek başına sorun değil. Sorun, teslim alınan şeyin bakımını içeride yapamamak. Sözleşmeye üç şey yazdırırdım: sürümlenmiş istemler ve araç tanımları, kabul testinde kullanılan değerlendirme setleri, bir de canlıya geçtikten sonra iç ekibin tek başına yaptığı en az bir değişiklik. Üçüncüsü yapılamıyorsa elinizde bir ürün değil, bir bağımlılık var.

Model Context Protocol 2026-07-28: protokol artık durumsuz

Model Context Protocol Blog · 28 Temmuz 2026

MCP’nin 28 Temmuz sürümü protokolün çekirdeğini durumsuz bir istek-yanıt modeline çevirdi. Başlatma el sıkışması ve oturum kimlikleri kalktı; her istek kendi sürüm ve yetenek bilgisini taşıyor. Sunucunun çağrı ortasında kullanıcıdan girdi istemesi artık Multi Round-Trip Requests ile yapılıyor, yöntem ve araç adları da HTTP başlıklarında (Mcp-Method, Mcp-Name) gidiyor. Yetkilendirme sıkılaştırıldı; Tasks, MCP Apps ve Enterprise Managed Authorization resmî eklenti oldu. Roots, Sampling ve Logging kullanımdan kaldırıldı, geçiş için en az on iki ay süre tanındı.

Neden önemli. Kurum içinde MCP sunucusu işletiyorsanız iki iyi haber var. Sunucular yatayda rahat ölçeklenecek ve bir ağ geçidi, istek gövdesini açmadan hangi aracın çağrıldığını görüp yetki kuralı uygulayabilecek. Bu, güvenlik ekibiyle konuşulabilecek somut bir başlık. Yapılacak iş de belli: hangi sunucularınızın kaldırılan özellikleri kullandığını şimdi listeleyin. Envanteri olmayan bir kurum için on iki ay kısa bir süre.

AB Yapay Zekâ Yasası: yüksek risk ertelendi, şeffaflık ertelenmedi

Avrupa Birliği Resmî Gazetesi · 24 Temmuz 2026

Digital Omnibus olarak bilinen (AB) 2026/1744 sayılı Tüzük, yayımından üç gün sonra, 27 Temmuz’da yürürlüğe girdi. Ek III kapsamındaki yüksek riskli sistemlere ilişkin yükümlülükler 2 Aralık 2027’ye, Ek I kapsamındaki, ürünlere gömülü sistemlerinkiler 2 Ağustos 2028’e kaydı. 50. maddedeki şeffaflık yükümlülükleri ise yerinde kaldı; örneğin kişiye bir yapay zekâ sistemiyle konuştuğunu söyleme yükümlülüğü 2 Ağustos 2026’dan beri geçerli. Üretilen içeriğin makinece okunabilir biçimde işaretlenmesi için, 2 Ağustos 2026’dan önce piyasaya çıkmış sistemlerin sağlayıcılarına dört aylık geçiş süresi tanındı. Bu süre 2 Aralık 2026’da doluyor.

Neden önemli. Türkiye’den AB’ye hizmet veren ya da AB’li müşterisi olan şirketler için iş sırası değişti. Yüksek risk sınıflandırması için nefes payı var, ama müşteriyle konuşan bir sohbet botunuz ya da metin üreten bir akışınız varsa bildirim yükümlülüğü bugünün işi. Ben önce envanteri çıkarırdım: hangi akışta bir insan, karşısında bir model olduğunu bilmeden yazışıyor?

e-Arşiv: basit usul ve işletme hesabında son çeyrek

TÜRMOB · 2 Ocak 2026 (Resmî Gazete, 31 Aralık 2025)

589 Sıra No.lu VUK Genel Tebliği, e-Fatura ve e-Arşiv uygulamasına dahil olmayan mükelleflerden basit usul ve işletme hesabı esasında olanlara bir yıl ek süre verdi. Bu gruptakiler 31 Aralık 2026’ya kadar vergiler dahil 3 bin TL’yi aşmayan faturaları kâğıtta düzenleyebiliyor, aşanları GİB portalından e-Arşiv olarak düzenlemek zorunda. 1 Ocak 2027’den itibaren tutar ne olursa olsun bütün faturaları e-Arşiv olacak. Diğer mükellefler için aynı kural 1 Ocak 2026’dan beri geçerli.

Neden önemli. Esnaftan ve küçük tedarikçiden çok alım yapan şirketlerde borç hesapları hattına hâlâ kâğıt ya da taranmış fatura giriyor. 2027’de bu kanalın daralmasını beklemek mantıklı. Kâğıt fatura okuyan bir OCR akışınız varsa gelecek yılın hacim tahminini bu değişikliği hesaba katarak yeniden yapın. Açılan kapasiteyi e-Belge verisini doğrudan ERP’ye bağlayan entegrasyonlara kaydırmak bence daha akıllıca.

IXP: sayfa başına değil, işlem başına ücret

UiPath Documentation · 8 Temmuz ve 14 Eylül 2026

UiPath, IXP’de yapılandırılmamış ve karmaşık belgelerden veri çıkarımının tüketimini 8 Temmuz’dan itibaren sayfa başına sabit ücret yerine işlem başına ölçüyor. IXP ve Document Understanding lisansları da ek sayfa maliyeti olmadan birlikte kullanılabiliyor. 23 Temmuz’da model sürümlerini doğrudan bir Orchestrator klasörüne dağıtma seçeneği önizlemeye girdi. 14 Eylül’de ise Bring Your Own Subscription önizlemesi açıldı: IXP, kurumun kendi Gemini ya da GPT aboneliğiyle çalışabiliyor, uygun projelerde tüketim indirimli oluyor ve AI Trust Layer politikaları devrede kalıyor.

Neden önemli. Belge işleme iş vakaları çoğunlukla sayfa sayısı üzerinden kurulur. Ölçü birimi değişince hesap da değişir ve hangi belge tipinizde lehinize, hangisinde aleyhinize döndüğünü ancak kendi örneğinizle görebilirsiniz. Elinizdeki iş vakasını gerçek bir aylık belge örneğiyle yeniden hesaplayın. Kendi model aboneliği olan kurumlar için BYOS, veri yerleşimi ve fiyat konuşmasında yeni bir seçenek. Yalnız henüz önizlemede.

Önümüzdeki haftalarda iki şeyi izleyeceğim: Maestro Orchestrate ve Automate’in kullanılabilirlik tarihleri ve 2 Aralık işaretleme tarihi yaklaşırken model sağlayıcılarının ne yayımladığı.

UiPath Maestro ve ajanlarla kurduğumuz lojistik anomali akışı işi üçe bölüyor: kural tabanlı RPA kontrolleri, dil modeliyle sınıflandırma ve operasyon paydaşlarına otomatik istisna bildirimi. Bu yazıda bu iş bölümünün mantığını anlatıyorum.

Kuralın kesin bildiğini modele sormayın

Bir sevkiyat kaydında zorunlu alan boşsa, bunu söylemek için dil modeline gerek yok. Tanımlı bir eşik aşıldıysa ya da aynı kayıt iki kez geldiyse de öyle. Bu kontroller ucuzdur, her seferinde aynı sonucu verir ve denetimde açıklaması kolaydır.

Modeli, kuralın tek başına karar veremediği yerde devreye sokmak gerekir. Bence en net örnek serbest metin. Bir operasyon notunda geçen gecikmenin nedeni, açıklama alanında yazan bir ifade ya da iki alan arasındaki tutarsızlığın anlamı gibi şeyleri kural yazarak yakalamak zordur ve her yeni durumda kural sayısı artar. Sınıflandırma burada işe yarar.

Bu sıralamanın bir yan faydası da var: model yalnızca kuralın işaretlediği kayıtları görür. Böylece maliyet, toplam kayıt sayısıyla değil, şüpheli kayıt sayısıyla büyür.

Modelden serbest yazı değil, form isteyin

Sınıflandırma adımında modelin çıktısını önceden tanımlı bir şemaya bağlamak, akışın geri kalanının sağlam çalışması için şart. Anomali türü sabit bir listeden seçilmeli, gerekçe kısa tutulmalı, model emin değilse bunu söyleyebileceği bir alan olmalı. Serbest metin dönen bir model, akışın sonraki adımlarını tahmin yürütmeye zorlar.

Türler listesini operasyon ekibiyle birlikte yazmak da işin parçası. Listede olmayan bir tür ortaya çıktığında modelin bunu “diğer” diye işaretlemesi, yanlış bir türe zorla yerleştirmesinden iyidir.

Bildirim de bir tasarım işi

Otomatik bildirim, akışın en az konuşulan ama en çok şikâyet alan parçası olabilir. Herkes her şeyi alırsa kısa sürede kimse hiçbir şeyi okumaz. Benim bildirim tasarımında baktığım üç şey var:

• Kim alıyor? Anomali türüne göre ilgili ekip ya da kişi.
• Ne görüyor? Kayıt, anomali türü ve tek cümlelik gerekçe. Okuyanın sisteme girip aramasına gerek kalmamalı.
• Ne zaman tekrar alıyor? Aynı anomali için ikinci bildirim gitmemeli, durum değişmedikçe.

Maestro’nun yeri

Bu akışta orkestrasyonun işi, adımları doğru sırayla çalıştırmak ve bir kaydın hangi aşamada beklediğini görünür kılmak. Kural, model ve insan adımları farklı hızlarda ilerler: kural milisaniyeler içinde biter, insan incelemesi saatler sürebilir. UiPath’in FUSION 2026’da Maestro’yu uzun soluklu süreçler için Orchestrate ve yüksek hacimli kısa işler için Automate diye ikiye ayırması bu farkı ürün düzeyinde tanıyor. Konuyu ilk radarda biraz daha açtım.

İnsan kapısını baştan koyun

Teslim ettiğimiz akışın çekirdeği kural, sınıflandırma ve bildirimden oluşuyor. Benzer bir akışı yeniden kursam, modelin emin olmadığı durumlar için en baştan bir insan inceleme adımı koyardım. Gerekçem basit: bu kayıtlar modelin hangi anomali türünde zorlandığını gösteren en değerli veri. İnsan kararı gerekçesiyle kaydedildiğinde, bir sonraki iyileştirmenin nereden başlayacağı da belli olur.

Genişletmeden önce ölçün

Bir anomali akışını yeni bir bölgeye ya da yeni bir veri kaynağına yaymadan önce üç şeyi ölçerdim:

1. Etiketli küçük bir örnek setinde sınıflandırmanın doğruluğu. Bunu kabul testine yazın.
2. Yanlış alarm oranı. Operasyon ekibinin güveni ilk haftalarda kazanılır ya da kaybedilir.
3. Kayıt başına maliyet. Model çağrıları hacimle birlikte büyür, kural kontrolleri büyümez.

Üçü de ölçülmüyorsa elinizde umut verici bir demo var; o kadar.

Ulusal bayrak taşıyıcı bir havayolunun Finans ve Muhasebe birimi için kurduğumuz belge işleme programı bu ikinci sorunun üstüne kurulu. Program kurumun kendi veri merkezinde çalışıyor, tedarikçi faturalarını uçtan uca işliyor ve canlıda. Bu yazıda kurumun iç detaylarına girmeden, tasarımı belirleyen kararları anlatıyorum.

İlk kısıt: belge binadan çıkmayacak

Mimariyi belirleyen ilk karar teknik değil, kurumsaldı: belgeler kurumun dışına gönderilmeyecek. Finans belgelerinde bu sık rastlanan bir şart ve bence haklı bir şart. Tedarikçi faturası; banka bilgisi, sözleşme fiyatı ve ödeme takvimi taşır.

Bunun sonucu, bulutta birkaç ayarla açılan pek çok şeyin yerinde bir altyapı işine dönüşmesi. Sayısallaştırma ve çıkarım bileşenleri kurum içinde çalışmak zorunda. Model sürümleri, güncellemeler ve kapasite planı da projenin parçası oluyor. UiPath kendi dokümantasyonunda Document Understanding’in Automation Suite ve Standalone kurulumlarda sunulmaya devam ettiğini açıkça yazıyor. Yerinde çalışma şartı olan kurumlar için bu, ürün seçimini daraltan bir bilgi.

Bence buradan çıkacak ders basit: yerinde kurulumu ayrı bir iş kalemi olarak planlayın. Dağıtımın bir alt maddesi sayılırsa, zaman çizelgesinde bir yerde sıkışır.

Okumakla anlamak arasındaki üç zorluk

Bu programın kapsamı üç kelimeyle özetlenebilir: çok para birimi, çok dil, çok tablo. Her biri ayrı bir problem.

Çok para birimi. Tutarın yanında para birimi her zaman yazmaz. Ondalık ayırıcı ülkeden ülkeye değişir ve aynı tedarikçi farklı dönemlerde farklı biçim kullanabilir. Çıkarım sonrasında her tutarın tek bir gösterime çevrilmesi ve para biriminin tedarikçinin beklenen para birimiyle karşılaştırılması gerekir. Bu karşılaştırmayı kurala bırakırım. Model yanılabilir; “bu tedarikçi bize hep avroyla fatura keser” bilgisi ise ana veride zaten var.

Çok dil. Aynı alan farklı dillerde farklı etiketlerle gelir. Latin alfabesi dışındaki yazılar ayrı bir zorluk. Başka bir projede Çince karakterli belgeler için ayrı bir çıkarım hattı kurduk ve bu hat doğruluğu %55 artırdı. Bu sonuç bir şeyi gösteriyor: bütün dilleri tek bir modelle çözmeye çalışmak yerine sorunlu dili ayırıp kendi hattına almak denemeye değer.

Çok tablo. Satır kalemleri birden fazla tabloya dağılabilir, tablolar sayfa sonunda bölünebilir, ara toplamlar satır gibi görünebilir. Burada en iyi sigorta yine bir kural: satırların toplamı fatura toplamını tutmuyorsa belge otomatik geçmez.

İnsan doğrulaması bir yedek değil, tasarımın kendisi

Bu programın iki ayırt edici parçası doğrulama ekranının tasarımı ve yapılandırılmış insan eskalasyonu. İkincisi kulağa soyut geliyor, o yüzden açayım.

Yapılandırılmamış eskalasyonda belge bir kişiye “kontrol eder misiniz?” notuyla gider. Kişi belgeyi baştan okur, neyin yanlış olduğunu kendisi bulur ve her seferinde aynı işi tekrarlar. Yapılandırılmış eskalasyonda ise belge, takıldığı yerle birlikte gelir: hangi alan, hangi kural, hangi güven skoru. Nedeni farklı olan belgeler farklı kişilere gidebilir. Okunamayan bir alan doğrulama ekibinin işidir; ana veride olmayan bir tedarikçi ise satın almanın.

Bunun iki faydası var. Doğrulayan kişi zamanını yalnızca şüpheli alana harcar. İkincisi, düzeltmeler nedenleriyle birlikte kaydedildiği için hangi belge tipinin, hangi alanın sorun çıkardığı ölçülebilir hâle gelir. Model iyileştirmesine nereden başlanacağına bu kayıtlar karar verir.

Güven eşiklerini alan bazında koyarım, belge bazında değil. Tedarikçi adındaki küçük bir okuma hatası ana veri eşleşmesiyle yakalanır; tutardaki bir hata ise kimse fark etmeden ödemeye dönüşebilir. Aynı eşiği ikisine uygulamak mantıklı değil.

Bu kurguyu kopyalamadan önce

Benzer bir programa başlayacak bir ekibe şu listeyi verirdim:

1. Gerçek bir aylık belge örneği toplayın. Tedarikçi, dil, para birimi ve sayfa sayısı dağılımını görmeden tahmin yapmayın.
2. Doğrulama ekranına kimin bakacağını ve haftada ne kadar zamanı olduğunu baştan yazın. İnsan adımı kapasitesiz bir kuyruğa dönüşürse otomasyon yavaşlar.
3. Hangi alanın hangi eşikle geçeceğine iş birimiyle birlikte karar verin ve bu kararın sahibini belirleyin.
4. ERP’ye yazmadan önce son tutarlılık kontrollerini kural olarak tanımlayın. Model ne kadar iyi olursa olsun bu kontrolleri modele bırakmayın.
5. Yerinde kurulum varsa donanım, OCR motoru lisansı ve model güncelleme prosedürünü proje planına ayrı satır olarak koyun.
6. Model sürümü değiştiğinde geri dönüş planınız olsun. Yeni sürüm bir alanda iyileşip başka bir alanda kötüleşebilir.

Bu listedeki maddelerin hiçbiri yapay zekâ ile ilgili değil. Belge işleme projelerinde sonucu belirleyen kararların çoğu da öyle.

BOTTEQ’te belge işleme hatlarını Document Understanding ve Base64.ai’nin OCR/ICR motorlarını birleştirerek kuruyoruz. Aşağıdaki tablonun dayanağı ise UiPath’in kendi dokümantasyonu. Kaynaklar yazının sonunda. Yorumlar ise bana ait.

İki yolun kısa tarifi

Document Understanding (DU), yapılandırılmış ve yarı yapılandırılmış belgeler için: formlar, satın alma siparişleri, başvurular, faturalar. Düzeni aynı ya da birbirine çok yakın olan belgelerde önceden eğitilmiş makine öğrenmesi modelleriyle çalışıyor. Üretken yapay zekâ özellikleri kurumun AI Trust Layer politikalarıyla yönetilebiliyor. DU ayrı bir servis olarak devam ediyor ve Automation Suite ile Standalone kurulumlarda da sunuluyor.

IXP, UiPath’in DU ile Communications Mining’i bir araya getirdiği ve yanına istem (prompt) tabanlı yeni bir yetenek eklediği çatı: yapılandırılmamış ve karmaşık belgeler için üretken çıkarım. Bu yetenek faaliyet raporları, sözleşmeler, kira sözleşmeleri gibi belgeler için tarif ediliyor. Karmaşık tablolar, grafikler, onay kutuları, imza ve el yazısı içeren, değerin bağlamdan çıkarılması ya da bölümler arasında birleştirilmesi gereken durumlar bu yolun alanı. Burada üretken yapay zekâ zorunlu.

Karar tablosu

Tabloya sığmayan üç soru

Karışık belge yığınları. Kredi başvurusu dosyası gibi, kimlik, adres belgesi ve banka dökümünün tek dosyada geldiği durumlarda asıl iş çıkarımdan önce başlar: belgeleri ayırmak ve türlerini belirlemek. Hangi yolu seçerseniz seçin, bu ayırma işinin nerede ve nasıl yapılacağını pilotta netleştirin. Burada kural, model ve insan arasındaki iş bölümü çıkarımdan daha belirleyici olabiliyor.

Proje tipi. DU’nun kendi içinde de seçim var. Modern projeler daha hızlı ve rehberli bir model geliştirme deneyimi sunuyor. Classic projeler model ve veri setini dışa aktarmaya ve kiracılar arası kullanıma izin veriyor, yalnız Automation Cloud’da çalışıyor. AI Center tabanlı projeler en fazla kontrolü veriyor ve Standalone kurulumları da destekliyor, ama Cloud API desteği yok. Yerinde kurulum şartı varsa bu ayrım tek başına seçimi belirleyebilir.

Maliyet birimi. Temmuz 2026’dan bu yana IXP’de yapılandırılmamış ve karmaşık belgelerden çıkarım sayfa başına sabit ücretle değil, işlem başına ölçülüyor. IXP ve DU lisansları da ek sayfa maliyeti olmadan birlikte kullanılabiliyor. Sayfa sayısıyla kurulmuş eski bir iş vakası varsa, onu gerçek bir belge örneğiyle yeniden hesaplamak gerekir.

IXP’ye geçerken iki tuzak

Onayladığınız etiket “doğru” sayılır. IXP’de modelin başarı skoru, sizin onayladığınız etiketlere göre hesaplanır. Etiketleme sırasında yanlış bir değeri onaylarsanız o değer referans olur ve skor yükselir. Yüksek bir skor, değerlerin gerçekten doğru olduğunu kanıtlamaz. Etiketlemeye kabul testi ciddiyetiyle yaklaşın.

Biçim farkını hata sanmayın. Tarih ve parasal tutar gibi hazır veri tipleri değeri normalize edilmiş biçimde döndürür. Sayfadaki “21-JUN-22” ile modelin döndüğü ISO tarih aynı değeri gösteriyorsa bu bir hata değil. Asıl dikkat etmeniz gereken, değerin anlamının değiştiği durumlar: ondalık ayırıcının yanlış okunması gibi.

Benim varsayılanım

Belge setinin çoğu fatura, form ya da sipariş gibi düzeni belli belgelerse Document Understanding ile başlarım. Doğrulamada en çok zaman alan, düzeni dağınık ya da değeri bağlamdan çıkan belgeleri ayrı bir kuyruğa toplarım ve IXP’yi önce o kuyrukta denerim. İki yol aynı hatta birlikte çalışabilir. Seçimi tek seferlik bir platform kararı gibi görmek yerine, belge tipi başına verilen bir karar olarak ele almak bence daha sağlıklı.

Müşteri organizasyonlarında değişiklik yönetimi, izleme ve olay müdahalesi çerçeveleri kurduk. Bu işin özünde basit bir gerçek yatıyor: bir sistemi canlıya almak, ona yetki vermektir. RPA botları için bu yetki dardı; bot ne yapacağı yazılmış adımları izlerdi. Ajan ise bir sonraki adımı kendisi seçiyor. Bu yüzden canlı onayından önce sorulacak sorular da değişiyor. Benim listem yedi soru.

1. Karar mı veriyor, öneri mi?

Aynı ajan, iki farklı rolde bambaşka bir risk taşır. Bir tedarik anomalisini sınıflandırıp bir insanın önüne koyan ajan öneride bulunur. Ödeme blokajını kendisi kaldıran ajan ise karar verir. Tasarım dokümanında her eylem için bu ayrımı tek tek yazın. “Ajan şunu yapar” cümlesi yetmez; “ajan şunu önerir, şu kişi onaylar” ya da “ajan şunu yapar, şu durumda durur” demek gerekir.

2. Yanlış karar geri alınabilir mi, kaça patlar?

Eylemleri iki eksende sıralamayı öneririm: geri alınabilir mi, yanlış olursa maliyeti ne? Geri alınabilir ve ucuz eylemler ajana bırakılabilir. Geri alınamayan ya da pahalı olanlara bir insan onayı kapısı konmalı. Bu kapıyı ajanın yetersizliğinin itirafı gibi görmemek gerekiyor; yaptığınız şey yetkiyi bilinçli olarak bölmek. Kapının nerede durduğu da zamanla değişebilir. Kayıtlar ajanın belirli bir eylem türünde güvenilir olduğunu gösterdikçe kapıyı geri çekmek mümkün olur.

3. Hangi araçlara, hangi kimlikle erişiyor?

Ajanın erişebildiği her araç, onun yapabileceği her şeyin listesidir. İnsan kullanıcının yetkileriyle çalışan bir ajan, o kullanıcının yapabileceği her hatayı yapabilir. Ayrı bir hizmet kimliği, yalnızca gereken araçlar ve gereken en dar yetki şart. Model Context Protocol’ün Temmuz 2026 sürümü bu konuda işinizi kolaylaştırıyor: yöntem ve araç adları HTTP başlıklarında taşındığı için bir ağ geçidi, istek gövdesini açmadan hangi aracın çağrıldığını görüp kural uygulayabiliyor.

4. “Doğru”yu ajanı yazmadan önce tanımladınız mı?

Kabul kriteri olmayan bir ajan projesi, bitmeyen bir demodur. Ajanı yazmaya başlamadan önce gerçek örneklerden küçük bir değerlendirme seti oluşturun: hangi girdi için hangi çıktı doğru, hangisi kabul edilebilir, hangisi hatalı? Bu set hem kabul testinin hem de her istem değişikliğinden sonraki gerileme testinin temeli olur. Dışarıdan yaptırılan projelerde bu set teslim edilecekler listesinde yer almalı.

5. Her çalıştırmanın izi var mı?

Bir ajan yanlış bir şey yaptığında sorulacak ilk soru “neden?” olur. Cevap verebilmek için her çalıştırmada girdinin, çağrılan araçların, aracın döndüğü sonucun, modelin çıktısının ve maliyetin kaydı gerekir. Bu kayıtlar olay müdahalesinin ham maddesi. Olmadan yapılan her inceleme tahmindir. İzi tutmanın bir faydası daha var: hangi görevin kaça mal olduğunu gösterir, bütçe konuşmasını da somutlaştırır.

6. Kişisel veriye dokunuyor mu?

KVKK, 12 Mart 2026’da etken yapay zekâ sistemleri için bir rehber yayımladı. Rehberi özetleyen hukuk notlarına göre kurumlardan beklenenler şunlar: etken yapay zekâ kullanımını kapsayan bir veri yönetişimi çerçevesi ve risk değerlendirmesi, veri işleme aktörleri arasında sorumlulukların netleşmesi, insan gözetiminin tasarım aşamasından itibaren kurgulanması, tasarımdan ve varsayılan olarak mahremiyet, bir de çalışanların bilgilendirilmesi. Bu listedeki her madde yukarıdaki sorulardan birine bağlanıyor. Ajanınız kişisel veri işliyorsa bu bağlantıyı yazılı hâle getirin. Denetimde ilk istenecek belge o olur.

AB’ye hizmet veriyorsanız bir madde daha var. AB Yapay Zekâ Yasası’nın şeffaflık yükümlülükleri yeni tüzükle ertelenmedi. İnsanlarla doğrudan yazışan bir ajan, karşısındakine bir yapay zekâ sistemiyle konuştuğunu söylemek zorunda.

7. Kapattığınızda ne oluyor?

En az sorulan soru bu. Ajan hata verdiğinde, maliyeti beklenmedik şekilde arttığında ya da modelin sağlayıcısı bir değişiklik yaptığında işi kim devralıyor? Benim beklentim, her ajan için yazılı bir geri dönüş yolu olması: aynı işi kural tabanlı bir robot yapabiliyorsa o robot hazırda beklemeli, yapamıyorsa iş bir insan kuyruğuna düşmeli. Kapatma düğmesinin kimde olduğu ve kapatma kararının hangi göstergeyle verileceği de yazılı olmalı.

Cevap “bilmiyoruz” ise

Bu yedi sorudan birine verilen cevap “bilmiyoruz” ise, canlıda bir ajan değil, canlıda bir pilot çalıştırıyorsunuz demektir. Bunda kötü bir şey yok; yeter ki herkes bunun bir pilot olduğunu bilsin. Sorunlar, bir pilotun ürün gibi bütçelendiği ve ürün gibi denetlendiği gün başlıyor.