Waarom een modelnaam geen versie is: wijzigingsbeheer voor AI-agents

U moet elke wijziging aan model, prompt, tool of policy als een versieerbare release van een complete behavior bundle behandelen, vastleggen en kunnen terugdraaien. Zonder die registratie kunt u niet aantonen welke agent-versie op welk moment op welke data actief was.

An analysis of 17 August 2026 of wijzigingsbeheer bij AI-agents en de behavior bundle argues that a model name alone does not constitute a version, and that providers routinely change agent behavior under the same model alias without formal incident reporting. De praktijkreferenties uit juli 2026 tonen aan dat grote providers aanpassingen doorvoeren aan contextlimieten, redeneerbudget, routering en prompts, soms zonder transparantie naar afnemers. In our assessment, dit betekent dat organisaties die alleen op een modelnaam vertrouwen, geen zicht hebben op welke gedragsversie in productie staat, en dus niet kunnen bewijzen welke agent-configuratie een bepaalde beslissing heeft genomen.

Waarom een modelnaam geen versie is

De aanname dat gedrag stabiel blijft zolang het model niet wordt vervangen, is niet houdbaar. Onder één modelnaam bestaan in de praktijk meerdere gedragsversies. Een organisatie die noteert "we gebruiken model X" weet feitelijk niet welke agent-versie actief is. Zonder eigen versie-registratie en trace-logging kunt u niet reconstrueren of een verandering in gedrag voortkwam uit een eigen aanpassing of uit een stille wijziging bij de provider.

Dit is meer dan een technisch detail voor wie met vertrouwelijke of hoog-trust informatie werkt. Het bepaalt of u na een beslissing nog kunt aantonen welke versie op welk moment op welke data actief was.

Wat vormt samen het werkelijke gedrag?

Model, prompt, toolschema's, retrieval, policies en runtime vormen samen één behavior bundle. Elke verandering aan een van die lagen wijzigt het gedrag van het systeem. Rollback is alleen veilig naar de laatst bekende stabiele bundel — niet naar één losse component zoals het model alleen.

De agent-harness — code, prompts, tools en geheugen — bepaalt het gedrag van een AI-systeem net zo sterk als het onderliggende model. Wijzigingsbeheer dat alleen naar modelgewichten kijkt, mist daarmee het grootste deel van het beeld.

Welke risico's ontstaan zonder versieering?

• Onzichtbare wijzigingen — providers voeren aanpassingen door onder dezelfde modelnaam zonder formeel incidentrapport.
• Verlies van reconstructie — u kunt niet aantonen welke agent-versie een bepaalde output heeft gegenereerd.
• Ongecontroleerde drift — gedragsveranderingen gebeuren zonder dat u ze kunt detecteren of terugdraaien.
• Compliance-risico — u kunt niet bewijzen welke versie toegang had tot welke data op welk moment.
• Falende rollback — terugdraaien naar een oud model helpt niet als prompts, tools of policies inmiddels zijn gewijzigd.

Welke controles moet u kunnen aantonen?

1. Registreer de complete behavior bundle — documenteer model, prompt, toolschema's, retrieval-instellingen en policies als één versieerbare eenheid.
2. Voer trace-logging in — leg vast welke bundel-versie op welk moment op welke data actief was.
3. Implementeer canary-routes — test wijzigingen op een klein deel van het verkeer voordat u ze volledig uitrolt.
4. Definieer rollback-paden — zorg dat u naar de laatst bekende stabiele bundel kunt terugkeren.
5. Meet gedragsafwijkingen — detecteer drift en onverwachte veranderingen post-deployment.
6. Documenteer wijzigingsbeslissingen — leg vast waarom, wanneer en hoe u wijzigingen hebt doorgevoerd.

Hoe past dit in bestaande kaders?

Dit staat niet los van NIST AI Risk Management Framework (AI RMF 1.0). Wijzigingsbeheer is expliciet onderdeel van de GOVERN- en MANAGE-functies: organisaties moeten AI-systemen over de hele levenscyclus monitoren, grenzen en use-cases documenteren, post-deployment-risico's meten en systemen kunnen deactiveren of terugdraaien bij misgedrag.

Het MEASURE-playbook van NIST werkt dat verder uit richting continue meting, post-deployment-monitoring en drift-detectie. Change management en rollback worden daarin gekoppeld aan meetbare afwijkingen. Organisaties moeten bewijs vastleggen over gedrag vóór en na wijzigingen. Rollback is dan geen ad-hoc reflex, maar een gedocumenteerde beslissing op basis van metingen.

Wat kunnen tools bijdragen en wat niet?

Wijzigingsbeheer verschuift van een losse MLOps-stap naar een verifieerbaar release- en bewijsproces rond complete behavior bundles. Een verificatieconsole kan dat wijzigingsbeheer zichtbaarder en beter controleerbaar maken door zicht te geven op welke modellen en configuraties bij een taak zijn gebruikt en welke uitkomsten van elkaar afweken. Dit ondersteunt de reconstructie die NIST vraagt en maakt controle mogelijk. Maar de inrichting van canary-routes, rollbackpaden en meetprocessen blijft werk voor uw organisatie zelf. Geen tool garandeert correctheid of waarheid en geen tool elimineert hallucinaties. Het professionele eindoordeel over wat acceptabel is, blijft altijd bij u.