Een AI pilot naar productie brengen lukt als vijf dingen geregeld zijn: een trigger die zonder mens start, een route voor fouten, een eigenaar met naam, een meetpunt, en een plek om te wijzigen zonder het draaiende systeem te raken. Ontbreekt er één, dan is het een demo die toevallig elke dag draait.
Dit is geschreven voor de operationeel verantwoordelijke in een bedrijf van 5 tot 50 mensen met een proof of concept die werkt. Een proof of concept is een proefopstelling: gebouwd om te laten zien dat iets kán, niet om er werk van af te laten hangen.
Waarom komen AI-initiatieven niet verder dan een pilot?
Omdat een pilot wordt beoordeeld op of hij werkt, en productie op of hij blijft werken. Dat zijn andere vragen. In een pilot start iemand de boel handmatig, kijkt mee, en herstelt zelf wat misgaat. Die persoon is het foutafhandelingssysteem, en die rol staat nergens op papier.
Daar komt bij dat de pilot bijna altijd op de makkelijkste gevallen is getest. De uitzonderingen, de lege velden, de klant met twee adressen: die komen pas als het systeem elke dag draait. De oorzaken achter mislukte trajecten staan uitgewerkt in waarom mkb-bedrijven vaker falen met AI-implementaties. Dit artikel gaat over de overdracht zelf.
Wanneer is een pilot klaar voor productie?
Als deze zeven punten af zijn. De mechanismen komen uit de documentatie van n8n, het platform waarop WeAdapt het meeste bouwt; Make en Zapier lossen dezelfde punten op hun eigen manier op.
- Een trigger die zonder mens start. Elke productie-workflow heeft minstens één trigger-node nodig, de node die bepaalt wanneer de workflow draait [S-030]. Zolang iemand op knop moet drukken, is het geen productie.
- Een route voor fouten. Wijs in de workflow-instellingen een workflow aan die start als deze workflow faalt [S-037]. Die fout-workflow krijgt de details van de mislukte workflow en de fouten [S-031] en legt ze neer waar iemand kijkt.
- Bewaarde uitvoeringen. Bepaal of mislukte en geslaagde productie-uitvoeringen bewaard worden [S-037]. Zonder bewaarde uitvoeringen kun je een storing de volgende ochtend niet reconstrueren.
- Een grens aan de looptijd. Stel in na hoeveel tijd een uitvoering wordt afgebroken [S-037]. Een workflow die blijft hangen, is vervelender dan een workflow die faalt, omdat hij geen melding geeft.
- Een eigenaar en een goedkeuring. Leg vast wie mag wijzigen. Werkt er meer dan één persoon aan, laat dan een specifieke versie goedkeuren vóór publicatie, door de toegewezen reviewer of een admin [S-034].
- Een plek om te wijzigen. Een omgeving bestaat uit een instance plus een Git-branch, en een gangbaar patroon is een aparte omgeving voor ontwikkeling en voor productie [S-036]. Let op: credentials en variabelewaarden gaan niet mee met Git, die zet je per omgeving apart klaar [S-036].
- Een meetpunt. Spreek af welk getal je volgt: het aantal productie-uitvoeringen en het faalpercentage daarvan [S-035]. Zonder meetpunt merkt niemand dat een workflow is stilgevallen.
De checklist is bewust kort. Wie er meer dan een dagdeel aan besteedt, is waarschijnlijk iets aan het bouwen dat de pilot nog niet nodig had.
Wat gebeurt er als een workflow faalt?
Zonder fout-workflow: niets zichtbaars. De uitvoering stopt, de dag gaat door, en het gat komt later boven water als ontbrekende gegevens die iemand met de hand bijwerkt. Dat is de dure variant, omdat de kosten verderop in het proces vallen.
Met fout-workflow ligt de route vast. De Error Trigger-node haalt de details van de mislukte workflow en de fouten op en draait de fout-workflow [S-031]. Wat daarin gebeurt, kies je zelf: een bericht in het kanaal waar het team toch al kijkt, een regel in een logboek, een taak in het systeem waar het werk in staat. Eén fout-workflow voor alle workflows is genoeg om mee te beginnen.
Waar wijzig je een systeem dat al draait?
Niet in het draaiende systeem, zodra er iets van afhangt. Een omgeving is een instance plus een branch, en de scheiding tussen ontwikkeling en productie is precies bedoeld voor het moment waarop je wilt wijzigen zonder het werk stil te leggen [S-036].
Voor een mkb met een handvol workflows hoeft dat niet zwaar. Twee dingen volstaan meestal: een kopie waarin je test, en de afspraak dat een wijziging pas naar productie gaat als iemand anders ernaar heeft gekeken [S-034]. Wat je wel expliciet moet regelen, zijn de credentials: die synchroniseren niet mee en moeten per omgeving worden ingesteld [S-036]. Dat is de fout die de eerste keer altijd gemaakt wordt.
Wie is de eigenaar en wat meet je?
Eén persoon met naam, en twee getallen. De eigenaar is degene die de meldingen krijgt en mag beslissen of een wijziging doorgaat. Zonder die naam blijft het beheer bij de laatste bouwer liggen, en dat is zelden een bewuste keuze.
De twee getallen zijn het aantal productie-uitvoeringen en het faalpercentage daarvan. Beide staan in het overzicht van n8n, naast de gemiddelde looptijd en de bespaarde tijd zoals per workflow ingesteld [S-035]. Kijk er maandelijks naar. Een workflow die opeens de helft minder draait, is meestal stilgevallen op een bron die van veldnaam is veranderd.
Wat een cijfer niet vertelt, is of de uitkomst nog klopt. Dat hoor je van de mensen die ermee werken. Een rapportage die elke week handmatig wordt nagewerkt, telt als geslaagde uitvoering en is toch niet af; hoe dat er in de praktijk uitziet, staat in rapportages automatiseren.
Hoe lang duurt de overgang?
Korter dan de meeste trajecten suggereren, mits de scope klein blijft. WeAdapt werkt van discovery call tot live in vier weken, inclusief procesmapping, bouwen, review en training. Dat is de doorlooptijd van een eerste werkende workflow, niet van een programma dat de hele organisatie raakt.
De overgang van pilot naar productie zelf is meestal een kwestie van dagen, niet weken, zodra de zeven punten helder zijn. Het meeste tijdverlies zit niet in de techniek maar in de beslissing wie eigenaar wordt.
Veelgestelde vragen
Wat is het verschil tussen een pilot en productie? Een pilot bewijst dat iets kan, met een mens die meekijkt. Productie betekent dat het werk ervan afhangt en er niemand standaard meekijkt. Daarom vraagt productie een trigger, een foutroute, een eigenaar en een meetpunt, en een pilot niet.
Moet elke automatisering naar productie? Nee. Een pilot die laat zien dat de winst tegenvalt, heeft zijn werk gedaan. Doorzetten omdat er al tijd in zit, is de duurste reden om iets in productie te nemen.
Wat als de pilot in een andere tool is gebouwd? Dan is de overgang een herbouw, geen verhuizing. Beoordeel of de pilot alleen de logica moest bewijzen. Is dat zo, dan is opnieuw opbouwen in het platform waar het beheer straks ligt vaak sneller dan de proefopstelling productiewaardig maken.
Hoeveel mensen heb je nodig voor beheer? Eén eigenaar en één achtervang. Niet omdat het veel werk is, maar omdat één persoon op vakantie gaat. De hoeveelheid werk hangt af van het aantal koppelingen, niet van het aantal workflows.
De weg van proefopstelling naar productie loopt bij WeAdapt via consultancy voor de volgorde, en daarna workflow automatisering voor wat er echt komt te draaien.
Wil je weten welke van je proefopstellingen klaar is voor productie? Plan een gesprek. Wat er dan feitelijk komt te draaien, staat in de cases.