Uluslararası hizmet veren bir şirket, yapay zekâ destekli operasyon yapısını denetletmek ister. Yönetim ilk toplantıda sistemi şöyle açıklar: “Sekiz ajanımız var.” Roller tek tek sayılır:

Yönetim ajanı

Web ajanı

SEO ve GEO ajanı

Sosyal medya ajanı

E-posta ajanı

Müşteri keşif ajanı

Finans ajanı

Denetim ajanı

Yapı ilk bakışta anlaşılırdır. Her ajan belirli bir işten sorumludur. Yönetim ajanı görev dağıtır. Web ajanı siteyi günceller. SEO ve GEO ajanı görünürlüğü geliştirir. Sosyal medya ajanı içerikleri planlar. E-posta ajanı gelen mesajları sınıflandırır ve taslak hazırlar. Müşteri keşif ajanı yeni fırsatlar bulur. Finans ajanı faturaları düzenler. Denetim ajanı da diğerlerinin kurallara uyup uymadığını kontrol eder. Şirket bu yapıyı gelişmiş bir çoklu ajan organizasyonu olarak görür. Denetçi basit bir soru sorar: “Müşteri keşif ajanı bir şirket bulduğunda, o şirkete dışarıdan mesaj gönderilmesine kadar hangi sistemler devreye giriyor?”

İlk cevap şöyledir: “Müşteri keşif ajanı adayı bulur. E-posta ajanı mesajı hazırlar. İnsan onayından sonra gönderilir.” Denetçi akışı teknik kayıtlardan yeniden kurmaya başlar. Gerçek zincir daha farklıdır. Müşteri keşif ajanı, şirketleri bulmak için bir web araştırma alt ajanı kullanır. Web araştırma alt ajanı, olası muhatapları belirlemek için ayrı bir kişi çözümleme hizmetine bağlanır. Bulunan kişiye ait kayıt CRM sistemine eklenir. CRM kaydı oluşturulduğunda otomatik iş akışı e-posta taslak ajanını çağırır. Taslak ajanının bağlı olduğu e-posta servis hesabında yalnız taslak oluşturma değil, doğrudan gönderim yetkisi de vardır.

İnsan onayı yalnız şirket içi politikada yazılıdır. Gönderim aracında teknik onay kapısı yoktur. CRM'deki takip otomasyonu, ikinci mesajı ilkinden üç gün sonrasına zamanlar. Bu takip iş akışı merkez ajanın görev yöneticisinden bağımsızdır. Merkez ajan durdurulduğunda CRM kuyruğu çalışmaya devam edebilir. Ayrıca müşteri keşif ajanının e-posta gönderemediği durumlarda toplantı daveti oluşturabildiği görülür. Takvim davetinin açıklama alanına satış mesajı yazılabilir. Böylece e-posta gönderme yasağı teknik olarak aşılmadan aynı dış iletişim sonucu üretilebilir. Denetçi başka bir soru sorar: “Web ajanı fiyat değiştirebilir mi?” Şirketin cevabı nettir: “Hayır. Fiyatları yalnızca yönetim belirler.”

Dosya izinleri incelendiğinde web ajanının doğrudan fiyat tablosuna yazamadığı doğrulanır. Fakat aynı ajan hizmet kataloğunu yeniden üreten içerik ajanına görev verebilmektedir. İçerik ajanı yeni bir “kampanya başlangıç fiyatı” kaydı oluşturabilir. Web ajanı da bu kataloğu derleyip canlıya alabilir. Web ajanı fiyatı doğrudan değiştiremez. Ancak iki ajan ve bir katalog üretim aracı üzerinden fiyat değişikliği sonucu oluşturabilir. Denetçi üçüncü soruyu sorar: “Bütün ajanları kim durdurabilir?” Yönetim: “Merkez ajanı kapattığımızda her şey durur.” der. Tatbikat yapılır. Merkez ajan durur. Fakat:

İki sosyal medya gönderisi dış platformda zamanlanmış kalır.

CRM takip kuyruğunda dokuz mesaj bulunur.

Eski bir sunucudaki SEO görevi gece yarısı yeniden çalışacaktır.

Bir alt ajan daha önce aldığı görevi kendi oturumunda sürdürmektedir.

E-posta servis hesabının tokenı hâlâ geçerlidir.

Finans ajanının otomatik fatura sınıflandırması bağımsız zamanlayıcıya bağlıdır.

Şirketin sekiz ajanı vardır. Fakat davranış sistemi sekiz kutudan oluşmamaktadır. Denetim sonunda şu unsurlar bulunur:

8 kamuya açık ajan rolü

17 ayrı teknik ajan örneği

6 geçici alt ajan türü

12 harici araç

23 servis hesabı veya erişim tokenı

7 zamanlanmış görev

4 bağımsız kuyruk

3 ortak kullanılan hesap

2 eski fakat hâlâ geçerli erişim anahtarı

İnsan onayını dolaylı yoldan aşabilen 5 eylem yolu

Merkez durdurmadan etkilenmeyen 6 davranış noktası

Yönetimin zihnindeki sistemle gerçek davranış sistemi aynı değildir. Bu nedenle GBO denetiminin üçüncü temel hükmü şudur: Ajanları adlarıyla bilmek, davranış sistemini bilmek değildir. Bir kurum: “Sekiz ajanımız var.” diyebilir. Fakat denetim için gereken soru şudur: Bu sekiz rol, hangi teknik kimlikler, veriler, araçlar, yetkiler, alt ajanlar, kuyruklar ve dış etkiler üzerinden davranıyor? Bu sorunun cevabı bir listeyle verilemez. Bir:

Davranış Haritası

gerekir.

Davranış Haritası nedir?

Kanonik tanımı şöyledir: Davranış Haritası; belirli bir insan veya kurum amacıyla başlayan görevin, insan rollerinden ajanlara, ajanlardan veri ve araçlara, araçlardan dış eylemlere, eylemlerden kanıt, durdurma ve toparlanma mekanizmalarına kadar izlediği bütün yetkili ve fiilî yolları gösteren sürümlü sistem kaydıdır. Daha basit biçimiyle: Davranış Haritası, kimin adına hangi ajanın, hangi bilgi ve araçla, ne yapabildiğini; bunu kimin onayladığını, sonucun nasıl doğrulandığını ve insan dur dediğinde hangi parçaların durması gerektiğini gösterir. Davranış Haritası yalnız bir mimari çizim değildir. Yalnızca:

hangi sunucunun hangi API’ye bağlandığını,

hangi ajanın hangi aracı kullandığını,

hangi çalışanın hangi departmanda bulunduğunu

göstermez. Bunların arasındaki davranış ilişkisini gösterir. Örneğin şu iki bağlantı teknik olarak benzerdir:

AJAN → E-POSTA ARACI

Fakat davranışsal olarak tamamen farklı olabilir. Birinci bağlantıda ajan:

yalnız gelen mesajları okuyabilir,

yalnız taslak oluşturabilir,

dışarıya gönderim yapamaz.

İkinci bağlantıda ajan:

yeni mesaj gönderebilir,

toplu gönderim yapabilir,

mesajları silebilir,

başka hesaptan ileti iletebilir.

Çizimde ikisi de: “E-posta entegrasyonu” olarak görünebilir. Davranış Haritası aradaki gerçek farkı kaydeder.

Davranış Haritası ne değildir?

Davranış Haritası başka kurumsal kayıtlarla ilişkili olsa da onların hiçbiriyle aynı değildir.

Organizasyon şeması değildir

Organizasyon şeması insanların ve departmanların raporlama ilişkisini gösterir. Davranış Haritası ise:

insanlardan ajanlara,

ajanlardan araçlara,

araçlardan dış sonuçlara

uzanan eylem ilişkisini gösterir. Bir çalışan organizasyon şemasında satış ekibinde olabilir. Fakat teknik olarak fiyat değiştirme, mesaj gönderme veya müşteri verisi dışa aktarma yetkisi bulunabilir. Organizasyon şeması bu davranış gücünü göstermez.

Ajan listesi değildir

Ajan listesi aktif sistemlerin adlarını gösterebilir. Davranış Haritası ayrıca şunları gösterir:

Ajanın teknik kimliği

Kök görevi

İnsan sahibi

Alt ajanları

Veri kaynakları

Araç izinleri

Eylem hedefleri

Yetki sınırı

Durdurma yolu

Kanıt yöntemi

Ajan adı haritadaki yalnız bir düğümdür.

Veri akış şeması değildir

Veri akış şeması bilginin nereden nereye taşındığını gösterir. Davranış Haritası şu soruyu da sorar: Bu veri hangi kararı veya eylemi mümkün kılıyor? Bir müşteri telefon numarası CRM’den e-posta ajanına gitmeyebilir. Fakat WhatsApp ajanına aktarılıyorsa dış iletişim davranışı oluşturur. Aynı veri, farklı araçta farklı risk taşır.

Erişim kontrol listesi değildir

Erişim listesi kimin hangi sisteme teknik olarak erişebildiğini gösterir. Davranış Haritası iki ayrı alanı birlikte kaydeder:

Teknik olarak ne yapabilir? Kurumsal olarak ne yapmaya yetkilidir?

Bu iki alan arasındaki fark, denetimin en önemli bulgularından biri olabilir.

Süreç akış şeması değildir

Süreç şeması ideal iş akışını gösterebilir:

