Wat gebeurt er met een AI-hulpmiddel na zes maanden?

De vraag die te weinig gesteld wordt

Bij de meeste AI-trajecten gaat de aandacht naar de eerste week: wat er gebouwd wordt, hoe snel het draait, wat het meteen oplevert. Wat er zes maanden later gebeurt, komt zelden ter sprake, wanneer de nieuwigheid eraf is en niemand er nog dagelijks bij stilstaat. Toch is dat precies het moment waarop de meeste interne automatiseringen bij kmo’s in de problemen komen. Stilletjes, niet met een knal.

Waarom een hulpmiddel stil uitvalt

Een hulpmiddel dat vandaag perfect werkt, draait op een reeks aannames. Een leverancier levert facturen aan in een vast formaat. Een systeem blijft dezelfde velden gebruiken. Een API-koppeling, de automatische verbinding tussen twee systemen, blijft bestaan zoals ze is opgezet. Die aannames zijn geen fouten van de bouwer. Het zijn gewoon de spelregels op het moment van bouwen. Het probleem is dat die spelregels na verloop van tijd veranderen, zonder dat daar enige aankondiging bij hoort.

Een leverancier stapt over op een nieuw boekhoudpakket en de PDF-lay-out van hun facturen verandert. Een CRM krijgt een update en een veld dat het hulpmiddel uitleest, wordt hernoemd. Een API-versie wordt uitgefaseerd. Op zichzelf zijn dat kleine, normale wijzigingen, het soort dingen die overal voortdurend gebeuren. Voor een hulpmiddel dat op de oude structuur gebouwd is, is dat al genoeg om het stil te laten vastlopen.

Het echte probleem is niet die wijziging zelf. Het is dat de meeste interne tools geen enkel signaal geven wanneer dat gebeurt. Ze stoppen niet met een duidelijke foutmelding op een scherm dat iemand toch elke dag bekijkt. Ze verwerken gewoon niets meer. Erger nog: soms verwerken ze iets verkeerd, zonder dat er een alarm afgaat. Weken of maanden later merkt iemand toevallig dat een taak die “geautomatiseerd” was, eigenlijk al een tijd niet meer gebeurde. Op dat moment is het probleem niet alleen technisch, het is ook een vertrouwensprobleem: iedereen dacht dat het onder controle was.

Er is nog een tweede, minstens even belangrijke oorzaak: er is niemand die het hulpmiddel als “van hen” beschouwt. Wanneer de bouwer vertrekt zonder dat iemand intern de rol van eigenaar overneemt, merkt niemand meer wanneer er iets misloopt. Er is dan ook niemand om een wijziging te melden of een aanpassing te vragen. Een hulpmiddel zonder eigenaar is, letterlijk, een wees — het overleeft alleen zolang niets rondom het verandert.

Wat een hulpmiddel wél laat overleven

Drie dingen maken het verschil tussen een tool die na zes maanden nog draait en een die stil is uitgevallen.

Het draait op systemen die u al bezit. Een hulpmiddel dat leeft binnen uw mailbox, uw CRM, uw ERP-systeem of een automatiseringsplatform waarvoor u al betaalt, blijft bestaan ongeacht wie het gebouwd heeft. Heeft het een eigen plek nodig om te draaien, dan kan dat ook: een klein, betaalbaar servertje dat u zelf rechtstreeks betaalt en beheert. Het draait dan in een container, een pakket dat de software en haar instellingen samen meeneemt, zodat het bij een wijziging van provider gewoon meeverhuist. Niets hangt af van of de bouwer nog bereikbaar is.

Fouten zijn zichtbaar, niet stil. Stuurt een hulpmiddel een e-mail of bericht naar een vaste persoon zodra het vastloopt of iets tegenkomt dat het niet kan verwerken? Dan wordt het probleem niet pas na maanden ontdekt. Het meldt zichzelf op de dag dat het ontstaat. Dan is het nog een kwestie van minuten om te begrijpen wat er gebeurde, geen weken speurwerk achteraf. Dat is ook waarom een hulpmiddel dat stil faalt eigenlijk erger is dan geen hulpmiddel: bij geen hulpmiddel weet u tenminste dat het werk nog manueel moet gebeuren.

Er is een interne eigenaar. Iemand bij u weet dat het hulpmiddel bestaat: niet per se de meest technische persoon, wel iemand die het proces kent. Die persoon weet wat het hulpmiddel hoort te doen, en wie te contacteren wanneer het meldt dat er iets misloopt. De overdrachtsdocumentatie is voor die persoon geschreven, niet voor een ontwikkelaar: wat het doet, wat het activeert, hoe het eruitziet als het stuk is, en wat de eerste dingen zijn om te controleren.

Wat u realistisch mag verwachten

Geen van deze drie dingen maakt een hulpmiddel onderhoudsvrij. Dat is ook niet de belofte. Systemen die vandaag draaien, hebben af en toe gewoon aandacht nodig: een leverancier die verandert, een koppeling die bijgewerkt moet worden, een servertje dat een update nodig heeft. Dat hoort bij automatisering, of ze nu bij een kmo of bij een groot bedrijf draait. Het verschil zit in iets anders: merkt u het meteen, en is er iemand die weet wat te doen wanneer het zover is?

Voor dat laatste bestaan Losse dagen: tegen een vast dagtarief, precies bedoeld voor het moment waarop een eerder gebouwd hulpmiddel bijstelling nodig heeft. Geen supportcontract met vaste reactietijden, geen abonnement — gewoon een dag werk wanneer het nodig is, net als de dag waarop het oorspronkelijk gebouwd werd.

Waarom dit vooraf gezegd wordt

De meeste verkooppraat rond AI-tools doet alsof “klaar” ook “voorgoed” betekent. Dat is niet eerlijk, en het is ook niet nodig om iets te verkopen dat wél waarde heeft. Een hulpmiddel dat vandaag een uur per dag bespaart, blijft die waarde leveren zolang iemand weet dat het bestaat en zolang het luid genoeg is wanneer het misgaat. Dat is een haalbare, eerlijke belofte — heel anders dan doen alsof er nooit meer naar omgekeken moet worden.

Meer over de bredere verwachtingen rond een traject leest u in wat mag u van een AI-traject verwachten — en wat niet. Wat er vooraf al nagekeken kan worden, staat in is onze data klaar voor AI?. Wilt u weten hoe dat er in de praktijk bij u uitziet, dan is een gratis kennismaking de eenvoudigste manier om dat te bekijken.