Welke beveiliging moet je geregeld hebben voordat AI live gaat?

Beveiliging is de stap die het vaakst blijft liggen. Niet omdat ondernemers hem onbelangrijk vinden, maar omdat er geen moment is waarop iemand zegt: nu is het genoeg. Bij een grondslag of een verwerkersovereenkomst weet je wanneer je klaar bent. Bij beveiliging staat er in de wet geen enkele concrete maatregel. Er staat alleen dat het niveau moet passen bij het risico.

Dat is geen slordigheid maar een keuze. En het betekent dat de vraag "wat moet ik geregeld hebben voordat de AI live gaat" alleen te beantwoorden is door zelf te kijken wat er in jouw situatie mis kan gaan. Hieronder staat hoe je dat doet zonder securityafdeling, wat er praktisch bij AI-klantcontact hoort, en waar de grens ligt tussen jouw werk en dat van je leverancier.

Waarom staat er nergens een lijst met verplichte maatregelen?

Artikel 32 AVG heet "Beveiliging van de verwerking" en dat is precies wat je zou verwachten: een opsomming van wat je moet installeren. Die opsomming staat er niet. De wettekst begint met "rekening houdend met de stand van de techniek, de uitvoeringskosten, alsook met de aard, de omvang, de context en de verwerkingsdoeleinden" en met de risico's voor de rechten en vrijheden van personen. Daarna volgt de opdracht: neem passende technische en organisatorische maatregelen om een op het risico afgestemd beveiligingsniveau te waarborgen.

De Autoriteit Persoonsgegevens zegt het in gewone taal: elke organisatie die persoonsgegevens verwerkt moet zelf bepalen welke maatregelen nodig zijn, en daarvoor eerst bekijken welke risico's de verwerking met zich meebrengt. Er is dus geen afvinklijst van de toezichthouder waarachter je kunt schuilen. Maar er is ook geen norm die je bedrijf niet aankan: het niveau schaalt mee met het risico, niet met de omvang van het bedrijf.

Twee dingen volgen daaruit die vaak verkeerd begrepen worden. Het eerste: een klein bedrijf mag minder uitgeven aan beveiliging, want de uitvoeringskosten staan letterlijk in de wettekst als factor. Maar dat is een weging, geen vrijbrief — als het risico hoog is, weegt kosten licht. Het tweede: het risico dat je moet wegen is de schade voor de mensen van wie de gegevens zijn, niet de schade voor jou. Een lek van tweehonderd chatgesprekken over een verstopte afvoer is iets anders dan een lek van tweehonderd gesprekken over een medische klacht, ook al is het bedrijf even groot.

Wat betekent "passend" als je met een handvol mensen werkt?

Passend betekent: je hebt gekeken, je hebt gekozen, en je kunt uitleggen waarom. Voor een klein bedrijf past dat op één vel papier. Vijf vragen zijn genoeg. Wat kan er misgaan met deze gesprekken? Hoe erg is dat voor de klant? Hoe waarschijnlijk is het? Wat doen we ertegen? Wat blijft er over aan risico, en vinden we dat acceptabel?

Wat AI hier verandert, is niet de zwaarte van de eisen maar het aantal plekken waar klantgegevens terechtkomen. Vóór de AI had je meestal één plek: het postvak of de telefoon. Zodra er een AI-assistent draait, zijn dat er al snel vier. De gesprekken zelf, in het systeem van de leverancier. De doorzoekbare kennisbron waar de AI antwoorden uit haalt, waar vaak stukken uit oude gesprekken in zijn opgenomen. De logbestanden van wat er gevraagd en geantwoord is. En de omgeving van de partij die het taalmodel levert. Elke kopie is een plek waar het mis kan gaan, en elke kopie hoort in je afweging genoemd te worden.

Er is nog een verschil met gewone software. Een AI-assistent doet iets uit zichzelf: hij leest binnenkomende berichten en hij stuurt berichten terug. Dat betekent dat een fout niet stil blijft staan maar naar buiten gaat, naar een klant. Beveiliging gaat hier dus niet alleen over binnenkomen, maar ook over wat er ongecontroleerd naar buiten kan.

Wie kan er eigenlijk bij de gesprekken?

Toegangsbeheer is de maatregel met de beste verhouding tussen moeite en effect, en tegelijk de maatregel die in kleine bedrijven het slechtst geregeld is. De klassieke zwakke plek is de gedeelde inlog: één account waar het hele team mee werkt, met een wachtwoord dat in een groepsapp is gedeeld. Zolang dat zo is, kun je na een incident nooit vaststellen wie wat heeft gezien, en kun je bij vertrek van een medewerker niet één toegang intrekken zonder iedereen te storen.

