AI bouwde de app in 10 minuten — maar is die klaar voor uw klanten?

De scène zal u misschien bekend voorkomen. Een directeur of manager verschijnt op een teamvergadering met een brede glimlach en een laptopscherm. "Ik heb gisteren een intern tool gebouwd met AI — in minder dan een kwartier!" De demo werkt vlekkeloos. Het heeft knoppen. Het slaat data op. Het ziet er zelfs redelijk professioneel uit. "We kunnen dit volgende week in productie zetten." En precies daar begint het probleem.

De demo-val: wat u ziet is niet wat uw klant ervaart

Een demo is per definitie optimistisch. U klikt op de happy path: de knoppen doen wat ze moeten doen, de data wordt opgeslagen, alles ziet er netjes uit. Wat u in die demo niet ziet, is wat er gebeurt als iemand een onverwachte invoer geeft, wat er gebeurt als tien collega's tegelijk inloggen, of — erger nog — wat er gebeurt als iemand met kwade bedoelingen uw tool een beetje te hard tegen de grenzen duwt.

AI-tools zijn bijzonder goed in het genereren van code die in de demo werkt. Ze zijn veel minder goed in het anticiperen op alles wat in de realiteit mis kan gaan. En dat is precies het onderscheid tussen een prototype en productie-klare software.

Vier dingen die AI consequent vergeet

1. Beveiliging: de voordeur zonder slot

