AI model deprecation: je AI-agent heeft een houdbaarheidsdatum

De AI-agent die je vorig jaar hebt gelanceerd draait op een onderdeel met een houdbaarheidsdatum. Het is ook het enige deel van je stack dat iemand anders kan uitzetten. Niet stilletjes uitfaseren in een changelog, maar uitzetten, op een datum die zij kiezen, met soms niet meer dan 60 dagen waarschuwing. Dat is AI model deprecation, en het is de onderhoudspost die vrijwel niemand in de offerte zet.

Dit artikel is geschreven voor oprichters, CTO's en operationeel leidinggevenden die al een AI-agent in productie hebben draaien, of die op het punt staan het budget ervoor goed te keuren. Ben je nog aan het uitzoeken of agents überhaupt nuttig zijn, dan is dit nog niet het juiste stuk. Het probleem dat hier beschreven wordt ontstaat pas als er iets echts draait waar mensen van afhankelijk zijn.

In dit artikel lees je wat AI model deprecation is, op welke twee heel verschillende manieren een modelwissel je pijn doet, wat de gepubliceerde retirement-kalender voor 2026 werkelijk zegt, hoe lang een model realistisch meegaat, de 5 vragen die je moet stellen voordat je een agent-build goedkeurt, wat een migratie kost, en wie daarvoor zou moeten betalen.

Kort samengevat: je hebt geen afgerond systeem gekocht. Je hebt een afhankelijkheid gekocht van de productroadmap van iemand anders. Teams die dat begrijpen behandelen modelwissels als een geplande onderhoudspost: begroot, geoefend, saai. Teams die dat niet doen komen het tegen als een incident, meestal in dezelfde week dat er nog iets anders misgaat.

‍

Belangrijkste punten

• AI model deprecation is het moment waarop een aanbieder een modelversie uitfaseert, waarna aanvragen naar dat model mislukken. Het is een normaal onderdeel van de levenscyclus, geen zeldzame gebeurtenis.

• Anthropic belooft minimaal 60 dagen aankondiging voor publiek uitgebrachte modellen. OpenAI belooft minimaal 6 maanden voor algemeen beschikbare modellen, 3 maanden voor gespecialiseerde varianten, en soms slechts 2 weken voor previewmodellen.

• In de praktijk blijft een frontier-modelversie ongeveer 12 tot 18 maanden beschikbaar. Ga ervan uit dat je het minstens een keer vervangt tijdens de levensduur van je agent.

• De uitschakeling is de goedkope storing. Die is luid, en je foutlogboeken vangen hem op.

• De upgrade die je zelf kiest is de dure. De API blijft succes teruggeven terwijl het gedrag stilletjes verschuift.

• De grootste kostenfactor is het aantal plekken waar de modelversie in je codebase staat opgeschreven.

• Zonder een opgeslagen set echte testgevallen en een afgesproken slaagnorm kun je niet aantonen dat een vervangend model veilig is. Elke migratie wordt dan een discussie over meningen.

• Een goed gebouwde agent vangt een retirement op in 1 tot 3 geplande dagen. Een slecht gebouwde kost 2 tot 6 ongeplande engineerweken.

‍

Wat is AI model deprecation?

AI model deprecation is het proces waarbij een AI-aanbieder een specifieke modelversie markeert als niet langer aanbevolen, er een retirement-datum aan koppelt, en het model vervolgens intrekt. Na die datum mislukken aanvragen naar dat model in plaats van dat ze slechter worden. Het model wordt niet minder goed. Het houdt op te bestaan.

Aanbieders gebruiken een vrij consistente set labels voor de levenscyclus. Een model is actief zolang het volledig ondersteund wordt. Het wordt legacy zodra het geen updates meer krijgt. Het is deprecated zodra er een vervanger wordt aanbevolen en er een retirement-datum is gepubliceerd. Het is retired als het endpoint niet meer antwoordt.

