De drempel om een app te bouwen is ingestort, de drempel om gebruikersdata aan te raken niet

E-commerce-platformleiders hebben me de afgelopen tijd allemaal hetzelfde gevraagd: de businesskant kan met AI in één week drie interne tools in elkaar zetten, terwijl de IT-ontwikkelingsplanning nog tot volgende kwartaal loopt. Waar zit nou precies de bottleneck?

Ons antwoord is één enkele stelling: de drempel om te ontwikkelen is ingestort, de drempel om gebruikersdata aan te raken niet.

Achter deze uitspraak schuilen twee dingen die tegelijkertijd gebeuren.

Bolt.new is gemaakt door StackBlitz en werd in oktober 2024 stilletjes gelanceerd via een tweet. Binnen vijf maanden zat het bedrijf op 40 miljoen dollar aan ARR. Sacra en Growth Unhinged volgen het als het op één na snelst groeiende product ooit (alleen ChatGPT groeide sneller). Bij de afsluiting van het fiscale jaar 2026 liet StackBlitz-CEO Eric Simons op LinkedIn weten: driekwart van de Fortune 500 gebruikt inmiddels Bolt.new, en de enterprise-ARR is jaar-op-jaar vertienvoudigd (officiële post van Eric Simons, afsluiting fiscaal jaar 2026). Lovable is een team uit Stockholm, Zweden (oprichter Anton Osika). In november 2025 haalde het bedrijf 200 miljoen dollar op in een Serie A tegen een waardering van 1,8 miljard dollar; eind december 2025 volgde een Serie B tegen 6,6 miljard dollar — een bijna verviervoudiging in een half jaar tijd (bevestigd door Forbes, CNBC, Bloomberg en TechCrunch). In juni 2026 brak Lovable door de 500 miljoen dollar aan ARR (Forbes, met bevestiging door TechCrunch op 09-06-2026). Forbes citeerde diezelfde dag vier ingewijden die stellen dat het bedrijf een nieuwe financieringsronde voorbereidt tegen een waardering van 12 miljard dollar (ruwweg een verdubbeling). Dit soort tools comprimeert het bouwen van een applicatie van “een paar mensen, een paar maanden” naar “één persoon, één middag”.

Maar terwijl de toetredingsdrempel voor ontwikkeling instort, zijn de drempels die er in jouw bedrijf echt toe doen en die écht tijd kosten, geen millimeter opgeschoven: de beoordeling van grensoverschrijdende dataoverdracht, de classificatie- en beveiligingstest (等保测评, een verplichte Chinese cybersecurity-assessment), de algoritmeregistratie, de change-approval (Change Advisory Board) en de reconciliatie-audit. Deze drempels hebben vrijwel niets met code te maken, maar kosten elk enkele weken. App-generatoren hebben de eerste deur opengebroken: de business kan nu zelf applicaties bouwen. Maar de tweede deur — wie toegang krijgt tot productiedata en wie kern-transacties mag wijzigen — is geen millimeter opgeschoven.

Daardoor ontstaat een risico dat de meeste beslissers nog niet op de radar hebben: wie een app kan bouwen, is nog niet gemachtigd om die app legaal aan data te koppelen.

Een reële situatie die wij begeleidden (e-commerce, geanonimiseerd): De creator-marketingafdeling van een woonwinkel-e-commercebedrijf bouwde in twee maanden tijd zelf zeven interne tools met Lovable: creator-matching, commissieberekening, trendtracking voor bestsellers en retourtoewijzing. Niemand informeerde de technische afdeling. Bij de halfjaarlijkse shadow-IT-inventarisatie bleek dat vier van die tools een brede ordertabel met telefoonnummers en bezorgadressen uitlezen, en dat twee tools data exporteerden naar persoonlijke cloudopslag. Dit is sinds de tweede helft van 2025 een veelvoorkomend beeld bij asset-inventarisaties door e-commerce-platformteams — geen incidenteel geval.

Een reële situatie die wij begeleidden (telecomoperator, geanonimiseerd): Bij een interne trainings-evaluatie in een regionale divisie van een provinciale operator gaf de projectmanager van de marketingafdeling toe dat zij met Bolt al een “snelle klantprofiel-querytool” hadden gebouwd: invoeren van een telefoonnummer levert direct de afgelopen 90 dagen aan abonnementswijzigingen, klachtenhistorie en aanbevolen actietabellen op — de technische afdeling was hier volledig van onkundig. Dit raakt direct de rode lijn van de Cybersecuritywet en de Wet Bescherming Persoonsgegevens (PIPL) met betrekking tot toegangsrechten voor het opvragen van persoonsgegevens.

Bekijk eerst een afbeelding om te zien hoe deze blootstelling eruitziet.

Twee drempels: één valt, één houdt stand Hoog Laag 2020 2024 2026 Drempelhoogte Ontwikkeldrempel (code schrijven) AI-generator: één middag Compliance-drempel (data-export / MLPS / algoritmeregistratie / wijzigingsgoedkeuring / reconciliatie) Nauwelijks bewogen Risicoblootstelling Afstand tussen twee drempels = Mensen die apps kunnen bouwen Mogelijk niet bevoegd om data aan te raken Sneller ontwikkelen ≠ sneller leveren — de onbeweeglijke rode lijn boven is de bottleneck

Hieronder wordt het stap voor stap uitgesplitst: welk probleem van wie deze tools oplossen, hoe de rol van engineers verandert, hoe schaduwapps in e-commerce eruitzien, welke hobbels sterk gereguleerde sectoren écht tegenkomen, en hoe je een compliance-kanaal voor de business creëert.

1. Deze vijf tools eerst op hun juiste plek zetten

Veel mensen gooien al deze tools op één hoop en noemen het ‘AI-programmeren’. Maar ze bedienen twee totaal verschillende doelgroepen. Wie dat onderscheid helder heeft, kan pas echt goede keuzes maken.

De ene groep: ‘mensen die kunnen programmeren’. Zij willen een snellere code-editor: eentje die de context van hun codebase begrijpt, wijzigingen doorvoert over meerdere bestanden heen, tests automatisch draait en foutmeldingen uitlegt. Denk aan Cursor, Trae van ByteDance, Tongyi Lingma van Alibaba, en GitHub Copilot. Het uitgangspunt is dat je zelf al verstand van techniek hebt; de tool bespaart je het repetitieve werk. Deze groep hebben we in deel vier van deze serie al behandeld, dus daar duiken we hier niet verder in.

De andere groep: ‘mensen die niet kunnen programmeren’. Dat is het onderwerp van dit artikel: app-generatoren. Je typt in één zin in het Nederlands wat je wilt, en je krijgt direct een werkende applicatie: frontend, backend, database, deployment — alles in één keer geregeld. Er wordt niet van je verwacht dat je kunt programmeren.

Voor dit artikel hebben we vier app-generatoren geselecteerd. Daarnaast behandelen we Trae apart uit de AI IDE’s, omdat die precies raakt aan een punt dat cruciaal is voor sterk gereguleerde sectoren.

Bolt.new (van StackBlitz). In oktober 2024 stil gelanceerd via een enkele tweet, door Sacra en Growth Unhinged bestempeld als het op één na snelst groeiende product ooit (alleen achter ChatGPT): binnen de eerste week $1M ARR, na vier weken $4M, na ongeveer twee maanden $20M, na vijf maanden $40M, met circa 5 miljoen geregistreerde gebruikers (volgens openbare uitspraken van de StackBlitz CEO). De onderliggende technologie heet WebContainers en draait een volledige Node.js-omgeving in de browser, waardoor AI direct bestanden kan bewerken, pakketten kan installeren en services kan starten — zonder dat jij lokaal iets hoeft in te stellen. Aan het einde van fiscaal jaar 2026 gebruikte driekwart van de Fortune 500 Bolt.new, en verdrievoudigde de enterprise-ARR ruimschoots op jaarbasis (officiële post van Eric Simons op LinkedIn, afsluiting fiscaal jaar 2026). StackBlitz haalde in januari 2025 een Serie B van $105,5M op, tegen een waardering van circa $700M (o.a. Business Insider). Typisch gebruik: een kleine app of landingspagina bouwen die je direct in de browser kunt openen en bekijken.

