Pitfalls, Boundaries & Decision Check

Een “handig scriptje” dat ineens een incident wordt

Een teamlid maakt met AI een script dat klantnotities uit e-mails samenvat en automatisch in het CRM plakt. Het werkt direct, iedereen is blij, en na twee weken vraagt een manager waarom sommige accounts ineens een verkeerde status hebben. Bij navraag blijkt: het script overschreef velden, er was geen logging, en het gebruikte e-mailteksten waar ook persoonsgegevens en vertrouwelijke afspraken in stonden. Niemand kan nog reconstrueren welke records zijn aangepast, met welke prompt, en op basis van welke input.

Dit is waarom pitfalls, boundaries en een decision check nu nodig zijn. Vibecoding verlaagt de drempel om automatisering te maken, maar het verlaagt óók de drempel om onbedoeld data, processen en verantwoordelijkheden te raken. In bedrijven telt niet alleen of iets “werkt”, maar of het verantwoord werkt: herhaalbaar, uitlegbaar, compliant, en met een stopknop als het misgaat.

In deze les breng je structuur aan in die risico’s. Je leert de meest voorkomende valkuilen herkennen, je leert waar de harde grenzen liggen (data, processen, beslissingen), en je krijgt een praktisch besluitkader om te bepalen: doorgaan, aanpassen, of escaleren.

Begrippen die je scherp moet houden (en waarom)

Pitfall betekent hier: een voorspelbare foutmodus van AI-gedreven bouwen die vaak pas laat zichtbaar wordt. Denk aan hallucinaties (overtuigend fout), verborgen aannames in code, of onbedoeld datalek door “even” een voorbeeld te plakken. Het lastige is dat deze fouten vaak geen crash geven; ze lekken stilletjes door in processen en rapportages.

Boundary is een grens waar vibecoding ophoudt “persoonlijke efficiëntie” te zijn en begint te lijken op een bedrijfsapplicatie of gereguleerd proces. De belangrijkste boundaries uit de praktijk zijn: persoonsgegevens, klant-impact, financiële impact, en beslissingen die mensen of klanten zichtbaar raken. Zodra je over zo’n grens gaat, heb je governance nodig: eigenaarschap, review, logging en toegangsbeheer.

Decision check is een korte, herhaalbare set vragen die je vóór implementatie beantwoordt. Het doel is niet om snelheid weg te nemen, maar om te voorkomen dat “snelle winst” later “lang incident” wordt. In de vorige les stond al centraal: AI-output is een voorstel, prompts zijn datapijplijnen, en vibecoding wordt snel een proces. De decision check is de praktische vertaling daarvan naar: “mag dit zo live, en onder welke voorwaarden?”

Als analogie: vibecoding is koken met een slimme assistent die recepten improviseert. Dat kan geweldig zijn, maar in een bedrijf serveer je niet alleen aan jezelf. De boundaries zijn je allergenenlijst en voedselveiligheidsregels; de decision check is je HACCP-moment: wat kan misgaan, hoe merk ik het, en wat doe ik dan?

De belangrijkste valkuilen en grenzen (met oorzaken, misvattingen en best practices)

1) “Het werkt” is niet hetzelfde als “het is betrouwbaar”

Generatieve AI kan code produceren die syntactisch klopt en zelfs functioneel lijkt, maar ondertussen aannames bevat over dataformaten, definities en randgevallen. In vibecoding zie je dit vaak als scripts die op één exportbestand werken, maar falen bij een leeg veld, een andere datumnotatie of een extra kolom. Het risico wordt groter omdat de output overtuigend oogt: nette variabelen, logische comments, een plausibele structuur. Daardoor krijgt het sneller vertrouwen dan handgeschreven “rommelcode”, terwijl de onderliggende zekerheid juist lager kan zijn.

Een typische misvatting is: “als ik genoeg context geef, voorkomt dat fouten.” Meer context kan de kans op relevante output verhogen, maar het maakt het niet waarheidsgetrouw of compleet. Het model blijft probabilistisch genereren en kan met veel context zelfs zelfverzekerder fout worden. In bedrijfsprocessen is dat gevaarlijk omdat fouten vaak niet direct in beeld zijn: een verkeerd berekende “health score”, een gemiste contractuitzondering, of een churn-label op basis van een verkeerde definitie van “actieve klant”.

Best practices sluiten aan op wat je eerder leerde: behandel output als eerste concept en ontwerp voor toetsbaarheid. Dat betekent dat je expliciet vraagt om aannames (“welke aannames maak je over datums/valuta/IDs?”), dat je werkt met voorbeelden (“hier zijn 5 correcte cases, pas precies die logica toe”), en dat je altijd toetst tegen een golden source (CRM-velden, HR-systeem, grootboek). Zodra iets invloed heeft op besluiten, leg je bovendien review-criteria vast: wat moet een mens controleren voordat het door mag.

2) Prompts zijn datapijplijnen: dataminimalisatie is een technische én organisatorische grens

