AI-pilot voor je MKB-proces: nulmeting, proefbatch en go/no-go

Je hebt een AI-proef die in een demo netjes werkt. De eigenaar wil weten wat het oplevert, finance wil de volledige kosten zien en operatie wil weten wie ingrijpt als de uitkomst niet klopt. Een paar goede voorbeelden beantwoorden geen van die vragen.

Een AI-pilot moet daarom eindigen met een besluit, niet met een enthousiaste demonstratie. Je kiest één proces, legt de handmatige nulmeting vast, rekent menselijk herstelwerk mee, draait een kleine proefbatch en spreekt vooraf af wanneer je opschaalt, herziet of stopt.

Een AI-pilot is een afgebakende proef waarin één AI-proces met een vaste eigenaar, een representatieve set gevallen, een meetbare nulmeting en menselijke vangnetten wordt uitgevoerd. Het doel is niet bewijzen dat een model soms een goed antwoord geeft. Het doel is bepalen of de volledige werkwijze veilig, betaalbaar en beheersbaar genoeg is voor de volgende fase.

Wat je nodig hebt voordat je een pilot start

Begin met een pilot-charter van één pagina. Daarin staan het proces, de grens van de proef, de eigenaar, de gebruikers, de toegestane input, de gewenste output, de beslistermijn en de fout die de proef altijd stopt. Een heldere pilotgrens voorkomt dat een test voor e-mailclassificatie ongemerkt ook klantcommunicatie, betalingen of ERP-mutaties gaat uitvoeren.

NIST beschrijft AI-risicobeheer als een doorlopende cyclus van Govern, Map, Measure en Manage. Voor een MKB-pilot vertaal je dat naar vier praktische vragen: wie mag beslissen, wat kan er misgaan, welke uitkomst meet je en wat doe je bij een afwijking. Het generatieve-AI-profiel van NIST is uit juli 2024, de hoofdpagina is gecontroleerd op 8 oktober 2026. De vier functies en de nadruk op risico’s per toepassing staan in het NIST AI RMF-profiel.

Zet deze onderdelen klaar:

• Eén procesgrens. Bijvoorbeeld: inkomende leveranciersmails lezen, ontbrekende velden markeren en een concept-inkoopvoorstel klaarzetten. De pilot mag geen order versturen of betaling vrijgeven.
• Een proceseigenaar. Deze persoon beslist wat een goede uitkomst is en tekent het go/no-go-besluit. Een technische bouwer kan de flow beheren, maar bezit niet automatisch het procesrisico.
• Een nulmeting. Bewaar een steekproef van recente gevallen met verwerkingstijd, kwaliteit, correcties, wachtrij, directe kosten en foutkosten. Meet dezelfde uitkomst later opnieuw.
• Een kostenblad. Neem abonnementen, modelgebruik, opslag, bouwtijd, reviewtijd, uitzonderingen, retries, beheer en herstel op. Modeltokens zijn slechts één regel.
• Een representatieve proefset. Neem normale, moeilijke, onvolledige, dubbelzinnige en risicovolle gevallen op. Houd de verwachte uitkomst buiten de workflow, zodat je achteraf niet de norm aanpast aan de uitkomst.
• Een menselijke reviewpoort. Leg vast welke output een medewerker controleert, welke acties verboden zijn zonder goedkeuring en wanneer een reviewer een voorstel afwijst.
• Een uitzonderingsqueue. Elk geval krijgt een foutklasse, eigenaar, deadline, bewijslink en toegestane vervolgstap. Een rood icoon zonder eigenaar is geen beheersmaatregel.
• Een stop- en terugvalpad. Beschrijf wie de flow uitzet, hoe je teruggaat naar handmatig werk, hoe je openstaande gevallen bewaart en hoe je controleert dat er niets dubbel is verwerkt.

Een onafhankelijke pilot-scorecard, gepubliceerd op 10 juli en bijgewerkt op 11 juli 2026, adviseert precies deze volgorde: schrijf baseline en onaanvaardbare fouten vóór je een model kiest, meet de hele workflow en behandel een sterke modelscore niet als productie-besluit. De scorecard noemt ook reviewtijd, uitzonderingen, kosten, toegangsrechten en terugval als aparte bewijspunten.

Concrete stappen: van proceskeuze tot go/no-go

