Met AI bouw je zelf een werkende app of een dashboard. Veilig live zetten is een ander verhaal: inloggen, rechten, sleutels, back-ups, logging en onderhoud. Wat je regelt voordat klanten en klantgegevens erin gaan, en wanneer je beter opnieuw begint.
Een klantportaal, een urenregistratie, een dashboard voor het maandagoverleg. Met AI-tools als Lovable, Bolt, Cursor of Claude kun je zoiets nu zelf bouwen. Je beschrijft wat je wilt, de AI schrijft de code, je stuurt een paar rondes bij en er staat iets dat werkt. Collega’s zien het en willen ermee werken.
Dan komt de vraag: kan dit zo live?
Een ondernemer met wie ik sprak, had zelf met AI een website en een app gebouwd. Het bouwen ging snel. Daarna kwamen de vragen: waar host je dit, hoe regel je het inloggen, wat gebeurt er met de database, wie maakt de back-ups en wie doet de updates? Terechte vragen. Precies daar zit het verschil tussen een prototype en productie.
Of je die app überhaupt moet bouwen, is een andere vraag. Die behandelde ik in bouwen was nooit het probleem. Hier gaat het om de stap daarna: van iets dat werkt naar iets waar klanten en klantgegevens veilig in kunnen.
Vibe coding is software bouwen door een AI-model in gewone taal te vertellen wat je wilt, waarna het model de code schrijft. De term komt van AI-onderzoeker Andrej Karpathy. In februari 2025 beschreef hij op X een nieuwe manier van programmeren waarbij je je overgeeft aan de vibes en vergeet dat de code bestaat.1 Collins Dictionary koos vibe coding in november 2025 tot woord van het jaar.2
Wij werken er zelf dagelijks mee; ik vertelde erover in het interview over AI en maatwerksoftware. Ik ben er dus niet tegen. Het bouwen is sneller geworden. Het werk om iets veilig in productie te krijgen, is gebleven.
Omdat werken en veilig zijn twee verschillende tests. Een demo laat zien dat de knoppen doen wat ze moeten doen. Hij laat niet zien wat er gebeurt als iemand uitlogt en een afgeschermde pagina direct intypt, een ander klantnummer in de adresbalk zet of eindeloos wachtwoorden probeert.
Onderzoekers van onder meer Carnegie Mellon University hebben dat gemeten. In hun benchmark (arXiv, herziene versie van augustus 2026) kregen AI-codeeragents 186 programmeertaken uit bestaande open-sourceprojecten, taken waarbij menselijke ontwikkelaars eerder een kwetsbaarheid hadden ingebouwd. De best scorende combinatie van agent en taalmodel leverde bij 57% van de taken werkende code op, maar 79,3% van die werkende oplossingen had een beveiligingsprobleem.3
Het ging bewust om taken waarbij beveiliging ertoe doet, dus dit is geen doorsnede van alle apps. De les is wel helder: code die door de functionele test komt, is daarmee nog niet veilig.
Het grootste risico is ook niet exotisch. OWASP, een internationale non-profitstichting voor softwarebeveiliging, zet in de Top 10 van 2025 ‘broken access control’ op één: gebruikers die kunnen zien of doen wat buiten hun rechten valt. Volgens OWASP bleek 100% van de geteste applicaties er een vorm van te hebben.4
‘Het werkt’ is niet hetzelfde als ‘het kan veilig live’.
Dit is wat ik minimaal zou regelen. De lijst sluit aan op wat OWASP, de Autoriteit Persoonsgegevens (AP) en het databaseplatform Supabase noemen. Supabase somt in zijn checklist voor vibe coders uit 2025 de gebruikelijke gaten op: API-sleutels in de code aan de voorkant, ontbrekende controle op invoer en foutafhandeling, eenvoudige inlog zonder goede beveiliging, en geen monitoring, back-ups of herstelplan.5
Begin bij de vraag wie wat mag zien en doen. Log uit en typ de adressen van afgeschermde pagina’s direct in je browser. Maak voor elke rol een testaccount en controleer of iedereen alleen ziet wat bij die rol hoort.5 De AP schrijft (2024) dat je al bij een vrij laag risiconiveau een autorisatiematrix nodig hebt: per systeem vastgelegd welke medewerker welke toegang heeft, en actueel gehouden. Ze raadt ook meerfactorauthenticatie aan op alle systemen met toegangscontrole.6
Een API-sleutel die in de code aan de voorkant staat, kan iedereen lezen die de broncode van de pagina opent. Zoek je code na op sleutels en wachtwoorden en zet ze als omgevingsvariabelen op de server.5 Hebben ze ooit in de code of in een openbare repository gestaan, vervang ze dan door nieuwe.
Werk je met een database als Supabase, zet dan row level security aan en test of gebruikers elkaars gegevens niet kunnen opvragen.5 Regel back-ups en probeer minstens één keer of je er ook mee kunt terugzetten. De AP noemt in haar voorbeelden van beveiligingsmaatregelen (2026) expliciet back-ups waarmee je gegevens tijdig kunt herstellen.7
Een prototype draait vaak in de omgeving van de tool waarmee je het bouwde. Voor productie wil je weten waar de app draait, wie erbij kan en hoe een nieuwe versie live gaat zonder dat je de vorige kwijtraakt. Loop ook de standaardinstellingen na: een verkeerde beveiligingsconfiguratie staat in de OWASP Top 10 van 2025 op twee.8
Als er iets misgaat, wil je het eerder weten dan je klant. Leg vast wie wat heeft gedaan, zeker waar persoonsgegevens in het spel zijn, en zorg dat een fout of een verdachte inlogpoging bij iemand binnenkomt. OWASP noemt tekortschietende logging en alerts als aparte categorie in de lijst van 2025.8 De AP noemt logbestanden bijhouden en regelmatig controleren als maatregel.7
Een met AI gebouwde app leunt op pakketten van anderen. Die krijgen beveiligingsupdates, en jouw app moet mee. In de OWASP-lijst van 2025 staan fouten in de softwareketen op drie.8 De AP noemt het beheer van technische kwetsbaarheden en software up-to-date houden als voorbeeld van een technische maatregel.7 Spreek af wie de updates doet, hoe vaak, en wie daarna test of alles nog werkt.
Verwerk je in Nederland klant- of medewerkersgegevens in je app, dan valt dat onder de AVG, net als bij elke andere software. Volgens de AP (2026) moet elke organisatie die persoonsgegevens verwerkt zelf bepalen welke beveiligingsmaatregelen nodig zijn, en kunnen aantonen dat die gegevens goed beveiligd zijn.9 Een app die je zelf met AI in elkaar hebt gezet, valt daar ook onder. Test met nepgegevens en bewaar niet meer dan je nodig hebt.
Het laatste stuk van een AI-build gaat over de dingen die je klant nooit mag merken.
Denk aan een chat die klantvragen beantwoordt of een knop die een document samenvat. OWASP houdt voor toepassingen met taalmodellen een aparte top tien bij. In de versie van 2025 staan prompt injection en het lekken van gevoelige informatie bovenaan.10 Prompt injection betekent dat iemand via de invoer de AI andere instructies geeft dan jij bedoelde.
Op zes staat ‘excessive agency’: een AI die schade kan aanrichten omdat hij te veel functies, te veel rechten of te veel zelfstandigheid heeft gekregen. De oplossing is weinig spannend. Laat de AI alleen doen wat de gebruiker namens wie hij werkt zelf mag, en niet meer. Dat raadt OWASP ook aan.11 In het operating system voor een franchiseorganisatie dat we bouwden, kan de AI-assistent alleen gegevens opvragen en acties uitvoeren waarvoor de ingelogde gebruiker zelf bevoegd is.
Niet door de AI te vragen of zijn code veilig is en het daarbij te laten. In het onderzoek hierboven moest de agent eerst zelf de beveiligingsrisico’s van een taak benoemen, of kreeg hij te horen welk type kwetsbaarheid hij moest vermijden. Geen van beide dichtte het gat betrouwbaar, en de onderzoekers pleiten voor een verplichte beveiligingscontrole.3 Die controle moet dus van buiten komen:
Reken die controletijd mee. Als elke wijziging daarna uren nalopen kost, is de winst kleiner dan hij leek.
Als je elke AI-output moet nalopen, heb je werk verplaatst in plaats van weggehaald.
Bij zelfgebouwde apps blijft het eigenaarschap makkelijk bij één persoon hangen. De app draait op het account van degene die hem bouwde. De code staat op één laptop of in één account bij een AI-tool. Niemand anders weet hoe hij in elkaar zit.
Voor een demo is dat prima. Voor software waar je bedrijf op draait niet. Zet code, hosting, domein en database op naam van het bedrijf. Beschrijf hoe je de app installeert, uitrolt en terugzet. En spreek af wie er gebeld wordt als hij ’s avonds niet werkt: jij, een collega of een partner met een onderhoudsafspraak.
Een prototype bewijst dat iets kan. Productie bewijst dat je erop kunt vertrouwen.
Dat hangt af van wat er onder de motorkap zit, en dat zie je niet aan de voorkant. Daarom begint het met een technische check: hoe zijn inloggen en rechten opgezet, hoe ziet het datamodel eruit, waar staan de sleutels, wat is er getest? Soms is de basis goed en gaat het om dichtzetten, testen en beheer regelen. Soms is de app vooral een goed uitgewerkt ontwerp, en is opnieuw bouwen de kortere weg.
Wat productie extra vraagt, zie je in wat we voor klanten bouwden. Bij Filplast hebben het CRM en het dealerportaal elk hun eigen authenticatie met gescheiden sessies, en is de data per dealer volledig afgeschermd. Bij Vlotverkocht zorgt een zogeheten outbox-patroon ervoor dat geen enkele stap in een dossier dubbel gebeurt of verloren gaat. Zulke onderdelen zie je niet in een demo. Je klant merkt ze pas als ze ontbreken.
Wil je een prototype laten doorbouwen tot iets dat blijft draaien, dan is dat waar maatwerk software laten ontwikkelen bij ons over gaat. We bouwen verder op een fundament dat bij ons al draait, dus niet vanaf nul, en de broncode is van jou.
Niet vanzelf. Vibe coding is een manier van bouwen; het risico zit in code die werkt maar niet is gecontroleerd op inloggen, rechten, sleutels en invoer. Laat die onderdelen nalopen door iemand anders dan de bouwer voordat er echte gebruikers of gegevens in komen.
Technisch kan dat vaak met een paar klikken. De vraag is of het verantwoord is. Loop minimaal inloggen en rechten, sleutels, database en back-ups, hosting, logging, updates en persoonsgegevens langs, en spreek af wie de app beheert.
Niet altijd. Is de basis goed opgezet, dan zijn dichtzetten, testen en beheer regelen genoeg. Is het vooral een werkend ontwerp, dan kan opnieuw bouwen op een bestaand fundament sneller zijn dan repareren. Een technische check van de code laat zien welke van de twee het is.
Dat kan, maar dan gelden dezelfde regels als voor elke andere software. Je bepaalt zelf welke beveiliging nodig is en moet kunnen aantonen dat de gegevens goed beveiligd zijn. Test daarom met nepgegevens en zet pas echte klantgegevens in de app als rechten, back-ups en logging geregeld zijn.
Twijfel je of jouw app al live kan, of wat er nog ontbreekt? Plan een gesprek en neem mee wat je hebt gebouwd.
De Quickscan duurt één uur. Jullie weten daarna precies wat er speelt, of jullie daarna klant worden of niet.
