Bir yapay zekâ ajanına ERP (kurumsal kaynak planlama) sisteminize güvenli erişim vermek için ajana işini yapmasına yetecek en dar yetkiyi tanımlamanız gerekir: veritabanının tamamı yerine salt okunur görünümler, kayıt yerine taslak ve para, stok veya ana veriyi değiştiren her işlem için insan onayı. İstanbul'da uygulamalı makine öğrenmesi ve yapay zekâ danışmanlığı veren Data Department, üretici, distribütör ve perakende şirketleri için ajan mimarilerini bu ilkeyle tasarlar.
Yapay zekâ ajanı sıradan bir ERP kullanıcısından neden farklıdır?
Yapay zekâ ajanı, bir LLM (büyük dil modeli) üzerine kurulan ve hangi aracı çağıracağına kendisi karar verebilen bir yazılımdır. Sorgu çalıştırabilir, belge okuyabilir, sipariş kaydı oluşturabilir. Ajanı yararlı kılan bu yetenektir; riskli kılan da aynı yetenektir.
Bir çalışan talimatı yöneticisinden alır. Ajan ise işlediği her metni talimat olarak yorumlayabilir: e-postalar, tedarikçi belgeleri, web sayfaları ve diğer araçların çıktıları. Bu metinlerden birinde gizli bir talimat bulunuyorsa, geniş yetkilerle bağlanmış bir ajan bu talimatı uygulayabilir. OWASP (Open Worldwide Application Security Project) Top 10 for LLM Applications 2025 listesi, istem enjeksiyonunu (prompt injection) birinci risk, görevin gerektirdiğinden fazla yetki ve özerklik anlamına gelen "aşırı yetkiyi" (excessive agency) ise altıncı risk olarak sıralamaktadır.
Buradan çıkan sonuç açıktır. Ajanı işe yeni başlamış bir çalışan gibi değerlendirmelisiniz. Ajana binanın ana anahtarını değil, yalnızca ihtiyaç duyduğu kapıları açan bir giriş kartı verilmelidir.
Geniş erişim hangi sorunlara yol açar?
Ajan pilotlarında karşılaştığımız sorunların çoğu dikkat çekici saldırılar değil, tasarımda yapılan sıradan kestirmelerdir:
- Ajan ortak bir yönetici hesabıyla bağlanır; bu nedenle her işlem bilgi teknolojileri biriminden yapılmış gibi görünür.
- Kimse daha dar bir kapsam tanımlamadığı için ajan, bordro ve müşteri banka bilgileri dahil tüm tabloları sorgulayabilir.
- Ajan belgeleri doğrudan kaydedebilir; yanlış okunan bir miktar gerçek bir satın alma siparişine dönüşür.
- Bir işleme hangi istemin, hangi verinin ve hangi araç çağrısının yol açtığı kayıt altına alınmaz.
Bu kestirmelerin her biri pilot aşamasında zaman kazandırır ancak ajanın canlı kullanıma alınmasını onaylanamaz hâle getirir.
"Ana anahtar değil, giriş kartı" ilkesi uygulamada ne anlama gelir?
Ajanı herhangi bir sisteme bağlamadan önce ihtiyaç duyduğu her yeteneği aşağıdaki dört düzeyden birine yerleştirmenizi öneririz:
| Düzey | Ajanın yapabileceği | ERP'de örnek | Kontrol yöntemi |
|---|---|---|---|
| Okuma | Seçilmiş, salt okunur görünümleri sorgulamak | Açık siparişler, depo bazında stok, teslim tarihleri | Ayrılmış veritabanı görünümleri, satır bazında filtreler |
| Taslak | Kaydı oluşturmadan hazırlamak | Taslak satın alma talebi, taslak müşteri yanıtı | Bir çalışan inceler ve kaydeder |
| Onaylı işlem | Adı belirli bir kişinin onayından sonra uygulamak | Teslim tarihini değiştirmek, bloke siparişi serbest bırakmak | İş akışında onay adımı ve kayıt |
| Yasak | Ajana hiçbir şekilde açılmaz | Ödemeler, ana veri değişiklikleri, kullanıcı yetkileri, silme işlemleri | Araç olarak tanımlanmaz |
Yararlı ERP ajanlarının büyük bölümü ilk iki düzeyde çalışır. Bir kullanım senaryosu "yasak" düzeyindeki işlemleri gerektiriyorsa, bu senaryo genellikle bir ajan için uygun değildir.
Okuma yetkisi nasıl tasarlanmalıdır?
Ajanı doğrudan canlı veritabanına bağlamamanızı öneririz. Kullanıcıların gerçekte sorduğu soruları yanıtlayan, sütun adları ve iş tanımları açık az sayıda görünüm oluşturun. Doğal dilden SQL (yapılandırılmış sorgu dili) sorgusu üreten, NL2SQL (doğal dilden SQL'e) olarak adlandırılan bir asistan, iyi belgelenmiş üç görünüm üzerinde çalıştığında yüzlerce ham tabloyu tahminle dolaşan bir asistandan daha doğru yanıt verir.
Ajanın değil, soruyu soran kullanıcının yetkilerini uygulayın. Bir bölge satış müdürü soru sorduğunda ajan yalnızca o müdürün görmeye yetkili olduğu veriyi görmelidir. Mümkün olduğunda raporlama veritabanı veya okuma kopyası kullanılmalıdır; böylece hatalı bir sorgu sipariş girişini yavaşlatamaz.
Hangi işlemler insan onayı gerektirmelidir?
Uygulanabilir bir kural şudur: gönderim, ödeme, silme veya ana veri değişikliği içeren her işlem bir çalışanın onayını gerektirmelidir. Ajan işlemi hazırlar ve gerekçesini açıklar; adı belirli bir kişi işlemi ERP'nin olağan iş akışı içinde onaylar.
Bu yaklaşım geçici bir alışma dönemi önlemi değildir. Etkisi yüksek işlemler için kalıcı ve doğru tasarım budur. Ajan, bilgiyi toplama ve kaydı hazırlama süresinden tasarruf sağlar; sorumluluk ise çalışanda kalır.
Ajanın işlemleri nasıl denetlenebilir hâle getirilir?
Ajana ERP'de ve bağlı tüm sistemlerde, çalışanlardan ve bilgi teknolojileri servis hesaplarından ayrı, kendine ait bir kimlik tanımlayın. Ardından her işlem için şu bilgileri kayıt altına alın:
- işlemi kimin istediği ve ajanın kimin adına hareket ettiği;
- hangi aracın hangi parametrelerle çağrıldığı;
- ajanın karar vermeden önce hangi veriyi okuduğu;
- işlemi kimin, ne zaman onayladığı.
Bu kayıt sayesinde "bu işlemi kim, neden yaptı?" sorusunu dakikalar içinde yanıtlayabilirsiniz. Böyle bir kayıt bulunmadığında açıklanamayan tek bir değişiklik projenin sona ermesine yol açabilir.
Ajanı ERP sisteminize bağlamadan önce kontrol listesi
- [ ] Ajanın ortak veya yönetici hesabı değil, kendine ait bir kimliği vardır.
- [ ] Okuma erişimi ham tablolar üzerinden değil, adı ve tanımı belirli görünümler üzerinden sağlanır.
- [ ] Ajanın görebileceği veri, soruyu soran kullanıcının yetkileriyle sınırlıdır.
- [ ] Her yazma işlemi taslak olarak hazırlanır veya adı belirli bir kişinin onayını gerektirir.
- [ ] Ödemeler, ana veri, kullanıcı yetkileri ve silme işlemleri araç olarak tanımlanmamıştır.
- [ ] Her araç çağrısı kullanıcı, parametreler, okunan veri ve onaylayan kişi bilgisiyle kaydedilir.
- [ ] E-posta, belge ve web sayfalarından gelen metinler talimat olarak değil, veri olarak işlenir.
- [ ] Ajanın mevcut yetkileriyle yapabileceği en kötü işlem yazılı olarak belirlenmiştir.
Son madde ekipte endişe yaratıyorsa, yetkileri pilottan sonra değil, pilottan önce daraltmanız gerekir. Bir ajan tasarımını ekip dışından biriyle sınamak için ücretsiz 30 dakikalık yapay zekâ fırsat değerlendirmesi uygun bir başlangıçtır. Bu sistemleri nasıl kurduğumuzu üretken yapay zekâ ve kurumsal asistanlar sayfamızda, belge tarafını ise üretimde belge işleme yazımızda bulabilirsiniz.
Sık sorulan sorular
Yapay zekâ ajanı ERP'de doğrudan işlem kaydedebilir mi?
Teknik olarak mümkündür ancak para, stok veya ana veriyi etkileyen işlemlerde bunu önermiyoruz. Ajanın taslak hazırlaması ve adı belirli bir kişinin bu taslağı olağan iş akışında kaydetmesi daha güvenli bir yöntemdir.
Salt okunur erişim her zaman güvenli midir?
Salt okunur erişim çok daha güvenlidir ancak kendiliğinden güvenli değildir. Okuma yetkisi de maaş, fiyat veya müşteri verisini açığa çıkarabilir; bu nedenle erişim seçilmiş görünümlerle ve her kullanıcının kendi yetkileriyle sınırlandırılmalıdır.
Ajanın ayrı bir kullanıcı hesabı olması gerekir mi?
Evet. Ayrı bir kimlik, ajanın yetkilerini sınırlamanıza, başka hiçbir kullanıcıyı etkilemeden ajanı devre dışı bırakmanıza ve her işlemi ajana ve talebi yapan kişiye kadar izlemenize olanak tanır.
ERP ajanı projesine nereden başlanmalıdır?
Sipariş durumu veya stok bulunabilirliği gibi, birkaç seçilmiş görünüm üzerinde çalışan salt okunur bir soru yanıtlama senaryosuyla başlamanızı öneririz. Taslak ve onay adımları, kullanıcılar yanıtlara güvenmeye başladıktan sonra eklenmelidir.