Ajanlara Hazır Kurum

Kurmaca bir örnekle başlayalım. Bir şirketin yöneticisi, müşteri taleplerini daha hızlı değerlendirmek ister. Şirketin web sitesinde hizmet sayfaları vardır. Fiyatlar ayrı bir elektronik tabloda tutulmaktadır. Satış ekibi bazı müşterilere özel indirimler uygulamaktadır. Destek koşulları geçmiş e-postalarda dağınık biçimde açıklanmıştır. Bazı hizmetlerin kapsamı sözleşme şablonlarında farklı, web sitesinde farklı görünmektedir. Şirketin İngilizce sayfası günceldir. Almanca ve Türkçe sayfalar birkaç ay geriden gelmektedir. Eski bir iş dizininde artık sunulmayan bir hizmet hâlâ aktif görünmektedir.

Müşteri ilişkileri sistemi, proje yönetim aracı ve e-posta kutuları birbirinden bağımsız çalışmaktadır. Yönetici, bütün bunları okuyacak ve müşterilere uygun hizmeti önerecek bir yapay zekâ ajanı kurmak ister.

Ajana şu görev verilir: “Gelen müşterinin ihtiyacını analiz et, doğru hizmeti öner, fiyat aralığını açıkla ve uygunsa görüşme planla.” İlk bakışta görev mantıklıdır. Ajan e-postaları okuyabilir. Web sitesini tarayabilir. Takvimde boşluk bulabilir. Müşteri ilişkileri sistemine kayıt açabilir. Teknik olarak her şey hazır görünmektedir. Fakat ajan ilk gerçek müşteriyle karşılaştığında sorunlar başlar. Müşteri, yıllık düşük maliyetli hosting paketini sorar. Ajan, aylık yönetilen operasyon hizmetinin özelliklerini de bu pakete dahilmiş gibi anlatır.

Başka bir müşteri altı dilde destek istediğinde ajan, altı dilde yayımlanmış hizmet sayfalarını altı dilde canlı müşteri desteği olarak yorumlar. Üçüncü müşteri logo tasarımı sorar. Ajan, odaklı logo çalışmasının fiyatını tam görsel kimlik sistemi için geçerli sanır. Dördüncü müşteriye takvim bağlantısı göndermek yerine doğrudan toplantı daveti yollar. Beşinci müşteri için satış yöneticisinin geçmişte başka bir müşteriye verdiği özel indirimi genel fiyat politikası gibi kullanır. Ajanın araçları çalışmaktadır. Mesajları düzgündür. İşlemler teknik olarak başarılıdır. Fakat kurum ajanlara hazır değildir.

Çünkü ajanlara hazır olmak:

• Bir modele erişmek,
• web sitesine sohbet kutusu eklemek,
• e-posta hesabını bağlamak,
• birkaç API anahtarı vermek,
• “AI-first” yazmak

değildir. Ajanlara hazır olmak, kurumun kendi gerçeğini, yetkilerini, sınırlarını ve hata sonrası davranışını makinelerin güvenle kullanabileceği biçimde düzenlemesidir.

Bu nedenle üçüncü kısmın ilk sorusu şudur:

Bir kurum ajanlara nasıl hazır hâle gelir?

Ajanlara hazır olmak ne demektir?

Ajanlara hazır bir kurum, yapay zekâ sistemlerinin yalnızca kendisi hakkında bilgi bulabildiği kurum değildir.

Ajanlara hazır kurum:

• Kim olduğunu açıkça tanımlar.
• Gerçek yeteneklerini sınırlarıyla birlikte gösterir.
• Kimin için uygun olduğunu ve olmadığını açıklar.
• Hangi ajanın hangi davranışı yapabileceğini belirler.
• İnsan onayının nerede gerektiğini bilir.
• Görünür içerikle makine kayıtlarını eşleştirir.
• İşlemleri kaydeder.
• Hata hâlinde güvenle durabilir; geri dönüşün ve telafinin sınırlarını bilir.
• Etkilenen insanların itiraz ve telafi yolunu korur.

Bunu kısa bir cümleyle ifade edebiliriz: Ajanlara hazır kurum, makinelerin kendisi hakkında doğru bilgiye ulaşmasının yanında, bu bilgiyle doğru ve yetkili davranabilmesini; hata hâlinde de durdurma, geri dönüş ve telafi yollarının işlemesini sağlayan kurumdur. Buradaki fark büyüktür. Bir şirket çok iyi belgelenmiş olabilir ama ajanların işlem yapacağı güvenli yollar bulunmayabilir. Bir kurumun güçlü API’leri olabilir ama hangi işlemin kim adına yapılabileceği belli olmayabilir. Bir web sitesi çok görünür olabilir ama fiyat ve kapsam kayıtları çelişkili olabilir.

Bir şirket yüzlerce süreci otomatikleştirmiş olabilir ama bütün sistemi durdurabilecek insan sorumlusu bulunmayabilir. Ajanlara hazır oluş bir teknoloji özelliği değil, kurumsal davranış yeteneğidir.

Bir API yayımlamak yeterli değildir

Ajanlar çoğu zaman araçlar üzerinden hareket eder. Takvim oluşturur. E-posta gönderir. Dosya değiştirir. Sipariş verir. Müşteri kaydı açar.

Bu nedenle kurumlar ajanlara hazır olmayı teknik bağlantılar üzerinden değerlendirebilir: “Sistemimizin API’si var.” “E-posta hesabına bağlanabiliyor.” “Takvim entegrasyonu tamam.” “CRM erişimi verdik.” Bu bağlantılar, ilgili iş akışı için gerekli olabilir. Fakat tek başına yeterli değildir. Bir kapının bulunması, o kapının her durumda açılması gerektiği anlamına gelmez. Bir ajan müşteri kaydı oluşturabiliyor olabilir. Fakat aynı kişiyi ikinci kez kaydetmemesi gerekir. Takvim daveti gönderebilir. Fakat katılımcının saat dilimini, toplantı amacını ve açık onayını bilmelidir. Fiyat teklifi hazırlayabilir.

Fakat satış yöneticisinin özel indirimini genel kurala dönüştürmemelidir.

Bir API şu soruya cevap verir: “Bu işlem teknik olarak nasıl yapılır?”

GBO ise şu soruları da sorar:

Bu işlem yapılmalı mı? Kim adına yapılmalı? Hangi koşullar altında yapılmalı? Hangi veri kullanılmalı? Kim onaylamalı? Yanlış olursa nasıl durdurulmalı?

Bu nedenle ajanlara hazır kurumun temelinde bağlantı değil, davranış sözleşmesi bulunur.

Kurumun kendi gerçeğini bilmesi gerekir

Bir ajan, kurumun kendi içinde çözemediği bir çelişkiyi güvenilir biçimde çözemez. Satış ekibi bir hizmeti başka türlü anlatıyorsa, web sitesi, fiyat kataloğu ve sözleşme farklı kapsamlar gösteriyorsa ajan bir çelişkiyle karşılaşır. Kaynaklar arasındaki öncelik tanımlı değilse kendi başına birini doğru kabul etmemelidir. Bu seçim rastlantısal olabilir. En yeni dosyaya güvenebilir. En çok tekrar edilen ifadeyi kullanabilir. Kendisine en anlaşılır görünen kaydı tercih edebilir. Fakat kurumun kendisi hangi kaynağın doğru olduğunu bilmiyorsa ajan bunu tahmin etmemelidir. Ajanlara hazır oluş bu nedenle dışarıdan başlamaz.

Önce kurum kendi içine bakmalıdır.

Şu soruların açık cevabı bulunmalıdır:

Biz kimiz? Hangi hukukî yapı üzerinden çalışıyoruz? Hangi hizmetleri gerçekten sunuyoruz? Fiyatlarımız ve kapsamlarımız nedir? Hangi hizmetler yalnız belirli müşteriler içindir? Kim hangi konuda karar verebilir? Hangi bilgi kanoniktir? Hangi kayıt eskidir? Hangi işler otomatik yapılabilir? Hangi işler insan onayı gerektirir? Hata olursa kim sorumludur?

