Word ik aanbieder als mijn medewerkers zelf AI-tools bouwen? Het korte antwoord: ja, zodra die tool binnen uw organisatie in gebruik gaat en u hem onder eigen naam inzet. Dan verschuift uw rol van gebruiksverantwoordelijke naar aanbieder, met alle verplichtingen die daarbij horen.
Een marketingmedewerker bouwt in een avond een klantanalyse-dashboard met ChatGPT. Een HR-manager maakt een tool die cv's automatisch rangschikt. Een financieel analist creëert een applicatie die facturen classificeert. Welkom in het tijdperk van vibe coding, waar iedereen met behulp van AI-assistenten software kan bouwen. Programmeerkennis? Niet nodig.
Dit fenomeen groeit razendsnel. Tools als ChatGPT, Claude, Cursor of GitHub Copilot maken het mogelijk om in enkele uren werkende applicaties te bouwen door simpelweg te beschrijven wat je wilt. Krachtig, zeker. Maar het brengt ook serieuze risico's met zich mee. Zeker als je kijkt naar de EU AI Act.
Wat is vibe coding?
Vibe coding is een term die begin 2025 populair werd. Het verwijst naar het bouwen van software door in natuurlijke taal te beschrijven wat je wilt, waarna een AI-assistent de code genereert. De bouwer hoeft niet te begrijpen hoe de code werkt. Het gaat puur om het eindresultaat. Je beschrijft de vibe van wat je wilt, de AI maakt het.
Voor veel medewerkers voelt dit als een doorbraak. Eindelijk kunnen ze zelf tools bouwen die precies doen wat ze nodig hebben, zonder weken te wachten op de IT-afdeling. Het probleem? Deze apps belanden steeds vaker in productie. Ze worden gebruikt door collegas, klanten, soms zelfs voor besluitvorming. Zonder dat iemand de code heeft gereviewed, de beveiliging heeft getest of heeft gecontroleerd of de app aan wet- en regelgeving voldoet.
De dubbele AI-laag
Bij vibe coding speelt een bijzonder fenomeen dat we de dubbele AI-laag noemen. Er zijn twee niveaus van AI betrokken.
De eerste laag is de AI waarmee gebouwd wordt. Tools als ChatGPT, Claude of Cursor zijn zelf AI-systemen die code genereren. Deze AI bepaalt hoe de applicatie werkt, welke logica wordt toegepast, hoe data wordt verwerkt.
De tweede laag is de AI die in de gebouwde app zit. Veel vibe-coded apps integreren zelf ook AI-functionaliteit. Denk aan een app die de OpenAI API aanroept om teksten te analyseren, klanten te classificeren of beslissingen te ondersteunen.
Beide lagen zijn relevant voor de AI Act. De eerste laag valt onder de verantwoordelijkheid van de aanbieder van de AI-tool. Maar de tweede laag, de AI die uw medewerker in een zelfgebouwde app stopt, valt onder uw verantwoordelijkheid als organisatie. U bent dan juridisch de gebruiksverantwoordelijke. Stelt u de app beschikbaar aan derden? Dan bent u mogelijk zelfs de aanbieder.
Wanneer wordt uw organisatie aanbieder?
Dit is een cruciaal punt dat veel organisaties over het hoofd zien. Onder de AI Act bent u aanbieder zodra u een AI-systeem ontwikkelt of laat ontwikkelen én het onder eigen naam of merk op de markt brengt of in gebruik stelt. Bouwt een medewerker een vibe-coded app die AI bevat en zet uw organisatie die onder eigen naam in gebruik? Dan bent u aanbieder. Artikel 3, punt 3 spreekt van op de markt brengen of in gebruik stellen, dus verspreiding naar buiten is niet vereist: een app die alleen intern draait telt net zo goed.
Dat brengt zwaardere verplichtingen met zich mee dan het gebruik van bestaande AI-tools. Als aanbieder bent u verantwoordelijk voor een conformiteitsbeoordeling bij hoog-risico systemen, technische documentatie, een kwaliteitsbeheersysteem, monitoring na het op de markt brengen. Ook het melden van ernstige incidenten valt daaronder.
Het beveiligingsprobleem
Naast de juridische risico's is er een minstens zo groot praktisch probleem: de beveiliging van vibe-coded apps is vaak dramatisch slecht. Dat is geen verwijt aan de bouwers. Zij zijn geen ontwikkelaars, ze kunnen de kwaliteit van de gegenereerde code simpelweg niet beoordelen.
Wat we tegenkomen in vibe-coded apps is alarmerend. API-sleutels staan hardcoded in de broncode, zichtbaar voor iedereen. Input-validatie ontbreekt, waardoor SQL-injectie of cross-site scripting mogelijk is. Authenticatie is er niet of halfbakken geïmplementeerd. Data gaat onversleuteld over de lijn. Toegangscontroles? Niet aanwezig. Foutmeldingen lekken technische details die aanvallers kunnen misbruiken. Logging of monitoring om inbraken te detecteren is er al helemaal niet.
Dit is niet alleen een IT-probleem. De AI Act eist voor hoog-risico AI-systemen expliciet dat ze cyberbeveiligd zijn, technisch robuust. Een slecht beveiligde AI-app die beslissingen neemt over mensen, zoals het rangschikken van sollicitanten of het beoordelen van kredietaanvragen, levert een dubbel compliance-risico op. Het voldoet niet aan de beveiligingseisen van de AI Act. Tegelijkertijd schendt het mogelijk de AVG door onvoldoende bescherming van persoonsgegevens.
Shadow AI: het onzichtbare risico
Het grootste gevaar van vibe coding is dat het buiten het zicht van IT, compliance en management plaatsvindt. Dit fenomeen heet shadow AI. Het zijn AI-toepassingen die door individuele medewerkers worden gebouwd zonder dat de organisatie ervan weet.
Shadow AI is bijzonder lastig te beheersen. De apps draaien op persoonlijke accounts of gratis cloud-diensten. Ze worden gedeeld via e-mail of chatberichten. Ze verschijnen niet in de IT-inventaris. Er is geen code review, geen security audit, geen registratie in het AI-register.
Dit is precies het type situatie waar toezichthouders op zullen letten. De AI Act verplicht organisaties om te weten welke AI-systemen ze gebruiken. Stel dat bij een inspectie blijkt dat er tientallen ongeregistreerde AI-apps in gebruik zijn, gebouwd door medewerkers die niet eens wisten dat de AI Act bestond. Dat wordt lastig uit te leggen.
Wat moet u nu doen?
Vibe coding verbieden is geen realistisch antwoord. De productiviteitswinst is te groot. Medewerkers zullen het toch doen, desnoods op eigen apparaten. Een betere aanpak is om het te kanaliseren.
Stel een beleid op voor intern gebouwde AI-apps. Definieer wanneer een vibe-coded app geregistreerd moet worden in uw AI-register. Een vuistregel: elke app die persoonsgegevens verwerkt, beslissingen over mensen ondersteunt of door meer dan de bouwer zelf wordt gebruikt, hoort in het register.
Richt een lichtgewicht reviewproces in. Niet elke interne tool hoeft door een volledig security-audit. Maar een basischeck op hardcoded credentials, input-validatie, toegangscontrole: dat voorkomt de ergste problemen. Overweeg een interne checklist die medewerkers zelf kunnen doorlopen voordat ze een app delen.
Investeer in AI-geletterdheid, want de verplichting uit Artikel 4 van de AI Act is hier direct relevant. Medewerkers die AI-tools gebruiken om software te bouwen moeten begrijpen welke risico's dat meebrengt. Niet alleen technisch, ook juridisch. Een korte training over de basisprincipes van de AI Act kan veel problemen voorkomen.
Breng bestaande vibe-coded apps in kaart. Grote kans dat er binnen uw organisatie al meerdere zelfgebouwde AI-apps in omloop zijn. Doe een inventarisatie, beoordeel de risico's, registreer de apps die onder de AI Act vallen in uw AI-register.
Veelgestelde vragen
Wanneer word ik aanbieder van een zelfgebouwde tool?
Zodra u een AI-systeem onder eigen naam in gebruik neemt of op de markt brengt. Voor intern gebruik betekent dat: de tool draait in uw organisatie, u bepaalt het doel en er is geen externe leverancier die de verantwoordelijkheid draagt. De verplichtingen die dan gelden, hangen af van de risicoklasse van de toepassing.
Geldt dit ook voor een spreadsheet met een AI-formule?
De grens ligt bij de vraag of er sprake is van een AI-systeem met een eigen gebruiksdoel. Een losse formule die een tekst samenvat, is een hulpmiddel. Een gebouwde applicatie die cv's rangschikt of facturen classificeert en waarop mensen beslissingen nemen, is een systeem.
Moeten wij vibe-coded tools in het AI-register zetten?
Ja, en juist die. Ze ontstaan buiten IT om, dus zonder register ziet niemand ze. Leg per tool vast wie hem bouwde, wat hij doet, welke data erin gaat en wie eigenaar is. Dat is ook de enige manier om te merken dat een experiment een productiesysteem is geworden.
Mogen wij zelfbouw dan maar beter verbieden?
Dat duwt het ondergronds. Een aanvraag- en goedkeuringsroute werkt beter: medewerkers melden wat ze willen bouwen, u beoordeelt het gebruiksdoel vooraf, en wat door de poort komt staat meteen in het register.
Wie is aansprakelijk als een zelfgebouwde tool fout gaat?
Uw organisatie. Er is geen leverancier om naar te wijzen, en de medewerker handelde in functie. Dat maakt de interne beoordeling vooraf belangrijker dan bij ingekochte software, waar u tenminste nog een conformiteitsverklaring kunt opvragen.
Van risico naar kans
Vibe coding hoeft geen bedreiging te zijn voor uw compliance-positie. Met het juiste beleid kunt u de innovatiekracht van uw medewerkers benutten, zonder in te leveren op compliance.
De gratis risicoscan werkt ook voor intern gebouwde apps: scan uw vibe-coded tools en zie direct in welke risicocategorie ze vallen.