Wanneer “even snel” ineens te veel prijsgeeft

Een accountmanager wil na een demo snel een follow-up e-mail maken met AI. Om “minder generiek” te worden, plakt ze de notulen van het gesprek in de prompt: namen van deelnemers, een interne ticketlink, en een opmerking over een beveiligingsissue dat nog niet publiek is. De e-mail wordt inderdaad scherp en relevant—maar de prompt bevat nu informatie die je mogelijk niet in een externe AI-tool mag zetten, en die bovendien in logs of trainingsdata kan belanden (afhankelijk van tool en instellingen). De snelheidwinst verandert zo in een compliance- en reputatierisico.

Dit onderwerp is juist nu belangrijk omdat vibecoding in bedrijven aanvoelt als normale productiviteit (“ik maak het alleen even sneller”), terwijl de input in de prompt vaak de échte asset is: bedrijfskennis, klantdetails, beleidsinterpretaties en interne beslissingen. Als je die input niet goed verpakt, krijg je óf generieke output (te weinig context), óf onnodig risico (te veel context). Context packaging is de vaardigheid om precies genoeg te geven voor bruikbare output—zonder oversharing.

Vandaag krijg je een praktische manier om context te “pakken”: wat moet erin, wat moet eruit, en hoe stuur je het model richting kwaliteit en herhaalbaarheid zonder gevoelige details te delen.

Wat “context” in een prompt echt is (en waarom het geen dump is)

Context is alle achtergrondinformatie die het model nodig heeft om jouw taak goed uit te voeren: doel, doelgroep, definities, bronmateriaal, randvoorwaarden en kwaliteitslat. In de vorige les is context één van de bouwstenen van een sterke prompt—naast rol, constraints, outputformat en succescriteria. Het belangrijke verschil: context is niet “alles wat jij weet”, maar alles wat het model nodig heeft om een specifiek deliverable te maken dat iemand kan reviewen en goedkeuren.

Oversharing betekent: je deelt meer (of specifieker) dan nodig is om de taak te laten slagen. Dat kan gaan over persoonsgegevens, klantnamen, interne systemen, security-details, prijsafspraken, interne discussies (“Legal wil dit nog niet”), of simpelweg te veel ruis waardoor het model gaat leunen op irrelevante details. Oversharing is dus niet alleen een privacyprobleem; het is ook een kwaliteitprobleem, omdat extra details de output de verkeerde kant op kunnen “ankeren”.

Een nuttige analogie: zie context als een productverpakking. De verpakking heeft genoeg informatie om het product veilig te gebruiken (ingrediënten, waarschuwingen, gebruiksaanwijzing), maar je stopt niet het volledige productieproces, alle leverancierscontracten en de complete boekhouding in dezelfde doos. Goede context is vergelijkbaar: voldoende om correct te handelen, maar zo beperkt dat de schade bij verkeerd gebruik klein blijft.

Het doel is een balans tussen drie dingen die in organisaties altijd spelen:

  • Relevantie: genoeg achtergrond om niet generiek te worden.

  • Controleerbaarheid: reviewers moeten kunnen zien waarop output is gebaseerd (bron, definities, aannames).

  • Risicobeheersing: zo min mogelijk gevoelige details in prompts, zeker buiten je eigen perimeter.

Een simpel, herhaalbaar model: minimal viable context + harde randen

1) Minimal viable context: wat móét het model weten?

Minimal viable context is de kleinste set informatie die nog steeds bruikbare output oplevert. In bedrijfswerk zit die set meestal in vijf categorieën:

  • Doel en doelgroep: Waar moet de output toe leiden, en voor wie is het?

  • Bron en “wat is leidend?”: Welke tekst, bullets of beleidsregels moeten gevolgd worden?

  • Definities en terminologie: Welke woorden hebben bij jullie een vaste betekenis?

  • Succescriteria: Waaraan herken je dat dit “af” is (bijv. auditbaar, toon correct, geen nieuwe feiten)?

  • Constraints: Wat mag expliciet niet (privacy, geen interne systemen, geen absolute claims)?

Het effect is causaal en voorspelbaar: als je doel/doelgroep mist, wordt de output generiek; als je bron “leidend” niet benoemt, gaat het model creatief interpreteren; als je definities niet geeft, introduceert het model stille wijzigingen; en zonder constraints kun je per ongeluk privacy of compliance schenden. Context packaging is dus niet “kort houden”, maar het minimaliseren van variatie en risico.

Een typische misvatting uit vibecoding is: “Als ik meer context geef, wordt het vanzelf beter.” In werkelijkheid stijgt de kwaliteit soms, maar stijgt óók de kans dat je iets deelt wat niet gedeeld had mogen worden, of dat verouderde details als feit worden verwerkt. Je optimaliseert daarom niet op “meer”, maar op “precies genoeg, met duidelijke randen”.

2) Harde randen: wat je uit je prompt weert (of abstraheert)

