Aanroepen binnen je regio's houden¶

Het concept achter modellen en routering staat in Modellen en routering.

Een beleid kan bepalen in welke regio's Core namens je sleutel mag werken. Zet je in policy.settings.regions_allow een lijst regio's, dan houdt Core elke bestemming van een aanroep aan die lijst: het model dat antwoordt, maar ook het embedding-model, de tools, de diensten achter een kennisconnector en de computers. Een bestemming buiten de lijst wordt geweigerd, tenzij je beleid haar met name noemt als regio-uitzondering.

Staat er geen lijst (regions_allow is null, de standaard), dan geldt niets van deze pagina.

Een regiobeperking instellen¶

De lijst staat in de settings van het beleidsdocument van een sleutel, van je organisatie of van allebei:

{
  "settings": {
    "regions_allow": ["eu"]
  }
}

Een regio schrijf je als eu, us, global, in-cluster (de eigen infrastructuur van je installatie) of een landcode van twee letters zoals nl. Regio's liggen in elkaar: in-cluster en elke EU-lidstaat liggen in eu, en alles ligt in global. Een bestemming in nl voldoet dus aan een lijst met eu; een bestemming in us of global niet. Een lege lijst wordt geweigerd.

In de console staan deze velden onder Waar gegevens heen mogen, op de kaart Instellingen van de policy van een sleutel en van de organisatie (Sleutels). Een sleutel met management zet ze via de API: PATCH /keys/{key_id} met policy voor een sleutel, PUT /organisation/policy voor de organisatie (Organisaties beheren via de API). Beide vervangen het hele document, dus lees het eerst met GET /keys/{key_id} of GET /organisation/policy en stuur het compleet terug, met rules erbij: een instelling die je weglaat, valt terug op haar standaard, en een document zonder rules krijgt de standaardregels, die geen host voor een tool en geen schrijven van geheugen toestaan. Stuur de versie die je las mee in If-Match, zodat je geen wijziging overschrijft die iemand tussen je lezen en je schrijven heeft opgeslagen (Sleutels uitgeven, roteren en intrekken).

Elk document telt. Beperken je sleutel, je organisatie en de organisaties erboven de regio's, dan moet een bestemming aan elk daarvan voldoen. Een sleutel kan het beleid van zijn organisatie dus alleen verder beperken, nooit verruimen, en een organisatie beperkt alleen verder wat de organisaties erboven toelaten (De organisaties erboven tellen ook mee).

Waar het voor geldt¶

Het embedding-model valt ook onder je regels over modellen, met of zonder regiolijst: een beleid dat modellen beperkt, moet ook het embedding-model toestaan (Kennis).

Een bestemming waarvan niemand de regio heeft opgegeven, wordt geweigerd: Core neemt niet aan dat ze wel goed zit. Elke weigering staat in je auditspoor als policy.decision met decision: denied.

Regio-uitzonderingen¶

Soms moet één bestemming buiten je regio's bereikbaar zijn: een Amerikaanse zoekdienst onder een EU-beleid, of één model dat alleen elders draait. us aan je lijst toevoegen zou dan elke Amerikaanse bestemming openzetten, modellen inbegrepen. Noem die ene bestemming in plaats daarvan in policy.settings.region_exceptions:

{
  "settings": {
    "regions_allow": ["eu"],
    "region_exceptions": ["builtin:web_search", "host:api.tickets.example.com"]
  }
}

Elke regel noemt precies één bestemming, in een van deze vormen:

Een andere vorm geeft 422. Een uitzondering telt alleen in een document dat zelf regio's beperkt.

Elk document moet de bestemming toelaten. Elk document dat regio's beperkt, wordt apart geraadpleegd: het laat een bestemming toe als zijn eigen regions_allow de plaats toelaat óf zijn eigen region_exceptions de bestemming noemt. Houdt je organisatie zich aan eu, dan helpt een uitzondering op je sleutel alleen als het organisatiebeleid dezelfde bestemming ook noemt. Laat je organisatie us al toe, dan hoeft ze de uitzondering van je sleutel voor een Amerikaans model niet te herhalen. Een host:-jokerteken dekt de hosts eronder, dus host:*.firecrawl.dev op de organisatie en host:api.firecrawl.dev op de sleutel laten samen api.firecrawl.dev door. Een dienst telt als genoemd onder zijn eigen naam en onder de host die hij gebruikt. Hetzelfde geldt voor elke organisatie boven de jouwe die regio's beperkt (De organisaties erboven tellen ook mee).

Waar de bestemming ook draait, ook als niemand dat weet. Een uitzondering noemt een bestemming, geen plaats. Ze dekt dus ook een bestemming waarvan niemand de regio opgaf, zoals een MCP-server zonder region. Omdat geen enkele regio een onbekende plaats toelaat, moet dan elk document dat regio's beperkt de bestemming zelf noemen.

Een uitzondering heft verder niets op. De regels van je beleid, voor modellen, tools, hosts en personen (Je eerste regel schrijven), de hosts die je organisatie toestaat, de hosts die je installatie blokkeert en de hosting.region van een beurt gelden gewoon. Vraagt een verzoek hosting.region: "eu", dan wordt een model buiten de EU geweigerd, ook als het beleid er een uitzondering voor heeft: wie het verzoek stuurde, vroeg om die plaats.

Elk gebruik wordt vastgelegd. Een aanroep die door een uitzondering doorgaat, staat in het auditspoor als policy.decision met decision: allowed en reason: allowed by residency exception; refs noemt de uitzondering die het toeliet.

Leveranciers aan plaatsen houden¶

