ERP Entegre Yapay Zeka Agent Geliştirmede İşlemler İnsan Onayıyla Nasıl Yürütülmeli?

ERP Agent İşlemlerinde Risk Seviyesi Nasıl Ayrıştırılır?

ERP üzerinde çalışan bir agent için ilk karar, bilgi okuma ile kayıt değiştirme yetkilerini birbirinden ayırmaktır. Ürün stoğunu sorgulamak, açık siparişleri özetlemek veya fatura durumunu açıklamak düşük etkili bir okuma işlemidir; buna karşılık satın alma talebi oluşturmak, müşteri limitini değiştirmek ya da muhasebe kaydını kesinleştirmek kurumsal sonucu doğrudan etkiler. İşlem etkisi yükseldikçe insan kontrolü ve teknik koruma katmanı da yükselmelidir.

Okuma, taslak ve kesinleştirme üç ayrı yetki olmalıdır

Agentın yalnızca “erişimi var” veya “erişimi yok” şeklinde değerlendirilmesi yetersizdir. Sağlıklı modelde okuma, öneri üretme, taslak oluşturma ve kesin kayıt atma farklı yetki seviyeleri olarak ele alınır. Daha geniş mimariyi değerlendirirken ERP, CRM ve doküman süreçleri için AI agent mimarisi yaklaşımı da araç çağrılarının iş süreciyle nasıl ilişkilendirileceğini netleştirir. Böylece agentın karar alanı ile ERP'nin otorite alanı birbirine karışmaz.

• Salt okuma yapan sorgular düşük riskli sınıfta tutulabilir.
• Taslak kayıtlar ERP içinde ayrı durum koduyla açılabilir.
• Finansal veya stok etkili işlemler onaysız kesinleşmemelidir.
• Yetki seviyesi işlem türü ve kullanıcı rolüne göre değişmelidir.
• Agentın her araç çağrısı önceden tanımlanmış bir amaca bağlanmalıdır.

Güvenlik bir süreçtir, ürün değil. - Bruce Schneier

Hangi ERP İşlemleri Agent Tarafından Taslak Hazırlanmalı?

Agent, geri döndürülmesi zor veya finansal etkisi yüksek işlemleri doğrudan kesinleştirmek yerine taslak olarak hazırlamalıdır. Satın alma talebi, teklif taslağı, masraf kaydı, tedarikçi talebi, stok transfer önerisi ve müşteri hizmeti kaynaklı sipariş değişikliği gibi kayıtlar buna uygundur. Taslak aşaması, otomasyon hızını korurken karar sorumluluğunu insanda bırakır.

Taslak kapsamı işlem etkisi ve geri dönüş maliyetine göre seçilir

Her şirketin “kritik işlem” tanımı farklıdır. Bu nedenle sabit bir liste yerine tutar, veri hassasiyeti, stok etkisi, finansal kapanış, vergi sonucu, müşteri taahhüdü ve dış sisteme bildirim gibi ölçütler kullanılmalıdır. Örneğin düşük tutarlı bir satın alma talebi otomatik taslak olabilirken belirli eşik üzerindeki bir talep ek belge ve onay isteyebilir. Taslağın ERP içinde hangi statüde tutulacağı ve kimlerin düzenleyebileceği de baştan belirlenmelidir.

• Satın alma talepleri onay öncesi taslak olarak oluşturulabilir.
• Satış siparişi değişiklikleri kesinleşmeden önce kullanıcıya gösterilebilir.
• Stok transferleri öneri olarak hazırlanıp depo sorumlusuna yönlendirilebilir.
• Masraf ve gider kayıtları belge kontrolünden sonra onaya sunulabilir.
• Tedarikçi veya müşteri ana veri değişiklikleri otomatik kesinleşmemelidir.
• Muhasebe fişi gibi yüksek etkili kayıtlar çift kontrol gerektirebilir.

İnsan Onayı Hangi Aşamada ve Hangi Yetkili Rolünden Alınmalı?

İnsan onayı, agent gerekli veriyi topladıktan ve işlemi taslak olarak hazırladıktan sonra, ERP üzerinde kalıcı değişiklik yapılmadan hemen önce alınmalıdır. Onay verecek kişi ise agentın kullanıcı hesabı değil, sürecin gerçek sorumluluğunu taşıyan rol olmalıdır. Onay matrisi işlem türü, tutar, departman ve risk seviyesine göre tanımlanmalıdır.

Onay ekranı karar için gerekli bağlamı tek yerde göstermelidir

Onay isteyen arayüz yalnızca “kabul et” düğmesi sunmamalıdır. Agentın hangi girdileri kullandığı, hangi kaydı değiştireceği, önceki ve önerilen değer, tutar, bağlı belge ve işlem gerekçesi görünmelidir. Canlı sisteme geçişte MLOps, güvenlik ve insan onayının birlikte tasarlanması, teknik kontrol ile operasyonel sorumluluğun aynı akışta ele alınmasına yardımcı olur. Onay sonrası agent yalnızca onaylanan versiyonu kesinleştirmelidir.

