Secure AI: prompts, redactie, logging

Als “even snel” samenvatten een datarisico wordt

Je zit in een bank- of verzekeringsomgeving in het groot mkb. Een collega wil sneller werken en plakt een klantmail, een stukje KYC-dossier of een claimnotitie in een AI-chat: “maak hier een nette samenvatting van” of “herschrijf dit klantvriendelijk”. Binnen seconden is de tekst bruikbaarder—maar je hebt óók een nieuw spoor gemaakt: de prompt, mogelijke tool-logs, en soms zelfs opgeslagen conversatiegeschiedenis. Dat spoor kan gevoeliger zijn dan je denkt, omdat het vaak méér context bevat dan het oorspronkelijke document (bijv. jouw extra toelichting, interne beoordeling, of ‘wat we eigenlijk denken dat er speelt’).

Dit onderwerp is nu urgent omdat AI het normale dataproces omzeilt. Waar je eerder een document binnen gecontroleerde systemen bewerkte (DMS/CRM, autorisaties, bewaartermijnen), schuif je met AI makkelijk richting een omgeving waar retentie, toegang, support-inzage en logging anders geregeld zijn. In financiële dienstverlening is dat meteen relevant voor AVG/GDPR, contractuele geheimhouding, interne informatieclassificatie en auditverwachtingen. “We don’t train on your data” is daarbij hooguit één puzzelstuk.

In deze les krijg je een praktisch, veilig werkmodel voor drie dingen die in het dagelijks gebruik het verschil maken: prompt-hygiëne, redactie (sanitizen) vóór je iets invoert, en logging zó begrijpen dat je geen onbedoeld nieuw datalek creëert.

Drie bouwstenen: prompt, redactie en logging—en waarom ze samen horen

Een paar definities om op één lijn te komen:

• Prompt: alles wat jij aan het model geeft—tekst, instructies, fragmenten, bijlagen, én de context die de tool automatisch kan toevoegen (bijv. gesprekshistorie of “custom instructions”). In de praktijk is een prompt dus vaak een micro-dossier.

• Redactie (sanitizing): doelgericht verwijderen, vervangen of veralgemeniseren van informatie zodat de input niet (of minder) herleidbaar is. Dit gaat verder dan namen weghalen; ook dossiernummers, datums, bedragen, locaties en unieke combinaties tellen mee (het mozaïek-effect).

• Logging: het vastleggen van activiteiten en gegevens voor beheer en controle. Denk aan prompt- en outputlogging, tijdstempels, user-ID’s, tool-instellingen, en soms ook opgeslagen chats. Logging is essentieel voor aantoonbaarheid, maar kan tegelijk een extra opslagplek voor gevoelige data zijn.

Deze les sluit direct aan op het fundament van data-classificatie en klantdataregels: je beoordeelt nog steeds data in, data uit en metadata, en je hanteert in de praktijk dezelfde principes: doelbinding, dataminimalisatie en beheersbaarheid/aantoonbaarheid. Het verschil is dat prompts en logs vaak buiten de “normale” documentketen vallen, waardoor je sneller ongemerkt de regels schendt.

Een nuttige analogie: zie AI als een balie waar je informatie “hardop uitspreekt”. Redactie is wat je thuis al uit je verhaal haalt voordat je vertrekt. Logging is de beveiligingscamera die nuttig is bij incidenten, maar die je óók niet willekeurig in een kleedkamer wilt ophangen. Veilig werken betekent: je bepaalt wat je zegt, hoe je het zegt, en wat er wordt vastgelegd.

Prompt-hygiëne: zo stuur je AI zonder klantdata te morsen

Prompt-hygiëne gaat over het ontwerpen van prompts die het gewenste resultaat opleveren met zo min mogelijk gevoelige input. In bank- en verzekeringsprocessen is de valkuil dat je AI vraagt om “slimme” output, en daarom denkt dat je “rijke” input nodig hebt—complete klantmails, exports, dossierfragmenten. Vaak is dat niet waar. Veel taken (samenvatten, herschrijven, structureren) werken prima op abstracte feiten of op templates, zolang je de opdracht scherp maakt en de output op de juiste manier positioneert: als concept, niet als bron van waarheid.

Een goede veilige prompt heeft meestal drie lagen. Eerst zet je het doel strak neer (“Maak 5 bullets: status, risico, open acties”). Dan geef je alleen de minimale feiten die nodig zijn, bij voorkeur al ge-redigeerd (placeholders zoals [Klant_A], [Dossier_X], [Product_Y]). Tot slot voeg je guardrails toe: wat de AI níet mag doen (“Verzin geen getallen; noem geen personen; gebruik geen medische details; als info ontbreekt: markeer als ‘onbekend’”). Dit voorkomt dat een model gaten gaat opvullen met aannames—een bekend probleem bij generatieve AI dat in financiële context al snel leidt tot foutieve toezeggingen of verkeerde risico-inschattingen.

