AI-implementatie stopt niet bij livegang. Het stopt, als het al stopt, ergens in het tweede jaar: wanneer het model waarop u bouwde uit productie gaat, wanneer het systeem waaruit het leest van vorm verandert, of wanneer de ene persoon die het begreep een andere baan neemt. Bijna niemand vraagt mij naar dat jaar. De offertes die ik word gevraagd uit te brengen gaan over de bouw, en het grootste risico zit in wat daarna komt.
Waarom vraagt niemand wat er na livegang gebeurt?
Ik heb inmiddels enkele honderden eerste gesprekken gevoerd met Nederlandse en Vlaamse ondernemers, en de vragen zijn opvallend constant. Wat kan het. Hoe lang duurt het. Wat kost het. Voor wie heeft u dit eerder gebouwd. Dat zijn goede vragen en ik zou ze zelf ook stellen. Maar in ongeveer één op de tien gesprekken vraagt iemand hoe dit ding er over achttien maanden uitziet, en op wiens bureau het dan ligt.
Dat is geen gebrek aan verstand. Zo hebben we allemaal geleerd software te kopen: als een investering met een opleverdatum, een livegang en een klein feestje. Het project heeft een einde, dus het ding moet ook een einde hebben. Er is bovendien een stillere reden aan mijn kant van de tafel, en die noem ik maar gewoon. Het tweede jaar ter sprake brengen maakt een offerte ingewikkelder. Het voegt een regel toe waar niemand budget voor had en een gesprek over wie dat werk gaat doen. In de eerste periode van Crux Digits begon ik er zelf ook niet over, tenzij de klant dat deed. Dat was een fout, en de systemen die stilvielen hebben mij dat geleerd.
Uw AI-model heeft een einddatum, en die staat gepubliceerd
Dit is het deel dat vrijwel elke koper verrast, en het is in tien seconden te controleren. Het grote model dat uw systeem aanroept heeft een gepubliceerd einde.
Anthropic houdt een pagina met modeluitfaseringen bij met een statustabel waarin elk actief model een "not sooner than"-datum vermeldt, en het bedrijf belooft een aankondigingstermijn van minimaal 60 dagen voordat een publiek uitgebracht model wordt uitgezet. Dat zijn geen hypothetische data. Claude Opus 4.1 werd op 5 juni 2026 aangekondigd voor uitfasering en accepteerde vanaf 5 augustus 2026 geen verzoeken meer, eenenzestig dagen later. Claude Sonnet 3.7 en Claude Haiku 3.5 gingen allebei op 19 februari 2026 uit de lucht. Zodra die datum voorbij is, mislukken verzoeken aan dat model op de API van de aanbieder zelf.
OpenAI publiceert zijn eigen aankondigingstermijnen, per modelsoort: minimaal zes maanden voor algemeen beschikbare modellen, minimaal drie maanden voor gespecialiseerde varianten, en soms slechts twee weken voor previewmodellen, met het uitdrukkelijke advies previewmodellen niet te gebruiken voor bedrijfskritisch productiewerk tenzij u op korte termijn kunt migreren.
Ik wil hier zorgvuldig zijn, want dit is geen schandaal en het is geen pleidooi tegen gehoste modellen. Gepubliceerde data en notificatiemails zijn meer openheid dan de meeste bedrijfssoftware biedt; genoeg pakketten op eigen servers sterven zonder zelfs maar een brief. Het punt is smaller en praktischer. Niemand aan de koperskant van een AI-project heeft ooit in deze termen hoeven denken. Uw boekhoudpakket stopt niet op een donderdag in augustus met antwoorden. Een model wel, en die datum stond al die tijd op een openbare webpagina.
Dat levert precies twee eisen op, allebei saai. De modelnaam moet op één plek in uw systeem staan, als één configuratiewaarde in plaats van verspreid door code en een stuk of twaalf opgeslagen prompts. En een met naam genoemde medewerker bij uw eigen bedrijf, niet alleen bij uw leverancier, moet op het account staan dat de melding ontvangt. Ik schreef eerder over waarom ik bouw om consultant-lock-in te voorkomen; dit is hetzelfde principe op de schaal van één regel configuratie. Het is ook het eerste wat ter sprake komt bij de vraag over zelf een open-weight model draaien, wat het probleem verplaatst in plaats van het op te lossen. U houdt de gewichten en u erft de hosting, het patchen en de beveiligingsupdates. Beide regelingen hierboven zijn in september 2026 gelezen op de pagina's van de aanbieders zelf, en beide worden van tijd tot tijd herzien, wat op zichzelf al iets zegt.
Wat breekt er in het tweede jaar?
Vier dingen, in de volgorde waarin ik ze zie. Het model staat op die lijst. Het staat er niet bovenaan.
1. De systemen waaruit het leest
Een AI-systeem ziet de wereld vrijwel nooit rechtstreeks. Het ziet de wereld door de datastructuur van iemand anders: een export uit Exact of AFAS, een orderregel uit een WMS, een pdf-opmaak die een leverancier heeft herzien, een API-versie met een afbouwmelding ergens in de release notes. Dit is de meest voorkomende oorzaak van een systeem dat ongemerkt onjuist is geworden, terwijl er aan de AI helemaal niets veranderde. Een veld kreeg een andere naam, of een leverancier zette het factuurtotaal twee centimeter naar links, en een extractie die vrijwel altijd goed was zit er nu vaak genoeg naast om schade aan te richten, en niemand heeft gekeken.
2. De aannames die erin zijn vastgelegd
Elke automatisering draagt een momentopname van het bedrijf op de dag dat zij werd gebouwd. Dan komt er een nieuwe productlijn, een andere btw-behandeling, een klanttype dat vorig jaar niet bestond, een regel die het verkoopteam in een niet genotuleerd overleg veranderde. Het systeem protesteert niet. Het blijft zelfverzekerde, keurig opgemaakte uitvoer produceren voor een bedrijf dat verder is gegaan. Zelfverzekerdheid zonder juistheid is het kenmerkende faalpatroon van taalmodellen, en in jaar twee is het gevaarlijker dan in week één, omdat inmiddels niemand meer controleert. Draait u een eigen getraind model in plaats van een gehost model, dan komt hetzelfde binnen via drift in de data zelf.
3. De persoon
Binnen een paar maanden na livegang wordt één iemand degene die dat AI-ding kent. Meestal niet iemand van IT. Het is de persoon die zowel het proces als het gereedschap begreep, en die het systeem in zijn hoofd draagt in plaats van in een document. Dan krijgt hij promotie, of neemt hij die baan bij dat grotere bedrijf verderop, en draait het ding onbeheerd door tot het óf irrelevant óf onjuist is. Dit is het organisatorische faalpatroon waar ik steeds op terugkom, en documentatie alleen lost het niet op. Twee mensen wel.
4. Het model
En dan het model, dat na die drie bijna een opluchting is. Het is een datum, vooraf gepubliceerd, met een aanbevolen vervanger en een migratiehandleiding erbij. Staat de modelnaam op één plek en test iemand de vervanger vóór de deadline, dan is het een middag werk. Zo niet, dan is het een storing waarover een klant u belt.
Van wie is het systeem in jaar twee?
Het eerlijke antwoord is dat eigenaarschap meestal onbenoemd blijft, en alles wat onbenoemd blijft komt vanzelf bij niemand terecht.
Mijn standpunt, vaker verdedigd dan meteen beaamd: het systeem hoort bij de afdeling waarvan de cijfers veranderen, niet bij IT. IT beheert het, zoals IT de mailserver beheert. Maar wie verantwoordelijk is voor de vraag of de uitvoer deugt, moet de persoon zijn wiens eigen werk er makkelijker of moeilijker van wordt. Is de financiële afdeling eigenaar van factuurherkenning, dan merkt iemand in week één dat de opmaak van een nieuwe leverancier het stukmaakt. Is IT eigenaar, dan wordt diezelfde storing een melding die niemand maakt, omdat de mensen die de slechte data zien niet weten dát die slecht is.
In de praktijk heeft dat eigenaarschap een naam en een ritme nodig, en allebei horen ze op papier vóór livegang in plaats van erna. Wekelijks in de eerste maand en daarna maandelijks volstaat meestal voor een klein systeem: iemand opent twintig uitkomsten en vraagt zich af of hij daar zijn eigen naam onder had gezet. Het is weinig glamoureus werk en het kost een half uur. Het is ook precies het verschil tussen een systeem dat in jaar twee nog vertrouwd wordt en een systeem waar men stilletjes omheen is gaan werken terwijl iedereen bleef zeggen dat het live stond.
Het land dat onderhoud allang begrijpt
Er zit iets licht absurds in het uitleggen van onderhoud aan een Nederlands publiek.
De Unie van Waterschappen noemt de waterschappen de oudste democratische instellingen van Nederland. Ze bestaan sinds de dertiende eeuw en worden apart in de Grondwet genoemd, naast het Rijk, de provincies en de gemeenten. Het zijn er eenentwintig. Elk jaar stelt het algemeen bestuur de waterschapsbelasting vast en bepaalt het waaraan dat geld wordt besteed. Niemand in dit land beschouwt een dijk als een afgerond project. Niemand betaalt er één keer voor en verwacht er daarna nooit meer iets over te horen. De rekening komt jaarlijks, zolang iemand hier wil wonen, en niemand ziet dat als bewijs dat de oorspronkelijke aanleg mislukt is. Het geldt als de voorwaarde voor droge voeten.
En vervolgens koopt diezelfde ondernemer software alsof het een eenmalige aanschaf is, en ervaart hij de aandacht in het tweede jaar als een budgetoverschrijding in plaats van als de kern van de zaak. Het verschil zit niet in kennis. Het zit erin dat een dijk bij wet een bestuur en een heffing heeft, en uw AI-systeem geen van beide, tenzij iemand ze er bewust aan geeft.
De drie vragen die ik nu in elke offerte zet
Geen van deze vragen is slim bedacht. Het zijn simpelweg de drie leemtes die ik het duurste stilzwijgen heb zien veroorzaken.
Welk model, en waar staat die naam opgeschreven?
Expliciet benoemd, vastgelegd in één configuratiewaarde, met de uitfaseringspagina van de aanbieder in het overdrachtsdocument en een medewerker van de klant op de notificatielijst. Kan een leverancier dit niet in één zin beantwoorden, dan koopt u iets dat u zonder hem niet kunt onderhouden, en dat was waarschijnlijk niet wat u dacht te kopen.
Uit welke systemen leest het, en wie waarschuwt ons als die veranderen?
Noem ze bij naam. Bepaal daarna wie zich abonneert op de release notes van elk ervan: die van uw ERP-partner, die van uw WMS-leverancier, die van de leverancier wiens documentopmaak u uitleest. Bij de meeste tweedejaarsstoringen waarvoor ik werd gehaald, stond het antwoord op "waarom werkt het niet meer" in release notes die bij geen van beide bedrijven iemand had gelezen.
Wie kijkt naar de uitvoer, hoe vaak, en wat mag diegene zelf aanpassen?
Een naam, een frequentie en een grens. Dat laatste weegt zwaarder dan mensen verwachten. Kan de gebruiker geen regel of formulering aanpassen zonder een ticket, dan raakt het systeem achterhaald en herstelt niemand het, omdat de herstelactie meer aandacht kost dan de fout. Een deel van dat werk kunt u zelf doen; een deel is het waard om terug te leggen bij wie het bouwde. Hoe dan ook hoort in het kostengesprek bij de offerte wat het kost om het draaiend te houden, niet in een verrassende factuur in maand veertien.
Wat dit zou moeten veranderen aan hoe u AI koopt
Vooral zou het u kleiner moeten laten bouwen. Een systeem waarvan het tweede jaar betaalbaar is in aandacht én in geld, is een systeem dat nog draait wanneer het er werkelijk toe doet. De projecten die ik heb zien overleven waren zelden de ambitieuze. Het waren de projecten die zo smal waren dat één persoon het geheel achttien maanden later nog in zijn hoofd had en het een collega op de gang kon uitleggen.
Het zou ook één vraag in het eerste gesprek moeten veranderen. Het nuttigste dat een aspirant-klant mij kan vragen is niet wat het systeem gaat doen. Het is: wat gebeurt er als we dit willen uitzetten? Een leverancier met een helder antwoord heeft over jaar twee nagedacht. De data is van u, hier is de export, dit valt stil en dit blijft werken. Een leverancier die ongemakkelijk kijkt heeft u zojuist het belangrijkste verteld dat u die dag zou leren, en dat nog voordat u iets had getekend.
AI-implementatie is geen opleverdatum. Het is het eerste jaar van iets dat nu van u is, en in het tweede jaar merkt u of u het bezit of dat het u bezit.