• Süreç sahibi kritik işlem türlerini ve onay rollerini belirlemelidir.
• Tutar eşikleri farklı yönetici seviyelerine yönlendirme yapabilir.
• Onay isteyen kayıt değişirse önceki onay geçersiz sayılmalıdır.
• Reddedilen işlem gerekçesi denetim kaydında tutulmalıdır.
• Onay yetkisi vekâlet ve izin dönemlerini de kapsamalıdır.

Agent Erişimi ve Araç Çağrıları Nasıl Sınırlandırılmalı?

Agentın ERP erişimi en az yetki ilkesiyle sınırlandırılmalı; yalnızca görevi için gerekli kayıtları okuyabilmeli ve yalnızca izin verilen araçları çağırabilmelidir. Tek bir geniş yetkili servis hesabı üzerinden tüm modüllere erişmek, operasyonel riski büyütür. Yetkilendirme kullanıcı, agent, araç, kayıt türü ve işlem eşiği düzeyinde ayrıştırılmalıdır.

Araç katmanı model çıktısından bağımsız politika uygulamalıdır

Model bir işlemi talep etse bile gerçek API çağrısı ayrı bir politika katmanından geçmelidir. Bu katman izin verilen endpointleri, alanları, tutar limitlerini, şirket kodlarını ve çalışma saatlerini kontrol edebilir. Ayrıca prompt injection veya beklenmeyen model davranışı gibi riskler için kurumsal yapay zekâ güvenliğinde yetkisiz erişim kontrolleri dikkate alınmalıdır. Agentın kimliği ve adına işlem yaptığı kullanıcı da denetim açısından ayrı tutulmalıdır.

• Her agent için ayrı servis kimliği ve kapsam tanımlanmalıdır.
• Okuma ve yazma izinleri farklı yetki paketlerinde tutulmalıdır.
• İzin verilen API uçları beyaz liste mantığıyla sınırlandırılmalıdır.
• Tutar veya adet limitleri araç katmanında zorunlu kontrol edilmelidir.
• Hassas alanlar maskeleme veya alan bazlı yetkiyle korunmalıdır.
• Yetki değişiklikleri versiyonlanmalı ve geriye dönük izlenebilmelidir.

Yanlış ERP İşlemi Nasıl Durdurulur ve Geri Alınır?

Yanlış bir agent işlemini güvenli biçimde yönetmek için yalnızca “iptal” butonu yeterli değildir; işlem öncesi doğrulama, kesinleştirme kilidi, idempotency kontrolü ve geri alma planı birlikte tasarlanmalıdır. Özellikle ERP kayıtlarında aynı çağrının iki kez çalışması veya bağlantı kesildiği için sonucun belirsiz kalması ciddi veri tutarsızlığı yaratabilir. Her yazma işlemi kontrollü biçimde durdurulabilir, tekrar edilebilir veya telafi edilebilir olmalıdır.

Geri alma yöntemi ERP işleminin doğasına göre belirlenir

Bazı kayıtlar teknik olarak silinmemeli, ters kayıt veya düzeltme belgesiyle telafi edilmelidir. Bu nedenle rollback tasarımı ERP'nin muhasebe ve işlem kurallarıyla uyumlu olmalıdır. Entegrasyon kesintisinde agent yeni işlem başlatmamalı; durum belirsizse önce ERP'den işlem sonucunu sorgulamalıdır. Tekrar denemelerde benzersiz işlem anahtarı kullanılması, aynı talebin iki kez kesinleşmesini önler ve destek ekibinin sorunu daha hızlı ayıklamasını sağlar.

• Kesinleştirme öncesi son doğrulama kuralı çalıştırılmalıdır.
• Her yazma çağrısına benzersiz işlem kimliği verilmelidir.
• Bağlantı kesilirse sonuç doğrulanmadan otomatik tekrar yapılmamalıdır.
• Silme yerine ters kayıt gereken ERP süreçleri önceden belirlenmelidir.
• Acil durdurma mekanizması agentın yazma araçlarını merkezi olarak kapatmalıdır.
• Başarısız işlem kullanıcıya ve süreç sahibine açık durumla gösterilmelidir.

Agent Denetim Kaydı Hangi Kritik Bilgileri Saklamalıdır?

Agent denetim kaydı, yalnızca işlemin başarılı veya başarısız olduğunu değil, kararın hangi veriler ve hangi yetkilerle üretildiğini de gösterebilmelidir. Kurumsal inceleme için kullanıcı, agent kimliği, çağrılan araç, hedef kayıt, önceki değer, önerilen değişiklik, onaylayan kişi, zaman damgası ve ERP sonucu birlikte tutulmalıdır. Denetim izi sonradan açıklama yapabilecek kadar ayrıntılı, gereksiz hassas veri toplamadan yeterli olmalıdır.