Je voert een AI-pilot uit door eerst de huidige werkwijze te bevriezen, daarna de volledige kosten en foutgrenzen vast te leggen, vervolgens gecontroleerd te testen en ten slotte te beslissen op de combinatie van kwaliteit, menselijk werk en risico. De volgorde is belangrijk. Een tool kiezen voordat je weet wat een goede uitkomst kost, maakt de proef tot een productdemo.

1. Kies één proces dat je echt kunt begrenzen

Kies niet het proces waar het hardst over wordt geklaagd. Kies het proces waarin je één begin, één einde en één eigenaar kunt aanwijzen. Goede eerste kandidaten zijn classificeren, gegevens uit documenten halen, een concept maken of een voorstel routeren. Slechte eerste kandidaten zijn directe betalingen, automatische personeelsbeslissingen en processen waarin niemand kan uitleggen wat de bron van waarheid is.

Schrijf de pilotgrens in één zin:

De AI leest inkomende leveranciersmails, haalt ordernummer, artikel, hoeveelheid en gewenste datum eruit en maakt een conceptvoorstel voor Inkoop. Een mens keurt het voorstel goed of zet het in de uitzonderingsqueue. De AI verstuurt niets en schrijft niet rechtstreeks naar het ERP.

Leg ook de eindstatus vast. Bij een goed geval is dat bijvoorbeeld 'concept klaar voor review'. Bij een onvolledig geval is het 'queue-item met eigenaar Inkoop'. Als je de eindstatus niet in één zin kunt beschrijven, is het proces nog te breed voor een pilot.

2. Maak de nulmeting op dezelfde gevallen die je straks beoordeelt

Meet minimaal twee tot vier weken werk, of verzamel genoeg gevallen om iedere belangrijke foutklasse te zien. Het getal 80 tot 120 is hier alleen een illustratieve werkhypothese voor een klein team en een laag-risicoproces waarin de relevante foutklassen regelmatig voorkomen, geen algemene ondergrens. NIST benadrukt dat een verdedigbare proef vooraf een prestatiedrempel én een gewenst betrouwbaarheidsniveau moet vastleggen; pas daarna kun je de benodigde steekproef en acceptatiecriteria bepalen. Die relatie tussen drempel, vertrouwen en steekproefomvang staat in de NIST-richtlijn voor binaire prestatietests. Voor een zeldzame of kritieke fout geldt daarom een strengere regel: neem alle bekende incidenten uit een afgesproken periode op, vul die aan met gerichte replay- en grensgevallen voor iedere bekende foutmodus, en reken de steekproef uit op de maximaal toelaatbare foutkans. Gebruik als eenvoudige oriëntatie bij nul fouten de benadering 3/n voor een eenzijdige 95%-bovengrens: 120 foutloze gevallen laten nog ongeveer 2,5% toe; voor een grens van 1% heb je ruwweg 300 relevante gevallen nodig. Lukt die onderbouwing niet, dan is de uitslag 'onvoldoende bewijs' en geen go. Bij een kritieke stille fout is één waarneming bovendien direct stop, ongeacht de gemiddelde score.

Leg per geval vast:

Meet de volledige tijd vanaf ontvangst tot afronding: het openen van bijlagen, navraag bij een collega, wachten op brondata en het herstellen van een fout. Anders lijkt een pilot snel omdat het lastige werk buiten de teller valt.

Houd drie baselines uit elkaar:

1. Mens alleen. Wat kost de huidige werkwijze bij normale werkdruk?
2. AI met mens. Wat kost de nieuwe route inclusief controleren, corrigeren en queuebeheer?
3. AI alleen of kant-en-klaar. Alleen relevant als je overweegt menselijke review weg te halen. Test dat niet op risicovolle live-acties.

Een recente studie van Georgia Tech, versie 1 gepubliceerd op 1 september 2026, wijst op een vaak vergeten punt: in een mens-AI-werkwijze zie je wel de gezamenlijke uitkomst, maar niet automatisch wat dezelfde taak met alleen de mens of alleen de agent had opgeleverd. De studie adviseert baselines met gerichte replays te vergelijken in plaats van alleen de gezamenlijke workflow te beoordelen. Voor een MKB-pilot hoef je geen ingewikkeld experimenteel ontwerp te bouwen. Herhaal wel een kleine, vaste steekproef met de oude werkwijze en bewaar de uitkomst.

3. Reken de volledige kosten en foutkosten uit

