Bir politika belgesi ajanı neden durduramaz?

Bir şirketin satın alma politikası, tedarikçi bilgilerinin kimlerle paylaşılabileceğini açıkça söylüyor olsun. Satın alma ekibinin ajanı belgeyi okumuş, özetini de doğru çıkarmış. Sonra bir çalışan, gelen bir teklif dosyasını inceletip tedarikçi kaydını güncellemesini istiyor. Dosyanın içinde başka bir işleme yönlendiren bir metin var. Ajanın belgeyi hatırlaması önemli, ama kayıt güncelleme aracını çağırdığı anda bu hatırlama tek başına yetki kontrolü sayılmaz. Neden?

Çünkü politika metni ile eylem farklı yerlerde yaşar. Metin, hem insanın hem modelin ne amaçlandığını anlamasına yardım eder. Araç çağrısı ise gerçek bir değişiklik yapar. Bir politika yalnızca modele verilen açıklamada bulunuyorsa, modelin her durumda onu doğru yorumlayacağına güvenmek gerekir. Yanlış yorum, eksik bağlam ya da dışarıdan gelen yönlendirici içerik yüzünden bu güven kırılabilir. Belgeyi daha sert bir dille yazmak, aracın önüne otomatik olarak bir kapı koymaz.

Kuralı karar anına taşımak

agentic-organization deposundaki ADR-0005 bu ayrımı politika motoruyla ele alıyor. İnsanların okuyacağı politika metni duruyor; içinde yapılandırılmış kural blokları da bulunabiliyor. Motor, ilgili kuralları toplayıp araç adı ve argümanlar gibi girdiler üzerinde bir karar veriyor. Karar izin, onay isteği veya ret olabilir. Böylece konu yalnızca ajanın ne okuduğu değil, bir aracı çalıştırmadan önce hangi kuralla karşılaştığı haline geliyor.

Bu ayrım, örneğin teklif özetlemek ile kaydı değiştirmek arasında işe yarar. İkisi aynı dosyadan başlayabilir. Ama birincisi bir taslak üretirken ikincisi kurumsal kayıt üzerinde işlem yapar. Kural, aracın adı ve parametreleriyle eşleşiyorsa, modelin ürettiği güven verici açıklama işlem iznine dönüşmez. Denetlenebilir nokta cümledeki niyet değil, çağrının kendisidir.

Depodaki uygulamada kurallar politika Markdown içindeki yapılandırılmış bloklardan okunuyor. Şirket, departman ve ajan kapsamındaki ilgili politikalar yükleniyor; alt departmanlar üst departmanın bağlı politikalarını da devralabiliyor. Birden çok kural eşleşirse son eşleşen kuralın sonucu geçerli. Bu sıra, kural yazan ekibin ayrıca sınaması gereken bir tasarım tercihi: genel bir izin ile özel bir ret yanlış sıralanırsa beklenmeyen sonuç doğabilir. Kural yazmak, sadece belgenin altına birkaç teknik satır eklemek değil, karar sırasını ve istisnaları test etmektir.

Neden yalnızca prompt değil?

ADR-0005’in değerlendirdiği ilk seçenek politikaları modelin talimatlarında bırakmak. Böyle yapmak kolay ve açıklayıcı, fakat eylem sınırını modelin yorumuna bağlıyor. Diğer uçta bağımsız, geniş kapsamlı politika dilleri var. Bu yol güçlü olabilir, ancak iş kuralını günlük politika belgesiyle aynı yerde yönetmeyi ve ekiplerin okuyacağı metni korumayı zorlaştırabilir. Seçilen yaklaşım insanın okuyacağı Markdown ile araç çağrısında değerlendirilen yapılandırılmış kuralı birlikte tutuyor. İki katman aynı şey değil: metindeki her cümle kendiliğinden çalışan kurala dönüşmüyor.

Bunun pratik bedeli var. Bir kural eksikse, motorun varsayılan sonucuna bakmak gerekir. Kodda eşleşmeyen çağrılar için varsayılan etki izin; varsayılan çalışma modu ise dry_run. Bu modda düzgün eşleşmiş ret veya onay isteği gözlenebilir, ama henüz zorlanmaz. Hatalı istek veya bozuk kural gibi fail closed sonuçları ise bu modda da engel olur. Dolayısıyla sadece “politika motoru var” demek, her tehlikeli aracın bugün engellendiği anlamına gelmez. Kapsam, varsayılan etki ve enforce ayarı birlikte incelenmeli.