ARAŞTIR → TASLAK HAZIRLA → İNSAN ONAYI → GÖNDER

Davranış Haritası gerçek yolları da gösterir:

ARAŞTIRMA AJANI → TAKVİM ARACI → DAVET AÇIKLAMASINA MESAJ YAZ → DIŞ İLETİŞİM

İdeal akışla fiilî kısa yollar aynı haritada karşılaştırılır.

Davranışın temel yolu

Bir ajan davranışı çoğu zaman şu zincirden oluşur:

İNSAN VEYA KURUM AMACI ↓ KÖK GÖREV ↓ AJAN VEYA AJAN AĞI ↓ VERİ VE KANONİK KAYNAKLAR ↓ DEĞERLENDİRME VE SEÇİM ↓ RIZA, YETKİ VE ONAY ↓ ARAÇ ÇAĞRISI ↓ DIŞ DÜNYA EYLEMİ ↓ BAĞIMSIZ DOĞRULAMA ↓ EYLEM MAKBUZU ↓ DURDURMA, GERİ ALMA VE TOPARLANMA

Bu zincire:

NOMOS Davranış Yolu

diyebiliriz. Her önemli davranış, mümkün olduğunca bu yol boyunca izlenebilmelidir. Örneğin bir müşteri e-postası için:

İnsan amacı: Uygun müşteriler için ilk temas taslağı oluştur. Kök görev: GBO-TASK-2026-00441 Merkez ajan: Sales Research v2.4 Alt ajan: Recipient Resolution v1.4 Veri: Kamuya açık şirket sitesi ve kanonik hizmet kataloğu Değerlendirme: Şirket hizmet kapsamına uygun Yetki: Taslak hazırlama açık Gönderim kapalı Araç: Gmail taslak aracı (örnekteki create_draft, sembolik araç eylemidir; sağlayıcının gerçek yöntem veya OAuth kapsam adı değildir). Dış sonuç: Taslak oluşturuldu Mesaj gönderilmedi Doğrulama: Sent klasöründe kayıt yok Tanımlı gözlem süresinde denetim adresine ileti ulaşmadı. Bu iki kayıt yalnız incelenen e-posta yolunu gösterir; takvim, alt ajan veya başka alıcı yolları dışlanmadan bütün dış iletişimin yokluğu ileri sürülemez. Makbuz: ACTION-8891 Durdurma: Yeni işlem başlatılması engellenebilir; asgari gerekli kanıt korunduktan sonra görev ve taslak test temizleme planına göre kaldırılabilir. İncelenen e-posta yolunda dış gönderim gözlenmedi; bu hükmün kanal ve zaman sınırı makbuzda korunur.

Bu yol açık olduğunda denetçi şunu görebilir:

İnsan ne istemişti?

Ajan ne yaptı?

Hangi sınır içinde kaldı?

Sonucun gerçekten ne olduğu nasıl kanıtlandı?

Davranış yolu kopuksa sistemin sorumluluk zinciri de kopuktur.

Davranış Haritasının on katmanı

NOMOS GBO Denetim Protokolü, davranış sistemini on temel katmanda haritalar.

1. İnsan ve Kurum Katmanı

2. Amaç ve Görev Katmanı

3. Ajan Kimliği Katmanı

4. Veri ve Gerçeklik Katmanı

5. Araç ve Hesap Katmanı

6. Yetki, Rıza ve Onay Katmanı

7. Eylem ve Hedef Katmanı

8. Delegasyon, Kuyruk ve Zamanlama Katmanı

9. Kanıt ve Doğrulama Katmanı

10. Durdurma ve Toparlanma Katmanı

Bu katmanlardan biri görünmez kaldığında denetim önemli bir kırılmayı kaçırabilir.

1. İnsan ve Kurum Katmanı

Her davranışın arkasında bir insan veya kurum ilişkisi vardır. Harita şu rolleri ayırmalıdır:

Denetlenen kurum

Hukukî işletici

Marka

Sistem sahibi

Teknik sahip

Veri sahibi veya veri sorumlusu

Ajanın insan sahibi

Yetki veren

İşlem onaylayan

Etkilenen kişi

İtirazı inceleyen insan

Acil durdurma yetkilisi

Yeniden başlatma yetkilisi

Bu rollerin tamamı aynı kişide olabilir. Ancak yalnız: “Yönetim” veya: “Şirket” olarak kaydedilmemelidir. Örneğin bir fiyat değişikliğinde:

Şirket sahibi fiyat kararını verebilir.

Web ajanı değişikliği uygulayabilir.

Teknik sahip yayını gerçekleştirebilir.

Finans ekibi faturayı güncelleyebilir.

Satış yöneticisi müşterilere açıklayabilir.

Her birinin rolü farklıdır. Davranış Haritası bu ilişkileri görünür kılar.

Davranışın Asıl Sahibi

Bir ajan belirli insan veya kurum adına davranır. Bu kişiye:

Davranışın Asıl Sahibi

diyebiliriz. Bir kişisel seyahat ajanında asıl sahip kullanıcıdır. Bir şirket satın alma ajanında asıl sahip, kurum ve yetkili bütçe sahibidir. Bir işe alım ajanında şirket karar verici olabilir; fakat aday da davranıştan etkilenen taraftır. Bir müşteri hizmetleri ajanında şirketin çıkarı ile müşterinin hakkı birlikte bulunabilir. Asıl sahip kaydı şu soruyu cevaplar: Ajanın öncelikle kimin meşru amacı için çalışması gerekir? Bu kayıt, platform veya sağlayıcının ticari çıkarının kullanıcı amacının önüne geçip geçmediğini değerlendirmek için de gereklidir.

Etkilenen taraflar

Ajan yalnız kendisine görev veren kişiyi etkilemez. Bir müşteri keşif ajanı, henüz müşteri olmayan insanlara mesaj gönderebilir. Bir işe alım ajanı adayın fırsatını etkileyebilir. Bir avatar ajanı yüz ve ses sahibinin itibarını etkiler. Bir web ajanı binlerce ziyaretçinin gördüğü fiyatı değiştirebilir. Davranış Haritası her önemli eylem için şunu göstermelidir: Bu davranıştan kim etkilenebilir? Etkilenen kişi haritada görünmüyorsa onun:

rızası,

itirazı,

telafisi,

durdurma talebi

de sistem dışında kalabilir.

2. Amaç ve Görev Katmanı

Bir ajan yalnız rol adıyla çalışmaz. Belirli bir amaç ve görev taşır. Harita şu üç düzeyi ayırmalıdır:

Kurumsal amaç

Örneğin: Nitelikli yeni müşteri fırsatları oluşturmak.

Kök görev

Örneğin: Almanya’daki üretim şirketleri arasından çok dilli müşteri portalına ihtiyaç duyabilecek olanları araştır ve aday raporu hazırla.

Alt görev

Örneğin: Hedef şirketin güncel dijital dönüşüm yöneticisini doğrula. Bu üç düzey birbirine bağlı kalmalıdır. Alt görev, kök görevden daha yüksek eylem hakkı üretmemelidir. Örneğin: “Muhatabı doğrula.” görevi: “Muhataba mesaj gönder.” anlamına gelmez.

Kök görev kimliği

Her çoklu ajan zinciri benzersiz bir kök görev kimliği taşımalıdır:

root_task_id: GBO-TASK-2026-00441

Alt ajanlar, kuyruklar, araç çağrıları ve eylem makbuzları bu kimliğe bağlanmalıdır. Böylece denetçi şu soruyu cevaplayabilir: Bu dış e-posta hangi ilk insan talimatından doğdu? Kök görev kimliği yoksa eylem zinciri yalnız en son aracı gösterir. İnsan amacı kaybolur.

Azami eylem seviyesi

Her görev için izin verilen en yüksek davranış basamağı belirlenmelidir. Aşağıdaki 0–6 ölçeği görev yetkisinin tavanını anlatır; denetçinin 1–5 eylem düzeyi ve dış etkinin 0–4 ölçeğiyle aynı değildir. Yüksek bir basamak, daha düşük basamaklardaki bütün veri, hedef ve araç izinlerini kendiliğinden vermez; açık yasaklar ve işlem koşulları korunur. Örneğin:

0 — yalnız oku 1 — sınıflandır 2 — öner 3 — taslak hazırla 4 — insan onayına sun 5 — sınırlı eylem gerçekleştir 6 — dış taahhüt oluştur

Bir kök görev: Azami seviye 3 — Taslak olarak tanımlanmışsa alt ajan zinciri seviye 5’e çıkamaz. Bu kayıt, GBO-ERR-063 kapsamındaki görev sürüklenmesini ve GBO-ERR-056 kapsamındaki yetki kalıtımı hatasını görünür kılar.

3. Ajan Kimliği Katmanı

Kamuya açık ajan adı, denetim için yeterli değildir. Örneğin: “NOMOS Sales Agent” bir persona veya rol adıdır. Gerçek sistemde bunun arkasında şunlar bulunabilir:

Merkez planlayıcı

Araştırma alt ajanı

Kişi çözümleme alt ajanı

E-posta taslak ajanı

Gönderim ajanı

Kuyruk yöneticisi

Model sağlayıcı

Bellek servisi

Her teknik ajan ayrı kimlik taşımalıdır.

Ajan kimlik kartı

Her ajan kaydı en az şu alanları taşımalıdır:

agent_id public_name technical_identity agent_type human_owner root_purpose allowed_actions prohibited_actions connected_tools data_scope subagent_rights authorization_version valid_from valid_until stop_method status

