Medewerkers bouwen AI-apps: weet u waar ze draaien?

Waarschijnlijk draait er ergens in uw organisatie een applicatie waarvan u het bestaan niet kent. Een medewerker bouwde die in een middag met hulp van een AI-model. De app werkt en bespaart tijd, maar staat mogelijk op een publiek adres zonder beveiliging.

Dit is allang geen uitzondering meer. Sinds dit jaar kan vrijwel iedere gemotiveerde medewerker zonder programmeerkennis een bruikbare interne tool maken. Grote cloudpartijen spelen daarop in met snelle oplossingen, zoals een inloglaag die u met één klik toevoegt.

Verbieden is de duurste fout die u hierbij kunt maken. Het risico is reëel, maar een verbod maakt het niet kleiner. Het verplaatst de tools naar de schaduw. En onzichtbare risico’s ontdekt u vaak pas wanneer iemand anders ze al heeft gevonden.

Wat kan er misgaan met AI-apps van medewerkers?

De problemen zitten zelden in de code zelf. Ze ontstaan in de vier basiszaken die een AI-model niet automatisch voor u regelt, tenzij u daar expliciet om vraagt.

• Geen toegangscontrole. De tool staat online op een voorspelbare URL. Iedereen die de link vindt, kan naar binnen. Zoekmachines en geautomatiseerde scanners vinden zulke pagina’s vaak verrassend snel.

• Een sleutel in de etalage. Een API-sleutel die in de frontend belandt, in plaats van in een .env op de server. Iedere bezoeker kan die uitlezen en op uw kosten gebruiken.

• Geen logging. Zonder registratie weet u niet wie welke gegevens heeft bekeken. Bij een incident kunt u dus niet vaststellen wat er is geraakt. Daardoor wordt ook uw meldplicht een gok.

• Geen eigenaar. De bouwer vertrekt, terwijl de tool blijft draaien op een persoonlijk account. Soms valt die stil doordat een kaart wordt geblokkeerd; soms draait hij ongecontroleerd door.

  
  

Maak het tastbaar. Een installatiebedrijf bouwt een planningstool waarin monteurs adressen, telefoonnummers en soms toegangsinstructies zien. Dat is feitelijk een adressenlijst van woningen, inclusief informatie over toegang.

Een accountantskantoor bouwt een scherm waarin een grootboek wordt geplakt en automatisch een BTW-signaal verschijnt. Handig, maar de omzetgegevens van klanten kunnen daarbij terechtkomen bij een partij waarmee niemand een verwerkersovereenkomst heeft gesloten.

Een webshop maakt een retourdashboard om te zien welke leverancier de meeste klachten veroorzaakt. Een goed idee, totdat blijkt dat er een export met klantnamen en bestelgeschiedenis aan gekoppeld is.

Waarom een verbod niet werkt?

Reken mee. Een zelfgebouwde tool bespaart de maker vaak twee tot vier uur per week. Bij een intern uurtarief van €45 levert dat jaarlijks €4.500 en €9.000 aan tijdwinst op. Voor één medewerker, met één tool.

Daarom werkt een verbod zelden. U vraagt iemand om een paar uur tijdwinst per week op te geven voor een risico dat abstract voelt. In de praktijk verhuist de tool dan naar een privéaccount en verdwijnt hij uit beeld.

Zet daar de andere kant tegenover. Een Iers ziekenhuis kreeg deze maand een boete van €300.000 na een ransomwaredatalek. Niet omdat het ziekenhuis zelf aanviel, maar omdat het slachtoffer werd en de beveiliging onvoldoende bleek. Dat is de kern: slachtoffer zijn is geen verzachtende omstandigheid. De toezichthouder beoordeelt wat u vooraf geregeld had, niet wie er aanbelde.

Daar komt de meldplichtbinnen72 uur bij. Zonder logging weet u niet welke gegevens zijn gelekt. Dan moet u breed melden, mogelijk aan alle klanten. Die kosten staan zelden in een risicoanalyse, maar zijn vaak de grootste.

Maak veilig bouwen de makkelijkste route

De enige aanpak die standhoudt: maak veilig bouwen eenvoudiger dan onveilig bouwen. Niet met een dik beleidsdocument, maar met goede infrastructuur.

Zorg voor één plek waar interne tools mogen landen, met inloggen via de bestaande bedrijfsaccounts en standaard ingeschakelde logging. Wie daar deployt, is snel klaar. Wie een tool elders plaatst, moet zelf over authenticatie nadenken. Mensen kiezen dan vanzelf de veilige, makkelijke route.

Leg daarnaast drie regels vast die iedereen begrijpt en die u in vijf minuten kunt uitleggen:

• Geen publieke URL zonder inloggen. Ook niet ‘tijdelijk om te testen’; tijdelijk wordt al snel permanent.

• Geen echte klantgegevens in een experiment. Werk met fictieve of geanonimiseerde data. Pas als de tool werkt, bespreekt u het gebruik van echte gegevens.

• Elke tool heeft een eigenaar en een controledatum. Leg vast wie verantwoordelijk is en wanneer u beoordeelt of de tool nog nodig is.

Begin met inventariseren; dat kost hooguit een halve ochtend. Vraag medewerkers welke tools zij zelf hebben gemaakt en maak duidelijk dat daar geen straf op staat. Controleer vervolgens domeinbeheer, hostingaccounts en kleine abonnementen in uw factuuroverzicht. Daar vindt u vaak de vergeten tools.

Waarom een inloglaag niet genoeg is

Hier is nuance nodig. Een inloglaag voor een interne tool beveiligt de voordeur, maar niet automatisch de achterdeur.

Een sleutel in de frontend blijft zichtbaar. Klantgegevens die al naar een AI-model zijn gestuurd, blijven verstuurd. Een koppeling met uw boekhoudsysteem kan nog steeds draaien met de ruime rechten van de bouwer, in plaats van met de minimale rechten die de tool nodig heeft. En een vertrekkende collega kan toegang houden tot het deploy-account.

Voeg daar een nieuw risico aan toe: AI-agents die in uw systemen meekijken, krijgen vaak rechten die zijn bedoeld voor een medewerker die twee keer nadenkt. Een agent doet dat niet en kan een actie duizenden keren sneller herhalen. Rechten die veilig lijken voor een ervaren medewerker, zijn dat niet altijd voor een automatisch proces dat de hele nacht doorwerkt.

Wees ook realistisch over wat wél prima kan. Een tool die alleen rekent, offertes optelt of tekst herschrijft zonder persoonsgegevens te verwerken, hoeft geen groot probleem te zijn. Laat die ruimte bestaan. Als u overal even streng op bent, verliest u het onderscheid tussen onschuldig en risicovol.

Wees strikt bij drie categorieën: persoonsgegevens van klanten, gegevens over betalingen of bankrekeningen en gegevens over gezondheid of personeel. Daar is geen vrijblijvende experimenteerruimte. Bouw daar niet zomaar in een middag een nieuwe tool omheen, hoe overtuigend het AI-model ook klinkt.

De vraag die u vandaag moet stellen

Vraag niet: ‘Bouwt iemand hier stiekem software?’ Vraag: ‘Welke toepassingen zijn vanaf internet bereikbaar, en zijn ze goed beveiligd?’

Organisaties die dit goed aanpakken, hebben niet per se de strengste regels. Ze bieden een plek waar medewerkers veilig mogen bouwen, waar toegangscontrole al geregeld is en waar iemand regelmatig controleert wat er nog draait. Dat kost minder dan een verbod handhaven — en het is de aanpak die werkt.