MLOps-beveiliging Voor AI-systemen In De Nederlandse Overheid

De volledige levenscyclus van AI-systemen – van dataverzameling en -preparatie tot modeltraining, validatie, deployment en monitoring – bevat tal van beveiligingsrisico's die kunnen leiden tot ernstige gevolgen voor de Nederlandse overheid. Onbeveiligde MLOps-processen kunnen worden misbruikt om trainingsdata te manipuleren, modelcode te wijzigen, gevoelige informatie uit configuraties te stelen of onbetrouwbare modellen in productie te brengen. Voor overheidsorganisaties die AI gebruiken in processen met grote impact op burgers, zoals uitkeringsbesluiten, fraudedetectie, risicoclassificaties of toezicht, kan dit leiden tot onrechtmatige besluiten, privacy-schendingen, discriminatie en verlies van vertrouwen. De EU AI Act, AVG, BIO en NIS2 eisen dat organisaties kunnen aantonen hoe zij de volledige levenscyclus van AI-systemen beheren en beveiligen. MLOps-beveiliging maakt dit aantoonbaar en traceerbaar, en voorkomt dat kwetsbaarheden in ontwikkel- en deployment-processen leiden tot gecompromitteerde systemen.

Implementatie

Dit artikel beschrijft hoe u MLOps-beveiliging systematisch inricht voor AI-systemen binnen de Nederlandse overheid. We behandelen beveiligingsmaatregelen voor elke fase van de MLOps-levenscyclus: data governance en beveiliging, beveiligde modelontwikkeling en -training, artifactbeheer en versiecontrole, beveiligde deployment-processen, en continue monitoring en incidentrespons. Vervolgens gaan we in op de technische implementatie met Azure Machine Learning, Azure DevOps, GitHub Actions en gerelateerde services, inclusief integratie met Azure Key Vault, Microsoft Defender voor Cloud en Azure Policy. Tot slot laten we zien hoe u MLOps-beveiliging integreert in governanceprocessen, risicomanagement, audittrajecten en compliance-rapportages, zodat organisaties aantoonbaar voldoen aan eisen vanuit wet- en regelgeving en betrouwbare AI-systemen kunnen ontwikkelen en uitrollen.

Beveiligingsfundament voor MLOps: principes en architectuur

Effectieve MLOps-beveiliging bouwt voort op een solide fundament van beveiligingsprincipes die door de volledige levenscyclus van AI-systemen worden toegepast. Het beginsel van defense in depth is hierbij cruciaal: beveiliging wordt op meerdere lagen ingebouwd, zodat een falen in één laag niet onmiddellijk leidt tot compromittering van het hele systeem. Dit betekent dat data, code, configuraties, modellen en infrastructure elk hun eigen beveiligingscontroles hebben, en dat deze controles elkaar aanvullen en versterken. Voor Nederlandse overheidsorganisaties betekent dit dat MLOps-beveiliging niet wordt gezien als een losstaand technisch project, maar als een integraal onderdeel van het bredere informatiebeveiligingsbeleid, dat aansluit op de BIO, NIS2 en andere relevante kaders.

Een tweede fundamenteel principe is least privilege: elke component, gebruiker, service-account of proces in de MLOps-levenscyclus krijgt alleen de minimale rechten die nodig zijn voor de specifieke taak. Dit betekent bijvoorbeeld dat datawetenschappers wel toegang hebben tot trainingsdata en modelcode, maar geen directe toegang tot productieomgevingen of gevoelige configuraties. Deployment-processen gebruiken managed identities of service principals met expliciet afgebakende rollen, zodat bij een compromis de schade beperkt blijft tot één omgeving of functie. Voor kritieke operaties, zoals het promoten van een model naar productie of het wijzigen van beveiligingsconfiguraties, worden extra goedkeuringsstappen ingebouwd, zoals meervoudige goedkeuring of automatische checks die controleren of een model voldoet aan fairness-criteria, security-scans heeft doorstaan en de juiste documentatie heeft.

