AI ajanı güvenlik kontrol listesi

1. Amaç ve sınır açık mı?

Ajanın amacını kullanıcı ve iş sonucu ile yazın. “Destek mesajlarını daha iyi yönetir” belirsizdir. “Onaylı politika metninden gelen destek talebini etiketler ve temsilciye taslak verir; müşteri adına yanıt göndermez” net bir sınırdır. Bu cümle, test senaryosunu ve yetki tasarımını belirler.

Belgenin ikinci satırına yasak eylemleri ekleyin. Para hareketi başlatmaz, erişim vermez, fiyat değiştirmez, müşteri verisini dışa aktarmaya yetkili değildir gibi sınırlar kullanılabilir. Sınırların açık olması, ekibin “araç yapabiliyorsa yapsın” varsayımını engeller.

2. Veri envanteri var mı?

Ajan hangi veriyi okur, yazar, iletir veya loglar? Her veri türünü sınıflandırın: genel içerik, kurum içi bilgi, müşteri verisi, finans/ödeme bilgisi, sözleşme, sağlık/güvenlik veya hassas kişisel veri. Verinin kaynağını, sahibini, saklama kuralını ve kimlerin erişebileceğini yazın. Bilinmeyen veri türü, güvenlik kararı verilemeyen veri türüdür.

Testte gerçek müşteri verisi yerine maskelenmiş veya örnek veri kullanın. Ajanın hata mesajı, bildirim veya günlükte gereksiz ayrıntı göstermediğini kontrol edin. Veri işleme ve dış hizmet kullanımı için güncel resmi koşullar ile kurumunuzun politika ve onay süreçlerini değerlendirin.

3. Onaylı bilgi kaynağı tanımlı mı?

Ajanın verdiği önerinin hangi belgeye dayandığı belli olmalıdır. Eski teslimat politikası, çelişkili ürün bilgisi veya sahibi olmayan prosedür, ajanın yanlış fakat ikna edici sonuç üretmesine yol açar. Her kaynak için sahibi, son güncelleme tarihi ve geçerlilik sınırı bulunsun. Kaynak dışı konu geldiğinde ajan kesin yanıt vermek yerine soru sormalı veya insan kuyruğuna yönlendirmelidir.

Kaynak değiştiğinde ajanın davranışı da test edilmelidir. Yeni kampanya koşulu, güncellenen iade politikası veya kaldırılmış ürün bilgisi doğru yansıyor mu? Bilgi tabanı bakımı, ajanın yaşam döngüsünün parçasıdır.

4. En az yetki uygulanıyor mu?

Ajanın her bağlantısı için gerçekten gereken en dar erişim kapsamını kullanın. Sadece arama yapacak ajan yazma izni istememeli; yalnızca belirli kayıtları okuyacak akış tüm müşteri verisine erişmemelidir. Bağlantı hesabı kurum adına olmalı, sahibi ve yedek sorumlusu bilinmelidir. Kişisel çalışanın hesabına bağlı erişim, rol değişiminde kırılganlık yaratır.

Erişim listesi düzenli gözden geçirilmeli; çalışan ayrıldığında, görev değiştiğinde veya proje durduğunda kaldırılmalıdır. Erişim anahtarının yenileme, iptal ve acil durum süreci yazılı olsun.

5. İnsan onayı doğru yerde mi?

İnsan onayı, etki seviyesine göre kurgulanmalıdır. Yeşil işler; etiketleme, iç özet, görev taslağı gibi düşük riskli işlemler olabilir. Sarı işler; müşteri yanıt taslağı, ürün metni, rapor yorumu gibi ikinci göz gerektiren işlerdir. Kırmızı işler; ödeme, fiyat, erişim, kişisel veri paylaşımı, resmî taahhüt ve yüksek etkili kararları kapsar; açık yetkili onayı olmadan tamamlanmamalıdır.

