We bouwen steeds sneller. Maar waar is de fundering?

Ik hoor steeds meer verhalen van ondernemers die met Claude en andere AI-tools zelf koppelingen bouwen tussen hun systemen. Ook in de horeca. Het enthousiasme is groot: ineens kunnen ze zelf dingen automatiseren waar ze eerder een ontwikkelaar voor nodig hadden.

Dat enthousiasme snap ik. Wat eerst weken werk was, kun je nu soms in een middag neerzetten. Een reserveringssysteem koppelen, administratie automatiseren, informatie uit verschillende systemen combineren. Er kan ontzettend veel.

Maar telkens vraag ik me af: wie denkt er na over wat er achter die koppelingen met onze gegevens gebeurt?

Een werkende koppeling is nog geen fundering

Een reservering komt binnen, de gegevens verschijnen in het juiste systeem en de bevestiging wordt verstuurd. Het werkt. Alleen zegt dat nog weinig over de privacy van de gast die zojuist een tafel heeft geboekt.

Waar gaan de naam, het telefoonnummer en het mailadres naartoe? Welke andere partijen krijgen die gegevens? Wie kan erbij? Hoe lang blijven ze bewaard? En wat gebeurt er met een opmerking over een allergie, die ook iets over iemands gezondheid kan vertellen?

Bij personeelsgegevens spelen vergelijkbare vragen. Een handige koppeling tussen de planning en de administratie kan veel werk besparen. Maar een hulpmiddel voor één taak hoeft geen toegang te krijgen tot het hele personeelsbestand.

Ik denk niet dat ondernemers daar bewust onzorgvuldig mee omgaan. Het probleem is dat je tegenwoordig iets kunt bouwen voordat je weet welke vragen je had moeten stellen. De zichtbare uitkomst werkt al, terwijl de fundering nog ontbreekt.

AI laten bouwen en gegevens naar AI sturen zijn verschillende dingen

Er zit een belangrijk verschil tussen AI gebruiken om code te schrijven en echte persoonsgegevens naar een AI-dienst sturen. Een koppeling die met Claude is gebouwd, stuurt niet automatisch alle gegevens naar Claude. Dat hangt af van de code en de diensten die de toepassing gebruikt.

Juist daarom moet je verder kijken dan het hulpmiddel waarmee iets is gemaakt. Stuurt de koppeling alleen een reservering naar de administratie? Of gaat de inhoud ook naar een AI-dienst om bijvoorbeeld een bericht samen te vatten of een antwoord voor te stellen? Dat zijn verschillende gegevensstromen, met verschillende afwegingen.

Je moet weten welke informatie wordt verstuurd, waarvoor die nodig is en welke afspraken gelden bij de ontvanger. Dat kun je niet afleiden uit het feit dat de toepassing een goed antwoord geeft.

Privacy hoort vóór het bouwen te beginnen

Als ontwikkelaar wil ik beginnen bij privacy, de AVG, toegangsrechten en de plek waar gegevens worden verwerkt. Welke gegevens zijn echt nodig? Wat mag een gebruiker zien? Welke bevoegdheden krijgt een koppeling? En welke leveranciers komen erbij?

Een Europese basis voor servers en diensten is voor mij een uitgangspunt. Maar een server in Europa is op zichzelf geen AVG-garantie. Ook het doel, de toegang, de bewaartermijnen en de afspraken met leveranciers tellen mee. Voor doorgifte buiten de Europese Economische Ruimte gelden bovendien aanvullende voorwaarden.

Die fundering moet ook in het dagelijkse werk standhouden. Stel dat een gast vraagt welke gegevens je over hem hebt, of vraagt om verwijdering. Kun je dan terugvinden in welke systemen zijn informatie staat? Weet je wie het verzoek afhandelt en wat je aan gekoppelde partijen moet doorgeven?

Niet ieder gegeven hoeft in elke situatie te worden verwijderd. Wel moet je zulke verzoeken kunnen beoordelen en beantwoorden. Als niemand de gegevensstromen overziet, wordt dat lastig.

Moet toestemming vanzelfsprekender worden?

Daarnaast zit ik met een bredere vraag. Zou expliciete toestemming de norm moeten worden wanneer bedrijven onze persoonsgegevens door AI laten verwerken? Niet verstopt in algemene voorwaarden, maar begrijpelijk: dit willen we met je gegevens doen, via deze dienst en voor dit doel. Met een echte mogelijkheid om nee te zeggen.

Dat is een maatschappelijke vraag, geen beschrijving van wat de wet nu altijd vereist. De AVG kent verschillende grondslagen voor gegevensverwerking; toestemming is daar één van. Bij werknemers is toestemming bovendien ingewikkeld, omdat de afhankelijkheid van een werkgever een vrije keuze in de weg kan staan.

Voor mij gaat de vraag vooral over zeggenschap. Als klant of medewerker wil je kunnen begrijpen wat er met je gegevens gebeurt. De snelheid waarmee een bedrijf iets kan automatiseren, mag niet bepalen hoeveel zicht jij daarop overhoudt.

Wie zorgt voor de fundering?

Die fundering is ook waar we met Trustbird aan werken: organisaties helpen om informatiebeveiliging en privacy structureel te organiseren. Zodat je weet welke gegevens je verwerkt, welke risico’s daarbij horen en wie waarvoor verantwoordelijk is.

Maar de vraag is breder dan één product. Hoe maken we die fundering net zo vanzelfsprekend als de tools waarmee we bouwen? Moeten AI-aanbieders betere grenzen en waarschuwingen inbouwen? Wat mag je verwachten van een enthousiaste ondernemer die de risico’s nog niet kent? En hoe leggen wij als ontwikkelaars beter uit dat werkende software nog geen verantwoorde software is?

Anders reserveer ik straks alleen nog onder James Bond, met een tijdelijk mailadres en telefoonnummer. Half als grap. Maar ik wil niet hoeven raden waar mijn gegevens belanden nadat ik een tafel heb geboekt.