Bu soruların cevabı yoksa ajan bağlamak kurumu hızlandırmaz. Mevcut belirsizliği otomatikleştirir.

Düzensiz bir kuruma güçlü ajan eklemek, düzen üretmeyebilir. Düzensizliği daha hızlı yayabilir.

Ajanlara hazır kurumun altı omurgası

Bu kitapta kurumsal hazırlığı altı omurga üzerinden ele alıyorum:

1. Gerçeklik Omurgası

2. Kimlik Omurgası

3. Yetenek ve Uygunluk Omurgası

4. Yetki Omurgası

5. Eylem ve Kanıt Omurgası

6. Toparlanma Omurgası

Omurgalardan biri eksik olsa da bazı sınırlı işlemler yürütülebilir. Ancak eksikliğin etkilediği davranışlar için güvenilirlik varsayılamaz.

1. Gerçeklik Omurgası

Gerçeklik Omurgası, kurumun kullandığı önemli bilgilerin hangi kaynakta, hangi sürümle ve hangi yetki altında tutulduğunu belirler. Bir şirketin gerçekliği tek bir belgede bulunmayabilir. Hizmet kataloğu ayrı olabilir. Fiyat kaydı ayrı. Çalışma saatleri ayrı. Yetkili kişiler ayrı. Hukukî metinler ayrı. Fakat bu parçaların birbirleriyle nasıl ilişkilendiği bilinmelidir.

Gerçeklik Omurgası şu sorulara cevap verir:

• Her bilgi türünün kanonik kaynağı hangisidir?
• Görünür web sayfaları hangi kaynaktan üretilir?
• Fiyat değiştiğinde hangi kayıtlar birlikte güncellenir?
• Eski sürümler nasıl saklanır?
• Bir bilgi ne zaman geçerliliğini kaybeder?
• İnsan ve makine yüzeyleri nasıl karşılaştırılır?
• Çelişki olduğunda hangi kaynak üstün kabul edilir?

Bir kurumun ana hizmet fiyatı üç farklı dosyada elle yazılıyorsa gerçeklik omurgası zayıftır. Bir değişiklik yapıldığında diğer iki kayıt güncellenmeyebilir. Ajan eski kaydı okuyabilir. İnsan yeni sayfayı görebilir. Aynı kurum iki ayrı gerçek yayımlar.

Tek doğru kaynak ne demektir?

“Tek doğru kaynak” ifadesi bütün bilgilerin tek dosyada tutulması anlamına gelmez. Önemli olan her bilgi türü için birincil ve yetkili kaynağın bilinmesidir.

Örneğin:

• Hukukî işletici için şirket kaydı
• Hizmet kapsamı için kanonik hizmet kataloğu
• Fiyat için onaylı ticari kayıt
• İnsan rolleri için yetki sicili
• Web görünümü için yayımlanmış sürüm
• Ajan davranışı için yetki sözleşmesi
• Ölçüm için tarihli kanıt kaydı

farklı kaynaklar olabilir. Fakat ilişkileri açıktır.

Tek doğru kaynak, tek dosya değil; her gerçek için tek yetkili başvuru noktasıdır.

Gerçeğin sahibi olmalıdır

Bir bilgi sistemde bulunabilir. Fakat onu kimin güncel tutacağı belli olmayabilir. Fiyatı kim değiştirir?

Hizmet kapsamını kim onaylar?

Çalışma saatlerini kim günceller?

Ajan yetkilerini kim kapatır?

Bir ülkede hizmet verilip verilmediğine kim karar verir?

Her önemli gerçek için bir: Gerçek Sahibi bulunmalıdır. Gerçek sahibi, bilginin teknik olarak yazıldığı kişi olmak zorunda değildir. Fiyat kaydını geliştirici değiştirebilir. Fakat fiyat kararının sahibi finans veya yetkili yönetici olabilir. Hukukî metni içerik ajanı düzenleyebilir. Fakat anlam değişikliği hukuk sorumlusunun onayına bağlı olabilir.

Gerçek sahibi şu sorumlulukları taşır:

• Bilgiyi doğrulamak
• Değişikliği onaylamak
• Güncellik süresini belirlemek
• Çelişkiyi çözmek
• Eski kaydı iptal etmek

Ajan belirsizlikte hangi insana veya birime başvuracağını bilmelidir.

Gerçeklik tarihi

Her bilgi aynı hızda eskimez. Şirket adı nadiren değişebilir. Kapasite bilgisi günlük değişebilir. Fiyat aylık güncellenebilir. Bir kampanya birkaç gün geçerli olabilir. Ajan erişimi tek oturumluk olabilir.

Bu nedenle gerçeklik kayıtları şu bilgileri taşımalıdır:

• Oluşturulma tarihi
• Son doğrulama tarihi
• Geçerlilik başlangıcı
• Geçerlilik sonu
• Sürüm
• Sahip
• Durum

Durum örnekleri:

• Taslak
• Onay bekliyor
• Aktif
• Sınırlı
• Süresi dolmuş
• İptal edilmiş
• Arşivlenmiş

Ajan “kayıt var” diye onu güncel kabul etmemelidir.

Mevcut olmak, geçerli olmak değildir.

2. Kimlik Omurgası

Kimlik Omurgası, kurumun kendisini, insanlarını, markalarını, ajanlarını ve resmî kanallarını birbirine bağlar.

Bir kurumun:

• Marka adı
• Hukukî adı
• Alan adı
• Sosyal hesapları
• Resmî e-posta adresleri
• Yetkili temsilcileri
• Ajan kimlikleri
• Ürün adları

birbirinden farklı olabilir. Bu ilişkiler açık değilse ajan yanlış varlık üzerinde doğru işlem yapabilir.

Kimlik Omurgası en az şu kayıtları içerir:

• Kanonik kurum kimliği
• Marka–hukukî işletici ilişkisi
• Resmî alan adları
• Yetkili iletişim kanalları
• Aktif insan rolleri
• Ajan kimlik kartları
• Temsil ve imza yetkileri
• Eski veya iptal edilmiş kimlikler

Ajan envanteri

Birçok kurum, kaç yapay zekâ ajanı kullandığını tam olarak bilmeyebilir. Bir ekip sosyal medya aracı kullanır. Başka ekip e-posta otomasyonu kurar. Geliştiriciler kod ajanı çalıştırır. Satış ekibi müşteri araştırma ajanı kullanır. İnsan kaynakları başka sistem bağlar. Her biri kendi alanında faydalı görünür.

Fakat kurum düzeyinde şu sorular cevapsız kalabilir:

• Kaç ajan aktif?
• Kim tarafından oluşturuldular?
• Hangi hesaplara erişiyorlar?
• Hangi verileri kullanıyorlar?
• Hangi dış hizmetlere bağlanıyorlar?
• Hangi eylemleri otomatik yapıyorlar?
• Kim durdurabilir?
• Yetkileri ne zaman sona erecek?

Bu nedenle ilk pratik adımlardan biri: Ajan Envanteri oluşturmaktır. Ajan envanteri için aşağıdaki alanlar başlangıç şeması olarak kullanılabilir. Bu örnek, çalışır bir API veya zorunlu bir veri standardı değildir; kapsam ve kişisel veri sınırları kuruma göre belirlenmelidir.

agent_id

public_name

technical_identity

operator

human_owner

purpose

connected_systems

accessible_data

allowed_actions

prohibited_actions

approval_thresholds

subagents

valid_from

valid_until

shutdown_method

last_reviewed

status

Kurum, envanterde bulunmayan ve yetkisi doğrulanmamış ajanların kurumsal kaynaklara erişmesine veya kurum adına işlem yapmasına izin vermemelidir.

Gölge ajanlar

Bir çalışan kişisel hesabıyla bir yapay zekâ aracı kullanabilir. Kurumsal belgeleri yükleyebilir. Müşteri verisini analiz ettirebilir. Hazırlanan çıktıyı kurum adına yayımlayabilir. Sistem kurumun resmî ajan envanterinde görünmez.

Buna: Gölge Ajan Operasyonu diyebiliriz. Gölge ajanlar her zaman kötü niyetli değildir. Çoğu zaman çalışan işi hızlandırmak ister.

