Mimari ve çalışma modeli
Kurumsal yapay zekâ yönetişimi tek bir onay formu değil; kullanım amacı, veri, model, istem, araç yetkileri, değerlendirme seti ve üretim telemetrisini aynı değişiklik zincirinde izleyen bir yaşam döngüsüdür. Fikir aşamasında iş sahibi ve etkilenen kullanıcılar tanımlanır; tasarımda veri sınıfı ile güven sınırı belirlenir; üretim öncesinde kalite, güvenlik, maliyet ve geri dönüş eşikleri kanıtlanır.
Model sağlayıcısı değişse bile kontrol düzlemi kurumda kalmalıdır. Model kartı, veri kaynağı kaydı, istem sürümü, değerlendirme sonucu, risk kabulü ve dağıtım kimliği birbirine bağlanır. Yüksek etkili bir kullanım için insan onayı, itiraz yolu ve kayıt saklama süresi; düşük etkili bir özetleme aracı içinse daha hafif fakat ölçülebilir bir kontrol seti uygulanabilir.
Üretimde yönetişim, sabit bir belge yerine ölçülebilir kapılarla çalışır. Kalite düşüşü, veri kaynağı değişikliği, yeni araç yetkisi, model sürümü veya mevzuat etkisi yeniden değerlendirmeyi tetikler. Sahibi olmayan modeller, amaç dışı yeniden kullanım ve kontrolsüz gölge AI envanter dışı kaldığında teknik risk görünmez olur.
- 1Kullanım amacı ve risk sınıfı
- 2Veri/model/istem envanteri
- 3Değerlendirme ve yetki kapıları
- 4Üretim izleme ve yeniden onay
Tasarım parametreleri
- Kullanım amacı kartı
- Karar, kullanıcı, yasaklanan kullanım ve başarı ölçütlerini tek kayıtta tanımlayın.
- Risk kademesi
- Etki, veri hassasiyeti, özerklik ve geri döndürülebilirliğe göre düşük-orta-yüksek sınıfı verin.
- Kanıt paketi
- Model, veri, istem, eval, red-team, maliyet ve onay kayıtlarını dağıtım kimliğine bağlayın.
- Değişiklik tetikleyicisi
- Model veya veri sürümü, araç yetkisi ve eşik değişiminde yeniden test zorunluluğu koyun.
Hesap ve uygulama örneği
İK yardımcısı için 240 soruluk altın set hazırlanır; kabul eşiği doğrulukta %92, kaynaksız yanıtta en fazla %2 ve kişisel veri sızıntısında sıfırdır. Yeni model doğruluğu %94 verse de kaynaksız cevap oranı %4 ise üretim kapısı açılmaz; retrieval veya cevap politikası düzeltilip aynı sürümlü set yeniden çalıştırılır.
Aylık 80.000 istekte insan incelemesi için %1 tabakalı örnek seçilirse 800 kayıt incelenir. Yüksek riskli bordro soruları ayrıca yüzde yüz örneklenir. Her olay model, istem, kaynak ve politika sürümüne bağlandığı için sorun yalnız modele atfedilmez.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
ai-release validate --manifest release.yaml --eval-set hr-golden-v3
ai-release approve --risk-tier high --evidence evidence.json
ai-release deploy --id hr-assistant-2026-10-25 --canary 5%Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Sonuçlar yeniden üretilemiyor | İstem, model veya retrieval sürümü kayıtlı değildir. | Aynı girdi için dağıtım kimliği ve bağımlılık manifestini kontrol edin. |
| Gölge AI kullanımı artıyor | Onaylı hizmet yolu yavaş veya envanter görünürlüğü eksiktir. | Ağ/SaaS envanteri ile erişim kayıtlarını karşılaştırın; güvenli bir talep süreci sağlayın. |
| Kalite sessizce düşüyor | Üretim dağılımı altın setten ayrılmış veya kaynak içeriği değişmiştir. | Canlı örnekleri risk tabakalarıyla yeniden etiketleyip regresyon setine ekleyin. |
Kabul ve doğrulama kontrolleri
- Her sistem için iş sahibi, teknik sahibi ve risk sahibini kaydedin.
- Veri sınıfını, saklama süresini ve model sağlayıcısına giden alanları doğrulayın.
- Model, istem, retrieval ve araç sürümlerini tek dağıtım kimliğinde sabitleyin.
- Kalite, güvenlik, maliyet ve gecikme eşiklerini üretimden önce çalıştırın.
- İnsan müdahalesi ile geri alma yolunu tatbik edin.
- Değişiklik ve olay kayıtlarını periyodik yönetim gözden geçirmesine bağlayın.
İlgili kavramlar
Politikanın yaşam döngüsü
Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.
Güven sınırı ve hata alanı
Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
En az yetki ve görev ayrımı
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.