Bir yapay zeka denetim kaydı neleri içermeli ve kimler okumalı?

Temsili bir örnek ele alalım. Bir müşteri, verilmesinin üzerinden aylar geçmiş bir para iadesi kararına itiraz ediyor: asistan iade edilen bir kanepe için kısmi para iadesi önermiş, bir temsilci bunu onaylamış; müşteri ise politikanın tam para iadesi vaat ettiğini söylüyor. Artık birinin kesin bir yanıt vermesi gerekiyor.

İyi bir denetim kaydıyla bu dakikalar sürer. Kayıt, müşterinin mesajını ve fotoğraflarını geldiği haliyle, siparişi, iade politikasının o gün yürürlükte olan sürümünü, sistemin atıf yaptığı bölümü, öneriyi üreten model ve prompt sürümünü ve öneriyi onaylayan temsilciyi gösterir. Sistemin haklı olduğunu gösterebilir. Eski bir sürüme atıf yaptığını da gösterebilir; bunu bilmek de aynı derecede önemlidir.

Kayıt yoksa ekip olanları hafızasına dayanarak yeniden kurmaya çalışır. Bir yapay zeka denetim kaydı, her karar yeniden kurulabilecek şekilde tasarlanmalı; kayıtların kendisi de hassas veri olarak ele alınmalıdır.

Bir denetim kaydı hangi soruları yanıtlamalı?

Herhangi bir vakada, ilgili kişilere sormaya gerek kalmadan yanıtlanması gereken beş soru:

• Sistem ne gördü?
• Hangi kaynakları, hangi sürümleriyle kullandı?
• Çıktıyı hangi model, prompt ve ayarlar üretti?
• Ne önerdi ve neyi belirsiz diye işaretledi?
• Kim karar verdi, ne yaptı ve ne zaman?

Kayıt bu beş sorunun hepsini yanıtlayamıyorsa bir denetim kaydı değil, bir hata ayıklama kaydıdır.

Her vaka için neler kaydedilmeli?

Her alanın gerekçesiyle birlikte bir alan listesi:

1. Vaka kimliği ve zaman damgaları: geliş, işleme, inceleme ve işlem anları için; böylece olaylar sıraya konabilir ve başka sistemlerle eşleştirilebilir.
2. Geldiği haliyle girdi ya da ona bir referans ve bir parmak izi (hash); böylece kaynak sonradan değişse bile sistemin ne gördüğünü gösterebilirsiniz.
3. Sürümleriyle getirilen kaynaklar: belge kimlikleri, sürümler ya da yürürlük tarihleri ve kullanılan bölümler; çünkü politikalar değişir ve itirazın tamamı çoğu zaman “Hangi sürüm?” sorusudur.
4. Sorgulanan veriler: sistemin okuduğu sipariş, tutarlar ve müşteri durumu; çünkü çıktının arkasındaki olgular bunlardır.
5. Model ve prompt sürümü: sağlayıcının döndürdüğü model tanımlayıcısı, kod deponuzdaki prompt sürümü ve temel ayarlar; çünkü bunlardan herhangi biri değiştiğinde davranış da değişir.
6. İnceleyene gösterildiği haliyle çıktı, atıflar dahil; çünkü kişinin onayladığı şey odur.
7. Uyarılar ve kontroller: doğrulama sonuçları, belirsizlik uyarıları, tetiklenen kurallar ve bir vakanın neden yetkili kişiye aktarıldığı.
8. İnceleyen ve yapılan işlem: kimin incelediği, neyi değiştirdiği, onayladığı ya da reddettiği ve müdahale ettiyse müdahale nedeni.
9. Asıl kayıt sistemindeki nihai sonuç: gerçekte neyin gönderildiği, ödendiği ya da kayda alındığı.

İnsanın ne gördüğünü kaydetmek, modelin ne dediğini kaydetmek kadar önemlidir. Bir onay ancak onaylayanın önünde ne olduğunu gösterebildiğinizde bir anlam taşır.

Kayıtlar ne kadar süre saklanmalı?