Lovable (Stockholm, Zweden; opgericht door Anton Osika; voortgekomen uit het open-sourceproject GPT Engineer). Hun aanpak: van één zin naar een volledig deploybare applicatie, gepositioneerd dichter bij volwaardige bedrijfsapplicaties dan Bolt. In november 2025 haalden ze $200M op in een Serie A-ronde tegen een waardering van $1.8B; eind december 2025 volgde een Serie B van $330M tegen een waardering van $6.6B — de waardering verviervoudigde bijna in een half jaar tijd. In juni 2026 brak de ARR door de $500M (gerapporteerd door Forbes op 2026-06-05, tegelijkertijd ook door TechCrunch opgepikt). Op dezelfde dag citeerde Forbes vier ingewijden die stelden dat het bedrijf een nieuwe financieringsronde voorbereidt tegen een waardering van ongeveer $12B (ruwweg een verdubbeling; Forbes/Rashi Shrivastava). Tot de enterprise-klanten van Lovable behoren inmiddels Workday, Asana en NVIDIA (samengevat door ARR.club, 2026).

Vercel v0. Gelanceerd in oktober 2023, officieel hernoemd van v0.dev naar v0.app op 3 februari 2026. Geëvolueerd van een UI-componentenscaffolder naar een full-stack applicatiegenerator (sandbox-runtime + GitHub-integratie + Snowflake/AWS-database-integratie). Volgens officiële Vercel-cijfers van maart 2026 gebruiken meer dan 6 miljoen ontwikkelaars het platform, met ongeveer 80.000 actieve teams per maand (concurrentieanalisten schatten de ARR op circa $42M, samengevat door Taskade in maart 2026).

Replit Agent 4. Uitgebracht op 13 maart 2026, de belangrijkste update in Replit’s geschiedenis. Drie dingen veranderden tegelijk: ① Design Mode werd Infinite Design Canvas, waarmee je kunt ontwerpen en tegelijkertijd code kunt aanpassen; ② samenwerking veranderde van fork-and-merge naar “zelfde project, multi-threaded taken” — meerdere sub-agents draaien parallel, en een speciale conflict-oplossende sub-agent voegt de resultaten automatisch samen. Officiële cijfers: Agent 4 lost 90% van de merge-conflicten automatisch op (AlphaSignal 2026, bevestigd in Replit’s officiële changelog van maart 2026); ③ planning en uitvoering zijn niet langer sequentieel — je kunt plannen terwijl je bouwt. In dezelfde periode haalde Replit een Serie D-financiering op met een waardering van bijna $9 miljard (Atal Upadhyay 2026; meerdere bronnen zoals TechCrunch/Bloomberg bevestigen dit). Replit begon als online programmeeromgeving en heeft daardoor samenwerking en hosting in het DNA zitten. Met Agent 4 is “met een paar mensen samen een product bouwen” teruggebracht tot de snelheid van een individuele developer.

De gemene deler van deze vier: de kosten van “een app bouwen” gaan van team-maanden naar individuele uren.

Trae verdient een aparte bespreking, omdat het voor enterprise-klanten in telecom, financiën en e-commerce een concreet leveranciersrisico vormt. Trae is qua vorm een IDE (editor), maar in wezen een ontwikkelomgeving die onlosmakelijk verbonden is met de servers van ByteDance. Voor bedrijfsgebruikers moet het daarom niet worden behandeld als een ‘gewone IDE’, maar als een ‘tool voor data-uitwisseling naar het buitenland’ die een grondige toegangsbeoordeling vereist. ByteDance lanceerde Trae in januari 2025, met Cursor als directe concurrent. De strategie: hoogwaardige modellen zoals Claude en GPT-4o gratis aanbieden. Binnen 12 maanden registreerden 6 miljoen gebruikers zich, waren er 1,6 miljoen maandelijkse actieve gebruikers en werden er in totaal ongeveer 100 miljard regels code gegenereerd (samengevat uit onderzoek van OpenAI Tools Hub, mei 2026). Maar in juli 2025 publiceerde de securityonderzoeker segmentationf4u1t het project telemetry_research, waarmee werd bewezen dat Trae, zelfs als je telemetrie in de instellingen uitschakelt, op de achtergrond continu gegevens blijft verzenden naar servers van ByteDance, waaronder mon-va.byteoversea.com – met inbegrip van hardware-informatie, besturingssysteemversie, permanente apparaat- en machine-ID’s en projectactiviteitsgegevens. Een enkele telemetrie-batch kan maximaal 53.606 bytes groot zijn; ongeveer 7 minuten normaal gebruik genereert 500+ aanroepen en circa 26 MB aan data (primaire data van GitHub segmentationf4u1t/trae_telemetry_research; gerapporteerd door The Register/Cybernews op 28-07-2025).

De reactie van ByteDance achteraf is het waard om vast te leggen. In een update van 2026-08-01 schrijft Cybernews: ByteDance erkent in een officiële verklaring dat de telemetry-toggle in de IDE-instellingen alleen de telemetrie van het VS Code-gedeelte beheert; de datacollectie van andere Trae-functionaliteiten wordt niet door deze schakelaar beïnvloed — in gewone mensentaal: je dacht dat je het had uitgeschakeld, maar dat was niet zo. Onderzoekers bevestigden na direct contact met het Trae-team dat er een aparte Privacy Mode gepland staat voor rond augustus 2026. Tegelijkertijd doorbrak Trae in februari 2026 de “forever free”-belofte met een token-based paywall, waardoor veel ontwikkelaars die het in hun productieomgeving hadden opgenomen opnieuw gingen evalueren (samengevat in een onderzoek van OpenAI Tools Hub, mei 2026).

Voor individuele ontwikkelaars is de gratis Claude best aantrekkelijk. Voor jou als beslisser is dit echter een klassiek vraagstuk rond grensoverschrijdende data-uitwisseling: je engineers voeden een tool met bedrijfscode, en mogelijk ook configuraties en interfaces, die data terugstuurt naar servers van ByteDance. In sectoren als telecom en financiën, die onder de Dataveniligheids wet (Data Security Law) en de Persoonlijke informatiebeschermingswet (Personal Information Protection Law) vallen, is deze stap op zichzelf al voldoende om een compliance-incident te triggeren. Sectie 4 gaat hier dieper op in.

2. Ontwikkeling herschreven: van ‘code schrijven’ naar ‘beoordelen, orkestreren, bewaken’

App-generatoren worden het makkelijkst verkeerd begrepen als ‘we hebben straks geen engineers meer nodig’. Die richting klopt niet.

De juiste formulering is: het verandert de focus van het werk van de engineer, het schaft de functie niet af. Wanneer AI en zakelijke gebruikers zelf code en applicaties kunnen produceren, verschuift de waarde van de engineer van ‘zelf schrijven’ naar drie dingen: beoordelen of die output klopt, deze orkestreren tot betrouwbare systemen, en de poortwachter zijn voor veiligheid en kwaliteit.

Deze drie dingen zijn schaarser dan ‘code schrijven’, en ook meer waard. Mensen die een React-component kunnen schrijven zijn er genoeg; mensen die kunnen beoordelen of een door AI gegenereerde promotie-app aan productiegegevens mag raken, of de authenticatie niet nep is, of er geen logs naar buitenlandse diensten worden gestuurd — die zijn veel schaarser.

Hier moet een duidelijke gelaagde beoordeling komen, omdat te veel bedrijven in dit vraagstuk doorschieten naar extremen: óf ze durven alles aan de generator toe te vertrouwen, óf ze verbieden het volledig. Beide extremen kosten geld.