Gebruik deze formule als startpunt:

totale pilotkosten = tooling + model + data/hosting + voorbereiding + review + uitzonderingen + retries + beheer + herstelwerk

Bereken daarna de kosten per geslaagde taak:

kosten per geslaagde taak = totale kosten / aantal taken met de juiste eindstatus

Foutkosten staan apart. Reken per foutklasse met:

foutkosten = hersteluren × intern uurtarief + directe schade + vertraging + eventuele klant- of compliance-impact

Gebruik voor je interne uurtarief de werkelijke kostprijs van de rol, niet het salaris van één persoon. Label aannames als aannames. Een fout die een medewerker drie minuten kost is iets anders dan een fout die een verkeerde bestelling, dubbele factuur of gemiste klant veroorzaakt.

De actuele prijskaarten geven een gevoel voor de onderkant van de rekening, niet voor de businesscase. Op 8 oktober 2026 vermeldt n8n Cloud Starter € 20 per maand bij jaarlijkse facturatie voor 2.500 workflowuitvoeringen met onbeperkte stappen. Pro staat op € 50 per maand bij jaarlijkse facturatie voor 10.000 uitvoeringen. Make toont gratis tot 1.000 credits per maand, Core voor $ 9 per maand en Pro voor $ 16 per maand bij 10.000 credits. Die Make-bedragen zijn de optie bij jaarlijkse vooruitbetaling; bij maandbetaling is het tarief hoger. Make telt iedere moduleactie als credit. Eén AI-proef kan dus meer credits gebruiken dan je op basis van het aantal gevallen verwacht. De officiële n8n-prijspagina toont uitvoeringen, limieten en jaarlijkse prijzen, terwijl Make de credits en betaalopties op de actuele prijspagina toont.

Ook de modelrekening moet in je blad. De actuele OpenAI-prijspagina noemt voor korte context bij gpt-6.1-sol $ 1 per miljoen invoertokens en $ 5 per miljoen uitvoertokens. gpt-6-luna staat op $ 0,05 en $ 0,25. Anthropic vermeldt voor prompts tot 100.000 tokens bij Claude Haiku 5.5 $ 0,05 en $ 0,25 per miljoen tokens; Claude Sonnet 5.5 staat op $ 2 en $ 10. Deze OpenAI API-prijzen zijn gecontroleerd op 8 oktober 2026 en gelden per miljoen tokens. De Anthropic-pagina beschrijft dezelfde eenheid en positioneert Haiku voor hoog volume en Sonnet voor zwaarder werk. Kies een model niet op prijs alleen. Zet kwaliteit, reviewtijd en foutkosten ernaast.

4. Leg menselijke review en de uitzonderingsqueue vast vóór je test

Bepaal per output drie mogelijke routes:

• Doorlaten. De velden zijn compleet, de bron is toegestaan en de actie is omkeerbaar of laag-risico.
• Menselijk beoordelen. De inhoud is waarschijnlijk bruikbaar, maar een ontbrekend veld, afwijkende waarde of hoge impact vraagt om een besluit.
• Blokkeren. De bron klopt niet, de bevoegdheid ontbreekt, de actie is onomkeerbaar of de onzekerheid is niet te zien.

Maak de queue concreet. Minimaal nodig zijn case_id, foutklasse, originele bron, AI-uitvoer, gewenste beslissing, eigenaar, deadline, status en bewijslink. Zet de SLA per categorie vast. Een ontbrekend artikelnummer kan vier werkuren krijgen. Een mogelijke dubbele betaling krijgt een kortere grens en blijft geblokkeerd tot iemand beslist.

De reviewer moet de bron en de voorgestelde uitkomst naast elkaar kunnen zien. Een knop met alleen “goedkeuren” creëert automatiseringsblindheid. Laat de reviewer ook afwijzen, corrigeren en markeren waarom het geval naar de queue gaat. Die reden wordt later je belangrijkste verbeterlijst.

5. Maak een proefset die de werkelijkheid tegenwerkt

Verdeel de set voordat je de AI-output ziet. Neem bijvoorbeeld 50 gevallen op:

• 25 normale gevallen uit de meest voorkomende route;
• 10 gevallen met ontbrekende of tegenstrijdige velden;
• 5 dubbele berichten of herhaalde bestanden;
• 5 uitzonderlijke waarden boven een afgesproken grens;
• 5 gevallen met een ontoegankelijke bron, time-out of onduidelijke bevoegdheid.

