Hoe je AI-gegenereerde code beheert in een gereguleerde omgeving

AI schrijft steeds meer code. Dat is geen trend meer, het is praktijk. In onze projecten zien we dat een significant deel van de codebase via AI-tools tot stand komt: van boilerplate tot bedrijfslogica, van testscenario's tot API-integraties. De productiviteitswinst is reeel.

Maar in gereguleerde sectoren, denk aan zorg, financiele dienstverlening, luchtvaart, publieke sector, brengt die snelheid een vraag met zich mee die je niet kunt omzeilen: wie is verantwoordelijk voor de code die een AI heeft geschreven? En hoe zorg je dat die code voldoet aan de eisen die jouw sector stelt?

Bij Livewall bouwen we webapplicaties en platforms voor organisaties in precies deze sectoren. Van een digitaal ondersteuningsplatform voor Veilig Thuis tot een gezondheidsplatform voor Zorg van de Zaak. Complianceverplichtingen zijn voor ons geen abstractie, ze zijn een onderdeel van het ontwerpproces.

Het fundamentele misverstand over AI en compliance

Het meest gehoorde misverstand: als een AI de code schrijft, is de verantwoordelijkheid onduidelijk. Dat klopt niet. De verantwoordelijkheid ligt exact waar die altijd heeft gelegen: bij de organisatie die het systeem in productie neemt.

AI verandert wie de code typt, niet wie er juridisch en operationeel voor instaat. Een zorgplatform dat persoonsgegevens verwerkt moet voldoen aan de AVG, ongeacht of een developer of een taalmodel de verwerkingslogica heeft geschreven. Een financiele applicatie moet audittrails bijhouden. Een publiek systeem moet toegankelijk zijn volgens WCAG. Geen van die verplichtingen vervalt omdat er AI in het ontwikkelproces zit.

Wat AI wel verandert, is het tempo. En dat tempo maakt governance urgenter, niet minder relevant.

Vier lagen van governance die je nodig hebt

Governance voor AI-gegenereerde code is geen enkelvoudig beleidsdocument. Het is een stapeling van afspraken, tooling en gewoontes die samen bepalen of je met vertrouwen kunt deployen.

1. Eigenaarschap van elke regel code. Elke commit moet een menselijke eigenaar hebben die de code heeft beoordeeld en goedgekeurd. Dat klinkt vanzelfsprekend, maar in de praktijk sluipen er bij hogere AI-output sneller blokken code doorheen die niemand echt heeft gelezen. Maak het expliciet in je code review-proces: AI-gegenereerde code vereist dezelfde reviewstandaard als handgeschreven code, en soms een strengere.

2. Reproduceerbare en auditeerbare wijzigingen. In gereguleerde omgevingen moet je kunnen aantonen wat er is veranderd, wanneer, door wie en waarom. Git-history is een begin, maar niet genoeg. Koppel elke wijziging aan een ticket, een requirement of een compliance-item. Automatiseer dat zoveel mogelijk: als je AI-tools gebruikt die code genereren, log dan ook de prompt en het model dat is gebruikt. Dat is nu al relevant voor auditors, en wordt dat meer.

3. Geautomatiseerde compliance-checks in de CI/CD-pipeline. Handmatige audits zijn te traag voor het tempo van AI-ondersteunde ontwikkeling. Bouw statische analyse, dependency scanning en toegankelijkheidscontroles in de pipeline in, zodat elke PR automatisch wordt getoetst. Bij webapplicatie-ontwikkeling voor gereguleerde sectoren is dit geen nice-to-have, het is de basishygiene.

4. Heldere scope-afbakening voor AI-tooling. Niet elke module leent zich voor AI-generatie. Authenticatie, autorisatie, gegevensverwerking met privacygevoelige informatie: dat zijn gebieden waar je AI als sparringpartner kunt inzetten, maar waar de uiteindelijke implementatie extra menselijke review vergt. Maak die grens expliciet in je team.

Het risico van vibe-coding in een gereguleerde context

Vibe-coding, het snel genereren en doordraaien van code zonder diep na te denken over de architectuur of implicaties, is productief in de vroege verkenningsfase. Maar in gereguleerde omgevingen is het een risico als het patroon doorzet naar productie.

