De CRA vraagt wat er in je software zit. Maar wat zit er in de black box?

Als freelance projectmanager kijk ik hier niet naar als een puur technisch probleem, maar als een delivery-vraagstuk. De CRA raakt je scope, je planning, je leveranciersafspraken en, misschien wel de belangrijkste vraag, wie tekent voor het risico als het misgaat. Dit hoort op de stuurgroep, niet alleen bij het securityteam. Vandaar dit stuk, geschreven vanuit de bril van iemand die techniek en business met elkaar moet laten praten.

De Cyber Resilience Act stelt een vraag die simpel klinkt: wat zit er in je software?

Voor klassieke code hebben we daar een antwoord op. Het heet een SBOM, een Software Bill of Materials. Een inventaris van elke component, elke library, elke afhankelijkheid. De CRA maakt die verplicht: in Annex I moet je een machine-leesbare SBOM opstellen, minstens van je top-level dependencies, en die bijhouden zolang je het product ondersteunt. Het is onderdeel van je technische documentatie, opvraagbaar door de toezichthouder. Volledige naleving moet klaar zijn tegen 11 december 2027, de meldplicht voor actief misbruikte kwetsbaarheden al tegen 11 september 2026.

Zover de theorie. Nu de realiteit. Je software bevat vandaag AI. Een model in een feature, een API-call naar een LLM, een aanbevelingsengine die je zelf niet meer volledig kunt uitleggen. En daar loopt de SBOM-logica vast.

Een SBOM veronderstelt dat je je componenten kunt ontleden

Bij een library kan dat. Je weet welke versie erin zit, welke kwetsbaarheden eraan hangen, of er een patch is. Bij een AI-model kan dat niet. Je kunt documenteren "we gebruiken model X", maar niet wat er echt in die black box zit: de trainingsdata, de gewichten, het gedrag onder randgevallen, de afhankelijkheden die je niet ziet. Je hebt een component in je product waarvan je de binnenkant niet kent. En dat is precies het soort ding dat de CRA je vraagt te beheersen.

De sector heeft daar een antwoord op bedacht: de AI-BOM. Een uitbreiding van het SBOM-idee naar AI-specifieke elementen, modellen, prompts, agents, frameworks, met de metadata om ze te besturen. Nuttig, en het wordt de norm. Maar laat je niet foppen: een AI-BOM vertelt je dát er een model in je software zit. Niet óf het in jouw context veilig of exploiteerbaar is. Het is een betere inventaris, geen conclusie.

En daar komt ISO 42001 binnen

Waar de SBOM en de AI-BOM je vertellen wat erin zit, is ISO 42001 het managementsysteem dat je dwingt er iets mee te doen. Het verplicht je om je AI-systemen te inventariseren, om ontwerp en datagebruik te documenteren, om impactbeoordelingen te maken over de hele levenscyclus, en om provenance en integriteit te controleren. Het is, kort gezegd, hoe je verantwoording aflegt voor het deel van je software dat je niet kunt openmaken.

Belangrijke nuance, want ik zie hier vaak overmoed: ISO 42001 dekt niet automatisch alles wat de AI Act van je vraagt. Er wordt zelfs een aparte Europese norm ontwikkeld (prEN 18286) om dat gat te dichten. Een 42001-certificaat is dus geen vrijgeleide. Het is een fundament, geen eindpunt. Wie het als vinkje behandelt, komt bedrogen uit bij de eerste audit die verder graaft dan de map met beleidsdocumenten.

Wat betekent dit concreet voor jou?

Vier stappen die je zelf kunt zetten, in het verlengde van de klassieke SBOM-aanpak:

1. Maak een inventaris van je AI. Niet "gebruiken we AI", maar: welke modellen, in welke systemen, met welke data, met welke eigenaar. De meeste organisaties kunnen die vraag vandaag niet beantwoorden, en je kunt niet beheersen wat je niet in beeld hebt.
2. Eis transparantie van je leveranciers. Model cards, dataprovenance, een verklaring over trainingsdata en bekende beperkingen. Als je het model niet zelf bouwt, is dit je enige venster in de black box. Zet het contractueel vast.
3. Breng een VEX-achtige logica naar je AI. Een kwetsbaarheid of beperking van een model is niet in elke context een reëel risico. Beoordeel per gebruik of het in jóuw toepassing echt exploiteerbaar is, en documenteer dat oordeel.
4. Koppel dit aan een risicoafweging. Een inventaris zonder threat modeling blijft een document zonder conclusie. Doe een beknopte oefening voor je meest kritieke AI-systemen, en herhaal ze.

De kern

De CRA vraagt wat er in de doos zit. Voor code beantwoord je dat met een SBOM. Voor AI kun je de doos niet openen, en dan wordt de vraag niet makkelijker maar belangrijker. ISO 42001 is niet het antwoord op alles, maar het is wel de manier waarop je aantoonbaar verantwoording aflegt voor het deel dat je niet kunt zien.

Certificaat aan de muur is niet hetzelfde als weten wat er in je black box zit. Het verschil tussen die twee is waar de meeste organisaties de komende twee jaar gaan struikelen.