Modelregister versus leverancierslijst: weet welke modellen er draaien

Een leverancierslijst vertelt je bij wie je inkoopt; een modelregister vertelt je welke modellen je systemen aanroepen en onder welke voorwaarden elk model mag draaien. De eerste kijkt vanuit inkoop, de tweede vanuit de dagelijkse operatie.

Een goedgekeurde leverancier kan een endpoint aanbieden dat niemand heeft vrijgegeven voor een bepaald taaktype of een bepaalde dataklasse. Een lokaal gehost model kan productieverzoeken afhandelen zonder ooit op een leverancierslijst te staan. In beide gevallen gaat het om een modelbesluit, en met de naam van de leverancier is geen van beide geregeld.

In Het model-portfolio is het register de canonieke catalogus van elk model in het portfolio. Het is de R van ROUTE: Register, Doel-typering, Uitvoeringsbeleid, Tracken en Evolueren. Bij laag volume, één taaktype en geen gereguleerde data kan één model genoeg zijn. Ook dat ene model heeft een taakopdracht, een eigenaar en een datagrens nodig.

Welke vraag beantwoordt elke lijst?

Vraag	Leverancierslijst	Modelregister
Wie is de contractpartij?	Aanbieder, contract en verlengingsdatum	Niet de vraag van het register; het legt de host en de eigenaar van de rij vast
Wat draait er?	Een ingekochte dienst of een product	Model-ID en, waar dat ertoe doet, host en uitvoeringsconfiguratie
Welk werk mag het doen?	Een ingekochte functie	Taakopdracht met de toegestane taaktypen
Welke data mag erheen?	De voorwaarden van de aanbieder voor datagebruik	Privacyklasse voor dit model op deze host
Wat gebeurt er bij een wijziging?	Beoordeling van leverancier of contract	Routecontrole, statuswijziging en uiteindelijk uitfasering

De leverancierslijst heeft een echte taak. Hoofdstuk 11 van het boek houdt er een apart provider-risicoregister voor bij, met één rij per tegenpartij: welk deel van je routes van die aanbieder afhangt, welke minimale aankondigingstermijn de aanbieder bij uitfasering belooft en hoe die zich daar in de praktijk aan houdt, prijsstabiliteit, voorwaarden voor datagebruik, gevalideerde alternatieven en de verlengingsdatum. Meerdere modellen van één aanbieder delen hetzelfde tegenpartijrisico, en het contract met die aanbieder zegt nog steeds niet welk van die modellen een route aanriep.

De twee lijsten groeien uit elkaar omdat toegang goedkoop is en validatie niet. Een prototype dat in één middag op een bestaand account is gebouwd, kan live verkeer gaan verwerken zonder formeel besluit, en er volgt geen leveranciersbeoordeling omdat er geen nieuwe leverancier bij komt. Teams voegen ook parallel modellen toe: data science draait een embeddings-model, het productteam hangt een vision-model aan een prototype, devops zet lokaal een model op voor loganalyse. Elk daarvan voegt een operationele positie toe, zonder nieuw contract.

De rij-eenheid van het register is een model met zijn wezenlijke uitvoeringsconfiguratie. Registreer verschillende hosts als aparte rijen, ook bij dezelfde gewichten: een andere host verandert kosten, latentie en privacyvoorwaarden. Het boek waarschuwt: zet je achter een gateway voor meerdere aanbieders een model vast, dan ligt de host daarmee standaard nog niet vast. De gateway kan zelf de aanbieder kiezen en naar een andere uitwijken. Vereist de privacy-tier of het contract één host, dan geeft hoofdstuk 5 de oplossing: zet de volgorde van aanbieders vast, schakel het automatisch uitwijken naar andere aanbieders uit en schrijf de toegestane hosts in de rij. De gateway zelf krijgt een rij in het provider-risicoregister.

Wat hoort er in het kleinste bruikbare register?

Hoofdstuk 3 van Het model-portfolio geeft een minimum van negen velden, die elk een operationele vraag beantwoorden.