Hier zit geen kwade opzet achter. Aanbieders faseren oude modellen uit om capaciteit vrij te maken voor nieuwe, en ze publiceren de data openlijk. Anthropic houdt een openbare pagina met model deprecations bij met elke aangekondigde retirement, en OpenAI doet hetzelfde in zijn deprecations-documentatie. De informatie is nooit verborgen geweest. Wat mensen verrast, is dat aan hun kant van de tafel niemand de opdracht had om het te lezen.

Dat is het echte gat. Model deprecation is geen technisch probleem dat engineering vergeten is op te lossen. Het is een leverancierskwestie die nooit een eigenaar heeft gekregen, omdat bij het opstellen van de scope iedereen bezig was met de vraag of het überhaupt zou werken.

‍

De twee manieren waarop een modelwissel je pijn doet

De meeste artikelen over dit onderwerp behandelen deprecation als een gebeurtenis. Het zijn er eigenlijk twee, en ze gedragen zich zo verschillend dat juist het op een hoop gooien ervan teams in de problemen brengt.

De luide storing, en dat is de goedkope

Een model bereikt zijn retirement-datum en je aanvragen beginnen te mislukken. Je krijgt foutmeldingen. Iemand wordt gebeld. Het is genant als het onder werktijd gebeurt, en het is echt verstorend als de agent in een klantgericht proces zit.

Maar let op wat er goed is aan deze storing. Hij is ondubbelzinnig, hij verschijnt in monitoring die je al hebt, en niemand discussieert over de vraag of het gebeurd is. Je verliest een paar uur of een dag, je wisselt de modelverwijzing om, je gaat live. Pijnlijk, zichtbaar, begrensd.

De stille verschuiving, en dat is de dure

Kijk nu naar het andere geval, waar niemand ruimte voor inplant. Het oude model verdwijnt, dus je stapt voor de deadline over op de aanbevolen vervanger. Alles geeft succes terug. De latency ziet er prima uit. De dashboards staan op groen.

En de agent gaat zich net iets anders gedragen. Hij formatteert een tool-aanroep op een manier die je parser minder soepel verwerkt. Hij wordt voorzichtiger bij een categorie verzoeken die hij eerder gewoon afhandelde, waardoor een klein deel van de gevallen nu geweigerd wordt en stilletjes in een menselijke wachtrij belandt. Hij schrijft langere antwoorden, wat je tokenkosten verandert. Hij legt een dubbelzinnige instructie de andere kant op uit.

Niets daarvan levert een foutmelding op. Je logboeken zijn schoon, want vanuit de API gezien is er niets mislukt. Het signaal komt weken later via de achterdeur binnen: een supportlead merkt op dat de wachtrij zwaarder aanvoelt, finance vraagt waarom de inferentiekosten zijn gestegen, een klant zegt dat de toon veranderd is. Tegen die tijd kun je het effect niet meer aan de oorzaak koppelen, want er zijn in die weken nog tien andere dingen veranderd.

Dit is de kern die het onthouden waard is. Luide storingen kosten je een dag. Stille verschuiving kost je een kwartaal aan trage verwarring, en juist die is niet zichtbaar in de monitoring die je nu hebt.

‍

Wat de retirement-kalender voor 2026 werkelijk zegt

Dit is niet theoretisch, en het is niet ver weg. Beide grote aanbieders hebben data gepubliceerd die binnen de komende maanden vallen.

Een paar dingen in die kalender verdienen aandacht. De OpenAI Assistants API verdwijnt op 26 augustus 2026 en wordt vervangen door de Responses API. Dat is een interfacewijziging, geen modelwijziging, wat betekent dat agents die er direct op gebouwd zijn code-werk nodig hebben in plaats van een configuratiewissel.

Op 23 oktober 2026 gaan GPT-4, GPT-3.5 Turbo, o1 en o1-pro uit. Een groot aantal productiesystemen dat tussen 2023 en 2025 is gebouwd wijst nog precies naar die namen. En op 11 december 2026 verdwijnen ook de augustus-2025-snapshots van GPT-5 en o3. Dat is het even laten bezinken waard: een model dat halverwege 2025 uitkwam wordt voor het einde van 2026 uitgezet.

