U hebt geen modelleverancier gekozen. U hebt er een verzameld.

Wat zich opstapelde, en hoe

Geen enkel bestuur keurt een eenleverancierstrategie voor de modellaag goed. De concentratie komt applicatie per applicatie binnen. De eerste gecomponeerde applicatie roept de SDK aan die die dag openstond. De tweede kopieert de eerste, want dat is precies waar componeren voor dient. Bij de vierde is het patroon huisstijl geworden, en de huisstijl een afhankelijkheid.

Dat is dezelfde zin als de faalwijze die de governance al benoemt: zodra een gecomponeerde applicatie data bevat die nergens anders bestaat, is ze stilletjes een system of record geworden. Niemand heeft dat gebouwd; het is ontstaan. Modelconcentratie heeft dezelfde vorm, één laag lager — en ze is moeilijker te zien, want er staat niets op het architectuurschema om naar te wijzen. De afhankelijkheid is een regel in een configuratiebestand.

Het goedkoopste wat u bouwde, draagt de diepste afhankelijkheid.

Twee afhankelijkheden, twee urgenties

Ze worden routineus door elkaar gehaald, en dat levert het verkeerde budget op. De ene is een productiviteitsvraag met een draaglijke faalwijze. De andere is een continuïteitsvraag met een geruisloze.

Het menselijke gebruik is een echte troef, en het model dat er draait is misschien gewoon het beste voor dat werk. Niets hier pleit ervoor daaraan te raken. Wat overblijft: het hulpmiddel, de gewoonte en de productiviteit die ermee kwam. De remedie is smaller en goedkoper dan van leverancier wisselen — roep geen enkele leverancier rechtstreeks aan vanuit iets waar het bedrijf van afhangt.

Waarom er geen beschikbaarheidscijfer in dit stuk staat

Het zou makkelijk zijn te openen met een cijfer van een statuspagina. Zulke cijfers bewegen wekelijks, elk ervan is betwistbaar, en een lezer die het cijfer betwist, betwist het argument dat eraan hangt. Het argument heeft er geen nodig. Het vraagt alleen de erkenning dat u nooit een beschikbaarheidsafspraak hebt onderhandeld voor datgene waar uw workflow nu op steunt. Dat kost dertig seconden op een prijspagina, en het antwoord is bijna altijd hetzelfde.

Wat wél de moeite is: de vorm van de rekensom, niet de positie van een leverancier daarop. Enterprisecontracten gaan routineus uit van drie negens. Consumenten- en developertarieven van frontier-modeldiensten beloven doorgaans niets.

De toets die u al hanteert

Elke sourcingdoctrine die naam waardig draagt de vraag die dit beslecht: kunnen wij binnen zes maanden van leverancier wisselen zonder de capaciteit te verliezen? Is het antwoord nee, dan is de afhankelijkheid te diep om een partnerschap te heten. De meeste bedrijven passen die toets toe op hun integrator, hun platformleverancier en hun bureau. Bijna niemand past hem toe op de modellaag, want die zag er nooit uit als een leverancier. Ze zag eruit als een functie.

Dan de tweede regel: koop wat commodity is, bouw wat differentieert, componeer de lange staart. Een router tussen uw applicaties en de modelleveranciers is commodity. Niemand waardeert uw bedrijf hoger omdat u er zelf een schreef, er bestaan degelijke producten in die categorie, en de engineering om er een te onderhouden is engineering die niet naar uw eigen product gaat.

Wat een gateway werkelijk doet

Ze zit tussen uw applicaties en de modelleveranciers en toont één interface. Erachter routeert u op kost, latency, taaktype of gezondheid van de leverancier; valt u automatisch terug wanneer er één degradeert; en voegt u een leverancier toe of vervangt u er een via configuratie in plaats van code.

Vier klassen, elk met de prijs die eraan hangt:

• —Gehoste marktplaats. Eén API voor veel leveranciers, als dienst gedraaid door iemand anders. De snelste start en de dunste governance — uw verkeer verlaat uw grens, en er staat een percentage op de uitgave.
• —Open source, zelf gehost. De router als component die u zelf draait. Volledige controle over residentie en configuratie — en permanent engineeringeigenaarschap op iets dat uw product niet is.
• —Beheerd, governance-eerst. De router als product, met rollen, guardrails en audit ingebouwd. Voor teams die het auditspoor harder nodig hebben dan de flexibiliteit — tegen een abonnement en één leveranciersrelatie extra.
• —Hyperscaler-eigen. Modeltoegang en routering binnen een cloudomgeving die u al contracteerde. Voor omgevingen die al op één cloud staan — waarbij de diepte van de afhankelijkheid verschuift van de modelleverancier naar de cloudleverancier.

De keuze hangt aan één vraag, en die is niet technisch: waar moet het verkeer staan, en wie moet het kunnen auditeren? Beantwoord dat en de klasse kiest zichzelf. Beantwoord het na de pilot en u draait de pilot twee keer.

De goedkoopste eerste stap is niet de gateway

Vóór welke keuze ook is er een stap die dit kwartaal beschikbaar is, tegen bijna geen inspanning. De meeste frontier-modellen worden ook geleverd via de modeldienst van minstens één hyperscaler, op infrastructuur die losstaat van de eigen interface van de leverancier. Zelfde model, zelfde gewichten, ander faaldomein, ander contract — en meestal binnen een cloudovereenkomst die u al tekende, met de residentie- en auditvoorwaarden die u al onderhandelde.

