AI Geçidi Koruma Önlemleri: Kullanıcılar Görmeden Önce İstekleri ve Çıktıları Doğrulayın

Üretim AI uygulamaları sadece iyi bir isteme ihtiyaç duymaz. Modelin ne aldığını inceleyebilen, geri döneni inceleyebilen ve yanıt bir kullanıcıya veya aşağı akış sistemine ulaşmadan önce net bir karar verebilen bir kontrol katmanına ihtiyaç duyarlar.

Bu, AI geçit koruma kurallarının arkasındaki fikirdir.

Tam mimari ürüne göre değişecektir. Bazı ekipler kontrolleri uygulama arka ucuna koyar. Bazıları bir geçit veya proxy kullanır. Bazıları model düzeyindeki güvenlik ayarlarını özel doğrulama ile birleştirir. Önemli olan, güvenliğin her özellik ekibinin aynı mantığı her uç noktaya bağlamayı hatırlamasına bağlı olmamasıdır.

Yapıcılar için koruma kuralları ürün sorumluluğunun bir parçasıdır. ShareAI, model kullanımını yönlendirmenize ve AI trafiğinden gelir elde etmenize yardımcı olabilir, ancak uygulamanız yine de politika, izinler, kayıt tutma, müşteri deneyimi ve insan incelemesi konularında sorumludur.

Geçit düzeyindeki koruma kurallarının önemi

Bir AI uygulaması genellikle basit başlar. Bir uç nokta bir modeli çağırır. Sonra kullanım genişler: daha fazla özellik, daha fazla müşteri, daha fazla model sağlayıcı, daha fazla dahili araç, daha fazla kullanıcı tarafından oluşturulan giriş ve üretilen bir yanıtın eylemi tetikleyebileceği daha fazla yer.

O noktada, özellik başına güvenlik mantığına güvenmek zorlaşır. Bir uygulama sürümü isteme enjeksiyonunu engelleyebilir. Bir diğeri sadece toksisiteyi kontrol edebilir. Üçüncüsü, ekip lansmana yetişmek için yarışırken çıktı doğrulamayı atlayabilir.

Geçit düzeyindeki koruma kuralları, doğrulamayı model trafiğine yakın bir yere koyarak tutarlılık sorununu çözer. Uygulama, istemi, model yanıtını veya her ikisini değerlendiren paylaşılan bir katman aracılığıyla bir istek gönderebilir. Katman, izin ver, engelle, sansürle, incele veya yeniden dene gibi bir karar döndürür.

Bu, ürün yargısına olan ihtiyacı ortadan kaldırmaz. Onu uygulamak için tek bir yer oluşturur.

İyi koruma kuralları dört soruya cevap vermelidir:

• Bu istem bir modele göndermek için güvenli mi?
• Bu model çıktısı bir kullanıcıya göstermek için güvenli mi?
• Model, uygulamanın sağladığı kanıtlara bağlı kaldı mı?
• Ne oldu ve ekip daha sonra kararı denetleyebilir mi?

Model çağrısından önce neyi doğrulamalı?

Girdi doğrulaması, riskleri modele ulaşmadan önce yakalar.

İlk kategori istem enjeksiyonudur. Bir kullanıcı, belge, web sayfası veya araç sonucu, sistem istemini geçersiz kılmak, gizli bağlamı sızdırmak veya modelin kullanmaması gereken bir aracı çağırmasını zorlamak için tasarlanmış talimatlar içerebilir. LLM Uygulamaları için OWASP İlk 10 istem enjeksiyonunu ve aşırı yetkilendirmeyi bir nedenle temel LLM uygulama riskleri olarak ele alır: model talimatları takip ediyor olabilir, ancak ürün yine de sonuçtan sorumludur.

İkinci kategori politika uyumudur. Uygulamanız tıbbi, hukuki, finansal, yetişkin, kötüye kullanım veya kendine zarar verme ile ilgili içeriği desteklemiyorsa, model jetonlarını harcamadan veya müşteri odaklı bir yanıt oluşturmadan önce bunu doğrulayın.

Üçüncü kategori hassas verilerdir. Bazı istemler, engellenmesi, maskelenmesi veya daha sıkı bir iş akışından geçirilmesi gereken sırlar, kimlik bilgileri, kişisel veriler veya tescilli içerik içerebilir.

Dördüncü kategori araç iznidir. Uygulamanız modelleri şu gibi desenler aracılığıyla araçlara bağlarsa Model Bağlam Protokolü, doğrulama modelin neye dokunmasına izin verildiğini dikkate almalıdır. Bir dosya okumak, bir veritabanını sorgulamak, bir e-posta göndermek ve bir kaydı silmek aynı güven düzeyini paylaşmamalıdır.

Kullanıcı çıktıyı görmeden önce neyi doğrulamalı

Çıktı doğrulaması, üretimden sonra ancak maruz kalmadan önce sorunları yakalar.

Doğrudan güvenlik kontrolleriyle başlayın: toksisite, taciz, güvensiz talimatlar, hassas bilgiler ve politika ihlalleri. Orijinal istem zararsız görünse bile model, ürününüzün göstermemesi gereken bir şey üretebilir.

