Versioneer prompts, modellen en workflowlogica als één AI-release

Een AI-release is de volledige configuratie die het geleverde gedrag bepaalt, niet alleen een prompttekst of modelendpoint. Wie uitsluitend het model terugzet, kan de gewijzigde prompt, tooldefinitie, bevoegdheidsregel, contextbron of retryroute ongemerkt laten draaien. Zonder één identiteit voor de hele bundel blijft bij een storing onduidelijk wat precies is getest, welke configuratie een verzoek heeft afgehandeld en welke bekende goede combinatie veilig het verkeer kan overnemen.

Wat hoort samen één AI-release te vormen?

Eén AI-release omvat iedere relevante runtimeafhankelijkheid die gedrag, bevoegdheid, risico, kosten, snelheid of waarneembaarheid materieel kan veranderen. NIST behandelt activiteiten en betrokkenen in de AI-levenscyclus als onderling afhankelijk; Google Cloud beschrijft een productiesysteem voor machine learning eveneens als meer dan modelcode alleen. De praktische grens is daarom de werkende configuratie die een echt verzoek ontvangt en afhandelt, inclusief relevante onderdelen van derden.

• De prompt, het opgeloste model-ID en alle effectieve inferentieparameters.
• Tool- en invoerschema’s, toegangsrechten, goedkeuringsregels, beleid en guardrails.
• Retrieval-, context- en routeringsinstellingen, workflowcode en uitvoerschema’s.
• Runtimeafhankelijkheden en omgevingsbindingen die de afhandeling per verzoek kunnen beïnvloeden.
• Versies van evaluatiesets, beoordelaars, rubrics en drempels die het promotiebesluit onderbouwen.

Evaluatiemiddelen draaien doorgaans niet mee in het servingpad, maar horen wel bij het releasebewijs. Een nieuwe rubric of drempel kan immers dezelfde uitslag anders laten wegen. Geef de runtimekandidaat daarom één release-ID en koppel daar de gebruikte assurance-assets aan. Neem een afhankelijkheid alleen op als die de dienst of het toelatingsbesluit merkbaar kan beïnvloeden; zo blijft het register volledig zonder een inventaris van elk technisch detail te worden.

Hoe bind je de gedragsstack in een releasemanifest?

Bevries voor iedere kandidaat een manifest met stabiele verwijzingen naar alle opgenomen componenten en hun effectieve instellingen. Een alias als ‘productie’ of ‘nieuwste’ is slechts een beweegbare aanwijzer; bewaar het opgeloste versienummer, commit-ID, artefactdigest of de inhoudshash. Dat is extra belangrijk wanneer een register een prompt onveranderlijk maakt, maar gekoppelde modelinstellingen of aliassen nog wel laat wijzigen. Zet een beschikbare, geteste modelsnapshot vast zonder daar deterministische uitvoer van te beloven.

• Release-ID, aanmaaktijd, eigenaar, doeldienst, status en vorige bekende goede release.
• Opgeloste componentversies, digests of hashes plus alle effectieve parameters.
• Featureflag-ID, routeringsvoorwaarden, goedgekeurde verbindingen en data- of retrievalreferenties, maar geen geheimen.
• Compatibiliteitsvoorwaarden, migraties, stopcriteria, rollbackeigenaar en herstelrunbook.
• Koppelingen naar buildbewijs, evaluatieresultaten, goedkeuringen en latere deploymentgebeurtenissen.

Voor een interne supportassistent kan support-assistant-r18 bijvoorbeeld prompt p-42, modelsnapshot m-2026-07 met parameters, CRM-toolschema t-9, beleid policy-12, workflowcommit wf-a71, uitvoerschema reply-6 en het runtime-lockbestand binden. Het releasepakket koppelt eval-23 en de beoordelaars apart. Kandidaat r17 is pas een geldig rollbackdoel nadat is gecontroleerd of die versie overweg kan met de nieuwe optionele velden voor vervaldatum en escalatiereden.

Kan iets het geleverde gedrag of de toestemming daarvoor veranderen, dan verdient het een opgeloste identiteit in het releasebestand.

Welk bewijs bepaalt of de kandidaat verder mag?

