Van AI-demo naar beheerste modelupdate: kies eerst de leerlus
Kies een beheerde updatecyclus vóór je nieuw gedrag live zet
Een demo beantwoordt hooguit de vraag of een model een taak kan uitvoeren in de getoonde situatie. Voor een productteam volgt daaruit een andere keuze: behandel iedere wijziging aan model, prompt, data of configuratie als een beheerde release. De Europese Commissie noemt onder meer governance en kwaliteit van datasets, logging, menselijk toezicht, nauwkeurigheid, robuustheid en post-market monitoring als gebieden waarvoor geharmoniseerde normen worden voorbereid. Dat is geen voorschrift voor een specifieke technische inrichting, maar wel een bruikbare reikwijdte voor het ontwerp van je leerlus. Leg daarom vóór een release vast welke feedback bruikbaar is, wie de data goedkeurt, welke private eval de verandering toetst en wie een terugvalbesluit mag nemen.
Maak van feedback bewijs, geen automatische trainingsinput
Feedback is pas leerbaar materiaal wanneer de herkomst, betekenis en toestemming duidelijk zijn. De NIST-passage vraagt expliciet of derden een proces hebben om mogelijke kwetsbaarheden, risico’s of vertekeningen in een AI-systeem te melden. Richt zo’n route in voor gebruikers, domeinexperts en beheerders, maar houd melding, beoordeling en hergebruik uit elkaar. Een negatieve beoordeling kan een evaluatiecase opleveren zonder dat zij meteen trainingsdata is. Een expertcorrectie kan waardevol zijn, mits een eigenaar haar controleert en de context bewaart. Hiermee blijft zichtbaar welk signaal tot welke wijziging heeft geleid en voorkom je dat ruis of ongeschikte data ongemerkt modelgedrag stuurt. Noteer per kandidaat-update ook de verwachte verbetering én de gevallen waarin die verbetering niet hoeft te gelden.
Gebruik een releasebeslisregister als praktisch hulpmiddel
Gebruik voor één concrete workflow een klein beslisregister, niet een breed governanceprogramma. Noteer per versie: de wijziging, de goedgekeurde databron of feedback, de private-evalcases, de gemeten uitkomst, de eigenaar, het monitoringssignaal en de terugvalversie. Het praktische artefact voor deze versie luidt: “Leg per modelupdate de goedgekeurde feedbackbron, eigenaar, private eval, monitoringssignaal, livebesluit en terugvalversie vast.” Zo wordt rollback een vooraf gekozen handeling in plaats van improvisatie na een incident. De bronpassages onderbouwen geen universele drempelwaarden, wettelijke classificatie of gegarandeerde kwaliteitswinst voor een individuele toepassing; ze noemen wel relevante beheergebieden. Deze bronpassages beschrijven relevante beheergebieden, maar geen universele drempelwaarden, wettelijke classificatie of garantie dat een individuele modelupdate beter presteert.