In de vorige les waren constraints een eigen bouwsteen; hier maak je ze praktisch door “rode zones” standaard uit je context te halen. Denk in drie soorten randen:

  • Privacy-rand: geen persoonsgegevens, geen contactgegevens, geen bijzondere persoonsgegevens.

  • Bedrijfsgeheim-rand: geen interne links, systemen, kwetsbaarheden, roadmap, prijsafspraken.

  • Verantwoordings-rand: geen uitspraken of toezeggingen die je later moet waarmaken (“100% veilig”, “volledig compliant”) tenzij je exacte, goedgekeurde tekst hebt.

Dit is niet alleen voorzichtigheid; het maakt je prompts ook beter onderhoudbaar. Als je output later herhaald moet worden door iemand anders, wil je niet dat succes afhankelijk is van het plakken van gevoelige notulen. Je wilt een template die werkt met geabstraheerde, veilige context (bijv. “klant is IT-manager in zorgsector”, “doel is afspraak voor technische deep-dive”).

3) Abstractie in plaats van details: dezelfde relevantie, minder risico

De kerntechniek is abstraheren: je vervangt specifieke gevoelige details door categorieën of placeholders, terwijl je de relevante besluitinformatie bewaart. Voorbeeld: in plaats van “Jan Jansen van klant X” gebruik je “de IT-manager” en “de klant”. In plaats van “Confluence-link naar incident 18473” gebruik je “een intern incident (niet delen)”. En in plaats van “ze hebben kwetsbaarheid Y” gebruik je “er is een openstaand security-vraagstuk dat nog in onderzoek is”.

Deze aanpak werkt omdat modellen vooral baat hebben bij structuur en intentie (doel, constraints, format, criteria) en minder bij identificeerbare details. Je houdt de stuurinformatie, je verwijdert de identificeerbaarheid. Een tweede voordeel: je reduceert “context-ruis”, waardoor het model minder snel irrelevante feiten gaat verwerken alsof ze belangrijk zijn.

4) Context als pakketje: scheid “mag delen” van “alleen intern”

In organisaties is veel context wél nodig—maar niet alles hoort in dezelfde prompt, zeker niet in tools buiten de gecontroleerde omgeving. Een praktische packaging-regel is daarom: splits context in lagen.

Laag Wat zit erin (voorbeelden) Waarom dit helpt Risico als je dit mengt
Publiek / algemeen Sector, type klant, algemeen doel (“follow-up na demo”), neutrale tone-of-voice Houdt output relevant zonder herleidbaarheid Lage toegevoegde waarde van specifieke details; je deelt onnodig veel
Intern / bedrijfsafspraken Merktoon (“nuchter, geen hype”), standaarddisclaimers, approved claims, beleidsterminologie Consistentie en compliance zonder klantdata Onjuiste claims of tone-of-voice drift als dit ontbreekt
Vertrouwelijk / casus-specifiek Namen, prijzen, interne links, security-details, onderhandelingspositie Vaak niet nodig voor de vorm; hoog risico Datalek, juridische exposure, reputatieschade

De bedoeling is niet dat je nooit casus-specifiek werkt, maar dat je bewust kiest waar je die informatie verwerkt. Als je wél casuscontext nodig hebt, probeer dan eerst te abstraheren of te herformuleren naar niet-identificeerbare kenmerken. En als iets écht niet te abstraheren is, dan is dat een signaal dat je een andere werkwijze of toolkeuze nodig hebt (of een strikt intern goedgekeurd kanaal).

5) Maak review makkelijker: laat het model expliciet omgaan met hiaten

Een goed verpakte context is vaak “net niet volledig”. Dat is oké—zolang je het model instrueert om hiaten zichtbaar te maken, in plaats van ze te vullen met verzinsels. Dit sluit aan op de vorige les: succescriteria zoals “maak aannames expliciet” en “geen nieuwe feiten toevoegen zonder markering” zijn hier essentieel.

Je context packaging wordt sterker als je in je prompt standaard toevoegt:

  • “Als informatie ontbreekt: stel max. 3 gerichte vragen.”

  • “Markeer aannames met ‘AANNAME: …’.”

  • “Gebruik alleen het aangeleverde bronmateriaal; voeg geen nieuwe feiten toe.”

Zo krijg je output die niet alleen netjes is, maar ook controleerbaar. Reviewers zien direct: wat is gebaseerd op bron, wat is invulling, wat is nog een open punt. Dat voorkomt dat AI “stil” beleid aanpast of commerciële toezeggingen doet die niemand heeft goedgekeurd.

[[flowchart-placeholder]]

Twee bedrijfsvoorbeelden: dezelfde bruikbaarheid, minder blootstelling

Voorbeeld 1: HR herschrijft beleid — zonder interne discussies en personeelscases te lekken

Situatie: HR wil een thuiswerkbeleid begrijpelijk maken voor medewerkers. In vibecoding ontstaat snel de neiging om extra context te plakken: klachtenmails van medewerkers, voorbeelden van misbruik, of een interne discussie met Legal (“zo streng willen we het eigenlijk niet opschrijven”). Dat voelt behulpzaam, maar het is precies de context die je later niet in een extern systeem terug wil zien, en die bovendien de tekst kan kleuren met uitzonderingssituaties.