Welke apps aan de generator, welke nooit Lage complexiteit ←────────────→ Hoge complexiteit Data-gevoeligheid: laag ↑ hoog ↓ Geef ze gerust aan de generator Landingspagina's, campagnepagina's Interne dashboards zonder gevoelige data (geen login, alleen lezen) Prototype / demo Vereist: gemaskeerde data + compliant kanaal Probeer het, maar engineering nemt het over Interne ops-tools (raken orders / voorraad) Werkplek van accountmanager B-kant selfservice-backend Vereist: prototype door generator, herschreven door engineering voor productie Generator bouwt, sterke governance vangt Frontend van knowledgebase klantenservice Opvraagpagina's met persoonsgegevens Interne portals met login (gebruikersidentiteit + rechtenniveaus) Vereist: authenticatie, audit, MLPS — niets mag ontbreken Nooit aan de generator geven Handelssystemen / betaling / verrekening Risico-engine / anti-fraude Kernboekhouding / regelgevende rapportage Vereist: professioneel engineeringteam, end-to-end bewaking Criterium: x-as = logische complexiteit, y-as = of het geld of persoonsgegevens raakt

Deze afbeelding wil maar één ding zeggen: de horizontale as toont hoe complex de logica van de applicatie is, de verticale as of het geld en persoonlijke gegevens raakt. In het vak rechtsonder (hoog complex plus hoog gevoelig) komt de app-generator er nooit aan te pas, hoe slim ook. Een promotielandingspagina aan Lovable toevertrouwen is prima; je betaalgateway eraan toevertrouwen — dan is het alleen een kwestie van tijd voordat het misgaat.

Neem die rode lijn goed in je op, en kijk dan naar wat er in e-commerce gaande is.

3. De echte pijn in e-commerce: schaduwapplicaties raken orderdata

Even inzoomen. Gartner gooide in de tweede helft van 2025 een opvallend cijfer op tafel: tegen eind 2026 zal 40% van de bedrijfsapplicaties taakspecifieke AI-agents bevatten, tegen minder dan 5% in 2025 (officiële Gartner-prognose, eveneens gepubliceerd door Process Excellence Network op 27-08-2025). Daarbij hoort een nog opvallender cijfer: Gartner rapporteert een groei van 1445% in adviesaanvragen over multi-agent-systemen tussen Q1 2024 en Q2 2025 — het snelst groeiende onderwerp binnen Gartners AI-advisory-tak, zonder uitzondering (samengevoegd uit RAPIDCLAW/Hendricks.ai/Arion Research).

Vertaal deze twee getallen naar de taal van e-commerce: 40% van de bedrijfsapplicaties draait AI-agents, plus een tweede cijfer — de vraag naar advies over multi-agent systemen bij bedrijven is met +1445% gestegen (gemeten naar de groei van Gartner AI-advisory-opdrachten, niet naar implementaties, maar het richtinggevende signaal is duidelijk): AI-agents zijn verschoven van “helpen met code schrijven” naar “meerdere agents die samenwerken en een volledig bedrijfsproces doorlopen”. Wanneer AI-agents daadwerkelijk in bedrijfsapplicaties worden ingezet, data raken, processen doorlopen en logs schrijven, verandert de aard van app-generatoren van “tool” naar “systeem”.

Onderzoeksbureau UpGuard publiceerde in 2025 een rapport (State of Shadow AI, besproken door Cybersecurity Dive) met twee cijfers die nog opvallender zijn dan Gartners 40%: meer dan 80% van de medewerkers gebruikt niet-goedgekeurde AI-tools op het werk, en zelfs binnen securityteams doet bijna 90% dit. En dan is er nog dit: ongeveer de helft van de medewerkers geeft toe bedrijfsgevoelige data direct in die niet-goedgekeurde tools te plakken. Mimecast komt uit op 51%, Teramind op 49% — dezelfde orde van grootte. Gartner voegt daar nog een ander cijfer aan toe: 69% van de organisaties vermoedt of bevestigt dat medewerkers verboden AI-tools gebruiken, terwijl slechts 37% van de organisaties een AI-gebruiksbeleid heeft (via The Hacker News).

Vertaal deze cijfers naar de taal van e-commerce: jouw operations, jouw marketing, jouw campagneplanners bouwen met tools als Bolt, Lovable en v0 zelf applicaties in elkaar. Een configuratietool voor promotieregels, een dashboard voor het selecteren van influencers, een mini-app voor voorraadinzage, een tool voor het doorzetten van after-sales tickets. Ze zijn snel, gebruiksvriendelijk en lossen echte problemen op. En ze gaan vrijwel allemaal volledig langs IT en datagovernance heen.

H1 2026: vier cijfers tonen hoe dringend het is 5% Enterprise-apps 2025 met ingebedde AI-agenten 40% Verwachting 2026 Gartner 2025-08 +1445% Enterprise-vragen Multi-agent 2024Q1→2025Q2 80%+ Medewerkers die niet-goedgekeurde AI-tools gebruiken (UpGuard 2025) ~50% Medewerkers die vertrouwelijke data in deze tools plakken Enterprise-apps volledig agent-gebaseerd + medewerkers die privé AI gebruiken = schaduw-apps blijven zich vermenigvuldigen Venster van besluitvormers: 3-6 maanden Gartner-waarschuwing: bepaal nu uw AI-agentstrategie, anders laten snellere concurrenten u achter Data zijn representatief;methodologieën variëren, richting is consistent

Een reële casus die we begeleidden (e-commerce, geanonimiseerd): Vanaf de tweede helft van 2025 voerden we bij vier middelgrote tot grote e-commercebedrijven (platformteams van 50–200 personen) een inventarisatie uit van shadow IT. Geen enkel bedrijf kwam er blanco uit. Het meest typerend was een woninginrichting-e-commercer: binnen twee maanden had het team voor content creators zeven interne tools gebouwd met Lovable. Vier daarvan draaiden op brede ordertabellen (met telefoonnummers en verzendadressen), en twee exporteerden data naar persoonlijke cloudopslag. Op de dag van de inventarisatie zei de securityverantwoordelijke: „We hebben er bijna voor gekozen om niet verder te gaan met de inventarisatie — uit angst dat niemand de uitkomsten zou durven oppakken.”

Je zou dit ‘dataschaduw-IT’ kunnen noemen. De afgelopen tien jaar hadden we het vooral over shadow IT in de vorm van zelf aangeschafte SaaS door businessafdelingen (verkoop koopt een CRM, marketing koopt een e-mailtool). Nu is shadow IT een applicatie die de businessafdeling zélf bouwt. Er wordt een niet-goedgekeurd tool gebruikt — en erger nog: er ontstaat een nieuw systeem dat met gevoelige data werkt, maar nergens op de IT-activiteitenlijst staat.

Het verschil zit in de schaal: een SaaS aanschaffen is een extern systeem aansluiten; met een app-generator bouw je intern een hele reeks nieuwe systemen, elk met eigen data-interfaces en elk potentieel toegankelijk vanaf het internet. Op jaarbasis kan een e-commercebedrijf zo honderden applicaties extra krijgen, zonder dat er ook maar één op de IT-activiteitenlijst staat.

Dit valt niet tegen te houden. Die 80% van UpGuard zegt genoeg: “verbieden” werkt niet. Mensen pakken het gereedschap dat het makkelijkst werkt om hun werk af te krijgen — dat is menselijke natuur, en het is KPI. Dus stel niet de vraag “hoe zorgen we dat de business geen generatieve tools gebruikt”, maar “hoe zorgen we dat ze het veilig doen”. Sectie 4 gaat over de compliance-drempels, sectie 5 over hoe je de kanalen inricht.

Vier: welke compliance-drempels zijn er — beschouw ze niet als een test

Dit is het onderdeel dat in dit artikel het duidelijkst moet zijn, en ook het onderdeel waar het snelst fouten worden gemaakt.

Veel mensen met een achtergrond bij internetbedrijven denken bij “quality gates” automatisch aan geautomatiseerde tests in CI/CD: unit tests draaien, integratietests draaien, regressietests draaien, groen licht en door. Tech-teams die bij e-commercebedrijven de piekbelastingen draaien, kennen dit spelletje goed.

Maar in telecom, financiële dienstverlening, gereguleerde productie en e-commerce gaat “validatie” veel verder dan testen. De echte bottlenecks zijn een aantal poorten die vrijwel niets met de code zelf te maken hebben, maar elk wel enkele weken in beslag nemen. Om die als “tests” te omschrijven is een internetbedrijven-bril die beslissers op het verkeerde been zet over de doorlooptijd.

We lopen ze één voor één langs.

