Waarom privacy begint voordat je prompt wordt verstuurd

AI in maatwerksoftware: wat komt er écht bij kijken?

AI gebruiken voelt vaak laagdrempelig.

Je typt een vraag, plakt wat context in het venster en krijgt direct een bruikbaar antwoord terug. Voor losse experimenten is dat handig. Maar zodra AI onderdeel wordt van bedrijfssoftware, klantportalen, dossiers of interne processen, ontstaat er een belangrijke vraag: welke informatie stuur je eigenlijk naar het AI-model?

Die vraag wordt vaak te laat gesteld.

Veel aandacht gaat uit naar wat AI teruggeeft: klopt het antwoord, is het bruikbaar, is het volledig? Maar privacy begint eerder. Niet bij de output, maar bij de input.

Voordat een prompt wordt verstuurd, moet al duidelijk zijn welke data erin zit, waar die data naartoe gaat, of die data daar wel naartoe mag en hoe je achteraf kunt aantonen wat er is gebeurd.

Binnen ons R&D-traject NoardCode AI Gateway onderzoeken we daarom hoe privacy, data-integriteit en beveiliging onderdeel kunnen worden van de AI-verwerkingsketen zelf. In het projectplan wordt dit beschreven als onderzoek naar onder andere een lokaal draaiende LLM-firewall, een geautomatiseerde anonimisatielaag, validatie, versleuteling, auditfuncties en logging.

Een prompt is ook data

Een prompt wordt vaak gezien als een simpele vraag aan AI. Maar in zakelijke software is een prompt meestal veel meer dan dat.

Een prompt kan bestaan uit:

• een vraag van een gebruiker;
• gegevens uit een klantdossier;
• interne notities;
• documenten of bijlagen;
• persoonsgegevens;
• financiele gegevens;
• contractafspraken;
• projectinformatie;
• technische foutmeldingen;
• context uit een database;
• eerdere conversatiegeschiedenis.

Met andere woorden: een prompt is niet zomaar tekst. Het is een samengesteld datapakket.

En precies daarom moet je een prompt behandelen als onderdeel van je dataverwerking. Zeker wanneer de prompt informatie bevat die bedrijfsgevoelig, privacygevoelig of klantgebonden is.

De vraag is dus niet alleen: "Welk antwoord willen we van AI?" Maar ook: "Welke informatie geven we AI om dat antwoord te kunnen maken?"

Niet alles hoort naar een extern model

Veel AI-toepassingen werken met externe modellen. Dat is logisch: ze zijn krachtig, goed beschikbaar en eenvoudig te koppelen via API's.

Maar niet alle informatie is geschikt om zomaar naar een externe AI-dienst te sturen.

Denk aan:

• persoonsgegevens van klanten of medewerkers;
• medische of zorggerelateerde gegevens;
• financiele dossiers;
• juridische documenten;
• interne bedrijfsstrategieen;
• broncode;
• contracten;
• vertrouwelijke klantafspraken;
• data van minderjarigen;
• concurrentiegevoelige informatie.

Soms mag die informatie juridisch niet naar buiten. Soms wil je het bedrijfsmatig niet. En soms wil je eerst precies weten welke delen van de informatie wel of niet nodig zijn.

Daarom begint privacy voordat de prompt wordt verstuurd.

Een goede AI-integratie moet kunnen bepalen welke data lokaal blijft, welke data geanonimiseerd kan worden en welke data eventueel veilig naar een extern model mag.

Het risico van gemak

Het gevaar van AI zit deels in het gemak.

Omdat AI zo toegankelijk is, is de verleiding groot om snel informatie te kopieren en te plakken. Een foutmelding met klantdata. Een dossier met namen en adressen. Een contractpassage. Een Excel-export. Een e-mailthread.

Voor individuele gebruikers is dat begrijpelijk. Ze willen snel geholpen worden.

Maar voor organisaties kan dit risico's opleveren. Niet omdat medewerkers onzorgvuldig willen zijn, maar omdat de software onvoldoende vangrails biedt.

Als je AI integreert in een applicatie, moet je die vangrails dus inbouwen.