Er zijn vier groepen die bij de gesprekken kunnen, en je moet ze alle vier apart langsgaan.

• Je eigen mensen. Persoonlijke accounts, tweefactorinlog, en rechten per rol. Een vakantiekracht die klantvragen afhandelt hoeft geen exportknop te hebben.
• De AI zelf. Dit is de nieuwe vraag. Een medewerker zoekt één klant op; een AI-assistent heeft een staande verbinding met alles waar je hem op aansluit. Begrens dat: alleen lezen waar lezen genoeg is, alleen de velden die nodig zijn voor het antwoord, en niet standaard toegang tot mappen of tabellen waar hij alleen "voor de zekerheid" bij kan.
• Mensen bij de leverancier. Support- en beheerders bij je leverancier kunnen technisch vrijwel altijd bij je gegevens. Dat hoeft geen probleem te zijn, maar het hoort geen verrassing te zijn. Vraag op schrift wie dat kan, wanneer ze dat doen, en of jij dat achteraf kunt zien.
• De plek waar escalaties landen. Als de AI het niet weet, gaat het gesprek naar een mens. Die doorgestuurde gesprekken belanden in een gedeeld postvak, een appgroep of een privételefoon. Dat is bijna altijd de slechtst beveiligde kopie van het hele traject, en hij wordt bij de beoordeling stelselmatig vergeten.

Welke maatregelen passen specifiek bij AI-klantcontact?

De onderstaande maatregelen zijn geen wettelijke voorschriften — die bestaan zoals gezegd niet. Het is een vertaling van de risico's die bij deze manier van werken horen naar iets wat je op een dinsdagmiddag kunt regelen. Wat er voor jou wel of niet bij hoort, hangt af van je eigen afweging.

Maatregelen en waarom ze passen bij AI in klantcontact

Maatregel	Waarom hij hier past
Persoonlijke accounts met tweefactorinlog	Zonder herleidbare accounts is achteraf niet vast te stellen wie een gesprek heeft gelezen of geëxporteerd. Dat maakt elk onderzoek na een incident onmogelijk.
Begrensde leesrechten voor de AI	De assistent zoekt sneller en breder dan een mens. Wat hij mag inzien, kan hij in een antwoord laten belanden — ook bij de verkeerde klant.
Gescheiden kennisbron voor interne stukken	Inkoopprijzen, personeelsafspraken en interne notities horen niet in de bron waar de klantassistent uit put, ook al staan ze in dezelfde map.
Versiebeheer op instructies en kennisbron	Als de assistent ineens iets anders zegt, moet je kunnen zien wie wat wanneer heeft gewijzigd. Zonder dat is een fout niet terug te draaien en niet te verklaren.
Limiet op uitgaande berichten	Een fout in een geautomatiseerd systeem herhaalt zich in seconden. Een bovengrens per uur zet een dak op de schade voordat iemand het merkt.
Een uitknop die iedereen kan bedienen	Als het alleen de leverancier of één technisch iemand kan stoppen, loopt het door tijdens een weekend of een vakantie.
Testen zonder echte klantgegevens	Proefopstellingen en demo's leven langer dan bedoeld en zijn zelden even goed beveiligd als de echte omgeving.
Beveiliging van het apparaat met de koppeling	Loopt het klantkanaal via een telefoon, dan is die telefoon onderdeel van je beveiliging. Een toestel zonder schermslot is een open postvak.
Afgesproken herstelpad	Een back-up die nooit is teruggezet, is een aanname. Weten hoe je binnen een dag weer verder kunt, hoort bij het niveau dat je claimt.

Wat moet je loggen — en wat juist niet?

Loggen is wat de rest van je maatregelen controleerbaar maakt. Zonder logbestand blijft het bij "wij denken dat er niemand bij kon". Dat is geen onderbouwing, en bij een incident is het ook geen startpunt: je kunt dan niet vaststellen hoeveel gesprekken zijn ingezien, door wie, en vanaf wanneer.

Er zijn twee soorten logs en dat onderscheid is belangrijk, omdat ze in tegengestelde richting werken. Een handelingslog registreert wie wat wanneer deed. Een inhoudslog bewaart wat er in het gesprek stond. Het eerste wil je bewust vergroten, het tweede bewust verkleinen.

