De 5 onzichtbare productierisico’s van geprompte apps
Een AI-model levert wat je vraagt: een app die werkt. Wat je niet vraagt, omdat je niet weet dat het nodig is, blijft vaak achterwege. Dat is geen tekortkoming van de tool, maar van de opdracht. Hieronder vijf gebieden waar dat verschil in de praktijk het duidelijkst zichtbaar wordt.
1. Security, privacy en hardening
Security is de grootste valkuil, omdat een lek onzichtbaar blijft tot het misgaat.
Een veelvoorkomend patroon in gegenereerde code: API-keys en andere secrets staan direct in de app. Die code wordt gebundeld in de binary die iedereen uit de store kan downloaden en met gratis tools kan uitpakken. Een sleutel in de app is daarmee in feite een openbare sleutel.
Een productierijpe app werkt anders. Secrets blijven op de server en de app communiceert via een eigen backend of proxy, met kortlevende tokens die na korte tijd verlopen. Gevoelige gegevens op het toestel staan in de iOS Keychain of de Android Keystore, niet in gewone app-opslag. Al het verkeer loopt via HTTPS/TLS, App Transport Security op iOS blijft ingeschakeld en voor gevoelige toepassingen voegt certificate pinning een extra laag toe. De OWASP MASVS (Mobile Application Security Verification Standard), de internationale beveiligingsstandaard voor mobiele apps, dient daarbij als meetlat.
Gevolg: gaat het mis met persoonsgegevens? Dan geldt de AVG-meldplicht: een datalek meld je binnen 72 uur bij de Autoriteit Persoonsgegevens. Daarbij loop je het risico op reputatieschade, die vaak langer doorwerkt dan het incident zelf.
2. Compliance en afwijzing door App Store en Google Play
AI schrijft wel de code, maar regelt niet de andere zaken die Apple en Google eisen bij het publiceren. Denk hierbij aan verklaringen en toelichtingen op het gebied van privacy en security,
Bij Apple is sinds 1 mei 2024 een Privacy Manifest verplicht. Daarin verklaar je onder meer waarom je app bepaalde required reason API's gebruikt, en veelgebruikte third-party SDK's moeten een eigen manifest meeleveren. Google verhoogt jaarlijks het minimale target API level: sinds 31 augustus 2026 moeten nieuwe apps en updates gericht zijn op Android 16 (API-niveau 36). Gevoelige permissies, zoals achtergrondlocatie, vragen daarnaast om een onderbouwing in de Play Console.
Dit zijn geen zaken die een prompt automatisch afdekt. Ze vragen kennis van de actuele store-eisen en van wat de gebruikte SDK's onder de motorkap doen.
Gevolg: een afwijzing, vertraging in de uitrol en een app die (nog) niet kan worden gebruikt.
3. Architectuur en schaalbaarheid bij toestelfragmentatie
Soepel op de nieuwste iPhone is niet hetzelfde als stabiel op een budget-Android met zwak bereik.
Een gegenereerde app wordt meestal getest op één toestel of in een simulator, op snelle wifi. De werkelijkheid is diverser. Android draait op duizenden modellen, met verschillende hoeveelheden geheugen, processoren en fabrikantaanpassingen.
Geheugenlekken komen vaak pas aan het licht bij langdurig gebruik, bijvoorbeeld wanneer een scan-app een volledige dienst in een magazijn openstaat. En wat gebeurt er als de verbinding halverwege een formulier wegvalt, of het besturingssysteem de app op de achtergrond afsluit? Zonder doordacht state management gaan gegevens verloren of worden ze dubbel verstuurd.
Daarom test je een productie-app op echte toestellen, onder realistische netwerkomstandigheden en gedurende langere tijd.
Gevolg: een stilgevallen werkvloer of onbetrouwbare data, die vaak pas later opvalt.
4. Kennisborging, testen en onderhoudbaarheid
Code die niemand begrijpt of test, wordt een risico zodra er iets misgaat of iemand vertrekt.
Bij vibe coding stapelt elke prompt nieuwe code op de vorige, zonder vaste structuur. Zolang alles werkt, merk je daar weinig van. Maar bij een storing, een nieuwe wens of het vertrek van de collega die de app 'promptte', blijkt hoe moeilijk overdraagbaar zo'n codebase is.
Een onderhoudbare app heeft een heldere architectuur, zoals Clean Architecture of MVVM, waarin schermen, bedrijfslogica en data van elkaar gescheiden zijn. Documentatie legt vast waarom keuzes zijn gemaakt. Geautomatiseerde tests vangen regressie op: een wijziging die ongemerkt iets anders breekt.
Een minder bekend aandachtspunt zijn licenties. AI voegt moeiteloos open-source libraries toe, maar sommige vallen onder een copyleft-licentie zoals de GPL. Die kan je verplichten om je eigen broncode te delen, wat botst met een closed-source bedrijfsapp. Het loont om alle licenties in kaart te brengen.
Gevolg: stilstand bij incidenten en hoge kosten voor herbouw.
5. Productieklaar: monitoring en toegankelijkheid
Zonder monitoring hoor je pas van problemen als de klant belt.
Crashrapportage via tools als Sentry of Firebase Crashlytics, aangevuld met gerichte logging, laat precies zien op welk toestel, welke OS-versie en bij welke handeling een fout optreedt. Zo los je problemen op voordat gebruikers ze melden.
Toegankelijkheid verdient eveneens aandacht. Sinds 28 juni 2025 geldt de European Accessibility Act (EAA), die stelt dat veel consumentgerichte digitale diensten verplicht toegankelijk zijn, bijvoorbeeld op het gebied van webwinkels, bankieren en vervoer. Voor de overheid geldt al langer het ‘Besluit digitale toegankelijkheid overheid’, en ook in aanbestedingen is toegankelijkheid steeds vaker een eis. Interne B2B-apps vallen grotendeels buiten de EAA, maar wie levert aan de overheid of de app later openstelt voor klanten, heeft er wel mee te maken. Denk aan ondersteuning voor screenreaders zoals VoiceOver en TalkBack, voldoende kleurcontrast en schaalbare tekst.
Gevolg: problemen blijven onzichtbaar en je loopt mogelijk aanbestedingen mis.