Niet door gebruikers voortdurend te waarschuwen met lange juridische teksten, maar door technisch te voorkomen dat gevoelige informatie onnodig wordt meegestuurd.

Privacy by design in AI-integratie

Bij privacyvriendelijke AI-integratie moet je niet achteraf controleren of er iets misging. Je moet de verwerkingsketen vooraf goed ontwerpen.

Dat betekent onder andere:

• dataminimalisatie toepassen;
• gevoelige velden herkennen;
• persoonsgegevens maskeren of verwijderen;
• prompts valideren voor verzending;
• duidelijke regels instellen voor lokale of externe verwerking;
• logging bijhouden;
• rechten en rollen respecteren;
• output controleren voordat die wordt opgeslagen of getoond.

Dit sluit aan bij het principe van privacy by design: privacy is geen losse juridische laag achteraf, maar een ontwerpkeuze in de techniek.

Voor AI is dat extra belangrijk, omdat prompts dynamisch zijn. Ze worden vaak samengesteld uit meerdere bronnen en kunnen per gebruiker, vraag of context verschillen.

Anonimiseren voordat AI meeleest

Een belangrijke technische maatregel is anonimisering of pseudonimisering voordat een prompt naar een AI-model gaat.

Stel dat een AI-model moet helpen met het samenvatten van een klantvraag. Daarvoor hoeft het model misschien niet te weten dat de klant Jan de Vries heet, op een specifiek adres woont en klantnummer 18472 heeft.

De prompt kan vaak prima werken met neutrale aanduidingen zoals de klant, organisatie A, contactpersoon 1, factuur X of project Y.

Daarmee blijft de inhoudelijke context bruikbaar, terwijl gevoelige details niet worden gedeeld.

Maar dit moet zorgvuldig gebeuren. Te veel anonimiseren kan context wegnemen. Te weinig anonimiseren kan privacyrisico's opleveren.

Daarom is anonimisering geen simpele zoek-en-vervang-actie. Het vraagt om herkenning van datatypes, context en doel van de AI-taak.

Een lokale LLM als controlelaag

Binnen de NoardCode AI Gateway onderzoeken we het idee van een lokale LLM-firewall.

Dat betekent: een lokaal draaiend AI-model of controlemechanisme dat prompts beoordeelt voordat ze eventueel naar een extern AI-model worden gestuurd.

Zo'n controlelaag kan bijvoorbeeld helpen om persoonsgegevens te herkennen, vertrouwelijke informatie te markeren, gevoelige passages te anonimiseren, prompts te blokkeren wanneer ze niet voldoen aan beleid, te bepalen of lokale verwerking verplicht is, output te controleren voordat die teruggaat naar de gebruiker en logging te maken van wat is aangepast, verwijderd of doorgelaten.

Je kunt het zien als een poortwachter voor AI-verkeer.

Niet elke prompt hoeft door dezelfde route. Een algemene vraag kan misschien prima naar een extern model. Een prompt met gevoelige klantinformatie moet misschien lokaal blijven of eerst worden opgeschoond.

Beleid vertalen naar techniek

Veel organisaties hebben privacybeleid. Maar bij AI is de uitdaging om dat beleid technisch afdwingbaar te maken.

Een beleidsregel kan bijvoorbeeld zijn: persoonsgegevens mogen niet naar externe AI-modellen worden gestuurd.

Maar hoe weet de software of een prompt persoonsgegevens bevat? Wat gebeurt er als een document meerdere soorten data bevat? Wie bepaalt of een uitzondering is toegestaan? Hoe wordt dit vastgelegd? Wat gebeurt er als de AI-output opnieuw gevoelige informatie bevat?

Daarom moet privacybeleid worden vertaald naar technische regels.

Bijvoorbeeld:

• deze datatypes mogen nooit extern verwerkt worden;
• deze klantcategorieen mogen alleen lokaal worden verwerkt;
• deze rollen mogen AI gebruiken op bepaalde dossiers;
• deze prompts moeten altijd worden geanonimiseerd;
• deze output mag niet automatisch worden opgeslagen;
• deze acties moeten altijd gelogd worden.