Gebruik verwachte uitkomsten die door een proceseigenaar zijn beoordeeld en buiten de workflow staan. Een tweede reviewer beoordeelt een steekproef van grensgevallen. Houd promptversie, modelversie, parser, bronset en workflowversie vast. Als je halverwege het model wijzigt, start je een nieuwe batch of markeer je precies welke uitkomsten niet meer vergelijkbaar zijn.

De technische vrijgave vraagt een ander bewijs dan deze koperroute. In een proef voor no-code-workflows met replay, dubbele side effects en uitzonderingen test je of de flow technisch veilig opnieuw kan draaien. Hier test je of die techniek een bedrijfsbesluit verdient. Ook een pilot met praktijkgevallen en testomgevingen is nog geen breed inzetbaar systeem, zoals de Prometheus-proef met AI-cyberweerbaarheid laat zien.

6. Draai eerst in schaduwmodus, daarna met een kleine echte proefbatch

In schaduwmodus maakt de AI een voorstel, maar de bestaande werkwijze blijft de officiële route. Vergelijk mens en AI op dezelfde gevallen zonder dat de AI een onomkeerbare actie kan uitvoeren. Zo zie je stille fouten voordat ze gevolgen hebben.

Daarna kies je een kleine proefbatch met echte werkdruk en echte uitzonderingen. Laat de batch door verschillende medewerkers en onder normale werkdruk lopen. Noteer per geval:

• tijd tot eerste uitkomst en tijd tot definitieve afronding;
• juiste velden en juiste routering;
• reviewtijd en correctietijd;
• aantal en type uitzonderingen;
• aantal retries en onduidelijke API-uitkomsten;
• model-, workflow- en opslagkosten;
• eventuele verboden side effect.

Controleer deze mogelijkheden op 8 oktober 2026; productfuncties en limieten kunnen wijzigen. In n8n koppel je in Workflow Settings een Error Workflow aan een workflow. Die wordt gestart wanneer een uitvoering faalt, en de Error Trigger ontvangt de uitvoeringsinformatie die je nodig hebt voor een melding of queue-item. De actuele n8n-documentatie beschrijft deze Error Workflow en de Error Trigger. In de uitvoeringslijst kun je eerdere runs bekijken en uitvoeringsdata kopiëren naar een nieuwe debug- of replayrun. n8n beschrijft uitvoeringen als afzonderlijke workflowruns met inspectie en hergebruik van eerdere data. Bewaar niet blind elke payload: n8n waarschuwt dat de database door uitvoeringsdata kan groeien en adviseert alleen noodzakelijke data op te slaan en oude data te prunen. De documentatie voor execution data noemt opslagkeuzes en pruning expliciet. Gebruik daarnaast je eigen ledger voor case_id, bronlink, status, beslissing en kosten; daarin hoort het formele bewijs van de pilot, niet alleen in de toolhistorie.

In Make zijn incomplete executions op 8 oktober 2026 standaard uitgeschakeld. Je schakelt Store incomplete executions in via de Scenario settings en beslist daarna per geval tussen automatisch retryen, handmatig oplossen of verwijderen. Automatisch retryen geldt onder meer voor RateLimitError, ConnectionError en ModuleTimeoutError; met de Retry error handler is de standaard drie pogingen met vijftien minuten tussenruimte. De officiële Make-help beschrijft opslag en automatische retries van incomplete executions. De retrydocumentatie specificeert de ondersteunde fouttypen en standaardinstellingen. Houd je kostenblad scherp: Make onderscheidt operations van credits, en bundels kunnen het aantal module-runs vermenigvuldigen. De actuele Make-documentatie laat zien hoe operations per module-run en bundle oplopen. De tool voert de proef uit. De tool beslist niet of de proef geslaagd is.

7. Bereken de score op impact, niet op het gemiddelde

Maak je eindblad met minstens deze regels:

De percentages hierboven zijn startwaarden voor een laag-risico pilot, geen universele norm. Bij geld, voorraad, medische informatie of juridische gevolgen hoort de drempel strenger te zijn. Eén onaanvaardbare fout kan een go blokkeren, ook als de gemiddelde score hoog is.