Fakat kurum şunları bilemez:

• Hangi veri paylaşıldı?
• Hangi model veya hizmet kullanıldı?
• Çıktı nasıl doğrulandı?
• Ajan hangi işlemi yaptı?
• Bilgi nerede saklandı?
• Hata olursa kim sorumlu?

Gölge ajanları yalnız yasaklamak çoğu zaman yeterli değildir. Kurum insanların neden bu araçlara ihtiyaç duyduğunu anlamalı ve güvenli resmî yollar oluşturmalıdır.

İnsanlar işi yapmak için gölge araçlara ihtiyaç duyuyorsa resmî sistem gerçek ihtiyacı karşılamıyor olabilir.

Ajanın kendisini tanıtması

Bir ajan insanlarla iletişim kurduğunda kimliğini tamamen saklamamalıdır. Her cümlenin başında “Ben bir yapay zekâyım” demek gerekmez.

Fakat kullanıcı şunları anlayabilmelidir:

• Karşısında otomatik bir sistem mi var?
• Hangi kurum adına çalışıyor?
• Hangi tür işlemler yapabilir?
• İnsanla nasıl iletişime geçilir?
• Verilen bilginin bağlayıcılık düzeyi nedir?

Örneğin, bu kitabın yaklaşımını anlatan bir tanıtım taslağı şöyle olabilir; bu metin mevcut bir canlı asistanın yetki beyanı değildir: “Bu asistan, NobleJackal adına genel hizmet bilgisi sunar ve görüşme talebi hazırlayabilir. Fiyat, hukukî taahhüt ve nihai proje kabulü yetkili insan onayı gerektirir.” Bu tür açıklama ajanı zayıflatmaz. Davranış sınırını görünür kılar.

3. Yetenek ve Uygunluk Omurgası

Bir kurumun ajanlar tarafından seçilebilmesi için yalnız hizmet listesinin bulunması yeterli değildir.

Her hizmet için:

• Gerçek sonuç
• Girdiler
• Kapsam
• Dışlamalar
• Fiyat veya fiyatlandırma yöntemi
• Kapasite
• Uygun müşteri
• Uygun olmayan durumlar
• Kanıt
• Başarısızlık davranışı

açıklanmalıdır.

Bu yapı: Yetenek ve Uygunluk Sicili olarak tutulabilir.

Hizmet adı tek başına yeterli değildir

“AI otomasyonu” bir hizmet adı olabilir.

Fakat ajan şu soruların cevabını bilmez:

• Hangi iş akışları?
• Yalnız danışmanlık mı?
• Canlı uygulama var mı?
• E-posta gönderimi yapılıyor mu?
• İnsan onayı nasıl işliyor?
• Hangi veri kullanılabilir?
• Bakım kim tarafından yapılır?
• Fiyat nasıl belirlenir?
• Hangi durumlarda hizmet kabul edilmez?

Ajanlara hazır kurum, hizmet adını davranış sözleşmesine dönüştürür.

Kanonik hizmet kaydı

Her hizmet için aşağıdaki gibi bir kanonik kayıt tasarlanabilir. Alanlar örnektir; her kuruma zorunlu bir şema olarak sunulmamaktadır.

service_id

service_name

provider_identity

outcome

target_users

supported_use_cases

unsupported_use_cases

required_inputs

deliverables

scope_included

scope_excluded

pricing_model

starting_price

third_party_costs

supported_languages

supported_regions

capacity_status

estimated_start

evidence

quality_criteria

human_approval

failure_behavior

version

validity

Bu kayıt yalnız makineler için değildir. Satış, web, teklif, sözleşme ve operasyon ekipleri de aynı kaynağı kullanır. Böylece kurumun farklı yüzeyleri aynı ticari gerçeğe bağlanır.

Uygun olmayan müşteriyi açıkça tanımlamak

Bir hizmetin kimin için uygun olmadığı da kayda geçmelidir.

Örneğin:

• Belirli bütçenin altındaki projeler
• Acil ve gerçekçi olmayan teslim süresi isteyenler
• Gerekli veri erişimini sağlayamayanlar
• İzinsiz yüz veya ses klonlaması talep edenler
• Sahte yorum, manipülatif SEO veya aldatıcı arayüz isteyenler
• İnsan onayını tamamen kaldırmak isteyen yüksek riskli süreçler

Bu dışlamalar yalnız etik değildir. Ajanın yanlış müşteriyle işlem başlatma riskini azaltan seçim sınırlarıdır.

Kapasite durumu

Bir hizmet kalıcı olarak katalogda bulunabilir. Fakat kapasite durumu daha sık değişir.

Bu nedenle ayrı bir kayıt gerekebilir:

service_id

availability_status

accepting_new_work

earliest_start

capacity_band

last_updated

expires_at

Ajan eski kapasite kaydıyla bağlayıcı söz vermemelidir.

Kapasite bilinmiyorsa: “Hizmet sunuluyor; güncel başlangıç tarihi için doğrulama gerekiyor.” demelidir.

4. Yetki Omurgası

Yetki Omurgası, kurumda kimin ve hangi ajanın hangi davranışları gerçekleştirebileceğini gösterir. Bu omurga kurulmadan ajanlara geniş araç erişimi vermek ciddi risk oluşturur.

Yetki Omurgası şu bileşenlerden oluşur:

• İnsan rol haritası
• Ajan yetki haritası
• Veri erişim sınırları
• Finansal sınırlar
• İletişim yetkileri
• Yayın yetkileri
• İnsan onayı eşikleri
• Delegasyon kuralları
• Acil durdurma sorumluluğu
• Süre ve iptal kayıtları

Rol tabanlı yetki tek başına yeterli olmayabilir

Bir kurum: “Satış ajanı satış işlemlerine erişebilir.” diyebilir. Bu çok geniştir.

Satış işlemleri şunları içerebilir:

• Aday araştırma
• Kısa liste
• İlk mesaj taslağı
• Mesaj gönderme
• Görüşme planlama
• Fiyat açıklama
• İndirim verme
• Teklif gönderme
• Sözleşme kabul etme

Hepsi aynı yetki değildir. Yetki davranış türüne göre ayrılmalıdır.

Yetki matrisi

Aşağıdaki tablo, geçerli görev yetkisi ve veri erişim sınırları zaten tanımlanmış bir kurum için örnek bir dağılımdır. “Gerekmez”, bu örnekte her işlem için yeniden onay gerekmediğini anlatır; yetkisiz erişim veya iletişime izin vermez.

Gerçek kurumlarda bu matris daha ayrıntılı olabilir. Önemli olan “ajan erişebiliyor” ile “ajan yetkili” arasındaki farkın görünür olmasıdır.

İnsan Devir Noktaları

Her süreçte insanın devreye gireceği anlar belirlenmelidir.

Buna: İnsan Devir Noktası diyebiliriz.

Örnekler:

• İlk dış iletişim
• Fiyat veya indirim açıklaması
• Bağlayıcı teklif
• Canlı üretim yayını
• Yüksek tutarlı satın alma
• Kişisel veri aktarımı
• Biyometrik içerik üretimi
• Hukukî veya kamuya açık açıklama
• Geri alınamaz işlem

İnsan devir noktası yalnız “risk varsa sor” gibi belirsiz bırakılmamalıdır. Mümkün olduğunca açık olmalıdır.

İnsan onayının içeriği

Ajan onay isterken yalnız: “Devam edeyim mi?” dememelidir.

Şunları göstermelidir:

• Ne yapacak?
• Kimin adına?
• Hangi hedefe?
• Hangi veriyle?
• Ne kadar maliyetle?
• Hangi taahhütle?
• Geri alınabilir mi?
• Hangi belirsizlik devam ediyor?

Bu, insanın gerçek karar vermesini sağlar.

Yetki süreleri

Ajan yetkileri süresiz ve gözden geçirmesiz bırakılmamalıdır.

Şu biçimlerde sınırlandırılabilir:

• Tek görev
• Tek dosya kümesi
• Tek müşteri
• Tek kampanya
• Belirli bütçe
• Belirli tarih aralığı
• Belirli iş saatleri
• Belirli ülke veya kanal

