Waarom de meeste AI-automatiseringsprojecten in productie breken

De meeste AI-automatiseringsprojecten halen de demo, gaan live, en breken drie tot zes weken later stilletjes. Niet luid - er is geen exception in de log, geen Slack-alert om 3 uur 's nachts. De workflow blijft draaien. De outputs blijven stromen. Niemand merkt het een tijdje.

Dan vangt iemand een dubbele factuur. Of een lead die als "hot" gekwalificeerd was, blijkt een koude inquiry uit 2023 te zijn. Of de dagelijkse samenvattingsmail stopt subtiel met het bevatten van één van de databronnen. En het team leert, pijnlijk, dat de "automatisering" weken stilletjes aan het degraderen is geweest.

Ik heb er genoeg opgeruimd om het patroon te herkennen. Vijf failure modes duiken op in ongeveer elke andere opdracht.

1. De prompt is unversioned

Dit is de meest voorkomende. Het team bouwde de workflow in een no-code tool of een Python-notebook. De prompt is een multiline-string ergens. Hij is veertien keer aangepast sinds launch. Niemand weet welke versie nu in productie staat. Niemand weet wat er anders was aan de versie die twee weken geleden werkte.

De fix is onspectaculair: behandel prompts als code. Zet ze in je repo. Versie ze. Tag ze met de model-versie waar ze tegen getest zijn. Test outputs tegen een kleine maar echte dataset bij elke wijziging. De bedrijven die dit goed doen hebben een prompts-directory die er ruwweg uitziet als een kleine set unit tests.

2. Het model veranderde onder je voeten

OpenAI ship een nieuwe modelversie. Anthropic deprecate een oude. Zelfs binnen hetzelfde nominale model worden weights getuned. De API van de provider veranderde niet. Jouw code veranderde niet. De output van de workflow dreef toch af.

Als je automatisering ervan afhangt dat het model JSON in een specifieke vorm retourneert, of een specifiek soort samenvatting, of een specifieke classificatie-taxonomie - heb je monitoring nodig op de output, niet alleen op de API-call-status. Een korte eval-suite die dagelijks tegen een bevroren set inputs draait en output-deltas vergelijkt vangt dit voor je klanten dat doen. Het is ongeveer tien regels code. De meeste teams schrijven het niet.

3. Er is geen mens in de loop waar dat zou moeten

De demo liet het end-to-end zien zonder menselijke interventie. Het team werd enthousiast en ship het zonder. Nu maakt een LLM beslissingen die af en toe geld, klantperceptie of juridische blootstelling raken.

Voor een klasse beslissingen - kwalificatie ambigu, confidence onder een drempel, alles wat billing of contracten raakt - is een menselijke review-stap geen stap terug. Het is het verschil tussen een workflow die je je team kunt verdedigen en een die je niet kunt verdedigen.

Ik schrijf meer over waar precies de menselijke stap hoort in een apart stuk. De korte versie: elke beslissing die reversibel en hoogvolume is, automatiseer vrij. Alles onomkeerbaar of laagvolume, houd een mens in de loop. Alles ertussenin, route op confidence score.

4. Failure modes zijn onzichtbaar

De API-call retourneerde 200. De JSON parsede. De workflow ging door. Niets was mis vanuit het perspectief van je monitoring.

Maar het model retourneerde een lege string voor een veld dat de klantnaam moest bevatten. Of het hallucineerde een SKU die niet bestaat. Of het categoriseerde een retour-aanvraag als een verkoop-inquiry.

Observability voor AI-workflows is fundamenteel anders dan observability voor deterministische systemen. Je moet de inhoud van de output instrumenteren, niet alleen het succes van de call. Anomaly detection op output-distributie. Sampling van 1% van outputs voor menselijke review. Alerting wanneer het percentage lege velden, laag-confidence classificaties of specifieke failure-tokens een baseline overschrijdt.

Dit is niet exotisch. Het wordt ook zelden geshipped.

5. De workflow draait op platform-glue zonder echte backend

Het team bouwde het in Make, n8n of Zapier, met een dunne laag glue tussen APIs. Het werkte prachtig in development. Het werkt meestal in productie. Maar er is geen queue, geen retry-semantiek, geen dead-letter pattern, geen idempotency, geen transactionele boundary.

Wanneer een integratie upstream timing wijzigt - en ze wijzigen altijd timing - verwerkt de workflow ofwel stilletjes dubbel ofwel dropt stilletjes events. De "retry on failure" van het platform is niet hetzelfde als een queue met fatsoenlijke at-least-once-semantiek.

Sommige workflows kunnen voor altijd op platform-glue leven. Sommige absoluut niet. De ones die billing, identiteit, fulfillment of iets gereguleerds raken horen op een echte backend met echte queue-infrastructuur. Laravel + Horizon is één optie. Er zijn andere. Het punt is dat "no-code is sneller" stopt waar te zijn de derde keer dat je een stilletjes gedropt event moet debuggen.

Het patroon dat overleeft

De automatiseringen die ik gebouwd heb die vijf jaar draaiden hadden een paar onspectaculaire dingen gemeen:

• Prompts versioned in de repo, getest voor deploy.
• Output-monitoring, niet alleen API-monitoring.
• Menselijke review-stap voor elke onomkeerbare beslissing, gated op confidence.
• Echte queue-infrastructuur, idempotency, dead-letter handling.
• Gerichte inzet van AI - voor de stappen waar het zich daadwerkelijk verdiende - en plain deterministische code voor al het andere.

Niets daarvan is opwindend. Niets ervan verschijnt op een launch-aankondiging. Alles ervan is het verschil tussen een workflow die een kwartaal in productie overleeft en een die stilletjes degradeert.

Als je AI-workflows ship en je niet kunt vertellen welke van die vijf je team gedekt heeft, zijn de workflows niet af. Ze staan aan het begin van het deel dat niemand wil doen.