Transparantie en traceerbaarheid vormen de derde pijler van het beveiligingsfundament. Elke wijziging in data, code, configuraties, modellen en deployments moet volledig traceerbaar zijn: wie heeft wat gewijzigd, wanneer, waarom en met welke goedkeuring? Dit wordt bereikt door uitgebreide auditlogging op alle MLOps-activiteiten, door versiebeheer van code, configuraties en modelartifacten, en door automatische generatie van deployment-artifacten met digitale handtekeningen en metadata. In een productieomgeving betekent dit dat alle wijzigingen worden vastgelegd in log-analytics workspaces, dat model-registries zoals Azure Machine Learning een volledige geschiedenis bijhouden van alle versies en deployments, en dat incidenten kunnen worden teruggevoerd naar specifieke commits, configuraties of modeltrainingen. Deze traceerbaarheid is niet alleen belangrijk voor compliance en audits, maar ook voor forensisch onderzoek na een security-incident en voor het kunnen terugdraaien van wijzigingen wanneer problemen worden ontdekt.

Ten slotte moet de beveiligingsarchitectuur flexibiliteit en schaalbaarheid bieden zonder beveiliging te compromitteren. In de praktijk betekent dit dat MLOps-processen modulair zijn opgezet met herbruikbare templates voor veelvoorkomende stappen zoals data-validatie, code-scans, tests en deployments, met standaard beveiligingsconfiguraties die automatisch worden toegepast. Dit voorkomt dat teams per project opnieuw beveiligingsmaatregelen moeten uitdenken en implementeren, wat zowel tijd bespaart als consistentie waarborgt. Tegelijkertijd moeten MLOps-processen kunnen opschalen naar honderden modellen en teams zonder dat de beveiligingscontroles een bottleneck worden. Dit vraagt om geautomatiseerde processen, parallelle uitvoering waar mogelijk, en slim gebruik van caching en artifact-repositories zodat niet elke run alle stappen vanaf nul moet doorlopen.

Data governance en beveiliging in MLOps

Data vormt de basis van elk AI-systeem, en daarom is data governance en beveiliging een kritieke component van MLOps-beveiliging. Voor Nederlandse overheidsorganisaties betekent dit dat alle data die wordt gebruikt voor modeltraining, validatie en testing moet voldoen aan strikte eisen op het gebied van privacy, classificatie, herkomst en kwaliteit. Data wordt geclassificeerd volgens het dataclassificatieschema van de organisatie, waarbij gevoelige of bijzondere persoonsgegevens extra bescherming krijgen. Toegang tot data wordt gereguleerd op basis van least privilege, waarbij alleen geautoriseerde personen en systemen toegang hebben tot specifieke datasets voor specifieke doeleinden. Alle toegang wordt gelogd voor auditdoeleinden, zodat kan worden nagegaan wie welke data heeft gebruikt en wanneer.

Tijdens de dataverzameling en -preparatie worden verschillende beveiligingsmaatregelen toegepast. Data wordt versleuteld in transit en at rest, waarbij sterke encryptie-algoritmen worden gebruikt die voldoen aan de eisen van de BIO en NIS2. Data lineage wordt bijgehouden, zodat kan worden nagegaan waar data vandaan komt, hoe deze is getransformeerd en welke modellen deze hebben gebruikt. Dit is essentieel voor compliance met de AVG, waarbij organisaties moeten kunnen aantonen welke persoonsgegevens worden gebruikt en voor welke doeleinden. Data quality checks worden uitgevoerd om te voorkomen dat onjuiste, incomplete of gemanipuleerde data in modellen terechtkomt, wat kan leiden tot bias, onbetrouwbare uitkomsten of beveiligingskwetsbaarheden.

Voor gevoelige datasets worden aanvullende maatregelen genomen, zoals differential privacy, federated learning of secure multi-party computation, waarbij data niet volledig wordt gedeeld maar alleen de noodzakelijke informatie voor modeltraining. Data wordt opgeslagen in beveiligde repositories met strikte toegangscontroles, waarbij gebruik wordt gemaakt van Azure Key Vault voor het beheer van credentials en Azure Storage met encryption en network isolation voor de daadwerkelijke dataopslag. Retention policies worden toegepast om te zorgen dat data niet langer wordt bewaard dan noodzakelijk, in lijn met AVG-eisen en organisatiebeleid. Wanneer data wordt gedeeld met externe partijen of ketenpartners, worden verwerkersovereenkomsten en data sharing agreements gebruikt om te borgen dat dezelfde beveiligingsstandaarden worden toegepast.

