Een developer plakt een connection string in ChatGPT om een configuratieprobleem te debuggen. Een collega kopieert een stuk klantdata naar een AI-tool “even om de mapping te testen.” Weer iemand anders deelt een intern API-contract om sneller clientcode te genereren.

Herkenbaar? Waarschijnlijk wel. Risicovol? Absoluut.

Geen van deze mensen had slechte bedoelingen. Ze probeerden gewoon hun werk te doen. Maar in de haast om productief te zijn deelden ze dingen die het pand nooit hadden mogen verlaten.

Het probleem: waar gaat je input naartoe?

Als je een prompt typt in een AI-tool, verdwijnt je input niet na het antwoord. Afhankelijk van de dienst kan het worden opgeslagen, gelogd, of zelfs gebruikt om toekomstige modellen te trainen. De meeste diensten zijn hier transparant over in hun voorwaarden — maar laten we eerlijk zijn, wie leest die?

De kernvraag is niet “is deze AI-tool goed?” Het is: waar komt mijn input terecht, en wie kan erbij?

Voor tools die op je eigen infrastructuur draaien is het antwoord simpel. Voor externe diensten ligt het genuanceerder. Sommige aanbieders hebben enterprise-plannen waarbij je data niet voor training wordt gebruikt. Anderen maken dat onderscheid niet. En zelfs als ze het wel doen — data reist nog steeds over het internet, wordt opgeslagen op hun servers, en valt onder hun securitybeleid.

Dit betekent niet dat je geen externe AI-tools moet gebruiken. Het betekent dat je moet nadenken over wat je erin stopt.

Wat je NOOIT moet delen

De lijst is korter dan je denkt, maar de gevolgen als het misgaat zijn serieus:

  • Credentials: API-keys, connection strings, wachtwoorden, tokens. Niet “even snel” om iets te debuggen. Strip ze er eerst uit.
  • Klantdata: Namen, e-mailadressen, financiële gegevens, gezondheidsdata — alles wat herleidbaar is tot een persoon of onder de AVG valt.
  • Productiedata: Echte database-exports, logbestanden met gebruikersinformatie, interne systeemconfiguraties.
  • Bedrijfsgeheimen: Eigen algoritmes, nog niet uitgebrachte productdetails, interne strategiedocumenten.

De rode draad: als het een probleem zou zijn wanneer het opduikt in een datalekmelding, plak het dan niet in een externe AI-tool.

Wat je WEL veilig kunt delen

Het goede nieuws: er is genoeg dat je zonder risico kunt delen.

  • Publieke code en open-source patronen: Alles wat al op GitHub staat of in openbare documentatie.
  • Generieke architectuurvragen: “Hoe implementeer ik het mediator-pattern in .NET?” geeft niets gevoeligs prijs.
  • Foutmeldingen — zolang je de gevoelige context eruit haalt. NullReferenceException op regel 42 in OrderService.cs is prima. Dezelfde fout met een volledige stacktrace inclusief klant-ID’s is dat niet.
  • Testdata en mock-objecten: Synthetische data die je hebt gemaakt voor testdoeleinden.
  • Algemene best practices: Vragen over design patterns, coderingconventies, of framework-gebruik.

De vuistregel: zou je dit zonder nadenken op Stack Overflow posten? Dan is het ook prima voor een AI-tool.

Het kernprincipe: jij bent verantwoordelijk

Ik heb een AI-richtlijnendocument geschreven voor mijn team, en de openingszin zegt alles:

AI is een hulpmiddel, geen verantwoordelijke. Wanneer werk wordt opgeleverd, is AI daar niet verantwoordelijk voor. De verantwoordelijkheid ligt altijd bij degene die het werk maakt, reviewt en incheckt.

Dit komt neer op vier regels:

1. Jij reviewt alles. Code, tests, documentatie — alles wat AI genereert moet door jou worden gecontroleerd voor het wordt gecommit. Inclusief checken op per ongeluk meegenomen secrets.