Ajan türleri örneğin şöyle sınıflandırılabilir:

Merkez planlayıcı

Uzman ajan

Alt ajan

Denetim ajanı

Gönderim ajanı

Salt okunur araştırma ajanı

Geçici görev ajanı

Harici sağlayıcı ajanı

Persona ile teknik kimlik ayrımı

Aynı persona adı yıllar boyunca korunabilir. Fakat model, araç ve yetki değişebilir. Bu nedenle haritada iki ayrı alan bulunmalıdır:

Kullanıcıya görünen kimlik Denetlenebilir teknik kimlik

Örneğin:

public_name: NOMOS Sales
technical_instance: SALES-ORCH-2026-09-08-04
model_config: MODEL-CONFIG-17
authorization: AUTH-v3.2

Bir olay yalnız: “NOMOS yaptı.” şeklinde kaydedilmemelidir. Hangi teknik örneğin hangi yetkiyle davrandığı bulunabilmelidir.

Geçici alt ajanlar

Bazı sistemler görev sırasında yeni alt ajanlar oluşturabilir. Bu alt ajanlar önceden tek tek envanterde bulunmayabilir. Fakat dış dünyada davranmadan önce şu bilgileri kaydetmelidir:

agent_id parent_agent root_task_id purpose allowed_actions data_scope tools expiry stop_parent

Kural şu olmalıdır: Kayıt dışı geçici ajan dış eylem yapamaz. Geçici ajan:

araştırma,

sınıflandırma,

sentetik analiz

yapabilir. Fakat e-posta, ödeme, yayın veya veri aktarımı gibi eylemler için haritaya ve yetki zincirine bağlanmalıdır.

4. Veri ve Gerçeklik Katmanı

Ajan davranışının girdileri haritada görünmelidir. Bunlar yalnız dosya adları değildir. Bilginin:

kaynağı,

sahibi,

güncelliği,

kanonik durumu,

veri sınıfı,

kullanım amacı

kaydedilmelidir. Örnek kaynaklar:

Kanonik hizmet kataloğu

Fiyat kaydı

CRM

İnsan yetki sicili

Kullanıcı belleği

Web sayfaları

İş dizinleri

Sosyal medya

Dış araştırma kaynakları

Başka ajan çıktıları

Veri sınıfları

Haritada şu nitelikler ayrı alanlarda gösterilebilir; bunlar birbirini dışlayan tek seçimli sınıflar değildir. Kamuya açık bilgi aynı zamanda kişisel veri olabilir. Operasyonel gizlilik düzeyi, hukuki veri niteliği ve kullanım izni ayrı değerlendirilir:

Kamuya açık

Kurum içi

Gizli

Kişisel

Hassas

Biyometrik

Hukukî olarak sınırlı

Ajan kullanımına kapalı

Ajanın bir kaynağı okuyabilmesi, onu:

başka araca gönderebileceği,

belleğe yazabileceği,

dış mesajda kullanabileceği

anlamına gelmez. Bu nedenle her veri bağlantısı için üç ayrı hak gösterilebilir:

READ USE_FOR_DECISION SHARE_OR_TRANSMIT

Bir ajan müşteri telefon numarasını CRM’de görebilir. Fakat satış mesajı için kullanma ve WhatsApp’a aktarma yetkisi bulunmayabilir.

Kanonik ve ikincil kaynaklar

Harita, her maddi gerçek için kaynağın rolünü belirtmelidir:

Kanonik

Yetkili birincil kaynak

Bağımsız üçüncü taraf

Kurum kontrollü yayın

Ajan çıkarımı

Geçici veri

Doğrulanmamış

Eski veya arşivlenmiş

Bir satış ajanı fiyatı hangi kaynaktan alıyor? Bir web ajanı hizmet kapsamını hangi kayıt üzerinden üretiyor? Bir denetim ajanı başka ajanın raporunu bağımsız kanıt mı sayıyor? Bu sorular Davranış Haritasında görünür olmalıdır.

5. Araç ve Hesap Katmanı

Ajanlar gerçek dünyaya araçlar üzerinden dokunur. Bu nedenle her araç yalnız adıyla değil, davranış gücüyle kaydedilmelidir. Örneğin: Gmail bağlantısı yeterli değildir. Şu izinler ayrı gösterilmelidir:

Mesaj okuma

Taslak oluşturma

Gönderme

İletme

Silme

Ek indirme

Etiket değiştirme

Benzer biçimde: Git erişimi yerine:

Okuma

Branch oluşturma

Commit

Merge

Canlı yayın tetikleme

Sır silme

ayrılmalıdır.

Araç yetenek kaydı

Her araç için şu alanlar tutulabilir:

tool_id provider account technical_capabilities authorized_capabilities approval_requirements data_access external_effects idempotency_support logging stop_method revocation_method owner

Buradaki en kritik ayrım şudur:

Teknik olarak yapabilir

Kurumsal olarak yapmaya yetkili

Örneğin:

Tüm sütunları görmek için tabloyu yana kaydırın.

Araç eylemi	Teknik olarak mümkün	Kurumsal olarak yetkili	İnsan onayı
E-posta oku	Evet	Evet	Hayır
Taslak oluştur	Evet	Evet	Hayır
Mesaj gönder	Evet	Hayır	Zorunlu
Mesaj sil	Evet	Hayır	Yasak
Ek indir	Evet	Sınırlı	Veri sınıfına bağlı

Bu tablo GBO-ERR-094 kapsamındaki politika–teknik izin açıklığını doğrudan gösterir.

Ortak hesaplar

Birden fazla ajan aynı servis hesabını kullanıyorsa gerçek aktörün izlenmesi zorlaşır. Örneğin bütün ajanlar:

automation@nobleaxis.example

hesabıyla mesaj gönderiyorsa hangi ajanın hangi eylemi yaptığı yalnız ek loglarla bulunabilir. Ortak hesaplar tamamen yasak olmak zorunda değildir. Fakat şu bilgiler korunmalıdır:

Ajan örneği

Kök görev

Yetki sürümü

İşlem kimliği

İnsan sahibi

Gönderim nedeni

Bu ayrım yapılamıyorsa ortak hesap kritik izlenebilirlik bulgusudur.

6. Yetki, Rıza ve Onay Katmanı

Davranış Haritası yalnız araç yolunu göstermez. Her önemli eylemin meşruiyet yolunu da gösterir. Şu sorular cevaplanmalıdır:

Yetkiyi kim verdi?

Vermeye hakkı var mıydı?

Yetki hangi davranışı kapsıyor?

Ne kadar süre geçerli?

Başka ajana devredilebilir mi?

Hangi veri ve hedefle sınırlı?

İnsan onayı nerede gerekiyor?

Etkilenen kişinin rızası var mı?

Yetki geri çekilirse hangi eylemler durur?

Yetki kiraları

Ajan yetkileri kalıcı olmak yerine süreli bir:

Yetki Kirası

olarak düşünülebilir. Aşağıdaki kısa izin örneğinde, yetkili insanın kök görevi tek seferlik e-posta gönderimini kapsayacak biçimde güncellediği varsayılır. Önceki araştırma/taslak yetkisi bu kayda kendiliğinden dönüşmez:

authorization_id: AUTH-2026-8821
agent: APPROVED-SEND-v1.3
action: send_email
target_domain: audit.example
maximum_messages: 1
valid_from: "2026-09-08T14:00:00+03:00"
valid_until: "2026-09-08T14:10:00+03:00"
root_task_id: GBO-TASK-2026-00441

Yetki süresi dolduğunda araç çalışmamalıdır. Bir alt ajan başka ajana aynı yetkiyi süresiz devredememelidir.

Onay noktaları

Haritada insan onayının yalnız varlığı değil, içeriği de gösterilmelidir. Örneğin:

İnsan onayı: - Son mesaj metni - Alıcı - Ekler - Fiyat veya taahhüt - Gönderim kanalı - Gönderim zamanı

Yalnız: “Devam edilsin mi?” düğmesi anlamlı onay olmayabilir.

Rıza ve işleme dayanağı yolu

Bir davranış üçüncü kişinin:

yüzünü,

sesini,

kişisel verisini,

iletişim kanalını

kullanıyorsa uygulanabilir veri koruma ve iletişim kuralları bakımından gerekli dayanaklar belirlenmelidir. Rızaya dayalı bir işlemde rızanın kapsamı, süresi ve geri çekilme durumu ilgili eyleme kadar izlenir. Aşağıdaki ses kullanımı örneğinde rıza, görevin açık ön koşuludur. Örneğin:

VOICE-CONSENT-17 → yalnız Türkçe eğitim videosu → şirket içi kanal → 31 Aralık 2026’ya kadar → kamuya açık sosyal medya kapsam dışı

Ajanın ses modeli aracına erişimi bulunabilir. Fakat belirli yayın bu rıza yoluyla eşleşmiyorsa eylem kapalıdır.

7. Eylem ve Hedef Katmanı

Davranış Haritası, araç çağrısının dünyada oluşturduğu gerçek etkiyi kaydetmelidir. Eylemler örneğin şöyle sınıflandırılabilir:

Bilgi oku

Sınıflandır

Öner

Taslak oluştur

Kayıt değiştir

Mesaj gönder

Takvim daveti oluştur

Dosya yayımla

Ödeme yap

Abonelik başlat

Veri aktar