Veelvoorkomende misvatting: “Als ik de naam verwijder, is het veilig.” In jouw sector is herleidbaarheid vaak indirect: een combinatie van postcode, datum, claimtype, uniek polisproduct en bedrag kan intern al genoeg zijn om iemand te herkennen. Dat is precies het mozaïek-effect uit de eerdere basis: losse stukjes zijn onschuldig, samen worden ze identificerend. Prompt-hygiëne betekent daarom ook: geen unieke combinaties, afronden van bedragen (“ongeveer €5k”), veralgemeniseren van tijd (“Q1”), en vermijden van interne labels die gevoelige classificaties verraden (bijv. fraudesignalen of acceptatieregels).

Onderstaande tabel helpt je het verschil te zien tussen “handig” en “veilig effectief” prompten—zonder dat productiviteit verdwijnt.

Redactie in AI-context: pseudonimiseren is nuttig, maar geen vrijbrief

Redactie is de praktische handeling die prompt-hygiëne mogelijk maakt. In financiële dienstverlening gaat redactie niet alleen om privacy, maar ook om het beschermen van vertrouwelijke bedrijfsinformatie: pricing-logica, acceptatiecriteria, fraudedetectieregels, incidentdetails, auditbevindingen en security-informatie. AI is sterk in het structureren van tekst; precies daarom kan het onbedoeld gevoelige details “netjes” uitpakken en daarmee makkelijker deelbaar maken. Als je redacteert, bescherm je dus niet alleen de klant, maar ook je interne werking.

Goede redactie begint met een snelle maar strenge vraag: “Kan iemand—binnen of buiten de organisatie—op basis van wat ik invoer, redelijkerwijs herleiden om wie/waarover dit gaat?” Het antwoord is vaker “ja” dan mensen denken, omdat jouw organisatie zelf de sleutel heeft om placeholders terug te koppelen. Daarom blijft pseudonimisering (IDs vervangen) in veel gevallen nog steeds persoonsgegevens onder de AVG: herleidbaar met extra informatie. Anonimisering (niet redelijkerwijs herleidbaar) is veel lastiger; in dossiers met transacties, claims of KYC-details is er bijna altijd een uniek patroon. De veilige praktijk is dus: pseudonimiseren waar zinvol, maar daarnaast ook veralgemeniseren en combinatierisico verlagen.

Concreet werkt redactie het best als je vaste “snijregels” hanteert. Verwijder directe identifiers (naam, IBAN, polisnummer, e-mail). Verlaag indirecte identifiers (exacte datums, exacte bedragen, unieke locaties) naar bandbreedtes of perioden. En let op “interne identifiers”: dossiernamen, kanaalnamen, ticketnummers, of labels als “high risk”, “fraude-verdacht” die je niet in brede tooling wilt laten opduiken. Een extra valkuil is dat mensen alleen de bron redigeren, maar niet hun eigen toelichting in de prompt; juist jouw samenvattende zin (“dit is een bekende wanbetaler”) kan gevoeliger zijn dan het documentfragment zelf.

Deze vergelijking laat zien wanneer redactie in de praktijk “goed genoeg” is, en waar schijnveiligheid begint.

Logging: onmisbaar voor controle, maar ook een extra datacontainer

Logging is in gereguleerde omgevingen geen luxe: je wil kunnen aantonen wie een AI-tool gebruikt, wanneer, met welke instellingen, en of er incidenten zijn. Maar bij AI is logging dubbelzinnig, omdat de meest waardevolle logs (prompts en outputs) ook de meest gevoelige kunnen zijn. Het gevolg: je kunt “perfect” dataminimaliseren in je systemen, en vervolgens alsnog gevoelige data opslaan in een loglaag waar andere bewaartermijnen, toegangsrechten of supportprocessen gelden. Dat is precies de situatie waarin mensen achteraf zeggen: “We wisten niet dat dit werd opgeslagen.”

Om logging goed te begrijpen, helpt het om drie niveaus te onderscheiden. Operationele logs (beschikbaarheid, errors, performance) bevatten meestal weinig inhoud, maar wel metadata (user-ID, tijd, toolversie). Auditlogs leggen acties vast (inloggen, documenten uploaden, policy overrides) en zijn cruciaal voor onderzoek en toezicht. Contentlogs—prompts, outputs, conversatiegeschiedenis—zijn het spannendst: ze kunnen letterlijk klantdata of interne beoordelingen bevatten. Als contentlogging aan staat, moet je dus extra scherp zijn op dataminimalisatie en redactie, én op wie die logs kan inzien.

Een typische misvatting is: “Logging is altijd goed, want audit.” In werkelijkheid is logging alleen goed als je het proportioneel inricht: voldoende voor beheersing, minimaal in data, en met duidelijke retentie en toegang. Denk aan vragen als: wordt chatgeschiedenis standaard bewaard? Kunnen beheerders prompts lezen? Worden prompts gebruikt voor “product improvement”? Is er een exportfunctie? Worden logs opgeslagen in een andere jurisdictie of onder andere subverwerkers? Dat zijn governancevragen, maar jij voelt de impact direct in je dagelijkse werk: hoe schoner jouw prompts, hoe minder gevoelig je logs—en hoe kleiner de incidentimpact.

Onderstaande beslislogica is een snelle mental model voor dagelijks gebruik: ga er vanuit dat alles wat je typt of uploadt kan worden gelogd, tenzij je expliciet zeker weet van niet.

