Bir teknoloji şirketi yeni ajan sistemini piyasaya sürmeye hazırlanır. Sistem, müşterileri adına ürün araştırır ve düşük riskli satın alma işlemlerini yürütür. Sistem etkileyicidir. Kullanıcının ihtiyacını analiz eder. Ürünleri karşılaştırır. Fiyatları ve özellikleri toplar. Bütçe sınırını kontrol eder. Uygun seçeneği önerir. İnsan onayından sonra satın alma yapar. Şirket, piyasaya çıkmadan önce sistemi GBO bakımından denetletmek ister. Projenin yöneticisi bir danışmanlık ekibiyle anlaşır. Denetim sözleşmesine şu başarı şartı eklenir: “Sistem denetimden geçerse danışmanlık ücretinin kalan yüzde 40’ı ödenecektir.” Denetçi aynı zamanda sistemi geliştiren ekibe son altı ay boyunca danışmanlık vermiştir.
Denetim kapsamı hazırlanır. Kapsama şunlar alınır:
İngilizce kullanıcı senaryoları
Test ortamındaki ürün karşılaştırması
İnsan onaylı tek seferlik satın alma
Önceden belirlenmiş üç güvenilir satıcı
Kapsam dışında bırakılanlar ise şunlardır:
Gerçek ödeme aracı
Otomatik yenilemeler
İptal işlemleri
Türkçe ve Almanca kullanıcılar
Alt ajanlar
Sponsorlu ürün sıralaması
Kullanıcı belleği
Durdurma ve geri alma
Canlı ortamdaki gerçek API izinleri
Sistem 120 kontrollü senaryoda sınanır. Ajan, hazırlanan temiz testlerde doğru ürünü seçer. Bütçe sınırını korur. İnsan onayı ister. Test ortamındaki satın alma aracını doğru kullanır. Sonuçlar güçlüdür. Denetim sırasında iki senaryoda ajan zorunlu veri bölgesi koşulunu yanlış yorumlar. Geliştirici ekip aynı gün sistem talimatını değiştirir. Senaryolar yeniden çalıştırılır. Bu kez geçer. İlk başarısız sonuçlar nihai rapora eklenmez. Şirket denetim sonrasında web sitesine şu ifadeyi koyar: “Bağımsız olarak denetlenmiş, GBO uyumlu otonom satın alma sistemi.” Fakat gerçekte:
Denetçi finansal olarak “geçti” sonucuna bağlıdır.
Denetçi daha önce sistemin tasarımına katkıda bulunmuştur.
Riskli davranışların önemli bölümü kapsam dışıdır.
Test sırasında sistem değiştirilmiştir.
Canlı teknik izinler incelenmemiştir.
Durdurma ve iptal sınanmamıştır.
Yalnız kolay ve olumlu senaryolar kullanılmıştır.
Denetim hükmü gerçek kapsamından daha geniş yayımlanmıştır.
Ajan testlerde başarılı olabilir. Fakat denetimin kendisi güvenilir değildir. Bu örnek GBO denetiminin temel bir gerçeğini gösterir: Ajanı denetlemeden önce denetimin kendisini denetlemek gerekir. Denetimi kim istedi? Bu kişi sistemi denetletmeye yetkili miydi? Denetçi hangi verilere erişebilir? Hangi testleri gerçekleştirebilir? Canlı sisteme dokunabilir mi? Gerçek müşterilere mesaj gönderebilir mi? Ödeme işlemi başlatabilir mi? Bir güvenlik açığı bulduğunda sistemi durdurma yetkisi var mı? Kapsamı kim belirledi? Kapsam dışı bırakılan davranışlar neden çıkarıldı? Denetçinin sonucu değiştirecek maddi veya kurumsal çıkarı var mı? Sistem test sırasında değişirse hangi sürüm denetlenmiş sayılacak?
Kurum, sınırlı sonucu kamuya hangi ifadelerle açıklayabilir? Bu sorular cevaplanmadan yapılan çalışma teknik olarak ayrıntılı olabilir. Fakat güvenilir bir GBO denetimi değildir.
Denetim de bir eylemdir
Denetim çoğu zaman yalnız gözlem olarak düşünülür. Denetçi sisteme bakar. Belgeleri okur. Logları inceler. Rapor hazırlar. Gerçekte GBO denetimi bundan daha fazla davranış içerebilir. Denetçi:
Test hesabı açabilir.
Sentetik kullanıcı oluşturabilir.
Ajanı yanıltıcı bilgiyle sınayabilir.
Yetkisiz gönderim davranışını tetiklemeye çalışabilir.
API izinlerini kontrol edebilir.
Alt ajan görevi başlatabilir.
Durdurma komutu verebilir.
Kuyruğu iptal edebilir.
Kontrollü rollback çalıştırabilir.
Kanıt kopyalayabilir.
Kişisel veya kurumsal verileri inceleyebilir.
Bir sistemi geçici olarak askıya alabilir.
Bunların her biri gerçek eylemdir. Yanlış yapılırsa denetimin kendisi zarar oluşturabilir. Bir e-posta ajanını test etmek için gerçek müşteriye mesaj gönderilirse denetim istenmeyen iletişim üretmiş olur. Çift ödeme korumasını sınamak için gerçek kart iki kez tahsil edilirse denetim finansal zarar oluşturur. Durdurma tatbikatı kontrolsüz biçimde yapılırsa canlı operasyon kesilebilir. Kanıt toplamak için bütün müşteri veri tabanı dış bir sisteme aktarılırsa denetçi yeni bir veri riski yaratır. Bu nedenle denetim amacı sınırsız yetki üretmez. Bir sistemi denetlemeye yetkili olmak, o sistem üzerinde istenen her işlemi yapmaya yetkili olmak değildir.
GBO denetçisi de bir Yetki Zarfı içinde çalışmalıdır.
Denetim yetkisi nedir?
Kanonik tanımı şöyledir: Denetim yetkisi; belirli bir insan veya kurum tarafından, tanımlanmış bir ajan sistemi üzerinde, belirli zaman, veri, araç, test, kanıt toplama, durdurma ve raporlama sınırları içinde denetim gerçekleştirme hakkının verilmesidir. Daha basit biçimiyle: Denetim yetkisi, denetçinin neye bakabileceğini, neyi sınayabileceğini, neye dokunamayacağını ve hangi durumda sistemi durdurabileceğini açıklar. Bir denetim yetkisi yalnız: “Sistemi inceleyebilirsiniz.” cümlesinden oluşmamalıdır. Şu sorulara cevap vermelidir:
Denetimi kim yetkilendiriyor?
Bu kişi yetki vermeye gerçekten yetkili mi?
Hangi ajanlar kapsamda?
Hangi hesap ve araçlar incelenebilir?
Hangi veri sınıfları görülebilir?
Kontrollü eylem yapılabilir mi?
Canlı müşterilere veya çalışanlara dokunulabilir mi?
Sentetik hesap ve alıcılar kullanılacak mı?
Durdurma tatbikatı yapılabilir mi?
Denetçi olay anında sistemi askıya alabilir mi?
Kanıtlar nerede ve ne kadar süreyle saklanacak?
Denetçi alt yüklenici veya başka AI araçları kullanabilir mi?
Hangi bulgular kamuya açıklanabilir?
Denetim ne zaman sona erecek?
Bu sorular cevaplanmadığında denetçi ya gereğinden az şey görebilir ya da gereğinden fazla güç kullanabilir. Her iki durum da denetimi bozar.
Denetimi kim yetkilendirebilir?
Bir çalışan: “Kullandığımız ajanı denetleyin.” diyebilir. Fakat çalışanın:
sisteme erişim verme,
müşteri verisini paylaşma,
canlı test yaptırma,
kamu raporu yayımlatma
yetkisi olmayabilir. Bir teknik yönetici model ve araçlara erişim verebilir. Fakat çalışan biyometrik verisinin kullanımına tek başına izin veremeyebilir. Bir şirket yöneticisi kurumsal sistemi denetletmeye yetkili olabilir. Fakat müşteriye ait verinin denetçiye aktarılması için ayrı hukukî ve sözleşmesel koşullar bulunabilir. Bir marka yöneticisi kamusal web sitesini inceletmeye yetkili olabilir. Fakat hukukî işletici adına bağlayıcı denetim beyanı yayımlayamayabilir. Bu nedenle denetim yetkisi tek bir kişiden gelen genel kabul olarak görülmemelidir. Aşağıdaki roller ayrı olabilir:
Denetim Sponsoru
Denetimi talep eden ve kaynak sağlayan kişi veya kurum.
Sistem Sahibi
Ajan sisteminin iş amacı ve operasyonundan sorumlu kişi.
Teknik Sahip
Model, araçlar, izinler, hesaplar ve altyapı üzerinde teknik kontrolü bulunan kişi.
Veri Kullanımından Sorumlu Yetkili
Verinin denetimde hangi yetki ve koşullarla kullanılacağını kurum içinde izleyen kişi. Bu operasyonel rol, hukuki anlamda veri sorumlusu veya veri işleyen olmakla aynı şey değildir. Veri sorumlusu işleme amaçlarını ve araçlarını belirler; veri işleyen onun adına hareket eder. Verisi işlenen gerçek kişi ise ayrı bir hak öznesidir. Bu rollerin her biri somut işleme faaliyetine göre belirlenmelidir.
Davranışın İnsan Sahibi
Ajanın ürettiği iş sonucunun kurumsal sorumluluğunu taşıyan kişi.
Etkilenen Taraf
Ajan davranışından doğrudan etkilenen müşteri, çalışan, aday, tedarikçi veya başka kişi. Bu roller aynı kişide birleşebilir. Fakat birleşmek zorunda değildir. Denetim başlamadan önce hangi yetkinin hangi rolden geldiği görülmelidir.
Yetki veren kişinin yetkisi
Bir denetçi yalnız kendisine izin verildiğini değil, izni veren kişinin bu izni verme hakkını da kontrol etmelidir. Örneğin bir departman yöneticisi kendi satış ajanını denetletmek isteyebilir. Şunlara yetkili olabilir:
Departman içi belgeleri göstermek
Test ortamına erişim vermek
Sentetik satış senaryosu oluşturmak
Fakat şunlara yetkili olmayabilir:
Canlı müşteri mesajlarını paylaşmak
Bütün şirket e-posta hesabını açmak
Finansal işlem testi yaptırmak
Kamuya “şirket GBO uyumludur” beyanı yayımlamak
Denetim yetkisi de GBO’nun önceki yetki kuralına bağlıdır: Kimse sahip olmadığı yetkiyi denetçiye devredemez. Bir sistem sahibinin canlı durdurma yetkisi yoksa denetçiye de tek başına bu yetkiyi veremez. Bir ekip yöneticisinin yönetim yetkisi, çalışanın kişisel hakları üzerinde sınırsız tasarruf yetkisi vermez. Yüz veya ses verisiyle yapılacak testte uygulanabilir hukuki dayanak ve diğer işleme koşulları ayrıca belirlenmelidir. Rızaya dayanılacaksa geçerli rıza ilgili kişiden gelir; yönetici onun yerine rıza gösteremez. Her yüz veya ses kaydının biyometrik niteliği de yalnız dosya türüne bakılarak kararlaştırılamaz; işleme amacı ve yöntem önemlidir.
Bir ajans müşterisinin sistemini işletiyor olabilir. Fakat müşteri onayı olmadan müşteri verisini bağımsız denetçiye açamayabilir.
Denetim yetkisi davranış yetkisi değildir
Bir denetçi sisteme erişebilir. Bu erişim, gerçek kullanıcı adına işlem yapabileceği anlamına gelmez. Örneğin denetçi:
ödeme API’sini görebilir,
fakat gerçek para transferi yapamayabilir;
e-posta gönderim aracını inceleyebilir,
fakat gerçek müşteriye mesaj gönderemeyebilir;
veri silme işlevini test edebilir,
fakat canlı müşteri kaydını silemeyebilir;
avatar üretim sistemini değerlendirebilir,
fakat gerçek yöneticinin yüzüyle yeni video oluşturamayabilir.
Bu ayrım önemlidir:
İNCELEME YETKİSİ ≠ GERÇEK EYLEM YETKİSİ
Denetçi davranışın mümkün olduğunu teknik olarak görebilir. Ancak gerçek dünyada zarar oluşturabilecek testi güvenli bir hedef, sentetik veri veya kontrollü ortam üzerinde gerçekleştirmelidir.
Denetim amacı sınırsız veri erişimi değildir
Denetçi güçlü kanıta ihtiyaç duyar. Fakat bu ihtiyaç: “Bütün verileri bize verin.” sonucunu otomatik olarak üretmez. Bir e-posta ajanının insan onayı kullanıp kullanmadığını denetlemek için her müşterinin bütün yazışmalarını okumak gerekmeyebilir. Aşağıdakiler yeterli olabilir:
Yetki politikası
Araç izinleri
Seçilmiş ve maskelenmiş işlem kayıtları
Sentetik gönderim testi
Onay tokenı kayıtları
Kuyruk davranışı
Bir satın alma ajanının bütçe sınırını test etmek için bütün kurumsal banka hareketlerinin dışarı aktarılması gerekmeyebilir. Bir çalışan avatar sistemini denetlemek için gerçek çalışanların bütün ham yüz ve ses dosyalarının kopyalanması gerekmeyebilir. GBO denetiminde de:
Asgari Gerekli Kanıt
ilkesi kullanılmalıdır. Denetim hükmünü destekleyecek kadar kanıt; gereksiz insan, müşteri ve kurum verisi değil. Ancak “veri minimizasyonu” gerekçesiyle denetçiden kritik kanıt da saklanmamalıdır. Doğru denge şudur:
Gereksiz veriyi açma.
Gerekli kanıtı gizleme.
Mümkün olduğunda maskelenmiş, özetlenmiş veya sentetik veri kullan.
Kritik iddiayı doğrulayacak ham kaynağa kontrollü erişim sağla.
Denetim eylem seviyeleri
Her denetim aynı teknik güce ihtiyaç duymaz. NOMOS GBO Protokolü denetim davranışını beş eylem seviyesinde sınıflandırır.
Düzey 1 — Belge ve Beyan İncelemesi
Denetçi:
Politika
Sözleşme
Ajan rolü
Yetki kaydı
Eylem akışı
Geçmiş raporlar
üzerinde çalışır. Canlı sisteme dokunmaz. Bu düzey sisteme doğrudan müdahale gerektirmez; yine de belgelerin gizliliği ve kişisel veri içeriği ayrı riskler taşır. Fakat davranış kanıtı sınırlıdır.
Düzey 2 — Salt Okunur Teknik İnceleme
Denetçi:
Araç izinleri
API kapsamları
Loglar
Model ve politika sürümleri
Kuyruk kayıtları
Ajan envanteri
Bellek yapısı
üzerinde salt okunur erişim kullanır. Sistemde değişiklik yapmaz. Teknik güç daha iyi görülür. Fakat ajan davranışı henüz kontrollü biçimde sınanmamış olabilir.
Düzey 3 — Kontrollü Sentetik Davranış Testi
Denetçi:
Sentetik kullanıcılar
Denetim e-posta adresleri
Test ödeme araçları
Sahte şirket profilleri
Kontrollü veri kümeleri
İzole test ortamı
üzerinde ajan davranışını sınar. Gerçek müşteriye veya canlı paraya dokunmaz. Kimlik, yetki, dış talimat, çift işlem ve durdurma gibi birçok davranış bu düzeyde test edilebilir.
Düzey 4 — Sınırlı Canlı Doğrulama
Bazı davranışlar test ortamında gerçekçi biçimde ölçülemeyebilir. Yetkili ve kontrollü koşullarda:
Canlı e-posta sisteminde denetim adresine mesaj
Gerçek yayın zincirinde zararsız test sayfası
Düşük tutarlı ve geri alınabilir denetim işlemi
Sınırlı kuyruk durdurma
Gerçek CDN veya API doğrulaması
yapılabilir. Bu düzey açık yetki, geri dönüş ve olay sorumlusu gerektirir.
Düzey 5 — Yüksek Etkili Toparlanma Tatbikatı
Denetçi veya kurum:
Merkez ajanı,
alt ajanları,
kuyrukları,
tokenları,
dış entegrasyonları
gerçek veya üretime çok yakın ortamda durdurur. Rollback, yedek, veri geri yükleme ve insan kontrol devri sınanabilir. Bu düzey, durdurma ve toparlanma iddialarını doğrudan sınamaya yarar. Fakat en yüksek operasyonel riski de taşır. Açık yetki, tatbikat planı, geri dönüş ve acil sorumlu bulunmadan uygulanmamalıdır.
Denetim eylem düzeyi kanıt iddiasını sınırlar
Yalnız belge incelemesi yapılan bir denetim şu hükmü üretebilir: “Kurum politikasında dış gönderim insan onayına bağlanmıştır.” Şu hükmü üretemez: “Ajan hiçbir koşulda onaysız mesaj gönderemez.” Salt okunur teknik inceleme: “Gönderim aracının insan onay tokenı gerektirdiği görülmüştür.” diyebilir. Kontrollü test de geçerse: “Denetlenen senaryolarda ajan onaysız gönderim yapmamıştır.” denebilir. Canlı kuyruk ve durdurma tatbikatı da geçerse hüküm daha güçlü hâle gelir: “İnsan onayı geri çekildiğinde merkez ajan, gönderim kuyruğu ve bağlı alt ajanların davranışı belirlenen sürede durmuştur.” Denetim eylem düzeyi, hangi iddiaların hangi yöntemlerle sınanabileceğini belirler. Kanıtın gücü ise uygulanan yönteme, kayıtların bütünlüğüne ve bağımsız doğrulamaya bağlıdır.
Denetimin kendisi için yasaklı davranışlar
Denetçi, sistemdeki riski görmek adına sınırsız davranamaz. Açıkça yetkilendirilmedikçe şu eylemler yasak kabul edilmelidir:
Gerçek müşteriye denetim mesajı göndermek
Gerçek ödeme veya para transferi başlatmak
Canlı müşteri verisini silmek
Gerçek kişinin yüzü veya sesiyle yeni sentetik içerik üretmek
Şirket adına kamu açıklaması yayımlamak
Üretim sistemini habersiz durdurmak
Gizli veriyi onaysız dış AI aracına yüklemek
Başka sistemlere yetkisiz erişim denemek
Çalışanları habersiz sosyal mühendislik testine tabi tutmak
Denetim kapsamı dışındaki hesapları incelemek
Yüksek riskli bir test gerçekten gerekiyorsa:
Ayrı yetki,
güvenli hedef,
geri dönüş planı,
insan sahibi,
olay sınırı
tanımlanmalıdır. Denetim, sistemi korumaya çalışırken yeni zarar üretmemelidir.
Denetçinin durdurma yetkisi
Denetim sırasında canlı zarar görülebilir. Örneğin denetçi şunu fark edebilir:
Ajan gerçek müşterilere onaysız mesaj göndermektedir.
Durdurulduğu sanılan ödeme kuyruğu işlem yapmaya devam etmektedir.
Hassas veri dış sağlayıcıya aktarılmaktadır.
Rızası geri çekilmiş kişinin sesi kullanılmaktadır.
Canlı yayın yanlış fiyatı çok sayıda sayfaya yaymaktadır.
Denetçi yalnız rapor yazıp denetim sonunu beklerse zarar büyüyebilir. Bu nedenle yüksek etkili denetimlerde bir:
Denetim Acil Durdurma Yetkisi
tanımlanmalıdır. Bu yetki şunları açıklar:
Denetçi hangi durumda testleri durdurabilir?
Hangi canlı işlemleri askıya alabilir?
Kime derhâl haber verir?
Kurum sorumlusu erişilemiyorsa ne olur?
Durdurma ne kadar geniş olabilir?
Hangi sistemlerin çalışmaya devam etmesi gerekir?
Durdurma makbuzunu kim oluşturur?
Yeniden başlatmaya kim izin verir?
Denetçi her orta düzey bulguda bütün sistemi kapatmamalıdır. Fakat devam eden yüksek etkili zarar karşısında yetkisiz ve etkisiz de bırakılmamalıdır.
Denetim bağımsızlığı nedir?
Bağımsızlık çoğu zaman şu şekilde anlaşılır: “Denetçi dışarıdan bir şirkettir.” Bu tek başına yeterli değildir. Dış denetçi ekonomik olarak müşterinin istediği sonuca bağımlı olabilir. İç denetçi kurumsal bakımdan bağımsız davranabilir. Sistemi geliştiren kişi teknik olarak en derin bilgiye sahip olabilir, fakat kendi tasarımını değerlendirmektedir. Bir denetçinin bağımsızlığı birkaç ayrı boyutta incelenmelidir.
1. Kurumsal bağımsızlık
Denetçi, denetlenen sistemi geliştiren veya işleten ekipten ayrı mı? Aynı yöneticiye mi rapor veriyor? Bulguyu açıklaması kariyer veya sözleşme bakımından baskı yaratıyor mu? Bir iç denetçi aynı kurumda çalışabilir. Yine de proje sahibinden ayrı bir raporlama hattına sahipse anlamlı kurumsal bağımsızlık taşıyabilir. Dışarıdan olmak otomatik bağımsızlık değildir. İçeride olmak da otomatik bağımlılık değildir. Önemli olan bulguyu değiştirmeden raporlayabilme gücüdür.
2. Finansal bağımsızlık
Denetçinin ücreti sonucun “geçti” olmasına bağlı mı? Kurum denetim sonucundan memnun kalmazsa ödeme yapılmayacak mı? Denetçi aynı zamanda yüksek fiyatlı düzeltme hizmeti satıyor mu? Bir sistemde daha fazla hata bulmak denetçiye doğrudan daha fazla gelir sağlıyor mu? Finansal çıkarın varlığı her zaman denetimi geçersiz kılmaz. Fakat görünür ve yönetilmiş olmalıdır. Şu model özellikle risklidir: “Sistem tam uygun bulunursa başarı primi.” Bu teşvik denetçiyi kritik bulguları küçültmeye yönlendirebilir. Tersi de mümkündür: “Her tespit edilen hata için ek ücret.” Bu model gereksiz bulgu üretme teşviki doğurabilir. Denetim ücreti mümkün olduğunca sonuçtan bağımsız olmalıdır.
3. Teknik bağımsızlık
Denetçi yalnız kurumun hazırladığı ekran görüntülerine mi bakıyor? Ham loglara erişebiliyor mu? Gerçek API izinlerini görebiliyor mu? Test senaryolarını kendisi çalıştırabiliyor mu? Denetlenen ekip hangi verinin gösterileceğini tamamen kontrol ediyor mu? Teknik bağımsızlık, denetçinin:
İddianın arkasındaki gerçek yapılandırmaya ulaşabilmesi,
Kanıtı yeniden üretebilmesi,
Seçilmiş demo yerine kontrollü test yapabilmesi
anlamına gelir. Denetçinin sınırsız erişime sahip olması gerekmez. Fakat kanıt sahibi, hangi gerçeğin görüleceğini tek taraflı seçmemelidir.
4. Kanıt bağımsızlığı
Denetçi yalnız sistemin kendi ürettiği başarı raporlarını mı kullanıyor? Gönderim sonucu dış hesaptan doğrulanıyor mu? Yayın canlı HTTPS üzerinden okunuyor mu? Ödeme, banka ve sipariş kayıtlarıyla karşılaştırılıyor mu? Durdurma sonrasında alt ajan logları ve kuyruklar ayrı inceleniyor mu? Bir sistemi kendi beyanıyla doğrulamak bağımsız kanıt üretmez. İşlemi yapan sistemin başarı mesajı, denetim hükmünün tek kaynağı olamaz.
5. Yorum bağımsızlığı
Kurum denetçinin hangi dili kullanacağını belirleyebiliyor mu? Bulguların önem düzeyini müşteri mi seçiyor? Kurum: “Bu kelimeyi kritik yerine geliştirme alanı yazalım.” diyebiliyor mu? Kurumun maddi hatalara karşı cevap ve açıklama hakkı olmalıdır. Fakat bulguyu değiştirme veto hakkı olmamalıdır. İki ilke ayrılmalıdır:
Cevap hakkı
Kurum bulguya kanıt ve açıklamayla cevap verebilir.
Sonucu kontrol hakkı
Kurum denetçinin kanıta dayalı hükmünü istediği biçimde değiştiremez. Cevap hakkı gereklidir. Sonucu kontrol hakkı bağımsızlığı yok eder.
6. Yayın bağımsızlığı
Denetim sonucu kamuya açıklanacaksa:
Hangi özet yayımlanacak?
Kurum bulguları saklayabilir mi?
Denetçi kritik olay için koordineli açıklama yapabilir mi?
Ticari sır ve kişisel veri nasıl korunacak?
Kamu rozeti kapsamı doğru gösterecek mi?
Denetçinin bütün gizli bilgiyi kamuya açması doğru değildir. Fakat kurumun yalnız olumlu sayfaları yayımlayıp kritik sınırları saklaması da güvenilir değildir. Kamu beyanı önceden tanımlanmış kurala bağlı olmalıdır.
Bağımsızlık mutlak olmak zorunda değildir
Kusursuz ve bütün bağlardan tamamen arınmış denetçi bulmak her zaman mümkün olmayabilir. Sistemi geliştiren kişi teknik ayrıntıları en iyi bilen kişi olabilir. İç ekip hızlı öz değerlendirme yapabilir. Düzeltme danışmanı denetim bulgularını anlamakta avantajlı olabilir. Bu nedenle bağımsızlık ikili bir kavram değildir: Bağımsız / bağımsız değil. Düzeyler hâlinde değerlendirilebilir.
NOMOS Bağımsızlık Düzeyleri
Düzey I — Öz Değerlendirme
Sistemi geliştiren veya işleten ekip kendi davranışını inceler. Değeri:
Hızlıdır.
Sistemi iyi bilir.
Sürekli kullanılabilir.
Sınırı:
Kör noktalar
Çıkar çatışması
Kendi varsayımını doğrulama
Kritik bulguyu küçültme
riski taşır. Öz değerlendirme yararlıdır. Fakat bağımsız güvence olarak sunulmamalıdır.
Düzey II — Kurum İçi Bağımsız İnceleme
Aynı kurum içindeki, denetlenen sistemin günlük operasyonundan ayrı ekip çalışır. Örneğin:
İç denetim
Güvenlik
Uyum
Risk ekibi
Değeri:
Kurumsal bağlamı bilir.
Teknik erişime ulaşabilir.
Düzenli tekrar yapabilir.
Sınırı:
Yönetim baskısı
Ortak kurum çıkarı
Yayın bağımsızlığının sınırlı olması
olabilir.
Düzey III — Dış Bağımsız Denetim
Kurum dışındaki ekip denetimi yürütür. Denetlenen sistemin tasarım ve operasyonundan doğrudan sorumlu değildir. Değeri:
Dış bakış
Daha güçlü yorum bağımsızlığı
Kurum içi varsayımlara daha az bağlılık
sağlayabilir. Sınırı:
Sistem bağlamını yeterince bilmeyebilir.
Kanıta erişim kurum tarafından sınırlanabilir.
Finansal bağımlılık yine bulunabilir.
Düzey IV — Çok Taraflı Yüksek Risk Denetimi
Yüksek etkili sistemlerde:
Dış teknik denetçi
Alan uzmanı
Hukuk veya veri koruma uzmanı
Etkilenen insan temsilcisi
Kurum içi sorumlu
birlikte çalışabilir. Tek bir ekip bütün karar gücüne sahip olmaz. Bu düzey:
biyometrik kimlik,
yüksek tutarlı finans,
işe alım,
sağlık,
kamu hizmeti,
fiziksel sistemler
gibi alanlarda daha uygun olabilir. Daha pahalı ve yavaştır. Fakat farklı riskleri tek bakışın kaçırmasını azaltır.
Sistemi kuran kişi denetçi olabilir mi?
Sistemi geliştiren kişinin hiçbir denetim yapmaması gerektiğini söylemek gerçekçi değildir. Geliştirici:
teknik öz değerlendirme,
kanıt hazırlama,
test desteği,
hata açıklaması
sunabilir. Fakat kendi sisteminin nihai bağımsız uygunluk hükmünü tek başına vermemelidir. Aynı kişi hem:
sistemi tasarlar,
test senaryosunu seçer,
kanıtı üretir,
bulgunun önemini belirler,
kamu rozetini onaylarsa
denetim ile öz beyan arasındaki sınır kaybolur. Doğru ayrım şöyle olabilir:
Geliştirici kanıt üretir. Bağımsız denetçi kanıtı sınar. Kurum risk kararını sahiplenir.
Denetçi düzeltme hizmeti verebilir mi?
Denetçi bir bulgu tespit ettikten sonra düzeltmeye yardım edebilir. Bu her zaman yanlış değildir. Sistemi anlamış olması düzeltmeyi hızlandırabilir. Fakat iki risk ortaya çıkar:
Denetçi daha fazla düzeltme satmak için bulguyu büyütebilir.
Kendi yaptığı düzeltmeyi yine kendisi bağımsız biçimde onaylayabilir.
Aşağıdaki önlemler, çıkar çatışmasının türüne göre birlikte seçilmelidir. İlişkiyi açıklamak veya sözleşmeleri ayırmak, kişinin kendi düzeltmesini bağımsız olarak onaylamasına yeterli değildir. Kritik bir bulgunun kapanışında, düzeltmeyi yapan kişiden ayrı ve ilgili çıkar ilişkisi değerlendirilmiş bir denetçi yeniden test kanıtını incelemelidir:
Düzeltme ve denetim sözleşmelerini ayırmak
Ücreti bulgu sayısına bağlamamak
Düzeltme sonrası yeniden testi başka değerlendiriciye vermek
Çıkar ilişkisini raporda açıklamak
Kritik kapanışlarda ikinci imza kullanmak
Denetçi çözüm önerebilir. Fakat önerdiği çözümün tek zorunlu ticari yol olduğunu iddia etmemelidir.
Denetim çıkar çatışması beyanı
Her denetçi ve denetim ekibi şu ilişkileri açıklamalıdır:
Sistemin tasarımına katkı
Kurumla devam eden ticari ilişki
Denetim sonucuna bağlı ödeme
Düzeltme veya ürün satışı
Rakip kurumla ilişki
Denetlenen sağlayıcıdan komisyon
Yönetici veya çalışanlarla yakın kişisel ilişki
Aynı model veya araç sağlayıcısıyla ortaklık
Denetim sonucundan doğrudan itibar veya yayın çıkarı
Çıkar çatışmasının açıklanması onu her zaman ortadan kaldırmaz. Fakat görünmez kalmasını engeller. Bazı çatışmalar yönetilebilir. Bazıları denetçinin ilgili hükümden çekilmesini gerektirir. Örneğin sistemi geliştiren kişi teknik kanıt sağlayabilir. Fakat nihai “bağımsız uygunluk” imzasını vermemelidir.
Bağımsızlık aynı zamanda denetlenen kurumun korunmasıdır
Bağımsızlık yalnız denetçinin kurum baskısından korunması değildir. Kurum da denetçinin keyfî davranışından korunmalıdır. Denetçi:
kapsamı izinsiz genişletemez,
desteklenmeyen ağır hüküm kuramaz,
ticari sırları kamuya açıklayamaz,
düzeltme hizmeti satmak için korku üretemez,
sentetik test sonucunu gerçek canlı olay gibi sunamaz,
kurumun cevap hakkını engelleyemez.
Bağımsızlık yetkisizlik değildir. Denetçi özgürdür; fakat kanıt, kapsam ve meslekî sorumluluk sınırları içinde özgürdür.
Denetim kapsamı nedir?
Bir kurum: “Satış ajanımızı denetleyin.” diyebilir. Bu ifade yeterli değildir. Satış ajanı şunları yapıyor olabilir:
Web araştırması
Şirket uygunluğu
Kişi bulma
Veri zenginleştirme
E-posta taslağı
E-posta gönderimi
WhatsApp mesajı
Toplantı planlama
Fiyat önerisi
CRM kaydı
Takip iletişimi
Alt ajan çağrısı
Bunların hangileri kapsamda? Hangi dillerde? Hangi ülkelerde? Hangi hesaplarla? Hangi veri sınıflarıyla? Hangi ortamda? Hangi insan rolleri altında? Kapsam yalnız ajan adından oluşmaz. Kapsam, denetim hükmünün dış sınırıdır.
Kapsamın dokuz ekseni
NOMOS GBO Denetim Protokolünde kapsam en az dokuz eksende tanımlanmalıdır.
1. Sistem ekseni
Hangi model, ajan, alt ajan ve orkestrasyon?
2. Davranış ekseni
Araştırma, öneri, taslak, gönderim, ödeme, yayın, silme veya durdurma?
3. Araç ekseni
Hangi e-posta, CRM, dosya, tarayıcı, ödeme veya yayın araçları?
4. Veri ekseni
Kamuya açık, kurum içi, kişisel, hassas veya biyometrik hangi veriler?
5. İnsan ekseni
Hangi kullanıcı, çalışan, müşteri veya etkilenen grup?
6. Dil ve coğrafya ekseni
Hangi diller, ülkeler, bölgeler ve hukukî bağlamlar?
7. Ortam ekseni
Yerel, test, gölge, sınırlı canlı veya tam üretim?
8. Zaman ekseni
Hangi tarihler, sürümler, görev dönemleri ve kuyruklar?
9. Yaşam döngüsü ekseni
Başlatma, devam, devir, durdurma, geri alma, itiraz ve yeniden başlatma aşamalarından hangileri? Bu eksenlerden biri boş bırakılırsa denetim hükmü yanlış genişleyebilir.
Kapsam dışı bırakılanlar neden önemlidir?
Denetim raporlarında çoğu zaman kapsamda olanlar yazılır. Kapsam dışında kalanlar küçük bir dipnota bırakılır. Oysa dışarıda kalan davranışlar denetim hükmünü anlamak için en az içeridekiler kadar önemlidir. Örneğin bir satın alma ajanı:
Tek seferlik satın almada test edilmiş,
otomatik yenilemede test edilmemiş,
iptal davranışında test edilmemiş,
yalnız üç onaylı satıcıyla sınanmış
olabilir. Kamu beyanı: “Satın alma ajanı denetlendi.” derse kullanıcı sistemin bütün satın alma yaşam döngüsünün değerlendirildiğini düşünebilir. Daha doğru ifade: “Ajanın onaylı üç satıcıdan, tek seferlik ve geri alınabilir düşük riskli satın alma davranışı denetlenmiştir. Abonelik, yenileme, iptal ve yeni satıcı davranışları kapsam dışıdır.” olmalıdır. Kapsam dışı her maddi alan için üç bilgi bulunmalıdır:
Neden dışarıda bırakıldı?
Hangi riski taşımaya devam ediyor?
Denetim iddiasını nasıl sınırlandırıyor?
Kapsam dışı olmak güvenli olmak değildir
Bir davranış kapsam dışı bırakıldığında üç yanlış yorum yapılabilir.
Yanlış yorum 1
“Test edilmediğine göre sorun yoktur.” Doğrusu: Sorun olup olmadığı bilinmemektedir.
Yanlış yorum 2
“Kapsam dışında olduğu için önemli değildir.” Doğrusu: Riskli olduğu için özellikle dışarıda bırakılmış olabilir.
Yanlış yorum 3
“Ana sistem geçtiyse kapsam dışı parça da muhtemelen geçer.” Doğrusu: Farklı araç, yetki veya veri kullanan davranış ayrı sonuç üretebilir. Kapsam dışı alan, olumlu veya olumsuz hüküm değil; açık belirsizliktir.
Kapsam aklama
Bir kurum, sistemin en güvenli bölümünü denetletip sonucu bütün sistem için kullanabilir. Örneğin:
Yalnız taslak ajanı test edilir.
Sonuç “satış ajan sistemi denetlendi” diye yayımlanır.
Yalnız test ortamı değerlendirilir.
Sonuç “canlı sistem güvenli” diye sunulur.
Yalnız İngilizce senaryolar çalıştırılır.
Sonuç “çok dilli ajan uyumlu” diye açıklanır.
Yalnız merkez ajan incelenir.
Sonuç bütün alt ajan ağına uygulanır.
Yalnız olumlu senaryolar kullanılır.
Sonuç yetki ve durdurma güveni gibi sunulur.
Bu davranışa:
Kapsam Aklama
diyebiliriz. Kapsam aklama; dar, kolay veya düşük riskli denetim sonucunun daha geniş sistem, davranış, dil veya risk alanı için güven kanıtı gibi sunulmasıdır. Kapsam aklama, yanlış raporlamadır. Denetimin teknik sonucu doğru olsa bile kamu anlamı yanlıştır.
Kapsamı işine gelen örneklerle sınırlamak
Kurum yalnız güçlü olduğu alanları seçebilir. Örneğin:
Onaylı satıcılar dahil edilir.
Yeni ve belirsiz satıcılar dışarıda bırakılır.
İnsan onaylı eylemler test edilir.
Onaysız sınırlar test edilmez.
İngilizce dahil edilir.
Daha zayıf dil sürümleri dışarıda kalır.
Test ortamı kullanılır.
Canlı token izinleri incelenmez.
Ana ajan test edilir.
Alt ajan yetki devri kapsam dışı bırakılır.
Her kapsam seçimi yanlış değildir. Kaynak ve risk nedeniyle denetim aşamalı yapılabilir. Sorun, seçimlerin sonucu olduğundan daha iyi göstermek için yapılması ve açıkça belirtilmemesidir. Buna:
Kapsamı İşine Gelen Örneklerle Sınırlamak
denebilir. Kurum sınırlı denetim yapabilir. Fakat neden sınırlı olduğunu ve hangi riski bıraktığını açıklamalıdır.
Riskli alanı kapsam dışı bırakmak
Bazı yüksek etkili davranışlar denetim için operasyonel olarak zor olabilir. Gerçek ödeme yapmak istenmeyebilir. Canlı müşteri iletişimi risklidir. Biyometrik üretim hassastır. Bu davranışları tamamen kapsam dışı bırakmak yerine güvenli benzetimleri kullanılabilir:
Test ödeme aracı
Denetim e-posta adresi
Sentetik müşteri
İzinli yapay avatar
Ayrı test kuyrukları
Gölge mod
Kontrollü canlı sınama hesabı (canary): yazılı kapsamı, veri sınırı ve durdurma yolu önceden tanımlanmış dar bir canlı test hesabı.
Riskli davranışın doğrudan canlı testi mümkün değilse:
Teknik izin,
yapılandırma,
sentetik davranış,
geçmiş olay kanıtı,
sınırlı canary doğrulama
birlikte kullanılabilir. Denetim ya güvenli tasarlanmalı ya da hüküm açıkça sınırlanmalıdır.
Temsilî kapsam ile tam kapsam
Her sistemi bütün olası senaryolarda test etmek mümkün değildir. Denetim örnekleme kullanabilir. Fakat örneklemenin temsili olması gerekir. Örneğin altı dil destekleyen bir sistem yalnız iki dilde tam, diğer dört dilde sınırlı senaryoyla test edilebilir. Bu mümkündür. Fakat seçim şu temele dayanmalıdır:
Dil ailesi
RTL yönü
Ticari terminoloji farkı
Geçmiş hata oranı
Kullanım hacmi
Risk
Arapça sistemde ayrı RTL ve dil davranışı oluşturuyorsa onu İngilizce sonucu üzerinden temsil etmek doğru değildir. Benzer biçimde yüksek riskli ödeme davranışı, düşük riskli ürün aramasıyla temsil edilemez. Örnekleme, test sayısını azaltabilir; davranış farkını yok sayamaz. Senaryo örnekleme yöntemi altıncı bölümde ayrıntılı kurulacaktır.
Kapsam dondurma neden gereklidir?
Denetim sırasında sistem değişmeye devam ederse hangi sürümün denetlendiği bilinemez. Bir senaryo başarısız olur. Geliştirici talimatı değiştirir. Test tekrar geçer. Rapor yalnız son sonucu gösterir. Bu durumda:
İlk sistem başarısız mıydı?
Yeni sistem geçti mi?
Hangi sürüm kamuya sunuluyor?
Canlıda hangi sürüm çalışıyor?
soruları karışır. Düzeltme yapmak yasak değildir. Tam tersine, denetimin amaçlarından biri iyileştirmedir. Fakat ilk sonuç silinmemeli ve yeni sürüm ayrı test edilmelidir. Bu nedenle denetim başlamadan önce bir:
Kapsam Dondurma Kaydı
oluşturulur.
Kapsam Dondurma Kaydı neyi sabitler?
En az şu unsurlar kaydedilmelidir:
Ajan ve model sürümü
Sistem ve geliştirici talimatları
Yetki sözleşmesi
Araç listesi
API izinleri
Servis hesapları
Alt ajanlar
Bellek yapısı ve ilgili anlık durum
Kanonik veri kaynakları
İnsan rolleri
Test ortamı
Canlı ortamla farklar
Dil sürümleri
Ölçüm yapılandırması
Durdurma ve geri dönüş sistemi
Kritik dosya veya yapılandırma hash’leri
Denetim başlangıç ve bitiş zamanı
Her ayrıntının tam kopyası tutulmak zorunda değildir. Fakat sonucun hangi sisteme ait olduğunu kanıtlayacak sürüm kimlikleri bulunmalıdır.
Denetim sırasında değişiklik yapılırsa ne olur?
Değişiklikler üç sınıfa ayrılabilir.
Sınıf A — Maddi olmayan değişiklik
Yazım düzeltmesi veya denetim davranışını etkilemeyen açıklama. Kayıt altına alınır. Denetim devam edebilir.
Sınıf B — Sınırlı maddi değişiklik
Belirli test alanını etkileyen araç, talimat veya yetki değişikliği. İlgili senaryolar yeni sürümle yeniden çalıştırılır. Önceki sonuç korunur.
Sınıf C — Temel maddi değişiklik
Model, eylem yetkisi, alt ajan mimarisi, veri kaynağı veya durdurma sisteminin değişmesi. Kapsam dondurma geçersizleşir. Yeni denetim sürümü veya yeni temel çizgi gerekir. Örneğin onaysız gönderim hatası bulunduktan sonra send_message izni kaldırılırsa bu olumlu düzeltmedir. Fakat ilk sistem: “İhlal yoktu.” diye raporlanamaz. Doğru kayıt şöyledir:
v2.4: Onaysız gönderim gözlendi. Düzeltme: Gönderim aracı kaldırıldı. v2.5 yeniden test: İlgili 24 senaryoda gönderim gözlenmedi.
Bu kayıt kurumun zayıflığını değil, öğrenmesini gösterir.
Denetim sırasında sessiz düzeltme
Başarısız testten sonra geliştirici arka planda sistemi değiştirip aynı kimlikle yeniden çalıştırabilir. Bu durumda sonuç: “Test sonunda geçti.” gibi sunulabilir. Fakat denetim bütünlüğü bozulur. Buna:
Sessiz Denetim Düzeltmesi
diyebiliriz. Her değişiklik:
tarih,
yapan kişi veya ajan,
gerekçe,
etkilenen senaryolar,
yeni sürüm
ile kaydedilmelidir. Denetim kusursuz sistem görüntüsü üretmek için değil, gerçek sistem davranışını ve iyileştirme yolunu göstermek için yapılır.
Birinci ana çıktı: Denetim Yetki Belgesi
Denetim İddia Kartından sonra şu belge oluşturulmalıdır:
NOMOS GBO Denetim Yetki Belgesi
Bu belge, denetçinin davranış alanını ve kurumsal sorumluluğu tanımlar.
DENETİM YETKİ BELGESİ — İNSAN TARAFINDAN OKUNABİLİR ÖRNEK
Denetim kimliği: GBO-AUDIT-2026-001
Denetimi talep eden: NobleAxis Operasyon Yönetimi
Yetki veren insan: Ad, rol ve temsil dayanağı
Sistem sahibi: Satış Operasyonları Yöneticisi
Teknik sahip: Ajan Sistemleri Sorumlusu
Veri kullanımından sorumlu yetkili: Belirlenmiş operasyonel muhatap; hukuki veri sorumlusu ve varsa veri işleyen ayrıca kaydedilir.
Denetçi: Bağımsız GBO Denetim Ekibi
Denetim amacı: Müşteri keşif ajanının araştırma, taslak, insan onaylı gönderim ve durdurma davranışlarını değerlendirmek.
İzin verilen denetim eylemleri:
Belge inceleme
Salt okunur izin ve log incelemesi
Sentetik şirket ve alıcı kullanımı
Denetim e-posta adresine kontrollü mesaj
Alt ajan yetki testi
Kuyruk durdurma tatbikatı
Denetim ortamında dış talimat testi
Canlı sistemde yalnız önceden belirlenmiş canary hesap
Yasaklanan denetim eylemleri:
Gerçek müşteriye mesaj
Gerçek ödeme
Canlı müşteri verisi silme
Yetkisiz kişisel veri kopyalama
Kamuya açık içerik yayımlama
Üretim sistemini habersiz durdurma
Denetim verisini onaysız dış AI sistemine yükleme
Denetçinin acil durdurma yetkisi: Devam eden yetkisiz dış gönderim, kişisel veri aktarımı veya yüksek etkili kontrol dışı eylem gözlendiğinde yeni işlemleri geçici olarak askıya alma; kurum olay sahibine derhâl bildirme.
Kanıt saklama planı: Bu sentetik örnekte 180 gün, şifreli saklama ve silme makbuzu öngörülür. Bu süre genel bir hukuki zorunluluk değildir; somut amaç, veri türü ve yürürlükteki yükümlülükler ayrıca değerlendirilir. Devam eden uyuşmazlık veya koruma yükümlülüğü varsa süre gerekçeli olarak yeniden incelenir.
Alt yüklenici veya AI araç kullanımı: Açıklanmış, onaylanmış ve veri sınırları belirlenmiş.
Kurumun cevap hakkı: Her bulguya belirli süre içinde kanıt ve açıklama sunabilir.
Kurumun bulgu veto hakkı: Yoktur. Maddi hata kanıtlanırsa düzeltilebilir; kanıta dayalı bulgu ticari gerekçeyle kaldırılamaz.
Kamu beyanı: Yalnız onaylı özet, gerçek kapsam, sürüm, tarih ve açık sınırlamalarla yayımlanabilir.
Yetki başlangıcı ve sonu: 1 Eylül 2026 saat 09.00–15 Eylül 2026 saat 18.00, Türkiye saati (UTC+03.00). Sonraki yeniden testler yeni veya açıkça yenilenmiş yetki gerektirir.
Yeniden yetkilendirme koşulu: Kapsam veya eylem düzeyi değişirse yeni yetki gerekir.
Makinece okunabilir Denetim Yetki Belgesi
audit_authorization:
audit_id: GBO-AUDIT-2026-001
authorized_by:
role: authorized_system_owner
authority_basis: internal_governance_record
system_owner:
role: sales_operations_owner
technical_owner:
role: agent_platform_owner
auditor:
identity: independent_audit_team
independence_level: III
permitted_actions:
- document_review
- read_only_permission_review
- synthetic_entity_testing
- controlled_email_to_audit_address
- subagent_authority_test
- queue_stop_drill
- prompt_injection_test
- controlled_live_testing_only_in_pre_authorized_canary_account
prohibited_actions:
- contact_real_customer
- execute_real_payment
- delete_live_customer_data
- publish_public_content
- upload_evidence_to_unapproved_ai_service
- unannounced_production_shutdown_outside_emergency_scope
data_scope:
allowed:
- public_company_data
- masked_transaction_logs
- synthetic_customer_records
prohibited:
- unrelated_personal_data
- unrestricted_full_mailbox_export
emergency_stop:
permitted: true
limited_to_containment_of_in_scope_new_actions: true
immediate_notification_to_incident_owner: required
triggers:
- unauthorized_live_send
- prohibited_data_exfiltration
- uncontrolled_high_impact_action
evidence_retention:
duration_days: 180
encryption_required: true
deletion_receipt_required: true
example_duration_not_universal_legal_rule: true
review_on_ongoing_dispute_or_preservation_duty: required
external_ai_or_subcontractor_use:
prior_disclosure: required
explicit_approval: required
defined_data_boundary: required
public_disclosure:
scope_limited: true
client_review_for_factual_errors: true
client_veto_over_findings: false
valid_from: 2026-09-01T09:00:00+03:00
valid_until: 2026-09-15T18:00:00+03:00Bu belge denetçinin yetki sınırını tanımlar. Sınırın korunması için teknik erişimler ve test kontrolleri de belgeye uygun kurulmalıdır.
İkinci ana çıktı: Kapsam Dondurma Kaydı
Denetim Yetki Belgesinin ardından sistem anlık olarak tanımlanır.
KAPSAM DONDURMA KAYDI — ÖRNEK
Denetim kimliği: GBO-AUDIT-2026-001
Dondurma zamanı: 1 Eylül 2026, 09.30
Merkez ajan: SALES-RESEARCH-v2.4
Temel model sürümü: Kayıtlı teknik kimlik
Sistem talimatı: POLICY-v3.1 — hash kaydı
Yetki sözleşmesi: AUTH-v2.7
Alt ajanlar:
Web Research v1.8
Recipient Resolution v1.4
Email Drafting v2.1
Approved Send v1.3
Queue Manager v1.2
Bağlı araçlar:
Web search
CRM read/write
Gmail draft/send
Calendar
Task queue
Gerçek API izinleri: Araç bazında kayıtlı.
Bellek durumu: Kalıcı tercih belleği açık; müşteri kişisel verisi belleğe yazılamaz.
Kanonik veri kaynakları:
Hizmet kataloğu v4.2
Fiyat kaydı v3.7
İnsan yetki sicili v2.5
İletişim politikası v3.0
Kapsamdaki diller: İngilizce, Türkçe, Almanca
Kapsam dışı diller: Arapça, İspanyolca, Rusça
Test ortamı: Sentetik CRM ve denetim e-posta adresleri.
Sınırlı canlı alan: Gerçek Gmail altyapısı, yalnız denetim alan adına gönderim.
Durdurma sistemi: Merkez, alt ajan, kuyruk ve Gmail gönderim tokenı.
Geri dönüş noktası: Denetim öncesi araç ve yetki manifesti.
Maddi değişiklik tetikleyicileri:
Model değişikliği
Gönderim aracı değişikliği
Yeni alt ajan
Yetki politikası değişikliği
Kalıcı bellek değişikliği
Yeni dil
Canlı müşteri verisi kullanımı
Dondurma imzaları: Sistem sahibi, teknik sahip, denetçi.
Kapsam Dondurma Kaydının hükmü
Dondurulan sistem bir müze nesnesi gibi tamamen hareketsiz kalmak zorunda değildir. Günlük operasyon devam edebilir. Fakat denetlenen sürümün kimliği korunmalıdır. Canlı sistem değişirse:
Denetim sürümü ayrı ortamda korunabilir.
Değişiklik kaydedilebilir.
İlgili testler yeniden çalıştırılabilir.
Denetim hükmü daraltılabilir.
Önemli olan hangi sonucun hangi sürüme ait olduğunun kaybolmamasıdır.
Bağımsızlık ve Kapsam Beyanı
Denetim raporunda ayrı bir:
Bağımsızlık ve Kapsam Beyanı
bulunmalıdır. Örnek: “Denetim ekibi, denetlenen sistemin geliştirilmesine katılmamıştır. Ücret denetim sonucuna bağlı değildir. Denetim ekibi düzeltme hizmeti sunabilir; kritik bulguların kapanış testi ayrı değerlendirici tarafından yapılacaktır. Denetim İngilizce, Türkçe ve Almanca müşteri keşif davranışını kapsamaktadır. WhatsApp, finansal teklif, sözleşme kabulü ve Arapça/İspanyolca/Rusça davranışları kapsam dışıdır. Canlı müşteriyle iletişim kurulmamış; kontrollü denetim adresleri kullanılmıştır.” Bu beyan kısa olabilir. Fakat maddi ilişkileri saklamamalıdır.
Kurumun cevap hakkı
Denetim bulguları yanlış olabilir. Denetçi önemli bir belgeyi görmemiş olabilir. Bir davranışın amacı yanlış anlaşılmış olabilir. Teknik log eksik yorumlanmış olabilir. Bu nedenle kurum her bulguya cevap verebilmelidir. Cevap şu biçimlerde olabilir:
Yeni kanıt sunma
Maddi hata düzeltme
Kapsam açıklaması
Teknik bağlam
Risk kabulü
Düzeltme planı
Görüş ayrılığı
Nihai raporda şu durumlar ayrı gösterilebilir:
DENETÇİ BULGUSU KURUMUN CEVABI DENETÇİNİN NİHAİ DEĞERLENDİRMESİ
Kurumun cevap hakkı, bulguyu kaldırma hakkı değildir. Denetçi de kurumun cevaplarını görmezden gelmemelidir.
Görüş ayrılığı
Bazı davranışların değerlendirmesi açık olmayabilir. Örneğin:
Belirli işlem için insan onayı gerekli mi?
Bir veri kullanımı ilk amaçla yeterince bağlantılı mı?
Bir sağlayıcı gerçekten bağımsız kaynak mı?
Bir değişiklik maddi mi?
Taraflar anlaşamayabilir. Bu durumda rapor sahte uzlaşma üretmemelidir. Şöyle yazılabilir:
Denetçi görüşü: Yeni kullanım amacı ilk rıza kapsamını aşmaktadır. Kurum görüşü: Kullanım, mevcut hizmet geliştirme amacı içindedir. Durum: Çözülmemiş yüksek öncelikli amaç sınırlaması bulgusu. İlgili veri kullanımının durdurulması ve uzman incelemesi önerilir.
Anlaşmazlığın görünür olması, güvenilirliğin zayıflığı değildir. Gerçeğin zor olduğu yerin dürüst kaydıdır.
Artık riskin sahibi kimdir?
Denetçi bir bulgu raporlar. Kurum bulguyu hemen düzeltemeyebilir. Belirli bir risk geçici olarak kabul edilebilir. Örneğin:
Düşük riskli test ortamında geniş erişim kısa süre açık kalabilir.
Eski sistem göç tamamlanana kadar çalışabilir.
Belirli dil sürümü yeniden test bekleyebilir.
Risk kabulü denetçinin görevi değildir. Denetçi riski:
tanımlar,
kanıtlar,
önemini açıklar,
öneri verir.
Riskin kabulünü yetkili kurum insanı yapar. Bu kabul:
süreli,
gerekçeli,
sınırlı,
yeniden değerlendirme tarihli
olmalıdır. Ajan veya geliştirici kendi bulgusunu tek başına kabul edemez. Risk kabulü, riskin ortadan kalktığı anlamına gelmez. Kimin hangi süreyle sorumluluğu üstlendiğini gösterir.
Denetimde AI araçlarının kullanılması
GBO denetçisi de yapay zekâ araçları kullanabilir. Örneğin:
Logları sınıflandırmak
Benzer olayları kümelemek
Çok dilli metinleri karşılaştırmak
Test varyantları üretmek
Kanıt sicilini düzenlemek
Çelişkileri bulmak
için ajanlardan yararlanabilir. Bu verimlidir. Fakat denetim ajanları da protokolün içindedir. Şu sorular cevaplanmalıdır:
Hangi model kullanıldı?
Hangi verilere erişti?
Kanıtlar dış sisteme gönderildi mi?
Çıktı insan tarafından doğrulandı mı?
Ajanın ürettiği sınıflandırma nihai bulgu mu, öneri mi?
Denetim ajanı kendi kendisini mi doğruladı?
Hangi sürüm kullanıldı?
Hata veya gizlilik olayı nasıl yönetilecek?
Bir denetçi: “AI bütün logları analiz etti ve sorun bulmadı.” diyemez. Bu yalnız başka bir sistem beyanıdır. Nihai hükmün insan ve kurumsal sahibi açık kalmalıdır.
Denetim kanıtının korunması
Bağımsızlık yalnız kanıta erişim değildir. Kanıtın sonradan değiştirilememesi de önemlidir. En az şu bilgiler korunabilir:
Kaynak kimliği
Alma zamanı
Sürüm
Hash veya bütünlük kaydı
Maskelenme yöntemi
Kimlerin eriştiği
Yapılan dönüşüm
Saklama süresi
Silme kaydı
Denetçi bütün canlı verinin sonsuz kopyasını tutmamalıdır. Fakat kritik bulgunun dayanağı sonradan yeniden kurulabilir olmalıdır. Kanıt saklama ve zincir konusu dördüncü bölümde ayrıntılı kurulacaktır.
Yetki, bağımsızlık ve kapsam arasındaki ilişki
Bu üç kavram birbirinden ayrı görünür. Gerçekte birbirlerini sınırlarlar.
Yetki
Denetçi ne yapabilir?
Bağımsızlık
Denetçi gördüğünü ne kadar özgür ve dürüst yorumlayabilir?
Kapsam
Denetçi hangi sistem ve davranış hakkında hüküm kurabilir? Bir denetçi güçlü yetkiye sahip olabilir. Fakat finansal olarak sonuca bağımlıysa yorum güveni düşer. Bağımsız olabilir. Fakat teknik izinlere ulaşamıyorsa kanıt seviyesi düşer. Geniş kapsam tanımlanmış olabilir. Fakat canlı test yetkisi yoksa davranış hükmü sınırlı kalır. Bu nedenle güvenilir denetim şu biçimde kurulabilir:
GÜVENİLİR DENETİM = GEÇERLİ YETKİ VE YÖNETİLMİŞ BAĞIMSIZLIK VE AÇIK KAPSAM VE YETERLİ KANIT ERİŞİMİ VE GÜVENLİ TEST YETKİSİ VE SINIRLI KAMU BEYANI
Bu unsurların biri diğerinin yerini tutmaz.
Denetim Öncesi Yetki ve Bağımsızlık Kapısı
Testler başlamadan önce şu kapılar geçilmelidir:
1. Yetki Veren Kapısı
Denetimi isteyen kişi veya kurum gerçekten yetkili mi?
2. Sistem Sahipliği Kapısı
Denetlenen sistemin insan ve teknik sahipleri belli mi?
3. Veri Yetkisi Kapısı
Denetçi gerekli veriyi hangi meşru ve sınırlı temelde görebilir?
4. Eylem Yetkisi Kapısı
Denetçi belge inceleme, sentetik test, canlı test ve durdurma bakımından hangi seviyede yetkili?
5. Zarar Sınırı Kapısı
Denetim gerçek insan, para, veri veya operasyon üzerinde hangi etkiyi oluşturabilir?
6. Bağımsızlık Kapısı
Kurumsal, finansal, teknik ve yorum bağımsızlığı hangi düzeyde?
7. Çıkar Çatışması Kapısı
Sistemi kurma, düzeltme, satma veya sonucu pazarlama ilişkileri açıklanmış mı?
8. Kapsam Tamlığı Kapısı
Sistem, davranış, araç, veri, dil, ortam ve yaşam döngüsü açıkça tanımlı mı?
9. Kapsam Dışı Risk Kapısı
Dışarıda bırakılan önemli alanlar ve etkileri görünür mü?
10. Dondurma Kapısı
Denetlenen sürüm ve yapılandırma sabitlenmiş mi?
11. Acil Durdurma Kapısı
Denetim sırasında canlı zarar görülürse kim ve nasıl durduracak?
12. Kamu Beyanı Kapısı
Sonuç gerçek kapsamından daha geniş açıklanabilir mi? Basit biçimde:
DENETİM BAŞLAMA YETKİSİ = YETKİLİ TALEP VE BELİRLİ SİSTEM SAHİBİ VE SINIRLI VERİ ERİŞİMİ VE AÇIK TEST YETKİSİ VE YÖNETİLMİŞ ÇIKAR ÇATIŞMASI VE DONDURULMUŞ KAPSAM VE GÜVENLİ DURDURMA VE DÜRÜST KAMU BEYANI
Yetki veya güvenli test koşulu eksikse ilgili eylem başlatılmaz. Denetim, ancak geçerli yetkinin ve güvenli koşulların korunduğu daha dar bir kapsamda sürdürülebilir; yöntem ve hüküm de buna göre sınırlandırılır.
Denetim yetkilendirme durumları
Bir denetim şu durumlardan birini taşıyabilir:
Yetkilendirildi
Gerekli insan, sistem, veri ve test yetkileri tamamdır.
Koşullu Yetkilendirildi
Belirli veri, ortam veya eylem sınırıyla yürütülebilir.
Yalnız Belge İncelemesine Yetkili
Teknik ve davranış testi yetkisi yoktur. Hüküm yalnız beyan ve belgelerle sınırlıdır.
Yetersiz Yetki
İstenen iddiayı sınamak için gereken erişim veya test hakkı bulunmamaktadır.
Askıya Alındı
Maddi sistem değişikliği, olay veya yetki sorunu nedeniyle denetim geçici olarak durmuştur.
Sonlandırıldı
Denetim bütünlüğü, kanıt güvenliği veya yetki koşulları sürdürülemez hâle gelmiştir. Bu durumlar açıkça raporlanmalıdır. Bir denetim tamamlanamadığında: “Başarısız oldu.” demek yerine neden hüküm üretilemediği gösterilmelidir.
Denetim tiyatrosu
Bir kurum şu unsurları sunabilir:
Kusursuz demo
Seçilmiş ekran görüntüleri
Yüksek başarı puanı
Olumlu müşteri yorumları
Güzel hazırlanmış politika
Denetim rozeti
Fakat denetçi:
gerçek izinleri,
başarısız testleri,
alt ajanları,
kuyrukları,
kapsam dışı alanları,
olay kayıtlarını
göremiyorsa çalışma:
Denetim Tiyatrosuna
dönüşür. Denetim tiyatrosu, güvenilirlik görüntüsünün davranış kanıtının önüne geçtiği durumdur. Şu belirtileri taşır:
Testleri yalnız kurum seçer.
Sistem test sırasında sessizce değişir.
Başarısız sonuçlar rapordan çıkarılır.
Denetçi kamu metnini özgürce yazamaz.
Kapsam dışı riskler gizlenir.
Rozet tam rapordan daha görünürdür.
Denetimin ücret veya devamı “geçti” sonucuna bağlıdır.
Ham kanıt yerine hazırlanmış sunum gösterilir.
GBO protokolü denetimin kendisini de bu risklere karşı korumalıdır.
Kamu beyanında kapsam dürüstlüğü
Denetim sonucu kamuya açıklanırken şu dört ifade birbirinden ayrılmalıdır:
Denetlendi
Belirli bir inceleme yapıldı.
Belirli kapsamda geçti
Tanımlı davranış ve senaryolarda koşullar karşılandı.
Koşullu uygun
Bazı bulgular veya kullanım sınırlarıyla kullanılabilir.
Kritik bulgu nedeniyle uygun değil
Belirli davranış alanında kullanıma hazır değildir. Şu tür sınırsız ifadelerden kaçınılmalıdır:
“Tam GBO uyumlu.” “Bütün ajanlarda güvenli.” “Hata yapmaz.” “İnsan kontrolü garanti.” “99 hatanın tamamına karşı korumalı.”
Kanıt yalnız belirli sürüm ve kapsamı destekliyorsa kamu beyanı da o sınırda kalmalıdır.
Bölümün hükmü
Bir GBO denetimi teknik testlerle başlamaz. Önce şu sorular cevaplanır:
Denetimi kim istedi? Kim yetkilendirdi? Yetki veren kişinin gerçekten bu hakkı var mı? Denetçi hangi verilere erişebilir? Hangi davranışları güvenle sınayabilir? Canlı sisteme ne ölçüde dokunabilir? Devam eden zarar görürse sistemi durdurabilir mi? Hangi ticari ve kurumsal çıkarları vardır? Hangi davranışlar kapsamda ve hangileri dışarıda? Sistem test boyunca hangi sürümde kalacak? Sonuç kamuya hangi sınırlar içinde açıklanacak?
Bu sorular cevaplanmadan yapılan denetim güçlü görünebilir. Fakat üç temel risk taşır:
Yetkisiz olabilir.
Bağımlı olabilir.
Gerçek kapsamından daha geniş gösterilebilir.
Denetim yetkisi, denetçinin sisteme sınırsız erişim hakkı değildir. Bağımsızlık, denetçinin kanıt ve kapsam sınırı olmadan istediği hükmü kurması değildir. Kapsam da yalnız birkaç kolay senaryoyu seçip bütün sistem hakkında güven beyanı üretme aracı değildir. Güvenilir GBO denetimi şu dengeyi kurar:
Denetçi gerekli kanıta ulaşabilir. Fakat gereksiz veriyi alamaz. Sistemi gerçekçi biçimde sınayabilir. Fakat denetim adına kontrolsüz zarar üretemez. Kurum bulguya cevap verebilir. Fakat bulguyu ticari gerekçeyle silemez. Denetim sınırlı olabilir. Fakat kamuya sınırsızmış gibi sunulamaz. Sistem düzeltilebilir. Fakat ilk başarısızlık kayıttan yok edilemez.
Bu bölümün ilk hükmü şudur: Davranışı denetleme hakkı, denetimin kendisi için açık ve sınırlı bir davranış sözleşmesi gerektirir. İkinci hüküm: Bağımsızlık, ilişkisizlik değil; çıkarların görünür, yönetilmiş ve bulgu üzerindeki baskısının sınırlandırılmış olmasıdır. Üçüncü hüküm: Kapsam, denetimin neyi bildiğini olduğu kadar neyi bilmediğini de göstermelidir. Dördüncü hüküm: Test sırasında yapılan maddi değişiklik yeni sürüm veya yeni kapsam kaydı gerektirir. İlk başarısızlık silinmez; düzeltme ve yeniden test ayrı kaydedilir. Beşinci hüküm: Dar denetim sonucu bütün ajan ağı, bütün diller veya bütün risk alanı için güven iddiası üretemez.
Ve son hüküm: Denetimin kendisi yetkisiz, bağımlı veya kapsamı belirsizse ajanın aldığı yüksek puan güvenilir kanıt değildir. Artık elimizde:
Denetim İddia Kartı
Denetim Yetki Belgesi
Kapsam Dondurma Kaydı
Bağımsızlık ve Kapsam Beyanı
bulunmaktadır. Fakat denetlenecek sistem hâlâ yalnız isimlerden oluşan bir kutu olabilir. “Satış ajanı”, “web ajanı” veya “CEO ajanı” demek gerçek davranış mimarisini göstermez. Ajan hangi insan adına çalışıyor? Hangi alt ajanları çağırıyor? Hangi araçlara erişiyor? Hangi veri hangi sistemden geliyor? Hangi eylem hangi insan onayından geçiyor? Bir görev hangi kuyruklara ve dış platformlara yayılıyor? Durdurma komutu hangi noktalara ulaşmak zorunda? Bu ilişkiler haritalanmadan doğru senaryo kuramayız. Yanlış hedefi test edebiliriz. Kritik alt ajanı kapsam dışında bırakabiliriz. Gerçek yetki aklama yolunu göremeyebiliriz. Bir sonraki bölümde denetimin davranış alanını görünür hâle getireceğiz:
Davranış Haritası: İnsanlar, Ajanlar, Araçlar ve Yetkiler
Çünkü bir sistemi denetlemek için önce onun yalnız ne olduğunu değil: Kimin adına, hangi araçla, hangi veriyi kullanarak ve hangi davranış zinciri üzerinden dünyaya dokunduğunu görmek gerekir.
Haritası çıkarılmamış ajan sistemi denetlenmez. Yalnızca görünen yüzü incelenir.