Bir yapay zeka sistemi için destek sözleşmesi neyi taahhüt etmeli?

Destek sözleşmesi taslağı, BT sözleşmelerinin hep taahhüt ettiği şeyleri taahhüt ediyor: erişilebilirlik ve destek talepleri için yanıt süreleri. Bir yapay zeka sistemi ikisini de karşılayıp yine de bir ay boyunca yanılabilir; çünkü hatalarının çoğu kesinti değildir; doğru görünen yanlış yanıtlardır.

İşe yarar bir yapay zeka destek sözleşmesi, yani hizmet seviyesi sözleşmesi (SLA), bunun yerine ölçülebilecek olanı taahhüt eder: üzerinde anlaşılmış bir değerlendirme setinde kalite eşikleri, olaylar için yanıt süreleri, model ve prompt değişikliklerinin kuralları, maliyet raporlaması ve düzenli bir iyileştirme toplantısı. Madde listesini notun sonunda bulabilirsiniz.

Standart BT hizmet seviyeleri yapay zeka sistemlerine neden uymaz?

Çünkü erişilebilirliği ölçerler ve sorun nadiren erişilebilirliktir. Kalite, belgeleriniz ve vaka dağılımınız gibi tedarikçinin kontrol etmediği girdilere ve iki tarafın da kontrol etmediği bir model sağlayıcıya bağlıdır. O sağlayıcı bir modeli güncellediğinde sistem, hiçbir sürüm yayına alınmadan değişebilir. Tek bir doğruluk yüzdesi ise ya anlamsızdır ya da uygulatılamaz: Hangi vakalarda doğru, kim ölçüyor, hangi dönem boyunca?

Erişilebilirlik maddelerini koruyun. Yapay zeka sistemlerinin gerçekte nasıl hata yaptığına göre yeni maddeler ekleyin.

Kalite konusunda ne taahhüt edilebilir?

Doğruluğu, kesintisiz çalışma süresini taahhüt eder gibi taahhüt edemezsiniz.

Taahhüt edebileceğiniz şey bir yöntemdir. Taahhüdü, iki tarafın üzerinde anlaştığı, sürümlediği ve güncel tuttuğu bir değerlendirme setine ve canlı vakaların örneklem incelemesine bağlayın; çünkü hiçbir set, canlı kullanımın getirdiği her şeyi öngöremez.

Bir iade asistanı için temsili bir madde ele alalım: Her sürümden önce sistem, güncel değerlendirme setinde her vaka türü için anlaşılan eşikleri karşılar ve hiçbir zaman sipariş tutarının üzerinde bir iade önermez. Tedarikçi ve iade sorumlusu her hafta canlı vakalardan rastgele seçilen kırk vakayı anlaşılan puanlama ölçütüne göre puanlar. Art arda iki haftanın örneklemi eşiğin altında kalırsa tedarikçi durumu araştırır, nedeni raporlar ve anlaşılan süre içinde bir düzeltme önerir; taraflardan her biri de son sağlıklı sürüme geri dönebilir.

Bunu tek bir doğruluk yüzdesiyle karşılaştırın. Madde neyin, hangi vakalarda, kim tarafından ölçüldüğünü ve sonra ne olacağını söylüyor.

Olaylar için yanıt süreleri neleri kapsamalı?

Önem derecelerini, ilk saatler için olay müdahale planını anlatan notumuzda olduğu gibi, bileşene göre değil etkiye göre tanımlayın. Her derece için iş akışının çalışma saatlerine uyan müdahale beklentileri üzerinde anlaşın: Gece de çalışan, müşteriye dönük bir asistan, bir arka ofis kuyruğundan farklı bir kapsama ister. Tetikleyicilerin yalnızca kesintiyi değil, yapay zekaya özgü hataları da içerdiğinden emin olun: zararlı ya da politikaya aykırı çıktı, yanlış kişiye gösterilen veri, eşiğin altına düşen kalite ve maliyet sıçramaları.

Düzeltme süresini değil, olayı teyit etme ve etkisini sınırlama sürelerini taahhüt edin; çünkü bir düzeltmenin önce değerlendirme setini geçmesi gerekir. Ekibinizin tedarikçiyi beklemeden sistemi durdurabileceğini ve kişisel veriyle ilgili her durumun hemen veri koruma görevlinize (DPO) ulaşacağını yazın.

Model ve prompt değişiklikleri nasıl yönetilmeli?

