Waarom de meeste AI-automatiseringen in productie stukgaan

De meeste AI-automatiseringen doen het prima in de demo en gaan een paar weken na livegang stilletjes kapot. Er staat geen exception in de log en er gaat geen alert af; de workflow blijft draaien en er komt gewoon output uit. Het valt daardoor een tijd niemand op.

Tot iemand over een dubbele factuur valt, een lead die als "hot" gekwalificeerd stond een oude koude aanvraag blijkt, of de dagelijkse samenvattingsmail ineens een databron mist. Dan blijkt de automatisering al weken verkeerde output te geven.

Ik heb er genoeg opgeruimd om het patroon te herkennen. Vijf oorzaken komen telkens terug.

1. De prompt staat nergens in versiebeheer

Dit kom ik het vaakst tegen. De workflow is gebouwd in een no-code tool of een Python-notebook, en de prompt staat daar ergens als losse string. Sinds de livegang is hij tientallen keren aangepast. Niemand weet welke versie er in productie staat, of wat er anders was aan de versie die twee weken geleden nog goed werkte.

De oplossing is niet spannend: behandel prompts als code. Zet ze in je repo, versioneer ze en tag ze met de modelversie waar ze tegen getest zijn. Test bij elke wijziging de output tegen een kleine, echte dataset. Wie dit goed doet heeft een prompts-directory die eruitziet als een kleine set unit tests.

2. Het model is veranderd, jouw code niet

OpenAI zet een nieuwe modelversie live, Anthropic faseert een oude uit, en ook binnen dezelfde versie wordt bijgesteld. Je code en de API blijven gelijk, maar de output verschuift.

Hangt je automatisering af van JSON in een vaste vorm, een bepaald soort samenvatting of een vaste classificatie-indeling, dan heb je monitoring nodig op de output, niet alleen op de status van de API-call. Een kleine testset die dagelijks tegen dezelfde bevroren inputs draait en de verschillen vergelijkt, vangt dit op voordat je klanten het merken. Het is weinig code, maar de meeste teams komen er niet aan toe.

3. Er zit geen mens in de loop waar dat wel moet

In de demo zat geen menselijke tussenstap, en zo is het ook live gegaan. Nu neemt een LLM beslissingen die af en toe geld, klantvertrouwen of juridische risico's raken.

Voor twijfelgevallen, cases met confidence onder een drempel en alles wat facturatie of contracten raakt, hoort er een menselijke review-stap in te zitten. Juist daardoor kun je de rest automatisch laten lopen.

Waar die stap precies hoort staat in een apart stuk. De korte versie: omkeerbare beslissingen met veel volume kun je automatiseren, bij onomkeerbare beslissingen hoort een mens, en daartussenin laat je de confidence score beslissen.

4. Fouten zijn onzichtbaar voor je monitoring

De API-call gaf een 200 terug, de JSON parste, de workflow liep door. Voor je monitoring was er niets aan de hand. Maar het model gaf een lege string terug in het veld voor de klantnaam, hallucineerde een SKU die niet bestaat, of zette een retouraanvraag weg als verkoopvraag.

Observability voor AI-workflows is anders dan voor deterministische systemen: je moet de inhoud van de output monitoren, niet alleen of de call slaagde. Denk aan anomaly detection op de verdeling van de output, een kleine steekproef die dagelijks door een mens wordt nagelopen, en een alert zodra het aandeel lege velden of laag-confidence classificaties boven een baseline uitkomt. Dit is geen exotische techniek, het wordt alleen zelden gebouwd.

5. Er zit geen echte backend onder

De workflow is gebouwd in Make, n8n of Zapier, als een dun laagje glue tussen de API's. Dat werkt in development en meestal ook in productie, maar er is geen queue, geen retry-semantiek, geen dead-letter pattern, geen idempotency en geen transactionele grens.

Zodra een gekoppeld systeem zijn timing verandert, en dat gebeurt vroeg of laat altijd, verwerkt de workflow events dubbel of laat hij ze stilletjes vallen. De "retry on failure" van het platform is niet hetzelfde als een queue met at-least-once-semantiek.

Voor veel workflows is zo'n platform prima, ook op de lange termijn. Maar workflows die facturatie, identiteit, fulfilment of iets gereguleerds raken, horen op een backend met echte queue-infrastructuur. Laravel met Horizon is één optie, er zijn er meer. "No-code is sneller" gaat niet meer op zodra je regelmatig stilletjes verdwenen events zit te debuggen.

Wat wel blijft draaien

De automatiseringen die ik heb gebouwd en die jaren bleven draaien, hebben een paar dingen gemeen:

• Prompts in versiebeheer, getest voor elke deploy.
• Monitoring op de output, niet alleen op de API-call.
• Een menselijke review-stap voor elke onomkeerbare beslissing, gestuurd op confidence.
• Echte queue-infrastructuur, idempotency, afhandeling van vastgelopen berichten.
• AI alleen in de stappen waar het echt iets oplevert, deterministische code voor de rest.

Draai je AI-workflows en kun je niet zeggen welke van deze vijf gedekt zijn, dan is dat de eerstvolgende klus.