Süre dolduğunda yetki yeniden değerlendirilmelidir.

5. Eylem ve Kanıt Omurgası

Bir ajan davranışı gerçekleştirirken yalnız sonucu üretmemelidir. Neyi, neden ve hangi yetkiyle yaptığını kaydetmelidir.

Bu omurganın temel unsurları şunlardır:

• Eylem kataloğu
• Ön koşullar
• Girdi doğrulaması
• Eylem makbuzu
• Bağımsız doğrulama
• Ölçüm
• Sürüm
• Kanıt saklama

Eylem kataloğu

Kurumun ajanlar tarafından yapılabilecek davranışları açıkça tanımlaması gerekir.

Örneğin:

• Müşteri adayı araştır
• E-posta taslağı oluştur
• Mesaj gönder
• Takvim önerisi hazırla
• Takvim daveti gönder
• Hizmet uygunluğu değerlendir
• Fiyat bilgisi göster
• Teklif taslağı hazırla
• Web içeriğini güncelle
• Canlı yayın yap
• Arama motoru bildirimi gönder
• Performans ölç
• Rapor oluştur

Her eylem için şu bilgiler bulunmalıdır:

• Gerekli girdiler
• Yetki düzeyi
• İnsan onayı
• Risk seviyesi
• Beklenen çıktı
• Başarı kanıtı
• Geri dönüş yöntemi

Bir eylemin tamamlanma koşulu

“Mesaj gönderildi” ancak uygun gönderim kanıtıyla doğrulandığında bir tamamlanma koşulu olabilir. Görevin amacı teslim, yanıt veya görüşme ise gönderim tek başına bu sonuçları kanıtlamaz.

Bir web yayını için tamamlanma koşulu:

• Dosyalar aktarıldı
• Uzak hash eşleşti
• Canlı HTML doğru
• Canonical ve dil bağlantıları geçti
• Mobil ve masaüstü görünüm doğrulandı
• Kritik hata yok
• Geri dönüş paketi mevcut

olabilir.

Bağlayıcı olmayan bir teklif taslağının paylaşılması için:

• Doğru muhatap doğrulandı
• Onaylanan metin gönderildi
• Paylaşılan veri sınırı korundu
• Mesaj kaydı tutuldu
• Bağlayıcı taahhüt oluşmadı

gerekebilir. Tamamlanma koşulu yalnız ajanın yaptığı işlemi değil, gerçek dünya sonucunu da içermelidir.

Eylem Makbuzu

Önemli davranışlardan sonra aşağıdaki gibi bir eylem makbuzu oluşturulabilir. Örnek alanlar, işlemin gerçek kayıtlarına bağlanmalıdır; ajanın kendi yazdığı özet tek başına başarı kanıtı değildir.

action_id

action_type

requested_by

performed_by

target

purpose

authorization

inputs_used

data_shared

started_at

completed_at

technical_result

real_world_verification

human_approval

rollback_status

open_uncertainties

Makbuz kullanıcıya sade biçimde, denetçiye daha ayrıntılı biçimde sunulabilir.

Kanıt hiyerarşisi

Her başarı iddiasının kanıtı aynı güçte değildir.

Örneğin bir web yayını için:

• Komut başarıyla çalıştı.
• Aktarım hizmeti yüklemeyi kabul etti.
• Uzak dosya hash’i eşleşti.
• Canlı HTTPS çıktısı doğrulandı.
• Gerçek tarayıcı sayfayı doğru gösterdi.
• Arama botu erişebildi.
• Arama motoru sayfayı indeksledi.
• Sayfa belirli sorguda görünürlük kazandı.
• Kullanıcı davranışı ve ticari sonuç oluştu.

Bu dokuz gözlem aynı şeyi kanıtlamaz; her zaman aynı sırayla gerçekleşmeleri de gerekmez. Ajan hangi düzeyde bulunduğunu açıkça söylemelidir.

Bildirim kabulü, indekslenme değildir. İndekslenme, sıralama değildir. Sıralama, müşteri değildir. Müşteri talebi, gelir değildir.

Kanıt dilinin bu ayrımı koruması gerekir.

Bağımsız doğrulama ilkesi

Bir işi yapan sistem kendi başarı mesajına tek başına güvenmemelidir. Mümkün olduğunda sonuç, işlemi yapan ajanın beyanından bağımsız bir kayıttan veya gözlemden kontrol edilmelidir. Yalnız farklı bir araç kullanmak, aynı hatalı kaynağa dayanılıyorsa bağımsızlık sağlamaz.

• Yüklemeden sonra dışarıdan indir.
• Üretimden sonra gerçek tarayıcıyla gör.
• Fiyat kaydını görünür sayfa ve katalog arasında karşılaştır.
• E-posta göndermeden önce alıcıyı ve ekleri; gönderimden sonra hizmetin işlem kaydını doğrula.
• Ödeme sonrasında sipariş ve banka kaydını eşleştir.
• Yetki kullanımında geçerli sözleşme sürümünü kaydet.

Bağımsız doğrulama maliyet getirir. Fakat sessiz başarısızlığı azaltır.

6. Toparlanma Omurgası

Ajanlara hazır kurum yalnız başarılı davranışı planlamaz.

Hata hâlinde:

• Kimin durduracağını
• Hangi sistemlerin kapatılacağını
• Son güvenli durumun ne olduğunu
• Hangi verilerin korunacağını
• Kimlerin bilgilendirileceğini
• İtirazın nasıl alınacağını
• Telafinin nasıl yapılacağını

önceden belirler.

Toparlanma Omurgası şu unsurları içerir:

• Olay sınıflandırması
• Güvenli durum
• Acil durdurma
• Kontrol noktaları
• Yedek ve rollback
• Olay günlüğü
• İnsan sorumlusu
• Bildirim
• İtiraz
• Telafi
• Kök neden
• Sözleşme güncellemesi

Ajanı durdurmakla sistemi durdurmak farklıdır

Merkez ajan kapatılabilir.

Fakat:

• Alt ajanlar
• Zamanlanmış görevler
• E-posta kuyrukları
• Harici otomasyonlar
• Abonelikler
• Dosya işlemleri

çalışmaya devam edebilir. Bu nedenle acil durdurma planı, etkilenen eylem zincirinin bütününü kapsamalı; ilgisiz veya durdurulması ayrıca zarar doğuracak sistemler için ayrı karar içermelidir.

Bir ajanı susturmak, başlattığı davranışları durdurmak değildir.

Son güvenli durum

Her kritik sistem için geri dönülebilecek durum veya güvenli durma biçimi önceden tanımlanmalıdır. Web sitesi için doğrulanmış sürüm, fiyat için onaylı katalog, veri için doğrulanmış yedek kullanılabilir. Yetki politikasında eski sürüme dönmek, iptal edilmiş erişimleri yeniden açmamalıdır; güncel yetki ve iptal kayıtları belirleyicidir. Gönderilmiş müşteri mesajları da gönderilmemiş taslaklara dönüştürülemez. Bu durumda kalan gönderimler durdurulur ve düzeltme ya da telafi yolu işletilir. Geri dönüş yolları, güvenli sınırlar içinde düzenli olarak test edilmelidir.

Davranış Sözleşmesi Sicili

Dördüncü bölümden sekizinci bölüme kadar kurduğumuz beş sözleşme, kurum içinde birlikte yönetilmelidir.

Buna: Davranış Sözleşmesi Sicili diyebiliriz.

Sicil şu kayıtları bir araya getirir:

• Kimlik Sözleşmesi
• Yetenek Sözleşmesi
• Uygunluk Sözleşmesi
• Yetki Sözleşmesi
• Geri Dönüş ve Telafi Sözleşmesi

Sicil tek bir dev belge olmak zorunda değildir. Fakat kayıtlar birbirine bağlanmalıdır. Bir hizmet kimliği değiştiğinde uygunluk ve fiyat kayıtları gözden geçirilmelidir. Bir ajan yetkisi değiştiğinde eylem kataloğu güncellenmelidir. Bir olay yaşandığında ilgili sözleşme sürümü bulunabilmelidir.

Davranış sözleşmesi statik değildir

