Kunt u AI API-toegang doorverkopen? Bouw een matrix met providerrechten voordat u start
Een werkende providersleutel bewijst niet dat u de API ervan mag herdistribueren. Bouw een rechtenmatrix met versiebeheer en dwing commerciële machtigingen af tijdens de toegang van klanten en het routeren van verzoeken.
Als een provider uw API-verzoek accepteert, betekent dit niet dat u toestemming heeft om dezelfde toegang aan klanten te verkopen. Technische beschikbaarheid en commerciële rechten zijn afzonderlijke voorwaarden.
Dit onderscheid is van belang wanneer u een AI API resellerplatform exploiteert, een compatibel eindpunt beschikbaar stelt of meerdere providers achter één sleutel bundelt. Upstream-voorwaarden kunnen een toepassing toestaan die modeluitvoer gebruikt, onbewerkte pass-through-toegang verbieden, een resellerovereenkomst vereisen, klantlocaties beperken of alleen inloggegevens van de klant toestaan.
De praktische oplossing is om distributierechten te behandelen als een routeringsmogelijkheid. Voordat een klant wordt toegelaten of een providerroute wordt geselecteerd, moet de gateway verifiëren dat het relevante account, model, leveringsmodus en klantgeografie onder de gedocumenteerde toestemming vallen.
Reikwijdte: Dit is operationele architectuur en begeleiding bij het opsporen van problemen, geen juridisch advies. De definitieve toestemming is afhankelijk van uw uitgevoerde overeenkomsten, aankoopkanalen, productontwerp en gekwalificeerde juridische beoordeling.
Waarom een werkende API-sleutel niet genoeg is
In overeenkomsten van aanbieders wordt doorgaans onderscheid gemaakt tussen verschillende commerciële relaties:
- Een applicatie gebruikt een model om functionaliteit aan zijn eindgebruikers te bieden.
- Een platform voegt substantiële workflow-, beleids- of orkestratiefuncties rond het model toe. gevolgtrekking.
- Een wederverkoper levert een providerservice onder een geautoriseerd partnerprogramma.
- Een gateway stelt een onbewerkt of licht gewijzigd providereindpunt bloot.
- Een klant koppelt zijn eigen provideraccount via 'bring-your-own-key' of BYOK.
Deze regelingen zijn niet uitwisselbaar. Uniforme facturering, analyse, routering en klantgerichte sleutels creëren echte waarde, maar ze zetten onbewerkte herdistributie niet automatisch om in een geautoriseerde klanttoepassing.
Referentieregels staan ook los van distributierechten. Zelfs wanneer een overeenkomst toestaat dat een applicatie eindgebruikers bedient, kan deze nog steeds de verkoop of overdracht van upstream-sleutels of accounttoegang verbieden. Downstream-klanten moeten door de gateway uitgegeven inloggegevens ontvangen, nooit de samengevoegde providerreferenties.
Wat de huidige providervoorwaarden illustreren
Hier volgen feitelijke voorbeelden die vóór gebruik moeten worden gecontroleerd aan de hand van de huidige documenten en uw eigen overeenkomsten:
- OpenAI: De serviceovereenkomst staat API integratie in klantapplicaties toe die beschikbaar zijn gesteld om te beëindigen gebruikers. Het verbiedt afzonderlijk het kopen, verkopen of overdragen van API sleutels en het doorverkopen of leasen van toegang tot een account of eindgebruikersaccount.
- Anthropic: De Commerciële Voorwaarden staan klanten toe services te gebruiken om producten en services aan te bieden die aan hun klanten en gebruikers worden aangeboden, terwijl de wederverkoop van Anthropic services zonder uitdrukkelijke toestemming wordt verboden.
- Microsoft Azure: Volgens de richtlijnen voor Azure-klantoplossingen is eenvoudige wederverkoop van API's voor modelinferentie op deze route niet toegestaan. Het identificeert onbewerkte of dun verpakte output, ongewijzigde eindpuntblootstelling en routering tussen inferentieproviders zonder output vorm te geven als voorbeelden die niet in aanmerking komen. Een in aanmerking komende oplossing moet primaire en significante functionaliteit toevoegen en de inferentie-API's binnen het platform houden.Bedrijven die daadwerkelijk Azure-wederverkoop zoeken, worden doorverwezen naar het Cloud Solution Provider-programma.
- Google Cloud: De algemene voorwaarden verbieden het verkopen, doorverkopen, in sublicentie geven, overdragen of distribueren van services. Servicespecifieke voorwaarden omvatten partnerbepalingen waarbij de geldende overeenkomst levering via een partner- of resellerprogramma toestaat.
Geografie kan de beslissing ook wijzigen. OpenAI stelt dat toegang tot of het aanbieden van API toegang buiten de ondersteunde landen en gebieden kan leiden tot blokkering of opschorting. De toegang van klanten kan daarom niet alleen afhankelijk zijn van het land waarin het gateway-bedrijf zijn provideraccount heeft geregistreerd.
De belangrijke conclusie is niet dat elke provider één regel volgt. Het tegenovergestelde is het geval: een boolean voor de hele provider, zoals provider_enabled kan de relevante machtigingen niet vertegenwoordigen.
Definieer leveringsmodi voordat u de rechten beoordeelt
Maak een gecontroleerd vocabulaire voor hoe klanten modelfunctionaliteit ontvangen. Een praktische eerste versie kan vijf modi gebruiken:
- Ingebedde workflow: Het model werkt binnen een gedefinieerde productworkflow, zoals documentclassificatie, ondersteunend opstellen of gestructureerde extractie.
- Ontwikkelaarsplatform met toegevoegde waarde: Klanten ontvangen een API, maar het platform voegt materiële orkestratie, beleidshandhaving, transformatie, evaluatie, of applicatieservices.
- Ruw compatibel eindpunt: Het platform geeft modelaanvragen en -reacties grotendeels door via een gemeenschappelijk API schema.
- Geautoriseerde wederverkoop in de cloud: De operator neemt deel aan een provider- of cloudresellerprogramma waarvan de overeenkomst het voorgestelde leveringsmodel omvat.
- Eigendom van de klant BYOK: De klant sluit een contract af met de provider en verstrekt inloggegevens voor gebruik via de gateway.
Leid de modus niet af uit marketingtaal. Leg vast wat het product daadwerkelijk doet. Als u bijvoorbeeld de naam van model-ID's wijzigt en een gebruiksdashboard toevoegt, kan de runtime-service nog steeds functioneel gelijkwaardig blijven aan een onbewerkt eindpunt.
Ontwikkel een matrix met versiebeheer van providerrechten
Het register moet gedetailleerder zijn dan een provider- of modelcatalogus. Elke rechtenrecord moet het volgende bevatten:
- Provider en contracterende entiteit
- Provideraccount, project, werkruimte, abonnement of factureringsaccount
- Aankoopkanaal, zoals direct, marktplaats, cloudprogramma of resellerprogramma
- Gedekt model, modelfamilie, service of implementatie
- Toegestane leveringsmodi
- Toegestane klant- en gebruikersregio's
- Beperkingen voor het klanttype
- Vereiste productfunctionaliteit of branding
- Verboden vormen van toegang
- Overeenkomst- of programmanaam en ingangsdatum
- Snapshot van de bron, reviewer, en beoordelingsdatum
- Goedkeuringsbereik, onderhandelde uitzonderingen en verlengingsdatum
- Status zoals concept, goedgekeurd, beperkt, verlopen of opgeschort
Houd records na goedkeuring onveranderlijk.Correcties en hernieuwde machtigingen zouden nieuwe versies met ingangsdatums moeten creëren. Dat maakt het mogelijk uit te leggen waarom een route in aanmerking kwam voor een historisch verzoek.
{
"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"
}Rechten afdwingen vóór selectie van provider
Voeg een fase voor rechtentoelating toe aan het AI API-controlevlak. Het moet worden uitgevoerd vóór status, prijs, latentie of capaciteitsrangschikking. Een route die snel en goedkoop is, komt niet in aanmerking als het commerciële recht het verzoek niet dekt.
De invoer van de beslissing moet ten minste het volgende bevatten:
- Huurder- en klantorganisatie
- Geverifieerde klant- en gebruikersgeografie
- Product- of leveringsmodus
- Aangevraagd model mogelijkheid
- Kandidaataanbiederaccount
- Huidige versie van de rechtenrecord
- Toepasselijke uitzonderings- of goedkeuringsreferentie
Een gestructureerde beslissing retourneren in plaats van een algemene autorisatiefout:
{
"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"]
}Gebruik standaard weigeren-gedrag wanneer een rechtenrecord ontbreekt, is verlopen of in afwachting is van beoordeling, of geografisch dubbelzinnig. Ga niet stilletjes door een ander samengevoegd account, tenzij dat account onafhankelijk geldige toestemming heeft voor dezelfde klant en modus.
Afzonderlijke rechtencontroles van gewone autorisatie
Tenantautorisatie geeft aan of een beller een model mag gebruiken. Toegang tot rechten geeft antwoord op de vraag of de exploitant dat model via een bepaald account en product mag leveren. Beide moeten slagen.
Deze scheiding zorgt er ook voor dat virtuele sleutels voor de klant nuttig blijven. De sleutel kan het tenant-, budget- en modelbeleid identificeren zonder de upstream-referentie openbaar te maken of over te dragen.
Gebruik BYOK als een expliciete terugval
Wanneer gepoolde inloggegevens geen duidelijke herdistributierechten hebben, kan een rechtstreeks gecontracteerde klantaccount een werkbare route bieden. Leg in de BYOK-modus vast wie eigenaar is van de providerrelatie, wie de provider betaalt, welke gatewaykosten nog steeds van toepassing zijn en wie quota of opschortingen van de provider afhandelt.
BYOK neemt niet elke verplichting weg. De gateway heeft nog steeds veilige opslag van inloggegevens, toestemmingscontroles, statustests, huurderisolatie en een proces voor wijzigingen in het providerbeleid nodig. Het leidt ook tot gefragmenteerde capaciteit en minder consistente prijzen. Het operationele ontwerp moet BYOK daarom behandelen als zijn eigen referentie- en factureringsmodus, en niet als een verborgen implementatiedetail.
Verander wijzigingen en opschortingen in de voorwaarden zonder alles uit te schakelen
Bewaak leveranciersovereenkomsten, programmadocumenten, productvoorwaarden en lijsten met ondersteunde landen.Bewaar gedateerde kopieën of hashes van beoordeelde documenten en vereis hergoedkeuring wanneer een belangrijke clausule, aankoopkanaal, contracterende entiteit of productontwerp verandert.
Een opschortingsrunbook moet beperkte controles ondersteunen:
- Schakel één provideraccount uit zonder de provider wereldwijd uit te schakelen.
- Verwijder één model of dienst uit de in aanmerking komende routes van een account.
- Blokkeer een leveringsmodus terwijl de goedgekeurde blijft ingebedde productietaken.
- Stop de toegang uit getroffen klantregio's.
- Verplaats in aanmerking komende klanten naar BYOK zonder inloggegevens vrij te geven.
- Stel getroffen klanten op de hoogte en bewaar het toegangsbewijs dat is gebruikt voor eerder verkeer.
Gepoolde accounts verminderen de integratie en de complexiteit van facturering, maar concentreren het risico op opschorting voor alle tenants. BYOK isoleert de relaties met leveranciers, maar vergroot de onboarding- en ondersteuningswerkzaamheden. Geautoriseerde resellerprogramma's kunnen duidelijkere toestemming geven, maar programmaregels, rapportageverplichtingen of commerciële verplichtingen opleggen. Dit zijn zakelijke afwegingen, niet alleen maar routeringsvoorkeuren.
Implementatiechecklist
- Inventariseer elk provideraccount en aankoopkanaal.
- Classificeer elk klantgericht product op leveringswijze.
- Zorg voor een juridische beoordeling van dubbelzinnige of onderhandelde toestemmingen.
- Creëer op bewijsmateriaal gebaseerde, Versiebeheerde rechtenrecords.
- Zorg ervoor dat ontbrekende of verlopen records mislukt worden gesloten.
- Evalueer de rechten vóór de status, kosten en latentie van de provider.
- Geef gatewaygegevens uit in plaats van upstream-sleutels over te dragen.
- Verifieer de geografie van de klant en bewaar de beslissingsinvoer.
- Definieer BYOK-facturering en verantwoordelijkheid expliciet.
- Test account-, model-, regio- en modusspecifieke opschortingscontroles.
- Reconcilieer live routes met het rechtenregister volgens een schema.
- Verwerk toepasselijke beperkingen in klantvoorwaarden en introductiecontroles.
Wat u kunt verwachten volgende
Voorspelling: Distributieregels voor providers zullen waarschijnlijk gedetailleerder worden naarmate modelcatalogi, cloudkanalen, agentservices en regionale controles zich uitbreiden. Gateways die rechten coderen op account- en leveringsmodusniveau zullen gemakkelijker aan te passen zijn dan systemen die zijn gebouwd rond een enkele, door de provider ingeschakelde vlag. Dit is een ontwerpvoorspelling, geen verklaring van het huidige providerbeleid.
Voordat u AI API-toegang doorverkoopt, moet u van elke productieroute eisen dat deze één vraag met bewijs beantwoordt: onder welke overeenkomst, account, leveringsmodus en geografische reikwijdte mag dit verzoek worden ingediend? Als het systeem dat antwoord niet kan geven, is de route niet gereed voor klantverkeer.