Hoe bouw je privacy-first AI voor gevoelige data?

De meeste AI-demo's gaan over data die niemand kan schaden: openbare teksten, marketingcopy, code. Maar zodra de input persoonlijk wordt — medische klachten, juridische dossiers, een dagboek, een droom — verandert de vraag. Dan gaat het niet meer over "wat kan AI", maar over "wat mag AI, en wat moet het juist níét doen".

Ik bouwde een product dat precies op die grens zit: Dreamalizing, een AI die mensen hun dromen laat verkennen. Droominhoud is zo'n beetje de meest persoonlijke input die bestaat. Juist daarom is het een scherpe testcase voor een vraag die elke organisatie die AI op gevoelige data wil inzetten tegenkomt: hoe houd je AI bruikbaar én veilig?

Het probleem

Bij gevoelige data lopen twee eisen tegen elkaar in:

• AI moet bruikbaar zijn — anders is het een leeg tekstveld
• AI mag nooit doen alsof het de waarheid kent — geen valse zekerheid, geen diagnose, geen claims die het niet kan onderbouwen

Een naïef product kiest één kant: óf een stellige "oracle" die zekerheid faket, óf een onschuldig opslagveld zonder waarde. Beide zijn fout. En dan is er nog de hardste eis: de data zelf mag niet lekken, niet naar derden, niet naar een groot AI-platform, niet naar een audit-log waar het niet thuishoort.

De oplossing: behandel AI als een systeem, niet als een feature

Privacy-first AI ontstaat niet door één instelling, maar door een reeks bewuste keuzes. Dit zijn de zes die ik in Dreamalizing maakte — en die net zo goed gelden voor een zorg-, juridische of HR-context:

1. Guided exploration in plaats van black-box output. De AI interpreteert niet, maar stelt gerichte vragen. De gebruiker blijft de autoriteit. Dat is geen UX-keuze maar een veiligheidskeuze: een model dat vragen stelt, kan minder onzin als waarheid presenteren.

2. Bounded AI met grenzen in het systeem. Geen therapie, geen diagnose, geen medische claims. Die grenzen zitten niet in een disclaimer onderaan, maar in de prompts, de guardrails en de evaluatie — afdwingbaar, niet cosmetisch.

3. Versleutelde opslag op eigen infra. Gevoelige input wordt versleuteld opgeslagen (AES-256-GCM, sleutel per gebruiker) op eigen infrastructuur — niet standaard bij een grote cloudpartij.

4. Lokale inferentie. De taalmodellen draaien lokaal, afgedwongen via configuratie. Gevoelige input gaat dus niet standaard naar een externe AI-dienst. Dat is het verschil tussen "we beloven privacy" en "het kán technisch niet anders".

5. Opt-in, geen opt-out. Patroonherkenning over meerdere invoer heen gebeurt alleen als de gebruiker daar bewust voor kiest. De standaard is: zo min mogelijk.

6. Verwijderbaar en herleidbaar. Een verwijderverzoek wist data ook echt volledig (AVG), en de keten is auditeerbaar — je kunt achteraf aantonen wat er met de data is gebeurd.

Waarom dit verder gaat dan een droomapp

De droom is hier het extreme voorbeeld, maar de principes zijn generiek. Context als waarheid (RAG op eigen bronnen), meetbaarheid (kwaliteit, kosten, latency als metrics), governance (rollen, logging, policies) en duidelijke grenzen — dat is precies de aanpak waarmee ik AI naar productie breng in klanttrajecten rond AI in productie.

Het verschil tussen een AI-pilot die blijft hangen en een AI-systeem dat draait, zit zelden in het model. Het zit in de vraag of je de gevoelige data, de grenzen en de herleidbaarheid net zo serieus neemt als het slimme antwoord.

Wil je AI inzetten op data die er echt toe doet?