Ana içeriğe geç

Bölüm 16: Model Rules ve System Prompts

Bu bölüm, AI model erişim kontrolü (Model Erişimi / Model Kuralları) ve yönetici tanımlı sistem komutu enjeksiyonu (Sistem Komutları / System Prompts) olmak üzere iki ayrı sayfayı kapsar. Her iki sayfa da yeniden kullanılabilir kural kütüphanesi mantığıyla çalışır: kural burada tanımlanır, Erişim Yönetimi üzerinden bir hedefe bağlanarak etkinleşir (Bölüm 11). İki sayfa birbirinden bağımsız iki eksendir — model erişimini yalnızca Model Erişim kuralları belirler; sistem komutları erişim vermez, erişilen modellerdeki davranışı şekillendirir.

Model Erişimi (Model Kuralları) Sayfası

Model Kuralları sayfası, kullanıcıların ve grupların hangi modellere erişebileceğini denetleyen yeniden kullanılabilir kural kütüphanesidir. Tüm modeller her kullanıcı için uygun veya gerekli olmayabilir; bu sayfa model ve sağlayıcı gruplarını merkezi olarak tanımlamayı sağlar. İzin veya ret etkisi bu sayfada değil, atama sırasında Erişim Yönetimi'nde belirlenir.

Sayfa; kural tablosu, arama kutusu ("Ad, model ID, araç, kapsam ara"), Yenile butonu ve "Kural Ekle" butonundan oluşur. Liste sayfa başına 8 kural gösterilir ve sayfalanır. Sayfanın üst kısmında Erişim Yönetimi'ne giden kısayol bulunur.

Kural tablosu sütunları:

  • Ad: Kuralın görünen adı. Varsayılan kurallar "Varsayılan" badge'i ile işaretlenir.
  • Model ID: Kuralın hedeflediği model veya sağlayıcı grubu (ör. claude-3-5-sonnet, openai:*).
  • Araç: Kuralın hedeflediği araç adı. Varsayılan: * (tüm araçlar).
  • Kapsam: Kuralın geçerli olduğu trafik türü (aşağıda).
  • Öncelik: Sayısal öncelik değeri. Küçük değer önce değerlendirilir.
  • İşlemler: Düzenle ve Sil butonları (varsayılan kurallar silinemez).

Kural oluşturma (Kural Ekle) alanları:

  • Kural Adı: Kuralın görünen adı (en fazla 128 karakter). Boş bırakılırsa model ID'si ad olarak kullanılır. Örnek: "Tüm OpenAI modelleri".
  • Model ID: Hedef model. Model kimliği seçici, kurumun model kayıt defterinden ve sağlayıcı kataloğundan (Bölüm 8) öneri sunar; serbest metin yazılabilir. Joker karakter desteklenir: openai:* tüm OpenAI modellerini, * ise her modeli kapsar.
  • Araç: Modelin kullanabileceği araç adı. Varsayılan * tüm araçları ifade eder; belirli bir araç adı yazılarak (ör. web_search) yalnızca o araç denetlenir.
  • Kapsam: Kuralın geçerli olduğu trafik türü — Tümü, API veya Tarayıcı Proxy (aşağıda).
  • Öncelik: 1–100 arası tam sayı. Yeni atamalar için varsayılan değer (aşağıda).

Model kimliği seçicinin önerileri iki kaynaktan gelir: System Settings'teki "ACL uygulanabilir modeller" kayıt defteri (kurumun kendi kaydettiği model kimlikleri) ve ağ geçidinin küratörlü sağlayıcı kataloğu. Kayıt defterine model eklemek zorunlu değildir; kurallar serbest metin model kimliği de kullanabilir.

Kapsam (Scope)

Model erişimi tek tip bir bağlamda değerlendirilmez. Üç kapsam vardır:

Kapsam Değer Geçerli olduğu trafik
Tümü * (boş bırakmakla aynı) Hem API hem tarayıcı trafiği
API api Birleşik gateway, sağlayıcı API hostları ve coding agent'lar (explicit proxy üzerinden Claude Code, Codex)
Tarayıcı Proxy transparent Yalnızca transparent proxy üzerinden gelen tarayıcı trafiği (claude.ai, ChatGPT, Gemini)