Aan de kant van Anthropic werden Claude Sonnet 4 en Claude Opus 4 op 15 juni 2026 uitgefaseerd na 62 dagen aankondiging, en Claude Opus 4.1 op 5 augustus 2026 na 61 dagen. Beide vielen binnen het gepubliceerde beleid van minimaal 60 dagen. Beide waren, als je er niet op lette, ook ongeveer 2 maanden van e-mail tot dood endpoint.

‍

Hoe lang gaat een model eigenlijk mee?

Ongeveer 12 tot 18 maanden. Dat is het getal om mee te plannen, en je kunt het afleiden uit de data hierboven in plaats van iemand op zijn woord te geloven.

Claude Opus 4.1 kwam uit in augustus 2025 en werd uitgefaseerd in augustus 2026, dus vrijwel exact 12 maanden. De GPT-5-snapshot van augustus 2025 verdwijnt in december 2026, ongeveer 16 maanden. Claude Sonnet 4, uitgebracht in mei 2025, verdween in juni 2026, dus 13 maanden. Het patroon is consistent genoeg om op te begroten.

Geef je vandaag opdracht voor een AI-agent en verwacht je dat die 3 jaar draait, dan koop je dus geen model. Je koopt 2 of 3 modelmigraties, of ze nu in de offerte staan of niet. Dat is de zin die in de meeste agent-offertes ontbreekt.

Het is eerlijk om hier ook de andere kant te noemen. Aankondigingstermijnen worden gepubliceerd, vervangers worden aanbevolen, en het nieuwere model is meestal beter en vaak goedkoper per token. Dit is geen valstrik. Het is gewoon een onderhoudscyclus waar de mensen die het budget goedkeuren niets over te horen krijgen, omdat hij onzichtbaar is in de fase waarin iedereen enthousiast is over de demo.

Ben je bezig met de bredere economie van agents in productie, dan behandelt onze SaaS AI Blueprint hoe je begroot voor AI-systemen na de lancering, inclusief de doorlopende kosten die de meeste eerste offertes weglaten. Hij is gratis en je leest hem in ongeveer 20 minuten.

‍

5 vragen die je stelt voordat je een AI-agent goedkeurt

Je hoeft niet technisch te worden om dit risico te beheersen. Je moet 5 vragen stellen in de offertefase, terwijl de antwoorden nog goedkoop te veranderen zijn, en luisteren of de antwoorden concreet zijn of vaag.

De eerste vraag klinkt triviaal en is dat niet. Noemt het antwoord een modelfamilie in plaats van een gedateerde versie, dan wijst de agent naar een bewegend doel: de aanbieder kan veranderen wat er achter die naam zit zonder het je te vertellen, en jouw gedrag verandert mee. Je wilt een specifieke gedateerde versie, bewust vastgezet.

De tweede vraag voorspelt je kosten. Een modelversie die in een configuratiebestand staat is een wijziging van 10 minuten. Diezelfde versie geplakt op 40 plekken verspreid over services, scripts en notebooks is een speurtocht, en dat is het verschil tussen een rustige middag en twee slechte weken.

De vierde vraag, over wie de migratie doet en op wiens budget, is de vraag die kopers het vaakst overslaan en het vaakst betreuren. Eindigt het bouwcontract bij de lancering en zegt het niets over modelwijzigingen, dan komt de eerste retirement binnen als een nieuwe onderhandeling met een partij die inmiddels alle troeven in handen heeft, omdat zij als enige weten hoe het werkt.

Stel deze 5 vragen en je komt veel te weten over hoe de agent gebouwd gaat worden, ruim voordat je een regel code ziet.

‍

Wat er verandert als een agent gebouwd is op modelwissels

Het verschil tussen een agent die voor een model gebouwd is en een agent die modelwissels overleeft is geen verschil in verfijning. Het is een handvol weinig glamoureuze keuzes die vroeg gemaakt worden, en die bij de bouw geen van alle duur zijn.

Zo ziet dat verschil er in de praktijk uit. Twee bedrijven krijgen op maandagochtend dezelfde retirement-mail voor een model waar hun factuurverwerkende agent van afhankelijk is.