2. Jij begrijpt wat je commit. Check nooit code in die je niet kunt uitleggen. Als AI iets genereert dat je niet begrijpt, vraag om uitleg of schrijf het zelf.

3. Jij test het resultaat. AI-gegenereerde tests moeten ook gevalideerd worden. Een groene test suite betekent niets als de tests niet daadwerkelijk het juiste gedrag controleren.

4. Jij bent de eigenaar. Op het moment dat je op “commit” drukt, is het jouw werk. Niet van AI, niet van een collega. Als er een bug in productie zit, is “maar AI schreef het” geen acceptabel antwoord.

Governance in een team: maak het expliciet

Individueel bewustzijn is goed. Maar in een team heb je gedeelde afspraken nodig. Want de developer die per ongeluk een connection string deelt is niet onzorgvuldig — die heeft gewoon nooit het gesprek gehad over wat wel en niet mag.

Dit werkt:

Schrijf de regels op. Documenteer wat wel en niet gedeeld mag worden met AI-tools. Houd het kort — een bulletlijst is genoeg. Zet het ergens waar iedereen het ziet: je wiki, je onboardingdocs, of je CLAUDE.md.

En nu we het daarover hebben — als je Claude Code gebruikt, is je CLAUDE.md dé plek voor “doe dit niet”-regels. Dingen als:

## Security
- Nooit API-keys, connection strings of secrets in prompts opnemen
- Geen echte klantdata verwerken — gebruik test fixtures uit /tests/fixtures/
- Persoonsgegevens uit error logs strippen voor je ze deelt

Claude leest dit bestand aan het begin van elke sessie. Het is niet alleen documentatie — het is actieve context die bepaalt hoe de AI met je codebase werkt.

Praat erover. Heb een gesprek van tien minuten in je volgende retro of standup. Niet om mensen bang te maken, maar om een gedeeld begrip te creëren. “Wat vinden we oké om te delen met AI-tools?” Die ene vraag levert meer edge cases op dan welk beleidsdocument ook.

Review erop. Voeg “geen secrets in AI-prompts” toe aan je code review checklist. Check .env-bestanden, check commit history op per ongeluk gecommitte credentials. Dit is goed practice ongeacht AI — maar AI maakt het urgenter.

Het gaat niet om angst

Ik wil helder zijn: dit is geen argument tegen het gebruik van AI-tools. Ik gebruik ze elke dag. Ze maken me sneller, ze vangen dingen die ik mis, en ze zijn oprecht nuttig om problemen door te denken.

Maar “nuttig” en “standaard veilig” zijn niet hetzelfde. AI-tools weten niet wat vertrouwelijk is in jouw context. Ze weten niet dat de database-URL die je net plakte productiecredentials bevat. Ze weten niet dat de JSON-blob die je debugt echte e-mailadressen van klanten bevat.

Jij wel. Dat is het punt.

Governance gaat niet over beperken wat je mag doen. Het gaat over weten wat je doet. Het is het verschil tussen hard rijden omdat je de weg kent, en hard rijden omdat je niet oplet.

Begin hier

Als je nog geen AI-governance hebt in je team, zijn hier drie dingen die je vandaag kunt doen:

  1. Maak een “nooit delen”-lijst. Vijf minuten, vijf bullets. Credentials, klantdata, productieconfiguraties, tokens, bedrijfsgeheimen. Pin het in je teamkanaal.

  2. Check je CLAUDE.md (of vergelijkbare config). Voeg een securitysectie toe met de regels waar je AI-tools zich aan moeten houden. Kost twee minuten en werkt vanaf dag één.

  3. Stel de vraag. In je volgende teamoverleg: “Wat vinden we oké om te delen met AI-tools?” Je zult verbaasd zijn hoeveel mensen hetzelfde hebben afgevraagd maar het niet hebben aangekaart.

AI governance klinkt groot en corporate. Dat hoeft het niet te zijn. Het begint met één gesprek en een paar duidelijke regels. De tools zijn krachtig — zorg dat je ze gebruikt met je ogen open.