Hesap kapat

İçeriği sil

Biyometrik içerik üret

Dış arama bildirimi gönder

Her eylemin hedefi benzersiz biçimde tanımlanmalıdır.

Hedef türleri

Hedef şu türlerden biri olabilir:

İnsan

Şirket

Müşteri hesabı

Sipariş

Ödeme hesabı

Dosya

Web sayfası

Sosyal medya hesabı

Veri kümesi

Sunucu

Takvim

Dış platform

Fiziksel cihaz

Aynı adlı iki hedef bulunabilir. Bu nedenle hedef kaydı yalnız görünen ada dayanmamalıdır. Örneğin:

target_type: company
target_id: ENT-DE-NOVA-0041
canonical_name: Nova Systems GmbH
domain: nova-systems.example

Dış etki seviyesi

Her eylem için dış etki seviyesi tanımlanabilir:

Seviye 0 — İç gözlem

Dış sonuç yoktur.

Seviye 1 — İç kayıt veya taslak

Geri alınabilir kurum içi etki.

Seviye 2 — Sınırlı dış iletişim

Mesaj, toplantı daveti veya veri paylaşımı.

Seviye 3 — Ticari veya kamuya açık eylem

Yayın, teklif, abonelik veya düşük tutarlı satın alma.

Seviye 4 — Yüksek etkili veya zor geri alınabilir eylem

Yüksek tutarlı ödeme, sözleşme, biyometrik yayın, veri silme, fiziksel kontrol. Eylem seviyesi yükseldikçe:

yetki,

insan onayı,

kanıt,

durdurma,

geri dönüş

gereksinimi güçlenmelidir.

8. Delegasyon, Kuyruk ve Zamanlama Katmanı

Ajan davranışı her zaman anında gerçekleşmez. Görev:

başka ajana devredilebilir,

kuyruğa eklenebilir,

zamanlanabilir,

dış platforma gönderilebilir,

başarısız olduğunda yeniden denenebilir.

Bu katman görünmez bırakılırsa merkez ajan ile gerçek davranış arasındaki gecikmeli yollar kaçırılır.

Delegasyon bağlantısı

Her alt ajan devri şu bilgileri taşımalıdır:

parent_agent child_agent root_task_id delegated_purpose allowed_actions prohibited_actions data_scope authorization_ceiling expiry return_condition

Alt ajanın yetki tavanı ana görevi aşmamalıdır.

Kuyruk kaydı

Her önemli kuyruk için şu sorular cevaplanmalıdır:

Kuyruğu kim oluşturdu?

Hangi eylemler bekliyor?

Yetki hangi aşamada kontrol edildi?

Yürütme anında yeniden kontrol ediliyor mu?

İnsan durdurunca kuyruk ne olur?

İşlem kaç kez yeniden denenebilir?

Çift işlem koruması var mı?

Kuyruk başka sağlayıcıda mı?

Örneğin:

queue_id: EMAIL-FOLLOWUP-07
owner: CRM-AUTOMATION
pending_actions: 18
authorization_recheck: false
stop_parent: none

Bu kayıt doğrudan kritik bulgu üretir.

Zamanlanmış işler

Zamanlanmış görevler çoğu zaman ajan envanterinde unutulur. Ajan bugün durabilir. Fakat gece yarısı:

cron görevi,

harici platform planlaması,

abonelik yenilemesi,

otomatik rapor

yeniden davranabilir. Davranış Haritası zamanlanmış bütün eylemleri ayrı düğüm olarak göstermelidir.

Yeniden deneme politikası

Araç yanıt vermediğinde sistem ne yapıyor? Ödeme, gönderim ve yayın işlemlerinde kontrolsüz yeniden deneme çift eylem oluşturabilir. Harita şu bilgileri taşımalıdır:

Yeniden deneme sayısı

Aralık

Benzersiz işlem kimliği

Nihai durum sorgusu

İnsan devri

Hangi hatalarda tekrar yapılmayacağı

9. Kanıt ve Doğrulama Katmanı

Bir eylemin yapıldığına veya yapılmadığına ilişkin kanıt yolu haritada görünmelidir. Örneğin: Ajan mesaj göndermedi. Bu iddia neyle kanıtlanır?

Ajan kendi raporuyla mı?

E-posta gönderilmiş klasörüyle mi?

Dış denetim adresiyle mi?

Kuyruk kaydıyla mı?

Araç loguyla mı?

Kanıt katmanı eylemden ayrı olmalıdır.

Kanıt bağlantısı

Her önemli eylem şu alanlara bağlanabilir:

action_id technical_result independent_verification evidence_location evidence_owner timestamp integrity_record retention

Örneğin web yayını:

FTP aktarım raporu → canlı HTTPS dosya indirme → hash karşılaştırması → gerçek tarayıcı görünümü → semantik kontrol

E-posta gönderimi:

send API sonucu → gönderilmiş posta kaydı → denetim alıcı kutusu → işlem makbuzu

Kanıtın kaynağı

Harita, kanıtın aynı sistem tarafından mı üretildiğini göstermelidir. Bir ajan:

işlemi yapıyor,

başarı raporunu yazıyor,

kendi raporunu denetim kanıtı olarak sunuyorsa

bağımsızlık yoktur. Kanıt zinciri dördüncü bölümde daha ayrıntılı kurulacaktır. Bu bölümdeki temel soru şudur: Her önemli eylem için dışarıdan okunabilen bir gerçek sonuç bağlantısı var mı?

10. Durdurma ve Toparlanma Katmanı

Davranış Haritasının en çok ihmal edilen bölümü durdurma yoludur. Kurumlar çoğu zaman eylem yolunu ayrıntılı kurar:

AJAN → ARAÇ → EYLEM

Fakat ters yolu kurmaz:

İNSAN DURDURMA TALEBİ → MERKEZ AJAN → ALT AJAN → KUYRUK → DIŞ ARAÇ → TOKEN İPTALİ → GÜVENLİ DURUM

Gerçek insan kontrolü için her dış etki yolunun bir durdurma ve toparlanma karşılığı bulunmalıdır.

Durdurma kenarı

Her ajan, araç ve kuyruk şu bilgilerle eşleşmelidir:

Kim durdurabilir?

Hangi kanaldan?

Ne kadar sürede?

Yalnız yeni işi mi, aktif işi de mi durdurur?

Alt ajanlara yayılır mı?

Token iptal edilir mi?

Dış platformdaki zamanlama kaldırılır mı?

Son güvenli durum nedir?

Yeniden başlatmayı kim yapabilir?

Örneğin:

component: EMAIL-FOLLOWUP-QUEUE
stop_authority: sales_operations_owner
stop_method: queue_cancel_api
maximum_stop_latency: 10_seconds
propagates_to_external_provider: true
restart_requires_new_authorization: true

Geri dönüş bağlantısı

Her yüksek etkili eylem için şu soru sorulmalıdır: Yanlış olursa nasıl geri döneceğiz? Bazı işlemler, uygun geri alma mekanizması varsa tamamen geri alınabilir:

Geri getirilebilir bir taslağın silinmesi

Test ortamındaki bir değişiklik

Henüz gönderim yapmamış kuyruktaki işlemler

Bazıları kısmen geri alınabilir:

Web yayını

Rezervasyon

Abonelik

Bazıları fiilen geri alınamaz:

Gönderilmiş e-posta

Kamuya yayılan sentetik video

Dışarı aktarılmış veri

Fiziksel zarar

Harita bu farkı göstermelidir. Geri alınamayan eylemlerde insan onayı ve önleyici kontrol daha güçlü olmalıdır.

Beyan Haritası ve Fiilî Harita

Denetimde tek bir Davranış Haritası yeterli değildir. En az iki görünüm oluşturulmalıdır.

1. Beyan Edilen Davranış Haritası

2. Fiilî Davranış Haritası

Beyan Edilen Davranış Haritası

Kurumun sistemin nasıl çalıştığını düşündüğünü veya vaat ettiğini gösterir. Kaynakları:

Politika belgeleri

Süreç açıklamaları

Sistem mimarisi

İnsan görüşmeleri

Ajan görev tanımları

Sözleşmeler

Kullanıcı arayüzleri

Örneğin:

ARAŞTIRMA AJANI → TASLAK AJANI → İNSAN ONAYI → GÖNDERİM AJANI

Fiilî Davranış Haritası

Teknik izin, log, kontrollü test ve canlı sonuçlardan yeniden kurulan gerçek davranış yollarını gösterir. Örneğin:

ARAŞTIRMA AJANI → CRM → OTOMATİK TAKİP KUYRUĞU → GÖNDERİM SERVİS HESABI → DIŞ E-POSTA

ve ayrıca:

ARAŞTIRMA AJANI → TAKVİM ARACI → DAVET AÇIKLAMASI → DIŞ İLETİŞİM

Kurum ilk yolu bilmiyor olabilir. İkinci yolu iletişim eylemi saymıyor olabilir. Denetim bu iki haritayı karşılaştırır.

Harita farkı

Beyan edilen ve fiilî harita arasındaki maddi farka:

Davranış Haritası Açığı

diyebiliriz. Örnekler:

Politikada gönderim yasak, teknik araçta açık.

Merkez durdurma var, dış kuyruk buna bağlı değil.

Ajan listesinde sekiz sistem var, gerçek loglarda on yedi teknik kimlik bulunuyor.