Wat we in de praktijk zien: AI-tools geven zelfverzekerd antwoord op vragen waarbij de context ontbreekt. Een taalmodel weet niet dat jouw sector een specifieke logging-standaard vereist. Het weet niet dat een bepaalde third-party library niet is goedgekeurd door jullie securityteam. Het weet niet dat de dataverwerking in module X onderhevig is aan een bewerkersovereenkomst.

Dat betekent niet dat je AI niet moet gebruiken. Het betekent dat je de AI-output altijd beoordeelt met die context in gedachten. En dat je je team traint om die beoordeling consistent te maken, niet afhankelijk van de inzichten van een individuele developer op een goede dag.

Ons zusterbureau Mach8 werkt aan AI-werkstromen waarbij die context-overdracht naar AI-systemen systematischer wordt gemaakt. Goede governance begint bij goede kennisoverdracht aan het systeem dat je inzet.

Hoe je een governance-kader opbouwt dat meeschaalt

Het probleem met veel compliance-kaders is dat ze zijn ontworpen voor een wereld van langzame, handmatige ontwikkeling. Ze werken niet goed als je team vier keer zo snel itereert.

De oplossing is niet minder governance, maar governance die automatiseert wat automatiseerbaar is en menselijk oordeel reserveert voor wat er echt toe doet.

Automatiseer:

• Dependency vulnerability scanning bij elke PR
• Linting en statische analyse op security-patronen
• Toegankelijkheidscontroles (axe, Lighthouse) in de testpipeline
• Automatische koppeling van commits aan compliance-tickets

Reserveer menselijk oordeel voor:

• Architectuurbeslissingen met langetermijngevolgen
• Review van code die privacygevoelige gegevens verwerkt
• Beoordeling van nieuwe third-party dependencies
• Incidentrespons en postmortems

Dit is precies hoe we werken in projecten als Zorg van de Zaak, waar de combinatie van gezondheidsdata en B2B-omgeving strikte eisen stelt aan zowel de code als het proces eromheen.

De rol van documentatie in een AI-versneld team

Een onderschat onderdeel van governance is documentatie. In een team dat snel gaat, is documentatie vaak het eerste dat erbij inschiet. Maar in gereguleerde omgevingen is het precies het bewijs dat auditors en toezichthouders vragen.

AI kan hier een deel van het probleem oplossen. Moderne AI-tools zijn goed in het genereren van technische documentatie op basis van bestaande code. Ze kunnen changelogs schrijven, API-documentatie bijhouden en testplannen structureren. Dat zijn taken die developers graag uitstellen en waarbij AI betrouwbaar levert.

Het risico is dat automatisch gegenereerde documentatie klopt op het niveau van de code, maar de bredere context mist: waarom is deze keuze gemaakt, welk compliance-item rechtvaardigt deze implementatie, wat is de intended use van dit component? Dat is de documentatie die mensen moeten schrijven, met of zonder AI-ondersteuning.

In onze digitale strategie aanpak adviseren we teams om documentatievereisten als onderdeel van de definitiefase vast te leggen, niet als afterthought na de launch.

Beginnen is minder complex dan het lijkt

Governance klinkt zwaar. In de praktijk begint het met drie concrete stappen die elk team vandaag kan zetten:

Stap 1: Maak AI-gebruik zichtbaar in je code review. Label commits of PR-beschrijvingen waar AI substantieel aan heeft bijgedragen. Dat dwingt bewuste review af en geeft je later inzicht in welke delen van de codebase extra aandacht verdienen.

Stap 2: Voeg twee geautomatiseerde checks toe aan je pipeline. Kies de twee compliance-checks die het meest relevant zijn voor jouw sector en automatiseer die in elke PR. Dat is beter dan een uitgebreid handmatig auditproces dat niemand consequent uitvoert.

Stap 3: Schrijf een AI-gebruiksbeleid voor je team. Niet een uitgebreid document, maar een pagina. Welke modules zijn off-limits voor AI-generatie zonder extra review? Welke libraries zijn goedgekeurd? Hoe ga je om met AI-gegenereerde code in productie-kritische paden? Die helderheid voorkomt dat goede intenties leiden tot slechte gewoontes.

Bij Livewall helpen we teams met het opzetten van custom tooling en interne systemen die dit soort governance ondersteunen zonder de ontwikkelsnelheid te remmen.