De kandidaat mag alleen verder op basis van bewijs over exact de gebundelde configuratie die uiteindelijk verkeer krijgt. Schrijf releasenotities daarom als beslisdocument: benoem het beoogde gedrag, alle gewijzigde afhankelijkheden, geraakte scenario’s en interfaces, gewijzigde bevoegdheden of observatie, bekende beperkingen, resterend risico, uitroleigenaar en het compatibele rollbackdoel. Een lijst met commits zonder gevolg voor gebruikers of bedrijfsprocessen is daarvoor te mager.

• Controleer of manifests oplossen, schema’s aansluiten, tools laden en bindings geldig zijn.
• Vergelijk workflowspecifieke taakresultaten, belangrijke segmenten en kostbare randgevallen met de huidige release.
• Test beleidsgrenzen, bevoegdheden, vereiste goedkeuringen en verboden toolhandelingen afzonderlijk.
• Beoordeel fouten, latency, gebruik, kosten per afgeronde taak, tracekwaliteit en waarschuwingen.
• Leg per poort de uitkomst promoveren, vasthouden of afwijzen vast, met een verantwoordelijke eigenaar.

Algemene modelevaluaties dekken niet alle nuances van een specifieke bedrijfsworkflow. Gebruik daarom echte, passend beheerste voorbeelden, relevante randgevallen en controleer ook de kwaliteit van automatische beoordelaars. Eén gunstig totaalcijfer mag een materiële fout in contract, bevoegdheid, veiligheid, toolgedrag of een belangrijk segment niet neutraliseren. Versioneer dataset, rubric, beoordelaar en drempel naast de uitslag, zodat later zichtbaar blijft volgens welke maatstaf de kandidaat is toegelaten.

Maak de poorten afdwingbaar waar het risico dat rechtvaardigt. Deploymentplatforms kunnen bijvoorbeeld onafhankelijke beoordelaars en externe kwaliteits- of observatiecontroles vereisen en zelfgoedkeuring beperken. Een klein team kan rollen combineren, maar niet het besluitspoor overslaan. Noteer wie de uitkomst gaf, op welk bewijs die rustte en of een uitzondering is gebruikt; daarmee wordt goedkeuring een controleerbare handeling in plaats van een mondeling akkoord.

Hoe gaat dezelfde kandidaat gecontroleerd naar productie?

Dezelfde opgeloste kandidaat gaat in meetbare stappen naar productie; de configuratie verandert onderweg niet. Begin waar mogelijk met shadow- of replayverkeer zonder uitvoerende neveneffecten. Schakel schrijvende tools uit of plaats ze in een sandbox, zodat een test geen echte taak, melding of gegevenswijziging herhaalt. Daarna volgen interne gebruikers, een stabiel toegewezen productiecohort, bredere blootstelling en uiteindelijk al het verkeer.

1. Speel representatieve verzoeken niet-actuerend af en vergelijk volledige workflowtraces met de huidige release.
2. Laat een interne gebruikersgroep de kandidaat gebruiken terwijl vereiste goedkeuringen actief blijven.
3. Routeer een sticky cohort naar de kandidaat en vergelijk taak-, veiligheids-, tool-, betrouwbaarheids-, latency- en kostensignalen.
4. Breid alleen uit wanneer het vooraf gekozen bewijs en observatievenster voldoende zijn en er geen stopconditie is geraakt.
5. Ga naar volledig verkeer, behoud het rollbackdoel gedurende de afgesproken periode en blijf per release monitoren.

Registreer cohortregels, verkeersverdeling, waarnemingstijd en besluit als deploymentgebeurtenissen bij het onveranderlijke manifest. Een vooraf goedgekeurde verhoging van blootstelling kan dezelfde kandidaat houden; een wijziging in prompt, modelinstelling, tool, bevoegdheid, beleid, context, workflow, schema, dependency of gedragsbepalende binding vereist een nieuw ID. Kies geen universeel canarypercentage: verkeersvolume, servicerisico, detectievertraging en operationele capaciteit bepalen hoeveel observatie nodig is. Ook een sticky cohort kan zeldzame fouten missen.

Wanneer stopt de release en wat moet rollback herstellen?