Beoordeling grensoverschrijdende dataoverdracht.[^1] Als jouw applicatie gebruikmaakt van AI-diensten uit het buitenland (veel generatieve modellen draaien op backend-infrastructuur van OpenAI of Anthropic), of als engineers een IDE zoals Trae gebruiken die data naar servers buiten China stuurt, dan gelden de eisen voor data-uitvoer uit de Datavelligheidswet en de Persoonlijke Informatiebeschermingswet — zolang er persoonsgegevens of bedrijfsgevoelige data in het spel zijn. Een volledige beoordeling van grensoverschrijdende dataoverdracht of het doorlopen van een standaardcontracttraject duurt al snel één tot twee maanden, maar kan ook een half jaar of langer in beslag nemen. De bevinding dat Trae nog steeds data verzendt, zelfs nadat telemetrie is uitgeschakeld, betekent dat je er niet vanuit kunt gaan dat er niets wordt verstuurd — ook al denk je van wel. In sterk gereguleerde sectoren hoort zo’n tool simpelweg niet thuis in de ontwikkelomgeving.

Classificatie- en beveiligingstest (MLPS / Dengbao).[^2] Onder de Cybersecuritywet geldt het classificatiestelsel (Multi-Level Protection Scheme 2.0). Een applicatie die gericht is op het publiek valt vrijwel zeker in niveau drie. Het volledige traject — classificatie, registratie, aanpassingen en audit — neemt doorgaans drie tot zes maanden in beslag. Dit is een wettelijke verplichting, geen optie. Een AI-gegenereerde applicatie krijgt geen vrijstelling van deze eisen, hoe snel je ook ontwikkelt.

Algoritmeregistratie.[^3] Als jouw applicatie publiek toegankelijk is en gebruikmaakt van generatieve AI (bijvoorbeeld automatisch gegenereerde productbeschrijvingen, geautomatiseerde klantenservice, of AI-gegenereerde content in gepersonaliseerde aanbevelingen), dan ben je op grond van de Tijdelijke Beheersmaatregelen voor Generatieve AI-diensten en de regelgeving rond algoritmische aanbevelingen verplicht om het algoritme te registreren. Live gaan zonder registratie is een compliance-incident.

Wijzigingsgoedkeuring (CAB) en terugdraaiplannen.[^4] Voor de kernsystemen van financiële instellingen en telecombedrijven moet een release door de Change Advisory Board worden goedgekeurd: impactanalyse, terugdraaiplan, bevestiging van het wijzigingsvenster. Wat hier wordt verbruikt is kalendertijd, geen machinetijd — als je dat venster mist, wacht je tot volgende week.

Afstemming en audit.[^5] Na een grote promotiecampagne in e-commerce of na de afwikkeling van betalingen in de financiële sector, moeten systemen worden afgestemd met de geldstromen en met upstream-partijen, en moet er een audittrail zijn waarmee elke transactie kan worden herleid. AI-gegenereerde applicaties schieten hier vaak tekort: ze draaien wel, maar er is geen afstemming ontworpen, en bij verschillen in de boekhouding is er geen spoor terug te vinden.

Zet dit alles op een rij, en je komt tot een contra-intuïtieve conclusie: app-generatoren versnellen de weg van “idee” naar “werkende prototype” met een factor tien, maar van “werkende prototype” naar “compliance-goedgekeurde livegang” bespaar je geen seconde. Die hordes kosten evenveel tijd als voorheen.

Dat is de rode lijn die in de grafiek in sectie één niet bewoog. De ontwikkeldrempel is ingestort — wat je bespaart is de tijd die engineers aan code besteden; de compliancedrempel is onveranderd — de evaluaties, assessments en goedkeuringen blijven evenveel dagen in beslag nemen. De grootste misvatting van beslissers is dat versnelling van het eerste automatisch leidt tot versnelling van het tweede. Dat gebeurt niet.

Vijf: geef de business een compliance-kanaal, laat het niet wild groeien

Als je het niet kunt tegenhouden, geef het dan een kanaal — dit is een van de weinige paden die werken bij het beheersen van shadow IT.

Twee paden voor shadow IT: als je het niet kunt blokkeren, geef het een kanaal Vandaag: wilde groei Operations bouwt zelf apps met Lovable ↓ niemand weet het Raakt orders / telefoonnummers / adressen ↓ geen registratie Data geëxporteerd naar persoonlijke clouds ↓ geen scan Pas ontdekt na een lek Honderden apps draaien, geen in de inventarislijst → Bestuurd: een snel kanaal Bedrijf levert een goedgekeurde generator ↓ zelfregistratie (5 minuten) Data getrapt: alleen gemaskeerd / testdata ↓ automatische beveiligingsscan Raakt gevoelige data → exportbeoordeling + MLPS ↓ in de inventarislijst Auditbaar, uit te schakelen, traceerbaar Business blijft snel, maar elke app staat op de lijst

Hoe bouw je zo’n kanaal concreet op? In vier stappen.

Stap één: het bedrijf levert zelf een beveiligde, goedgekeurde generator. In plaats van dat medewerkers buiten de organisatie om met willekeurige tools als Lovable aan de slag gaan, koopt of bouwt het bedrijf een eigen versie die voldoet aan de Chinese beveiligings- en compliance-eisen (等级保护, classificatie ter bescherming van informatie) en waarbij data binnen de landsgrenzen blijft. Deze versie krijgt een interne toegangspoort. Als de businesskant ermee uit de voeten kan, zoeken ze buiten niets meer op — dit is de ‘verleiding’ naast de ‘verboden toegang’. Microsoft FY26 biedt hier een referentievoorbeeld: EY rolde Copilot uit naar 150.000 medewerkers en boekte een productiviteitswinst van 15%; Atos implementeerde Copilot bij 56.000 medewerkers in 54 landen en beheert 19.000 AI-agents onder één controlevlak voor identiteit, beveiliging, compliance en agent-governance (Microsoft FY26-terugblikblog 2026-07-28, Atos officieel persbericht 2026-06-09; beide zijn gezamenlijke verklaringen van leverancier en klant). Wat deze twee gemeen hebben: ze hebben AI-tools aangesloten op het enterprise-grade beveiligings- en compliance-controlevlak — precies dat is een werkend voorbeeld van een ‘goedgekeurd kanaal’. In China zijn er vergelijkbare richtlijnen, zoals de ‘Compliance-richtlijn voor AI-toepassingen in de financiële sector’ van het Financiële Informatie- en Communicatie-instituut en de compliance-trajecten binnen het ‘AI voor nieuwe industrialisatie’-programma van het Ministerie van Industrie en Informatietechnologie. Het lokale pad ligt er al; wat ontbreekt, is de inbedding in de verplichte bedrijfsprocessen.

Stap twee: verplichte registratie. Wie heeft de app gebouwd, welke data worden uitgelezen, voor welke gebruikers is die bedoeld — alles gaat in één register. Houd de registratie licht: een formulier van vijf minuten, geen traject dat twee maanden duurt. Anders vult niemand het in en verdwijnt alles weer onder de radar. Het doel van registratie is niet om elke app goed te keuren, maar om een overzicht te hebben.

Stap drie: routering op basis van dataclassificatie. Gebruik de matrix uit sectie twee. Apps die alleen met geanonimiseerde of testdata werken, worden automatisch goedgekeurd. Zodra een app toegang vraagt tot echte orders of persoonsgegevens, worden automatisch een voorafgaande beoordeling van grensoverschrijdende dataoverdracht en een classificatiebeoordeling (等保测评, vergelijkbaar met een NIS2-compliancecheck) geactiveerd. Laat het proces de gevoeligheid van de data volgen, in plaats van één generieke maatregel op alle apps toe te passen.