Veld	Wat je vastlegt
Model-ID	Een stabiele identificatie die je terugvindt in configuratie en aanroeplogs.
Weergavenaam	Een naam die mensen herkennen in een dashboard of beleidstabel.
Model-tier	De rol in je portfolio: frontier, workhorse, lokaal of specialist.
Taakopdracht	De taaktypen die dit model hier mag afhandelen.
Kostenklasse	Laag, midden of hoog ten opzichte van je eigen portfolio, geen overgenomen prijs.
Privacyklasse	Welke data dit model op de geregistreerde host mag ontvangen.
Deployment-host	De API, het private endpoint, de server of het apparaat waarop het draait.
Uitfaseringsstatus	Active, deprecated of sunset.
Registereigenaar	De persoon die verantwoordelijk is voor het actueel houden van de rij.

Een taakopdracht is een toestemming, geen eigenschap van het model. Een model kan in een test prima code schrijven en toch alleen zijn vrijgegeven voor interne samenvattingen in batch. Codegeneratie vraagt dan om een apart besluit. Ook de model-tier is een rol in jouw portfolio, geen keurmerk van de aanbieder. Frontier, workhorse en lokaal zijn drie klassen uit het boek; de vierde, de specialist, is bedoeld voor een vaak terugkerende, goed afgebakende taak waarop algemene modellen de kwaliteitsdrempel niet halen.

De kostenklasse is een signaal voor je routebeleid, geen factuur. Laag, midden en hoog zijn relatief binnen je portfolio. Bewaar prijzen en de koppeling van klasse naar prijs apart. Herijk de klasse als een asymmetrische prijswijziging een model over een grens duwt of als je modelmix verandert. Een lage kostenklasse zegt niets over kwaliteit; het model moet nog steeds slagen voor je eigen taakevaluatie.

De privacyklasse gaat vóór kosten en capaciteit. Waar het model draait, de verwerkersvoorwaarden van de aanbieder en je eigen databeleid bepalen wat een route mag ontvangen. Is de klasse onbekend, schrijf dan under-review op, met een eigenaar en een oplossingsdatum. Volgens het boek mag zo’n rij in het register staan, maar geen productieverzoeken bedienen. De enige uitzondering staat op schrift: de registereigenaar mag een al draaiende route zonder persoonsgegevens of gereguleerde data tijdelijk laten doorlopen, begrensd tot de oplossingsdatum en op naam vastgelegd. Een oplossingsdatum is een uiterste termijn voor een besluit, geen toestemming om te routeren.

Daarna voegt hoofdstuk 3 vijf velden toe naarmate het portfolio groeit:

• Ability-tags en gedateerde prestatienotities, zodra je modellen binnen dezelfde model-tier moet kunnen onderscheiden. Gebruik één vaste woordenlijst, met tags als gestructureerde-extractie en code-generatie, en houd gedateerde notities bij uit je eigen evaluaties, inclusief wat misging.
• Licentie en uitvoeringsconfiguratie, zodra er open-weight- of redeneermodellen bijkomen. Een permissieve MIT-licentie en een community-licentie met commerciële beperkingen zijn verschillende juridische posities, en een 4-bit-kwantisatie of een hogere redeneer-effort kan kwaliteit, latentie en kosten veranderen bij hetzelfde model-ID.
• Stack-afhankelijkheid, op elke rij: de SDK, API-versie, het serving-framework en de runtime waartegen de route is geëvalueerd. Volgens het boek bepaalt juist die laag meestal of een migratie een kwestie van omwisselen is of van wachten.

Een rij in het register maakt een model kandidaat, maar bewijst niet dat het model op een nieuwe route je kwaliteitsdrempel haalt.

Hoe kan een goedgekeurde leverancier toch een schaduwmodel verbergen?

Hypothetisch voorbeeld. Een softwareteam heeft twee goedgekeurde leveranciers. Noord levert een model-API. Zuid levert een integratie die documenten verrijkt. Op de leverancierslijst staan beide contracten, de voorwaarden voor datagebruik en de verlengingsdata. Inkoop heeft zijn werk gedaan.

Het platformteam legt dertig dagen API-logs naast het gebruiksoverzicht van de integratie van Zuid. Daarin duiken twee verschillende modelaanroepen op:

Waargenomen gebruik	Vanuit de leverancierslijst	Controle in het register
batch-summary-v2 op de API van Noord vat interne tickets samen	Noord is een goedgekeurde contractpartij	Rij gevonden: ID, host, taakopdracht voor interne samenvattingen, kosten- en privacyklasse, status active, eigenaar
extract-a in de integratie van Zuid verwerkt documenten van nieuwe klantaccounts	Zuid is een goedgekeurde contractpartij	Geen rij: model, host, taakopdracht, privacyklasse en eigenaar ontbreken