Een betere packaging-stap-voor-stap aanpak:

  1. HR gebruikt als leidende bron alleen de huidige beleidsversie (de tekst die al goedgekeurd is).
  2. HR voegt definities en terminologie toe die niet mogen verschuiven (bijv. wat “thuiswerkdag”, “standplaats” of “arboregels” bij jullie betekenen).
  3. HR zet constraints expliciet: “betekenis mag niet veranderen”, “modale werkwoorden behouden” (moet/kan/mag), “geen nieuwe regels toevoegen”.
  4. HR vraagt om output in een reviewbaar format: vaste kopjes (scope, regels, uitzonderingen, contact), plus een “wijzigingslijst: redactioneel vs inhoudelijk”.

Impact en beperking: Legal kan de wijzigingslijst snel scannen op inhoudelijke verschuivingen, in plaats van zinnen te moeten vergelijken op gevoel. HR krijgt heldere taal voor medewerkers zonder dat anekdotes of gevoelige individuele cases in de prompt belanden. De beperking blijft dat parafrases soms nuance verschuiven; juist daarom is “markeer twijfel en open vragen” een belangrijk succescriterium bij context packaging.

Daarnaast past dit in een bredere workflow: je houdt de bron (beleid) in een gecontroleerde plek, en je gebruikt AI vooral als redactionele versneller. De prompt bevat dan het minimum dat nodig is: doel/doelgroep, leidende bron, harde constraints, en een outputformat dat review goedkoop maakt.

Voorbeeld 2: Sales follow-up e-mail — relevant zonder persoonsgegevens en interne concessies

Situatie: Sales wil na een demo een follow-up sturen. De “snelle” route is notulen plakken: namen, exacte pijnpunten, budgetindicatie, en een concessie (“we kunnen 20% korting doen als ze voor vrijdag tekenen”). Dat maakt de e-mail hyper-specifiek, maar het is precies het type informatie dat je niet wilt verspreiden via prompts. Bovendien kan het model die concessie per ongeluk herhalen of versterken (“we bieden standaard 20% korting”).

Packaging-stap-voor-stap met abstractie:

  1. Sales definieert doel en doelgroep: “korte follow-up naar drukke IT-manager, gericht op next step (technische deep-dive)”.
  2. Sales geeft niet-gevoelige context: sector (bijv. zorg/finance), hoofdprobleem als categorie (“legacy integraties”, “rapportage”), en gewenste toon (“nuchter, geen hype”).
  3. Sales zet harde constraints: geen persoonsgegevens, geen prijsafspraken, geen absolute security-claims, geen verwijzingen naar interne systemen.
  4. Sales vraagt om strak outputformat: onderwerpregel + 3 korte alinea’s + 1 call-to-action, max 120 woorden, en “als er informatie ontbreekt: stel 2 vragen”.

Impact en beperking: De output is nog steeds relevant (model weet wie de lezer is en wat de next step is), maar je hebt risico-informatie uit de prompt gehouden. Marketing ziet consistente tone-of-voice; Legal ziet minder riskante beweringen; en sales kan dezelfde template hergebruiken zonder telkens klantdata te dumpen. De beperking is dat de e-mail soms iets minder “persoonlijk” voelt; dat vang je op door personalisatie pas te doen in een gecontroleerde stap (bijv. handmatig toevoegen van één veilige zin, of via interne tooling die hiervoor is goedgekeurd).

In het proces werkt dit goed omdat je prompts meer gaan lijken op herbruikbare specs dan op eenmalige chats. Je team kan een standaard “follow-up prompt” onderhouden met vaste constraints en succescriteria, en alleen veilige variabelen invullen per klanttype.

De kern in één gedachte: relevantie door structuur, niet door geheimen

Context packaging zonder oversharing komt neer op één ontwerpkeuze: je streeft naar relevantie via duidelijke specificatie (doel, doelgroep, bron, definities, constraints, succescriteria) in plaats van relevantie via steeds meer interne details. Dat maakt output beter reviewbaar, minder risicovol, en makkelijker te herhalen door anderen.

Belangrijkste takeaways:

  • Minimal viable context: geef alleen wat nodig is om de taak goed te doen; alles extra is risico of ruis totdat bewezen is dat het nodig is.

  • Harde randen: zet privacy-, bedrijfsgeheim- en verantwoordingsgrenzen expliciet in je prompt, zodat “per ongeluk” delen minder kans krijgt.

  • Abstractie houdt relevantie hoog: gebruik rollen, categorieën en placeholders in plaats van namen, links en gevoelige specifics.

  • Maak hiaten zichtbaar: laat het model vragen stellen en aannames labelen, zodat reviewers kunnen afvinken in plaats van gokken.

In de volgende les, zul je dit verder uitbouwen met Reliability & output shaping [20 minutes].

Last modified: Thursday, 4 June 2026, 11:37 AM