Je API blijft hetzelfde. AI model drift breekt je workflow stil

Wat er gebeurde

Een team waar ik mee werkte had een stabiele classificatie-flow. Tickets gingen netjes naar de juiste queue. Op een maandagochtend waren dezelfde tickets “ineens” support in plaats van sales. De API gaf 200 terug. De modelnaam was ongewijzigd. Alleen het gedrag was verschoven.

Dat is het vervelende van AI model drift: je monitor voor uptime blijft groen. Je workflow faalt op kwaliteit, formaat of weigeringsdrempel. Geen exception. Wel verkeerde beslissingen die doorstromen naar klant of collega.

Kovil AI over model drift beschrijft precies dit patroon: output verandert terwijl de integratie er hetzelfde uitziet. Op DEV over AI workflow automation drift zie je dezelfde les voor geautomatiseerde ketens: als je alleen op HTTP-status let, mis je de drift.

Providers pushen verbeteringen. Soms een stille upgrade achter dezelfde alias. Soms een snapshot die “latest” heet en morgen anders antwoordt. Callsphere over silent downgrades legt nuchter uit waarom pin-snapshots ertoe doen. Geen complot. Wel een release die jij niet zelf hebt goedgekeurd.

Als je modelalias “stabiel” heet maar je output niet meet, heb je geen stabiele productielijn. Je hebt een open deploy-slot.

Waarom dit relevant is

In productie hangt AI zelden aan één chatvenster. Het hangt aan prompts, parsers, drempels en downstream-systemen. Eén verschoven JSON-veld breekt je parser. Eén strengere weigering stopt je batch. Eén zachtere classificatie stuurt werk naar de verkeerde queue.

AWS noemt dit in hun Prescriptive Guidance over drift monitoring een operationeel risico: je moet drift in productie meten, niet alleen bij de eerste demo. Dat geldt voor een team van vijftien net zo goed als voor een concern met een MLOps-afdeling.

Drie plekken waar ik AI model drift het hardst zie toeslaan:

• Formaat. Gisteren strikte JSON, vandaag een inleiding plus code fence. Je parser faalt stil of half.
• Gedrag. Labels, toon of weigeringsdrempel schuiven. Mensen merken het pas als klachten binnenkomen.
• Kosten en latentie. Zelfde call, andere runtime. Budgets en SLA’s glijden weg zonder alarm.

Dit lijkt op het ROI-probleem waarover ik schreef in zonder baseline is je AI-ROI een verhaal. Zonder golden set weet je niet of “het model beter is” of dat jouw workflow stiller kapot gaat. En als je pilot al negen maanden “bijna live” is, zoals in je AI-pilot is al negen maanden bijna live, dan is drift niet theoretisch. Dan is elke stille update een productie-incident zonder ticket. En meer chatten met ChatGPT maakt je bedrijf niet rijker: zonder meetbare output blijft drift onzichtbaar.

Wat je nu kunt doen

Geen nieuw platform. Wel vier gewoonten die je AI-keten behandelen als software die je zelf release.

1. Pin snapshots, niet alleen modelnamen

Gebruik vaste snapshot- of revision-IDs waar de provider die biedt. “gpt-x” of “claude-y-latest” is handig voor experimenten, riskant voor productie. Pin wat gisteren werkte. Upgrade bewust, met een rollback-pad.

2. Bouw een golden set en run die bij elke upgrade

Vijftig tot honderd echte voorbeelden met verwachte output (label, JSON-schema, weiger/ja). Draai die set vóór je een nieuwe snapshot activeert. Faalt 5% op schema of accuracy? Dan is het geen “kleine update”. Dan is het een failed deploy.

3. Treat provider upgrades as deployments

Zelfde ritme als bij code: staging, diff op golden set, canary op een deel van het verkeer, pas daarna 100%. Iemand tekent af. Changelog van de provider is input, niet een verrassing in je inbox.

4. Monitor output, niet alleen uptime

Track parse-falen, label-distributie, weigeringsratio, latencie en tokenkosten per flow. Alarmeer op verschuiving, niet alleen op 5xx. Dat is de kern van output-monitoring bij AI model drift: je ziet kwaliteit glijden vóór de business belt.

Voor prompts en evaluatie die dit volhouden, helpt vaak AI-modeloptimalisatie meer dan nóg een tool. Wil je agents en flows die niet stil kapot gaan bij elke provider-push? Kijk naar managed AI-agents of plan een kort gesprek via contact.