Monitoring en logging van data-gebruik vormen het sluitstuk van data governance. Alle toegang tot data wordt gelogd, inclusief wie welke datasets heeft geopend, wanneer, voor welk doel en met welk resultaat. Anomalie-detectie wordt gebruikt om ongebruikelijke data-accesspatronen te signaleren, zoals toegang buiten normale werkuren, toegang tot ongebruikelijke datasets of pogingen tot bulk-downloads. Deze signalen worden geaggregeerd in security information and event management (SIEM) systemen zoals Microsoft Sentinel, waar security-analisten ze kunnen analyseren op indicaties van misbruik of aanvallen. Door data governance en beveiliging op deze manier te integreren in MLOps-processen, zorgen organisaties ervoor dat data op een verantwoorde en beveiligde manier wordt gebruikt voor AI-ontwikkeling, wat essentieel is voor compliance met de AVG, BIO en andere relevante regelgeving.

Beveiligde modelontwikkeling en -training

De ontwikkel- en trainingfase van AI-modellen vereist specifieke beveiligingsmaatregelen om te voorkomen dat kwetsbaarheden, bias of onbetrouwbaarheid in modellen terechtkomen. Dit begint bij de code- en configuratiebeveiliging: alle code die wordt gebruikt voor data-preprocessing, feature engineering, modeltraining en validatie wordt onderworpen aan security scans die controleren op bekende kwetsbaarheden in dependencies, hardcoded geheimen zoals API-sleutels of wachtwoorden, en code die afwijkt van beveiligingsstandaarden. Wanneer een scan een probleem detecteert, wordt de ontwikkeling geblokkeerd totdat het probleem is opgelost, of wordt geëscaleerd naar een security-team voor beoordeling. Naast automatische scans worden ook statische code-analyse en linting uitgevoerd om codekwaliteit en consistentie te waarborgen.

Tijdens de modeltraining worden verschillende beveiligingscontroles toegepast. Training-omgevingen zijn geïsoleerd van productieomgevingen, met strikte netwerksegmentatie en toegangscontroles. Compute-resources worden beveiligd met managed identities en encryption, en alle training-activiteiten worden gelogd voor auditdoeleinden. Modeltraining wordt uitgevoerd met versioning, zodat elke training-run volledig reproduceerbaar is en kan worden teruggevoerd naar specifieke data, code en configuraties. Dit is essentieel voor compliance met de EU AI Act, waarbij organisaties moeten kunnen aantonen hoe modellen zijn ontwikkeld en getraind. Training-artifacten, zoals getrainde modellen, worden opgeslagen in beveiligde repositories met digitale handtekeningen, zodat kan worden geverifieerd dat een model daadwerkelijk door een geautoriseerd proces is geproduceerd en niet is gewijzigd na training.

Validatie en testing vormen een kritieke beveiligingslaag die voorkomt dat onbetrouwbare of beveiligde modellen in productie terechtkomen. Modellen worden getest op verschillende aspecten: functionele prestaties zoals nauwkeurigheid en recall, maar ook op beveiligingsaspecten zoals robuustheid tegen adversarial attacks, fairness en bias, en compliance met organisatiebeleid en wet- en regelgeving. Security testing omvat bijvoorbeeld het testen van modellen tegen verschillende soorten aanvallen, zoals model inversion attacks, membership inference attacks of model extraction attacks. Fairness testing controleert of modellen geen onterechte discriminatie bevatten tegen specifieke groepen, wat essentieel is voor compliance met de AVG en de EU AI Act. Alleen modellen die alle tests doorstaan, worden goedgekeurd voor deployment naar productie.

Documentatie en traceerbaarheid zijn eveneens belangrijk voor beveiligde modelontwikkeling. Voor elk model wordt een modelcard of technische documentatie bijgehouden die beschrijft hoe het model werkt, welke data is gebruikt voor training, welke beperkingen en risico's het model heeft, en hoe het model moet worden gebruikt en gemonitord. Deze documentatie wordt opgeslagen in een centraal register, zoals Azure Machine Learning model registry, en wordt gekoppeld aan versiecontrole en auditlogs. Dit maakt het mogelijk om bij incidenten of audits snel te achterhalen hoe een model is ontwikkeld, welke beslissingen zijn genomen tijdens de ontwikkeling, en welke maatregelen zijn genomen om beveiliging en betrouwbaarheid te waarborgen. Door deze documentatie en traceerbaarheid te integreren in MLOps-processen, zorgen organisaties ervoor dat modelontwikkeling transparant, controleerbaar en verantwoord is.