AI genereert code die functioneel is — maar veiligheid is een ander verhaal. De meest voorkomende kwetsbaarheden uit de OWASP Top 10 duiken keer op keer op in AI-gegenereerde code: SQL-injectie (waarbij een kwaadwillende gebruiker via een invulveld rechtstreeks in uw database kan schrijven of lezen), cross-site scripting (waarbij een aanvaller kwaadaardige scripts injecteert die door andere gebruikers worden uitgevoerd), en ontbrekende authenticatiecontroles (waarbij bepaalde pagina's of API-endpoints gewoon publiek toegankelijk zijn, ook al hoorden ze dat niet te zijn).

AI stelt u zelden de vraag: "Wie mag dit zien? Wie mag dit aanpassen? Wat mag er absoluut nooit uitlekken?" Die vragen vereisen domeinkennis van uw organisatie — kennis die een taalmodel niet heeft.

2. GDPR en AVG: de wet die AI niet kent

Uw AI-tool slaat gegevens op. Maar van wie? Op welke server? Hoe lang? Wie heeft toegang? Wat als een medewerker ontslag neemt — worden zijn gegevens verwijderd? Is er een verwerkersovereenkomst nodig? Heeft de betrokkene toestemming gegeven?

De AVG (Algemene Verordening Gegevensbescherming) stelt duidelijke eisen aan elke applicatie die persoonsgegevens verwerkt. Die eisen gelden ook voor uw intern tool met vijf gebruikers. AI-gegenereerde code bevat standaard geen toestemmingsbeheer, geen data retention policies, geen audit logging en geen mechanisme om gegevens te exporteren of te wissen op verzoek van de betrokkene. De boetes voor overtredingen zijn reëel: tot 4% van de wereldwijde jaaromzet of 20 miljoen euro, afhankelijk van welk bedrag het hoogst is.

3. Schaalbaarheid: van demo naar tien gelijktijdige gebruikers

In de demo bent u de enige gebruiker. De database is leeg, de server heeft alle resources voor zich alleen en er is geen netwerklatentie. Dat verandert snel wanneer het tool in gebruik genomen wordt.

AI-gegenereerde code mist standaard kritieke elementen voor productiegebruik: database-indexen op vaak bevraagde kolommen, connection pooling zodat de database niet overbelast raakt, rate limiting om te voorkomen dat één gebruiker het systeem monopoliseert, en foutafhandeling die graceful degradeert in plaats van crashes. Een tool dat prima werkt voor drie gebruikers in een demo, kan volledig vastlopen bij tien gelijktijdige gebruikers in de praktijk.

4. Onderhoud: wie belt er om 3 uur 's nachts?

Het meest onderschatte probleem van AI-gegenereerde code is niet dat het niet werkt — het is dat niemand begrijpt hoe het werkt. De code is gegenereerd, gekopieerd en in productie gezet. Er zijn geen tests. Er is geen documentatie. Er is geen architectuurkeuze die bewust gemaakt werd.

Op de dag dat het tool breekt — en dat zal een keer gebeuren — staat u voor een onmogelijke taak. De persoon die het gebouwd heeft, was de AI. Die kunt u niet bellen. De manager die de demo toonde, begrijpt de onderliggende code niet. De IT-afdeling weet niet eens dat het tool bestaat. Gegenereerde code zonder begrip is technische schuld met rente.

Hoe een echte ontwikkelaar te werk gaat — en hoe lang dat duurt

Dit is geen pleidooi tegen AI. AI is een uitstekend hulpmiddel in de handen van een ervaren ontwikkelaar. Maar het vervangt het ontwikkelproces niet. Laten we dat proces concreet maken.

Stap 1 — Analyse en requirements (1 à 2 weken)

Voordat er één regel code geschreven wordt, stelt een goede ontwikkelaar vragen. Wie gebruikt het tool? Welke data wordt verwerkt? Zijn er integraties met bestaande systemen? Wat zijn de juridische randvoorwaarden? Wat moet het tool in de toekomst kunnen doen dat het vandaag nog niet hoeft te doen? Die gesprekken kosten tijd, maar ze voorkomen dat u halverwege de bouw ontdekt dat de fundamenten niet kloppen.

Stap 2 — Architectuur en datamodel (3 à 5 dagen)

Hoe wordt de data gestructureerd? Welke technologie past bij de vereisten? Hoe wordt het tool gehost en geback-upt? Hoe worden gebruikersrollen en rechten geregeld? Een goed datamodel aan het begin bespaart weken refactoring later.

Stap 3 — Ontwikkeling (2 à 8 weken, afhankelijk van complexiteit)

Hier schrijft de ontwikkelaar code — en ja, een goede ontwikkelaar gebruikt AI als hulpmiddel voor repetitieve taken en eerste drafts. Maar hij controleert wat gegenereerd wordt, past het aan aan de context, schrijft tests die verifiëren dat het correct werkt, en zorgt voor foutafhandeling die zegt "er ging iets mis" in plaats van gewoon te crashen.

Stap 4 — Security review en testing (1 week)

Een aparte ronde waarbij de code bewust bekeken wordt door de bril van een aanvaller. Zijn alle inputs gevalideerd? Zijn er endpoints die per ongeluk publiek zijn? Wat geeft de applicatie terug bij onverwachte invoer? Dit is de fase die bij AI-gegenereerde code volledig ontbreekt.

Stap 5 — Deployment en monitoring (2 à 3 dagen)

De applicatie in een veilige omgeving zetten, met automatische back-ups, foutlogging en monitoring zodat u weet wanneer er iets fout gaat — bij voorkeur vóórdat een gebruiker u dat meldt.

Stap 6 — Documentatie en overdracht (1 week)

Alles vastleggen: hoe het tool werkt, hoe het onderhouden wordt, hoe toegang beheerd wordt, wat de afhankelijkheden zijn. Zodat over twee jaar, als de originele ontwikkelaar er niet meer is, een andere professional het werk kan overnemen.

Totale doorlooptijd voor een eenvoudig intern tool: 6 tot 12 weken. Niet omdat ontwikkelaars traag zijn, maar omdat elk van die stappen een echte functie vervult die niet overgeslagen kan worden zonder risico's te nemen die u later cash gaan kosten.

AI als copiloot, niet als piloot

De juiste conclusie is niet dat AI nutteloos is. Integendeel — een ervaren ontwikkelaar die AI gebruikt, werkt sneller dan ooit tevoren. Maar er is een cruciaal verschil: die ontwikkelaar weet wat hij controleert, wat hij aanpast en wat hij weggooide uit de gegenereerde output. Hij gebruikt AI als een gereedschap, niet als een oordeel.

Een directeur die een demo bouwt in tien minuten, heeft iets bereikt wat vijf jaar geleden onmogelijk was. Dat is indrukwekkend. Maar een demo is een startpunt, geen eindpunt. De vraag is niet of AI code kan genereren — dat kan het. De vraag is of die code veilig, schaalbaar, onderhoudbaar en wettelijk conform is. En dat antwoord vereist iemand die weet wat die woorden betekenen.

Heeft u een intern tool dat door AI gebouwd of voorgesteld werd en wilt u weten of het productie-klaar is? Of wilt u van bij het begin een stevige basis? Neem contact op — een eerlijk gesprek over uw specifieke situatie kost niets en levert altijd iets op.