Kurumlar değişir. Hizmetler değişir. Fiyatlar değişir. İnsanlar ayrılır. Yeni ajanlar eklenir. Riskler ortaya çıkar. Bu nedenle davranış sözleşmesi yaşayan bir sistem olmalıdır.

Her değişiklikte:

• Kim değişiklik yaptı?
• Neden?
• Hangi kayıtlar etkilendi?
• Hangi testler çalıştı?
• Hangi sürüm aktif oldu?
• Eski sürüm nasıl arşivlendi?

bilinmelidir.

Sözleşme ile gerçek davranış eşleşmelidir

Bir belgede: “Ajan dışarıya mesaj gönderemez.” yazabilir. Fakat e-posta aracında gönderim yetkisi açıksa sistem fiilen başka davranır.

Bir politikada: “Fiyat insan onayı gerektirir.” denebilir. Fakat web ajanı fiyat kataloğunu doğrudan değiştirebiliyorsa kural yalnız kâğıt üzerindedir.

Bu nedenle iki ayrı dünya karşılaştırılmalıdır:

Beyan edilen yetki

Politikada yazan.

Uygulanabilir yetki

Teknik sistemin gerçekten izin verdiği.

Aradaki farka: Yetki Uygulama Açığı diyebiliriz. Ajanlara hazır kurumda bu açık mümkün olduğunca küçüktür.

Kuralı teknik olarak uygulamak

Yetki, veri erişimi ve işlem sınırları yalnız model talimatına bırakılmamalı; ilgili araç veya hizmet katmanında da uygulanmalıdır.

Örneğin:

• Ajanın ödeme limiti teknik olarak sınırlandırılabilir.
• Canlı yayın insan onayı olmadan engellenebilir.
• Belirli veri alanları ajana hiç gösterilmeyebilir.
• Dış e-posta gönderimi ayrı yetki tokenı gerektirebilir.
• Fiyat kaydı yalnız yetkili rol tarafından değiştirilebilir.
• Yüksek riskli işlem iki ayrı onay isteyebilir.

Talimat önemlidir. Fakat yüksek riskte teknik kontrol daha güvenlidir.

Ajanın “yapmamalıyım” demesiyle, sistemin “yapamazsın” demesi aynı güven düzeyi değildir.

Araçların adı değil, davranışları yönetilmelidir

Bir kurum belirli bir yapay zekâ aracını yasaklayabilir. Fakat çalışan aynı davranışı başka araçla gerçekleştirebilir. Bu nedenle yönetişim yalnız ürün isimlerine dayanırsa hızla eskir.

Daha kalıcı yaklaşım şudur:

• Hangi veri dışarı çıkabilir?
• Hangi eylem otomatik yapılabilir?
• Hangi karar insan onayı gerektirir?
• Hangi çıktılar yayımlanmadan önce doğrulanır?
• Hangi kayıtlar saklanır?
• Hangi sistemler birbirine bağlanabilir?

Araç değişebilir. Davranış ilkesi kalır.

İnsan–ajan görev tasarımı

Ajanlara hazır kurum, işi yalnızca “insan işi” ve “AI işi” olarak ikiye ayırmaz. Süreç içinde görevleri davranış türüne göre dağıtır.

Örneğin:

Ajanın güçlü olduğu alanlar

• Büyük bilgi kümesini taramak
• Tutarsızlık bulmak
• Aday oluşturmak
• Taslak hazırlamak
• Test çalıştırmak
• Tekrarlanan doğrulamayı yürütmek
• Değişiklik envanteri çıkarmak
• Ölçüm kaydı tutmak

İnsanın merkezde olduğu alanlar

• Amaç belirlemek
• Değer ve risk tercihi yapmak
• Fiyat ve hukukî taahhüt vermek
• Yüksek etkili seçimleri onaylamak
• Çelişkili insan çıkarlarını değerlendirmek
• Telafi kararı vermek
• Nihai sorumluluğu üstlenmek

Bu ayrım mutlak değildir. Fakat tasarım için yararlıdır.

İnsan işi yalnız onay vermek değildir

İnsanı yalnız “evet” düğmesine indirgemek yanlış olur.

İnsan:

• neden bu hedefin seçildiğini,
• kimin etkileneceğini,
• hangi ödünleşimin kabul edilebilir olduğunu,
• kurumun neyi temsil etmek istediğini,
• hangi riskin alınabileceğini

belirler. Ajan bu bağlamı tamamen kendi başına yaratmamalıdır.

Ajanın işi yalnız hız değildir

Bir ajan kuruma yalnız daha hızlı işlem getirmez.

Doğru kullanıldığında:

• Tutarlılık
• İzlenebilirlik
• Sürekli denetim
• Diller arasında olgusal tutarlılık
• Tekrarlanabilir kalite
• Erken hata tespiti

sağlayabilir. Ajanın değeri yalnız insan emeğini azaltmakla ölçülmemelidir.

Daha önce insanın düzenli yapamadığı kontrolleri sürekli ve kanıtlı biçimde yapabilmesi de değerdir.

Ajanlara hazır veri

Kurumun verisi ajanlar tarafından kullanılabilir olmalıdır. Fakat “bütün veriyi tek yere topla” yaklaşımı tehlikeli olabilir.

Ajanlara hazır veri:

• Doğru
• Güncel
• Kaynaklı
• Sınıflandırılmış
• Erişim kontrollü
• Amaçla sınırlı
• Gerektiğinde silinebilir
• Kullanım kaydı tutulabilir

olmalıdır.

Veri sınıfları

Kurum veriyi aşağıdaki gibi etiketleyebilir. Bunlar birbirini dışlayan veya mevzuattaki sınıflandırmaların yerini alan kategoriler değildir; aynı veri birden fazla gruba girebilir.

• Kamuya açık
• Kurum içi
• Gizli
• Kişisel
• Hassas
• Hukukî olarak sınırlı
• Ajan kullanımına kapalı

Ajan her veri sınıfında aynı yetkiye sahip olmamalıdır.

Asgari veri ilkesi

Ajan görevi için gereken en az veriyle çalışmalıdır. Müşteri görüşmesi planlamak için bütün finansal geçmişe gerek yoktur. Hizmet uygunluğu değerlendirmek için kişisel kimlik numarası gerekmez. Bir sayfayı düzenlemek için bütün müşteri veritabanına erişmek gerekmez.

Daha fazla veri, her zaman daha iyi davranış değildir. Daha büyük zarar alanı da oluşturabilir.

Veri kökeni

Ajan kullandığı bilginin nereden geldiğini bilmelidir.

• İnsan girişi
• Kanonik şirket kaydı
• Dış kaynak
• Model çıkarımı
• Geçmiş konuşma
• Tahmin
• Ölçüm

aynı güven düzeyinde değildir. Çıkarım, gerçek gibi kaydedilmemelidir. Tahmin, fiyat veya yetki kaydına dönüşmemelidir.

Belirsizlik politikası

Ajanlara hazır kurum, sistemin bilgi eksikliğinde nasıl davranacağını tanımlar.

Ajan:

• Tahmin mi edecek?
• Soru mu soracak?
• Taslak mı hazırlayacak?
• İnsan onayı mı isteyecek?
• Görevi mi durduracak?

Bu davranış risk düzeyine göre değişebilir. Düşük riskli biçimsel bir kararda, açıkça belirtilmiş ve kolayca düzeltilebilen bir varsayım kabul edilebilir. Yüksek riskli fiyat, kimlik, rıza veya ödeme konusunda değildir.

Belirsizlik bütçesi

Her süreçte belirli miktarda belirsizlik bulunabilir. Fakat eylemin gerektirdiği kritik bir koşul doğrulanamıyorsa, başka alanlardaki kesinlik bu eksikliği telafi etmez.

Buna: Belirsizlik Bütçesi diyebiliriz.

Örneğin:

• Görüşme saatinde küçük esneklik olabilir.
• Fakat muhatap kimliği ve paylaşılacak veri belirsiz olmamalıdır.
• Yaklaşık başlangıç tarihi bilinmeyebilir.
• Fakat fiyatın aylık mı yıllık mı olduğu belirsiz kalmamalıdır.