Ardından, dayanak doğrulaması yapın. Uygulamanız referans belgeler, geri alma parçacıkları, veritabanı satırları veya müşteri kayıtları sağlıyorsa, yanıtın bu bağlama karşı kontrol edilmesi gerekir. Akıcı ancak desteklenmeyen bir yanıt, açık bir başarısızlıktan daha zararlı olabilir çünkü kullanıcılar ona daha fazla güvenme eğilimindedir.

Daha sonra yapıyı doğrulayın. Çıktının JSON, bir destek makrosu, bir sözleşme maddesi, bir veritabanı güncellemesi veya bir araç komutu olması gerekiyorsa, şemayı ve izin verilen alanları kontrol edin. Bir modelin, kısıtlanmış veri bekleyen bir yere rastgele metin yazmasına izin vermeyin.

Son olarak, eylem hazırlığını doğrulayın. Bir taslak e-posta, gözden geçirilmek üzere bir kullanıcıya gösterilebilir. Bir geri ödeme onayı, hesap değişikliği, kod birleştirme veya müşteri bildirimi açık bir insan onayı gerektirebilir.

Amaç her yanıtı mükemmel hale getirmek değildir. Tahmin edilebilir hataların pahalı oldukları yerlere ulaşmasını önlemektir.

Engelleme, izin verme veya inceleme davranışını kasıtlı olarak seçin.

Bir korkuluk, ürünün kararı nasıl kullanacağını bildiği sürece faydalıdır.

Düşük riskli sorunlar için uygulama, kullanıcıdan istemi gözden geçirmesini isteyebilir. Desteklenmeyen çıktılar için uygulama güvenli bir alternatifle yanıt verebilir ve sonucu doğrulayamadığını açıklayabilir. Yüksek riskli eylemler için uygulama çalışmayı bir insan inceleyicisine gönderebilir.

En zor karar, korkuluk sistemi hatalarını nasıl ele alacağınızdır. Doğrulama mevcut değilse, uygulama açık şekilde başarısız olup devam mı etmeli, yoksa kapalı şekilde başarısız olup isteği mi engellemeli?

Evrensel bir cevap yoktur.

Açık şekilde başarısız olmak, kullanılabilirliğin önemli olduğu ve çıktının hâlâ kullanıcı incelemesi gerektirdiği düşük riskli taslak özellikler için makul olabilir. Kapalı şekilde başarısız olmak, düzenlenmiş tavsiyeler, finansal işlemler, hesap değişiklikleri, özel veriler veya harici araç yürütme içeren iş akışları için daha güvenlidir.

Bu kararı küresel olarak değil, iş akışına göre verin. Bir ürün, beyin fırtınası için izin verici ve müşterileri, parayı, verileri veya güvenliği etkileyen eylemler için katı olabilir.

ShareAI’nin rolünü net tutun.

ShareAI, Yapıcıların AI kullanımını bir pazar yeri ve API katmanına bağlamasına yardımcı olur. Yapıcılar, çıkarımı ShareAI üzerinden yönlendirebilir, modelleri seçebilir model pazarı değil, ve kendi uygulamaları AI kullanımı oluşturduğunda bir marj belirleyebilir.

Bu, ShareAI’yi ürün güvenlik modelinizin sahibi yapmaz.

Yapıcı hâlâ şunların sahibidir:

• Kullanıcı kimlik doğrulama ve yetkilendirme.
• Uygulamaya özgü içerik politikası.
• İstem ve çıktı doğrulama.
• Araç izinleri ve onay akışları.
• Müşteri odaklı hata yönetimi.
• Günlük kaydı, izleme ve destek incelemesi.
• Gizlilik ve uyumluluk kararları.

Bu ayrım önemlidir. ShareAI, AI ürününüzün ekonomisini destekleyebilir, ancak koruma önlemleri müşterilerle yaptığınız uygulama sözleşmesinin bir parçasıdır.

Bir Builder iş akışı uyguluyorsanız, ShareAI belgeleri ve API referansı, ardından entegrasyonu kendi politika kontrolleriniz ve gözlemlenebilirlik ile eşleştirin.

Pratik bir uygulama kontrol listesi

Üretim modeli çağrıları etrafında koruma önlemleri eklerken bu kontrol listesini kullanın:

• Üründeki her AI iş akışını listeleyin.
• Her iş akışını riskine göre sınıflandırın: taslak hazırlama, tavsiye, müşteri eylemi, veri erişimi, araç eylemi veya düzenlenmiş alan.
• Enjeksiyon girişimleri, güvensiz içerik, desteklenmeyen istekler ve hassas veriler için istemleri doğrulayın.
• Çıktıları politika ihlalleri, desteklenmeyen iddialar, şema hataları ve veri sızıntısı açısından doğrulayın.
• Hangi iş akışlarının açık şekilde başarısız olabileceğine ve hangilerinin kapalı şekilde başarısız olması gerektiğine karar verin.
• Geri döndürülemez veya yüksek etkili eylemler için insan incelemesi ekleyin.
• Kararları, model kimliklerini, iş akışı kimliklerini, kullanıcı kimliklerini ve neden kodlarını kaydedin.
• Doğrulama gecikmesini ve hata oranını takip edin.
• Düşmanca istemler, karmaşık belgeler ve araç-sonuç enjeksiyonu ile test yapın.
• Kullanım genişledikçe politikaları yeniden gözden geçirin.