Stap vier: automatische beveiligingsscanning. AI-gegenereerde applicaties bevatten aanzienlijk meer kwetsbaarheden dan handgeschreven code. CodeRabbit heeft dit cijfer in 2026 bijgewerkt: AI-ondersteund gegenereerde code bevat 1,7 keer zoveel problemen (inclusief logische en correctheidsbugs) als traditioneel handgeschreven code (CodeRabbit’s eigen meetmethode, inclusief commercieel perspectief; bevestigd door de DORA-webinar van februari 2026 en de vergelijkende evaluatie van Kunal Ganglani in 2026). Het GenAI-codebeveiligingsrapport van Veracode uit 2025 is nog directer: in de door hen geteste steekproeven bevatte ongeveer 45% van de AI-gegenereerde code kwetsbaarheden op het niveau van de OWASP Top 10 (bij Java gegenereerde code lag het faalpercentage boven de 70%, Veracode’s eigen meetmethode, inclusief commercieel perspectief). Een grootschalige empirische analyse van openbare GitHub-repositories (arXiv:2510.26103) bevestigt dezelfde richting. Dus deze scanstap is verplicht voor AI-gegenereerde applicaties, niet optioneel. Integreer SAST, dependency scanning en secrets detection in het releaseproces van de generator; alleen bij een groene vlag wordt vrijgegeven. CodeRabbit is in juni 2026 openbaar bevestigd als de meest geïnstalleerde AI-codebeoordelingstool op GitHub/GitLab, met meer dan 15.000 betalende klanten en 6 miljoen beoordeelde repositories. Zelfs NVIDIA-CEO Jensen Huang heeft openlijk verklaard: “Het hele bedrijf bij NVIDIA gebruikt CodeRabbit” — het is redelijk om dit als een basisreferentiekader te beschouwen voor enterprise-grade AI-kwaliteitspoorten.

Deze vier stappen zorgen ervoor dat de snelheid aan de businesskant vrijwel gelijk blijft, maar elke applicatie komt op een auditabele lijst te staan. Applicaties die met gevoelige data werken, worden tegengehouden en moeten door een formele beoordeling. Dit is governance, geen vertraging.

Hier moet ik een veelverspreid cijfer rechtzetten. In een eerdere versie stond “45% shadow AI adoption rate”. Dat is een verkeerde toeschrijving. Die 45% is het defectpercentage van AI-gegenereerde code uit het Veracode-rapport, niet de adoptiegraad van tools. Voor shadow AI-adoptie moet je kijken naar die 80%+ van UpGuard. Die twee cijfers gaan over totaal verschillende zaken; haal ze niet door elkaar.

Zes. Wanneer je géén app-generator moet gebruiken

Het is geen wondermiddel. Vier typische vormen van verkeerd gebruik, en we hebben ze allemaal gezien bij klanten die wij bedienen.

Voor kerntransacties of risicobeheer. Dit is de gevaarlijkste vorm. Sommigen denken: “De generator is zo sterk, laten we de betaalgateway er ook eens doorheen gooien.” De rechterbenedenhoek van die matrix is de rode zone: complexe logica plus geld. Dat aan een generator overlaten, staat gelijk aan het overhandigen van je kernsystemen aan een stagiair die nergens verantwoordelijk voor is. Bij een financieel incident is er geen reconciliatie, geen audit, geen rollback-plan.

Door AI gegenereerde code is standaard veilig? CodeRabbit’s 1,7x en Veracode’s 45% hebben dat antwoord al gegeven. Tussen “ziet er werkend uit” en “is veilig werkend” zit een complete security engineering-cyclus. AI-gegenereerde applicaties anders behandelen dan handgeschreven code en lagere beveiligingsnormen hanteren, is sneller meer kwetsbaarheden creëren.

Persoonsgegevens verwerken via buitenlandse generatoren zonder exportbeoordeling. Dit is vooral subtiel in e-commerce: een marketingcampagnepagina voor consumenten, backend roept OpenAI aan voor tekstgeneratie, en het telefoonnummer dat de gebruiker invult, gaat stilletjes mee naar een buitenlandse dienst. Daarmee wordt de rode lijn van de Persoonsgegevensbeschermingswet (PIPL) overschreden. Als het misgaat, is het een datalek-incident, geen technische bug.

Trae en andere IDE’s met data-export standaard installeren voor alle engineers. De verleiding van gratis high-end modellen is groot; engineers installeren het uit zichzelf. Zodra je kerncode, configuraties en API’s op de servers van ByteDance (of een andere buitenlandse entiteit) staan, is herstel te laat. Zulke tools in de ontwikkelomgeving vereisen een toelatingsbeoordeling samen met security en legal — dat is geen beslissing die het techteam alleen kan nemen.

7. Door de lens van vier sectoren: welke toepassingen kunnen wel, welke absoluut niet

Deze sectie richt zich op 4 sectoren waarin we bedrijven door echte valkuilen hebben begeleid (e-commerce / financiële dienstverlening / telecom / productie). Overheid, zorg en andere sterk gereguleerde sectoren behandelen we apart in een ander artikel en komen hier niet aan bod.

Laten we de lens richten op de vier sectoren, met per sector een reëel scenario dat we in de praktijk zijn tegengekomen.

E-commerce. De grootste risico’s zitten in “promotieregelconfigurators”, “creator-productselectiedashboards” en “voorraadcheck-apps” — ze lijken op het eerste gezicht simpele tools, maar in de praktijk lezen ze orderbrede tabellen met telefoonnummers en adressen. Dit soort applicaties moet verplicht door het sanctioned kanaal uit paragraaf 3 worden geregistreerd; zodra ze echte data aanraken, wordt automatisch de Chinese datalokalisatie- en beveiligingsbeoordeling (等保测评 / data-export assessment) geactiveerd. We hebben met eigen ogen gezien hoe een e-commercebedrijf binnen twee maanden zeven interne tools bouwde, waarvan er vier orderbrede tabellen uitlezen — dit is geen incidenteel geval.

Financiën. De rode lijn ligt bij “transactiesystemen / betalingen / clearing en settlement / risicobeheer / fraudebestrijding / toezichtsrapportage”. De generator is wél geschikt voor zaken als een relatiemanagerwerkplek, een marketingcampagneconfigurator of een front-end voor reconciliatierapporten. Absoluut niet gebruiken voor een risico-engine of frauderegels — de 1,7x hogere ratio van logische bugs die CodeRabbit rapporteert (eigen meetmethode van CodeRabbit, inclusief commercieel perspectief) wordt in financiële scenario’s vertaald naar direct kapitaalrisico. Het bedrijf in deze case is geanonimiseerd: een joint-stock bank begon eind 2025 AI-gegenereerde code in te zetten voor de ondersteuning van toezichtsrapportage, maar de scripts voor de rapportage aan de National Financial Regulatory Administration bevatten drie velden met een verkeerde definitie — de bank werd op het matje geroepen. Een van de kernoorzaken: niemand controleerde de “ogenschijnlijk correcte code” die AI had gegenereerd.

Telecom/operators. Een regionale carrier waar we mee hebben gewerkt — de marketingafdeling van een van de decentrale divisies had met Bolt zelf een “snelle klantprofielfinder” gebouwd. Daarmee kon je op basis van een mobiel nummer de afgelopen 90 dagen aan abonnementen, klachten en aanbevelingen opvragen — een directe schending van de toegangsrechten onder de Chinese Personal Information Protection Law (PIPL). In telecomomgevingen kan een generator prima worden ingezet voor een “werkplek voor relatiebeheerders”, een “front-end voor de kennisbank van de klantenservice” of “configuratietools voor marketingcampagnes” — maar blijf ver weg van billing, facturatie en het opvragen van gespreksdetails. Dat is de kern van de telecombusiness; één fout daar en je haalt het nieuws.

Productie. MES/ERP-integratie, kwaliteitscontrole en rapportage zijn kernsystemen; een generator kan alleen ondersteunend werk doen — shopfloor-dashboards, routingsinformatie en OEE-demo’s. Absoluut niet aanraken: de kernalgoritmen van productieplanning, kwaliteitsbeoordelingsregels en de reconciliatie-interface met het bovenliggende ERP. Geanonimiseerd voorbeeld: een toeleverancier van auto-onderdelen (vergelijkbare openbaar bekende terugroepacties zijn er meerdere; de casus is samengesteld uit openbare terugroepberichten en eigen projectervaring, ter illustratie van de besluitvormingslogica, niet gericht op een specifiek bedrijf) liet zijn IT-afdeling met Bolt een “frontend-dashboard voor AI-kwaliteitsinspectie” bouwen — de bedoeling was alleen om steekproefbeelden en beoordelingsresultaten te tonen. Maar tijdens de frontend-rendering werd de ruwe betrouwbaarheidsdrempel van het AI-model direct in de client hardcoded. Een medewerker veranderde per ongeluk 0,85 naar 0,6, waardoor binnen drie dagen meer dan 200 onderdelen die als “afgekeurd” hadden moeten worden gemarkeerd, als “goedgekeurd” naar de volgende productielijn gingen. Het eindigde met het terugroepen van drie batches. De grootste fout die middelgrote productiebedrijven maken, is ook het “AI-frontend voor kwaliteitsinspectie” aan een generator toe te vertrouwen — de consequentie van een fout in kwaliteitsregels is een productterugroepactie, en één fout betekent een openbare terugroepmelding.

