AI API Erişimini Yeniden Satabilir misiniz? Lansmandan Önce Sağlayıcı Hakları Matrisi Oluşturun
Çalışan bir sağlayıcı anahtarı, API'ı yeniden dağıtabileceğinizi kanıtlamaz. Sürümlendirilmiş bir haklar matrisi oluşturun ve müşteri kabulü ve istek yönlendirme sırasında ticari izinleri zorunlu kılın.
Bir sağlayıcının API isteğinizi kabul etmesi, aynı erişimi müşterilere satma izniniz olduğu anlamına gelmez. Teknik kullanılabilirlik ve ticari yetki ayrı koşullardır.
Bu ayrım, AI API bayi platformunu çalıştırdığınızda, uyumlu bir uç nokta ortaya çıkardığınızda veya birden fazla sağlayıcıyı tek bir anahtar arkasında paketlediğinizde önemlidir. Yukarı akış koşulları, model çıktısı kullanan, ham doğrudan geçiş erişimini yasaklayan, bayi sözleşmesi gerektiren, müşteri konumlarını kısıtlayan veya yalnızca müşterinin sahip olduğu kimlik bilgilerine izin veren bir uygulamaya izin verebilir.
Pratik çözüm, dağıtım haklarını bir yönlendirme yeteneği olarak ele almaktır. Bir müşteriyi kabul etmeden veya bir sağlayıcı rotası seçmeden önce, ağ geçidinin ilgili hesabın, modelin, teslimat modunun ve müşteri coğrafyasının belgelenmiş izin kapsamında olduğunu doğrulaması gerekir.
Kapsam: Bu, yasal tavsiye değil, operasyonel mimari ve sorun tespit kılavuzudur. Nihai izin, yürütülen sözleşmelerinize, satın alma kanallarınıza, ürün tasarımınıza ve nitelikli yasal incelemenize bağlıdır.
Çalışan bir API anahtarı neden yeterli değildir
Sağlayıcı anlaşmaları genellikle çeşitli ticari ilişkiler arasında ayrım yapar:
- Bir uygulama, son kullanıcılarına işlevsellik sağlamak için bir model kullanır.
- Bir platform, model etrafında önemli iş akışı, politika veya düzenleme özellikleri ekler çıkarım.
- Bir satıcı, yetkili bir iş ortağı programı kapsamında bir sağlayıcı hizmeti sağlar.
- Bir ağ geçidi, ham veya hafifçe değiştirilmiş bir sağlayıcı uç noktasını açığa çıkarır.
- Bir müşteri, kendi anahtarını getir veya BYOK aracılığıyla kendi sağlayıcı hesabına bağlanır.
Bu düzenlemeler birbirinin yerine kullanılamaz. Birleştirilmiş faturalandırma, analiz, yönlendirme ve müşteriye yönelik anahtarlar gerçek değer yaratır ancak ham yeniden dağıtımı otomatik olarak yetkili bir müşteri uygulamasına dönüştürmezler.
Kimlik bilgisi kuralları da dağıtım haklarından ayrıdır. Bir anlaşma, bir uygulamanın son kullanıcılara hizmet vermesine izin verse bile, yukarı akış anahtarlarının veya hesap erişiminin satılmasını veya aktarılmasını yine de yasaklayabilir. Alt müşteriler, ağ geçidi tarafından verilen kimlik bilgilerini almalıdır, asla havuza alınmış sağlayıcı kimlik bilgilerini almamalıdır.
Mevcut sağlayıcı koşulları neyi göstermektedir
Aşağıdakiler, kullanımdan önce mevcut belgelerle ve kendi sözleşmelerinizle karşılaştırılarak kontrol edilmesi gereken gerçek örneklerdir:
- OpenAI: Hizmet Sözleşmesi, son kullanıcılara sunulan müşteri uygulamalarıyla API entegrasyona izin verir. API anahtarların satın alınmasını, satılmasını veya devredilmesini ve bir hesaba veya son kullanıcı hesabına erişimin yeniden satılmasını veya kiraya verilmesini ayrıca yasaklar.
- Anthropic: Ticari Şartları, müşterilerin, müşterilerine ve kullanıcılarına sunulan ürün ve hizmetleri güçlendirmek için hizmetleri kullanmasına izin verirken, Anthropic hizmetin açık onay olmadan yeniden satışını yasaklar.
- Microsoft Azure: Azure Müşteri Çözümü kılavuzu, bu rota kapsamında model çıkarım API'lerinin basit bir şekilde yeniden satışına izin verilmediğini söylüyor. Ham veya ince sarılmış çıktıyı, değiştirilmemiş uç nokta maruziyetini ve çıktıyı şekillendirmeden çıkarım sağlayıcılar arasındaki yönlendirmeyi uygun olmayan örnekler olarak tanımlar. Nitelikli bir çözüm, birincil ve önemli işlevsellik eklemeli ve çıkarım API'lerini platformda tutmalıdır.Gerçek Azure satışı isteyen işletmeler, Bulut Çözüm Sağlayıcısı programına yönlendirilir.
- Google Bulut: Genel şartları, hizmetlerin satılmasını, yeniden satılmasını, alt lisanslanmasını, aktarılmasını veya dağıtılmasını yasaklar. Hizmete özel şartlar, geçerli anlaşmanın bir iş ortağı veya bayi programı aracılığıyla tedarik yapılmasına izin verdiği iş ortağı hükümlerini içerir.
Coğrafya da kararı değiştirebilir. OpenAI, desteklenen ülke ve bölgeleri dışında API erişimine erişmenin veya erişim sunmanın engellemeye veya askıya almaya yol açabileceğini belirtir. Bu nedenle müşteri kabulü yalnızca ağ geçidi şirketinin sağlayıcı hesabını kaydettirdiği ülkeye bağlı olamaz.
Önemli sonuç, her sağlayıcının tek bir kurala uymamasıdır. Tam tersi: provider_enabled gibi sağlayıcı çapında bir boole, ilgili izinleri temsil edemez.
Hakları incelemeden önce dağıtım modlarını tanımlayın
Müşterilerin model işlevselliğini nasıl alacağına ilişkin kontrollü bir kelime dağarcığı oluşturun. Pratik bir ilk sürümde beş mod kullanılabilir:
- Yerleşik iş akışı: Model, belge sınıflandırması, destek taslağı oluşturma veya yapılandırılmış çıkarma gibi tanımlı bir ürün iş akışı içinde çalışır.
- Katma değerli geliştirici platformu: Müşteriler bir API alır ancak platform, malzeme düzenleme, politika uygulama, dönüştürme, değerlendirme veya uygulama hizmetleri.
- Ham uyumlu uç nokta: Platform, model isteklerini ve yanıtlarını büyük ölçüde ortak bir API şema aracılığıyla iletir.
- Yetkili bulut yeniden satışı: Operatör, sözleşmesi önerilen tedariki kapsayan bir sağlayıcı veya bulut satıcı programına katılır model.
- Müşteriye ait BYOK: Müşteri, sağlayıcıyla sözleşme yapar ve ağ geçidi aracılığıyla kullanılmak üzere kimlik bilgilerini sağlar.
Modu pazarlama dilinden çıkarmayın. Ürünün gerçekte ne yaptığını kaydedin. Örneğin, model kimliklerini yeniden adlandırmak ve bir kullanım kontrol paneli eklemek, çalışma zamanı hizmetini işlevsel olarak ham uç noktaya eşdeğer bırakabilir.
Sürümlendirilmiş bir sağlayıcı hakları matrisi oluşturun
Kayıt, bir sağlayıcıdan veya model kataloğundan daha ayrıntılı olmalıdır. Her hak kaydı şunları içermelidir:
- Sağlayıcı ve sözleşme yapan kuruluş
- Sağlayıcı hesabı, proje, çalışma alanı, abonelik veya faturalandırma hesabı
- Doğrudan, pazar yeri, bulut programı veya bayi programı gibi satın alma kanalı
- Kapsanan model, model ailesi, hizmet veya dağıtım
- İzin verilen teslimat modları
- İzin verilen müşteri ve kullanıcı bölgeleri
- Müşteri türü kısıtlamaları
- Gerekli ürün işlevselliği veya markalama
- Yasaklı erişim biçimleri
- Sözleşme veya program adı ve geçerlilik tarihi
- Kaynak anlık görüntüsü, inceleyen ve inceleme tarihi
- Onay kapsamı, müzakere edilen istisnalar ve yenileme tarihi
- Taslak, onaylanmış, kısıtlanmış, süresi dolmuş veya askıya alınmış gibi durum
Kayıtları onaydan sonra değiştirilemez şekilde tutun.Düzeltmeler ve yenilenen izinler, geçerlilik tarihlerine sahip yeni sürümler oluşturmalıdır. Bu, bir rotanın neden geçmiş bir istek için uygun olduğunu açıklamayı mümkün kılar.
{
"rights_record_id": "rr_azure_042_v3",
"provider": "cloud_provider_a",
"account_id": "acct_042",
"purchasing_channel": "customer_solution",
"service_scope": ["model-family-x"],
"delivery_modes": ["embedded_workflow"],
"customer_regions": ["approved-region-set-1"],
"prohibited_modes": ["raw_compatible_endpoint"],
"effective_from": "2026-09-01",
"effective_to": "2027-08-31",
"status": "approved",
"evidence_id": "ev_9182"
}Sağlayıcı seçiminden önce hakları uygulayın
AI API kontrol düzlemine bir hak kabul aşaması ekleyin. Sağlık, fiyat, gecikme veya kapasite sıralamasından önce çalıştırılmalıdır. Hızlı ve ucuz olan bir rota, ticari yetkisi talebi kapsamadığında uygunsuz kalır.
Karar girişi en azından şunları içermelidir:
- Kiracı ve müşteri organizasyonu
- Doğrulanmış müşteri ve kullanıcı coğrafyası
- Ürün veya teslimat modu
- İstenen model yetenek
- Aday sağlayıcı hesabı
- Geçerli hak kaydı sürümü
- Geçerli istisna veya onay referansı
Genel yetkilendirme hatası yerine yapılandırılmış bir karar döndürün:
{
"eligible": false,
"reason_code": "DELIVERY_MODE_NOT_PERMITTED",
"rights_record_id": "rr_azure_042_v3",
"requested_mode": "raw_compatible_endpoint",
"permitted_modes": ["embedded_workflow"],
"fallback_modes": ["customer_owned_byok"]
}Bir hak kaydı eksik olduğunda, süresi dolduğunda, incelenmeyi beklediğinde, varsayılan olarak reddetme davranışını kullanın, veya coğrafi olarak belirsiz. Hesabın aynı müşteri ve mod için bağımsız olarak geçerli izne sahip olmadığı sürece farklı bir havuz hesabı üzerinden sessizce yönlendirme yapmayın.
Hak kontrollerini sıradan yetkilendirmeden ayırın
Kiracı yetkilendirmesi, arayanın bir model kullanıp kullanamayacağını yanıtlar. Hakların kabulü, operatörün bu modeli belirli bir hesap ve ürün aracılığıyla sağlayıp sağlayamayacağını yanıtlar. Her ikisinin de geçmesi gerekir.
Bu ayrım aynı zamanda müşteriye yönelik sanal anahtarların da kullanışlı olmasını sağlar. Anahtar, yukarı akış kimlik bilgilerini açığa çıkarmadan veya aktarmadan kiracıyı, bütçeyi ve model politikasını tanımlayabilir.
BYOK'u açık bir geri dönüş olarak kullanın
Havuzda toplanan kimlik bilgileri net yeniden dağıtım haklarına sahip olmadığında, doğrudan sözleşmeli bir müşteri hesabı uygulanabilir bir yol sağlayabilir. BYOK modunda sağlayıcı ilişkisinin kime ait olduğunu, sağlayıcıya kimin ödeme yaptığını, hangi ağ geçidi ücretlerinin hâlâ geçerli olduğunu ve kota veya sağlayıcının askıya alınmasıyla kimin ilgilendiğini kaydedin.
BYOK her yükümlülüğü ortadan kaldırmaz. Ağ geçidinin hâlâ güvenli kimlik bilgileri depolamasına, izin kontrollerine, sistem durumu araştırmalarına, kiracı izolasyonuna ve sağlayıcı politikası değişiklikleri sürecine ihtiyacı var. Aynı zamanda parçalanmış kapasiteye ve daha az tutarlı fiyatlandırmaya neden olur. Bu nedenle operasyonel tasarım, BYOK'u gizli bir uygulama ayrıntısı olarak değil, kendi kimlik bilgisi ve faturalandırma modu olarak ele almalıdır.
Şart değişikliklerini ve askıya alma işlemlerini her şeyi devre dışı bırakmadan yönetin
Sağlayıcı sözleşmelerini, program belgelerini, ürün şartlarını ve desteklenen ülke listelerini izleyin.İncelenen belgelerin tarihli kopyalarını veya karmalarını koruyun ve önemli bir madde, satın alma kanalı, sözleşme yapan kuruluş veya ürün tasarımı değiştiğinde yeniden onay gerektirin.
Askıya alınan bir runbook, dar kontrolleri desteklemelidir:
- Sağlayıcıyı küresel olarak devre dışı bırakmadan bir sağlayıcı hesabını devre dışı bırakın.
- Bir hesabın uygun rotalarından bir modeli veya hizmeti kaldırın.
- Tutarken bir teslimat modunu engelleyin onaylı yerleşik iş yükleri.
- Etkilenen müşteri bölgelerinden kabulü durdurun.
- Kimlik bilgilerini açığa çıkarmadan uygun müşterileri BYOK'a taşıyın.
- Etkilenen müşterileri bilgilendirin ve önceki trafik için kullanılan kabul kanıtlarını koruyun.
Havuzlanmış hesaplar entegrasyon ve faturalandırma karmaşıklığını azaltır, ancak askıya alma riskini kiracılar arasında yoğunlaştırır. BYOK, sağlayıcı ilişkilerini izole eder ancak katılım ve destek çalışmalarını artırır. Yetkili satıcı programları daha net izinler sağlayabilir ancak program kurallarını, raporlama görevlerini veya ticari taahhütleri zorunlu kılabilir. Bunlar yalnızca yönlendirme tercihleri değil, ticari ödünlerdir.
Uygulama kontrol listesi
- Her sağlayıcı hesabının ve satın alma kanalının envanterini çıkarın.
- Müşteriye sunulan her ürünü teslimat moduna göre sınıflandırın.
- Belirsiz veya üzerinde anlaşmaya varılan izinler için yasal inceleme alın.
- Oluşturun Kanıta dayalı, sürümlendirilmiş hak kayıtları.
- Eksik veya süresi dolmuş kayıtların kapatılmasının başarısız olmasını sağlayın.
- Sağlayıcının durumu, maliyet ve gecikmeden önce hakları değerlendirin.
- Yukarı akış anahtarlarını aktarmak yerine ağ geçidi kimlik bilgilerini yayınlayın.
- Müşteri coğrafyasını doğrulayın ve karar girişlerini saklayın.
- BYOK'yi tanımlayın faturalandırma ve sorumluluğu açıkça belirtin.
- Hesaba, modele, bölgeye ve moda özel askıya alma kontrollerini test edin.
- Canlı rotaları, hak kaydıyla bir plan dahilinde uzlaştırın.
- Geçerli kısıtlamaları müşteri şartlarına ve katılım kontrollerine aktarın.
Neler beklenmeli? next
Tahmin: Model katalogları, bulut kanalları, aracı hizmetleri ve bölgesel kontroller genişledikçe sağlayıcı dağıtım kurallarının daha ayrıntılı hale gelmesi muhtemeldir. Hesap ve dağıtım modu düzeyinde hakları kodlayan ağ geçitlerinin uyarlanması, sağlayıcının etkin olduğu tek bir bayrak etrafında oluşturulan sistemlerden daha kolay olacaktır. Bu bir tasarım tahminidir, mevcut sağlayıcı politikasının bir beyanı değildir.
AI API erişimini yeniden satmadan önce, her üretim rotasının bir soruyu kanıtla yanıtlamasını zorunlu kılın: Bu istek hangi sözleşme, hesap, teslimat modu ve coğrafi kapsam kapsamında sunulabilir? Sistem bu yanıtı üretemezse rota müşteri trafiği için hazır değildir.