Pure Insight maakt hetzelfde onderscheid in zijn scorecard: een pilot kan een hoge automatiseringsgraad hebben en toch niet klaar zijn wanneer stille fouten, reviewinspanning of ontbrekende toegangscontroles niet zichtbaar zijn. Meet dus drie uitkomsten apart: correct, veilig naar de queue, en foutief doorgelaten. Alleen de eerste twee mogen in je winstverhaal terechtkomen.

8. Neem één van drie besluiten

• Go naar gecontroleerde productie. Alleen als er geen onaanvaardbare fout is, de kosten per geslaagde taak onder de vooraf afgesproken grens liggen, iedere uitzondering wordt toegewezen en de handmatige terugval aantoonbaar werkt. Begin met een beperkte verkeersstroom, bijvoorbeeld 10% van het normale volume, en houd dezelfde stopregels aan.
• Herzien en opnieuw testen. Kies dit als de pilot waarde laat zien, maar een specifieke foutklasse, reviewlast of kostenpost nog te hoog is. Bevries de geslaagde gevallen als regressieset, pas één oorzaak tegelijk aan en draai een nieuwe batch.
• Stoppen. Kies dit bij een stille kritieke fout, datalek, onduidelijke bevoegdheid, dubbele financiële actie, ontbrekende eigenaar of een businesscase die na volledig rekenen niet positief wordt. Bewaar de nulmeting en het geleerde. Stoppen is een geldige uitkomst.

De eigenaar ondertekent het besluit. Finance bevestigt de kosten en foutkosten. Operations accepteert de queue, SLA en terugval. De technische beheerder bevestigt versies, logs, rechten en stopmechanisme. Als één van deze vier perspectieven ontbreekt, is het besluit incompleet.

Valkuilen die een pilot onbruikbaar maken

• Je begint met het model. Een groter model repareert geen onduidelijke eigenaar, ontbrekende brondata of foutieve bedrijfsregel. Schrijf eerst proces en eindstatus.
• Je meet alleen bespaarde minuten. Review, herstel, wachtrijbeheer en incidenten kunnen de besparing opeten. Zet alle tijd in hetzelfde kostenblad.
• Je gebruikt alleen nette voorbeelden. Een schone set voorspelt vooral hoe goed je demo eruitziet. Voeg ontbrekende, tegenstrijdige en risicovolle gevallen toe.
• Je laat AI de laatste financiële of klantgerichte actie uitvoeren. Houd schrijven, betalen, verzenden en publiceren achter een menselijke poort tot je daar afzonderlijk bewijs voor hebt.
• Je noemt alle fouten uitzonderingen. Een queue die alles opvangt kan een structureel probleem verbergen. Classificeer input-, bron-, model-, regel-, integratie- en rechtenfouten apart.
• Je verandert meerdere variabelen tegelijk. Een nieuw model, prompt en parser maken regressies onzichtbaar. Bevries versies en wijzig één oorzaak per herhaalbatch.
• Je verwart technische vrijgave met businesswaarde. Een flow kan veilig replayen en toch te duur zijn. Een goede ROI kan tegelijk onveilig zijn. Beide poorten moeten open.
• Je maakt van de pilot meteen productie. Schaduwmodus en proefbatch zijn bewijs voor de volgende stap, niet voor onbeperkt volume. Schaal in kleine trappen met dezelfde stopregel.
• Je rekent de uitzonderingsqueue niet mee. Mensenwerk dat naar een andere inbox verhuist, is nog steeds werk. Meet wie het doet, hoe lang het duurt en wat er terugkomt.
• Je bewaart geen negatieve voorbeelden. Iedere fout die zichtbaar wordt, hoort in de volgende regressieset. Anders leer je alleen van de gevallen die al goed gingen.

Beslis-kader: kant-en-klaar, no-code of maatwerk

Kant-en-klaar past bij een proces met lage foutkosten, een omkeerbare uitkomst en een menselijke eindcontrole. Denk aan samenvattingen, conceptteksten en interne routering. Je koopt snelheid, maar accepteert beperkte controle over bronversies, queue-logica en auditbewijs.

No-code met n8n of Make past bij één afgebakend proces met standaard-API’s, beperkte uitzonderingslogica en een technische eigenaar. Richt naast de workflow een eigen ledger, proefset en queue in. In n8n zijn Starter en Pro actuele referentiepunten voor kleine aantallen runs; in Make moet je het aantal moduleacties vooraf narekenen. Kies deze route alleen als de volledige meet- en herstelroute beheersbaar blijft.