Kayıtlar operasyon, güvenlik ve hata analizi için kullanılmalıdır

Log tasarımının amacı yalnızca uyum gereksinimini karşılamak değildir. Destek ekibi hangi adımın bozulduğunu, güvenlik ekibi yetki dışı girişimi, süreç sahibi ise sık reddedilen önerileri görebilmelidir. Model girdilerinin tamamını sınırsız saklamak yerine gerekli bağlam, politika sonucu ve işlem özeti tutulabilir. Logların değiştirilmesini zorlaştıran merkezi kayıt sistemi ve erişim ayrımı, özellikle yüksek etkili ERP modüllerinde önemlidir.

• İşlemi başlatan kullanıcı ve agent kimliği birlikte kaydedilmelidir.
• Kullanılan araç ve API uç noktası görünür olmalıdır.
• Önceki değer ile önerilen değişiklik karşılaştırılabilmelidir.
• Onay veya ret kararı ve karar sahibi saklanmalıdır.
• ERP yanıt kodu ve işlem sonucu ilişkilendirilmelidir.
• Hassas veriler loglarda gereksiz biçimde çoğaltılmamalıdır.

ERP Entegrasyonu İçin Hangi Teknik Belgeler Gereklidir?

ERP entegre yapay zeka agent geliştirme teklifi hazırlanabilmesi için yalnızca API dokümanı yeterli değildir; süreç akışı, yetki matrisi, veri sözlüğü, test ortamı bilgisi ve hata senaryoları da paylaşılmalıdır. Teknik ekip hangi kaydın nereden geldiğini ve hangi durumda değiştirilebildiğini bilmeden güvenli araç çağrıları tasarlayamaz. Keşif dokümanı entegrasyon sınırlarını ve iş sorumluluklarını aynı anda görünür kılmalıdır.

Teklif öncesi belge seti belirsizliği ve yeniden işi azaltır

ERP'nin REST, SOAP, OData, webhook, mesaj kuyruğu veya özel entegrasyon katmanı sunup sunmadığı; kimlik doğrulama yöntemi; rate limit; sandbox erişimi ve hata kodları netleştirilmelidir. Mevcut sistem yapısını değerlendirmek için ERP ve CRM ile kurumsal yazılım entegrasyonu kapsamındaki veri akışı ve sistem sınırı yaklaşımı da yararlıdır. Ayrıca süreç sahibi, onay rolleri ve pilotta kullanılacak gerçekçi test senaryoları dokümana eklenmelidir.

• ERP API veya entegrasyon servisleri dokümantasyonu paylaşılmalıdır.
• İş süreçleri adım adım ve sorumlu rollerle gösterilmelidir.
• Onay matrisi tutar ve işlem türü eşikleriyle tanımlanmalıdır.
• Veri sözlüğü zorunlu alanları ve kod listelerini açıklamalıdır.
• Test ortamı, örnek veri ve kimlik doğrulama yöntemi belirtilmelidir.
• Hata, kesinti ve geri alma senaryoları belgeye eklenmelidir.

Kontrollü ERP Agent Pilotu Nasıl Planlanıp Ölçülmelidir?

İlk pilot, tüm ERP süreçlerini kapsamak yerine tek bir işlem ailesi, sınırlı kullanıcı grubu ve düşük etkili yetki setiyle başlamalıdır. Amaç agentın ne kadar çok işlem yaptığı değil, doğru taslağı üretip doğru noktada durması, insan onayını doğru kişiye yönlendirmesi ve hata halinde güvenli davranmasıdır. Pilot başarısı otomasyon oranından önce doğruluk, kontrol edilebilirlik ve operasyonel kabul ile ölçülmelidir.

Teknik ortak seçimi pilotun üretim ortamına taşınmasını belirler

Teklifleri karşılaştırırken yalnızca model seçimine değil ERP entegrasyonu, yetkilendirme, test otomasyonu, denetim kaydı, geri alma, gözlemleme ve canlı sistem desteğine bakılmalıdır. Pilot başarısını gerçek kullanıcılarla değerlendirme yaklaşımı için AI pilot proje başarı ölçütlerinin belirlenmesi süreci destekleyici bir çerçeve sunar. Teknik keşifte örnek işlemler, süreç sahipleri, onay matrisi ve ERP API olanakları birlikte incelenirse teklif kapsamları daha karşılaştırılabilir hale gelir.

• Pilot tek bir yüksek değerli fakat yönetilebilir sürece odaklanmalıdır.
• Başarı kriterleri gerçek kullanıcı senaryolarıyla ölçülebilir olmalıdır.
• Yanlış taslak, yanlış yönlendirme ve entegrasyon kesintisi test edilmelidir.
• Canlıya geçiş için yetki genişletme adımları ayrıca onaylanmalıdır.
• Destek, izleme ve değişiklik yönetimi teklif kapsamına dahil edilmelidir.
• Üretim öncesi sorumluluk matrisi teknik ve iş ekiplerince doğrulanmalıdır.