Onay veren kişi, öneri yanında kaynak, etkilenen kayıt, güven/ belirsizlik notu ve geri alma yolunu görmelidir. Bağlamı olmayan onay, gerçek kontrol değildir. İnsan kararını hızlandırmak için gerekli bilgiyi aynı yerde sunun.

6. Girdi kötü niyetli veya belirsiz olduğunda ne oluyor?

Ajan, kullanıcıdan veya başka sistemden gelen metni güvenilir talimat olarak varsaymamalıdır. Belirsiz, çelişkili, alakasız veya yetki dışı isteklerde işlem yapmaması gerekir. Test setine yanlış rol talebi, farklı kaynaktan çelişen bilgi, gereksiz veri isteme ve talimatı değiştirmeye çalışan mesajlar ekleyin. Beklenen davranışı yazın: dur, soru sor, kaynakla sınırla veya insana aktar.

Bu test yalnızca kötü niyet için değil, günlük iletişimdeki belirsizlik için gereklidir. Kullanıcı “müşteriye indirim yap” dediğinde hangi müşteriyi, hangi koşulla, kim onaylayacak? Ajanın belirsizliği görünür kılması, yanlış eylem yapmasından daha güvenlidir.

7. Hata ve tekrar deneme güvenli mi?

Bağlantı kesintisi, eksik alan, hedef sistem hatası veya aynı olayın iki kez gelmesi beklenen durumlardır. Ajan ya da otomasyon hata olduğunda neyi yapmadığını, neyi tamamladığını ve kime bildirim gönderdiğini kaydetmelidir. Körlemesine tekrar deneme, ikinci e-posta, ikinci kayıt veya ikinci ödeme gibi sorun yaratabilir.

Her kritik eylem için olay kimliği, hedef kayıt kimliği ve yeniden deneme davranışı belirlenmelidir. Mükerrerlik şüphesinde işlem insan incelemesine düşebilir. Hata mesajı; olay, kaynak, sonuç ve önerilen aksiyonu içermelidir.

8. Loglar yararlı ama gereğinden fazla mı değil?

Günlükler hata araştırmak ve denetim için önemlidir. Ancak müşteri bilgisini, erişim anahtarını veya gereksiz konuşma ayrıntısını loglamak yeni bir risk yaratır. Hangi olayların kaydedileceğini, kimin göreceğini, ne kadar süre tutulacağını ve silme sürecini belirleyin. Logları düzenli örneklemle inceleyin; yalnızca sorun çıktığında bakmayın.

İyi log, ajanın verdiği kararı yeniden anlamaya yetecek bağlamı taşır; hassas bilgiyi çoğaltmaz. Bu denge kurumun veri sınıfına göre değerlendirilmelidir.

9. Test ortamı üretimden ayrıldı mı?

Yeni kuralı veya bağlantıyı önce test verisiyle deneyin. Test ile üretim hesaplarını, erişim anahtarlarını ve bildirim kanallarını ayırın. Yanlışlıkla gerçek müşteriye mesaj göndermeyecek, canlı kaydı değiştirmeyecek bir ortam oluşturun. Küçük pilotta bile bu ayrım, geri dönüş maliyetini ciddi biçimde düşürür.

Test senaryolarında normal yol, boş veri, yanlış biçim, çelişkili kaynak, yetkisiz istek, ağ hatası ve mükerrer olay bulunmalıdır. Her senaryonun beklenen sonucu kaydedilmeli; sistem değiştikçe tekrar çalıştırılmalıdır.

10. Geri alma ve acil durdurma yolu var mı?

Bir ajan yanlış çıktı ürettiğinde veya kötü davranmaya başladığında kimin sistemi durduracağı, hangi erişimi iptal edeceği ve hangi kayıtların inceleneceği belli olmalıdır. Acil durdurma mekanizması sadece teknik ekipte değil, süreç sahibinde de görünür olmalıdır. Bir hata meydana gelmeden önce kısa tatbikat yapmak, gerçek olayda panik riskini azaltır.

