AI agent yayınlama checklist — production'a alma 12 maddesi
Adım adım
- 01
Görev kapsamı netleştirildi
Yayına almadan önce agent'ın ne yapacağı, ne yapmayacağı tek cümleyle yazılı olmalı. 'Agent her gün X klasöründeki yeni faturaları okur, metadata çıkarır, Y tablosuna düşürür; mali onay vermez, mail göndermez' gibi sınırı olan tanım. Üst yönetim veya proje sahibi bu cümleyi okuyup imzalamış olmalı. Belirsiz tanım — 'fatura işlerine bakar' — yayında kullanıcının kafasında karışıklık yaratır; kullanıcı agent'tan beklediği işi alamadığında geri çeker.
Doğrulama:Tek paragraflık görev tanımı imzalı kayıt altında mı?
- 02
Veri ikametgâhı kararı verildi
Agent'ın gördüğü veri yerel mi kalacak, bulutta mı işlenecek, hibrit mi? KVKK çerçevesinde her şirket kendi veri sınıflandırmasına göre karar verir. Tipik üç desen: tam yerel (özel nitelikli veri, KVKK §6), hibrit (agregat bulut + ham veri yerel), tam bulut (genel veri, kamuya açık bilgi). Karar yazılı olmalı; ileride denetimde 'şu veri neden bulutta?' sorusu çıktığında dayanak olur. Tezgah'ın pod ayarı bu kararı uygular: yerel inference zorunlu mu, hangi connector'e bulut çağrısı izinli.
Doğrulama:Veri ikametgâh kararı dokümante mi?
- 03
Tool listesi onaylandı
Agent'ın production'da kullanabileceği tool'lar tek tek listelenmeli ve her birinin risk seviyesi onaylanmış olmalı. Liste gözden geçirilmemiş tool'la production'a çıkmak güvenlik açığı; agent ileride o tool'u beklenmedik şekilde çağırabilir. PolicyEngine'in dışında bir tool olmamalı. Eklendi-çıkarıldı tablosu version control'de tutulur; tool eklemek için yeni release sürümü çıkar.
Doğrulama:Tool listesi version control'de imzalı mı?
- 04
PolicyEngine kuralları yazıldı
Agent'ın hangi tool'u hangi koşulda otomatik geçeceği, hangisinde kullanıcı onayına basacağı, hangisinde biyometrik isteyeceği — kural seti DSL ile yazılmış olmalı. PolicyEngine kuralları sadece görsel onay düğmeleri değil; kod gibi version'lanır, test edilir, review'dan geçer. Üretimde hangi kural gerçekten uygulandığı her çağrı sonunda audit chain'e damgalanır; sonradan 'agent bu çağrıda hangi kuralı tetiklendi' sorusu cevaplanabilir.
Doğrulama:DSL kuralları version control'de + örnek input'la test edildi mi?
- 05
Düşük/orta/yüksek risk eşikleri belirlendi
Risk seviyeleri sayısal eşiklerle desteklenmeli: 'tutar 50.000 TL altı orta, üzeri yüksek', 'eki 5MB altı orta, üzeri yüksek', 'tek seferde 10'dan fazla mail toplu sayılır biyometrik'. Eşiklerin nedeni dokümante edilmeli; rakam keyfi seçilmiş olmamalı, olası en kötü senaryonun ölçüsünden çıkarılmış olmalı. Üretim akışında eşiklerin gerçekçi olduğu ilk hafta gözlemle kontrol edilir; çok dar eşikler kullanıcıyı yorar, çok geniş eşikler güvenliği zayıflatır.
Doğrulama:Eşik tablosu + dayanak yazılı mı?
- 06
İlk hafta onay/red metrikleri toplandı
Yayına almadan önce yetiştirme aşamasında en az bir hafta veri toplanmış olmalı. Onay sayısı, red sayısı, biyometrik tetik sayısı, ortalama yanıt süresi, kullanıcının düzelttiği taslak oranı. Bu metrikler sağlıklı seyirde mi gözden geçirilir. Red oranı haftalar boyunca azalmıyorsa agent yetiştirilmemiş demektir; yayına almak erken. Bayesian profil yakınsamasının sayısal kanıtı bu metriklerde görünür.
Doğrulama:Bir haftalık metrik raporu hazır mı?
- 07
Red team testi geçildi
Agent yayın öncesi 200+ saldırı senaryosuna tabi tutulur: prompt injection (sistem promptu override), indirect injection (kullanıcı belgesi içinde gizli komut), tool misuse (yetkisiz tool çağrısı), data exfiltration (PII sızdırma denemeleri), jailbreak (safety guardrail aşma), cost abuse (sonsuz döngü). Tezgah'ın red team runner'ı saldırıları otomatik çalıştırır, agent'ın blok oranını ölçer. Critical kategoride %100 blok, high'ta %95+, medium'da %85+ eşiği geçilmeden yayın olmaz.
Doğrulama:Red team raporu yeşilse veya bilinen failler dokümante mi?
- 08
Audit chain bütünlüğü doğrulandı
Agent'ın yetiştirme süresince ürettiği audit kayıtları SHA-256 hash zinciriyle imzalı. Yayın öncesi `verify_chain` komutu çalıştırılır; zincirin başından sonuna kadar her satırın imzası doğru, parent hash'leri tutarlı, kopukluk yok. Bu kontrol denetimde 'agent yetiştirme süresi boyunca ne yaptı' sorusunu cevaplar. Zincir kopuksa nedeni araştırılmadan yayın olmaz; kopukluk diskte tahribat ya da kötü niyetli müdahale işareti.
Doğrulama:verify_chain komutu PASS döndürdü mü?
- 09
KVKK uyum kontrolü tamam
Veri sorumlusu açısından üç sorunun cevabı yazılı: agent hangi kişisel veriye dokunuyor, dokunma gerekçesi (KVKK §5/6), saklama süresi ne ve silme prosedürü kim tetikler. Veri sorumlusu (genelde şirket bilgi güvenliği veya KVKK görevlisi) checklist'i imzalar. Aydınlatma metni güncellenmiş, varsa veri ihlal bildirimi prosedürü hazır. Üçüncü taraf (bulut eğitmen sağlayıcı) ile veri işleyici sözleşmesi mevcut. Bu kontrol bir kerelik değil; agent'ın görev kapsamı değişince yenilenir.
Doğrulama:KVKK uyum dokümanı imzalı mı?
- 10
Sertifika alındı
Tezgah agent'ın yukarıdaki kontrolleri geçtiğini gören Ilura sertifikası üretir — P-256 ECDSA imzalı bir kayıt. Sertifika agent'ın versiyon hash'ini, yayın tarihini, red team skor özetini, KVKK kontrol referansını içerir. Bu sertifika agent'ın bir nevi kimlik kartı; production çağrılarında her başlığa damgalanır. Sertifika alınmamış agent yayına alınamaz; cloud runtime imzasız agent'ı çalıştırmayı reddeder. Sertifika her yeni versiyonda yenilenir.
Doğrulama:Sertifika hash'i kayıtta mı?
- 11
Rollback senaryosu denendi
Yayında bir şey ters giderse — agent yanlış davranıyor, kullanıcı şikayet ediyor, audit chain anomalisi var — geri dönmek için plan ne? Tezgah'ın version history'si önceki versiyona rollback eder. Ama prosedürü kullanmadan önce test edilmiş olmalı. Yayın öncesi staging ortamında bir rollback senaryosu çalıştırılır: 'şu versiyona geri dön' komutu verilir, sistem kabul eder, eski davranış gelir. Bu prova üretimde panik anında gereksiz hata yapmayı engeller. Rollback prosedürü yazılı, kim tetikleyecek kim onaylayacak belli.
Doğrulama:Staging'de rollback denemesi geçti mi?
- 12
Yayın versiyonu commit edildi
Agent'ın yayına çıkan halinin tam tanımı (purpose + tools + rules + memory snapshot + voice profile + Bayesian profile + LoRA adapter referansı) tek bir versiyon hash'inde dondurulur. Bu hash agent'ın 'doğum belgesi'. İleride her production çağrısı bu hash'i referans alır; yeni versiyon çıkarılana kadar değişmez. Versiyon mesajı Türkçe + kısa: 'Cloud'a yayınlandı — fatura okuma agent'ı, ilk production sürüm'. Yayın tarihi + commit hash'i bilinmesi gereken her dokümana gider — kullanıcı kılavuzu, KVKK ekleri, denetim defteri.
Doğrulama:Versiyon hash'i + commit mesajı kayıtta mı?
Kısa cevap
Agent’ı yayına almak 12 maddelik bir kontrol listesi: görev kapsamı yazılı, veri ikametgâhı kararı net, tool listesi imzalı, PolicyEngine kuralları version’lanmış, risk eşikleri rakamlı, ilk hafta metrikleri toplanmış, red team testi geçilmiş, audit chain bütünlüğü doğrulanmış, KVKK uyum kontrolü tamam, sertifika alınmış, rollback denenmiş, yayın versiyonu commit’lenmiş. Her madde tek başına basit; toplamı agent’ın production’a güvenli geçişini sağlıyor. 12’den biri eksik kalırsa yayın ertelenir; tamamı yeşilse yayın komutu verilir, agent bulut runtime’ında çalışmaya başlar.
Adım adım
Checklist
- Görev kapsamı netleştirildi
- Veri ikametgâhı kararı verildi
- Tool listesi onaylandı
- PolicyEngine kuralları yazıldı
- Risk eşikleri belirlendi
- İlk hafta onay/red metrikleri toplandı
- Red team testi geçildi
- Audit chain bütünlüğü doğrulandı
- KVKK uyum kontrolü tamam
- Sertifika alındı
- Rollback senaryosu denendi
- Yayın versiyonu commit edildi
Sık karşılaşılan hatalar
Yayına alma sırasında dört kritik hata öne çıkıyor.
Sırayı bozmak. Checklist sırası rastgele değil; her madde bir öncekine dayanır. Örneğin red team testi PolicyEngine kuralları yazılmadan çalıştırılırsa testin sonucu güvenilmez — agent kuralı bilmediği için zaten saldırıya açıktır. Sırayı atlamak yerine eksik maddeyi tamamlayıp dönmek mantıklı; checklist’in 12’sini sırayla geçmek ortalama 1-3 hafta alır.
Audit chain doğrulamasını atlamak. “Sayılar tuttu, sertifika geldi, hadi yayına” deyip audit chain bütünlüğünü kontrol etmemek. Chain’de bir kopukluk varsa — diskte hata, kötü niyetli müdahale, yedekleme bug’ı — yayın sonrası fark edilir ve geri dönüş zor olur. verify_chain komutu birkaç dakika sürer; atlamak risk almak demek.
Rollback’i provasız yayınlamak. “Eğer bir şey olursa rollback yaparız” demek prosedür değil. Prosedür yayın öncesi staging’de denenmiş, kim tetikleyeceği belli, ne kadar sürede tamamlandığı ölçülü olmalı. Üretimde panik anında ilk kez denemek hata yapma olasılığını yükseltir; provasız rollback başka bir kriz kaynağı olabilir.
Sertifikayı kalıcı sanmak. Agent versiyonu değişince sertifika tutmaz hale gelir. Yeni versiyon = yeni sertifika. Eski sertifika ile production çağrısı bayrak alır; üst üste birikirse cloud runtime agent’ı askıya alabilir. Versiyon değiştiğinde sertifika yenileme prosedürünü unutma — agent dokümanın bir parçası olsun.
Sonra ne okumalı?
Yayın sonrası agent’ın olgunlaşması bitmedi — yaşayan tether her production çağrısında öğrenmeyi sürdürür. Yeni görev eklemek istiyorsan görev seçimi metodolojisini gözden geçir: AI agent için görev seçimi. Yeni bir agent kurmak istiyorsan baştan başla: İlk AI agent nasıl kurulur. Sektörel detay için kendi alanına bak: finans, satın alma, hukuk, İK, lojistik, bakım-onarım.