Ajan, hangi belirsizliklerin kabul edilebilir olduğunu bilmelidir.

Değişiklik yönetimi

Ajanların kullandığı gerçeklik değiştiğinde sistem güncellenmelidir.

Bir fiyat değişirse:

• Web sayfası
• Hizmet kataloğu
• FAQ
• Schema
• Teklif şablonu
• Satış ajanı bilgisi

birlikte gözden geçirilmelidir.

Buna: Değişiklik Etki Haritası diyebiliriz. Bir gerçek değiştiğinde hangi yüzeylerin etkileneceği önceden bilinmelidir.

Küçük değişiklik, büyük davranış etkisi

Bir hizmetin adı değişebilir. Bu küçük editoryal değişiklik gibi görünür.

Fakat:

• Ajan eşleştirmesi
• Arama niyeti
• Fiyat kataloğu
• İç bağlantılar
• Ölçüm kohortu
• Kullanıcı beklentisi

etkilenebilir. Ajanlara hazır kurum değişiklikleri yalnız dosya düzeyinde değil, davranış sonucu düzeyinde değerlendirir.

Sürümleme

Her önemli kimlik, yetenek, uygunluk ve yetki kaydı sürümlenmelidir. Ajan eylemi hangi sürüme göre yaptı?

Bir olay olduğunda bu soru kritik olur. Eski sürümün aktif olmadığı açıkça gösterilmeli; gerekli denetim izi, saklama süresi ve erişim sınırları belirlenerek korunmalıdır. Bu, bütün kişisel verilerin süresiz saklanması anlamına gelmez.

Ölçüm olmadan hazır oluş kanıtlanamaz

Bir kurum kendisini ajanlara hazır ilan edebilir. Fakat gerçek davranış test edilmelidir.

Örnek senaryolar:

• Ajan doğru hizmeti seçiyor mu?
• Uygun olmayan müşteriyi reddedebiliyor mu?
• Fiyat belirsizliğinde soru soruyor mu?
• Yetkisiz gönderimi durduruyor mu?
• Eski rolü kullanmayı reddediyor mu?
• Alt ajan üzerinden yetki aşımı yapıyor mu?
• Hata hâlinde güvenli duruma dönüyor mu?
• Eylem makbuzu üretiyor mu?

Bu testler yalnız olumlu senaryolardan oluşmamalıdır. Sistemin “hayır” diyebilmesi de ölçülmelidir.

Olumsuz testler

Ajanlara hazır kurum şu tür denemeler yapmalıdır:

Kullanıcı, görev kapsamını belirsiz bırakırsa ne olur?

Eski fiyat kaydı daha görünürse ajan hangisini seçer?

Yetkisiz çalışan ödeme talimatı verirse?

Bir alt ajan daha geniş erişim isterse?

Rıza kaydı süresi dolmuşsa?

İki hizmetin adı birbirine benziyorsa?

Dış kaynak kanonik kaynağa aykırı bilgi verirse?

Geri dönüş yolu çalışmazsa?

Olumsuz test, sistemi kötü göstermek için değildir. Gerçek dünyaya hazırlamak içindir.

Ajan Hazırlık Borcu

Bir kurum ajanları hızla kullanmaya başlayabilir.

Fakat:

• Kimlik kayıtları dağınık,
• yetenekler belirsiz,
• yetkiler geniş,
• loglar eksik,
• geri dönüş test edilmemiş

olabilir. Teknoloji ilerlerken yönetişim geride kalır.

Buna: Ajan Hazırlık Borcu diyebiliriz. Ajan hazırlık borcu, kurumun ajanlara verdiği eylem gücüyle bu davranışı güvenli, doğru ve denetlenebilir biçimde yönetme kapasitesi arasındaki farktır. Borç büyüdükçe küçük bir hata daha geniş sonuç üretir.

Ajan hazırlık borcunun belirtileri

Bir kurumda şu cümleler sık duyuluyorsa borç olabilir: “Bu ajanın tam olarak neye eriştiğini bilmiyoruz.” “Bazen kendisi gönderiyor, bazen taslak bırakıyor.” “Fiyatı hangi dosyadan aldığı belli değil.” “Eski çalışan hesabı hâlâ bağlı olabilir.” “Bir hata olursa sistemi kapatırız ama nasıl kapandığını hiç denemedik.” “AI yaptı; hangi araç üzerinden yaptığını bilmiyoruz.” “Müşteri verisi modele gitmiş olabilir.” “Aynı görevi iki ajan yapıyor.” “Kimin onayladığı loglarda görünmüyor.” Bu ifadeler tek başına felaket değildir. Fakat borcun işaretidir.

Hazır olmayan kuruma daha fazla ajan eklemek

Bir sorun yaşandığında kurum çözüm olarak yeni ajan ekleyebilir. Satış ajanı hata yapar. Denetim ajanı eklenir. Denetim ajanının raporlarını özetlemek için başka ajan eklenir. Sonra bu ajanları yönetecek merkez ajan kurulur. Ajan sayısı artar. Fakat gerçeklik, yetki ve toparlanma omurgası kurulmazsa karmaşıklık büyür.

Daha fazla ajan, eksik yönetişimin çözümü değildir.

Bazen en doğru adım yeni ajan eklemek değil, mevcut davranış sistemini sadeleştirmektir.

Ajan sayısı değil, davranış bütünlüğü

On ajan kullanan küçük bir kurum, yüz ajan kullanan büyük kurumdan daha hazır olabilir.

Çünkü önemli olan:

• Kaç ajan olduğu değil,
• rollerinin ne kadar açık olduğu,
• ortak gerçeği kullanıp kullanmadıkları,
• yetki zincirinin korunup korunmadığı,
• sonuçların doğrulanıp doğrulanmadığıdır.

Ajanlara hazır kurumun beş seviyesi

Kurumsal hazırlık için bu kitapta beş düzey öneriyorum. Bu ölçek bir belgelendirme veya dış denetim sonucu değildir.

Seviye 1 — Bağlantılı

Ajanlar bazı sistemlere erişebilir. E-posta, dosya, takvim veya web araçları bağlıdır. Fakat yetki ve veri sınırları büyük ölçüde örtüktür.

Seviye 2 — Tanımlı

Ajan rolleri, hizmetler ve temel iş akışları belgelenmiştir. Kimlik ve görevler daha açıktır.

Seviye 3 — Sözleşmeli

Kimlik, yetenek, uygunluk, yetki ve toparlanma sözleşmeleri sürümlü biçimde bulunur.

Seviye 4 — Uygulanan

Teknik sistemler yetki sınırlarını uygular. İnsan onay eşikleri, veri kontrolleri ve eylem makbuzları çalışır.

Seviye 5 — Denetlenebilir ve öğrenen

Kurum gerçek senaryolarla davranışı ölçer. Olaylardan sözleşme güncellemesi çıkarır. Yetkileri düzenli gözden geçirir. Toparlanma tatbikatı yapar. GBO’nun hedefi yalnız birinci düzeyde bağlantı kurmak değildir. Beşinci düzeyde sorumlu davranış üretmektir.

Ajanlara hazır olma yanılgıları

“Web sitemiz çok iyi, hazırız.”

İyi web sitesi kimlik ve yetenek temsilini güçlendirebilir. Fakat yetki, eylem ve toparlanma sistemini tek başına kurmaz.

“Bütün bilgilerimiz bulutta.”

Bilginin erişilebilir olması onun doğru, güncel ve yetkili olduğu anlamına gelmez.

“Model çok güçlü.”

Model gücü, kurumsal sözleşme eksikliğini çözmez.

“İnsan zaten kontrol ediyor.”

İnsan neyi, ne zaman ve hangi bilgiyle kontrol ediyor?

Bu belirsizse onay yalnız tören olabilir.

“Hata olursa kapatırız.”

Nasıl?

Alt ajanlar, zamanlanmış işler ve dış sistemler de duracak mı?

“Ajan yalnız öneri veriyor.”

Öneri, otomatik iş akışında seçim veya eylem girdisine dönüşüyor olabilir.

Ajanlara hazır müşteri yüzeyi