Gözlemlenebilirlik için, OpenTelemetry gözlemlenebilirlik rehberi başlangıç noktası olarak faydalıdır. AI koruma önlemleri, bir isteğin neden engellendiğini ve uygulamanın sonraki adımda ne yaptığını açıklayan izler ve günlükler üretmelidir.

SSS

AI geçit koruma önlemleri nedir?

AI geçit koruma önlemleri, model trafiği yakınında yerleştirilen doğrulama kontrolleridir. İstemleri, çıktıları veya araç çağrılarını inceler ve AI yanıtı bir kullanıcıya veya sisteme ulaşmadan önce izin verme, engelleme, inceleme veya yeniden deneme gibi kararlar döndürür.

ShareAI bir AI koruma motoru sağlar mı?

Bu makale ShareAI'yi bir koruma motoru olarak konumlandırmaz. ShareAI, Yapıcıların modellere erişmesine, AI kullanımını yönlendirmesine ve uygulama trafiğini gelir elde etmesine yardımcı olur. Yapıcılar, kendi uygulama yığınlarında ürün spesifik güvenlik, politika, günlükleme ve inceleme kontrollerini uygulamalıdır.

Neden hem istemleri hem de çıktıları doğrulamalıyız?

İstem doğrulama, güvensiz veya manipülatif girdileri modele ulaşmadan önce yakalar. Çıktı doğrulama, bir kullanıcı veya alt sistem görmeden önce güvensiz, desteklenmeyen, hatalı veya politika ihlali yapan yanıtları yakalar.

İstem enjeksiyonu nedir?

İstem enjeksiyonu, uygulamanın amaçlanan davranışıyla çelişen talimatlarla modeli manipüle etme girişimidir. Kullanıcı girdisinden, alınan belgelerden, web sayfalarından veya araç sonuçlarından gelebilir.

Çıktı doğrulama neyi kontrol etmelidir?

Çıktı doğrulama, güvensiz içerik, desteklenmeyen iddialar, hassas veri sızıntısı, şema hataları, sağlanan bağlama karşı halüsinasyonlar ve herhangi bir alt işlem için hazır olma durumunu kontrol etmelidir.

Her engellenen istek aynı şekilde mi başarısız olmalı?

Hayır. Bir beyin fırtınası özelliği, bir finansal iş akışı veya hesap yönetim aracıyla farklı şekilde yanıt verebilir. Yanıtı riske göre eşleştirin: kullanıcıdan revize etmesini isteyin, güvenli bir alternatif gösterin, incelemeye gönderin veya tamamen engelleyin.

Açık başarısızlık ile kapalı başarısızlık nedir?

Açık başarısızlık, korkuluk sistemi kullanılamadığında uygulamanın devam etmesi anlamına gelir. Kapalı başarısızlık, doğrulama mevcut olana kadar uygulamanın isteği engellemesi anlamına gelir. Yüksek riskli iş akışları genellikle düşük riskli taslak özelliklerinden daha katı bir davranışı hak eder.

Korkuluklar Builder'ın gelir modelini nasıl etkiler?

Korkuluklar, boşa harcanan model çağrılarını azaltabilir, maliyetli hataları önleyebilir ve premium AI iş akışlarının güvenilirliğini artırabilir. Builder'lar yine de kullanımı ShareAI üzerinden yönlendirebilir ve bir marj belirleyebilir, ancak ürün, bir iş akışının daha fazla token harcamasına veya devam etmesine ne zaman izin verileceğini kontrol etmelidir.

Korkuluklar insan incelemesinin yerini alır mı?

Hayır. Korkuluklar öngörülebilir riski azaltır, ancak insan incelemesi geri dönüşü olmayan işlemler, düzenlenmiş iş akışları, hassas müşteri sonuçları ve modelin belirsiz olduğu durumlar için hâlâ önemlidir.

Ajanslar korkuluklar hakkında nasıl düşünmeli?

Ajanslar korkulukları müşteri teslimatının bir parçası olarak ele almalıdır. Özellikle AI özelliği müşteri verilerine veya harici araçlara dokunduğunda, lansmandan önce politika, kayıt, yükseltme ve inceleme davranışını tanımlayın.

Geçit korkulukları yalnızca büyük işletmeler için mi?

Hayır. Daha küçük ekipler de birden fazla AI özelliği, birden fazla model veya kullanıcıları, verileri veya parayı etkileyebilecek herhangi bir iş akışı olduğunda tutarlı doğrulamadan faydalanır.

Eklenmesi gereken ilk korkuluk nedir?

İstem enjeksiyonu algılama, çıktı politikası kontrolleri ve yapılandırılmış çıktılar için şema doğrulama ile başlayın. Ardından, iş akışı riski bunu hak ettiğinde, temel kontrol, araç izinleri ve insan incelemesi ekleyin.