Wat in een handelingslog thuishoort bij AI-klantcontact:

• inloggen en mislukte inlogpogingen, met tijdstip en account;
• exporteren en downloaden van gesprekken — dit is de handeling waarmee gegevens je systeem verlaten;
• wijzigingen aan de instructies van de assistent en aan de kennisbron waaruit hij put;
• koppelingen die worden toegevoegd of aangezet, inclusief wie dat deed;
• aantallen verzonden berichten per uur of per dag, zodat een uitschieter opvalt.

Wat je juist niet wil, is dat de volledige gesprekstekst ook nog eens in een tweede systeem terechtkomt dat niemand beheert. Veel koppelingen sturen standaard het hele bericht mee naar een foutopsporingsdienst of een monitoringtool. Zet dat uit of kort het in. Bijlagen, betaalgegevens en toevallig ingetypte wachtwoorden horen sowieso niet in een log.

Twee dingen die hierbij horen en makkelijk vergeten worden. Logbestanden zijn zelf ook persoonsgegevens, dus ze hebben net zo goed een bewaartermijn en beperkte toegang nodig. En een log die niemand leest, helpt pas achteraf. Zet er minstens één signaal op dat vanzelf bij je binnenkomt — bijvoorbeeld een bericht wanneer het aantal uitgaande berichten door het afgesproken plafond gaat.

Val je onder NIS2, en hoe stel je dat vast?

Rond NIS2 wordt veel verkocht aan bedrijven die er helemaal niet onder vallen. De toets is eenvoudiger dan de marketing suggereert. Artikel 2 van de NIS2-richtlijn stelt twee filters die allebei moeten kloppen: je organisatie is van een type dat in bijlage I of II van de richtlijn staat, én je komt in aanmerking als middelgrote onderneming volgens de EU-definitie in Aanbeveling 2003/361/EG. Het Nationaal Cyber Security Centrum vat het net zo samen: sector en grootte bepalen samen of een organisatie eronder valt.

In Nederland is de richtlijn uitgewerkt in de Cyberbeveiligingswet, die per 15 augustus 2026 van kracht is en de Wet beveiliging netwerk- en informatiesystemen vervangt. Belangrijk detail: er komt geen brief. De Rijksoverheid stelt uitdrukkelijk dat organisaties zelf verantwoordelijk zijn om te toetsen of ze onder de wet vallen. Doe die toets dus actief, en leg vast wat eruit kwam — ook als de uitkomst "nee" is, want dan heb je iets om naar te wijzen.

Kom je er wél onder, dan verandert er iets wezenlijks voor je AI-project. Artikel 21 van de Cyberbeveiligingswet legt een zorgplicht op: passende en evenredige technische, operationele en organisatorische maatregelen voor de risico's voor de beveiliging van de netwerk- en informatiesystemen die je voor je werkzaamheden gebruikt. Dat is breder dan de AVG. De AVG kijkt naar persoonsgegevens; de zorgplicht kijkt naar je systemen en je dienstverlening als geheel. Een ingekochte AI-oplossing waarmee je klantcontact draait, is zo'n systeem. Je kunt hem er niet buiten houden met het argument dat het maar een hulpmiddel is.

En er is een derde route waarlangs deze eisen bij kleine bedrijven binnenkomen, die vaker voorkomt dan de wettelijke: via het contract. Lever je aan een organisatie die er wel onder valt, dan is de kans groot dat zij hun eisen doorschuiven naar jou als toeleverancier. Dan gelden ze voor jou niet uit de wet maar uit de overeenkomst — met hetzelfde praktische gevolg, en meestal met een strakkere deadline.

Wat is van jou en wat is van je leverancier?

De beveiligingsplicht van artikel 32 AVG rust op beide partijen: op degene die bepaalt waarvoor de gegevens gebruikt worden, en op de partij die het systeem levert en de gegevens namens hem verwerkt. Gedeeld betekent hier niet opgesplitst. Als het misgaat, komt de klant bij jou en komt de toezichthouder bij jou. Dat je een goede leverancier had, is dan een verzachtende omstandigheid en geen antwoord.

De verdeling die in de praktijk werkt, ziet er ongeveer zo uit. Je leverancier is aan zet voor de techniek onder de motorkap: versleuteling van verbindingen en opslag, updates, scheiding tussen klanten, beschikbaarheid, en het gedrag van zijn eigen personeel. Jij bent aan zet voor alles wat aan jouw kant zit: welke gegevens je erin stopt, wie er een account krijgt en wie er een houdt na vertrek, waar de AI bij mag, wat hij mag versturen, en op welke apparaten het kanaal openstaat.