Kurumun dış müşterilere sunduğu yüzey de ajanlara hazır olabilir.

Bir müşteri veya onun ajanı şu bilgilere güvenle ulaşabilmelidir:

• Kurum kimliği
• Hizmet kapsamı
• Fiyatlandırma yöntemi
• Gerekli girdiler
• Uygunluk koşulları
• Destek sınırları
• İnsan iletişim noktası
• Rıza ve veri kullanımı
• İşlem ve iptal yolu
• Güncellik tarihi

Bu bilgiler dağınık ve çelişkiliyse müşteri ajanı yanlış davranabilir.

Ajanlara hazır olmak manipülasyon değildir

Bir kurum kendisini ajanların daha sık seçmesi için yapılandırabilir. Bu kolayca manipülasyona kayabilir. GBO’nun amacı sinyalleri süslemek değildir.

Ajanlara hazır olmak:

• Gerçeği açıklaştırmak,
• sınırları görünür kılmak,
• uygun seçimi kolaylaştırmak,
• yanlış seçimi zorlaştırmak

demektir.

Ajanlara hazır kurum, kendisini her durumda seçilebilir göstermeye çalışmaz. Doğru durumda güvenle seçilebilir hâle gelir.

Kurumsal örnek: Dağınık yapıdan ajanlara hazır yapıya

Kurmaca bir dijital hizmet şirketini düşünelim. Aşağıdaki geçiş, ölçülmüş bir müşteri sonucu değil, uygulama örneğidir.

Başlangıç durumu:

• 40’tan fazla hizmet
• Birkaç dil
• Farklı fiyat biçimleri
• Eski ve yeni sayfalar
• Birden fazla ajan
• E-posta, web, sosyal medya ve müşteri bulma otomasyonları
• Dağınık yetki kayıtları

Şirket yalnızca yeni ajan eklerse risk büyür.

Dönüşüm şu sırayla yapılabilir:

1. Hizmet envanteri

Gerçek hizmetler, fiyatlar ve kapsamlar çıkarılır.

2. Kanonik kayıt

Her hizmet için kapsamı ve fiyatlandırmayı belirleyen onaylı bir ana kayıt oluşturulur.

3. Çok dilli tutarlılık

Diller doğal biçimde yazılır ama aynı gerçeği taşır.

4. Ajan rol ayrımı

Web, e-posta, sosyal medya, SEO/GEO ve müşteri keşfi ajanları ayrılır.

5. Yetki sınırı

Araştırma ile dış iletişim; taslak ile yayın birbirinden ayrılır.

6. Kalite kapıları

Derleme, semantik, gerçek tarayıcı, canlı hash ve performans testleri kurulur.

7. Ölçüm kaydı

Hangi değişikliğin ne zaman yayımlandığı ve neyin ölçüleceği kaydedilir.

8. Stabilizasyon

Sistem sürekli kurcalanmaz; gerçek sonuçların oluşmasına izin verilir. Bu dönüşümün amacı, görünürlük çalışmasının yanında kurumun kendi davranışını daha iyi yönetmesidir. Arama görünürlüğü veya satış artışı ayrıca ölçülmelidir.

İlk doksan gün için pratik yol

Ajanlara hazır hâle gelmek tek günde tamamlanmaz. Aşağıdaki üç aşama örnek bir plandır; süre taahhüdü değildir. Yetki aşımı testleri ve toparlanma tatbikatları, onaylı kapsamda ve gerçek müşterilere zarar vermeyecek koşullarda yürütülmelidir.

İlk 30 gün — Gerçeği toparla

• Ajan envanteri çıkar.
• Kimlik ve hukukî ilişkileri kaydet.
• Hizmet, fiyat ve kapsam çelişkilerini bul.
• Kanonik kaynakları belirle.
• Yüksek riskli erişimleri gözden geçir.
• Eski ve gölge yetkileri kapat.
• Acil durdurma sorumlusunu belirle.

31–60 gün — Davranışı sözleşmeye bağla

• Yetenek ve uygunluk kayıtlarını oluştur.
• Ajan rollerini ayır.
• Yetki matrisini hazırla.
• İnsan devir noktalarını belirle.
• Eylem makbuzu tasarla.
• Görünür ve makinece okunabilir kayıtları eşleştir.
• Geri dönüş ve itiraz süreçlerini yaz.

61–90 gün — Test et ve sınırları uygula

• Olumlu ve olumsuz senaryolar çalıştır.
• Yetki aşımı denemeleri yap.
• Alt ajan devirlerini test et.
• Toparlanma tatbikatı yap.
• Gerçek kullanıcılarla açıklanabilirlik ve onay testleri yap.
• Eksik sözleşmeleri güncelle.
• Sınırlı üretim ortamında gözlemle.

Bu süre her kurum için farklı olabilir. Önemli olan teknoloji kurulumundan önce ve onunla birlikte yönetişim omurgasının kurulmasıdır.

NOMOS Ajanlara Hazır Kurum Sözleşmesi

Bu bölümün merkezî çıktısı: NOMOS Ajanlara Hazır Kurum Sözleşmesi olacaktır.

Kanonik tanımı şöyledir:

NOMOS Ajanlara Hazır Kurum Sözleşmesi; bir kurumun kimliklerini, kanonik gerçeklerini, hizmet ve yeteneklerini, uygunluk koşullarını, insan ve ajan yetkilerini, veri sınırlarını, eylem yollarını, doğrulama yöntemlerini, olay sorumluluğunu, geri dönüş ve telafi mekanizmalarını insanlara ve makinelere tutarlı biçimde sunan sürümlü kurumsal davranış sistemidir.

Daha basit biçimiyle: Bu sözleşme, kurumun ajanlara yalnızca kapı açmasını değil, hangi kapının ne zaman ve hangi yetkiyle açılacağını bilmesini sağlar.

Ajanlara Hazır Kurum Kapısı

Bir kurum yüksek etkili ajan eylemlerine başlamadan önce şu kapılardan geçmelidir:

1. Gerçeklik Kapısı

Kanonik bilgiler, sahipleri ve sürümleri belli mi?

2. Kimlik Kapısı

Marka, hukukî yapı, insan ve ajan kimlikleri doğru bağlandı mı?

3. Yetenek Kapısı

Gerçek hizmetler, girdiler, kapsam ve kanıtlar açık mı?

4. Uygunluk Kapısı

Kimin ve hangi durumun doğru eşleşme olduğu tanımlı mı?

5. Yetki Kapısı

İnsan ve ajan davranış sınırları uygulanabilir biçimde belirli mi?

6. Veri Kapısı

Ajan hangi veriyi hangi amaçla kullanabilir?

7. Eylem Kapısı

İşlem yolları, tamamlanma koşulları ve makbuzlar tanımlı mı?

8. Doğrulama Kapısı

Ajan kendi başarı beyanından bağımsız olarak kontrol ediliyor mu?

9. Toparlanma Kapısı

Durdurma, geri dönüş, itiraz ve telafi mekanizmaları çalışıyor mu?

10. İnsan Sorumluluğu Kapısı

Her kritik davranışın gerçek bir insan sorumlusu var mı?

Bu koşulların birlikte değerlendirilmesini gösteren kavramsal ifade şöyledir; sayısal bir güvenlik hesabı değildir:

AJANLARA HAZIR KURUM =

KANONİK GERÇEK

VE DOĞRU KİMLİK

VE AÇIK YETENEK

VE DOĞRULANMIŞ UYGUNLUK

VE UYGULANAN YETKİ

VE SINIRLI VERİ

VE KAYITLI EYLEM

VE BAĞIMSIZ DOĞRULAMA

VE TEST EDİLMİŞ TOPARLANMA

VE İNSAN SORUMLULUĞU

Bir eksiklik bütün ajan kullanımını durdurmak zorunda değildir. Ancak ilgili eylemin kritik koşulu eksikse o eylem yapılmamalıdır; mümkünse yetkili ve daha düşük riskli bir göreve geçilir. İnsan onayı, yasak veya yetkisiz bir işlemi kendiliğinden meşru hâle getirmez.

Örneğin:

• Yalnız araştırma
• Yalnız öneri
• Yalnız taslak
• Test ortamı
• İnsan onaylı yürütme