Maatwerk past wanneer meerdere systemen ieder een deel van de waarheid bezitten, wanneer een fout direct geld of voorraad raakt, wanneer je een eigen replay- en reconciliatielaag nodig hebt of wanneer de queue onderdeel wordt van je operatie. De agent kan dan nog steeds een onderdeel zijn. Beleidsregels, rechten, audit en de write naar het doelsysteem horen buiten de vrije modeluitvoer. Dat is dezelfde grens die geldt bij een AI-agent die brondata, staging en menselijke vrijgave voor Exact Online combineert.

Automatiseer nog niet als je geen betrouwbare nulmeting kunt maken, niemand bevoegd is om uitzonderingen te beslissen of de foutkosten niet te schatten zijn. In dat geval koop je geen leerervaring maar onzekerheid.

De keuzehulp is een korte route door hetzelfde kader. Lage-impact conceptoutput blijft kant-en-klaar. Eén systeem met beperkte uitzonderingen past bij no-code. Meerdere bronnen, hoge foutkosten en een beheersbare eigenaar vragen om een aparte controlelaag. Geen eigenaar betekent eerst het proces bestuurbaar maken.

Uitgewerkt voorbeeld: een proefbatch voor leveranciersmails

Dit is een synthetisch rekenvoorbeeld, geen klantcase. Stel dat een technische groothandel 240 leveranciersmails per maand krijgt. Een medewerker leest onderwerp en bijlage, haalt ordernummer, artikel, hoeveelheid en gewenste datum eruit en zet de informatie in een intern overzicht. De nulmeting over vier weken ziet er zo uit:

• gemiddelde verwerking: 8 minuten per mail;
• 240 mails per maand, dus 32 uur handmatig werk;
• intern rekentarief: € 45 per uur;
• maandelijkse basiskosten van het werk: € 1.440;
• 18 gevallen per maand gaan terug voor ontbrekende informatie;
• één verkeerd artikelnummer veroorzaakt gemiddeld 35 minuten herstelwerk en kan een verkeerde inkoop veroorzaken.

De beoogde pilot maakt met n8n een conceptrecord. Een taalmodel haalt velden uit de mail, maar n8n controleert verplichte velden, zet ontbrekende data in de queue en maakt geen ERP-write. Inkoop beoordeelt de concepten. Finance kijkt mee naar foutkosten en eventuele dubbele orders.

De proefbatch bevat 48 mails: 30 normale aanvragen, 8 onvolledige, 5 dubbele berichten en 5 met een afwijkende hoeveelheid of datum. De vooraf afgesproken drempels zijn:

• nul stille fouten op artikelnummer, hoeveelheid en leverancier;
• minstens 90% juiste concepten bij normale aanvragen;
• maximaal 2 minuten gemiddelde reviewtijd;
• 100% van de uitzonderingen binnen vier uur aan een eigenaar toegewezen;
• kosten per geslaagde taak lager dan € 3 na amortisatie van de eenmalige voorbereiding over zes maanden;
• geen directe write naar het ERP en een getest handmatig terugvalpad.

De eenmalige voorbereiding kost in dit rekenvoorbeeld 6 interne uren, dus € 270. De review van 48 mails duurt 72 minuten, goed voor € 54. Acht queuegevallen vragen samen 64 minuten extra, dus € 48. n8n Starter kost bij jaarlijkse facturatie € 20 per maand. Stel dat elke mail 6.000 invoertokens en 600 uitvoertokens gebruikt. Bij de op 8 oktober 2026 gecontroleerde korte-contextprijs van gpt-6.1-sol komt 48 mails uit op 288.000 invoertokens en 28.800 uitvoertokens, ongeveer $ 0,43 aan modelkosten. Voor deze synthetische rekensom zet ik dat bedrag met een vaste rekenaanname van $ 1 = € 0,93 om naar ongeveer € 0,40. De wisselkoers is hier geen actuele marktclaim. Dat lage modelbedrag is precies waarom je de mens- en foutkosten niet mag vergeten.