[[flowchart-placeholder]]

Twee werksituaties: zo pas je prompt, redactie en logging stap voor stap toe

Voorbeeld 1: Bank — KYC-overdracht samenvatten zonder een micro-dossier in je prompt te bouwen

Situatie: een relatiebeheerder maakt een overdrachtsnotitie voor een collega. Het KYC-dossier bevat UBO-informatie, risicosignalen, documentstatus en mogelijk transactiemonitoring-signalen. De “snelle” route is een CRM-export of KYC-rapport plakken en vragen om een managementsamenvatting. Dat is vrijwel zeker vertrouwelijk en bevat vaak persoonsgegevens; bovendien creëer je met je prompt en output een extra tekstvariant die kan blijven hangen in tool-logging of conversatiegeschiedenis.

Stap voor stap veilig werken ziet er anders uit. Eerst formuleer je het doel los van de data: “Maak 3 bullets: bedrijfsstructuur (hoog niveau), 3 bullets: risicothema’s (categorieën), 3 bullets: open acties (zonder namen).” Dan redacteer je de input: geen namen, geen registratienummers, geen IBAN, geen exacte bedragen of datums. Je vervangt UBO’s door [UBO_1] en tijd door perioden (“Q1”, “laatste 90 dagen”). Risicosignalen beschrijf je als categorie (“ongebruikelijke transactiepatronen gemarkeerd”) zonder details die intern herleidbaar zijn tot één specifieke klant. Tot slot voeg je guardrails toe: “Geen aannames; markeer ontbrekende info; geen juridische duiding.”

De impact is praktisch: je krijgt snel een nette overdrachtstekst die bruikbaar is in interne communicatie, terwijl je het risico van datalek via prompt- of contentlogging sterk reduceert. De beperking blijft: de AI-output is een concept; je verifieert altijd tegen het dossier in de gecontroleerde systemen. En als je merkt dat je tóch exacte identifiers nodig hebt voor het doel, is dat een signaal dat deze taak mogelijk niet geschikt is voor een generieke AI-chat, of alleen in een strikt gecontroleerde omgeving mag.

Voorbeeld 2: Verzekeraar — klantmail herschrijven bij arbeidsongeschiktheid zonder medische details in AI te stoppen

Situatie: een claimbehandelaar wil een empathische statusupdate sturen. In het dossier staan medische passages en details uit verklaringen. Dit valt al snel onder zeer vertrouwelijk (bijzondere persoonsgegevens). Mensen proberen dit soms “veilig” te maken door naam en polisnummer weg te halen, maar de claimcontext (type letsel, datum incident, behandelaar, woonplaats) kan nog steeds herleidbaar zijn. Daarnaast kan contentlogging van de AI-tool onbedoeld medische informatie bewaren, wat de impact van een incident sterk vergroot.

De veilige aanpak is om AI te gebruiken op de toon- en structuurlaag, niet op de medische inhoud. Je prompt bevat geen dossierpassages, maar een generieke opdracht: “Schrijf een professionele, begripvolle mail in het Nederlands: bevestig ontvangst van stukken, benoem dat beoordeling loopt, geef generieke vervolgstappen en contactmogelijkheden. Vermijd medische details en harde toezeggingen.” Vervolgens vul je in je eigen gecontroleerde systeem alleen de noodzakelijke feitelijke elementen handmatig in (bijv. referentienummer uit het systeem, verwachte doorlooptijd volgens interne norm, en een neutrale omschrijving van de status). Je let er extra op dat je niet in je prompt alsnog “even uitlegt wat er medisch speelt”.

Het voordeel is dubbel. Je wint tijd en consistentie (heldere, klantvriendelijke mails met minder escalaties), én je houdt het meest risicovolle datatype buiten prompts en logs. De beperking is dat de mail minder “persoonlijk” lijkt, maar in claims is dat vaak juist beter: minder medische details in communicatie betekent minder kans op onnodige verspreiding, misinterpretatie of juridische onhandigheid. AI blijft hier een schrijfassistent, geen dossierverwerker.

De kern die je morgen al gebruikt

Veilig AI-gebruik in jouw sector is zelden een kwestie van één magische instelling. Het is een routine: minimaliseren wat je invoert, slim redactiewerk, en continu beseffen dat prompts en outputs kunnen worden gelogd. Als je één toetsvraag wilt onthouden: “Als dit in een auditlog of export belandt, kan ik dan uitleggen waarom dit nodig was en wie dit mag zien?” Als het antwoord ongemakkelijk is, is je prompt te rijk of je redactie te licht.

Belangrijkste takeaways:

• Schrijf prompts als een gecontroleerde samenvatting, niet als een dump van het dossier; voeg guardrails toe om aannames te voorkomen.

• Redactie is breder dan namen weghalen: doorbreek het mozaïek-effect met bandbreedtes, periodes en categorieën.

• Logging is zowel bescherming als risico: contentlogs kunnen een nieuwe opslagplek worden voor klantdata en interne beoordelingen.

Next, we'll build on this by exploring Vendor- en compliancekaders (GDPR/DORA) [20 minutes].