Acht. Lessen voor beslissers

Inzicht één: Teken eerst een applicatielandschap, praat daarna pas over tooling. Pak de matrix uit het tweede deel en plaats de applicaties die je nu hebt en die je van plan bent te bouwen, op basis van complexiteit en datagevoeligheid. Je ziet direct: welke applicaties in de groene zone zitten en veilig aan een generator kunnen worden toevertrouwd voor versnelling, en welke in de rode zone zitten en absoluut onaangeraakt moeten blijven. Eén zo’n overzicht filtert een groot deel van de impulsieve voorstellen om ‘het kernssysteem te herbouwen met een generator’ eruit, en geeft tegelijkertijd de onderdelen die versneld mogen worden, het mandaat om dat ook echt te doen.

Inzicht twee: Beschouw datagrensoverschrijding en classificatie als toelatingseisen, niet als achteraf in te bouwen controles. Voordat je welke AI-tool dan ook aanschaft die met code of data in aanraking komt, moeten deze twee punten eerst zijn afgevinkt. Het probleem met tools zoals Trae is niet ‘of ze werken’, maar ‘of ze werken binnen jouw specifieke regelgevingsomgeving’. Die afweging moet je vooraf maken; de prijs van een verkeerde inschatting is herstelwerk achteraf, sancties, of zelfs het volledig offline moeten halen. Concreet: neem de aanschaf van AI-tools op in een gezamenlijk toelatingsproces met security en legal, en stel een duidelijke lijst op van tools die ‘de ontwikkelomgeving in mogen’ en een lijst voor tools die ‘individuele goedkeuring vereisen’.

Inzicht drie: Geef de business een compliance-vriendelijk pad, anders worden schaduwapplicaties alleen maar meer. Die 80% uit het derde deel bewijst dat blokkeren niet werkt. Wacht niet tot een incident de inventarisatie afdwingt, maar bouw nu het kanaal uit deel vijf: goedgekeurde generatoren, een lichtgewicht registratie, routering op basis van datatype, en automatische scans. Laat de business snel kunnen handelen, maar zorg dat elke actie op de lijst staat. Zo verander je schaduw-IT van een onbeheerde blinde vlek in een auditabele asset.

Inzicht 4: Verander de meetlat, anders gaat al het budget naar tools en blijft de bottleneck bestaan. Dit punt is gericht aan de CEO en de directie. Veel raden van bestuur meten het succes van hun AI-transformatie tegenwoordig af aan “hoeveel AI-licenties we hebben aangeschaft” en “hoeveel sneller we ontwikkelen”. Het probleem met deze meetlat is dat het budget vervolgens volledig naar tools vloeit, terwijl de schakels die écht bepalen of er opgeleverd kan worden — zoals de functionaris voor data-uitvoerbeoordeling, de compliance-functionaris voor de classificatie- en beschermingseisen (等级保护, de Chinese cybersecurity-classificatiestandaard), security engineering en de afdeling voor reconciliatie en audit — juist geen geld en geen mensen krijgen. Het resultaat: een stapel tools, maar nog steeds een trage oplevering. Om van de verlamming “we weten het wel, maar we kunnen het niet in beweging krijgen” af te komen, moet de meetlat op directieniveau worden aangepast. Voeg daarom indicatoren toe als: “hoeveel applicaties vallen onder het compliance-traject”, “het aantal shadow apps is gedaald van N naar M”, en “de doorlooptijd van prototype tot compliant livegang voor kernapplicaties”. Pas als de meetlat verandert, zal het budget naar de echte knelpunten stromen.

Zelfreflectie (wees eerlijk in je antwoord): Hoeveel applicaties die door businessafdelingen zelf met AI zijn gebouwd, draaien er momenteel in jouw organisatie — kun je daar een getal op plakken? Hoeveel van die applicaties raken aan orders, telefoonnummers of adressen? Weet jij waar de data naartoe gaat van de AI-IDE die je standaard voor je engineers hebt geïnstalleerd? Meten de cijfers die jij gebruikt om AI-impact te beoordelen nu eigenlijk “tools aanschaffen” of “sneller opleveren”? Als je bij één van deze vier vragen het antwoord schuldig moet blijven, dan is het risico dat dit artikel beschrijft al in jouw organisatie aanwezig.

Volgende stap

Dit is het vijfde artikel in een serie van achttien over de transformatie van software-engineering in het AI-tijdperk. We hebben gezien hoe app-generatoren en AI-IDE’s de drempel voor “een app bouwen” hebben verlaagd, en waarom de drempel voor het werken met data niet op dezelfde manier zal dalen.

Het volgende artikel (deel 6) behandelt een tegenovergestelde richting die steeds meer gemeengoed wordt in de industrie: Spec-Driven Development. Waarom GitHub Spec Kit, Claude Code, AWS Kiro en OpenAI’s AGENTS.md allemaal dezelfde kant opgaan: “eerst de vereisten vastleggen in documentatie, dan pas AI aan het werk zetten.” In de vorige sectie werd besproken dat AI-gegenereerde code een hoger foutenpercentage kent dan handmatig geschreven code; spec-driven development is een van de manieren om dit probleem aan te pakken: door vage mondelinge eisen om te zetten in controleerbare specificaties, krijgt AI pas een kans om gecontroleerd te worden.

Over deze serie: Deze serie blijft de nieuwste ontwikkelingen volgen op het gebied van AI-programmeertools, organisatiestructuren en software-engineeringparadigma’s. Volg deze serie voor voortdurend bijgewerkte inzichten.

Wil je deze aanpak toepassen binnen jouw organisatie?

Wanneer app-generatoren hun intrede doen in een bedrijf, draait het meestal om een paar concrete vragen: welke applicaties en data kunnen door de business zelf worden gegenereerd, welke moeten door IT worden beheerd, in hoeverre moeten bestaande validatieprocessen worden uitgebreid, en met welke KPI’s moet de pilot worden geëvalueerd.

Op dit moment bieden we drie vormen van samenwerking aan:

  • Interne training: aan de hand van concrete projecten binnen uw organisatie doorloopt u de selectie van een app-generator, de gebruiksgrenzen, de compliance-route en het ontwerp van het governancemechanisme.
  • Gericht adviestraject: gericht op één concrete beslissing, bijvoorbeeld “moeten we business-teams toegang geven tot een goedgekeurde app-generator?” of de prioritering van herstelmaatregelen na een inventarisatie van schaduwapplicaties.
  • Managementpresentaties en sectorlezingen: rond thema’s als AI-programmeertools, governance van schaduwapplicaties, AI-transformatie binnen organisaties en organisatorische governance.

Dit artikel biedt een generiek raamwerk. De daadwerkelijke implementatie vereist echter een herontwerp op basis van de datasgrenzen, wet- en regelgeving, technische volwassenheid en bestaande delivery-processen van uw organisatie. Voor samenwerking kunt u contact opnemen via coach@iaiuse.com.

Verder lezen: Zie het bord-methodologie v1.0 (Learn AI Slowly 187), waarin het 7-stappenraamwerk voor AI-transformatie binnen organisaties systematisch wordt toegelicht.

Over deze serie

“Software-engineering in transitie in het AI-tijdperk” is een onderzoeksreeks voor CIO’s, CDO’s, CTO’s en digitaliseringsverantwoordelijken in de telecom-, financiële, productie- en e-commercesector. De serie omvat 18 delen en richt zich op de vraag hoe AI-programmeertools, app-generatoren en de governance van schaduwapplicaties van invloed zijn op software-delivery-processen, organisatiestructuren, governancemechanismen en managementmetrics.