Dat als tweede pad configureren is een configuratiewijziging en een credential. Het overleeft een storing aan leverancierszijde zonder iets te veranderen aan uw prompts, uw evaluaties of uw outputkwaliteit.

Een tweede pad naar hetzelfde model is geen architectuur. Het is een week verzekering, en ze is nu beschikbaar.

— Wat overblijft: geen kostenroutering, geen governance, en geen verlichting van de concentratie in het model zelf — alleen in de infrastructuur die het levert. Het koopt tijd. Besteed die tijd aan de gateway.

Het governance-antwoord kost een kolom

De tegenwerping komt meteen van iedereen die ooit een governanceprogramma een jaar heeft zien opeten: dit mag geen nieuw comité worden. Dat wordt het niet. Elk deel van het antwoord verlengt iets dat al bestaat in een bedrijf dat gecomponeerde applicaties behoorlijk beheert.

Twee velden in het register. Het draagt al een eigenaar, de data die geraakt wordt en een classificatie per gecomponeerde applicatie — en het is meteen de AI Act-inventaris. Voeg toe: welke modelleverancier(s), en of er een fallback geconfigureerd is en wanneer die laatst getest werd. Dat is een kolom, geen proces.

Eén poort. Verleng de graduatieregel: alles wat gecomponeerd is en bedrijfskritisch wordt, heeft vóór graduatie een geteste terugvalweg nodig, naast de bestaande security- en architectuurgoedkeuring. Geen gedocumenteerde. Een geteste — dat is precies het punt.

Eén cijfer. Geef de stuurgroep het aandeel bedrijfskritische gecomponeerde workflows met een geteste fallback, elk kwartaal gerapporteerd tegen een gedateerd doel.

Twee kolommen, één poort, één cijfer. Geen parallel programma, geen beleidsdocument dat niemand leest, en — commercieel het belangrijkste — een inventaris die een due-diligencevraag beantwoordt vóór ze gesteld wordt.

Waarom modelconcentratie op de resultatenrekening staat en niet op het IT-budget

Leveranciersconcentratie is een due-diligencevraag sinds er due diligence bestaat. Een koper vraagt wat er gebeurt als de grootste leverancier de prijs verhoogt, de voorwaarden wijzigt of een dag stilvalt. Aan die vraag is niets nieuw. Nieuw is dat de modellaag nu een leverancier is — van een input die ín het product zit in plaats van ernaast — en dat ze in de meeste bedrijven nog niet op die lijst staat.

Twee gevolgen. Het eerste is gewoon: een niet-beprijsde leveranciersafhankelijkheid wordt uiteindelijk door iemand beprijsd, en die iemand is meestal de koper, in de richting die u verwacht. Het tweede snijdt dieper. Wie een architectuurschema doorneemt, zoekt vooral één patroon — een product dat een dunne schil is over één publieke modeldienst, zonder fallback, zonder eigen workflow, zonder eigen data. Uw bedrijf is dat misschien helemaal niet. Het intellectuele eigendom kan volledig van u zijn en de data echt eigen. De compositielaag kán er alsnog zo uitzien, want ze is het nieuwste, minst gedocumenteerde en meest zichtbare deel van het geheel.

U beprijst deze afhankelijkheid, of uw koper doet het voor u.

Dat beeld omdraaien kost een gatewayabonnement en twee kolommen in een register. Het niet omdraaien kost wat een beoordelaar beslist dat het kost, op het ene moment in het leven van het bedrijf waarop u geen positie hebt om te discussiëren.

De eerlijke grenzen

• —Een gateway voegt latency toe en één component om te beheren. Een reële kost — en dezelfde die u al aanvaardde voor elke andere integratielaag.
• —Routeren over meerdere leveranciers maakt modellen niet even goed. Eén model is misschien gewoon beter voor uw taak. De gateway levert optionaliteit onder druk, geen spreiding om de spreiding.
• —Ze lost eigenaarschap niet op. Zit de capaciteit in één hoofd, of het intellectuele eigendom in de repository van een partner, dan sluit dat op een aanwervingsplan en een contract — niet op een softwareaankoop.
• —Ze maakt een zwakke applicatie niet het behouden waard. Een slecht gekozen workflow over drie leveranciers routeren levert een slecht gekozen workflow op met betere uptime.

En ja, dat geldt ook voor ons

Het argument geldt eerst voor deze praktijk. NUVAI blijft modelagnostisch om precies de reden hierboven: de duurzame activa zijn de klantrelatie en het domeinmodel, niet een badge van een platform. Een praktijk die zich rond één leverancier merkt, heeft dezelfde fout gemaakt als die ze betaald wordt om te vinden.

Als kenniswerk met een factuur eraan betwistbaar is, dan is het onze dat ook. Dat hoort zo. Het verschil is wat u overhoudt op het einde: geen retainer die op traagheid verlengt, maar een werkend systeem, zijn registervermelding — nu met twee kolommen erbij — en een team dat het zonder ons draait.

Wij zijn de laatste factuur van deze soort die u voor die workflow koopt.