Een prompt voelt als een chatbericht, maar in organisaties is het functioneel een datapijplijn: je verplaatst informatie van een bronsysteem (of document) naar een AI-systeem, inclusief mogelijke opslag, logging en toegangsrechten. De valkuil is dat mensen data delen “om even te testen”: een volledige lijst met klanten, een screenshot van een contract, een ticketdump met persoonsinformatie. Zelfs als een tool belooft niet te trainen op jouw input, kan er nog steeds sprake zijn van opslag voor servicekwaliteit, incidentanalyse of beheerstoegang. Daarom is intern niet automatisch veilig.

De boundary hier is data-classificatie: persoonsgegevens, vertrouwelijke klantinformatie, interne strategie, broncode en security-details hebben een ander risicoprofiel dan openbare informatie. Dataminimalisatie is de meest praktische best practice: deel alleen wat nodig is om de taak te laten slagen, en vervang waar kan door geanonimiseerde of synthetische voorbeelden. Bovendien helpt het inhoudelijk: minder ruis geeft vaak betere output. Een prompt met 20 irrelevante velden leidt regelmatig tot interpretatiefouten of “meeslepen” van verkeerde definities.

Een misverstand is: “als ik het maar binnen het team houd, is het oké.” Maar zodra je prompt- en outputlogica in workflows terechtkomt (copy-paste, scripts, integraties), verspreidt data zich juist makkelijker. Richt daarom eenvoudige grenzen in: welke velden mogen erin, welke absoluut niet, en waar wordt output opgeslagen. En maak het concreet: “geen namen of e-mails, alleen klant-ID’s”, “geen complete contracten, alleen de relevante clausule”, “geen productiesleutels of tokens in prompts”.

3) Het kantelpunt: van persoonlijke automatisering naar bedrijfsproces

Vibecoding start vaak als “ik automatiseer mijn eigen repetitieve taak”. Het kantelpunt komt wanneer de automatisering herhaalbaar wordt (dagelijks/wekelijkse runs), door anderen gebruikt wordt, of gekoppeld raakt aan bronsystemen zoals CRM/ERP/HRM. Dan ben je feitelijk software aan het draaien in je organisatie, ook al staat het niet in een officiële backlog. De pitfall is schaduw-automatisering: niemand voelt zich eigenaar, er is geen versiebeheer, en bij een incident weet niemand waar de logica precies staat, wie hem kan aanpassen, en hoe je hem uitzet.

Een typische misvatting is: “het is maar een klein script, dus governance is overkill.” In werkelijkheid bepaalt impact het risiconiveau, niet codegrootte. Een script van 40 regels dat klantstatussen wijzigt kan meer schade doen dan een grote interne tool die alleen leest. Daarom is de boundary hier: raakt het script persoonsgegevens, financiële uitkomsten, klantcommunicatie of operationele acties? Zo ja, dan moeten er minimale bedrijfssoftware-principes op: eigenaarschap, changelog, simpele documentatie, en een rollback/stopmechanisme.

Best practices kunnen lichtgewicht zijn, maar moeten wél expliciet zijn. Leg minimaal vast: wat het script doet, welke data het aanraakt, welke velden het mag wijzigen (whitelist), en wie het mag draaien. Voeg logging toe: timestamp, input-samenvatting (zonder gevoelige details), promptversie, en resultaatstatus. Zo kun je achteraf reconstrueren wat er gebeurde, en voorkom je dat “vibe” verandert in “mystery meat” in audits of incidentreviews.

4) Mens-in-de-lus is een ontwerpkeuze (en werkt alleen met criteria)

Mens-in-de-lus klinkt als: “iemand kijkt er even naar.” In de praktijk werkt het pas als je bewust kiest waar de mens controleert en waarop. De pitfall is dat controle pas achteraf wordt toegevoegd, wanneer de automatisering al in gebruik is en de organisatie gewend is aan snelheid. Dan voelt review als vertraging en wordt het overgeslagen. Een tweede valkuil is dat mensen output wel lezen, maar zonder criteria; dan wordt controle een subjectieve “vibe check” en geen risicobeheersing.

De boundary is hier beslissingsimpact: zodra AI-output een besluit beïnvloedt (wie krijgt een korting, wie komt op een shortlist, welk account is “at risk”), moet je kunnen uitleggen hoe dat advies tot stand kwam en welke menselijke beoordeling plaatsvond. Auditability vraagt om zichtbaarheid: welke bronnen, welke definities, welke uitzonderingen, en welke onzekerheden. Zonder die elementen wordt een menselijke goedkeuring vooral een schijncontrole.

Best practice is om review “snackable” te maken: de AI moet output leveren in een formaat dat snel te verifiëren is, met expliciete onzekerheden (“onbekend”, “niet genoemd”), en met een duidelijke scheiding tussen feitenextractie en interpretatie. Koppel dat aan vooraf vastgestelde criteria: “komt dit uit de golden source?”, “zijn verboden velden leeg?”, “zijn uitzonderingen afgedekt?”, “is de actie omkeerbaar?”. Zo blijft vibecoding snel, maar niet roekeloos.

Wanneer iets nog kan, en wanneer je moet opschalen

Een korte decision check die je in 2 minuten kunt uitvoeren