Kimin neyi değiştirebileceğini ve her değişikliğin nasıl onaylanacağını yazıya dökün:

• Model sağlayıcı modelleri günceller ya da kullanımdan kaldırır; bunun ne zaman olacağını iki taraf da kontrol edemez. Tedarikçi bunu takip eder, mümkün olduğunda sürümleri sabitler ve yeni bir sürüme geçmeden önce değerlendirme setini yeniden çalıştırır.
• Tedarikçi promptları, bilgi erişimi ayarlarını ve model seçimlerini değiştirir. Her değişiklik değerlendirme setinden geçer ve bir değişiklik notu alır; önemli olanlar sizin onayınızı gerektirir.
• Sizin ekibiniz kaynak belgeleri, politikaları ve iş kurallarını değiştirir; bunlar da yanıtları aynı kesinlikle değiştirebilir. Kimin kime haber vereceği konusunda anlaşın.

İki tarafın da okuyabildiği bir değişiklik kaydı ve test edilmiş bir geri alma yolu tutun.

Maliyet raporlaması ve tavanlar nasıl ele alınmalı?

Görev başına maliyeti özellik bazında, hacimlerle birlikte ve olağan dışı her şeyin açıklamasıyla veren aylık bir rapor isteyin. Tavanın ne olacağı, harcama tavana yaklaştığında ne yapılacağı ve tavan aşılırsa bedeli kimin ödeyeceği konusunda anlaşın; bu son nokta hukuk danışmanınızın konusudur. Birkaç iş akışı tek bir sağlayıcı hesabını paylaşıyorsa maliyetlerin aralarında nasıl bölüneceği konusunda anlaşın. Sağlayıcının fiyat değişiklikleri size yansıtılmadan önce bildirim yapılmasını isteyin. Mümkünse model sağlayıcı hesabını kendi adınıza açın; böylece maliyetler görünür kalır ve tedarikçi değişirse hesap sizde kalır.

Düzenli gözden geçirme neleri içermeli?

Süreç sahibiyle aylık ya da üç aylık bir gözden geçirme şunları içerir: vaka türüne göre kalite eğilimleri, olaylar ve ürettikleri değerlendirme vakaları, yapılan değişiklikler, görev başına maliyet, müdahaleler ve geri bildirim ile kanıta dayanarak seçilen bir sonraki iyileştirmeler. Bu toplantının neye karar verebileceği (kapsamı genişletmek, bir dil eklemek ya da bir özelliği kaldırmak gibi) ve onayı kimin vereceği konusunda önceden anlaşın. Değerlendirme seti bu toplantılarda büyür; toplantıya getirilmeye değer sinyalleri canlıya geçişten sonra neyin izleneceğini anlatan notumuz sıralıyor.

Sözleşmede hangi maddeler olmalı?

1. Kapsam: kapsanan sistem, iş akışları, diller, saatler ve entegrasyonlar; böylece boşluklar görünür olur.
2. Kalite ölçüm yöntemi: değerlendirme seti, vaka türü başına eşikler ve örneklem incelemesi; çünkü genellikle aksayan kalitedir.
3. Olay önem dereceleri: tetikleyiciler, müdahale beklentileri ve sistemi kimin durdurabileceği; çünkü yapay zeka hataları nadiren kesintidir.
4. Değişiklik yönetimi: modelleri, promptları ve kaynakları kimin değiştirebileceği, değişikliklerin nasıl test edilip onaylanacağı ve nasıl geri alınacağı; çünkü sistem, yeni bir sürüm çıkmadan da değişebilir.
5. Maliyet raporlaması: görev başına maliyet, tavan ve tavana yaklaşıldığında ne olacağı; böylece her artışın bir açıklaması olur.
6. Gözden geçirme ritmi: ne sıklıkla, kimlerle ve hangi çıktılarla; çünkü sistem orada iyileşir.
7. Çıkış ve devir teslim: koddan ve promptlardan değerlendirme setlerine ve işletim kılavuzlarına kadar neleri teslim alacağınız; böylece tedarikçi değiştirebilirsiniz. Devir teslim kontrol listemiz bunları sıralıyor.

Sözleşme koşulları hukuk danışmanınızın işidir; bunlar ona götürmeniz gereken sorulardır. Bu çizgideki sözleşmeler yapay zeka güvenilirliği çalışmalarımızın parçasıdır ve genellikle hizmet seviyelerinin birlikte belirlendiği bir Yerleşik Yapay Zeka Ekibi modeliyle yürür.

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