Beveiligde deployment en productiebeheer

Gebruik PowerShell-script mlops-security.ps1 (functie Invoke-DeploymentSecurityCheck) – Controleert beveiligingsconfiguraties voor modeldeployments, inclusief toegangsrechten, encryptie, logging en compliance-status..

De deployment-fase is een kritiek moment in de MLOps-levenscyclus, omdat hier modellen daadwerkelijk in productie worden gebracht en toegankelijk worden voor gebruikers. Beveiligde deployment vereist daarom extra controles en maatregelen om te voorkomen dat onveilige, onbetrouwbare of gecompromitteerde modellen in productie terechtkomen. Voordat een model daadwerkelijk wordt gedeployed, wordt een laatste set controles uitgevoerd: zijn alle tests geslaagd, zijn security-scans gepasseerd, is er goedkeuring verkregen van de juiste personen, en voldoet het model aan alle compliance-criteria? Deze controles worden geautomatiseerd via gates in deployment-pijplijnen, zodat handmatige tussenkomst alleen nodig is bij uitzonderingen. Deployment-artifacten worden geverifieerd op integriteit met digitale handtekeningen, en alleen geautoriseerde systemen en gebruikers kunnen deployments uitvoeren.

Tijdens de deployment worden verschillende beveiligingsmaatregelen toegepast. Deployment-omgevingen zijn geïsoleerd van ontwikkel- en testomgevingen, met strikte netwerksegmentatie en toegangscontroles. Modellen worden gedeployed met encryption in transit en at rest, en alle communicatie tussen modellen en andere systemen wordt beveiligd met TLS. Toegang tot deployed modellen wordt gereguleerd met authentication en authorization, waarbij gebruik wordt gemaakt van managed identities, service principals of API-keys met minimale rechten. Rate limiting en throttling worden toegepast om te voorkomen dat modellen worden misbruikt voor denial-of-service-aanvallen of om kosten te genereren. Monitoring en logging worden direct ingeschakeld, zodat alle gebruik van deployed modellen wordt vastgelegd voor security- en compliance-doeleinden.

Canary deployments of blue-green deployments worden gebruikt wanneer mogelijk, zodat nieuwe modelversies eerst worden uitgerold naar een subset van de workload en kunnen worden gemonitord voordat volledige uitrol plaatsvindt. Wanneer tijdens deze fase problemen worden gedetecteerd, zoals afwijkend gedrag, verhoogde foutpercentages of security-incidenten, kan de deployment automatisch worden teruggedraaid zonder dat gebruikers worden getroffen. Rollback-procedures zijn vooraf getest en gedocumenteerd, zodat teams snel kunnen reageren wanneer problemen optreden. Na deployment blijft monitoring actief: de deployment-infrastructuur genereert alerts wanneer afwijkend gedrag wordt gedetecteerd, zoals ongebruikelijke toegangspatronen, verhoogde latency of foutpercentages, of indicaties van security-incidenten. Door deze geautomatiseerde safeguards te combineren met snelle rollback-mogelijkheden, minimaliseert u de impact van problemen terwijl u toch snel nieuwe modelversies kunt uitrollen.

Productiebeheer omvat continue beveiligingsbewaking en -onderhoud van deployed modellen. Modellen worden regelmatig gecontroleerd op beveiligingskwetsbaarheden, zoals bekende vulnerabilities in dependencies of configuraties, en op indicaties van compromittering of misbruik. Updates en patches worden uitgerold via dezelfde beveiligde deployment-processen, met dezelfde controles en goedkeuringen als nieuwe deployments. Wanneer modellen worden buiten gebruik gesteld, worden ze op een veilige manier verwijderd, waarbij alle gerelateerde data en logs worden bewaard volgens retention policies en compliance-eisen. Door productiebeheer op deze manier te integreren in MLOps-beveiliging, zorgen organisaties ervoor dat deployed modellen continu beveiligd blijven, zelfs na de initiële deployment.

Monitoring, detectie en incidentrespons

