Het auteursrecht beschermt de manier waarop software is geschreven. Bedrijfsgeheimen beschermen wat verborgen blijft. Geen van beide beschermt echter wat doorgaans het meest waardevol is: wat de software daadwerkelijk doet. Juist dat is de leemte die het octrooirecht beoogt op te vullen, en de Europese regels daarvoor zijn in de praktijk werkbaarder dan hun reputatie doet vermoeden.
Wanneer een oprichter tegen zijn octrooigemachtigde zegt: “We moeten onze AI beschermen,” is het meest nuttige antwoord geen geruststelling, maar een vraag: welk onderdeel?
Een softwaresysteem behandelen als één enkel object dat beschermd moet worden, is een van de kostbaarste fouten in een technologiestrategie. Een AI-product is geen ondeelbaar geheel, maar een stapeling van verschillende componenten, waarbij elk onderdeel onder een ander rechtsgebied valt.
Een typisch AI-systeem bestaat uit trainingsdata, een modelarchitectuur, de gedurende maanden van experimenteren geoptimaliseerde gewichten en hyperparameters, broncode, interfaces, output, documentatie, een merk en technische knowhow die uitsluitend binnen het ontwikkelteam aanwezig is. De broncode valt onder het auteursrecht. Gewichten en trainings- of afstemmingsmethoden kunnen doorgaans het beste als bedrijfsgeheim worden beschermd. Een werkelijk nieuwe technische methode kan voor octrooibescherming in aanmerking komen. Het merk wordt beschermd door het merkenrecht. De door AI gegenereerde output roept bovendien eigen, nog altijd niet volledig uitgekristalliseerde vragen op over auteurschap.
De opgave is dus nooit om één enkel intellectueel eigendomsrecht te kiezen voor “de AI”. De juiste aanpak is het systeem in kaart te brengen en voor iedere laag het passende beschermingsinstrument te kiezen. Dat is vooral van belang op het punt waar de twee goedkoopste en meest automatische vormen van bescherming — auteursrecht en bedrijfsgeheimen — tekortschieten: het onderdeel van de software dat doorgaans de grootste commerciële waarde vertegenwoordigt.
Waar auteursrecht en bedrijfsgeheimen tekortschieten
Het auteursrecht is vaak de eerste, vanzelfsprekende reflex. Het ontstaat automatisch, kost niets, geldt langdurig en doet precies waarvoor het bedoeld is: voorkomen dat anderen uw broncode, handleidingen of gebruikersinterfaces kopiëren. Maar het auteursrecht beschermt de vorm, niet de functie. Het beschermt de specifieke formulering die een programmeur heeft gekozen, niet het onderliggende idee, niet het algoritme, niet de methode en evenmin het gedrag van het draaiende softwaresysteem.
Het Europese recht is hierover ondubbelzinnig. De Softwarerichtlijn (2009/24/EG) beschermt uitsluitend de uitdrukkingsvorm van een computerprogramma en laat de ideeën en beginselen die aan enig onderdeel daarvan ten grondslag liggen — inclusief de interfaces — buiten de reikwijdte van het auteursrecht. Het Hof van Justitie bevestigde dit in de zaak SAS Institute v World Programming: de functionaliteit van een computerprogramma, de programmeertaal en het formaat van de gebruikte gegevensbestanden worden niet als beschermde uitdrukkingsvorm beschouwd. Een concurrent mag dus bestuderen hoe uw software zich gedraagt en die functionaliteit vervolgens volledig opnieuw ontwikkelen in geheel andere broncode, zonder daarmee inbreuk op het auteursrecht te maken. De richtlijn biedt daarvoor zelfs expliciet ruimte: rechtmatige gebruikers mogen een programma observeren, bestuderen en testen om de onderliggende ideeën en beginselen te achterhalen, en onder bepaalde voorwaarden mag software zelfs worden gedecompileerd ten behoeve van interoperabiliteit.
Dit zijn bewuste regels die concurrentie bevorderen. Zij maken tevens duidelijk dat het auteursrecht nooit bedoeld is geweest om een monopolie te verschaffen op wat software daadwerkelijk doet.
Bedrijfsgeheimen beschermen een ander terrein, maar laten eveneens een belangrijke leemte bestaan. Zij kunnen juist beschermen wat het auteursrecht niet beschermt: het server-side model, de trainingspipeline, afstemmingsparameters en de interne architectuur. Maar die bescherming duurt slechts zolang deze informatie daadwerkelijk geheim blijft. Een bedrijfsgeheim bestaat alleen zolang het geheim is, alleen zolang het economische waarde ontleent aan die geheimhouding, en alleen wanneer de rechthebbende redelijke maatregelen heeft genomen om de geheimhouding te waarborgen.
Die bescherming biedt echter geen verweer tegen iemand die onafhankelijk tot dezelfde oplossing komt. De Europese Richtlijn Bedrijfsgeheimen (2016/943) staat zowel onafhankelijke ontwikkeling als reverse engineering van een rechtmatig verkregen product uitdrukkelijk toe, behoudens geldige contractuele beperkingen. De richtlijn beschermt bovendien de arbeidsmobiliteit: werknemers mogen de ervaring en vaardigheden gebruiken die zij eerlijk tijdens hun werkzaamheden hebben opgedaan. Voor software die aan klanten wordt geleverd, via API’s toegankelijk is, wordt gebenchmarkt, kan worden gedecompileerd en wordt ontwikkeld door engineers die regelmatig van werkgever wisselen, zijn dit geen theoretische maar zeer reële beperkingen. Zodra een product op de markt verschijnt, kan veel van wat het onderscheidend maakt worden afgeleid, waardoor het geheim geleidelijk zijn beschermende waarde verliest.
Juist daarin schuilt de leemte. De commerciële waarde van software ligt meestal in haar technische werking, terwijl juist die werking buiten de bescherming van het auteursrecht valt en uiteindelijk ook niet door geheimhouding kan worden behouden zodra het product daadwerkelijk wordt gebruikt.
Wat een octrooi beschermt – en tegen welke prijs
Een octrooi is het enige gangbare intellectuele eigendomsrecht dat de technische oplossing zelf beschermt, in plaats van de wijze waarop deze is opgeschreven of geheim wordt gehouden. Het doet er niet toe of een inbreukmaker ooit uw broncode heeft gezien: als een concurrent zelfstandig tot dezelfde geoctrooieerde methode komt, vormt dat geen verweer. Juist daarom zijn octrooien zo waardevol wanneer het technische voordeel van software van buitenaf waarneembaar is, bijvoorbeeld in netwerkverkeer, benchmarkresultaten, een beveiligingshandshake of een interoperabele interface – kortom, juist op de plaatsen waar bescherming als bedrijfsgeheim het kwetsbaarst is.
Die bescherming heeft echter een prijs: openbaarmaking. Om een octrooi te verkrijgen moet de uitvinding zó duidelijk worden beschreven dat een vakman haar kan reproduceren, en die beschrijving wordt gepubliceerd. Dat is de kern van de afweging waarop het octrooirecht berust: een tijdelijk uitsluitend recht in ruil voor permanente openbaarmaking.
Daarom leent niet iedere innovatie zich voor octrooibescherming. Wanneer uw concurrentievoordeel berust op iets dat een buitenstaander in de praktijk nooit zou kunnen reverse engineeren – bijvoorbeeld een eigen methode voor datacuratie of een verzameling vertrouwelijke afstemmingsheuristieken – kan publicatie in een octrooiaanvraag die kennis juist aan concurrenten prijsgeven. De strategische vraag luidt daarom niet: “Kunnen we hiervoor een octrooi krijgen?”, maar: “Willen we deze kennis openbaar maken in ruil voor exclusiviteit, of vertegenwoordigt zij meer waarde wanneer zij geheim blijft?”
Dat verklaart waarom volwassen softwareportefeuilles uit meerdere beschermingslagen bestaan in plaats van uit één enkel intellectueel eigendomsrecht. Het auteursrecht vormt de basis en biedt bescherming tegen letterlijk kopiëren. Bedrijfsgeheimen beschermen de vluchtige en verborgen elementen: datasets, parameters, interne hulpmiddelen en andere niet-openbare details. Octrooien beschermen daarentegen de stabiele technische abstracties: verwerkingsprocessen, protocollen, interacties tussen apparaten en prestatiemechanismen die een concurrent anders rechtmatig opnieuw zou kunnen ontwikkelen. De kunst zit in de juiste afbakening: octrooieer de structuur, houd de instellingen geheim.
Kan AI in Europa worden geoctrooieerd?
Er bestaat een hardnekkige opvatting dat software – en AI in het bijzonder – in Europa niet octrooieerbaar is, omdat een AI-model “slechts wiskunde” zou zijn en daarom buiten het octrooisysteem valt. Die voorstelling van zaken is echter te simplistisch.
Het Europees Octrooiverdrag sluit wiskundige methoden, bedrijfsmethoden, spelregels, presentaties van informatie en “computerprogramma’s” inderdaad van octrooieerbaarheid uit. Maar die uitsluiting geldt uitsluitend als zodanig, en juist die nuance is doorslaggevend. Het Europees Octrooibureau vraagt niet of een uitvinding gebruikmaakt van software, een algoritme of een neuraal netwerk – vrijwel iedere moderne uitvinding doet dat. De relevante vraag is of het geclaimde onderwerp een technisch karakter heeft en of de kenmerken waarop de uitvinderswerkzaamheid berust, bijdragen aan de oplossing van een technisch probleem met technische middelen.
Wanneer men deze benadering eenmaal begrijpt, wordt ook de systematiek duidelijk. De eerste drempel is laag: een conclusie waarin een computer, processor of netwerk voorkomt, bezit in beginsel technisch karakter en wordt niet reeds daarom van octrooieerbaarheid uitgesloten. Maar daarmee is nog niet gezegd dat de uitvinding ook daadwerkelijk octrooieerbaar is. Bij de beoordeling van de uitvinderswerkzaamheid laat de examinator alle kenmerken buiten beschouwing die niet bijdragen aan het technische karakter van de uitvinding en beoordeelt uitsluitend wat overblijft. Dit is de kern van de zogenoemde COMVIK-benadering van het Europees Octrooibureau, en de gevolgen daarvan zijn aanzienlijk. Een bedrijfsregel, prijsformule, marketingdoelstelling of spelmechaniek kan weliswaar onderdeel uitmaken van de conclusie, maar wordt slechts beschouwd als een randvoorwaarde: een gegeven probleem waarmee de ingenieur aan de slag moet, niet als de bron van de uitvinding. De uitvinderswerkzaamheid moet daarom liggen in de niet voor de hand liggende technische wijze waarop het systeem aan die randvoorwaarden voldoet. Specifiek voor software geldt bovendien dat het programma een verder technisch effect (further technical effect) moet teweegbrengen: een technisch resultaat dat verder gaat dan de normale uitvoering van software op een processor.
Twee contrasterende voorbeelden illustreren waar de grens in de praktijk ligt. Een neuraal netwerk dat is getraind om op basis van een signaal onregelmatige hartslagen te detecteren, is in beginsel octrooieerbaar, omdat het een concreet technisch doel dient. Een neuraal netwerk dat juridische documenten op basis van hun tekst indeelt in declaratiecategorieën is dat in beginsel niet: het doel is taalkundig en administratief, hoe geavanceerd de onderliggende wiskunde ook mag zijn. Het model is in beide gevallen van dezelfde aard. Wat verschilt, is het probleem waarvoor het wordt ingezet.
De moeilijkere gevallen: wanneer de uitvinding een commercieel karakter lijkt te hebben
Hetzelfde uitgangspunt geldt voor uitvindingen die op het eerste gezicht een commercieel karakter hebben. Het Europees Octrooibureau sluit octrooien op het gebied van reclame, financiën of gaming niet uit; het sluit slechts uit dat juist die reclame-, financiële of spelaspecten de grondslag vormen voor de uitvinderswerkzaamheid.
Neem een videogame. Het voorspellen van de baan van een biljartbal, hoe nauwkeurig ook, lost geen technisch probleem op dat verder gaat dan de uitvoering van de spelregels. Maar het in realtime aanpassen van de stapgrootte van een simulatie op basis van gemeten netwerklatentie is wél technisch, omdat daarmee een daadwerkelijk netwerk- en verwerkingsprobleem wordt opgelost, en niet slechts de spelervaring wordt vormgegeven.
Hetzelfde uitgangspunt geldt voor de meest toonaangevende AI-technieken. Een trainingsmethode kan octrooieerbaar zijn wanneer de opzet ervan een technisch uitvoeringsprobleem oplost. Denk bijvoorbeeld aan het toewijzen van data-intensieve trainingsfasen aan een GPU en voorbereidende bewerkingen aan een CPU, waarbij gespecificeerde geheugentransfers tussen beide zorgen voor een efficiëntere uitvoering. Dat is een technische oplossing, in tegenstelling tot de algemene ambitie om “een model beter te laten voorspellen”. Het Europees Octrooibureau is bovendien kritischer geworden ten aanzien van algemeen geformuleerde conclusies. In recente beslissingen zijn conclusies afgewezen waarin beloofde voordelen – zoals een lager geheugengebruik of hogere verwerkingssnelheid – niet geloofwaardig konden worden onderbouwd over de volledige reikwijdte van de geclaimde uitvinding. Ook heeft het Bureau geoordeeld dat reinforcement learning op zichzelf geen technisch vakgebied vormt. De les voor het opstellen van octrooiaanvragen is onverbiddelijk: beschrijf het technische mechanisme, niet de beoogde ambitie.
Dezelfde toets, anders verwoord in andere rechtsgebieden
Deze benadering laat zich echter niet zonder meer naar andere rechtsgebieden vertalen. Juist daarin schuilt de praktische uitdaging van een internationale octrooistrategie. De belangrijkste octrooisystemen verschillen minder in de uitkomst dan in de weg waarlangs zij die bereiken.
In de Verenigde Staten worden octrooiconclusies beoordeeld aan de hand van het zogenoemde Alice-toetsingskader. Daarbij wordt eerst onderzocht of een conclusie is gericht op een abstract idee en, zo ja, of dat idee is geïntegreerd in een praktische toepassing of méér omvat dan een generieke implementatie op een computer.
China verlangt dat sprake is van een technische oplossing en erkent tegenwoordig expliciet de bijdrage van algoritmische kenmerken wanneer deze nauw samenhangen met technische kenmerken, bijvoorbeeld doordat zij de verwerkingssnelheid verhogen, opslagruimte verminderen of datatransmissie efficiënter maken.
Japan hanteert weer een andere formulering en verlangt een schepping van technische ideeën die gebruikmaakt van natuurwetten en die concreet wordt gerealiseerd met behulp van hardware.
Ook het Verenigd Koninkrijk, dat lange tijd een uitzonderingspositie innam, is aanzienlijk opgeschoven richting de Europese benadering. In de zaak Emotional Perception AI Ltd v Comptroller-General (UKSC 3), beslist in februari 2026, heeft het Britse Hooggerechtshof afstand genomen van de Aerotel-toets, die bijna twintig jaar lang bepalend was geweest voor de octrooieerbaarheid van software en AI. Volgens het Hof berustte die toets op een onjuiste uitleg van het Europees Octrooiverdrag.
De uitspraak stuurt Britse examinatoren nadrukkelijk in de richting van de benadering van het Europees Octrooibureau: de lage drempel van any hardware voor het aannemen van een uitvinding en een beoordeling van de uitvinderswerkzaamheid uitsluitend aan de hand van technische kenmerken, in grote lijnen overeenkomstig de beslissing G 1/19 van de Grote Kamer van Beroep. Het Britse octrooibureau (UKIPO) heeft inmiddels zijn afzonderlijke richtlijnen voor AI-uitvindingen ingetrokken.
In hoeverre beide systemen in de praktijk volledig naar elkaar zullen toegroeien, moet nog blijken. De praktische uitwerking is nog niet volledig uitgekristalliseerd, de betreffende aanvraag is terugverwezen naar het octrooibureau en op basis van de nieuwe maatstaf bestaat nog weinig nationale rechtspraak. De richting is echter duidelijk: het Verenigd Koninkrijk beweegt zich naar de Europese benadering toe, niet ervan af.
Die internationale convergentie is reëel. Overal geldt uiteindelijk dezelfde betrouwbare aanpak: formuleer de uitvinding rondom een concreet technisch probleem, beschrijf het specifieke technische mechanisme waarmee dat probleem wordt opgelost en onderbouw het meetbare technische effect. Pas vervolgens de formulering aan de terminologie van het betreffende octrooibureau aan. De meest gemaakte fout is eveneens overal dezelfde. Men claimt een bedrijfsidee, een aanbeveling of een spelregel, verpakt die vervolgens in algemene computerterminologie en hoopt daarmee aan de octrooieerbaarheidstoets te voldoen. Dat werkt niet. Examinatoren en rechters kijken naar de inhoud, niet naar de bewoordingen. Een “regel” hernoemen tot een “module” of niet-technische logica verpakken in terminologie over servers en clients overtuigt niemand.
Goed octrooischrijven is goed engineeren
Er is nog een laatste punt, en dat maakt de exercitie minder defensief en juist constructief van aard. De centrale eis van het Europese octrooisysteem – beschrijf het technische probleem, identificeer de technische middelen en leg uit hoe deze leiden tot een geloofwaardig technisch effect – is niet slechts een procedurele hobbel die moet worden genomen. Zij komt vrijwel volledig overeen met de discipline van goed engineeringwerk: deze niet-technische behoefte leidt tot dit technische probleem; dit is het mechanisme dat daarvoor een oplossing biedt; en dit is het technische effect dat daardoor wordt bereikt.
Een ontwikkelteam dat zijn uitvinding op deze manier kan beschrijven, begrijpt die doorgaans ook beter dan een team dat daartoe niet in staat is. Het Europese beoordelingskader beloont helderheid over wat software technisch gezien daadwerkelijk doet. Daarmee keren we terug naar de vraag waarmee dit artikel begon. De oprichter die zegt: “We moeten onze AI beschermen,” stelt eigenlijk de verkeerde vraag. De wedervraag van de octrooigemachtigde – “Welk onderdeel?” – vormt het begin van de juiste.
Begin met het in kaart brengen van het systeem
In de praktijk begint dit werk al ruim voordat een octrooiaanvraag wordt ingediend. De meest waardevolle eerste stap is het systeem laag voor laag in kaart te brengen en voor iedere component vast te stellen waar de werkelijke waarde ligt en welke vorm van bescherming daarbij het meest geschikt is. Wat werkelijk nieuw is, een technisch karakter heeft en zichtbaar wordt zodra een concurrent het product onderzoekt, komt in aanmerking voor octrooibescherming. Wat verborgen kan blijven en moeilijk via reverse engineering kan worden achterhaald, leent zich voor bescherming als bedrijfsgeheim. Broncode, documentatie en gebruikersinterfaces worden beschermd door het auteursrecht. Het merk valt onder het merkenrecht.
Juist het vroegtijdig maken van deze keuzes – en niet pas na een productlancering of een investeringsronde – maakt het verschil, omdat beslissingen over openbaarmaking zich moeilijk laten terugdraaien. Een methode die geheim is gebleven, kan later nog steeds voor octrooibescherming in aanmerking komen. Een methode die eenmaal openbaar is gemaakt, bijvoorbeeld in een wetenschappelijke publicatie, een demonstratie of zelfs een eigen octrooiaanvraag, kan daarentegen in de regel niet meer als bedrijfsgeheim worden beschermd.
Daarom geldt als uitgangspunt dat alles wat geheim kan blijven, ook bewust geheim moet worden gehouden. Het onderdeel dat werkelijk nieuw is, een technisch karakter heeft en zichtbaar wordt zodra een concurrent het product analyseert, is precies het onderdeel waarvoor het octrooirecht is bedoeld. Dat onderdeel tijdig identificeren – voordat de beschikbare opties kleiner worden – vormt het begin van een doordachte IE-strategie.
Mohammad Ahmadi Bidakhvidi heeft dit onderwerp onlangs uitvoerig behandeld in een presentatie in Leuven, waarin hij de gelaagde aanpak voor de beveiliging van AI-systemen en de praktische aspecten van het octrooieren van softwaregerelateerde uitvindingen in Europa heeft toegelicht. De bijbehorende slides kunnen hier worden gedownload.