De goedkeuring van een leverancier legt geen taakopdracht of privacyklasse per model vast. Daarmee is extract-a in de zin van het boek een schaduwmodel: in gebruik zonder rij in het register. Uit de leveranciersrelatie noch uit de factuur voor de integratie valt op te maken welke data dit model mocht ontvangen.

Stel dat een steekproef van de invoer contactgegevens van klanten bevat. Dan wordt de classificatie urgent, maar daarmee staat nog niet vast wat de voorwaarden van Zuid toestaan of dat er een wettelijke regel is geschonden. Het team legt het waargenomen model-ID vast, markeert de host als onbevestigd tot Zuid uitsluitsel geeft, wijst een eigenaar en een oplossingsdatum toe en zet de privacyklasse op under-review. Omdat de route persoonsgegevens draagt, geldt de uitzondering niet: het team zet de route stil terwijl het de data, de host en de voorwaarden controleert.

Komt de route door de controle, dan vult de eigenaar de negen velden en het Model-allocatiemandaat in, en wordt het routebeleid bijgewerkt voordat het verkeer weer start. Komt de route er niet door, dan vervangt of sluit het team haar en legt het de bevinding vast. Het voorbeeld laat een werkwijze zien en meldt geen echt auditresultaat of echte besparing.

Hoe bouw je het register op uit logs in plaats van uit je geheugen?

Begin bij het verkeer, niet bij wat mensen zich herinneren: het geheugen mist vergeten routes, geërfde diensten en aanroepen die in integraties verstopt zitten. Het volledige werkblad in hoofdstuk 3 kijkt negentig dagen terug; hoofdstuk 2 geeft een eerste ronde van dertig dagen. Die zet het werk in gang, maar bewijst niet dat oudere of zeldzamere aanroepen ontbreken.

1. Exporteer de waargenomen aanroepen. Haal dertig dagen API-logs en gebruiks- of factuuroverzichten op. Zet alle unieke model-ID’s en endpoints op een rij, ook die met weinig aanroepen, met route en serviceaccount waar die gelogd zijn. Verbergt de factuur het model-ID, markeer het dan als onopgelost in plaats van te gokken.
2. Vul aan wat facturen missen. Controleer de logs van je eigen modelservers, uitgerolde modellen, gateways en integraties van derden. Een model op je eigen hardware levert misschien geen factuur van een aanbieder op. Een integratie toont soms alleen een productnaam; vraag naar het onderliggende model en de host.
3. Koppel aanroepen aan rijen. Vergelijk voor elk waargenomen model en elke wezenlijke configuratie de host, de taakopdracht en de status met de route die het aanriep. Noteer aanroepen zonder rij en dubbele aliassen. Een active-rij zonder aanroepen in dit venster verdient een controle; stilte bewijst niet dat het model is uitgefaseerd.
4. Vul voor elke gevonden rij de negen velden in, en houd onopgeloste velden zichtbaar.

Je eigen logs zien niet wat een collega via een persoonlijk browseraccount doet, en missen soms aanroepen binnen de dienst van een leverancier. De bredere Schaduwmodel-audit uit het boek zet vier stappen in vaste volgorde: Detect (API-logs en facturen, declaraties en inkoopgegevens, geaggregeerd netwerkverkeer naar bekende model-endpoints, een anonieme, oordeelvrije enquête), Measure (wie wat gebruikt, voor welke taken, en welke dataklassen de organisatie verlaten), Govern (goedgekeurde routes voor de meest voorkomende schaduwtoepassingen, elk met een rij en een mandaat, en daarna een gepubliceerde lijst met goedgekeurde modellen) en Policy (een regel voor acceptabel gebruik, gekoppeld aan privacy-tiers). Kondig de audit vooraf aan, kijk naar tools en dataklassen in plaats van naar personen, en betrek wie over het beleid voor medewerkersmonitoring gaat.

Hoe ondersteunt een register je routebeleid en een audit?