Stop de release direct bij een vooraf benoemde veiligheids- of beleidsschending, onbevoegde toolhandeling, materiële contractbreuk of ernstige betrouwbaarheidsfout. Leg voor andere regressies servicespecifieke grenzen vast vóór de eerste blootstelling. Niet iedere onduidelijke bevinding vraagt onmiddellijk om rollback: een pauze met onderzoek kan passender zijn. Ook dan moeten cohort, verkeersstatus, besliseigenaar en eerstvolgende controle expliciet zijn, zodat ‘tijdelijk aankijken’ geen onbeheerde productiestand wordt.

Rollback herstelt het verkeer naar de volledige, compatibele bekende goede release en niet naar één willekeurig ouder model. Oefen die wissel vooraf en controleer schema’s, opgeslagen toestand, providerbeschikbaarheid, toolcontracten, routering en migraties. Een eerdere release kan technisch nog bestaan maar onbruikbaar zijn geworden door een nieuw verplicht veld of gewijzigde externe interface. Bewaar daarom zowel het beoogde hersteldoel als het resultaat van de meest recente compatibiliteitscontrole.

• Leg trigger, eerste waarneming, getroffen release, cohort en workflowpaden vast.
• Herstel verkeer en valideer de bekende goede bundel met gerichte dienstcontroles.
• Zoek getroffen verzoeken en externe actie-ID’s op via releasegebonden traces.
• Voer containment, reconciliatie, correctie, notificatie of compensatie uit via een afzonderlijk bevoegd runbook.

Een configuratierollback verandert uitsluitend de toekomstige routering. Hij verwijdert geen verzonden berichten, geschreven gegevens, goedkeuringen of reeds aangemaakte CRM-taken. Bij de supportassistent betekent een onjuiste taak bijvoorbeeld dat de actieroute wordt gesloten, de betrokken taak-ID’s uit traces worden gehaald en de bevoegde correctieprocedure wordt gevolgd. De precieze herstelactie hangt af van het externe systeem en organisatiebeleid; een technisch releaseproces kan die bevoegdheid niet zelf bepalen.

Welk dossier maakt de release later reconstrueerbaar?

Een duurzaam releasedossier reconstrueert de effectieve configuratie, het waargenomen bewijs en het genomen besluit. Bewaar daarom het onveranderlijke manifest met opgeloste identifiers en parameters, de gebruikte assurance-assets en resultaten, compatibiliteitsbevindingen, goedkeuringen, deploymentgebeurtenissen, verkeersverdeling, relevante traces, afwijkingen, rollbackgebeurtenissen en de eindstatus. Koppel de release-ID aan ieder verzoekspoor, zodat zichtbaar is welke generatie, toolaanroep, overdracht en guardrail bij de afhandeling hoorde.

• Componentversies, digests, effectieve instellingen, eigenaar, uitvoerder en tijdstippen.
• Evaluatieset, rubric, beoordelaar, drempels, vergelijking met de basisversie en gatebesluit.
• Cohort- en routeringsregels, blootstelling, observatieperiodes en promotie- of stopbesluiten.
• Applicatietrace-ID’s en provider-request-ID’s waar die beschikbaar en bruikbaar zijn.
• Rollbackdoel, compatibiliteitscontrole, verkeersherstel en afzonderlijke afhandeling van externe gevolgen.

Volledigheid vereist niet dat elke prompt, toolinvoer, modeluitvoer of klantpayload onbeperkt wordt bewaard. Tracing kan workflowhiërarchie en metadata vastleggen terwijl gevoelige model- of toolinhoud wordt uitgesloten. Laat classificatie, toegang en bewaartermijnen volgen uit het informatiebeleid van de organisatie. Identifiers en beheerste bewijsmonsters zijn vaak voldoende om een release te onderzoeken; extra inhoud opslaan zonder vastgesteld doel vergroot vooral het informatie- en toegangsrisico.

Noem het resultaat configuratiereproduceerbaarheid en besluitreproduceerbaarheid. Een vastgezette snapshot, contenthash of gearchiveerde aanvraag garandeert geen byte-identieke uitvoer van een stochastische of gehoste AI-dienst. Begin daarom met het kleinste releasepakket dat de kandidaat, het bewijs, de promotiebesluiten en het rollbackdoel ondubbelzinnig identificeert. Betrek bevoegde security-, privacy-, juridische, records-, risico- of domeinspecialisten wanneer een wijziging gevoelige gegevens, verstrekkende bevoegdheden, gereguleerde processen, bewaarplichten of herstel van externe acties raakt.