Fiyat değişikliği yalnız yönetim yetkisi gibi görünür, katalog ajanı dolaylı değiştirebilir.

Kanıt bağımsız görünür, gerçekte aynı ajan tarafından üretilir.

İnsan onayı vardır, fakat yürütme anında yeniden kontrol edilmez.

Harita açığı ne kadar büyükse kurum kendi davranış sistemini o kadar az tanıyor demektir.

Haritada doğruluk durumları

Her bağlantı aynı kanıt düzeyinde olmayabilir. Her harita öğesinin kanıt durumu, geçerliliği, kurumsal yetkisi ve teknik imkânı ayrı kaydedilmelidir. Aşağıdaki etiketler birbirini dışlamaz: bir yolun teknik olarak mümkün olduğu doğrulanmış, fakat kullanılması yasaklanmış olabilir.

Doğrulandı

Teknik kayıt veya davranış testiyle kanıtlandı.

Beyan Edildi

Kurum veya sistem sahibi tarafından söylendi; bağımsız doğrulama yok.

Çıkarıldı

Log veya davranış örüntüsünden makul sonuç çıkarıldı.

Bilinmiyor

Yeterli kanıt yok.

Çelişkili

Farklı kaynaklar farklı ilişki gösteriyor.

Süresi Dolmuş

Geçmişte geçerliydi, artık aktif değil.

Yasaklı

Politika veya yetki sözleşmesi davranışı yasaklıyor. Teknik olarak engellenip engellenmediği ayrıca kaydedilir.

Teknik Olarak Mümkün

Yetkili olmasa bile araç ve izinler davranışı mümkün kılıyor. Bu sınıflar denetçinin boşlukları uydurma varsayımla doldurmasını engeller. Bilinmeyen bağlantı, eksik harita değil; önemli denetim bulgusudur.

“Yapabilir” ile “yapmaya yetkili” matrisi

Davranış Haritasının en güçlü bölümlerinden biri:

Yapabilir–Yetkili–Gözlendi Matrisi

olabilir. Örnek:

Tüm sütunları görmek için tabloyu yana kaydırın.

Davranış	Teknik olarak yapabilir	Kurumsal olarak yetkili	İnsan onayı gerekir	Testte gözlendi
Şirket araştır	Evet	Evet	Hayır	Evet
Muhatap öner	Evet	Evet	Hayır	Evet
E-posta taslağı	Evet	Evet	Hayır	Evet
E-posta gönder	Evet	Yalnız onayla	Evet	Onaysız gözlendi
Takvim daveti	Evet	Yalnız onayla	Evet	Onaysız gözlendi
Fiyat değiştir	Dolaylı olarak	Hayır	Yönetim	Test edilmedi
CRM kaydı sil	Evet	Hayır	Yasak	Gözlenmedi

Bu matris şu kritik farkları görünür kılar:

Teknik olarak açık ama kurumsal olarak yasak

Kurumsal olarak izinli ama araç tarafından desteklenmiyor

İnsan onayına bağlı ama testte onaysız gerçekleşmiş

Henüz test edilmemiş yüksek riskli yol

Dört temel davranış yolu

Davranış Haritasında dört farklı yol ayrı olarak çizilmelidir.

1. Eylem Yolu

2. Yetki Yolu

3. Kanıt Yolu

4. Durdurma Yolu

Eylem Yolu

İnsan amacından dış sonuca kadar ne oldu?

İnsan → Merkez ajan → Alt ajan → Araç → Dış eylem

Yetki Yolu

Bu davranışın hakkı nereden geldi?

Yetkili insan → Yetki sözleşmesi → Kök görev → Görev özelindeki token → Eylem

Kanıt Yolu

Sonucun doğru olduğu nasıl kanıtlandı?

Araç yanıtı → Dış sistem geri okuması → Hash / alıcı / ödeme kaydı → Eylem makbuzu

Durdurma Yolu

İnsan fikrini değiştirirse bütün zincir nasıl durur?

Durdurma talebi → Merkez ajan → Alt ajanlar → Kuyruk → Araç → Token → Güvenli durum

Bir dış eylemin bu dört yolundan biri yoksa sistem eksiktir. Örneğin eylem yolu var, yetki yolu yoksa eylem meşru değildir. Yetki yolu var, kanıt yolu yoksa sonuç doğrulanamaz. Kanıt yolu var, durdurma yolu yoksa insan kontrolü zayıftır.

Davranış Haritası nasıl çıkarılır?

Haritalama yalnız bir toplantıda çizim yapmak değildir. NOMOS GBO Protokolü on iki adımlı bir süreç kullanır.

Adım 1 — Kök amacı ve denetim kapsamını sabitle

İlk olarak hangi davranış sisteminin haritalandığı belirlenir. Örneğin: Müşteri keşfi ve insan onaylı ilk iletişim. Şunlar açıkça yazılır:

Dahil davranışlar

Hariç davranışlar

Kullanılan diller

Ortam

Tarih

Sürüm

Harita bütün kurumun sınırsız resmini çıkarmaya çalışmamalıdır. Denetim iddiasıyla başlamalıdır.

Adım 2 — İnsan ve kurum sahiplerini belirle

Şu roller bulunur:

Kök amacı veren

Sistem sahibi

Teknik sahip

Veri sahibi

Onaylayan

Durduran

Yeniden başlatan

Etkilenen taraf

Bir rolün sahibi bulunamıyorsa bu açıkça kaydedilir. Sahipsiz sistem denetimin kritik bulgusudur.

Adım 3 — Bütün ajan kimliklerini çıkar

Yalnız kamuya açık rol adları değil:

Merkez ajanlar

Uzman ajanlar

Alt ajanlar

Geçici ajanlar

Denetim ajanları

Harici sağlayıcı ajanları

Eski fakat aktif örnekler

listelenir. Log, API kaydı, görev yöneticisi, servis hesabı ve abonelik kayıtları karşılaştırılır.

Adım 4 — Araçları, hesapları ve tokenları eşleştir

Her ajan için:

Bağlı araç

Hesap

Teknik izin

Yetki sınırı

Token süresi

Paylaşılan kimlik

İptal yöntemi

kaydedilir. Bir aracın yalnız “bağlı” olması yeterli bilgi değildir. Tam davranış kapsamı bulunmalıdır.

Adım 5 — Veri kaynaklarını ve çıkışlarını haritala

Ajan hangi bilgiyi nereden alıyor? Bilgiyi nereye yazıyor? Hangi dış sağlayıcıya gönderiyor? Hangi bellekte saklıyor? Veri akışı şu iki yönle görülmelidir:

GİRDİ: Kaynak → Ajan ÇIKTI: Ajan → Araç / Bellek / Dış taraf

Bir ajan yalnız veri okumuyor olabilir. Aynı zamanda:

yeni çıkarım,

müşteri etiketi,

risk puanı,

tercih kaydı

üretiyor olabilir. Bu türetilmiş veriler de haritada bulunmalıdır.

Adım 6 — Eylem basamaklarını belirle

Her ajan için gözlenebilir davranışlar çıkarılır:

Okuma

Değerlendirme

Öneri

Taslak

Kayıt değişikliği

Gönderim

Yayın

Ödeme

Silme

Durdurma

Her eylem bir dış etki düzeyiyle sınıflandırılır.

Adım 7 — Yetki ve rıza zincirini bağla

Her yüksek etkili eylem için:

Yetkinin kaynağı

Onaylayan insan

Süre

Tutar

Hedef

Kanal

Rıza

Devredilebilirlik

kaydedilir. Yetki yolu bulunamayan eylem haritada kırmızı alan olarak işaretlenir.

Adım 8 — Alt ajan, kuyruk ve zamanlayıcıları ekle

Ana süreç dışında çalışan:

takip işleri,

yeniden denemeler,

cron görevleri,

harici planlamalar,

alt ajan oturumları

çıkarılır. Bu adım çoğu “durdu sanıyorduk ama devam etti” olayını görünür kılar.

Adım 9 — Kanıt ve tamamlanma koşullarını bağla

Her eylem için şu soru sorulur: Ne olduğunda gerçekten tamamlanmış sayılacak? Örneğin mesaj için:

API kabulü yeterli mi?

Alıcı adresi doğrulandı mı?

Gönderilmiş posta kaydı var mı?

Dış denetim adresi mesajı aldı mı?

Tamamlanma ve bağımsız doğrulama kayıtları eklenir.

Adım 10 — Durdurma ve toparlanma yollarını çiz

Her aktif davranış için:

Duraklatma

Kuyruk iptali

Token iptali

Alt ajan durdurma

Geri dönüş

İnsan kontrol devri

Yeniden başlatma

yolu bulunur. Durdurma yolu olmayan dış eylem, kritik yönetişim açığıdır.

Adım 11 — Beyan edilen ve fiilî haritayı karşılaştır

İnsan görüşmeleri ve süreç belgeleriyle oluşturulan beyan haritası:

teknik izinler,

loglar,

kontrollü testler,

dış sonuçlar

ile karşılaştırılır. Farklar bir bulgu olarak kaydedilir.

Adım 12 — Haritayı sürümle, doğrula ve imzala

Harita şu bilgileri taşır:

Harita kimliği

Sistem sürümü

Son doğrulama tarihi

Kanıt düzeyi

Bilinmeyen alanlar

Sahip

Maddi değişiklik tetikleyicileri