İtirazları ve denetimleri yanıtlamaya yetecek kadar ve veri koruma kurallarınızın izin verdiğinden uzun olmamak üzere. Bu ikisi ters yönlere çeker ve yanıtı tek başınıza veremezsiniz: kayıtlar kişisel veri içerir; bu yüzden saklama ve erişimi veri koruma görevlinizle (DPO) kararlaştırın, sektöre özgü ya da sözleşmeden doğan kayıt tutma kurallarını da hukuk danışmanınıza sorun.

Kaydı ikiye bölmek çoğu zaman işe yarar. Karar kaydını (kimlikler, sürümler, uyarılar, inceleyen ve yapılan işlem) daha uzun süre, tam metni daha kısa süre saklayın ya da kopyalar yerine kaynak sisteme referanslar tutun. Bir silme talebinin denetim kaydını nasıl etkileyeceğine önceden karar verin.

Kayıtlara kimler erişebilmeli?

Uygulamaya erişenlerden daha az kişi. Uygulanabilir bir dağılım:

• Süreç sahibi ve denetçiler, bir gerekçe olduğunda tek tek vakaları okur.
• Güvenilirlik ekibi, izleme için toplulaştırılmış ve maskelenmiş veriyi görür.
• Mühendisler, hata ayıklama için süreli ve mümkün olduğunca maskelenmiş erişim alır.

Kayıtlara erişimi de kaydedin. Denetim kaydı çoğu zaman anlattığı sistemlerden daha az korunur; bu da onu sızıntı için kolay bir hedef yapar. Bu, koruma önlemlerimizdeki “Kim neye erişebilir?” sorusunun ta kendisidir.

Kayıtlar denetimin yanında iyileştirmeyi nasıl destekler?

Aynı kayıtlar gündelik kalite çalışmasını da besler. Müdahale oranları, uyarılar, vaka başına maliyet ve yanıt süreleri bu kayıtlardan çıkar; canlıya geçtikten sonraki izleme de bunlarla çalışır. İnceleyenin düzeltmesiyle birlikte her müdahale, değerlendirme seti için aday bir vakadır. Bir şey ters gittiğinde olay incelemesi kayıttan başlar. Kayıt, bir yönetim kurulunun ya da risk komitesinin sorması gerekenleri de yanıtlar: hangi sistemler hangi kararları etkiliyor, insanlar bu sistemlerin önerilerine ne sıklıkla müdahale ediyor ve son olay ne öğretti; yönetim kurullarının yapay zeka hakkında sorması gerekenlere bakın. Yalnızca denetçiler için tasarlanan bir kaydı genellikle yalnızca denetçiler okur; iyileştirme için tasarlanan bir kayda ise her hafta bakılır ve eksikleri de böyle bulunur.

Kaydın eksiksiz olduğu nasıl test edilir?

Bir yeniden kurma tatbikatı yapın. Rastgele bir geçmiş vaka ve zorlu bir vaka seçin; iki vakada da görev almamış birinden her kararı yalnızca kayıtlara bakarak yeniden kurmasını isteyin: sistemin ne gördüğü, hangi kaynakları ve sürümleri kullandığı, hangi model ve promptun yanıt verdiği, ne önerdiği ve kimin onayladığı. Süreyi tutun ve kayıtların yanıtlayamadığı her soruyu not edin.

Bir kararı kayıttan yeniden kuramıyorsanız onu ne savunabilir ne de ondan ders çıkarabilirsiniz.

Tatbikatı canlıya geçmeden önce ve yeni bir model ya da veri kaynağı gibi her büyük değişiklikten sonra tekrarlayın; çünkü fark edilmeden ilk bozulan alanlar sürüm alanlarıdır.

Geçmiş bir kararı yeniden kurabilir misiniz?

Sisteminizin bir süre önce verdiği bir kararı seçin ve kimse sizden istemeden önce onu kayıtlardan yeniden kurmayı deneyin. Yanıtlayamadığınız her soru, eklenecek bir alandır. Denetim kayıtlarını baştan sisteme yerleştirmek, özel yapay zeka yazılımına yaklaşımımızın bir parçasıdır.

Bu not genel bilgi amaçlıdır; hukuki tavsiye değildir.

Kaynaklar

1. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 ABD Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
2. ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system Uluslararası Standardizasyon Örgütü (ISO) www.iso.org/standard/42001
3. OECD AI Principles OECD oecd.ai/en/ai-principles