Deze serie volgt voortdurend academische papers, leveranciersdocumentatie en brancherapporten. De onderzoeksdatabase bevat inmiddels meer dan 200 documenten, en voor elke belangrijke conclusie wordt het bewijsniveau aangegeven, waarbij onderscheid wordt gemaakt tussen geverifieerde feiten, leveranciersclaims, brancheobservaties en de redenering van de auteur.

Ik heb bijna 8 jaar ervaring in consultancy en businessanalyse voor grote ondernemingen, onder meer bij IBM, waar ik betrokken was bij projecten in de telecom-, financiële, verzekerings- en maakindustrie. Daarna bleef ik actief aan de frontlinie van carrierproducten, internetproducten en AI-toepassingsontwikkeling, met focus op requirementsanalyse, productontwerp en cross-functionele implementatie.

De conclusies in deze serie over toolselectie, de gebruiksgrenzen van app-generatoren, compliancekanaalontwerp en organisatiegovernance zijn gebaseerd op deze praktijkervaring en worden gekruist gevalideerd met openbaar onderzoek en branchecasussen. Alle inhoud met betrekking tot specifieke projecten is geanonimiseerd; sommige branchescenario’s betreffen redeneringen over typische vraagstukken, met de relevante onderbouwing in de bronnen onderaan dit artikel.

Achter dit account zit eigenlijk een klein team — ik en 1 à 2 collega’s met wie ik langdurig samenwerk, verdeeld over AI-programmeertoolonderzoek, organisatiegovernance-casussen en coachingsgesprekken. De meeste projecten waarover we schrijven dat “we bedrijven erdoorheen hebben geloodst”, zijn gezamenlijk door ons opgeleverd. Klantgerelateerde compliancegrenzen en namen blijven onvermeld; de anonimiteit biedt ruimte voor toekomstige samenwerkingscollega’s.

Bronnen (alle geverifieerd, met bewijsniveau + standpunt per item)

  • StackBlitz CEO Eric Simons (LinkedIn, afsluiting boekjaar 2026). Bolt.new wordt gebruikt door driekwart van de Fortune 500; de enterprise-ARR steeg op jaarbasis met 10x. Een directe uitspraak van het bedrijf zelf (vanuit het perspectief van de leverancier). https://www.linkedin.com/posts/eric-simons-a464a664_a-growth-update-as-we-close-out-our-fiscal-activity-7425263313049026560-5tdV

  • Sacra / Growth Unhinged (2025). ARR-groeianalyse van Bolt.new (van circa 5 maanden tot 40 miljoen dollar ARR, circa 5 miljoen gebruikers, op één na snelste groei ooit, alleen achter ChatGPT). Primaire research/tracking. https://sacra.com/c/bolt-new/ 、https://www.growthunhinged.com/p/boltnew-growth-journey

  • Taskade (2026-03) / Business Insider. StackBlitz 2025-01 Serie B van $105,5M, waardering circa $700M; Bolt V2 gelanceerd op Bolt Cloud. Samenvatting van brancherapportages.

  • Forbes / Rashi Shrivastava (2026-06-05). Lovable voert een nieuwe financieringsronde tegen een waardering van $12B; ARR doorbreekt $500M (2026-06-09 TechCrunch bevestigt). Primaire brancheverslaggeving. https://www.forbes.com/sites/rashishrivastava/2026/06/05/ai-coding-startup-lovable-in-talks-to-raise-funding-at-a-12-billion-valuation

  • CNBC / Bloomberg (2025-12) / TechCrunch (2025-11). Lovable Serie B van $330M tegen een waardering van $6,6B; Serie A van $200M tegen een waardering van $1,8B. Brancheverslaggeving.

  • ARR.club (2026-07). Lovable’s ARR-groeicurve: $17M (2025-02) → $100M (2025-07) → $200M (2025-11) → $400M (2026-02) → $500M (2026-06); enterpriseklanten zijn onder meer Workday, Asana en NVIDIA. Sectoranalyse.

  • Vercel (2026-02-03, officiële blog “Introducing the new v0”). v0 is hernoemd van v0.dev naar v0.app en is geëvolueerd van een UI-componenttool naar een full-stack app-generator (sandbox-runtime + GitHub + Snowflake/AWS-integraties). Officiële leveranciersinformatie. https://vercel.com/blog/introducing-the-new-v0

  • Taskade (2026-03) / Vercel. v0 telde in maart 2026 meer dan 6M gebruikers, circa 80.000 maandelijkse actieve teams, en een geschatte ARR van ongeveer $42M. Gecombineerde sectorinschatting.

  • Replit (2026-03-13 officiële changelog + officiële blog “What’s changed from Agent 3 to Agent 4”). Agent 4 is uitgebracht op 2026-03-11; Infinite Design Canvas; fork-and-merge-samenwerking is omgevormd tot multi-threaded taken binnen hetzelfde project + automatische conflictoplossing (90% automatisch opgelost). Eerstelijns leveranciersinformatie. https://docs.replit.com/updates/2026/03/13/changelog

  • AlphaSignal (2026). Gedetailleerde berichtgeving over hoe Replit Agent 4 automatisch 90% van de merge-conflicten in teams oplost. Sectorrapportage. https://alphasignal.ai/news/replit-s-agent-4-resolves-90-of-team-merge-conflicts-automatically

  • Atal Upadhyay (2026-03-19). Replit maakte in dezelfde week een Serie D-financiering van $400 miljoen bekend, met een waardering van $9 miljard (in een half jaar tijd verdrievoudigd). Gebaseerd op meerdere branchepublicaties. https://atalupadhyay.wordpress.com/2026/03/19/replit-agent-4-replit-just-changed-everything

  • Cybernews (bijgewerkt 2026-08-01) / The Register (2025-07-28) / segmentationf4u1t (primair onderzoek via GitHub). Trae verzendt zelfs wanneer telemetrie is uitgeschakeld nog steeds hardware- en apparaat-ID’s en projectactiviteitsgegevens naar ByteDance-servers; een enkele batch kan oplopen tot 53.606 bytes; binnen 7 minuten werden meer dan 500 aanroepen geregistreerd, goed voor ongeveer 26 MB; ByteDance bevestigt officieel dat de toggle alleen het VS Code-framework gedeeltelijk uitschakelt; Privacy Mode staat gepland voor rond augustus 2026; Trae schrapte in februari 2026 het ‘forever free’-model en stapte over op een token-gebaseerde betaalmuur. Eersteklas beveiligingsonderzoek + brancheverslaggeving + verklaring van de leverancier. https://cybernews.com/security/bytedance-ai-coding-tool-trae-data-collection 、https://www.theregister.com/software/2025/07/28/bytedance-ai-ide-trae-telemetry-continues-even-after-opt-out/ 、https://github.com/segmentationf4u1t/trae_telemetry_research

  • OpenAI Tools Hub / Jim Liu (2026-05-18). Trae 12 maanden na lancering: 6M registraties / 1,6M maandelijkse actieve gebruikers / in totaal 100B regels code gegenereerd; in februari brak de token-paywall met de belofte van “forever free”. Gecombineerd onderzoek (vanuit analistenperspectief).

  • Gartner (geciteerd via Process Excellence Network, 2025-08-27 / DevOpsDigest / UC Today). Tegen eind 2026 zal 40% van de bedrijfsapplicaties taakspecifieke AI-agents bevatten (in 2025 was dat minder dan 5%); tegen 2035 zal agentic AI ongeveer 30% van de enterprise softwaremarkt uitmaken ($450 miljard). Officieel prognosedocument. https://www.processexcellencenetwork.com/ai/news/gartner-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026

  • Gartner (geciteerd via RapidClaw / Hendricks.ai / Arion Research, 2025-2026). Tussen Q1 2024 en Q2 2025 steeg de vraag van bedrijven naar advies over multi-agent systemen met 1445% — het snelst groeiende onderwerp binnen Gartners AI-advisorypraktijk. Primaire onderzoeksbron / tweedehands geciteerd.

  • Microsoft (FY26-terugblikblog, 2026-07-28). EY heeft Copilot uitgerold naar 150.000 medewerkers en behaalt daarmee een productiviteitswinst van 15%; de uitrol wordt uitgebreid naar 400.000 medewerkers wereldwijd. Atos heeft Copilot beschikbaar gesteld aan 56.000 medewerkers in 54 landen en beheert 19.000 AI-agents vanuit één uniforme beheeromgeving. Eerstelijns leverancier + klantbevestiging (vanuit leveranciers- en integratieperspectief). https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Atos Group (officieel persbericht, 2026-06-09). Atos breidt de samenwerking met Microsoft uit en implementeert Copilot E7 (Frontier Suite) voor 56.000 medewerkers, met een uniform beheerplatform voor Entra/Defender/Intune/Purview/Agent 365 en 19.000 agents in gebruik. Directe bedrijfsverklaring. https://www.atosgroup.com/en/press/atos-group-and-microsoft-expand-strategic-collaboration-scale-secure-agentic-ai-across-atos

  • UpGuard / Cybersecurity Dive (2025). Meer dan 80% van de medewerkers en bijna 90% van de securityverantwoordelijken gebruiken AI-tools die niet zijn goedgekeurd; ongeveer de helft van de medewerkers heeft vertrouwelijke gegevens in deze tools geplakt (vergelijkbare rapporten van Mimecast en Teramind bevestigen dit beeld). Primaire onderzoeksdata + brancheverslaggeving. https://www.cybersecuritydive.com/news/shadow-ai-employee-trust-upguard/805280/

  • Gartner (aangehaald via The Hacker News, mei 2026). 69% van de organisaties vermoedt of bevestigt dat medewerkers verboden AI-tools gebruiken; slechts 37% heeft beleid voor AI-gebruik. Brancheverslaggeving op basis van secundaire bron.

  • CodeRabbit (2026-02 DORA gezamenlijke webinar + Kunal Ganglani 2026-06 vergelijkende evaluatie). Het aantal problemen in AI-gegenereerde code (inclusief logische en correctheidsbugs) is ongeveer 1,7 keer zo hoog als bij traditioneel handgeschreven code; CodeRabbit is de meest geïnstalleerde AI-codebeoordelingstool op GitHub/GitLab, met meer dan 15.000 betalende klanten en 6 miljoen beoordeelde repositories; NVIDIA-CEO Jensen Huang heeft er publiekelijk zijn steun voor uitgesproken. Primair onderzoek / leveranciersdata / sectorbrede vergelijking. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report

  • Veracode (2025 GenAI Code Security Report). Ongeveer 45% van de door AI gegenereerde codevoorbeelden bevat kwetsbaarheden uit de OWASP Top 10 (bij Java gegenereerde code ligt het faalpercentage boven de 70%). Primaire onderzoeksbron. https://www.veracode.com/blog/genai-code-security-report/ （Let op: in een eerdere versie van dit artikel werd dit “45%” abusievelijk geïnterpreteerd als het adoptiepercentage van shadow AI; dat is inmiddels gecorrigeerd — de 45% heeft betrekking op het defectpercentage van AI-gegenereerde code, niet op de adoptiegraad van tools; het adoptiecijfer van shadow AI staat bij UpGuard op 80%+.)

  • arXiv:2510.26103. Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories.（Empirisch onderzoek uit eerste hand naar beveiligingskwetsbaarheden in AI-gegenereerde code.）