Zo ontstaat een policy-engine rondom AI-verwerking.

Logging: kunnen aantonen wat er is gebeurd

Privacy gaat niet alleen over voorkomen. Het gaat ook over aantoonbaarheid.

Als een organisatie AI gebruikt, wil je achteraf kunnen reconstrueren: welke gebruiker de AI-taak heeft gestart, welke gegevens zijn gebruikt, welke data is verwijderd of gemaskeerd, welk model is aangeroepen, of verwerking lokaal of extern was, welke output terugkwam, welke controles zijn uitgevoerd en welke foutmeldingen er waren.

Zonder logging wordt AI een black box.

Met goede logging wordt AI-verwerking controleerbaar. Dat is belangrijk voor interne kwaliteitscontrole, beveiliging, compliance en vertrouwen richting klanten.

Daarbij moet logging zelf natuurlijk ook veilig worden ingericht. Je wilt niet dat gevoelige informatie alsnog ongecontroleerd in logbestanden terechtkomt.

Data-integriteit: klopt de informatie wel?

Privacy gaat vaak over geheimhouding, maar binnen AI-integratie is data-integriteit minstens zo belangrijk.

Een AI-model moet werken met informatie die betrouwbaar, volledig en actueel is. Als de input vervuild, verouderd of onvolledig is, kan de output overtuigend maar verkeerd zijn.

Daarom onderzoeken we binnen dit project ook hoe de consistentie, volledigheid en vertrouwelijkheid van data kan worden gewaarborgd. Het projectplan benoemt hiervoor validatie- en versleutelingsmechanismen, audit- en loggingfuncties en reproduceerbaarheid van AI-interacties.

Voorbeelden van integriteitsvragen zijn: is deze bron nog actueel, hoort deze data bij de juiste klant, is het document definitief of concept, ontbreken er relevante velden, is informatie gewijzigd sinds de vorige AI-analyse, komt de output overeen met de meegegeven context en is de bron betrouwbaar genoeg voor deze taak?

Een privacyvriendelijke AI-integratie kijkt dus niet alleen naar wat er niet gedeeld mag worden, maar ook naar wat wel betrouwbaar genoeg is om te gebruiken.

Output kan ook privacygevoelig zijn

Veel aandacht gaat naar de prompt, maar de response verdient net zoveel aandacht.

Een AI-model kan in zijn antwoord gevoelige informatie herhalen, combineren of verkeerd samenvatten. Zeker wanneer het model werkt met dossiers, klantdata of interne kennis.

Daarom moet ook de output gecontroleerd worden.

Bijvoorbeeld: bevat het antwoord persoonsgegevens, wordt er informatie getoond die deze gebruiker niet mag zien, is het antwoord geschikt om op te slaan in het dossier, is bronverwijzing nodig, moet er een waarschuwing bij, mag de output automatisch worden doorgestuurd of is menselijke controle verplicht?

AI-output is dus geen neutrale tekst. Het is nieuwe verwerking van bestaande data.

Rechtenstructuren blijven leidend

Een AI-functie mag nooit meer toegang geven dan de gewone applicatie.

Als een gebruiker in een klantportaal alleen zijn eigen dossier mag zien, dan mag AI ook alleen op basis van dat dossier antwoorden. Als een medewerker geen toegang heeft tot financiele gegevens, mag AI die gegevens ook niet indirect gebruiken in een samenvatting.

Bij AI-integratie moet autorisatie op meerdere momenten worden toegepast: bij het ophalen van context, bij het samenstellen van de prompt, bij het kiezen van het model, bij het tonen van output, bij het opslaan van resultaten en bij het raadplegen van logs.

Daarmee wordt AI onderdeel van de bestaande security-architectuur in plaats van een losse bypass ernaast.

Wat betekent dit voor Laravel- en maatwerkapplicaties?

Voor Laravel-applicaties en maatwerksoftware ligt hier een belangrijk voordeel: veel rechten, datarelaties en workflows zijn al in de applicatie aanwezig.

Denk aan policies, gates, rollen en permissies, tenantstructuren, Eloquent-relaties, auditlogs, validatieregels, queues, encryptie, databasevelden met gevoelige informatie en bestaande businesslogica.

