Een modelbesluit vastleggen: registratie en herbeoordeling

Door Ivo Donker — samengesteld met AI-ondersteuning · Laatst bijgewerkt: 7 augustus 2026

Bij het ontwikkelen van softwaretoepassingen op basis van Large Language Models (LLM's) wordt de selectie van een specifiek model vaak beschouwd als een eenmalige ontwerpbeslissing. In een landschap waarin AI-providers gemiddeld om de enkele weken modelupdates uitrollen, API-endpoints uitfaseren of prijsstructuren aanpassen (stand: augustus 2026), blijkt deze aanname in de praktijk een risico voor de continuïteit. Een modelkeuze die niet formeel wordt geregistreerd, is binnen drie tot zes maanden niet meer te reconstrueren. Ontwikkelaars en systeemarchitecten vergeten de exacte beweegredenen, de geaccepteerde randvoorwaarden en de geteste alternatieven van het oorspronkelijke besluit. Wanneer er vervolgens vragen ontstaan over stijgende API-kosten, afnemende responskwaliteit of gewijzigde verwerkingsvoorwaarden, ontbreekt de basis voor een rationele analyse.

Het periodiek herbeoordelen van een modelkeuze heeft bovendien alleen zin wanneer de oorspronkelijke criteria kwantitatief en transparant zijn vastgelegd. Zonder vooraf gedefinieerde meetpunten vervalt een herbeoordeling in een subjectieve discussie over het 'gevoel' bij een nieuw uitgekomen model. Een gestructureerd modelbesluit voorkomt dit door keuzes te verankeren in meetbare prestaties, kosten en risico-analyses.

Waarom een modelbesluit vastleggen

Een modelbesluit vormt het administratieve en technische fundament onder een LLM-integratie. Het verankert niet alleen welk model op een specifiek moment is gekozen, maar legt expliciet vast waarom alternatieve modellen zijn afgewezen. In complexe productieomgevingen veranderen er continu variabelen: prompt-templates worden verfijnd, contextvensters groeien, en providers passen hun hardware-infrastructuur aan. Zonder registratie ontstaat er een historisch vacuüm waarin beslissingen opnieuw moeten worden geëvalueerd zodra het team van samenstelling verandert of wanneer een provider een update doorvoert.

Het vastleggen van een besluit dwingt een team om expliciet te worden over randvoorwaarden die tijdens de ontwikkelpijp anders onbelicht blijven. Denk hierbij aan de maximale acceptabele latentie voor de eindgebruiker, de bovengrens voor de kosten per duizend verwerkte transacties, en de juridische kaders rondom dataretentie door de modelaanbieder. Waar het initiële proces van een model kiezen zich voornamelijk richt op de vergelijkende analyse en eerste afweging bij de start van een toepassing, legt het modelbesluit deze uitkomsten duurzaam vast zodat ze als ijkpunt dienen voor de gehele levenscyclus van de software.

Een vastgelegd modelbesluit voorkomt ook het fenomeen van 'update-gebaseerde dwaalsporen'. Ontwikkelaars neigen er soms toe direct over te stappen naar een nieuw aangekondigd model zodra dit beschikbaar komt op de markt. Als in het besluitregister echter staat omschreven dat de huidige taak uitsluitend een eenvoudige entiteitsextractie betreft waarbij kosten en verwerkingssnelheid prioriteit hebben boven complexe redeneervermogens, kan een duurder of trager model direct worden uitgesloten zonder tijdrovende her-evaluaties.

Wat is een modelbesluit

Een modelbesluit is een onveranderlijk of versiebeheerd document – vergelijkbaar met een Architecture Decision Record (ADR) in traditionele softwarearchitectuur – waarin de keuze voor een specifiek LLM, een specifieke hostingservice en een specifieke configuratie voor een afgebakende taak wordt vastgelegd. Het modelbesluit vormt het scharnierpunt tussen de verkennende fase en de beheersfase van een LLM-applicatie.

Om verwarring in het beheerproces te voorkomen, moet een modelbesluit helder worden onderscheiden van drie andere documenten in de AI-levenscyclus:

• Modelkaart (Model Card): Dit is het document dat door de modelontwikkelaar of provider wordt geleverd (bijvoorbeeld door OpenAI, Anthropic, Meta of Hugging Face). Het beschrijft de architectuur, trainingsdata, algemene benchmarks en bekende beperkingen van het model. Dit artikel behandelt het lezen van modelkaarten en licenties niet; zie het artikel over modelkaarten en licenties lezen voor het analyseren van deze leveranciersdocumentatie. De modelkaart bevat externe feiten; het modelbesluit bevat uw interne afweging.
• Migratieplan: Dit is een operationeel draaiboek dat beschrijft welke stappen nodig zijn om model A in productie te vervangen door model B (inclusief prompt-transformaties, regressietesten en uitrolstrategieën). Voor de concrete planning en uitvoering van een dergelijke transitie raadpleegt u de handleiding voor modelversies en deprecatie; dit artikel beschrijft het inhoudelijke besluit dat aan een migratie voorafgaat.
• Monitoringslogbook: Dit is de continue stroom van runtime-telemetrie (latency p95, error-rates, tokenverbruik per dag, drift-metingen). Het logbook levert de feitelijke data op basis waarvan een modelbesluit later herbeoordeeld wordt, maar bevat zelf geen besluitvorming of criteria.

Een modelbesluit brengt deze elementen samen in een vast omlijnd kader. Het koppelt de externe claims uit de modelkaart aan de interne testdata uit het monitoringslogbook, en formuleert de randvoorwaarden die bepalen wanneer een migratieplan in werking moet treden.

Wat je vastlegt: het besluitregister

Een gestructureerd besluitregister bestaat uit een verzameling velden die zowel de context, de kwantitatieve onderbouwing als de randvoorwaarden van de keuze vastleggen. Het formatteren van het register als een vaste tabel of gestructureerd JSON/YAML-bestand borgt dat verschillende teams binnen een organisatie dezelfde standaarden hanteren.

Een volledig besluitregister bevat minimaal de volgende twaalf velden:

1. Datum: De datum waarop het besluit officieel is goedgekeurd.
2. Beslisser / Rol: De naam en functie van de eindverantwoordelijke (bijvoorbeeld Lead Architect of Product Owner).
3. Model + exacte versie: De unieke identifier van het model, inclusief de specifieke snapshot-versie of commit-hash (bijvoorbeeld gpt-4o-mini-2024-07-18 of meta-llama/Llama-3.1-70B-Instruct op een specifieke vLLM-instance). Vermijd het gebruik van zwevende aliassen zoals latest zonder versienummer.
4. Taak / Toepassing: De specifieke functionaliteit binnen de applicatie waarvoor dit model wordt ingezet (bijvoorbeeld "Samenvatten van klantenservicegesprekken voor CRM-invoer").
5. Motivatie: Korte kwalitatieve beschrijving van de doorslaggevende argumenten.
6. Meetbare criteria: Harde grenswaarden voor prestaties, kosten en snelheid.
7. Evaluatiebewijs: Een verwijzing naar de testset, benchmarkrun of evaluatierapportage waarop het besluit is gebaseerd.
8. Kostenraming: Verwachte operationele kosten op basis van het geschatte volume (bijvoorbeeld kosten per 1.000 transacties of TCO van eigen hardware).
9. Licentievoorwaarden: Toegestane gebruiksdoelen, verwerkersovereenkomsten (DPA) en garanties rondom dataretentie.
10. Risico's: Bekende zwakke punten van het model voor deze specifieke taak (bijvoorbeeld gevoeligheid voor hallucinaties bij lange contexten of strenge rate limits van de API-provider).
11. Herbeoordelingsdatum: Geplande datum voor de eerstvolgende periodieke controle.
12. Triggers: Gebeurtenissen die een tussentijdse herbeoordeling verplichten.

Onderstaande tabel geeft een concreet overzicht van hoe een besluitregister in de praktijk wordt ingevuld voor een specifieke verwerkingspijplijn (illustratief voorbeeld, stand: augustus 2026):

Criteria die herbeoordeling mogelijk maken

De kern van een bruikbaar modelbesluit ligt in de meetbaarheid van de geformuleerde criteria. Een criterium als "het model moet kwalitatief hoogwaardige teksten schrijven" is onbruikbaar voor herbeoordeling, omdat kwaliteitsbeleving subjectief is en verandert naarmate teams gewend raken aan LLM-outputs. Criteria moeten kwantitatief, reproduceerbaar en direct koppelbaar zijn aan de bedrijfsdoelstellingen.

Meetbare criteria worden opgedeeld in vier categorieën:

• Functionele prestaties: Nauwkeurigheid op een specifieke 'golden dataset', F1-score bij classificatietaken, of het percentage valide output-structuren (zoals JSON of SQL) bij 1.000 opeenvolgende verzoeken.
• Operationele eigenschappen: De Time-To-First-Token (TTFT), de verwerkingssnelheid in tokens per seconde, en de 95e percentiel (p95) van de totale responstijd onder normale productiebelasting.
• Financiële grenzen: De maximale kostprijs per duizend tokens (input en output gewogen) of de maximale totale kosten per succesvol afgehandelde gebruikerstransactie.
• Veiligheid en robuustheid: Het percentage geaccepteerde prompt-injections bij een standaard testsuite, of het foutpercentage bij randgevallen (edge cases) in de invoer.

Om deze criteria effectief te vertalen naar de praktijk, moeten ruwe metingen worden omgezet in een duidelijke beslisstructuur. Voor het gestructureerd uitvoeren en interpreteren van deze metingen verwijzen we naar het omzetten van evaluatieresultaten naar besliskaarten, waarin gedetailleerd wordt uitgelegd hoe u kwantitatieve testresultaten formuleert tot een helder besliskader.

Daarnaast vereist een betrouwbare herbeoordeling dat de bewijslast continu en geautomatiseerd kan worden verzameld. In dit proces vormt de methodiek voor het testen van LLM-integraties een onmisbare pijler. Geautomatiseerde integratietests leveren namelijk het harde bewijs dat aantoont of een bestaand model nog aan de gestelde criteria voldoet, of dat een nieuw modelkandidaat daadwerkelijk beter presteert op uw specifieke workload.

Herbeoordelingsmomenten

Een modelbesluit is geen statisch document dat na ondertekening in een archief verdwijnt. Het is een dynamische afspraak met een expliciete vervaldatum en een verzameling actievoorwaarden. Herbeoordelingen vinden plaats op twee manieren: via een vast kalenderritme of op basis van specifieke gebeurtenissen (triggers).

Kalendergebonden herbeoordeling

Voor standaard productietoepassingen is een vaste cyclus van drie tot zes maanden aan te bevelen. Tijdens deze periodieke review controleert het team of de aannames uit het besluitregister nog overeenkomen met de realiteit. Zijn de API-kosten nog conform de kostenraming? Is het volume veranderd? Zijn er in de tussentijd nieuwe modellen op de markt gekomen die dezelfde prestaties leveren tegen een fractie van de prijs? Een vaste cyclus borgt dat de applicatie niet ongemerkt op verouderde of onnodig dwaze infrastructuur blijft draaien.

Event-driven triggers

Naast de kalenderherbeoordeling moet het besluitregister specifieke situaties definiëren die direct een tussentijdse evaluatie afdwingen. Deze triggers voorkomen dat een organisatie pas reageert wanneer een dienst uitvalt of een factuur onverwacht hoog uitvalt. De belangrijkste triggers zijn:

• Aankondiging van een model-deprecatie: De provider geeft aan dat een API-endpoint binnen een bepaalde termijn wordt stopgezet.
• Release van een nieuwe modelversie: De provider brengt een update uit van het gekozen model of een direct concurrerend model in dezelfde prestatieklasse.
• Prijswijzigingen: Een aanpassing van de token tarieven door de huidige provider of een drastische prijsverlaging bij een directe concurrent.
• Kwaliteitsregressie in productie: Uit de continue evaluatie of gebruikers-feedback blijkt dat het aantal foutieve antwoorden, hallucinaties of format-fouten de afgesproken grenswaarde overschrijdt.
• Juridische of beleidsmatige wijzigingen: De provider past de algemene voorwaarden, het privacybeleid of de data-retentieovereenkomst aan, waardoor de licentievoorwaarden uit het besluitregister worden geschonden.

Om deze triggers tijdig te onderkennen zonder dat het team dagelijks handmatig nieuwsbronnen moet scannen, is een gestructureerd proces vereist. Voor het inrichten van een dergelijk signaleringsproces raadpleegt u het structureel bijhouden van modelupdates. Daarin staat beschreven hoe u wijzigingen bij providers geautomatiseerd opvangt en filtert op relevantie voor uw Besluitregister.

Beslisproces en eigenaarschap

Een veelvoorkomende valkuil bij het beheer van LLM-applicaties is het ontbreken van een duidelijke eigenaar van het modelbesluit. Wanneer niemand expliciet verantwoordelijk is voor de gemaakte keuze, voelt niemand zich geroepen om bij een trigger in actie te komen. Het eigenaarschap van een modelbesluit moet belegd worden bij een specifieke rol binnen het team – meestal de Lead AI Architect, de Senior Backend Developer of de Product Owner, afhankelijk van de organisatiegrootte.

Het beslisproces volgt idealiter een vaste escalatieladder:

1. Signalering: De monitoring-tooling of de periodieke kalender-check signaleert dat een criterium is geschonden of een trigger is afgegaan.
2. Analyse: De ontwikkelaar voert de standaard evaluatietestsuite (zoals vastgelegd in het evaluatiebewijs) uit op het huidige model en eventuele alternatieve modellen.
3. Voorstel: De ontwikkelaar stelt een herziening van het besluit voor (behouden, migreren naar nieuwe versie, of overstappen naar een andere provider).
4. Goedkeuring (Human-in-the-loop): De toegewezen beslisser beoordeelt de testresultaten en de financiële impact, en keurt het nieuwe besluit goed.

Hierbij geldt een strikte regel voor de administratieve verwerking: een gewijzigd besluit is altijd een nieuw besluit, nooit een correctie achteraf van het oude document. Het besluitregister werkt als een 'append-only' logboek. Als een model ingesteld op gpt-4o-mini-2024-07-18 wordt vervangen door gpt-4o-mini-2024-08-07, wordt Besluit #001 niet overschreven. Er wordt een nieuw Besluit #002 aangemaakt dat expliciet verwijst naar Besluit #001 en de reden van de vervanging documenteert. Dit behoudt de volledige audit-trail en maakt het mogelijk om bij problemen in productie direct terug te grijpen naar de historische aannames.

Voor een gedetailleerde uitwerking van de rollen en verantwoordelijkheden in de operationele fase verwijzen we naar het artikel over eigenaarschap van AI-toepassingen na go-live. Hierin wordt toegelicht hoe de overdracht tussen ontwikkeling en beheer formeel wordt geregeld.

Praktische uitvoering

Het vastleggen van modelbesluiten moet geen bureaucratische belasting worden die de ontwikkelingssnelheid afremt. Voor kleine teams, indie developers of homelab-beheerders is zware enterprise-software overbodig. Een sober en lichtgewicht proces werkt in de praktijk het beste.

Een eenvoudige en doeltreffende manier om modelbesluiten vast te leggen is het opnemen van een DECISIONS.md bestand direct in de Git-repository van de betreffende applicatie. Hierin wordt voor elke beslissing een vast Markdown-sjabloon gebruikt. Doordat het besluitregister samen met de broncode wordt versiebeheerd, is in één oogopslag te zien welk modelbesluit hoorde bij een specifieke release van de software.

Een geanonimiseerd en sober voorbeeld van één enkele besluitregel in een platte tekst- of Markdown-structuur ziet er als volgt uit:

Besluit-ID: DEC-20260807-01 | Datum: 07-08-2026 | Status: ACTIEF
Taak: Samenvatten van interne incidentreports (Module: services/reporter)
Gekozen model: mistral-large-2407 (gehost via interne vLLM-cluster op 2x RTX 6090)
Motivatie: Volledige datalokaliteit vereist (geen externe API toegestaan ivm vertrouwelijke incidentdata); presteert op interne testset gelijkwaardig aan commerciële gesloten modellen op de taak 'samenvatten'.
Hard criterium: Hallucinatie-rate op entiteiten < 0,5% op benchmarkset incidents-v1; verwerkingssnelheid > 40 tokens/sec.
Eigenaar: DevSecOps-team (contact: T. Jansen)
Herbeoordeling: 07-11-2026 of zodra nieuw lokaal open-weights model met >70B parameters verschijnt.

Door het sjabloon zo compact te houden, kost het aanmaken van een besluitregel minder dan vijftien minuten, terwijl het alle noodzakelijke informatie bevat voor toekomstige audit- en migratiemomenten.

Valkuilen

Bij het opzetten en onderhouden van een besluitregister komen in de praktijk een aantal hardnekkige valkuilen voor. Het onderstaande overzicht geeft de meest kritische aandachtspunten weer:

• Vastleggen maar nooit herbeoordelen: Het besluitregister wordt eenmalig ingevuld tijdens de uitrol van het project, maar er wordt nooit meer naar omgekeken. Hierdoor draait de applicatie na een jaar nog steeds op een verouderde, duurdere of tragere modelversie. Een besluit zonder geplande herbeoordelingsdatum is administratieve ballast.
• Criteria formuleren die niet meetbaar zijn: Het hanteren van vage doelen zoals "de antwoorden moeten natuurlijk klinken" of "het model moet slim genoeg zijn". Als criteria niet kwantitatief te toetsen zijn via een testscript of benchmark, kan bij een herbeoordeling niet objectief worden vastgesteld of een model nog voldoet.
• Geen expliciete eigenaar aanwijzen: Het besluit wordt opgeslagen in een gezamenlijke wiki zonder dat een specifiek individu of specifieke rol als eigenaar is aangewezen. Bij het afgaan van een trigger reageert niemand, omdat de verantwoordelijkheid tussen de afdelingen 'Development' en 'Operations' invalt.
• Verwarring tussen modelbesluit en modelkaart: Vertrouwen op de documentatie van de leverancier (modelkaart) in plaats van het vastleggen van de eigen specifieke toepassingscontext. Een modelkaart vermeldt dat een model "goed presteert op Python-code", maar borgt niet of het model voldoet aan uw interne latentie-eisen voor een specifieke API-endpoint.
• Het besluit niet koppelen aan de applicatieversie: Het besluit opslaan op een externe locatie zonder te registreren welke versie van de broncode (git commit hash) en welke prompt-templates bij het besluit hoorden. Hierdoor is bij regressietesten niet te achterhalen welke prompt-wijzigingen zijn doorgevoerd toen het model werd gekozen.
• Vergeten van specifieke event-driven triggers: Alleen vertrouwen op een kalenderreview (bijvoorbeeld eens per halfjaar) en vergeten om een stijging van de API-foutmarges of een deprecatie-aankondiging op te nemen als trigger. Dit leidt tot acute noodmigraties op het moment dat een provider een endpoint definitief uitschakelt.

Het vermijden van deze valkuilen vereist geen ingewikkelde processen, maar discipline in de toepassing van de gemaakte afspraken. Een gestructureerde checklist bij elke release voorkomt dat besluiten ongemerkt vervallen.

Het registreren en herbeoordelen van een modelbesluit vormt de ontbrekende schakel in een professionele LLM-levenscyclus. Waar de initiële modelselectie bepaalt waarmee een project start, zorgt het besluitregister ervoor dat keuzes gedurende de gehele levensduur transparant, meetbaar en beheersbaar blijven. Het verbindt het eerste keuzeproces direct met continue monitoring en een gecontroleerde migratieplanning. Door keuzes expliciet vast te leggen in een sober register met harde criteria en duidelijke eigenaars, transformeren ontwikkelaars hun AI-integraties van ad-hoc experimenten naar robuuste, herleidbare softwarecomponenten.