← Tüm yazılar
AIProduct Management
🌐 Read in English

Ajanın Kimlik Belgesi Yok

22 Nisan 2026·5 dk

Geçen hafta Microsoft, AI ajanlar için açık kaynak bir yönetişim aracı yayımladı. OWASP'ın 10 ajansal AI riskini runtime'da, milisaniyeler içinde engelliyor. İyi bir araç.

Ama benim dikkatimi çeken araç değildi. OWASP'ın artık "ajansal AI risk listesi" çıkarmak zorunda kaldığı gerçeğiydi.

Bu liste ancak yeterince ajan, yeterince sorun varsa oluşur. Biz o noktadayız.


Nisan başında EY, 130.000 kişilik işgücüne ajan tabanlı sistemler deploy ettiğini açıkladı. Denetim, 150 ülke, 160.000 süreç. Pilot değil, prodüksiyon. Databricks, ajanların hangi modellere ve araçlara erişebileceğini kontrol etmek için Unity AI Gateway'ini genişletti. Okta, Nisan sonunda "AI ajanlar için kimlik yönetimi" ürününü çıkarıyor.

Sektör bunu artık sesli söylüyor: ajanların kim olduğunu, ne yapabildiğini, ne yaptığını yönetmek zorundayız.


Ben bunu geçen ay pratik olarak hissettim.

Klinik yönetim yazılımımızın kullanıcı izin yapısını gözden geçirirken fark ettim: sistemdeki her kayıt iki şey soruyor. Kim oluşturdu, kim değiştirdi. Kullanıcı ID'sini çekiyor, yazıyor. Basit, mantıklı.

Şimdi şöyle bir senaryo düşünün: klinikte bir AI ajan çalışıyor. Randevu önerileri üretiyor, tedavi takvimlerini revize ediyor, hasta notlarını güncelliyor. Bir hata oluyor — yanlış tarih, yanlış tedavi planı atanmış. Sistem "değiştiren" alanına kimi yazacak?

Ajan bir kullanıcı değil. Ama iz de bırakmıyor.

Bu teorik değil. Bu hukuki bir sorun, regulatif bir sorun, ve ürün tasarımı sorunudur.


Çoğu yazılım insanlar için tasarlandı.

İnsan girişi: şifre. İnsan rolü: tanımlı. İnsan izinleri: kısıtlı. İnsan logu: her değişiklik kayıtlı, her oturum bir kimliğe bağlı.

Ajan? API key ile giriyor. Çoğu zaman geniş izinlerle — çünkü esneklik gerekiyor. Hangi kullanıcı bağlamında çalıştı? Hangi iş kuralını takip etti? Bu kararı kim verdi? Bunların hiçbiri standart log formatında yok.

Okta'nın araştırmasına göre şirketlerin büyük çoğunluğu şu an hangi ajanın neye eriştiğini bilmiyor. Bir kontrol uçağı yok. Yönetici roldeki bir API key sistemin tamamını görebilir, değiştirebilir, silebilir — ve bunu kim için, neden yaptığı hiçbir yerde yazmıyor.


Burada PM devreye giriyor.

Kimlik ve izin yönetimi güvenlik ekibinin konusu gibi görünür. Değil. Kim neyi yapabilir — bu iş mantığıdır. Ajanın hangi veriye erişebileceği — ürün kararıdır. Yapılan işlemin kaydının nasıl tutulacağı — UX ve veri modelidir.

"Bu ajan kimdir?" sorusunu sormak PM'in işi.

Sağlık yazılımında bu çok daha kritik. KVKK, denetim logları, e-Nabız entegrasyonu — bir hasta kaydının kimin tarafından değiştirildiği hukuki sorumluluk demek. Şu an bir ajan o kaydı değiştirdiyse sistem ne söylüyor? Klinik ne diyor?

17 tane destek talebi önünde "bu işlemi kim yaptı?" sorusuna cevap "sistem yaptı" olamaz.


Microsoft'un toolkit'i bir başlangıç noktası. Ama asıl soru şu: ürününüz bir ajan tarafından kullanıldığında ne oluyor?

Çoğu SaaS bu soruyu sormadı. Ben de sormamıştım. Bir ay önce geriye döndüm ve baktım: permission modeli, audit log, rol hiyerarşisi — hepsi insan varsayıyor.

Ajan varsayım değildi. Artık ajan varsayım.

"Ajanın kimlik belgesi yok" demek, onun sisteminizde anonim davranabileceği anlamına geliyor. Anonim ve yetkili. İkisi bir arada tehlikeli bir kombinasyon.


Bu konu önümüzdeki 12 ayda ürün roadmap'lerinde mutlaka yer bulacak. Şimdi soran PM'ler mimariyi kuruyor. Sormayanlar, daha sonra destek taleplerinde yanıt arayacak.