Digitale productveiligheid voor startups: hoe AI, software en cybersecurityregels in elkaar grijpen

Waarom digitale productveiligheid niet meer alleen over hardware gaat

Lange tijd was productveiligheid vooral gericht op tastbare producten. De logica daarachter was overzichtelijk: een product moest aan bepaalde essentiële eisen voldoen voordat het op de markt mocht komen, technische normen hielpen om die eisen concreet te maken, en fabrikanten moesten ingrijpen als een product achteraf toch onveilig bleek. Dat klassieke kader werkte goed zolang “product” in de praktijk vooral hardware betekende.

Die werkelijkheid is veranderd. Steeds meer functies die vroeger door fysieke componenten of menselijke handelingen werden vervuld, zitten nu in software. Software stuurt apparaten aan, bewaakt veiligheid, verwerkt gegevens, neemt geautomatiseerde beslissingen en kan na release op afstand worden aangepast via updates. Daardoor is het logisch dat digitale productveiligheid ook losstaande software is gaan raken, en niet alleen software die in hardware is ingebouwd.

Voor techbedrijven is dat een fundamentele verschuiving. Zodra software onder productveiligheidslogica valt, komt niet alleen de code zelf in beeld, maar ook de manier waarop updates, wijzigingen en correcties worden georganiseerd. In de praktijk betekent dat dat een releasecyclus niet meer alleen een technisch proces is, maar ook een compliancevraagstuk kan worden. Zeker bij AI speelt daarbij dat substantiële wijzigingen opnieuw gevolgen kunnen hebben voor conformiteit en beoordeling.

Bij Startup-Recht zien we dat dit voor founders vaak het moment is waarop de juridische puzzel ingewikkeld wordt. Een softwareteam denkt in iteraties, sprints en patches. Het Europese veiligheidskader denkt eerder in kwalificaties, essentiële eisen, conformiteit en corrigerende maatregelen. Die twee werelden schuiven nu steeds nadrukkelijker over elkaar heen.

Veiligheid betekent inmiddels meer dan fysieke schade voorkomen

Digitale productveiligheid draait bovendien niet meer alleen om de vraag of iemand lichamelijk letsel kan oplopen door een gebrekkig product. Bij software en AI verschuift het risicobeeld. Een systeem kan technisch goed functioneren en toch ernstige problemen veroorzaken, bijvoorbeeld door discriminatoire uitkomsten, aantasting van privacy of andere ingrepen in de rechten en belangen van gebruikers.

Dat bredere veiligheidsbegrip zie je terug in de AI-Verordening en in de CRA. De AI-Verordening koppelt veiligheid niet alleen aan gezondheid en klassieke productrisico’s, maar ook aan grondrechten. Daarom zijn bepaalde AI-toepassingen verboden, gelden voor hoog-risico AI-systemen aanvullende eisen rond onder meer data, documentatie en menselijk toezicht, en worden ook systeemrisico’s bij algemene AI-modellen in beeld gebracht. De CRA legt de nadruk op cyberveiligheid van producten met digitale elementen, met aandacht voor veiligheid by design, kwetsbaarheden en patching.

Voor startups en scale-ups is dat belangrijk omdat de juridische analyse daardoor breder wordt dan “werkt het product veilig?”. Ook vragen als “hoe robuust is het systeem?”, “hoe worden kwetsbaarheden opgespoord?”, en “welke risico’s ontstaan voor gebruikers buiten fysieke schade?” kunnen relevant worden. Vooral techbedrijven die AI inzetten in gevoelige contexten, of software bouwen die diep verweven is met apparaten, processen of kritieke functies, krijgen daardoor met een zwaardere beoordelingslat te maken.

Tegelijk laat dit ook zien waarom de uitvoering lastig is. Zodra wetgeving grondrechten en productveiligheid in één systeem probeert te vangen, wordt certificering complexer. Niet alles wat juridisch relevant is, laat zich eenvoudig vertalen naar een technische norm of een afvinkbare checklist. Dat maakt digitale productveiligheid juridisch ambitieus, maar niet automatisch eenvoudig toepasbaar.

Vier regimes die je als techbedrijf uit elkaar moet houden

De AI-Verordening

De AI-Verordening is gericht op AI-systemen, dus op software die onder de daarin opgenomen definitie valt. Het kader is risicogebaseerd: sommige toepassingen zijn verboden, sommige systemen worden als hoog risico aangemerkt en krijgen zwaardere eisen, en voor lichtere toepassingen gelden beperktere verplichtingen. Daarbij maakt het niet uit of AI als standalone software draait of in een fysiek product zit ingebouwd. Ook AI die als dienst wordt gebruikt, kan binnen het bereik vallen.