Gebruik PowerShell-script mlops-security.ps1 (functie Invoke-SecurityMonitoring) – Voert geautomatiseerde security monitoring uit op MLOps-processen en genereert alerts bij afwijkingen of incidenten..

Continue monitoring en detectie vormen een essentieel onderdeel van MLOps-beveiliging, omdat beveiligingsincidenten en kwetsbaarheden snel moeten worden geïdentificeerd en aangepakt voordat ze leiden tot ernstige gevolgen. Monitoring richt zich op verschillende aspecten: beveiligingsgebeurtenissen zoals mislukte authenticatiepogingen, ongebruikelijke toegang tot data of configuraties, wijzigingen in code of modellen zonder goedkeuring, en pogingen tot manipulatie of compromittering. Deze gebeurtenissen worden geaggregeerd in security information and event management (SIEM) systemen zoals Microsoft Sentinel, waar security-analisten ze kunnen analyseren op patronen die duiden op een aanval of intern misbruik. Automatische alerts worden geconfigureerd voor kritieke gebeurtenissen, zodat incidentrespons-teams direct kunnen worden geactiveerd wanneer een ernstige beveiligingsgebeurtenis plaatsvindt.

Naast beveiligingsgebeurtenissen worden ook operationele metingen gemonitord, zoals pijplijn-succespercentages, doorlooptijden, resource-gebruik en foutfrequenties. Wanneer deze metingen significant afwijken van normale patronen, kan dit duiden op problemen zoals denial-of-service-aanvallen, resource-exhaustion of configuratiefouten die beveiligingslekken kunnen introduceren. Anomalie-detectie wordt gebruikt om ongebruikelijke patronen te signaleren, zoals plotselinge toename in modelaanroepen, ongebruikelijke data-accesspatronen of afwijkende modeloutput. Deze signalen worden gecombineerd met beveiligingsgebeurtenissen om een compleet beeld te krijgen van de beveiligingsstatus van MLOps-processen.

Incidentrespons voor MLOps-beveiliging vereist duidelijke procedures en geautomatiseerde capabilities voor snelle detectie en mitigatie. Wanneer een beveiligingsincident wordt gedetecteerd, moeten teams direct kunnen bepalen welke modellen, data of processen zijn getroffen, wat de impact is, en welke acties moeten worden ondernomen om verdere schade te voorkomen. Dit begint bij het hebben van een up-to-date register van alle actieve modellen, pijplijnen en configuraties, zodat snel kan worden bepaald wat de impact is van een specifieke kwetsbaarheid of aanval. Automatische response-capabilities kunnen worden ingebouwd om bijvoorbeeld alle actieve deployments tijdelijk te pauzeren wanneer een kritieke kwetsbaarheid wordt gedetecteerd, of om automatisch alle modellen die in een bepaalde tijdspanne zijn gedeployed te markeren voor review wanneer een compromis wordt vermoed.

Post-incident analyse en learning vormen het sluitstuk van incidentrespons. Na elk beveiligingsincident wordt een grondige analyse uitgevoerd om te begrijpen wat er is gebeurd, wat de oorzaak was, welke impact het heeft gehad, en welke lessen kunnen worden getrokken. Deze analyse wordt vastgelegd in incidentrapporten die worden gedeeld met relevante teams en stakeholders, en wordt gebruikt om MLOps-processen en -beveiliging te verbeteren. Lessons learned worden geïntegreerd in beveiligingsstandaarden, templates en procedures, zodat vergelijkbare incidenten in de toekomst worden voorkomen. Door incidentrespons op deze manier te integreren in MLOps-beveiliging, zorgen organisaties ervoor dat ze snel kunnen reageren op beveiligingsincidenten en continu leren en verbeteren.

Governance, compliance en verantwoording

MLOps-beveiliging speelt een centrale rol in het kunnen aantonen van compliance richting interne en externe toezichthouders. Voor de EU AI Act vormen MLOps-processen het mechanisme waarmee wordt geborgd dat AI-systemen volgens gestandaardiseerde, beveiligde processen worden ontwikkeld en uitgerold, met adequate controles en traceerbaarheid. In AVG-context ondersteunen MLOps-processen de onderbouwing dat geautomatiseerde besluitvorming proportioneel en zorgvuldig is ingericht, dat gegevensbescherming by design en by default is toegepast, en dat alle verwerkingen traceerbaar zijn. Voor de BIO en NIS2 leveren MLOps-configuraties, auditlogs en incidentregistraties bewijs dat risico's rond kritieke processen actief worden beheerst en dat de organisatie in control is over de ontwikkeling en deployment van AI-technologie.