Daartussen zit een grijze zone die de meeste problemen veroorzaakt: instellingen die de leverancier levert maar die jij moet aanzetten. Bewaartermijnen, verplichte tweefactorinlog, beperking op wie mag exporteren, en of jouw gesprekken al dan niet gebruikt worden om modellen mee te verbeteren. Standaardinstellingen zijn gekozen om het aanmelden soepel te laten verlopen, niet om jouw risico af te dekken. Ga ze dus één voor één langs voordat je live gaat, niet erna.

Drie dingen wil je vóór de start op schrift hebben, en dit gaat verder dan het standaardcontract dat je toch al nodig hebt. Wie bij de leverancier kan meekijken in de gesprekken en onder welke voorwaarden. Wat er met de gesprekken gebeurt als je stopt: krijg je ze eruit, en worden ze daarna verwijderd. En hoe en hoe snel ze jou waarschuwen als er aan hun kant iets misgaat — want jij bent degene die daarna moet handelen, en zonder tijdig bericht van hen red je jouw eigen termijnen niet. Alle drie horen ze in het contract en niet in een verkoopgesprek.

Wat controleer je in de week voordat het live gaat?

Beveiliging klaarzetten is werk van weken; controleren of het klopt is werk van een uur. Loop deze punten langs en zet er een datum en een naam bij, zodat je later kunt laten zien dat het gebeurd is.

1. Iedereen die toegang heeft, staat op een lijst met een eigen account. Er staat niemand op die er niet meer werkt.
2. Tweefactorinlog staat aan voor alle accounts, ook voor die van jezelf en die van de externe bouwer.
3. Je weet welke bronnen de assistent kan lezen, en je hebt die lijst zelf bekeken in plaats van aangenomen.
4. De assistent kan niets wijzigen of verwijderen waar alleen lezen genoeg is.
5. Er staat een plafond op het aantal uitgaande berichten, en er komt een signaal binnen als dat wordt geraakt.
6. Twee mensen weten hoe ze het systeem stilzetten, en het is een keer geprobeerd.
7. De testomgeving bevat geen echte klantgegevens meer.
8. Er staat op papier wie je belt bij de leverancier als er iets misgaat, met een naam en een tijdvenster.
9. Je hebt vastgelegd of je onder de Cyberbeveiligingswet valt, met de uitkomst en de datum.

Zit er een gat, dan is dat geen reden om af te blazen. Het is een reden om kleiner te beginnen. Eén kanaal in plaats van drie, of een opzet waarin de AI alleen concepten voorstelt en een mens op verzenden drukt. Beperkt beginnen is zelf ook een beveiligingsmaatregel: het houdt de schade klein van precies datgene wat je nog niet weet.

Hoe hou je het bij als het eenmaal draait?

Een beveiligingsniveau is geen toestand maar onderhoud. Twee vaste momenten zijn genoeg voor een klein bedrijf. De eerste maand kijk je wekelijks naar het uitgaande verkeer: niet naar de inhoud van elk gesprek, maar naar de vorm — hoeveel berichten, naar hoeveel unieke mensen, op welke tijdstippen. Daar zie je een afwijking het eerst. En elk kwartaal loop je de accountlijst na: vertrokken medewerkers, tijdelijke krachten, de bouwer die drie maanden geleden klaar was en nog steeds beheerdersrechten heeft.

En bij elke verandering doe je de afweging opnieuw: een kanaal erbij, een nieuwe koppeling naar je administratie, een leverancierswissel, of een assistent die opeens ook afspraken mag verzetten in plaats van alleen antwoorden. Verandert wat het systeem kan of waar het bij kan, dan verandert het risico — en dan klopt de vorige afweging niet meer. Overweeg je een uitbreiding met duidelijk meer impact op mensen, kijk dan ook of er een aparte beoordeling vooraf nodig is; de wet noemt het gebruik van nieuwe technologie daarbij uitdrukkelijk als aanleiding.

Wat dit alles bij elkaar oplevert is niet alleen minder risico. Het is ook het enige eerlijke antwoord op de vraag die een klant of een toezichthouder ooit stelt: hoe wist je dat dit veilig genoeg was? Daar bestaat geen certificaat voor dat het antwoord voor je geeft. Er bestaat alleen een afweging die je hebt gemaakt, opgeschreven en sindsdien hebt bijgehouden.