Ik heb zelf iets gebouwd met AI: is dat veilig voor mijn bedrijf?

Iets dat je met AI hebt gebouwd is niet per definitie onveilig, maar er zitten vier risico's in die vrijwel altijd terugkomen: gegevens die voor iedereen toegankelijk zijn, sleutels die in de code staan, geen back-up, en geen idee wat er gebeurt als de dienst waar het op draait ermee stopt. Die vier zijn te controleren zonder dat je programmeur hoeft te zijn.

In het kort

• Zelf bouwen is niet het probleem. De onderdelen die je niet ziet zijn dat wel.
• Vier risico's komen bijna altijd terug: open toegang tot gegevens, sleutels in de code, geen geteste back-up, en geen uitweg als de dienst stopt.
• Die vier kun je zelf nakijken, ook zonder dat je code leest.
• Trek een grens zodra er gegevens van anderen in komen, en een tweede zodra je bedrijf stilstaat als het niet werkt.

Steeds meer ondernemers bouwen zelf iets. Een klein systeempje voor de planning, een formulier voor klanten, een tool die een berekening doet. Dat is een goede ontwikkeling, en ik zeg dat als iemand die er zijn beroep van heeft gemaakt. Het probleem is niet dat je het zelf bouwt. Het probleem is dat de dingen die je niet kunt zien ook niet worden aangeboden.

Waarom dit anders is dan vroeger zelf bouwen

Wie tien jaar geleden zelf iets in elkaar zette, kwam vanzelf de moeilijke onderdelen tegen. Je moest een server regelen, je moest nadenken over inloggen, je liep tegen foutmeldingen aan die je dwongen te begrijpen wat er gebeurde.

Nu werkt het andersom. Je beschrijft wat je wilt en er komt iets werkends uit. De moeilijke onderdelen zijn niet verdwenen, ze zijn onzichtbaar geworden. Er is een database aangemaakt, er staan toegangsregels ingesteld, er is een sleutel gegenereerd. Allemaal met standaardinstellingen die prima zijn om iets te proberen en niet altijd prima om klantgegevens in te zetten.

Dat is geen kritiek op die hulpmiddelen. Het is een gevolg van hoe ze werken: ze halen drempels weg, en sommige van die drempels stonden er niet voor niets.

De vier dingen die je zelf kunt nakijken

Je hoeft hiervoor geen code te lezen.

• Kan iemand anders bij de gegevens. Probeer het gewoon. Open je toepassing in een privévenster van je browser, zonder ingelogd te zijn. Kom je bij gegevens? Dan kan iedereen dat. Vraag ook aan iemand anders om in te loggen met zijn eigen account en te kijken of hij jouw gegevens ziet. Dat is het meest voorkomende lek: iedereen die ingelogd is, ziet alles.

• Staan er sleutels in de code. Als je toepassing praat met een andere dienst, is daar een sleutel voor nodig. Die hoort op de server te staan, niet in het deel dat in de browser draait. Dit is lastiger zelf te controleren, maar je kunt het vragen: waar staat de sleutel, en is hij zichtbaar voor een bezoeker.

• Is er een back-up en heb je hem getest. Niet of er een back-up is, maar of je er ooit iets mee hebt teruggezet. Een back-up die nooit is uitgeprobeerd is een aanname.

• Wat gebeurt er als de dienst stopt. Waar draait het, wie is de eigenaar van het account, en kun je je gegevens eruit halen. Als het antwoord op de laatste vraag nee is, heb je een probleem dat groeit met de tijd.

Twee vragen die er nog bij horen

• Wie kan erbij als jij er niet bent. Als het account op jouw persoonlijke mailadres staat en niemand anders erbij kan, is dat een risico dat losstaat van techniek.

• Wat gebeurt er bij groei. Iets dat werkt met vijftig regels kan onbruikbaar worden bij vijftigduizend. Dat is meestal geen ramp, maar wel goed om te weten voordat je erop gaat leunen.

Wat je zelf kunt oplossen en wat niet

Veel is zelf te doen. Toegangsregels aanzetten zodat iemand alleen zijn eigen gegevens ziet, een fatsoenlijke inlog inbouwen, tweestapsverificatie aanzetten op de accounts eromheen, en periodiek een export maken die je ergens anders bewaart. Dat zijn geen grote ingrepen en de meeste hulpmiddelen ondersteunen ze.

Lastiger wordt het als er echt bedrijfskritische processen op gaan draaien. Dan komen er vragen bij die niet met een instelling zijn op te lossen: wat als twee mensen tegelijk hetzelfde wijzigen, hoe voorkom je dat een fout in de code stilletjes verkeerde bedragen oplevert, en hoe zorg je dat een wijziging van vandaag niet iets van vorige maand kapotmaakt.

Dat is het punt waarop het geen hobby meer is maar een systeem waar je bedrijf van afhangt.

Mijn eerlijke advies

Ik ga je niet vertellen dat je moet stoppen met zelf bouwen. Iemand die zelf een prototype maakt, weet precies wat hij wil, en dat is de beste uitgangspositie die er is. Ik zie zulke prototypes graag, want ze zijn een betere specificatie dan welk document ook.

Wat ik wel zou aanraden: trek een grens bij het moment dat er gegevens van anderen in komen. Zolang het jouw eigen planning is, is het risico jouw risico. Zodra er klantgegevens, persoonsgegevens of financiële gegevens in gaan, is het niet meer alleen jouw risico en gelden er ook regels.

En trek een tweede grens bij het moment dat je bedrijf stilstaat als het niet werkt. Dan hoort er iemand naar te kijken die weet waar het aan kan liggen.

Hoe ik daarmee omga

Als iemand met een zelfgebouwd prototype komt, is mijn eerste vraag nooit of we het weggooien. Meestal is het antwoord nee. De opzet klopt vaak, want de bedenker snapt zijn eigen proces beter dan ik ooit zal doen.

Wat er dan gebeurt is dat ik de onderdelen die er onder zitten fatsoeneer: de toegang, de gegevensopslag, de foutafhandeling, de back-up. Dat is meestal een fractie van het werk van opnieuw beginnen, en je houdt de vorm die je zelf hebt bedacht.

Heb je zelf iets gebouwd en wil je weten of het klaar is voor echt gebruik? Plan gerust een vrijblijvend gesprek, dan kijk ik er met je naar en zeg ik eerlijk wat er moet en wat kan blijven.