Daha da önemlisi, kodun backend araç yürütme yolunda motorun çağrısını çevreleyen bir istisna yakalayıcısı bulunuyor. Motorun tümden bağlanma veya içe aktarma hatasında bu yolun çağrıyı engellemek yerine devam edebileceğine ilişkin bir TODO var. Bu sınır, “her durumda fail closed” gibi bir güvenlik iddiasını geçersiz kılar. Tasarımın hedefiyle bugünkü uygulanmış yol arasındaki farkı görmek, üretime alma kararının parçasıdır.

Aynı şirket, farklı eşikler

Üretim ekibinde bir ajan bakım kayıtlarını okuyup vardiya özeti hazırlayabilir; makine durumunu değiştiren çağrı ise ayrı değerlendirilmelidir. Satın almada teklifleri karşılaştırmak ile sipariş açmak ayrılır. Finans bir faturadaki tutarı çıkarabilir ama ödeme talimatı hazırlama veya iletme için başka bir kural ister. İK, başvuru belgelerini sınıflandırırken çalışan verisini dışarıya taşıma konusunda daha dar bir sınır çizebilir. Bilgi işlem ekibi bir yapılandırmayı okumaya izin verirken silme aracını kapatabilir. Bunlar mevcut ürünün hazır sunduğu sektör kuralları değil, politika kapsamını belirlerken sorulacak örnek sorulardır.

Departman farkı yalnızca farklı metinler yazmak değildir. Hangi ajanın hangi departmana bağlı olduğu, alt birimin üst birimden neyi devraldığı ve bir ajan için istisna tanımlanıp tanımlanmadığı önemlidir. Motor kapsamı bu ilişki üzerinden çözer. Ancak insanın okuyacağı yazılı gerekçe ile makinenin eşleştireceği araç kuralı ayrı ayrı gözden geçirilmelidir. “Finansın politikası daha sıkı” ifadesi teknik bir kural değildir; hangi çağrının hangi argümanlarla reddedileceği belirlenmedikçe çalışan bir sınır oluşmaz.

Belgeyi kurala dönüştürmenin sırası

İlk adım, ekiplerin bugün yazılı olarak bildiği sınırları toplamak. Ardından gerçekten araç seviyesinde ölçülebilen işlemleri ayırmak gerekir: örneğin hangi araca, hangi kapsamda, hangi parametrelerle gidildiği. İfadelerin geri kalanı başka bir değerlendirme biçimi isteyebilir. Özellikle cevabın içeriğine ilişkin bir kuralı sadece araç adıyla uygulamaya çalışmak yeterli değildir.

İkinci adım, az sayıda kuralı örnek çağrılarla sınamak ve dry_run kararlarını incelemek. Beklenmeyen retler kadar beklenmeyen izinler de kayda değerdir. Sonra kapsam ve varsayılan etki bilerek ayarlanır; gerçekten zorlanması istenen kurallar için enforce kararı verilir. Bu geçiş otomatik bir güvenlik garantisi değil, organizasyonun kontrol ettiği bir işletim kararıdır.

ADR-0017 mevcut politika belgelerini içeri alıp önerilen kuralları insan onayından geçirme, içerik tabanlı davranış kontrolleri ve günlük iş değerlendirmesi gibi daha geniş bir hedef tarif ediyor. Aynı belgenin kabul notu, bu parçaların henüz plan olduğunu açıkça söylüyor. Bugün çalışan araç kuralı motorunu, henüz yapılmamış belge alımı ve çıktı denetimiyle karıştırmamak gerekir. Bir şirket için uygulanabilir sonuç da burada: önce yapılabilen çağrıları görünür kılmak, sonra yazılı politikanın hangi kısmının gerçekten teknik karara bağlandığını göstermek.

Politikanın neden belge olarak kalmaması gerektiği sorusu, ajana hangi işleri devredeceğimiz sorusuyla birlikte okunmalı. agentic-organization içindeki ADR-0005, bu geçişin araç çağrısı sınırını; ADR-0017 ise belgelerden onaylı kurallara uzanan henüz tamamlanmamış yolu gösteriyor. Kendi ekibinizde bir kuralın sadece okunmasını mı, yoksa bir işlemden önce gerçekten kontrol edilmesini mi istediğinizi ayırmak için iyi bir başlangıç noktası.

Doğrulama notu: Bu yazı ADR-0005 ve ADR-0017 ile backend politika motoru ve araç yürütme kodundaki mevcut akış karşılaştırılarak yazılmıştır. Planlanan özellikler uygulanmış özelliklerden ayrı tutulmuştur.