Geri alma her zaman veriyi silmek değildir. Yanlış oluşturulan görevleri işaretlemek, müşteriye giden hatalı mesajı takip etmek, önceki sürüme dönmek veya insan incelemesi başlatmak farklı senaryolardır. Projeye uygun yolu yazın.

11. Sahip ve bakım ritmi belli mi?

Her ajan için iş sahibi, teknik/operasyonel sorumlu, bilgi kaynağı sahibi ve gözden geçirme tarihi olsun. Aracı kuran kişi ayrıldığında ya da kaynak değiştiğinde sistem sahipsiz kalmamalıdır. Ayda bir hata, erişim, kaynak güncelliği ve kullanım metriği kontrolü yapın. Yüksek riskli akışlarda daha sık inceleme gerekebilir.

Bakım notunda “ne değişti, neden değişti, hangi test tekrarlandı?” bilgisi yer alsın. Bu kayıt, hata anında ekip hafızasının yerine geçer.

12. Başarı ve zarar sinyali tanımlı mı?

Başarı; daha çok mesaj göndermek, daha fazla kayıt işlemek veya daha uzun özet üretmek değildir. Doğru yönlendirme, ilk kabul edilebilir taslak, insan müdahalesi süresi ve kritik hata oranı daha anlamlıdır. Aynı zamanda zarar sinyali belirleyin: müşteri tekrar iletişimi arttı mı, yanlış kuyruğa giden talep var mı, kaynak dışı iddia oluştu mu, erişim ihlali mi görüldü?

Bu sinyaller bir eşiği geçtiğinde genişlemeyi durdurun ve temel nedeni inceleyin. Güvenli sistem, sorunları saklamaz; erken görünür hale getirir.

Sonuç: güvenlik, ajanın yetenek sınırını tasarlamaktır

AI ajanı güvenliği; aracı korkudan kapatmak değil, doğru işi doğru yetkiyle ve doğru insan kontrolüyle yaptırmaktır. Amaç, veri, kaynak, yetki, hata, log, test, geri alma ve bakım başlıklarını yayından önce görünür yapın. Bu kontrol listesi, otomasyonun hızını korurken müşteriyi, ekibi ve işletmeyi gereksiz riskten korur.

Yayın öncesi uygulama denetimi

Kontrol listesini bir kez doldurup arşivlemeyin. Seçilen akışı test verisiyle tekrar çalıştırın, yetki ve hata davranışını ikinci sorumlu ile gözden geçirin. Farklı kişiler ajanın ne yapabildiğini aynı biçimde açıklayamıyorsa, amaç veya sınır yeterince net değildir.

Her ay küçük bir örneklem seçip kaynak, erişim, log ve insan onayı davranışını yeniden inceleyin. Yeni veri türü, ekip rolü veya bağlantı yeni kontrol ihtiyacı yaratabilir. Bulgunun yanında sorumlu kişi ve sonraki gözden geçirme tarihi olsun. Böylece güvenlik standardı yalnızca yayına alma gününde değil günlük işte de korunur.

Periyodik kontrolü işin parçası yapın

Bir ajan güvenlik kontrol listesi, yalnızca ilk kurulumda doldurulacak bir form değildir. Ekip değiştiğinde, yeni entegrasyon eklendiğinde veya ajan yeni bir görev üstlendiğinde izin varsayımları bozulabilir. Her ay süreç sahibiyle kısa bir gözden geçirme yapın: artık kullanılmayan bağlantıları kapatın, servis hesabının kapsamını yeniden daraltın ve en yüksek etkili aksiyonun onay kaydından birkaç örneği inceleyin. Bir hata yaşanmamış olması kontrolün gereksiz olduğunu göstermez; çoğu risk, düşük hacimde görünmeden birikir. Sonuçta hangi erişimin neden açık kaldığını, kimin sahip olduğunu ve ne zaman yeniden gözden geçirileceğini yazılı bırakın. Gözden geçirme sonucunu ayrıca tarih, sorumlu ve sonraki kontrol adımıyla paylaşın. Aynı kayıt, denetimde kararın izlenebilirliğini ve ekibin ortak hafızasını korur.