De decision check werkt het best als je hem ziet als “stoplicht”: groen (door), oranje (aanpassen), rood (escaleren). Je hoeft niet alles zwaar te maken, maar je moet wél consequent zijn.

1. Data-check: Welke data gaat erin en eruit? Is dataminimalisatie toegepast, en zijn gevoelige velden uitgesloten?
2. Impact-check: Beïnvloedt dit klantcommunicatie, financiële uitkomst, HR-besluitvorming of bronsystemen die “waarheid” zijn?
3. Controle-check: Waar zit de mens-in-de-lus, en welke criteria gebruikt die persoon om te beoordelen?
4. Traceerbaarheid-check: Kun je achteraf reconstrueren wat er gebeurde (logging, promptversie, inputsamenvatting) zonder extra privacyrisico?
5. Stop-check: Wat is je fallback als het misgaat? Kun je het uitzetten en herstel je wijzigingen?

[[flowchart-placeholder]]

Twee praktijkvoorbeelden: zo voorkom je dat vibecoding over de grens gaat

Voorbeeld 1: HR-samenvattingen zonder “AI kiest de beste kandidaat”

HR wil sneller door cv’s en motivatiebrieven heen. De verleiding is groot om AI te vragen: “geef mij de top 5 kandidaten.” Dat is precies waar pitfalls en boundaries samenkomen: je verwerkt persoonsgegevens, je bouwt impliciet een beslismodel, en je maakt het selectieproces minder uitlegbaar. Bovendien kan AI “aanvullen” wat niet in het cv staat, of onbewust sturen op niet-relevante kenmerken. Als dit in een workflow belandt, kan de bias niet incidenteel maar systematisch worden.

Een robuuste aanpak verschuift de taak van selectie naar structurering. Stap voor stap: HR definieert vooraf objectieve criteria (vereiste skills, minimale ervaring, must-have certificeringen) en verbiedt expliciet andere kenmerken. Vervolgens krijgt AI alleen de relevante passages of een geanonimiseerde versie, en de output is een tabel: criteria-match per kandidaat, met expliciete “onbekend”-velden waar informatie ontbreekt. Daarna beslist de recruiter, en noteert kort welke criteria doorslaggevend waren. Zo blijft AI een versneller van extractie en consistentie, niet de beslisser.

De impact is duidelijk: minder tijd aan lezen en knippen/plakken, en meer consistente dossiers. De beperking blijft dat slechte criteria slecht werk opschalen: als de functie-eisen vaag zijn, wordt de output ook vaag maar overtuigend. Daarom hoort bij de decision check hier vrijwel altijd “oranje”: gecontroleerde input, menselijke beslissing, en vastgelegde criteria.

Voorbeeld 2: CRM-updates door Customer Success zonder datakwaliteit te slopen

Customer Success wil na elk klantgesprek automatisch samenvattingen en next steps in het CRM. Vibecoding maakt het simpel: transcript → AI-samenvatting → API-call → CRM. De pitfall is dat je van “draft” naar “actie” schuift. Een klein interpretatiefoutje (“next step” wordt een commitment, “health score” krijgt een harde waarde) kan honderden records beïnvloeden, zeker als het op schaal draait. Zonder whitelist of logging merk je het pas als rapportages of klantafspraken niet meer kloppen.

Een veilige implementatie bouwt grenzen in. Stap voor stap: AI schrijft eerst alleen een draft naar een apart veld of een concept-record, nooit direct naar kernvelden. Alleen een whitelist van toegestane velden wordt gevuld (bijvoorbeeld “Gespreksnotitie”, “Voorgestelde next steps”), en gevoelige passages blijven buiten de output. De CSM keurt de draft goed en past waar nodig aan vóór publicatie. Logging legt vast welke promptversie is gebruikt, welke velden zijn aangeraakt, en of de gebruiker akkoord gaf. Daarmee kun je fouten herleiden en corrigeren zonder het CRM te vervuilen.

De voordelen zijn minder administratietijd en beter overdraagbare accountkennis. De beperkingen zijn discipline en definities: als teams niet afspreken wat een “next step” precies is (taak, e-mail, meeting), ontstaat alsnog chaos. Hier is de boundary meestal “hoog”: je raakt bronsystemen en klantafspraken, dus je decision check vereist vrijwel altijd review, logging en een stopmechanisme.

De kern in één keer scherp

Je hoeft vibecoding niet te stoppen om het veilig te maken; je moet het begrenzen en beslisbaar maken.

• AI-output is plausibel, niet bewezen: ontwerp voor toetsing aan golden sources en randgevallen.

• Prompts verplaatsen data: dataminimalisatie en duidelijke veldgrenzen zijn geen extra’s, maar randvoorwaarden.

• Herhaalbaarheid maakt het een proces: zodra het terugschrijft, gedeeld wordt of regelmatig draait, heb je eigenaarschap, logging en een stopknop nodig.

• Mens-in-de-lus werkt alleen met criteria: “even kijken” is niet genoeg zonder checkpunten die snel en herhaalbaar zijn.

This sets you up perfectly for Future Learning & Action Plan [20 minutes].