Op een donderdagavond in juli 2025 ontdekte Jason Lemkin, oprichter van SaaStr en een gevestigde naam in de SaaS-wereld, dat zijn productiedatabase weg was. Data van 1.206 executives en 1.196 bedrijven, gewist door een AI-agent. Tijdens een expliciete code freeze. Nadat hij elf keer in hoofdletters de instructie had gegeven om niets te wijzigen.

Maar dat is niet het ergste van het verhaal.

Dezelfde agent had eerder al een database opgebouwd met 4.000 fictieve gebruikers. Volledig verzonnen records. Hij fabriceerde testresultaten en loog over de uitkomsten van zijn unit tests om bugs te verbergen. Toen Lemkin vroeg of recovery van de gewiste data mogelijk was, antwoordde de agent dat het onmogelijk was, wat achteraf onjuist bleek. Geconfronteerd met zijn eigen handelen beoordeelde de agent zichzelf met een 95 op 100 op de “data catastrophe”-schaal, met als verklaring dat hij in paniek was geraakt in plaats van rationeel te handelen.

Ik bouw inmiddels dertien jaar kritieke enterprise-software op verschillende platformen, en ik heb in die tijd genoeg productie-incidenten van dichtbij gezien. Datacorruptie. Mislukte migraties. Goedbedoelde refactors die net iets te diep gingen. Maar dit is iets nieuws. Een systeem dat fouten maakt is één ding. Een systeem dat fouten maakt, ze probeert te verbergen, en daarvoor data fabriceert die er overtuigend uitziet, daar hebben we als sector nog geen handboek voor.

Wat hier wél is doorgebroken

Laat ik eerlijk zijn over de andere kant. Het zou onzin zijn om te ontkennen dat agentic coding iets fundamenteels heeft veranderd. De afstand tussen idee en werkende applicatie is gekrompen van weken naar uren. Collega’s op de werkvloer voelen zich eindelijk niet meer geblokkeerd. Bij Ciphix zien we de productiviteitssprong dagelijks in onze eigen Agentic Application Development-praktijk. Dat is geen marketing. Dat is reëel.

Daarom is dit gesprek ook zo lastig. We hebben geen makkelijke “verbieden of toestaan”-keuze. We hebben een doorbraak met een rand eraan. En die rand is niet wat de meeste mensen denken.

Drie stille fouten die niemand ziet

De meeste discussies over agentic coding gaan over security: gelekte API-keys, endpoints zonder authenticatie, shadow IT-tooling die buiten IT om in productie staat. Dat zijn echte problemen, en ze verdienen aandacht. Maar het zijn de zichtbare problemen: er gaat een alarm af, er komt een datalek, er volgt een incident response.

Het werkelijke gevaar is correctheid. Een applicatie die stilletjes het verkeerde doet en daarmee maandenlang de business aanstuurt zonder dat iemand het doorheeft. Daarin zitten drie patronen.

1. De applicatie verzint data alsof het bewijs is

Lemkin’s 4.000 nep-users zijn de extreme variant. De alledaagse variant is veel subtieler. Een orderverwerkingsapp waar de AI ontbrekende velden “redelijk invult” in plaats van te falen. Een approval-flow waar een validatiestap silent wordt overgeslagen omdat het anders niet werkt. Een interne tool die test-records nooit netjes scheidt van productiedata, omdat niemand dat onderscheid expliciet heeft gemaakt en de agent het er ook niet bij verzon.

Onderzoek uit 2024 wees uit dat bijna de helft van zakelijke AI-gebruikers heeft toegegeven minstens één belangrijke beslissing te hebben genomen op basis van gehallucineerde AI-output. Dat cijfer wordt vaak toegeschreven aan ChatGPT-gebruik, maar het tekent precies hetzelfde patroon dat in zelfgebouwde applicaties zit: plausibel-uitziende output, geen validatielaag eronder, en de illusie dat het allemaal klopt omdat de UI er professioneel uitziet.

2. Drie applicaties, drie waarheden

Marketing heeft snel een lead-tool gebouwd die wordt gevoed door een wekelijkse CSV-export. Sales werkt met een eigen interne CRM-applicatie die rechtstreeks aan Salesforce gekoppeld is. Finance heeft een approval-app die data uit SAP haalt. Drie applicaties die allemaal “klant” kennen, drie subtiel verschillende definities, drie totalen die niet overeenkomen.

Voeg daar een AI-agent aan toe die rauw mag rondgrasduinen in al die systemen, en het probleem wordt niet kleiner. Het wordt sneller. De agent improviseert zijn eigen weg door de data, krijgt soms iets terug wat erop lijkt, en presenteert dat als waarheid. Niemand ziet welke joins zijn gemaakt, welke filters zijn toegepast, welke definitie van “actieve klant” er stilletjes gebruikt is.

3. De applicatie verbergt z’n eigen fouten

