Wie in productie met AI-agents of copilots werkt, gaat er vaak van uit dat het gedrag stabiel blijft zolang het model niet wordt vervangen. Recente publicaties uit juli 2026 laten zien dat die aanname niet houdbaar is. Een praktijkrunbook van Digitalthoughtdisruption.com en een analyse op de Substack High Learning Rate wijzen beide op hetzelfde punt: een modelnaam is geen versie, en elke wijziging aan het geheel rond een model verandert het feitelijke gedrag van een systeem in productie.
Voor professionals die met vertrouwelijke of hoog-trust informatie werken is dat meer dan een technisch detail. Het bepaalt of je na een beslissing nog kunt aantonen welke versie op welk moment op welke data actief was.
Een modelnaam is geen stabiele versie
De Substack-analyse "Your Agent Changed Under the Model Name" (13 juli 2026) beschrijft hoe grote providers wijzigingen doorvoeren onder dezelfde modelnaam: aanpassingen aan contextlimieten, redeneerbudget, routering en review-prompts, soms weer deels teruggedraaid, zonder formeel incidentrapport. Het gevolg is dat er onder één alias in de praktijk meerdere gedragsversies bestaan.
Dat betekent dat een afnemer die noteert "we gebruiken model X" feitelijk niet weet welke agent-versie in productie staat. Zonder eigen versie-registratie en trace-logging kan een organisatie niet reconstrueren of een verandering in gedrag kwam door een eigen aanpassing of door een stille wijziging bij de provider.
Gedrag zit in de hele bundel, niet alleen in het model
Het runbook "How to Canary and Roll Back Model, Prompt, or Tool Changes" (23 juli 2026) formuleert het kernidee: model, prompt, toolschema's, retrieval, policies en runtime vormen samen één behavior bundle. Elke verandering aan een van die lagen wijzigt het gedrag, en rollback is alleen veilig naar de laatst bekende stabiele bundel — niet naar één losse component zoals het model.
Deze redenering wordt academisch onderbouwd. De arXiv-studie "Code as Agent Harness" laat zien dat de agent-harness — code, prompts, tools en geheugen — het gedrag van een AI-systeem net zo sterk bepaalt als het onderliggende model. Wijzigingsbeheer dat alleen naar modelgewichten kijkt, mist daarmee het grootste deel van het beeld.
Het runbook vertaalt dit naar concrete ontwerpprincipes:
- Immutabele release-ID's per behavior bundle, zodat elke versie herleidbaar is.
- Shadow-traffic zonder side-effects om nieuw gedrag eerst te observeren.
- Sticky canaries per workflow of tenant, zodat een subset gecontroleerd de nieuwe bundel krijgt.
- Harde rollback-triggers bij bijvoorbeeld datalekken of ongewenste toolcalls.
- Release-evidence: manifest, metrics en traces die het gedrag vóór en na een wijziging vastleggen.
Wijzigingsbeheer als onderdeel van risicomanagement
Deze praktijk staat niet los van bestaande kaders. Het NIST AI Risk Management Framework (AI RMF 1.0) positioneert wijzigingsbeheer expliciet binnen 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, en 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.
Samengevat: wijzigingsbeheer bij modelupdates verschuift van een losse MLOps-stap naar een verifieerbaar release- en bewijsproces rond complete behavior bundles. Wie dat niet inricht, verliest feitelijk zicht op wat agents en copilots in productie doen — juist op het moment dat het gedrag stilletjes verandert.
Waar een verificatielaag kan helpen
Voor organisaties die met gevoelige of hoog-trust informatie werken, komt daar een extra eis bij: kunnen aantonen welke versie wanneer toegang had tot welke data. Hier past een verificatielaag als IamVera.ai. Vera is geen chatbot en geen eigen taalmodel, maar een privacygerichte verificatielaag die een taak door geselecteerde onafhankelijke AI-modellen kan routeren en verificatiestappen, correcties, onderlinge verschillen en bronnen zichtbaar maakt voor inspectie.
In de context van wijzigingsbeheer betekent dat: meer zicht op welke modellen en configuraties bij een taak zijn gebruikt en welke uitkomsten van elkaar afweken. Dat garandeert geen correctheid of waarheid en elimineert geen hallucinaties, maar het maakt controle mogelijk en ondersteunt de reconstructie die de NIST-functies vragen. Het professionele eindoordeel blijft altijd bij de gebruiker.
Op het gebied van gegevensverwerking is de architectuur van Vera zo ontworpen dat voorbewerking en anonimisering plaatsvinden op EU-infrastructuur. Via de Semantic Privacy Shield kunnen gevoelige documentwaarden vóór AI-verwerking worden vervangen door synthetische, sessiegebonden equivalenten; de AI-keten analyseert de synthetische versie en de oorspronkelijke waarden kunnen lokaal worden hersteld. De workflow is fail-closed: mislukt de privacycontrole, dan wordt het document niet doorgestuurd. Documenten kunnen binnen de beschermde workflow worden bekeken en bewerkt via Vera Office, dat gebruikmaakt van Collabora Online en geen Microsoft Office-plug-in is.
De boodschap uit de bronnen blijft leidend: behandel elke AI-wijziging als een versieerbare, auditeerbare release van een complete bundel. Een verificatieconsole kan dat wijzigingsbeheer zichtbaarder en beter controleerbaar maken, maar de inrichting van canary-routes, rollbackpaden en meetprocessen blijft werk voor de organisatie zelf.