Het eerste bedrijf heeft de modelversie op een plek staan en een opgeslagen set van 300 echte facturen met de antwoorden die een mens al goed had gekeurd. Ze richten een kopie van de agent op het vervangende model en draaien die 300 gevallen. Hij scoort 292 goed tegenover eerder 294, en de 2 nieuwe missers zijn allebei een ongebruikelijk creditnotaformaat. Ze passen de instructies aan, draaien opnieuw, komen op 295. Ze sturen 2 dagen lang 10 procent van het live verkeer naar het nieuwe model, zien de cijfers standhouden, en zetten daarna de rest om. Totale inspanning: ongeveer 2 dagen, een maand voor de deadline, door een persoon.

Het tweede bedrijf weet niet op hoeveel plekken naar het model verwezen wordt. Er is geen opgeslagen testset, dus bewijs van juistheid betekent dat een analist handmatig steekproeven doet op wat er deze week toevallig langskomt. Ze vinden verwijzingen in de hoofdservice, daarna in een nachtelijke reconciliatietaak waar niemand aan gedacht had, daarna in een rapportagescript van iemand die het bedrijf verlaten heeft. Ze zetten alles om in het laatste weekend, omdat de deadline hen ertoe dwingt. Drie weken later merkt finance dat een categorie leverancierscredits niet meer gemarkeerd wordt. Niemand kan met zekerheid zeggen wanneer dat begonnen is.

Dezelfde mail, dezelfde aanbieder, dezelfde 60 dagen. Het verschil werd beslist tijdens de bouw, door mensen die niet in de kamer zaten toen het budget werd getekend.

‍

Waarom de testset het echte bezit is dat je koopt

Als je een operationeel ding uit dit artikel meeneemt, laat het dan dit zijn: het waardevolste onderdeel van je AI-agent is niet de prompt en niet de code. Het is de opgeslagen set echte gevallen met afgesproken juiste antwoorden, plus de slaagnorm die je goed genoeg vond.

Prompts worden herschreven. Modelversies worden uitgefaseerd. Frameworks worden vervangen. De testset overleeft dat allemaal, omdat hij iets vastlegt wat geen enkele leverancier je kan geven: wat jouw organisatie een juist antwoord vindt. Dat oordeel komt van jouw mensen, jouw beleid en jouw randgevallen, en het is echt van jou.

Het is ook wat een migratie verandert van een discussie in een meting. Zonder testset is "is het nieuwe model goed genoeg?" een kwestie van mening, en meningen laten zich niet voor een deadline beslechten. Met testset hangt er een getal aan de vraag, en duurt de beslissing een middag.

Een bruikbare testset hoeft niet ingewikkeld te zijn. Een paar honderd echte gevallen uit het werkelijke verkeer, bewust zwaarder gewogen richting de lastige, met het juiste antwoord vastgelegd en een vooraf afgesproken slaagnorm. De lastige gevallen tellen zwaarder dan het aantal, want de makkelijke slagen op elk model en zeggen je niets.

Bouw hem tijdens het eerste project, terwijl de mensen die weten hoe juist eruitziet toch al opletten. Hem 14 maanden later onder tijdsdruk alsnog maken is precies hoe hij er nooit komt.

‍

Wat een modelmigratie kost, en wie ervoor betaalt

Voor een agent die op de eerste manier gebouwd is, met een vastgezette versie, een verwijzingspunt en een echte testset, is een migratie 1 tot 3 dagen werk van een engineer. Het meeste daarvan is wachten op evaluatieruns en het volgen van de canary. Het past binnen normaal onderhoud en heeft zelden eigen goedkeuring nodig.

Voor een agent die op de tweede manier gebouwd is, reken op 2 tot 6 engineerweken, en verwacht dat de kosten op vier plekken landen in plaats van een:

• Het opsporen van elke plek waar naar het model verwezen wordt, wat onbegrensd werk is omdat je niet kunt weten wanneer je klaar bent.

• Handmatig vaststellen of het nieuwe model acceptabel is, omdat er geen opgeslagen testset bestaat.

• Repareren wat het nieuwe model anders doet, wat echt engineeringwerk is en geen configuratie.