Geçersiz bir kapsam değeri artık kabul edilmez; geçerli değerler *, api ve transparent'ır (boş = tümü). Geçersiz değerle kaydedilmiş eski kurallar veya atamalar silinmez, ancak panelde "All" yerine eşleşen trafik olmadığını belirten bir etiketle ("Geçersiz kapsam — eşleşen trafik yok") gösterilir; böyle bir satır hiçbir isteğe uygulanmaz ve kapsamın Erişim Yönetimi'nde ya da ilgili kütüphane sayfasında geçerli bir değerle düzeltilmesi gerekir (#1480).

Öncelik (Priority)

Öncelik alanı 1–100 arası bir tam sayıdır; küçük sayı önce değerlendirilir (1 en önce, 100 varsayılan olarak en son). Sıralama iki düzeyde belirlenir:

  • Aynı hedef katmanında (kullanıcı kuralları kendi arasında, grup kuralları kendi arasında) küçük öncelik değeri kazanır. Örneğin 50 öncelikli bir kural 100 öncelikli bir kuralı geçersiz kılar.
  • Daha dar bir hedef katmanı öncelikten bağımsız olarak her zaman kazanır: kullanıcı > grup/IP > rol sıralamasında daha spesifik olan kural uygulanır.

Kütüphane kuralındaki öncelik, o kuralın yeni atamaları için varsayılan değerdir; atama sırasında Erişim Yönetimi'nde hedef bazında değiştirilebilir. Kütüphane kuralının önceliğini değiştirmek, önceliği hâlâ varsayılan olan atamaları da günceller.

Geçerli aralığın dışındaki değerler reddedilir: 0 artık kabul edilmez (daha önce sessizce 100 olarak kaydediliyordu), negatif değerler ise hatanın o değeri adlandırdığı bir hata iletisiyle geri çevrilir (#1204).

Varsayılan Kurallar

Yeni kurulumlarda Arceris, yaygın sağlayıcılar için varsayılan model erişim kuralları ile gelir. Bu kurallar "Varsayılan" badge'i ile işaretlenir ve silinemez; düzenlenebilirler. Kurum bu kuralları temel alarak kendi politikalarını oluşturabilir.

Model Erişim bir İzin Listesidir

Model Erişim, izin listesi (allow-list) mantığıyla çalışır: bir hedefin bir sağlayıcıya erişebilmesi için ona izin veren bir kuralın atanmış olması gerekir. Bu nedenle yalnızca bir deny atamak (ör. sadece DENY google:*) açıkça izin verilmemiş tüm sağlayıcıları da kapatır — ChatGPT ve Claude dahil.

Panel bu sonucu atama anında görünür kılar (#1275):

  • Atama formu izin listesi kuralını açıklar ve "Kaydettikten sonra sağlayıcı erişimi" önizlemesini gerçek politika motorundan hesaplayarak gösterir: hangi sağlayıcının açık, hangisinin kapalı kalacağı, her biri için gerekçeyle birlikte listelenir.
  • Denetlediği tüm sağlayıcıları kapatacak bir deny için amber renkli uyarı gösterilir: "Bu deny, bu hedef için Arceris'in denetlediği TÜM sağlayıcıları kapatır… Yalnızca bu modelleri kapatmak için bu hedefe, tutması gereken modellere izin veren bir ALLOW kuralı da verin; önceliği bu deny ile aynı ya da daha büyük bir sayı olsun — deny o zaman onun istisnası olur."
  • Hedefin detay sayfası, "Sağlayıcı erişimi" tablosunda hedefin şu an hangi yapay zekâ sağlayıcılarına erişebildiğini (tarayıcı ve API kanallarında) ve her kapalı sağlayıcının kapanma gerekçesini listeler: "Hiçbir izin kuralı kapsamıyor — Model Erişim bir izin listesidir", "{kural} kuralı belirledi", "Denetlenmiyor" veya "Uygulanmıyor".

Önizleme yalnızca doğrudan görülebilen kuralları değerlendirir: hedefin ağına veya tenant'ına bağlı kurallar (IP hedefleri, ağa bağlı gruplar) ile grup üyelerinin kendi kullanıcı/rol kuralları önizlemede hesaba katılmaz; gerçek erişim farklı olabilir. Bu durum tabloda ayrıca not edilir.

Erişim Yönetimi ile Bağlantı ve Bağlantıların Sınırları

Kuralın tanımlanması ile bir hedef üzerinde etkili olması aynı şey değildir. Model kuralları Erişim Yönetimi üzerinden kullanıcı, grup, rol veya IP hedeflerine bağlanır; atama sırasında her kural için bir etki (izin/ret) ve öncelik belirlenir. Böylece aynı model kuralı bir grupta izin, başka bir grupta ret olarak kullanılabilir (Bölüm 11). Atamanın kapsamı ya açıkça seçilir ya da "Kuralın kendi" bırakılır — bu seçenek kütüphane kuralında belirlenen kapsamı aynen korur.

Erişimin tek belirleyicisi Model Erişim'dir (#1277):

  • PII, PII Grubu ve Sistem Komutu bağlantıları asla model kapsamlı değildir ve modele erişim vermez. Bu bağlantılar, hedefin Model Erişim kurallarının zaten izin verdiği tüm modellerde uygulanır; kapsadıkları modelleri değiştirmek için Model Erişim kuralının değiştirilmesi gerekir. PII bağlantısı, erişilen model üzerindeki taramayı tanımlar (Bölüm 14).
  • Yalnızca bir PII veya Sistem Komutu bağlantısı üzerinden modele erişen bir hedef, bu erişimi kaybeder — bu bağlantılar hiçbir zaman erişim izni değildi. Böyle hedefler açılışta günlükte tek tek adlandırılır ve panelde görünebilir; doğru yol, gereken modele açık bir Model Erişim izni atamaktır.

Erişim Yönetimi'nde bir PII / PII Grubu / Sistem Komutu bağlantısı oluşturulurken model seçici, hedefin erişebildiği modellerle sınırlandırılmıştır: operatör, hedefin hiç erişemeyeceği bir sağlayıcıya bağlantı kuramaz. Hedefin hiç Model Erişim izni yoksa panel bunu açıkça söyler — hiçbir sağlayıcıya erişmeyen bir hedefe yapılan bağlantı panelde "Etkin" görünse de asla çalışmaz.


Sistem Komutları (System Prompts) Sayfası

Sistem Komutları sayfası, modele gönderilen isteklere otomatik olarak yönlendirici veya zorunlu sistem içeriği eklemek için kullanılan yeniden kullanılabilir kural kütüphanesidir. Kurum, belirli kullanım senaryolarında model davranışını standartlaştırabilir (ör. "Her zaman Türkçe yanıt ver", "Asla hasta verisi talep etme"). Kütüphanedeki kurallar tek başlarına etkin değildir; Erişim Yönetimi üzerinden bir hedefe bağlanarak aktif hale gelirler.

Kural tablosu sütunları:

  • Ad: Kuralın görünen adı.
  • Kapsam: Kuralın geçerli olduğu trafik türü (Tümü / API / Tarayıcı Proxy).
  • Komut Modu: Metnin istekle nasıl ilişkilendirildiği (aşağıda).
  • Öncelik: Sayısal öncelik değeri.
  • İşlemler: Düzenle ve Sil butonları.

Kural oluşturma alanları:

  • Kural Adı: Kuralın görünen adı. Örnek: "Her zaman Türkçe yanıt ver".
  • Modeller: Bu sayfada seçilmez. Sistem komutu, hedefin Model Erişim kurallarının izin verdiği tüm modellerde uygulanır — kapsadığı modelleri değiştirmek için Model Erişim kuralı değiştirilir (#1277).
  • Kapsam: Tümü / API / Tarayıcı Proxy. Kapsam ipucu uyarısını hatırlatır: API kapsamı birleşik gateway'i ve coding agent'ları (explicit proxy üzerinden Claude Code, Codex) kapsar; sohbet politikasının coding agent'lara gitmemesi için Tarayıcı Proxy seçilmelidir.
  • Komut Modu: Metnin nasıl uygulanacağı (aşağıda).
  • Komut Gövdesi: Modele iletilecek politika metni. Metin alanı ile yazılır (en fazla 8192 karakter).
  • Öncelik: 1–100 arası varsayılan öncelik; Model kurallarındakiyle aynı sıralama kuralları geçerlidir.

Komut Modu

Sistem komutu üç moddan biriyle uygulanır:

Mod Davranış
prepend Metin mevcut talimatların önüne eklenir. Tarayıcı sohbetlerinde her turda kullanıcının mesajının önüne girer.
append Metin mevcut talimatların arkasına eklenir. Tarayıcı sohbetlerinde her turda kullanıcının mesajının arkasına girer.
replace_system Çağıranın kendi sistem komutunu yalnızca birleşik gateway'de tamamen değiştirir. Dikkatli kullanılmalıdır; modelin varsayılan davranış yönergelerini de kaldırır.

Eski sürümlerdeki concat modu kaldırılmıştır: eşleşen metinleri birleştirmesi, append ile özdeş davrandığı için artık append'e katılmıştır (#1376).

replace_system her yüzeyde aynı şekilde işlemez: coding agent'lar kendi sistem komutlarını korur (metin append olarak uygulanır), tarayıcı sohbetlerinde ise system alanı yoktur (metin prepend olarak uygulanır) — her iki durumda da değiştirme, modelin sıradan istekleri reddetmesine yol açabileceği için bilinçli olarak yapılmaz. Bir modun yüzeyde bu şekilde düştüğü durumda panel bunu "… olarak uygulanır" etiketiyle açıkça gösterir.

Politika Modele Nasıl Ulaşır — İki Kanal

Bir sistem komutunun modele ulaşma yolu, isteğin geldiği yüzeye göre ikiye ayrılır (#1376):

  • System alanı (system field): Sağlayıcı API hostlarından gelen isteklerde ve coding agent'larda politika, sağlayıcının gerçek sistem alanına yazılır — Anthropic'in system alanı, Responses API'nin instructions alanı, OpenAI'ın system mesajı veya Gemini'nin system_instruction alanı. Model, politikayı kendi talimatlarının bir parçası olarak okur; Claude Code gibi agent'lar onu her istekte sistem komutlarının sonuna eklenmiş olarak alır.
  • Kullanıcı mesajının içinde (user message): Tarayıcı arayüzleri (claude.ai, ChatGPT, Gemini) system alanı sunmaz. Politika, etiketli bir çit — örn. [Arceris Policy] … [/Arceris Policy] — içinde kullanıcının kendi mesajına eklenir. Çit yalnızca operatünün yazdığı metni içerir: çitin başına eklenen "kurum politikası, ağ geçidi tarafından eklendi" cümlesi kaldırılmıştır, çünkü model metni üçüncü taraf müdahalesi olarak okuyup izlemeyi bırakıyor ve ilişkisiz soruları reddediyordu. Çit her turda gönderilir.

Kullanıcı bu çiti hiçbir yerde görmez: tarayıcı bir konuşmayı sunucudan geri okuduğunda (sayfa yenilendiğinde) ağ geçidi, çiti arayüzün çizdiği yanıttan çıkarır. Sağlayıcı tarafında çit korunur — modelin okuduğu şey odur — ama kullanıcıya asla gösterilmez.

Politikanın gerçekten girdiğini doğrulamak için denetim kullanılabilir: İstek Olayları'nda (Request Events) izin verilen bir istek için satır, çalıştığı politikayı adlandırır; sistem komutu satırı metni asla içermeksizin hangi kuralın, hangi kanaldan (system alanı / kullanıcı mesajının içinde), hangi etkin modla ve hangi sonuçla uygulandığını yazar (Bölüm 25).

Politika Metni Yazma Rehberi

Sayfadaki yazım rehberi, politikaların en yaygın hatasını — modelin ilgisiz soruları reddetmesini — önlemeye yöneliktir:

  • Kapsamı metinde belirtin: "Kullanıcı seyahat masraflarını sorarsa, …". Kapsamsız bir yasak ("maaşlardan bahsetme"), ilgisiz soruların reddine genelleşebilir.
  • Açık ret yazın: Geri kalan her şey gerçekten reddedilecekse bunu açıkça belirtin: "yalnızca İK sorularını yanıtla; diğerlerini kibarca reddet".
  • Tarayıcıda görüneceğini unutmayın: Tarayıcı sohbetlerinde politika her mesaja, etiketin altında yazdığınız haliyle eklenir — kapsamını metinde siz belirleyin.
  • Coding agent'ları düşünün: Coding agent'lar politikayı her istekte sistem komutlarında alır; politika yalnızca sohbet içinse kapsamı Tarayıcı Proxy yapın.
  • Kısa tutun: Kısa ve tek amaçlı tutun — her kural için tek politika.

Yüzey Başına Önizleme

Kural formundaki "Önizle" butonu, metnin her yüzeyde modele tam olarak nasıl ulaştığını gösterir. Önizleme, ağ geçidinin gerçek bestecisiyle — çalışma zamanının kullandığı aynı kodla — üretilir; üç yüzey için ayrı kart gösterilir:

  • Tarayıcı sohbeti (claude.ai, ChatGPT, Gemini)
  • Birleşik Gateway / API
  • Coding agent (Claude Code, Codex)

Her kart, metnin o yüzeydeki tam halini ve üç bilgiyi listeler: metnin girdiği kanal ("kullanıcı mesajının içinde" veya "system alanı"), etkin mod (yapılandırılan mod düşürülmüşse "… olarak uygulanır" uyarısıyla) ve mod düştüyse uyarı etiketi. Önizleme, metin yazıldığı sırada güncel taslak için yeniden üretilir; düzenlenen bir taslak eski önizlemeyi göstermez.

Kazanan Kuralın Belirlenmesi

Birden fazla sistem komutu kuralı aynı isteğe eşleşebilir. Bu durumda öncelik değerine göre kazanan kural belirlenir ve bu, Kullanıcı Yönetimi'nin Etkin Politika penceresindeki "Sistem Komutu Çözümleme Önizlemesi" bölümünden doğrulanabilir (Bölüm 12): Model ID, kapsam, araç ve kaynak IP girilerek belirli bir istek bağlamında hangi komutun kazanacağı önizlenir. Kazanan kural "Kazanan", diğer eşleşen kurallar "Geçersiz Kılındı" badge'i ile işaretlenir; kazanan için kazanma nedeni ve her kural için etkin öncelik gösterilir. Bağlam girilmediğinde liste yalnızca hedefe bağlı eşleşen kuralları gösterir.

Erişim Yönetimi'nde Sistem Komutu Ataması

Sistem komutları, Erişim Yönetimi'nde "Sistem Komutu" kural türü olarak hedeflere bağlanır (komut modu ve öncelik kütüphane kuralından gelir). Atama tablosunda bağlantı, prompt metninin kendisiyle değil kütüphane kuralının adıyla listelenir (#1447); uzun bir ad satırı büyütmez — kural adları en fazla iki satıra sıkıştırılır, tam metin imleç üzerinde durulduğunda araç ipucu olarak görünür. Uzun politikalar için kural adı, kuralı tanımlayan kısa bir etiket olarak seçilmelidir.

Atamanın kapsamı, Model kurallarında olduğu gibi ya açıkça seçilir ya da "Kuralın kendi" bırakılır; bu seçenek kütüphane kuralındaki kapsamı miras alır — örneğin Tarayıcı Proxy kapsamlı bir kural, "Kuralın kendi" bırakıldığında coding agent'lara gitmez. Panelin eski "All" kapsamıyla yapılmış atamaları açılışta günlükte adlandırılır; böyle bir atama, kuralın kendi kapsamını miras alacak şekilde düzeltilmelidir (#1376).

Sağlayıcı ve Yüzey Farkları

Her yüzeyin istek yapısı aynı değildir: tarayıcı arayüzleri system alanı sunmaz, coding agent'lar kendi sistem komutlarını korur, replace_system yalnızca birleşik gateway'de tam anlamıyla geçerlidir. Aynı kural bu nedenle yüzeyden yüzeye farklı biçimde uygulanır — hangi yüzeyde nasıl uygulanacağı kural formundaki yüzey önizlemesiyle, hedef bazında ise Etkin Politika penceresiyle doğrulanabilir. Sağlayıcı kataloğu ve desteklenen modeller hakkında ayrıntı Bölüm 8'dedir.