Model Router verdeelt verzoeken over meerdere AI-providers, maar lost vendor lock-in niet vanzelf op

Microsofts Model Router in Foundry kan verzoeken sinds 6 oktober 2026 over modellen van meerdere providers verdelen met automatische fallback en per-verzoek routemetadata. Dat beperkt uitval van één model, maar vermindert vendor lock-in alleen aantoonbaar met minstens twee toegestane providers, een onafhankelijke control plane en een getest exitpad.

Wat heeft Microsoft precies aan Model Router in Foundry gewijzigd?

Microsoft heeft in zijn documentatie van 6 oktober 2026 beschreven dat Model Router verzoeken dynamisch kan verdelen over modellen van OpenAI, Anthropic, xAI, Fireworks, DeepSeek en Meta. Standaard is automatische failover naar een ander geschikt model beschikbaar, en per verzoek kan de router routingmetadata, de geordende volgorde van modelpogingen, de HTTP-statussen en het fallbackbesluit rapporteren.

Volgens de bijgewerkte Model Router-documentatie van Microsoft betekent dit dat een applicatie niet langer stilvalt zodra één onderliggend model niet reageert: het verkeer kan naar een alternatief model worden geleid, en dat besluit laat een spoor achter. Voor organisaties die operationele veerkracht en controleerbaarheid belangrijk vinden, is dat een concrete stap vooruit. De conceptdocumentatie voegt wel een harde randvoorwaarde toe: een eigen deployment heeft minstens twee modellen in de subset nodig om fallback te benutten.

Waarom betekent modelrouting over meerdere providers nog geen onafhankelijkheid van het platform?

Routeren tussen modellen binnen één platform is iets anders dan onafhankelijk zijn van dat platform. Microsoft stelt in zijn gids over hoge beschikbaarheid en veerkracht voor Foundry expliciet dat Foundry zelf geen automatische disaster recovery of failover voor de volledige oplossing biedt. Bij regionale of endpointuitval moet de applicatie, of een gateway, het verkeer naar een tweede deployment leiden.

De grens zit dus niet bij het model, maar bij de laag eromheen. De conceptdocumentatie van Model Router waarschuwt bovendien dat de actieve routerversie doorlopend nieuwe onderliggende modellen kan toevoegen, en dat het kleinste onderliggende contextvenster — de hoeveelheid tekst die een model in één keer kan verwerken — de effectieve grens voor alle verzoeken kan bepalen. Naar onze inschatting ontstaat hier een nieuw, vaak onopgemerkt risico: wie de router als vanzelfsprekende onafhankelijkheid presenteert, verplaatst het concentratiepunt van het model naar de router zelf. Als de router, de authenticatie, de quota of de netwerkverbinding naar dat ene platform uitvalt, helpt modeldiversiteit niet.

Dat Microsoft dit niet uniek maakt, blijkt uit een vergelijkbaar ontwerp elders. In de documentatie over Unity Gateway als centrale AI-governancelaag beschrijft Azure Databricks routing, traffic splitting, fallbacks en auditlogging over externe providers als afzonderlijke capaciteiten van de gateway — niet van het model. Dat bevestigt dat providerkeuze, fallback en audit een eigen control plane verdienen.

Wat betekent dit voor bestuurders, juristen en CISO's die concentratierisico willen beheersen?

Onze analyse: omdat Model Router bij een aangepaste subset minstens twee modellen nodig heeft om fallback te benutten, kan zonder expliciet subsetbeheer schijnveerkracht ontstaan die bij uitval alsnog faalt; daarom laat de CISO vastleggen welke modellen wegens privacy, regio, contextvenster of taakvereiste wel en niet zijn toegestaan, vóór de volgende release. Omdat Microsoft zelf stelt dat Foundry geen disaster recovery voor de volledige oplossing biedt, blijft de applicatie kwetsbaar voor regionale en endpointuitval ondanks modeldiversiteit; daarom laat de verantwoordelijke architect een tweede deployment, onafhankelijke quota en periodieke failovertests inrichten, en legt de bestuurder die test als terugkerende verplichting vast. Omdat de actieve routerversie doorlopend nieuwe onderliggende modellen kan toevoegen en het kleinste contextvenster de effectieve grens bepaalt, kan een gevalideerde workflow stilletjes veranderen; daarom spreekt de jurist in het contract versiecontrole, wijzigingsmelding en een afdwingbaar auditrecht met concreet inspectiebewijs af. Omdat de router per verzoek route-, model-, fout- en fallbackgegevens kán rapporteren maar dat niet vanzelf bewijswaarde geeft, blijft verantwoording achteraf naar onze inschatting zwak zonder een gekoppeld beslisrecord; daarom laat de verantwoordelijke manager per verzoek modelidentiteit, versie, pogingvolgorde, status, fallbackbesluit, dataclassificatie en menselijke vrijgave aan elkaar koppelen en bewaren.

Welke voorwaarden maken modelrouting aantoonbaar veerkrachtig tegen uitval en lock-in?

Naar onze analyse reduceert modelrouting concentratierisico alleen aantoonbaar als providerdiversiteit, route-onafhankelijkheid, compatibiliteit, observability en een getest exitpad samen worden beheerd. De volgende punten volgen uit de Microsoft-documentatie en uit onze analyse daarvan.

• Echte modeldiversiteit: configureer naar onze inschatting minstens twee inhoudelijk geschikte modellen van verschillende providers en documenteer per model waarom het wel of niet mag worden gebruikt. Microsoft beschrijft dat zonder tweede model in de subset fallback niet werkt.
• Onafhankelijke control plane: laat routing, circuit breaking, toegangsbeleid, quota en fallback naar onze inschatting niet uitsluitend afhangen van dezelfde provider als de primaire modellen; leg vast wat gebeurt als de router, authenticatie of quota uitvalt. Dit sluit aan bij het beheersen van providerconcentratie in de AI-leveranciersketen vastleggen.
• Compatibiliteit en versiecontrole: test incompatibele contextvensters en gewijzigde modelversies, omdat de routerversie volgens Microsoft kan veranderen en het kleinste venster de grens bepaalt.
• Bewijs per verzoek: registreer modelidentiteit, versie, route, pogingvolgorde, status, fouttype, fallbackbesluit, dataclassificatie en menselijke escalatie. Let op dat eensgezinde modellen geen onafhankelijke controle bewijzen; zie waarom meerdere modellen geen onafhankelijke verificatie bewijzen.
• Getest exitpad: onderhoud een alternatief pad naar een andere gateway of lokaal model en test provideruitval, quota-uitputting en herstel periodiek.

Naar onze inschatting zet wie deze vijf lagen gezamenlijk belegt de winst van multi-model routing om in aantoonbare veerkracht, terwijl wie één laag overslaat de afhankelijkheid van één platform in stand houdt. Meer context over het beheersen van dit soort afhankelijkheden staat in de themahub over AI-governance en beheersing.

Bronnen: Het artikel steunt op officiële Microsoft Learn-documentatie over Model Router, de Foundry-veerkrachtgids en Azure Databricks Unity Gateway.