• De staart van stille verschuiving die je niet opgemerkt hebt, en die weken later opduikt als supportdruk, kostenstijging of een vervelend klantgesprek.

De commerciële vraag telt hier net zo zwaar als de technische. Heeft een externe partij je agent gebouwd, kijk dan wat je contract zegt over modelwijzigingen, want de meeste zeggen er niets over. Stilte in een contract is hier niet neutraal. Het betekent dat de eerste retirement een nieuwe offerte wordt, geprijsd op een moment dat jij geen onderhandelingsruimte hebt en wel een harde deadline.

Twee contractafspraken zijn het waard om voor ondertekening af te dwingen. Ten eerste een vastgelegde reactie op wijzigingen van de aanbieder: wie handelt, hoe snel, en tegen welk tarief, zodat een retirement-mail een bekend proces start in plaats van een onderhandeling. Ten tweede eigendom van de evaluatieset op papier, zodat de testgevallen en afgesproken antwoorden van jou zijn en mee kunnen naar een andere partner of naar je eigen team. Geen van beide kost iets bij aanvang. Beide zijn achteraf vrijwel niet meer te krijgen.

‍

Hoe wij bij Codelevate met modelwissels omgaan

Wij draaien agents in productie voor klanten, dus we leven met deze cyclus in plaats van hem van een afstand te beschrijven. Onze aanpak is bewust saai.

Elke agent die wij bouwen verwijst op precies een plek naar zijn modelversie, en die versie is altijd een specifieke gedateerde string en nooit een familienaam. Voor de lancering bouwen we de evaluatieset samen met het team van de klant, met hun eigen gevallen en hun definitie van juist, en spreken we de slaagnorm samen af zodat niemand die later onder druk hoeft te bepalen. Die set is volledig eigendom van de klant.

We houden bij op welk model elk klantsysteem draait en toetsen dat aan de gepubliceerde deprecation-pagina's, zodat een retirement-datum ons maanden van tevoren als agendapunt bereikt in plaats van als mail op de ochtend dat het ertoe doet. Komt er een wijziging, dan draaien we eerst de evaluatie tegen de vervanger, vergelijken we met de vorige score, verplaatsen we een klein deel van het verkeer, en houden we de mogelijkheid om binnen een minuut terug te schakelen tot we er zeker van zijn.

Niets hiervan is slim bedacht. Het is het verschil tussen gepland onderhoud en een incident, en het is een groot deel van wat een werkende demo scheidt van een systeem waar je op kunt bouwen. Wil je een second opinion over een agent die al draait, dan kan ons AI-ontwikkelteam bekijken hoe die van jou in elkaar zit en je eerlijk vertellen of je kwetsbaar bent. Lees ook ons stuk over wie eigenaar is van je AI-agent na de lancering, want model deprecation is een symptoom van een grotere vraag over eigenaarschap die de meeste projecten nooit beantwoorden.

‍

De kern

AI model deprecation is geen risico dat je kunt wegnemen, want je hebt de roadmap van de aanbieder niet in de hand. Het is een risico dat je saai kunt maken. Teams die dit goed doen zetten hun versies vast, houden de verwijzing op een plek, bezitten een echte testset, spreken af wie handelt als de mail komt, en oefenen de wissel voordat de deadline hen dwingt.

De verandering die hier te halen valt is bescheiden en veel waard: van een agent die elke 12 tot 18 maanden stilletjes een risico wordt naar een agent die een modelwissel opvangt in een geplande middag. Dat is het verschil tussen een experiment en infrastructuur.

Begroot je voor AI-systemen die ook na de lanceringsdag moeten blijven draaien, dan is de SaaS AI Blueprint het nuttigste gratis stuk dat we hierover publiceren, inclusief de doorlopende kosten die eerste offertes meestal weglaten.

En heb je al een agent in productie en kun je de eerste van die 5 vragen niet beantwoorden, dan is dat een uur waard. Je kunt een plan een gratis gesprek met ons team in en we vertellen je waar je staat, of je nu met ons in zee gaat of niet.