ile sınırlandırılabilir.

Ajanlara hazır oluş puan değil, yetki seviyesidir

Bir kurum yüzde 80 hazır olduğunu söyleyebilir.

Fakat eksik yüzde 20:

• ödeme yetkisi,
• biyometrik rıza,
• veri geri dönüşü,
• hukukî kimlik

gibi kritik alanlardaysa yüksek etkili ajan davranışı yine güvenli değildir. Bu nedenle genel puan yararlı olsa bile tek başına karar vermemelidir.

Kritik kapı geçilmeden toplam puan eylem hakkı üretmez.

Kurum hangi noktada ajanı serbest bırakabilir?

Ajanın daha bağımsız çalışması şu koşullarda mümkündür:

• Amaç açık
• Gerçeklik kanonik
• Yetki sınırları teknik olarak uygulanmış
• Eylem geri alınabilir
• Başarı bağımsız doğrulanabilir
• Olay sahibi belli
• İnsan devir noktaları tanımlı
• Ajan geçmişte benzer görevlerde güvenilir performans göstermiş
• Görev yüksek riskli değil

Bu koşullar güçlendikçe insanın her küçük adımı onaylaması gerekmez.

İyi yönetişim bazı adımlarda zaman gerektirir; buna karşılık sınırları önceden doğrulanmış görevlerde tekrar tekrar onay istemeden ilerlemeyi mümkün kılabilir.

Ajanlara hazır kurumun ticari değeri

Bu dönüşüm yalnız güvenlik için değildir.

Beklenen ticari faydalar şunlardır; gerçekleşip gerçekleşmedikleri başlangıç ölçümleriyle karşılaştırılmalıdır:

• Hizmetler daha anlaşılır olur.
• Yanlış müşteri talepleri azalır.
• Satış görüşmeleri hızlanır.
• Fiyat ve kapsam anlaşmazlıkları düşer.
• Farklı dillerde aynı gerçek korunur.
• Çalışan ve ajan devirleri kolaylaşır.
• Hatalar daha erken yakalanır.
• Müşteri güveni artar.
• Daha fazla süreç kontrollü biçimde otomatikleşir.
• Kurumsal bilgi kişilerden bağımsızlaşır.

Ajanlara hazır oluş, yalnız gelecekteki teknolojiye hazırlanmak değildir. Bugünkü kurumsal dağınıklığı azaltmaktır.

İnsanlara hazır olmayan kurum ajanlara da hazır değildir

Bir şirketin hizmetini insan çalışanlar bile farklı anlatıyorsa ajanların doğru anlatması beklenemez. Çalışanlar kimin hangi yetkiye sahip olduğunu bilmiyorsa ajanların bilmesi beklenemez. Müşteri itiraz edecek insan bulamıyorsa AI itiraz sistemi gerçek olmayacaktır. Bu nedenle ajanlara hazır oluş çoğu zaman önce insanlara karşı daha açık kurum olmak anlamına gelir.

Makine için açıklık, insana karşı açıklığın yerine geçmez. Onu gerektirir.

Ajanlara hazır kurum için yirmi beş denetim sorusu

• Kurumun kanonik kimliği nedir?
• Marka ile hukukî işletici ilişkisi açık mıdır?
• Bütün aktif ajanlar envanterde bulunuyor mu?
• Her ajanın insan sorumlusu belli mi?
• Ajanların bağlı olduğu sistemler ve veriler biliniyor mu?
• Her önemli bilgi türünün kanonik kaynağı var mı?
• Fiyat, kapsam ve hizmet kayıtları birbirleriyle uyumlu mu?
• Eski veya iptal edilmiş kayıtlar ayrılmış mı?
• Her hizmetin gerçek sonucu ve girdileri açık mı?
• Dâhil ve hariç kapsamlar görünür mü?
• Uygun ve uygun olmayan müşteri koşulları tanımlı mı?
• Kapasite ve müsaitlik güncel mi?
• İnsan ve ajan yetkileri davranış türüne göre ayrılmış mı?
• Taslak, gönderim, yayın ve taahhüt ayrı yetkiler mi?
• İnsan devir noktaları belli mi?
• Yetki sınırları teknik olarak uygulanıyor mu?
• Ajan yalnız gerekli veriye erişiyor mu?
• Belirsizlikte nasıl davranacağı tanımlı mı?
• Her önemli eylem makbuz üretiyor mu?
• Teknik başarı gerçek dünya sonucundan ayrılıyor mu?
• Bağımsız doğrulama bulunuyor mu?
• Son güvenli durum ve geri dönüş yolu var mı?
• Alt ajanlar ve zamanlanmış işler birlikte durdurulabilir mi?
• İnsanların itiraz ve telafi yolu açık mı?
• Olaylardan sonra davranış sözleşmesi gözden geçiriliyor ve gerektiğinde güncelleniyor mu?

Bu soruların çoğuna cevap verilemiyorsa kurumun ajan hazırlık borcu yüksektir.

Bölümün hükmü

Ajanlara hazır olmak, bir yapay zekâ sistemini şirkete bağlamak değildir.

Ajanlara hazır olmak:

Kurumun gerçeğini toparlamak, kimlik ilişkilerini çözmek, yetenekleri ve sınırları açıklamak, doğru eşleşme koşullarını göstermek, insan ve ajan yetkilerini ayırmak, veriyi amaçla sınırlamak, eylemleri kaydetmek, başarıyı bağımsız doğrulamak, hata hâlinde durmak ve toparlanmak

demektir. Bir kurum bunu yapmadan güçlü ajanlara geniş yetki verirse mevcut karmaşayı hızlandırabilir.

Doğru kurum düzeni olmadan ajan:

• yanlış fiyatı daha hızlı yayabilir,
• yanlış müşteriyi daha hızlı seçebilir,
• yetkisiz mesajı daha profesyonel yazabilir,
• çelişkili bilgiyi altı dile daha tutarlı çevirebilir,
• hatalı kararı birçok sisteme aynı anda aktarabilir.

Ajan gücü tek başına olgunluk değildir.

Kurumsal olgunluk, ajanın ne kadar çok şey yapabildiğiyle değil; neyi, ne zaman, hangi yetkiyle ve hangi kanıtla yapabildiğinin bilinmesiyle ölçülür.

Ajanlara hazır kurum insanı ortadan kaldırmaz. İnsanın rolünü daha açık hâle getirir. İnsan amacı belirler. Değerleri ve risk sınırını tanımlar. Ajan araştırır, üretir, test eder ve sınırlar içinde hareket eder. Kritik eşikte insan yeniden devreye girer. Hata olduğunda sorumluluk kaybolmaz. Makine eylemi kayıtlıdır. İnsan itiraz edebilir. Sistem geri dönüşün mümkün olduğu yerde geri döner; diğer durumlarda durdurma ve telafi yolunu işletir.

Bu nedenle ajanlara hazır kurumun gerçek tanımı şudur: Makinelerin daha çok çalıştığı kurum değil; insan ve makinelerin sorumlulukları karışmadan birlikte davranabildiği kurum.

Fakat kurum ne kadar iyi hazırlanırsa hazırlansın, bir sonraki soru hâlâ açıktır:

Bu sistemin gerçekten doğru davranıp davranmadığını nasıl ölçeceğiz?

Bir ajanın markayı kaç kez seçtiği yeterli değildir. Kaç işlemi tamamladığı da yeterli değildir. Hız, sayı ve otomasyon tek başına kaliteyi göstermez. Bir sonraki bölümde GBO’nun ölçüm sistemine geçeceğiz.

Nitelikli eylemi nasıl ölçeceğiz?

Çünkü iyi davranış:

• yalnız eylem değildir,
• yalnız başarı değildir,
• yalnız kullanıcı memnuniyeti değildir.

İyi davranış, doğru koşullarda doğru seçimin; geçerli yetki, yeterli kanıt, güvenli yürütme ve sorumlu toparlanmayla birleşmesidir.

Ölçmediğimiz davranışı yönetemeyiz. Yanlış ölçtüğümüz davranışı ise daha tehlikeli biçimde büyütebiliriz.