Voor startups is vooral van belang dat de AI-Verordening niet alle software reguleert, maar specifiek AI-software. Daardoor ontstaat meteen een grensprobleem: software met geavanceerde functionaliteit valt niet automatisch onder dit kader, terwijl software die wel als AI kwalificeert soms juist met zware verplichtingen te maken krijgt. Die beperkte focus op AI lost dus niet het hele veiligheidsvraagstuk rond software op.

De CRA

De CRA is breder opgezet vanuit cyberveiligheidsperspectief. Zij ziet op producten met digitale elementen, waaronder hardware, standalone software, softwaremodules en bepaalde externe gegevensverwerkingsdiensten die door de fabrikant worden geleverd. De nadruk ligt op cyberveiligheidsvereisten, het omgaan met kwetsbaarheden en het beschikbaar maken van patches.

Voor productgedreven techbedrijven is de CRA daarom vaak het meest tastbare kader. Bouw je software die als product op de markt wordt gebracht, of software die een digitaal product ondersteunt, dan kom je al snel in deze sfeer terecht. Tegelijk zit hier ook een belangrijke beperking: de CRA is productgericht. Zuivere online diensten vallen niet automatisch mee onder hetzelfde regime. Daardoor is de dekking ambitieus, maar niet volledig sluitend voor alle moderne softwaremodellen.

NIS2

NIS2 kijkt minder naar het product en meer naar de organisatie en haar systemen. Het gaat om cyberbeveiliging vanuit ondernemingsperspectief. Binnen het toepassingsgebied moeten organisaties passende en evenredige maatregelen nemen en significante incidenten melden volgens een trapsgewijs meldschema. Daarbij spelen ook governance en beveiliging in de toeleveringsketen een duidelijke rol.

Voor scale-ups is dat relevant omdat groei niet alleen commercieel effect heeft, maar ook kan bepalen of een bedrijf binnen een zwaarder regelgevingskader terechtkomt. De vraag is dus niet alleen wat je bouwt, maar ook in welke sector je opereert, hoe groot je organisatie wordt en welke rol je in een keten vervult.

DORA

DORA is de sectorspecifieke variant voor financiële entiteiten. Dat regime is strenger en gedetailleerder dan NIS2 en richt zich onder meer op ICT-risicobeheer, incidentrapportage, veerkrachttesten, derde-partijrisico en dreigingsmonitoring. Binnen de financiële sector functioneert DORA in beginsel als lex specialis ten opzichte van NIS2 voor de inhoudelijke beveiligingseisen.

Voor fintechs, insurtechs en andere groeibedrijven in de financiële keten is dit cruciaal. Niet elk techbedrijf raakt DORA direct, maar zodra je in die sector opereert, of als leverancier nauw op zulke partijen aansluit, wordt het speelveld direct een stuk intensiever.

Het echte knelpunt: wanneer is software een product en wanneer een dienst?

De lastigste vraag in digitale productveiligheid is vaak niet welke regel bestaat, maar welke regel op jouw softwaremodel van toepassing is. Software kan immers op de markt worden gebracht als product, bijvoorbeeld als downloadbare software of als onderdeel van een apparaat, maar ook als dienst via een licentie, abonnement of cloudomgeving. Juist daar ontstaat frictie tussen de verschillende regimes.

NIS2 verplicht organisaties om hun eigen systemen te beveiligen, ongeacht of zij software verkopen of software als dienst aanbieden. De CRA richt zich daarentegen op producten met digitale elementen en dus vooral op de software als product. Dat betekent dat hetzelfde bedrijf met verschillende verplichtingen te maken kan krijgen, afhankelijk van de manier waarop zijn technologie juridisch wordt gekwalificeerd.

Voor SaaS-bedrijven is dat extra relevant. Bepaalde cloudoplossingen kunnen onder de CRA vallen als zij de functionaliteit van een product met digitale elementen ondersteunen, maar waar die grens precies ligt is niet scherp afgebakend. Dat levert rechtsonzekerheid op voor ondernemingen die werken met hybride modellen, dus software die deels product, deels dienst en deels infrastructuur is.

In de praktijk betekent dit dat founders niet te snel mogen aannemen dat één label volstaat. “We zijn een SaaS-bedrijf” zegt juridisch nog niet genoeg. Ook “we bouwen AI” of “we leveren embedded software” is zonder nadere analyse te grof. De relevante vraag is telkens hoe de oplossing wordt aangeboden, welke functie zij vervult, met welke producten of netwerken zij verbonden is en binnen welk regulatoir kader de onderneming zelf opereert.