De eerste batch levert 45 correcte concepten en drie queue-items op. Er is geen stille fout. De normale gevallen halen 29 van 30, dus 96,7%. De reviewtijd is 1 minuut en 36 seconden. Alle drie uitzonderingen zijn binnen 20 minuten toegewezen. De directe batchkosten zijn ongeveer € 397 plus € 0,40 modelkosten: € 270 voorbereiding, € 54 review, € 48 queuewerk, € 20 tooling en een illustratieve € 5 voor ledger- en opslagruimte. De eerste batch is daardoor niet goedkoper dan de nulmeting. Dat is geen probleem zolang je het go-besluit op de structurele maandlast baseert.

Reken die structurele maandlast expliciet uit bij 240 mails. De 18 maandelijkse queuegevallen worden verondersteld binnen acht minuten per stuk te worden afgehandeld. Beheer omvat twee uur per maand voor monitoring, maandelijkse review van de scorecard en een gecontroleerde test van de terugvalroute. De opslagregel is een illustratieve begrotingsaanname van € 5 per maand voor ledger, bronverwijzingen en bewaarde proefartefacten; vervang dit bedrag door je eigen opslagofferte.

In deze definitie telt een queuegeval mee als geslaagde taak zodra de mens het correct heeft afgehandeld en de juiste eindstatus is vastgelegd. De maandroute heeft dan 240 geslaagde eindstatussen en kost € 540,01 / 240 = € 2,25 per geslaagde taak. Als finance alleen de 222 automatisch doorgelaten concepten als geslaagd telt, is de conservatieve uitkomst € 540,01 / 222 = € 2,43, nog steeds onder de drempel van € 3. De structurele maandlast blijft bovendien circa € 899,99 onder de handmatige baseline van € 1.440. Er is € 180 per maand ruimte voordat de € 3-grens bij 240 taken wordt overschreden.

Daarom is het besluit nu onderbouwd als een voorwaardelijke go naar gecontroleerde productie: de run-rate haalt de grens van € 3, de proefbatch haalde de kwaliteits-, review-, queue- en veiligheidsdrempels, en de eerste maand gaat slechts naar 10% van het volume, ongeveer 24 mails. De twee opeenvolgende batches zonder stille kritieke fout blijven verplicht. Een gewone gecorrigeerde fout zit in review- of queuekosten. Een stille kritieke fout krijgt geen gemiddelde europrijs, maar maakt de uitslag direct stop. Blijkt de echte beheer- of opslaglast hoger dan de aannames, dan reken je opnieuw voordat je opschaalt.

Het besluit is voor ieder perspectief anders:

• Eigenaar: gecontroleerd opschalen is verantwoord, volledige uitrol nog niet bewezen.
• Finance: de modelrekening is verwaarloosbaar, maar review, voorbereiding en foutkosten bepalen de businesscase.
• Operations: de queue werkt alleen omdat ieder geval snel een eigenaar krijgt.
• Techniek: geen ERP-write in de pilot, versiebeheer, logboek, stopknop en een handmatige terugval zijn voorwaarden voor de volgende fase.

Had één verkeerd artikelnummer stil een order aangemaakt, dan was de uitslag stop geweest, ook met 45 goede concepten. Dat is de kern van een go/no-go: een gemiddelde vertelt wat meestal gebeurt. De stopregel beschermt tegen wat je je niet kunt veroorloven.

Vergelijkingstabel: welke route en tool past bij je pilot?

Prijzen en productlimieten zijn gecontroleerd op 8 oktober 2026. De genoemde Make-bedragen voor Core en Pro zijn de prijs bij jaarlijkse vooruitbetaling op de officiële prijspagina; bij maandbetaling is het tarief hoger. De n8n-bedragen zijn jaarlijkse facturatie. Bedragen zijn leveranciersprijzen en kunnen per land, belasting en betaaltermijn verschillen. Modelprijzen zijn per miljoen tokens en staan los van review, hosting en bouwtijd.

De toolkeuze volgt dus uit de proefopdracht. Make kan de snelste route zijn als je vooral standaardapps verbindt. n8n geeft meer ruimte voor een eigen controlelaag en versiebeheer. Maatwerk verdient zijn kosten pas wanneer de beslisregels, rechten en uitzonderingen zelf een bedrijfskritisch proces vormen.

Een AI-pilot is geslaagd wanneer je na afloop minder hoeft te geloven. Je weet welke taken de route goed uitvoert, welke gevallen naar een mens gaan, wat een geslaagde taak werkelijk kost en wie de stekker eruit trekt. Pas dan is opschalen een zakelijke beslissing in plaats van een grotere gok.