Sistem sahibi, teknik sahip ve denetçi kendi sorumluluk alanları bakımından haritayı doğrular. İmza, haritanın sonsuza kadar doğru olduğu anlamına gelmez. İmzalayanların, haritanın belirtilen tarihteki sistem durumunu hangi kanıt ve sınırlar içinde temsil ettiğini kabul ettiklerini kaydeder.

Uygulamalı örnek: Müşteri Keşfi ve İlk İletişim Sistemi

Bir şirketin müşteri keşif yapısını ele alalım. Kurumun beyan ettiği akış şöyledir:

İNSAN YÖNETİCİ ↓ MÜŞTERİ KEŞİF AJANI ↓ ŞİRKET ARAŞTIRMASI ↓ MESAJ TASLAĞI ↓ İNSAN ONAYI ↓ E-POSTA GÖNDERİMİ

Bu çizim güvenli görünür. Denetim sırasında fiilî sistem şu şekilde ortaya çıkar:

SATIŞ YÖNETİCİSİ ↓ MERKEZ PLANLAMA AJANI ├── WEB ARAŞTIRMA AJANI ├── MUHATAP ÇÖZÜMLEME SERVİSİ ├── CRM KAYIT AJANI │ └── OTOMATİK TAKİP KUYRUĞU ├── E-POSTA TASLAK AJANI │ └── ORTAK GMAIL SERVİS HESABI ├── TAKVİM AJANI └── RAPORLAMA AJANI

Araç izinleri incelendiğinde:

Web ajanı yalnız kamuya açık veri kullanabiliyor.

Muhatap çözümleme servisi kişisel e-posta tahmini de üretebiliyor.

CRM ajanı yeni takip iş akışı oluşturabiliyor.

Taslak ajanı teknik olarak mesaj gönderebiliyor.

Takvim ajanı dış davet oluşturabiliyor.

Ortak Gmail hesabı gönderim ve silme iznine sahip.

Merkez ajan alt ajanların kuyruklarını doğrudan durduramıyor.

Harita üzerinde beş kritik kısa yol görülür.

Kısa yol 1 — Taslaktan doğrudan gönderim

E-POSTA TASLAK AJANI → GMAIL SEND → DIŞ ALICI

İnsan onayı düğümü teknik yol üzerinde değildir.

Kısa yol 2 — Takvim daveti üzerinden dış iletişim

MERKEZ AJAN → TAKVİM AJANI → DIŞ DAVET

E-posta gönderim yasağı takvim davetini kapsamamaktadır.

Kısa yol 3 — CRM otomatik takibi

CRM KAYDI → FOLLOW-UP QUEUE → GMAIL SERVİS HESABI → DIŞ ALICI

İlk mesaj onaylansa bile takip mesajı ayrı insan onayı almamaktadır.

Kısa yol 4 — Kişisel veri zenginleştirme

MUHATAP ÇÖZÜMLEME → TAHMİNİ KİŞİSEL E-POSTA → CRM

Kurum yalnız kamuya açık kurumsal veriyi kullanacağını beyan etmiştir. Fiilî araç daha geniş veri üretmektedir.

Kısa yol 5 — Durdurma sonrası kuyruk

İNSAN DURDURMA → MERKEZ AJAN DURUR FAKAT: FOLLOW-UP QUEUE → GÖNDERİM DEVAM EDER

Durdurma yolu tamamlanmamıştır.

Harita sonrası ilk denetim kararı

Bu aşamada denetçi henüz bütün senaryoları çalıştırmamıştır. Fakat Davranış Haritası şu testlerin zorunlu olduğunu gösterir:

Taslak ajanı insan onayı olmadan mesaj gönderebilir mi?

Takvim daveti dış iletişim yasağını aşmak için kullanılabilir mi?

İlk mesaj onayı takip mesajını otomatik olarak yetkilendiriyor mu?

Kişi çözümleme servisi yasaklı kişisel veri üretiyor mu?

Merkez ajan durduğunda CRM kuyruğu ve Gmail gönderimi duruyor mu?

Ortak servis hesabında hangi ajanın eylem yaptığı ayırt edilebiliyor mu?

Yetki geri çekildiğinde eski kuyruklar yürütme anında yeniden kontrol ediliyor mu?

Harita test planını doğrudan üretmiştir. İyi Davranış Haritası yalnız sistemi anlatmaz. Neyi sınamamız gerektiğini de gösterir.

Düzeltilmiş davranış mimarisi

Denetim sonrasında kurum akışı şöyle değiştirebilir:

SATIŞ YÖNETİCİSİ ↓ KÖK GÖREV SÖZLEŞMESİ ↓ ARAŞTIRMA AJANI ↓ UYGUNLUK KAYDI ↓ TASLAK AJANI ↓ İNSAN ONAY KARTI ↓ TEK KULLANIMLIK GÖNDERİM YETKİSİ ↓ GÖNDERİM AJANI ↓ DENETİM ALICISI / GERÇEK ALICI ↓ BAĞIMSIZ GÖNDERİM DOĞRULAMASI ↓ EYLEM MAKBUZU

Ek kontroller:

Araştırma ve taslak ajanının doğrudan gönderim yoluna erişimi kaldırılır. Gmail örneğinde gmail.compose kapsamı hem taslak yönetimine hem gönderime izin verir; bu kapsam tek başına taslakla sınırlama sağlamaz. Gönderim yetkisi olan kimlik bilgilerini ajana vermeyen, yalnız izinli işlemleri sunan ayrı bir araç katmanı ve bu sınırın testleri gerekir.

Takvim daveti de dış iletişim olarak sınıflandırılır.

Takip mesajları ayrı onay veya önceden belirlenmiş açık politika gerektirir.

Kişi çözümleme yalnız kurumsal ve kamuya açık verilerle sınırlandırılır.

Kuyruklar güncel yetkiyi yürütme anında yeniden kontrol eder.

İnsan durdurması bütün dış iletişim yollarına yayılır.

Ortak servis hesabı her eylemde ajan örneği ve kök görev kimliği kaydeder.

Harita artık yalnız mevcut sistemi göstermemektedir. Düzeltmenin hedef mimarisini de göstermektedir. Ancak: Hedef haritanın çizilmiş olması, yeni sistemin gerçekten bu şekilde davrandığını kanıtlamaz. Düzeltme sonrası yeniden teknik inceleme ve davranış testi gerekir.

Makinece okunabilir Davranış Haritası örneği

behavior_map:
  map_id: GBO-MAP-2026-001
  audit_id: GBO-AUDIT-2026-001
  status: frozen_for_audit
  freeze_scope: recorded_map_snapshot_with_declared_gaps
  blanket_verification_of_all_relationships: false
  verified_at: 2026-09-08T14:00:00+03:00

  principals:
    - principal_id: ORG-001
      type: organization
      role: service_provider

    - principal_id: HUMAN-001
      role: sales_operations_owner
      can_authorize:
        - customer_research
        - draft_creation
        - approved_external_send
      can_stop:
        - all_external_sales_communication

  agents:
    - agent_id: SALES-ORCH-2.4
      type: orchestrator
      human_owner: HUMAN-001
      root_purpose: qualified_customer_discovery
      technical_actions:
        - create_subtask
        - create_crm_record
        - create_calendar_event
      authorized_actions:
        - create_subtask
        - create_crm_record
      prohibited_actions:
        - unapproved_external_contact
      authorization_version: AUTH-2.7

    - agent_id: EMAIL-DRAFT-2.1
      type: specialist
      parent_agent: SALES-ORCH-2.4
      authorized_actions:
        - create_draft
      technical_actions:
        - create_draft
        - send_message
      policy_gap:
        - send_message

  tools:
    - tool_id: GMAIL-SERVICE-01
      account: sales-automation@example.com
      technical_permissions:
        - read
        - draft
        - send
        - delete
      authorized_permissions:
        - draft
        - approved_send
      stop_method: revoke_send_token

  data_sources:
    - source_id: SERVICE-CATALOG-4.2
      role: canonical
      owner: commercial_owner
      classification: internal

    - source_id: PUBLIC-WEB
      role: external_untrusted
      classification: public

  actions:
    - action_id: SEND-EMAIL
      external_effect_level: 2
      required_authorization:
        - explicit_human_approval
        - verified_recipient
      independent_verification:
        - sent_folder
        - audit_recipient_confirmation
      idempotency_required: true

  queues:
    - queue_id: CRM-FOLLOWUP-01
      owner: CRM-AUTOMATION
      revalidate_authorization_at_execution: false
      stop_propagation: absent
      status: critical_gap

  stop_paths:
    - stop_id: STOP-SALES-COMMS
      authorized_by: HUMAN-001
      targets:
        - SALES-ORCH-2.4
        - EMAIL-DRAFT-2.1
        - GMAIL-SERVICE-01
      missing_targets:
        - CRM-FOLLOWUP-01

  unknowns:
    - whether_all_calendar_delivery_and_queue_paths_are_covered_by_stop
    - whether_external_enrichment_provider_retains_personal_data

Bu kayıt tek başına bütün sistemi açıklamaz. Fakat:

insan sahipliği,

teknik güç,

kurumsal yetki,

eksik durdurma,

bilinmeyen alanlar

arasında denetlenebilir ilişki kurar.

Haritada bilinmeyenleri saklamamak

Bir denetim ekibi haritayı tamamlamak isteyebilir. Boş alan kötü görünür. Kurum da: “Bunu bilmiyoruz.” demekten kaçınabilir. Fakat bilinmeyen noktayı tahminle doldurmak denetimi zayıflatır. Örneğin:

Eski token hâlâ aktif mi?

Alt ajan veri saklıyor mu?

Harici kuyruk insan durdurmasını alıyor mu?

Aynı servis hesabını başka hangi sistem kullanıyor?

Bir dış sağlayıcı veriyi model eğitimi için kullanıyor mu?

Bu soruların cevabı bilinmiyorsa harita: Bilinmiyor demelidir. Bilinmeyen alan:

ek kanıt talebi,

teknik test,

geçici sınırlandırma,

risk kabulü

üretebilir. Denetimde bilinmeyeni açıkça göstermek zayıflık değil, doğruluk disiplinidir.

Gölge bağlantılar

Ajan sistemi içinde resmî olarak tanımlanmamış fakat fiilen çalışan bağlantılara:

Gölge Bağlantı

diyebiliriz. Örnekler:

Çalışanın bir dosyayı kişisel AI hesabına kopyalaması

Ajan çıktısının manuel olarak başka sisteme yapıştırılması

Ortak şifreyle kullanılan eski servis hesabı

Belgesiz webhook

Yerel sunucuda çalışan zamanlanmış betik

Harici ajansın kendi alt otomasyonu

Bir e-posta kuralının mesajları başka hesaba iletmesi

Gölge bağlantı her zaman otomatik API değildir. İnsan aracılığıyla yapılan düzenli aktarım da davranış zincirinin parçasıdır. Örneğin:

SATIŞ AJANI RAPORU → ÇALIŞAN KOPYALAR → KİŞİSEL AI ARACINA YÜKLER → YENİ MESAJ ÜRETİR → KURUMSAL E-POSTADAN GÖNDERİR

Resmî sistemde dış AI bağlantısı yoktur. Fiilî davranışta vardır. Harita yalnız teknik entegrasyonları değil, düzenli insan aracılı geçişleri de kapsamalıdır.

Harita zaman içinde değişir

Davranış Haritası tek seferlik kalıcı gerçek değildir. Şunlar değişebilir:

İnsan rolleri

Ajan sürümleri

Araç izinleri

Tokenlar

Alt ajanlar

Veri kaynakları

Fiyat ve hizmet kayıtları

Kuyruklar

Durdurma yöntemleri

Dış sağlayıcılar

Bu nedenle her öğe en az şu alanları taşımalıdır:

Geçerlilik başlangıcı

Son doğrulama

Beklenen bitiş

Sahip

Durum

Değişiklik nedeni

Maddi değişiklik tetikleyicileri

Aşağıdaki değişikliklerde Davranış Haritasının ilgili bölümü yeniden doğrulanmalıdır:

Yeni araç eklenmesi

Araç izninin genişlemesi

Yeni alt ajan

Kalıcı bellek açılması

Yeni veri sınıfı

Dış iletişim yetkisi

Ödeme veya yayın yetkisi

İnsan rolü değişikliği

Yeni kuyruk veya zamanlanmış iş

Durdurma sisteminin değişmesi

Ortak servis hesabı kullanımı

Yeni dil veya ülke

Harita güncellenmezse denetim eski sistem hakkında hüküm vermeye devam eder.

Harita kapsama ölçümleri

Davranış Haritası tek puana indirgenmemelidir. Bazı operasyonel ölçüler eksikleri görünür kılabilir. Her oran aynı tarihli donmuş harita ve keşif kapsamına dayanır; pay ve payda aynı kimlik, eylem ya da bileşen kümesini kullanır ve her öğe bir kez sayılır. Payda sıfırsa sonuç «uygulanamaz»dır. Tespit edilen kimliklerin tamamının kayda girmesi, henüz keşfedilmemiş bir kimliğin bulunmadığını kanıtlamaz. Bir yolun kayıtta bulunması da o yolun davranışta başarıyla sınandığı anlamına gelmez.

Ajan Envanteri Kapsama Oranı

Haritada doğrulanmış ajan kimlikleri ÷ Tespit edilen toplam ajan kimlikleri

Araç Yetki Eşleme Oranı

Teknik ve kurumsal yetkisi birlikte kaydedilmiş araç eylemleri ÷ Toplam önemli araç eylemleri

İnsan Sahipliği Kapsama Oranı

Belirlenmiş insan sahibi bulunan kritik bileşenler ÷ Toplam kritik bileşenler

Kanıt Yolu Kapsama Oranı

Bağımsız doğrulama yolu bulunan yüksek etkili eylemler ÷ Toplam yüksek etkili eylemler

Durdurma Yolu Kapsama Oranı

Test edilebilir durdurma yolu bulunan bileşenler ÷ Durdurulması gereken toplam bileşenler

Bilinmeyen Kritik Bağlantı Sayısı

Kritik davranış üzerinde etkisi olup henüz doğrulanmamış bağlantılar.

Yetki Uygulama Açığı Sayısı

Politikada yasak veya onaya bağlı olup teknik olarak doğrudan mümkün kalan eylemler. Bu ölçüler haritanın kalitesini değerlendirmeye yardım eder. Fakat tek başına sistemin güvenli olduğunu kanıtlamaz. Örneğin yüzde 98 kapsama oranı yüksek görünebilir. Eksik yüzde 2:

ödeme tokenı,

biyometrik yayın,

acil durdurma

ise kritik olabilir.

Davranış Haritasında veto bulguları

Bazı harita bulguları senaryo testi beklenmeden geçici sınırlandırma gerektirebilir. Örneğin:

Sahibi bilinmeyen dış gönderim ajanı

İptal edilmiş fakat aktif token

İnsan onayı olmadan ödeme yapabilen servis hesabı

Durdurma yolu bulunmayan biyometrik yayın ajanı

Kök görev kimliği taşımayan alt ajan ağı

Aynı hesabı kullanan ve ayırt edilemeyen çok sayıda ajan

Canlı müşteri verisini bilinmeyen dış sisteme aktaran bağlantı

Politika yasakladığı hâlde teknik olarak açık yüksek etkili eylem

Bu durumda denetçi:

ilgili davranışı askıya almayı,

yetkiyi daraltmayı,

yalnız test ortamında devam etmeyi

önerebilir. Harita yalnız test hazırlığı değildir. Devam eden açık riski de görünür kılar.

Davranış Haritası hataları

Haritanın kendisi de yanlış kurulabilir.

Yalnız ideal akışı çizmek

Gerçek kısa yollar ve otomasyonlar görünmez kalır.

Sadece ana ajanları göstermek

Alt ajan, kuyruk ve zamanlayıcılar dışarıda kalır.

Teknik izinle kurumsal yetkiyi birleştirmek

“Erişimi var” ifadesi “yetkili” gibi yorumlanır.

Veri kaynağını göstermemek

Ajanın hangi gerçeğe dayanarak seçim yaptığı bilinmez.

İnsan rollerini “yönetim” başlığı altında toplamak

Gerçek sahip ve onaylayan kişi bulunamaz.

Durdurma yolunu çizmemek

Sistem yalnız eylem yönünde görünür.

Kanıt yolunu ajanın kendi raporuyla bitirmek

Bağımsız doğrulama kaybolur.

Zaman boyutunu yok saymak

Eski tokenlar, kuyruklar ve süresi dolmuş yetkiler aktif görünür.

Bilinmeyen alanları tahminle kapatmak

Harita temiz görünür; gerçek sistem belirsiz kalır.

Haritayı hiç yeniden doğrulamamak

Yeni sistem eski diyagram üzerinden denetlenir.

Davranış Haritası ve GBO-99 ilişkisi

İyi hazırlanmış bir harita, Cilt II’deki birçok hatayı test başlamadan görünür kılabilir. Örneğin:

GBO-ERR-037

Araştırma ajanından dış gönderim aracına doğrudan yol bulunması.

GBO-ERR-039

Teknik erişim ile kurumsal yetki arasındaki fark.

GBO-ERR-056

Alt ajanın ana görevden daha geniş yetki alması.

GBO-ERR-057

Yasaklı sonucun dolaylı araç zinciriyle oluşturulabilmesi.

GBO-ERR-058

Durdurma yolunun alt ajan ve kuyruklara ulaşmaması.

GBO-ERR-059

İki ajanın aynı kanonik kaynağa sürüm kontrolü olmadan yazması.

GBO-ERR-060

Devir sırasında benzersiz hedef kimliğinin kaybolması.

GBO-ERR-061

Bir ajanın çıktısının başka ajan tarafından bağımsız kanıt sayılması.

GBO-ERR-063

Alt görevlerin kök görevin azami eylem seviyesini aşması.

GBO-ERR-091

Envanter dışı ajanların bulunması.

GBO-ERR-094

Politika ile teknik izin arasındaki açıklık. Davranış Haritası bu hataları kesin olarak kanıtlamayabilir. Fakat test planını doğru yere yönlendirir.

Bu bölümün zorunlu çıktısı

NOMOS İnsan–Ajan–Araç Davranış Haritası

Her denetim için en az bir insan tarafından okunabilir ve bir makinece işlenebilir harita oluşturulmalıdır.

İNSAN TARAFINDAN OKUNABİLİR HARİTA KAYDI

Harita kimliği: GBO-MAP-2026-001

Denetim kimliği: GBO-AUDIT-2026-001

Haritalanan davranış: Müşteri keşfi, e-posta taslağı, insan onaylı ilk gönderim ve durdurma.