Een goede AI-integratie moet daarop aansluiten.

In plaats van AI buiten de applicatie om toegang te geven tot data, wil je AI laten werken binnen dezelfde regels als de rest van het systeem.

Dat betekent bijvoorbeeld: prompts samenstellen vanuit geautoriseerde data, gevoelige velden automatisch maskeren, AI-taken via queues verwerken, logging koppelen aan gebruikers en entiteiten, responses valideren voordat ze worden opgeslagen en per klant of tenant bepalen welke AI-route is toegestaan.

Privacy is ook vertrouwen

Voor organisaties is privacy niet alleen een juridische verplichting. Het is ook een vertrouwenskwestie.

Klanten, medewerkers en partners willen weten dat hun gegevens zorgvuldig worden behandeld. Zeker wanneer AI wordt ingezet, omdat er vaak onzekerheid bestaat over wat er met data gebeurt.

Een transparante AI-integratie kan dat vertrouwen versterken.

Door duidelijk te maken welke data wordt gebruikt, waarom die data nodig is, waar verwerking plaatsvindt, welke informatie wordt geanonimiseerd, hoe lang gegevens worden bewaard, welke controles zijn ingebouwd en wanneer menselijke controle nodig is.

AI hoeft geen black box te zijn. Maar dan moet privacy vanaf het begin worden meegenomen.

Wat onderzoeken we binnen de NoardCode AI Gateway?

Binnen de NoardCode AI Gateway onderzoeken we hoe een AI-infrastructuurlaag privacybewuster kan worden ingericht.

Daarbij kijken we onder andere naar lokale controle van prompts, automatische anonimisering, detectie van gevoelige data, validatie van input en output, versleuteling, audit trails, reproduceerbaarheid van AI-interacties, logging zonder onnodige datalekken, beleid voor lokale of externe verwerking en integratie met bestaande applicatierechten.

De centrale vraag is: hoe zorgen we dat AI alleen de informatie gebruikt die nodig, toegestaan en betrouwbaar is?

Dat is een technische vraag, maar ook een organisatorische. Want AI raakt aan softwarearchitectuur, security, privacybeleid en gebruikersvertrouwen.

Wat betekent dit voor organisaties?

Voor organisaties die AI willen inzetten, is het belangrijk om niet te beginnen met: welke AI-tool gaan we gebruiken?

Maar met: welke data willen we wel en niet door AI laten verwerken?

Daarna volgen pas de technische keuzes: welke informatie extern mag worden verwerkt, welke informatie lokaal moet blijven, welke velden gemaskeerd moeten worden, wie AI op welke data mag gebruiken, welke output gecontroleerd moet worden, welke logging nodig is en welke risico's niet acceptabel zijn.

Als die vragen niet vooraf worden beantwoord, ontstaat het risico dat AI sneller wordt ingevoerd dan de organisatie kan beheersen.

Wat leren we hiervan?

De belangrijkste les is dat privacy bij AI niet begint bij een privacyverklaring of gebruikerswaarschuwing.

Privacy begint in de architectuur.

Bij het ophalen van data. Bij het samenstellen van prompts. Bij het anonimiseren van gevoelige informatie. Bij het kiezen tussen lokaal en extern verwerken. Bij het loggen van acties. Bij het controleren van output.

Wie AI veilig wil inzetten, moet dus niet alleen nadenken over het model, maar over de volledige dataroute rondom het model.

Tot slot

AI kan veel waarde toevoegen aan bedrijfssoftware. Maar alleen als organisaties grip houden op hun data.

Daarom begint privacy voordat een prompt wordt verstuurd.

Binnen de NoardCode AI Gateway onderzoeken we hoe AI-integratie veiliger en controleerbaarder kan worden gemaakt met lokale controlelagen, anonimisering, validatie, logging en duidelijke verwerkingsregels.

In de volgende blog gaan we hier dieper op door met een concreet concept uit ons onderzoek: de lokale LLM-firewall als controlelaag tussen bedrijfsdata en AI-modellen.