Grip op wat er naar AI gaat: de AI-poort van Plainwater AI
Bram, de controller van een groothandel in technische onderdelen, wil weten waarom de marge per productgroep daalt. Noor, de data-engineer, wil daar een AI-model bij inzetten. De vraag van de directie is kort: wat ziet dat model van onze data?
Plainwater AI beantwoordt die vraag met een poort. Elk verzoek aan een model loopt erdoorheen, en elk verzoek krijgt precies één beleidsbesluit. Wat de regels niet toestaan, bereikt de modelleverancier nooit.
Op deze pagina lees je hoe die poort werkt: pseudoniemen voor namen, standen per databron, uitzonderingen per kolom en een audit achteraf.
Bijgewerkt .
Wat is de AI-poort?
De AI-poort is het ene punt waar elk verzoek aan een AI-model doorheen gaat, met per verzoek één beleidsbesluit. Dat besluit toetst het gekozen model, het budget en de regels van de klant voordat er iets vertrekt.
Regels staan daarmee in de poort en niet in een prompt. Een instructie als 'deel geen persoonsgegevens' kan een model negeren. Een poort die het verzoek tegenhoudt, kan het model niet omzeilen.
Voor Noor betekent dat: ze kiest een model dat de groothandel heeft toegestaan, en de poort controleert bij elk verzoek opnieuw of dat nog klopt. Een geweigerd verzoek komt niet bij de leverancier aan.
Hoe werken pseudoniemen voor tabel- en kolomnamen?
Pseudonimisering vervangt tabel- en kolomnamen door neutrale codes voordat ze naar het model gaan, en vertaalt het antwoord terug voor de mens. Het model ziet `t_0056`, Bram leest `Salarissen`.
Een objectnaam is ook data. Een tabel die `Ontslagen_2026` heet, vertelt een model al veel zonder dat er één rij meegaat. Daarom gaan namen standaard als pseudoniem de deur uit.
Het terugvertalen werkt ook voor namen die de agent zelf bedenkt. Bouwt hij een view `vw_t_0056_monitor`, dan leest Noor op haar scherm de echte naam met `monitor` erachter.
Een klant met echte klantdata werkt alleen met actieve pseudonimisering. Staat die niet aan, dan start de agent niet, en ook tijdens het werk controleert de poort dat bij elke stap opnieuw.
Welke standen van datatoegang zijn er?
Per databron kies je een van drie standen: alleen metrics, versleutelde waarden of open. De stand bepaalt of en hoe waarden uit de bron het model bereiken.
De strengste van klantregel en bronregel wint altijd. Een bron kan nooit ruimer staan dan de klant. Zet de groothandel alles op versleuteld, dan blijft een bron op open toch versleuteld.
| Stand | Wat het model krijgt | Wanneer je hem kiest |
|---|---|---|
| Alleen metrics | Metadata, tellingen en statistieken; geen rijen | Standaard; genoeg voor modelleren, kwaliteit en performance |
| Versleutelde waarden | Elke cel als stabiel token; joinen en tellen kan | Analyse waarbij de AI patronen moet zien, maar geen waarden |
| Open | Letterlijke waarden | Alleen op bronnen die de klant daar expliciet voor aanwijst |
Kun je per tabel of kolom strenger zijn?
Ja, per tabel of kolom leg je uitzonderingen vast die altijd gelden, ongeacht de stand van de bron. Naamkolommen zet je bijvoorbeeld standaard op verbergen.
Daarnaast geldt een cohortdrempel: tellingen onder tien worden `<10`. Zo herleidt niemand via een telling van drie medewerkers op één afdeling wie er ziek was.
Bram hoeft die regels niet zelf te onthouden. Ze staan op de bron, en de poort past ze toe bij elk verzoek van elke collega en elke agent.
Wat kun je achteraf terugzien?
Alle prompts en antwoorden worden versleuteld bewaard en zijn terug te lezen door wie daar recht op heeft. Elke inzage wordt zelf ook gelogd.
Per klant leg je richtlijnen vast. Het platform toetst opdrachten achteraf tegen de regels die golden toen de opdracht begon. Wat niet automatisch te controleren valt, krijgt het oordeel mens nodig en nooit het oordeel geslaagd.
Een bevinding noemt de regel, het oordeel en de plek waar het gebeurde. De tekst die de regel raakte, staat er niet in: een audit mag zelf geen lek worden.
Waar het ophoudt
De poort bewaakt wat het platform verstuurt. Wat een medewerker zelf in een andere chatdienst plakt, valt erbuiten; daarvoor blijft beleid binnen je organisatie nodig.
Pseudoniemen beschermen namen en waarden die het platform kent. Vrije tekst die een mens in een gesprek typt, gaat als tekst mee; de poort veegt daar wel bekende namen uit.
Werkt een consultant met zijn eigen AI-tool via MCP, dan draait het model buiten het platform. De bewaking zit dan op de tools: wat het model krijgt, gaat nog steeds door dezelfde regels.
Veelgestelde vragen
Stuurt Plainwater AI rijen uit mijn database naar een AI-model?
Niet in de standaardstand. Onder alleen metrics krijgt het model metadata, tellingen en statistieken. Rijen gaan alleen mee onder versleuteld (als tokens) of open (letterlijk), en open alleen op bronnen die je daar zelf voor aanwijst.
Wat gebeurt er als een verzoek niet aan de regels voldoet?
Dan weigert de poort het verzoek voordat het de modelleverancier bereikt. Het besluit wordt vastgelegd, zodat je later ziet wat er geweigerd is en waarom.
Kan een model de regels omzeilen met een slimme prompt?
Nee. De regels zijn handhaving in de poort, geen instructie in de prompt. Wat het model vraagt of schrijft, verandert niets aan wat de poort doorlaat.
Ziet het model de echte namen van mijn tabellen?
Bij een klant met echte klantdata niet: tabel- en kolomnamen gaan als pseudoniem mee. Het platform vertaalt het antwoord terug, zodat jij de echte namen leest.
Wie kan de bewaarde prompts en antwoorden lezen?
Alleen wie daar het recht voor heeft. De opslag is versleuteld, en elke inzage wordt zelf als gebeurtenis in de audit vastgelegd.