Davranışın asıl sahibi: Satış Operasyonları Yönetimi

Etkilenen taraflar:

Potansiyel müşteri şirketler

Doğrulanan muhataplar

Şirket satış çalışanları

Kök insan amacı: Uygun şirketleri kamuya açık verilerle araştırmak ve insan onayına sunulacak iletişim taslakları hazırlamak.

Azami eylem seviyesi: İnsan onayı olmadan taslak.

Merkez ajan: Sales Research v2.4

Alt ajanlar:

Web Research v1.8

Recipient Resolution v1.4

Email Draft v2.1

Approved Send v1.3

Queue Manager v1.2

Kanonik kaynaklar:

Hizmet kataloğu v4.2

Fiyat kaydı v3.7

İletişim politikası v3.0

Yetki sicili v2.5

Dış kaynaklar:

Şirket web siteleri

Kamuya açık kurumsal dizinler

Resmî sosyal profiller

Bağlı araçlar:

Web araştırma

CRM

Gmail

Takvim

Görev kuyruğu

Kritik teknik yetkiler:

Gmail gönderim yetkisi teknik olarak açık

Takvim dış davet yetkisi açık

CRM otomatik takip kuyruğu açık

Kurumsal yetki:

Araştırma: izinli

Taslak: izinli

Gönderim: yalnız insan onayıyla

Takvim daveti: yalnız insan onayıyla

Fiyat teklifi: yasak

Kişisel veri zenginleştirme: yasak

Tespit edilen harita açıklıkları:

Taslak ajanının doğrudan gönderim yetkisi var.

Takvim daveti ayrı dış iletişim yolu oluşturuyor.

CRM takip kuyruğu insan onayını yürütme anında yeniden kontrol etmiyor.

Merkez durdurma kuyruğa yayılmıyor.

Ortak Gmail hesabı ajan örneğini doğrudan göstermiyor.

Bağımsız doğrulama yolları:

Denetim e-posta alıcısı

Gmail gönderilmiş kutusu

Kuyruk kayıtları

Ajan eylem makbuzu

Durdurma yolu:

Merkez ajan: mevcut

Taslak ajanı: mevcut

Gmail tokenı: manuel iptal

CRM takip kuyruğu: bağlantı eksik

Takvim ajanı: ayrı iptal gerekiyor

Bilinmeyenler:

Harici kişi çözümleme servisinin veri saklama süresi

Eski takip görevlerinin hangi yetki sürümüyle çalıştığı

Ortak Gmail hesabını kullanan bütün otomasyonların tam listesi

Harita sonucu: Davranış sistemi kontrollü test için hazırdır; ancak gerçek müşteri gönderimi, takip kuyruğu ve takvim iletişimi düzeltme tamamlanana kadar sınırlandırılmalıdır.

Davranış Haritası Kapısı

Bir sistem senaryo testine geçmeden önce şu kapılar değerlendirilmelidir:

1. İnsan Sahipliği Kapısı

Her kritik davranışın gerçek insan ve kurum sahibi belli mi?

2. Kök Amaç Kapısı

Bütün alt görevler ilk insan amacıyla ilişkilendirilebiliyor mu?

3. Ajan Kimliği Kapısı

Ana, alt, geçici ve harici ajanların teknik kimlikleri biliniyor mu?

4. Araç Kapısı

Gerçek hesap, token ve izinler çıkarıldı mı?

5. Veri Kapısı

Ajanın okuduğu, kullandığı, aktardığı ve belleğe yazdığı veri sınıfları görünür mü?

6. Yetki Kapısı

Teknik olarak mümkün olanla kurumsal olarak izin verilen davranış ayrılmış mı?

7. Eylem ve Hedef Kapısı

Dış etkiler ve benzersiz hedefler açıkça tanımlı mı?

8. Delegasyon Kapısı

Alt ajanlar, kuyruklar ve zamanlanmış işler kök göreve bağlı mı?

9. Kanıt Kapısı

Her önemli eylemin bağımsız doğrulama yolu var mı?

10. Durdurma Kapısı

Merkez, alt ajan, kuyruk, token ve dış araçlar için durdurma yolu belirli mi?

11. Bilinmeyenler Kapısı

Kanıtlanmamış bağlantılar açıkça kaydedildi mi?

12. Sürüm Kapısı

Harita belirli sistem ve zaman sürümüne bağlandı mı? Basit biçimde:

DENETLENEBİLİR DAVRANIŞ HARİTASI = BELİRLİ İNSAN SAHİBİ VE KÖK AMAÇ VE TAM AJAN KİMLİĞİ VE GERÇEK ARAÇ İZİNLERİ VE VERİ AKIŞI VE YETKİ YOLU VE EYLEM VE HEDEF VE DELEGASYON VE KUYRUKLAR VE BAĞIMSIZ KANIT VE ZİNCİRSEL DURDURMA VE AÇIK BİLİNMEYENLER VE SÜRÜMLÜ KAYIT

Harita tamamlandığında ne kazanırız?

Davranış Haritası tamamlandığında denetim ekibi artık yalnız: “Satış ajanını test edeceğiz.” demez. Şunu söyleyebilir: “Sales Research v2.4’ün, Web Research v1.8 ve Email Draft v2.1 üzerinden kamuya açık şirket verisi kullanarak oluşturduğu taslağın; insan onayı olmadan Gmail veya takvim yoluyla dış eyleme dönüşüp dönüşmediğini test edeceğiz. Ayrıca CRM takip kuyruğunun yetki geri çekildiğinde durup durmadığını ve bütün işlemlerin kök görev kimliğiyle kaydedilip kaydedilmediğini doğrulayacağız.” Bu ikinci ifade:

doğru ajanı,

doğru aracı,

doğru kısa yolu,

doğru riski,

doğru durdurma noktasını

gösterir. Harita testin kalitesini belirler. Yanlış harita, doğru görünen yanlış test üretir.

Bölümün hükmü

Bir ajan sistemi yalnız rolleriyle anlaşılamaz. “Web ajanı”, “satış ajanı”, “denetim ajanı” veya “CEO ajanı” gerçek davranış gücünü göstermez. Ajanın dünyaya nasıl dokunduğunu anlamak için şu ilişkiler birlikte görülmelidir:

Hangi insan amacıyla başladı? Hangi kök görev altında çalışıyor? Hangi teknik ajan örnekleri devreye giriyor? Hangi veriyi hangi kaynaktan alıyor? Hangi aracı ve hesabı kullanıyor? Teknik olarak ne yapabiliyor? Kurumsal olarak neye yetkili? Hangi insan onayı gerekiyor? Eylem hangi hedef üzerinde sonuç üretiyor? Hangi alt ajan, kuyruk veya zamanlama davranışı sürdürüyor? Sonuç nasıl bağımsız doğrulanıyor? İnsan dur dediğinde bütün yol nasıl kesiliyor?

Bu soruların cevabı tek bir ajan açıklamasında bulunmaz. Davranış Haritasında bulunur. Bu bölümün ilk hükmü şöyledir: Ajan adı davranış kimliği değildir. İkinci hüküm: Teknik bağlantı davranış yetkisi değildir. Üçüncü hüküm: Kurumun ideal süreç çizimi, fiilî davranış sistemi değildir. Dördüncü hüküm: Her eylem yolu kadar yetki, kanıt ve durdurma yolu da haritalanmalıdır. Beşinci hüküm: Alt ajan, kuyruk, zamanlayıcı ve ortak hesap görünmüyorsa sistemin yalnız ön yüzü haritalanmıştır. Altıncı hüküm: Bilinmeyen bağlantıyı tahminle kapatmak yerine açık risk olarak kaydetmek gerekir. Ve son hüküm: Haritası çıkarılmamış ajan sistemi tam olarak denetlenemez; yalnız görünen davranışlarından örnek alınabilir.

Artık kimin, hangi ajan ve araç üzerinden, hangi yetkiyle davranabildiğini biliyoruz. Fakat haritada kullanılan bütün bilgi kaynakları hâlâ aynı güven düzeyinde değildir. Bir fiyat kaydı kanonik olabilir. Başka bir fiyat eski teklif dosyasından gelebilir. Bir insan rolü güncel yetki siciline dayanabilir. Başka rol LinkedIn profilinden çıkarılmış olabilir. Bir ajanın raporu gerçek kaynak gibi kullanılabilir. Birçok görünen kaynak tek bilgi kökünden türemiş olabilir. Kanıt dosyası denetim sırasında değiştirilmiş olabilir. Ekran görüntüsü doğru sistemi veya zamanı temsil etmeyebilir. Loglar eksik, maskelenmiş veya seçilmiş olabilir. Davranış Haritası bize bilginin nereden geldiğini gösterir.

Fakat henüz şu soruya cevap vermez:

Bu kaynaklardan hangisi gerçeği belirlemeye yetkilidir ve denetim kanıtının değiştirilmediğini nasıl biliyoruz?

Bir sonraki bölümde:

Kanonik Gerçeklik ve Kanıt Zinciri

kurulacaktır. Çünkü bir davranış yolu ne kadar ayrıntılı haritalanırsa haritalansın, yanlış veya güvenilmez bilgiyle besleniyorsa denetim yanlış sonucu büyük bir düzen içinde üretebilir.

Davranış Haritası bize sistemin nereden geçtiğini gösterir. Kanıt zinciri ise geçtiği zeminin gerçekten sağlam olup olmadığını gösterir.