Een regio zegt waar een aanroep verwerkt wordt, niet wie hem verwerkt. Een model dat in de EU draait bij een bedrijf met een moederbedrijf in de Verenigde Staten, valt onder allebei. policy.settings.vendors_allow houdt het bedrijf achter elke bestemming aan plaatsen, en een model aan open gewichten:

{
  "settings": {
    "vendors_allow": {
      "established_in": ["eu"],
      "parent_in": ["eu"],
      "open_weights": true
    }
  }
}

• established_in noemt waar het bedrijf achter een bestemming gevestigd mag zijn, parent_in waar het uiteindelijke moederbedrijf gevestigd mag zijn, gespeld zoals regions_allow. Laat er een weg om er niet naar te vragen.
• open_weights: true laat alleen modellen toe waarvan de gewichten gepubliceerd zijn, zodat een andere host ze kan draaien.
• Wat niemand heeft opgegeven, telt als global; een eis die eu noemt, weigert het dus tot iemand het opgeeft. Geen regio-uitzondering heft zo'n weigering op.

Je beheerder geeft per modelprovider op wie hem draait en per model of de gewichten open zijn; GET /models toont beide als vendor en open_weights. Voor wat je zelf registreert, geef je het zelf op: vendor op een API-connector, een MCP-server of een event-webhook, en callback_vendor naast de callback_url van een run, telkens {"established_in": "nl", "parent_in": "nl"}; een bedrijf zonder moederbedrijf geeft zijn eigen plaats. GET /key geeft in vendors_allow elke eis waaronder je sleutel beslist wordt. Elk document telt mee, net als bij regio's, en de console heeft voor deze instelling nog geen veld: je schrijft hem via de API, en opslaan in de console laat hem staan. Een geweigerd model antwoordt 403 met The model is not run by a company this key allows. of The model's weights are not open, as this key requires.

De organisaties erboven tellen ook mee¶

Hangt je organisatie onder een andere, dan wegen de drie lijsten onder policy.settings van elke organisatie erboven (regions_allow, region_exceptions en host_regions) mee naast die van je organisatie en je sleutel. Die documenten kun je niet lezen, tenzij je die organisaties ook beheert. Dit doen ze met je aanroepen:

• De regio's moeten elkaar raken. Een bestemming moet binnen de regions_allow liggen van elk document dat er een heeft. Een organisatie erboven die zich aan eu houdt, houdt elke organisatie eronder in eu, wat hun eigen lijsten ook zeggen.
• Elk beperkend document moet de bestemming toelaten of noemen. Een uitzondering in jouw beleid laat een bestemming alleen door als elke organisatie erboven die regio's beperkt de plaats zelf toelaat of dezelfde bestemming bij haar eigen uitzonderingen noemt. Doet een organisatie erboven geen van beide, vraag dan haar beheerder de uitzondering toe te voegen.
• Een host die erboven is geplaatst, is ook voor jou geplaatst. Geeft een organisatie erboven in haar host_regions op waar een host draait, dan hoef jij dat niet nog eens te doen. Plaatsen jouw document en een document erboven dezelfde host in twee verschillende regio's, dan geldt de host als nergens geplaatst en wordt hij geweigerd als onbekend. Haal dan je eigen opgave weg, of vraag de beheerder erboven welke regio daar staat.

Zien waar je aanroepen heen mogen¶

GET /key geeft in residency wat alle documenten waaronder je sleutel wordt beslist samen toelaten: dat van je sleutel, dat van je organisatie en die van de organisaties erboven.

{
  "residency": {
    "regions_allow": ["eu"],
    "region_exceptions": [
      { "exception": "builtin:web_search", "where": null }
    ]
  }
}

• regions_allow is waar alle lijsten elkaar raken. Leeg betekent dat ze niets gemeen hebben, en dan is geen enkele bestemming bereikbaar.
• region_exceptions noemt elke uitzondering van je sleutel en je organisatie waarmee je aanroepen worden beslist, met where: null als de bestemming overal bereikbaar is, omdat elk beperkend document haar noemt. Noemt een beperkend document haar niet, dan geeft where de plaatsen die dat document zelf toelaat. Houdt je organisatie zich aan eu en noemt ze een model als uitzondering, terwijl je sleutel alleen us toelaat, dan staat dat model er met where: ["us"], ook al is regions_allow dan leeg. Een uitzondering die niets toevoegt aan regions_allow, staat er niet in. De uitzonderingen van een organisatie erboven wegen mee en staan er niet in.
• residency is null als geen enkel document regio's beperkt.

De lijsten met modellen houden ook rekening met uitzonderingen: een model dat alleen door een uitzondering bereikbaar is, staat in GET /models en is allowed in ?kind=image, ?kind=audio en ?kind=embedding (Modellen die je sleutel bereikt zonder ze te noemen).

Werk dat in de console begint¶

Wat iemand in de console doet voor je organisatie, valt onder de regiokeuzes van de organisatie: een zoekopdracht of Probeer het op een zoektool, een pipelinetest, het schrijven van een skill, de test van een connector, en het inlezen van een bron of connector die iemand in de console heeft ingesteld. Ook wat een geïnstalleerde publicatie voor je organisatie doet, valt eronder. Daarvoor tellen regions_allow, region_exceptions en host_regions van het organisatiebeleid, en dezelfde drie lijsten van elke organisatie erboven. Van de regels tellen alleen die over bestemmingen: die van de organisatie zelf (Toegestane hosts) en die van de organisaties erboven. De overige regels en instellingen zijn voor sleutels, en wie in de console werkt, is geen sleutel. Beperkt de organisatie geen regio's, en ook geen organisatie erboven, dan is dat werk niet op regio beperkt.

Een actie die tekst inbedt met een model buiten die regio's, wordt geweigerd met The embedding model is not hosted in a region this organisation allows.