Governance van MLOps-beveiliging vereist duidelijke verantwoordelijkheden en besluitvormingsstructuren. Voor elk type model of proces wordt bepaald wie verantwoordelijk is voor beveiligingsconfiguraties, wie wijzigingen mag doorvoeren en met welke goedkeuring, en wie optreedt als eigenaar bij security-incidenten. Deze rollen moeten zijn vastgelegd in RACI-matrixen of vergelijkbare governance-documenten, zodat er geen onduidelijkheid bestaat over wie welke beslissingen mag nemen. Daarnaast moeten MLOps-standaarden en -templates periodiek worden gereviewd door een centrale security- of architectuurgroep, zodat nieuwe best practices worden geïntegreerd en consistentie wordt gewaarborgd tussen teams. Door deze governance-structuur te ondersteunen met technische afdwinging via Azure Policy of pijplijn-gates, voorkomt u dat teams onbewust afwijken van beveiligingsstandaarden of dat goedkeuringsprocessen worden omzeild.

Audit en compliance-controles worden regelmatig uitgevoerd om te verifiëren dat MLOps-processen voldoen aan beleidsafspraken en externe vereisten. Deze controles kunnen worden geautomatiseerd via scripts die configuraties analyseren en rapportages genereren, of handmatig worden uitgevoerd door security- en compliance-teams. Belangrijk is dat audit-bevindingen worden gedocumenteerd, dat remediatie-acties worden gepland en uitgevoerd, en dat de effectiviteit van remediaties wordt geverifieerd. Door deze cyclus systematisch door te lopen en te documenteren, kunnen organisaties aantonen richting interne en externe auditors dat zij serieus omgaan met MLOps-beveiliging en dat zij continu werken aan verbetering. Dit verhoogt niet alleen het vertrouwen in AI-systemen, maar helpt ook om problemen vroegtijdig te identificeren voordat ze leiden tot incidenten of compliance-schendingen.

Transparantie en verantwoording naar stakeholders zijn ten slotte belangrijk voor het behouden van vertrouwen in AI-systemen. Hoewel technische details van MLOps-processen niet publiek hoeven te zijn, moeten organisaties in begrijpelijke taal kunnen uitleggen dat en hoe AI-systemen worden ontwikkeld en uitgerold met adequate beveiligingsmaatregelen. Publieke verantwoording kan bijvoorbeeld plaatsvinden in jaarverslagen, privacyverklaringen of specifieke verantwoordingsrapportages over de inzet van AI. Hierin wordt beschreven welke typen AI-systemen worden gebruikt, welke waarborgen zijn ingericht in ontwikkel- en deployment-processen, hoe vaak security-assessments worden uitgevoerd en welke verbeteringen in de afgelopen periode zijn doorgevoerd. Dit draagt bij aan vertrouwen in digitale dienstverlening en helpt misverstanden of speculatie over de inzet van AI binnen de overheid te voorkomen.

Compliance & Frameworks

• BIO: 12.02, 12.05, 17.03, 18.01 - Beveiliging van ontwikkel- en deployment-processen voor AI-systemen, inclusief code-analyse, data governance, modelbeveiliging en traceerbaarheid.
• ISO 27001:2022: A.14.2.1, A.14.2.7, A.18.1.3, A.12.4.1 - Secure development lifecycle, change management en logging rond AI-ontwikkeling en deployment.
• NIS2: Artikel - Voortdurende risicobeoordeling en beveiliging van kritieke digitale diensten, inclusief ontwikkel- en deployment-processen voor AI-systemen.

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Richt een volledige MLOps-beveiligingsarchitectuur in met beveiligingsmaatregelen voor elke fase van de levenscyclus: data governance, beveiligde modelontwikkeling, artifactbeheer, beveiligde deployment en continue monitoring. Integreer beveiliging in governance, risicomanagement en audit, zodat organisaties aantoonbaar voldoen aan eisen vanuit wet- en regelgeving en betrouwbare AI-systemen kunnen ontwikkelen en uitrollen.

• Implementatietijd: 260 uur
• FTE required: 1.2 FTE