Waarom compliance voor startups snel zwaar kan worden

De overlap tussen deze regimes brengt een praktisch risico mee: overregulering en overrapportering. Als verschillende kaders tegelijk rapportage-, risicobeheer- en documentatieverplichtingen oproepen, dreigt compliance een doel op zichzelf te worden. Dat is niet alleen kostbaar, maar kan ook afleiden van de feitelijke technische verbetering van het product of systeem.

Dat probleem is voor software nog scherper dan voor hardware. Moderne software wordt voortdurend aangepast. Releasecycli zijn kort, updates volgen elkaar snel op en kwetsbaarheden moeten praktisch worden opgepakt. Een systeem van terugkerende beoordeling en certificering past daarom niet altijd soepel op de realiteit van softwareontwikkeling. Het gevolg kan zijn dat naleving gaat wringen met de snelheid waarmee techbedrijven normaal gesproken bouwen en verbeteren.

Voor kleinere bedrijven komt daar nog iets bij. Rapportage, certificering en technische documentatie vergen tijd, mensen en budget. Grote ondernemingen kunnen zulke trajecten vaak inrichten als afzonderlijke complianceprojecten. Voor startups en scale-ups lopen die verplichtingen juist direct door de productontwikkeling heen. Dat maakt prioritering lastig: elke euro en elk uur dat naar formele compliance gaat, gaat niet naar engineering, validatie of commerciële groei.

Open source voegt nog een extra laag toe. De regelgeving probeert daar wel onderscheid te maken, maar laat ook grijze zones bestaan, vooral wanneer vrijwillige of communitygedreven software in de praktijk doorgroeit naar commerciële inzet of ondersteuning daarvan. Juist in het startup-ecosysteem, waar open source regelmatig een bouwsteen van het product is, verdient dat extra aandacht.

Wat startups en scale-ups hier concreet mee moeten doen

Voor techbedrijven begint digitale productveiligheid met kwalificatie. Je moet eerst scherp krijgen of jouw software juridisch vooral als AI-systeem, digitaal product, dienst of gereguleerde bedrijfsactiviteit wordt benaderd. Zonder die stap is het bijna onmogelijk om gericht te bepalen welke verplichtingen prioriteit hebben.

Daarna volgt de vertaalslag naar het ontwikkelproces. Werk je met software-updates, vulnerability management en doorlopende productverbetering, dan moet compliance daarop aansluiten en niet pas ná release beginnen. In de praktijk betekent dit dat productteams, security en legal eerder samen moeten optrekken, juist omdat wijzigingen in software ook gevolgen kunnen hebben voor conformiteit, meldplichten of documentatie.

Daarnaast is het verstandig om alert te zijn op dubbelingen. Zeker waar AI-Verordening, CRA en NIS2 elkaar raken, kunnen vergelijkbare informatieverplichtingen of risicobeoordelingen langs verschillende routes terugkomen. Voor scale-ups die snel opschalen, meerdere markten bedienen of verschillende productvormen combineren, voorkomt een centrale complianceblik veel onnodige frictie.

Bij Startup-Recht zien we dat dit vooral relevant is voor bedrijven die hard groeien op een technisch sterk productfundament. In de vroege fase lijkt regelgeving soms nog iets voor later. Maar juist bij digitale productveiligheid geldt dat architectuur, releasebeleid en documentatiekeuzes vroeg worden gemaakt, terwijl de juridische impact vaak pas later zichtbaar wordt. Wie die vertaalslag te laat maakt, loopt niet alleen juridisch risico, maar ook vertraging op in productontwikkeling en go-to-market.

De belangrijkste takeaway

Digitale productveiligheid is geen nicheonderwerp meer voor fabrikanten van hardware. Voor startups en scale-ups raakt het inmiddels ook software, AI, cloudfunctionaliteit en de cyberweerbaarheid van organisaties zelf. De grootste uitdaging zit daarbij niet alleen in nieuwe regels, maar vooral in de overlap tussen regels die vanuit verschillende logica zijn opgebouwd.

Daarom is de kernvraag voor techbedrijven niet of zij met digitale productveiligheid te maken krijgen, maar waar precies het zwaartepunt ligt in hun eigen model. Wie die vraag op tijd stelt, kan productontwikkeling, security en compliance veel beter op elkaar laten aansluiten. En dat is precies waar in een snelgroeiende techomgeving de meeste winst te behalen valt.

‍