Toelichting bij data: Alle kwantitatieve gegevens in dit artikel zijn voorzien van een bronvermelding; enkele cijfers die door leveranciers niet openbaar zijn gemaakt of niet onafhankelijk zijn geverifieerd (zoals Lovable’s $12B financieringsronde die nog in onderhandeling is, en de exacte inventarisatiedatum van Atos’ 19.000 agents) zijn met de nodige terughoudendheid behandeld. Klantcases zijn geanonimiseerd (e-commerce operations team, regionale carrier marketingafdeling, etc.) en zijn gebaseerd op feitelijke observaties tijdens mijn begeleiding van implementatietrajecten; ze verwijzen niet naar specifieke bedrijven. Voor regelgeving (data-export, classificatie- en beveiligingstesten, algoritme-registratie) geldt de huidige wetgeving als uitgangspunt; de concrete toepassing hangt af van het bedrijfsmodel en het type data. Raadpleeg vóór implementatie altijd je juridische of compliance-afdeling.

[^1]: Belangrijke data-uitvoer valt onder artikel 31 van de Datasecuriteitswet (veiligheidsevaluatie voor belangrijke data-uitvoer); persoonsgegevens-uitvoer valt onder artikelen 38–43 van de Persoonsgegevensbeschermingswet (uitvoervoorwaarden/standaardcontracten/certificeringstrajecten/toestemming). Bijbehorende regels: Maatregelen voor de veiligheidsevaluatie van data-uitvoer (van kracht sinds 2022-09-01, Order nr. 11 van de Cyberspace Administration of China) en Maatregelen voor standaardcontracten voor de uitvoer van persoonsgegevens (van kracht sinds 2023-06-01).
[^2]: Artikel 21 van de Cybersecuritywet (classificatiebeschermingsstelsel) en de Informatiebeveiligingstechnologie – Basisvereisten voor cybersecurity-classificatiebescherming GB/T 22239-2019 (Classificatiebescherming 2.0); de Beheersmaatregelen voor informatiebeveiligingsclassificatiebescherming (Gongtongzi [2007] nr. 43) schrijven voor dat systemen van niveau drie jaarlijks een classificatie-evaluatie ondergaan en systemen van niveau twee doorgaans eens per twee jaar.

[^3]: Er zijn drie verschillende zaken: ① Artikel 24 van de Regelgeving voor het beheer van algoritmische aanbevelingen bij internetinformatiediensten (van kracht sinds 2022-03-01) (registratie van algoritmische aanbevelingen); ② Artikel 17 van de Regelgeving voor het beheer van diepe synthese bij internetinformatiediensten (van kracht sinds 2023-01-10) (registratie van diepe synthese); ③ Artikel 17 van de Tussentijdse maatregelen voor het beheer van generatieve AI-diensten (van kracht sinds 2023-08-15) (generatieve AI-diensten die voor het publiek beschikbaar zijn en een publieke opinie-karakter hebben, moeten een veiligheidsbeoordeling ondergaan — dit is een beoordeling, geen registratie). De code die door een app-generator wordt geproduceerd, valt op zichzelf niet noodzakelijkerwijs onder deze drie categorieën, maar als de gegenereerde applicatie zelf generatieve AI-diensten aanbiedt of functies voor algoritmische aanbevelingen/diepe synthese bevat, dan gelden de betreffende bepalingen wel.
[^4]: Het algemene raamwerk voor changemanagement volgt ITIL 4 Change Enablement; voor de financiële sector is de meest recente referentie de Regelgeving voor het toezicht op uitbesteding van IT-diensten door banken en verzekeraars (银保监发〔2021〕46 号) en de relevante circulaires van de Nationale Administratie voor Financieel Toezicht uit 2024; voor de verzekeringssector geldt aanvullend de Richtlijn voor het beheer van informatietechnologie bij verzekeringsinstellingen (保监发〔2009〕17 号, herziene versie 2024).

[^5]: Bewaartermijnen voor transactiegegevens: de daadwerkelijke bron is artikel 31 van de E-commercewet (platforms moeten transactiegegevens ≥ 3 jaar registreren en bewaren) plus artikel 26 van de Maatregelen voor het toezicht op online transacties (die expliciet een periode van 3 jaar vaststellen). Auditlogs: volgens niveau 3-systemen van de Chinese classificatie voor cybersecuritybescherming geldt een vereiste van ≥ 6 maanden bewaring van netwerklogs (als aanvulling op artikel 21 van de Cybersecuritywet), maar voor kritieke systemen in de financiële sector gelden volgens artikel 19 van de Richtlijnen voor datagovernance bij bank- en verzekeringsinstellingen en de Richtlijnen voor interne controle bij commerciële banken doorgaans vereisten van ≥ 5 jaar — die 6 maanden zijn dus een absolute ondergrens, geen aanbevolen richtlijn.