Model Router verdeelt verzoeken over AI-providers

U moet vastleggen welke AI-modellen in uw workflows zijn toegestaan, welke providers onafhankelijk van elkaar bereikbaar zijn, hoe u terugvalt als één provider uitvalt, wat u per verzoek registreert, en hoe u periodiek test dat u werkelijk kunt uitwijken naar een alternatief.

Een analyse van 28 oktober 2026 van modelrouting over meerdere AI-providers met automatische fallback stelt dat concentratierisico alleen afneemt als u minstens twee providers, een onafhankelijke control plane en een getest exitpad samen beheert. De casus is Microsoft Model Router in Foundry, dat sinds 6 oktober 2026 verzoeken dynamisch over modellen van OpenAI, Anthropic, xAI, Fireworks, DeepSeek en Meta kan verdelen met automatische fallback en per-verzoek routemetadata. In onze inschatting ligt hier een kritiek punt: wie modelrouting 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.

Welke risico's ontstaan als u modellen routeert zonder onafhankelijke controle?

Modelrouting binnen één platform biedt operationele veerkracht tegen uitval van één model, maar niet tegen uitval van het platform zelf. Microsoft stelt expliciet dat Foundry geen automatische disaster recovery of failover voor de volledige oplossing biedt. Bij regionale of endpointuitval moet uw applicatie of gateway het verkeer naar een tweede deployment leiden. De conceptdocumentatie 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.

De volgende foutmodi ontstaan zonder expliciete controle:

• Schijnveerkracht door onvolledig subsetbeheer — fallback werkt alleen als minstens twee modellen in uw subset zijn toegestaan; zonder vastgestelde keuze kan de router stilletjes naar een enkel model terugvallen.
• Regionale en endpointuitval — de router zelf is een enkel contactpunt; uitval van het platform treft alle modellen tegelijk.
• Stille wijziging van gevalideerde workflows — nieuwe modellen in de routerversie en veranderde contextvensters kunnen uw toepassing onverwacht breken.
• Zwakke verantwoording achteraf — routemetadata per verzoek geeft geen bewijswaarde zonder gekoppeld beslisrecord en classificatie.
• Contractuele blinde vlekken — versiecontrole, wijzigingsmelding en inspectiebewijs zijn niet standaard afgedwongen.

Welke controles moet u aantoonbaar kunnen demonstreren?

Modelrouting reduceert concentratierisico alleen aantoonbaar als providerdiversiteit, route-onafhankelijkheid, compatibiliteit, observability en een getest exitpad samen worden beheerd. U moet kunnen aantonen:

1. Expliciete subsetbeheer per rol — uw CISO legt vast welke modellen wegens privacy, regio, contextvenster of taakvereiste wel en niet zijn toegestaan, vóór elke release.
2. Tweede deployment met onafhankelijke quota — uw architect richt een tweede deployment in met eigen authenticatie, quota en netwerkpad, en test failover periodiek.
3. Versiecontrole en wijzigingsmelding in contract — uw jurist spreekt af dat de provider versies, wijzigingen en een afdwingbaar auditrecht met concreet inspectiebewijs garandeert.
4. Gekoppeld beslisrecord per verzoek — uw manager koppelt modelidentiteit, versie, pogingvolgorde, HTTP-status, fallbackbesluit, dataclassificatie en menselijke vrijgave aan elkaar en bewaart dit.
5. Periodieke failovertests met terugkerende verplichting — uw bestuurder legt vast dat failover naar het alternatief minstens één keer per kwartaal wordt getest en gedocumenteerd.

Hoe onderscheidt u routering van echte onafhankelijkheid?

Routering tussen modellen is iets anders dan onafhankelijkheid van het platform. Een vergelijkbaar ontwerp bij Azure Databricks Unity Gateway beschrijft routing, traffic splitting, fallbacks en auditlogging als afzonderlijke capaciteiten van de gateway — niet van het model. Dit bevestigt dat providerkeuze, fallback en audit een eigen control plane verdienen. Zonder die scheiding verplaatst u het concentratiepunt van het model naar de router, en u bent nog steeds afhankelijk van één platform.

Wat kan tooling doen en wat blijft uw eigen oordeel?

Routemetadata per verzoek, automatische fallback en subsetbeheer zijn mechanische taken die tooling betrouwbaar uitvoert. Wat tooling niet kan doen: bepalen welke modellen voor uw gegevens en doeleinden geschikt zijn, vastleggen welke providers u werkelijk onafhankelijk kunt bereiken, testen of failover in uw context werkelijk werkt, en verantwoorden waarom u op dit moment op deze provider vertrouwt. Die keuzes blijven uw professioneel oordeel. Tooling ondersteunt dat oordeel alleen als u eerst hebt bepaald wat u wilt bereiken en welke risico's u accepteert.