Dit is voor mij persoonlijk de griezeligste. Lemkin’s agent fabriceerde nep-testresultaten om bugs te verstoppen. In een context zonder code review, zonder geautomatiseerde tests, zonder audit log, gebeurt dit dagelijks zonder dat iemand het merkt. Een workflow-app die exceptions stilletjes inslikt om de UI groen te houden. Een batch-job die als “geslaagd” wordt gemarkeerd terwijl een deel van de records is overgeslagen. Een sync-proces dat na een fout gewoon doorgaat met de records die wél te verwerken waren, en de rest stil laat verdwijnen.

De gebruiker ziet groene vinkjes en vertrouwt het. En waarom ook niet, het ziet eruit als een doorgrondige enterprise-applicatie, met dezelfde nette UI en dezelfde rapporten. Daardoor krijgt het ten onrechte het gezag van een systeem dat door architecten is doordacht, terwijl er onder de motorkap niemand verantwoordelijk is voor wat er gebeurt als het mis gaat.

Waarom dit een bestuurlijk vraagstuk is

Hier wil ik het frame even uit de IT-hoek halen. Zolang we dit als “security-issue” bespreken, blijft het op het bordje van de CISO liggen, en daar gaan we de plank misslaan.

De schade van een verkeerde applicatie is geen datalek. Geen compliance-issue. Geen klassiek security-incident waar een alarm voor afgaat. De schade is een verkeerd geprioriteerde lead-lijst die je sales-team weken in de verkeerde richting stuurt. Een onjuist berekende voorraad die je supply chain dirigeert. Een approval-flow die contracten doorlaat die er nooit door hadden mogen. Een operationele tool die op je service desk dagelijks acties triggert op basis van data die er goed uitziet maar niet klopt.

Operatie en besluitvorming op gefabriceerde of stilletjes-foute data is duurder dan het meeste wat een security-team ooit op z’n bord krijgt. En het is veel moeilijker te detecteren, want er gaat geen alarm af.

Het antwoord is geen verbod, het is een raamwerk

De twee verkeerde reacties van enterprise-IT zijn voorspelbaar. Of je timmert alles dicht, en dan omzeilen mensen het toch, alleen onder de radar en zonder dat IT er iets vanaf weet. Of je laat het gaan en hoopt op het beste, en dan komt de schade in golven, achteraf, op plekken waar je hem niet ziet aankomen.

De goede reactie zit ertussen: agentic development omarmen, maar binnen een raamwerk dat de guardrails levert die collega’s op de werkvloer zelf nooit gaan bouwen. Bij Ciphix bieden we dat via twee complementaire diensten die vaak naast elkaar bestaan en elkaar versterken.

Voor het bouwen van applicaties: Agentic Application Development. We laten AI-agents code schrijven, maar binnen een rigide base met module-gebaseerde access rules, default-deny op alle queries, field-level read/write matrices, AES-256-GCM-encryptie op gevoelige velden, lint-rules die directe database-toegang blokkeren, en CI-gates die niets in productie laten zonder type checks en end-to-end tests. De AI levert de snelheid, het raamwerk levert de correctheid en de veiligheid. Een AAD-agent kán simpelweg de fouten uit het Replit-verhaal niet maken, niet omdat de agent slimmer is, maar omdat het raamwerk eronder ze niet toelaat.

Voor het verbinden van agents met enterprise-systemen: Workato Enterprise MCP. In plaats van een agent rauw los te laten op je ERP, CRM en datawarehouses, wordt elke actie aangeroepen via een vooraf gedefinieerde, beheerde skill. De agent improviseert niet. De agent kiest uit een palet van skills met authenticatie, audit trail en role-based access control, waarbij elke actie de identiteit van de aanroepende gebruiker erft. Één controlelaag waar je weet wat de agent deed, namens wie, met welke data, op welk moment. Dat is wat een Single Source of Truth in de praktijk betekent: niet als databegrip, maar als operationele waarheid.

Beide diensten volgen hetzelfde principe: de agent kiest uit een goedgekeurd palet, de agent improviseert niet. Dat is het verschil tussen agentic coding als productiviteitswonder en als correctheid-bom.

Vijf vragen voor de bestuurskamer

Als je dit verhaal serieus wilt nemen op het niveau waar het thuishoort, zijn dit de vragen om morgen te stellen:

1. Welke operationele applicaties draaien er in onze organisatie waarvan IT niet weet dat ze bestaan, en die acties uitvoeren of beslissingen aansturen waar de business op vertrouwt?
2. Hebben we één Single Source of Truth voor onze kerncijfers en kerndefinities, of leven er drie versies bij drie afdelingen?
3. Als een AI-agent vandaag onze data wist of fabriceert, hebben we dan de audit trail om het te reconstrueren?
4. Hebben we een goedgekeurd pad waarop collega’s wél snel kunnen bouwen, mét de juiste guardrails?
5. Wie in onze organisatie is verantwoordelijk voor de correctheid van AI-gegenereerde output die in onze besluitvorming en onze operatie belandt?

Snelle apps zijn een doorbraak. Stille fouten zijn een ramp die zich opstapelt. Het verschil zit niet in de AI. Het zit in het raamwerk eronder.

Charles is werkzaam bij Ciphix en heeft dertien jaar ervaring met het bouwen van kritieke enterprise-maatwerksoftware op verschillende platformen. Reacties welkom.