Een routebeleid heeft geregistreerde modellen nodig om uit te kiezen. Bij elk verzoek toetst het eerst of de dataklasse de geregistreerde host toestaat, en pas daarna kosten of capaciteit. Vervolgens legt het status, taakopdracht, model-tier en geteste vaardigheden naast de taak, en benoemt het de toewijzing en de fallback. Een leveranciersnaam beslist geen van die zaken per model.

Het boek bouwt elke rij uit tot een Model-allocatiemandaat (MAM): een autorisatie van één pagina die de geëvalueerde identiteit en configuratie vastlegt, plus de capaciteitstier, de toegewezen doeltypen, de kostenenvelop, de latentie-SLO, de privacy-tier, het escalatiepad, de reviewcadans en de uitfaseringsdatum of -trigger. De rij maakt een model zichtbaar. Het mandaat legt vast onder welke voorwaarden het mag draaien. Een route buiten die voorwaarden is een zichtbare beleidsschending, geen onzichtbare drift.

De uitfaseringsstatus bepaalt wat het beleid mag toewijzen en wat iemand later kan reconstrueren. Active betekent in gebruik onder een geldig mandaat. Deprecated betekent dat het model wordt uitgefaseerd: geen nieuwe routes, en volgens hoofdstuk 11 bepaalt de reden van de degradatie welk verkeer nog mag. Sunset betekent geen verkeer meer, terwijl de rij als auditgeschiedenis bewaard blijft. Bewaar gedateerde statuswijzigingen en noteer welk model het werk overnam. Wie een eerdere aanroep onderzoekt, heeft de status van toen nodig, niet de waarde die vandaag in de tabel staat.

Een register kan ook ongemerkt verouderen door levenscyclusdrift: rijen die ooit zijn geregistreerd en een taakopdracht kregen, blijven op active staan lang nadat hun routes zijn overgenomen, en bij een audit ziet niemand meer welke rijen bewust worden onderhouden en welke zijn vergeten. Het boek zet daar een kwartaalreview door elke eigenaar tegenover: taakopdracht, prestatienotitie, uitfaseringsstatus en kostenklasse. Blijft die review uit, dan krijgt de rij de markering review-overdue en geen nieuwe routetoewijzingen meer.

Zelfs een goed bijgehouden register bewijst op zichzelf niet dat eerdere aanroepen het beleid volgden. Leg de routelogs naast het model-ID, de host, de status en het mandaat die op dat moment golden, en bekijk de voorwaarden van de aanbieder als de vraag over datagebruik gaat. Ontbreken die gegevens, benoem dan wat niet meer te reconstrueren valt. Het eigen bewijsregister van het boek noemt het registerschema een ontwerp van de auteur, zonder vrijgegeven claim dat het iets meetbaar vermindert.

Probeer dit vandaag

Exporteer de modelaanroepen en facturen van de afgelopen dertig dagen waar je team bij kan, plus de logs van je eigen modelservers en de gebruiksexports van integraties. Zet elk uniek model-ID en elke host die er echt in voorkomt op een rij. Toont een integratie geen model-ID, schrijf dan “onbekend” op en noteer wie het opvraagt; leid een endpoint niet af uit een factuur van de leverancier.

Koppel elk waargenomen model en elke wezenlijke configuratie aan een rij in het register en vul de negen velden uit de tabel hierboven in. Omcirkel elke rij zonder eigenaar of zonder taakopdracht: dat is je eerste autorisatiegat. Wijs het toe en geef het een datum. Zet een onbekende privacyklasse op under-review en houd productieverkeer weg van die route tot de klasse vaststaat, tenzij de smalle uitzondering hierboven geldt. Vergroot het venster tot negentig dagen als je de volledige inventarisatie uit het boek doet.

Bewaar het venster, de bronexports, de aanroepen zonder rij en wie waarover beslist. Vraag dan een collega om één aanroep te kiezen en daarbij de rij, de taakopdracht, de privacyklasse en de status op de aanroepdatum te vinden. De test is geslaagd als alle vier uit de vastgelegde gegevens komen. Wat ontbreekt, schrijf je op als gat; je vult het niet in met een gok.

Citeer deze pagina:Modelregister versus leverancierslijst: weet welke modellen er draaien.Len P. van der Hof. https://lenvanderhof.com/nl/blog/modelregister-versus-leverancierslijst/ · Gepubliceerd 1 november 2026.