Commercieel gebruik van open modellen: gebruiksrechten en verplichtingen
Wanneer organisaties besluiten om artificial intelligence in te zetten binnen hun interne bedrijfsvoering of in commerciële producten, valt de keuze steeds vaker op open toegankelijke modellen. Het idee dat een model vrij te downloaden is van een platform en lokaal kan worden uitgevoerd, wekt snel de indruk dat er geen juridische of operationele beperkingen aan het gebruik kleven. In de praktijk blijkt de term 'open' in de wereld van kunstmatige intelligentie echter een aanzienlijk breder en complexer spectrum te beslaan dan bij traditionele openbronsoftware het geval is.
Het downloaden van de gewichten van een taalmodel geeft een organisatie het technische vermogen om het model uit te voeren, maar dit staat los van de juridische toestemming om dat model voor elk denkbaar doel in te zetten. De voorwaarden waaronder deze artefacten beschikbaar worden gesteld, variëren sterk per maker en per uitgave. Het is daarom essentieel om een helder beeld te hebben van de juridische gelaagdheid van AI-modellen, de verschillende typen gebruiksbeperkingen die in de markt voorkomen en de verplichtingen die op organisaties rusten zodra zij deze technologie commercieel gaan toepassen. Wie op zoek is naar geschikte modellen binnen een catalogus zoals de overzichten van open modellen, doet er goed aan vooraf te begrijpen welke juridische haken en ogen er aan distributiebestanden kunnen zitten.
Waarom 'open' bij AI niet hetzelfde betekent als bij software
In de traditionele softwareontwikkeling is het begrip 'open source' strak gedefinieerd. Broncode die onder een erkende licentie wordt vrijgegeven, verleent de gebruiker vier fundamentele vrijheden: het recht om de software voor elk doel uit te voeren, de werking ervan te bestuderen en aan te passen, kopieën te delen en aangepaste versies te verspreiden. Bij kunstmatige intelligentie, en met name bij grote taalmodellen, is de situatie anders. Een AI-model bestaat niet uit klassieke broncode die regel voor regel door een mens is geschreven, maar uit een verzameling van miljarden numerieke waarden (gewichten en parameters) die het resultaat zijn van een intensief trainingsproces.
Wanneer een ontwikkelaar of organisatie modelgewichten publiceert, spreekt men in de praktijk vaak over 'open gewichten' (open weights). Dit betekent enkel dat de binaire bestanden waarmee het model redeneert of teksten genereert vrij toegankelijk zijn. De voorwaarden waaronder je deze gewichten mag gebruiken, opslaan, aanpassen of commercieel mag exploiteren, worden bepaald door de bijbehorende overeenkomst of licentietekst. Veel makers voegen specifieke clausules toe die het gebruik beperken tot bepaalde toepassingsgebieden of bepaalde organisatiegrootten. Hierdoor kan een model technisch open en vrij downloadbaar zijn, maar juridisch gezien streng afgebakend voor commerciële doeleinden.
Daarnaast vereist het uitvoeren van een model meer dan alleen de gewichten. Het vereist ondersteunende software, zoals tokenizers, inferentie-pijplijnen en specifieke software-architecturen. Het feit dat de code van de inferentie-engine onder een vrije licentie valt, betekent niet automatisch dat dezelfde vrijheden gelden voor de gewichten die in het geheugen van de grafische kaart worden geladen. Het scheiden van de technische beschikbaarheid en de juridische rechten is de eerste cruciale stap bij een zorgvuldige beoordeling van AI-toepassingen.
De vier juridische lagen van een AI-systeem
Om te bepalen wat er commercieel wel en niet is toegestaan, moet een organisatie een AI-systeem niet als één enkel product beschouwen, maar als een stapel van vier afzonderlijke lagen. Elke laag kan onder een eigen regime van voorwaarden en intellectuele eigendomsrechten vallen. Het is heel gebruikelijk dat deze vier lagen zelden onder exact dezelfde voorwaarden vallen, waardoor een afzonderlijke controle per laag noodzakelijk is.
| Laag van het AI-systeem | Typische inhoud | Aandachtspunt bij licentiëring |
|---|---|---|
| 1. Modelgewichten | Miljarden parameters in binaire bestanden | Gebruiksbeperkingen, drempelwaarden voor omzet of gebruikers |
| 2. Ondersteunende code | Tokenizers, inferentie-scripts, training-pijplijnen | Vaak traditionele softwarelicenties (zoals Apache 2.0 of MIT) |
| 3. Trainingsdata | Tekstcorpora, datasets, geannoteerde bronnen | Auteursrecht van derden, herkomst, databankrechten |
| 4. Modeluitvoer | Gegenereerde teksten, code, uitkomsten | Beperkingen op het trainen van concurrerende modellen |
De eerste laag bestaat uit de modelgewichten zelf. Dit zijn de rekenkundige uitkomsten van het trainingsproces. De voorwaarden op deze laag bepalen wie de gewichten mag laden, op welke hardware dat mag gebeuren en of er commerciële diensten rond het model gebouwd mogen worden.
De tweede laag betreft de software om het model heen. Denk aan de broncode van de inferentie-engine, de scripts om gegevens te pre-processen en de integratiecode met databases. Deze code wordt regelmatig onder permissive softwarelicenties gepubliceerd. Het is dus mogelijk dat de code waarmee je het model aanroept volledig vrij is, terwijl de gewichten die door de code worden ingeladen beperkende voorwaarden hebben.
De derde laag is de trainingsdata waarmee het model is opgebouwd. Dit is in de praktijk de meest complexe laag, omdat de rechten op de ruwe data zelden volledig bij de maker van het model liggen. Een modelmaker kan de gewichten vrijgeven onder soepele voorwaarden, maar als het model is getraind op auteursrechtelijk beschermd materiaal zonder licentie, blijft er een reëel herkomstrisico bestaan voor de uiteindelijke gebruiker.
De vierde laag betreft de uitvoer (output) die het model genereert voor de eindgebruiker. Sommige voorwaarden stellen regels aan wat er met deze uitvoer gedaan mag worden. Voor een diepere analyse van de wettelijke aspecten rond gegenereerde content kun je het overzicht raadplegen over intellectueel eigendom en auteursrecht bij AI. Om de volledige documentatie rond een specifiek model goed te ontleden, is het daarnaast raadzaam om de richtlijnen te volgen voor het lezen van modelkaarten en licenties.
Typen voorwaarden in de praktijk
In het huidige landschap van open toegankelijke AI-modellen zijn de gebruiksrechten in te delen in vier hoofdcategorieën. Elke categorie heeft specifieke consequenties voor de commerciële haalbaarheid van een project.
1. Echt vrije voorwaarden
Bij dit type voorwaarden krijgt de gebruiker vrijwel onbeperkte vrijheid. Je mag de gewichten gebruiken voor commerciële toepassingen, het model aanpassen, integreren in eigen producten en de dienst aanbieden aan derden zonder dat daar financiële compensatie of gebruiksbeperkingen tegenover staan. De enige verplichting is doorgaans het behoud van de oorspronkelijke auteursrechtopmerking en een afwijzing van aansprakelijkheid.
2. Voorwaarden met een gebruiksbeperking (Acceptable Use Policies)
Veel populaire open modellen vallen onder voorwaarden die commercieel gebruik toestaan, mits het model niet wordt ingezet voor specifieke toepassingen. Typische uitsluitingen hebben betrekking op medische advisering zonder menselijke tussenkomst, het genereren van desinformatie, geautomatiseerde rechtspraak, wetshandhaving, of het beoordelen van de kredietwaardigheid van personen. Zodra je toepassing binnen een van deze geselecteerde domeinen valt, vervalt de toestemming om het model te gebruiken.
3. Voorwaarden met een drempelwaarde
Sommige ontwikkelaars hanteren voorwaarden die commercieel gebruik gratis toestaan tot een bepaalde grens. Deze grens wordt vaak uitgedrukt in een maximaal aantal maandelijks actieve gebruikers van het product waarin het model is verwerkt, of een maximale jaarlijkse omzet van de organisatie die het model inzet. Zodra jouw organisatie of product deze drempel overschrijdt, verplicht de overeenkomst je om contact op te nemen met de maker om een afzonderlijke, commerciële licentieovereenkomst af te sluiten.
4. Uitsluitend onderzoek en niet-commercieel gebruik
Een aanzienlijk deel van de beschikbare modellen wordt vrijgegeven met een expliciet verbod op commerciële exploitatie. Deze modellen zijn uitsluitend bedoeld voor academisch onderzoek, educatieve doeleinden of persoonlijke experimenten. Het inzetten van een dergelijk model in een interne bedrijfspijplijn die de commerciële omzet ondersteunt, vormt een rechtstreekse schending van de voorwaarden.
Let op: Een model dat restricties bevat op het gebied van gebruiksdoelen of bedrijfsgrootte voldoet volgens officiële maatstaven niet aan de definitie van 'Open Source'. Het hanteren van gebruiksbeperkingen sluit immers het principe van gelijke toegang zonder discriminatie van werkterreinen uit. Meer achtergrond over deze juridische en categorische discussie vind je in het artikel over het licentiedebat rond open modellen.
Naamsvermelding, afgeleide modellen en het trainen van concurrenten
Naast de vraag óf een model commercieel gebruikt mag worden, stellen voorwaarden vaak concrete eisen aan de wijze waarop het model wordt ingezet en doorontwikkeld. Deze verplichtingen worden in de praktijk regelmatig over het hoofd gezien, wat bij een audit of overname tot complicaties kan leiden.
Een veelvoorkomende eis is de verplichting tot naamsvermelding (attribution) en het doorgeven van voorwaarden. Als je een open model integreert in een softwareproduct dat je aan klanten levert, ben je vaak verplicht om in de documentatie of gebruikersinterface te vermelden op welk basismodel de dienst is gebouwd. Daarnaast eisen veel voorwaarden dat als je het model herverdeelt, je de oorspronkelijke licentietekst en gebruiksbeperkingen doorgeeft aan jouw afnemers. Je kunt jouw klanten dus niet meer rechten verlenen dan je zelf van de oorspronkelijke maker hebt ontvangen.
Wat gebeurt er bij afgeleide modellen?
In de praktijk worden open modellen zelden exact in hun originele vorm gebruikt. Organisaties voeren vaak fijnafstemming (fine-tuning) uit, trainen aanvullende adapters (zoals LoRA's) of passen kwantisatie toe om het model sneller te laten draaien. Het is een misvatting dat het trainen van een eigen laag op een bestaand model het onderliggende model juridisch 'wist'.
De algemene regel is dat afgeleide modellen (derivative works) gebonden blijven aan de voorwaarden van het oorspronkelijke basismodel. Als het basismodel gebruiksbeperkingen kent of een drempelwaarde hanteert, gelden die beperkingen onverkort voor het door jou gefijnafstemde model en de losse adapter-bestanden. Je kunt een beperkende licentie van een basismodel niet omzeilen door er een kleine hoeveelheid eigen data aan toe te voegen.
Het verbod op het trainen van concurrerende modellen
Een specifieke clausule die in veel moderne modelvoorwaarden is opgenomen, betreft het gebruik van de uitvoer (output) om andere AI-modellen te trainen. Grote modelmakers willen voorkomen dat een concurrent of een commerciële afnemer hun model gebruikt als een goedkope 'docent' om via synthese van data een kleiner, eigen model te trainen (distillatie).
Als een licentie expliciet verbiedt om generaties te gebruiken voor het trainen, verbeteren of valideren van concurrerende modellen, heeft dit directe gevolgen voor je data-architectuur. Je mag de antwoorden die het model genereert in dat geval niet opslaan in een database om die vervolgens te gebruiken als trainingsdataset voor een intern, kleiner model. Dit verbod geldt vaak ongeacht of de uiteindelijke toepassing intern of extern is.
Vastlegging, tussenpartijen en het herkomstrisico
Het op een verantwoorde manier inzetten van open modellen binnen een organisatie vereist een gedegen administratieve en technische aanpak. Het enkel downloaden van een bestand is onvoldoende om compliancy op de lange termijn te borgen.
Wat moet je intern vastleggen?
Modelvoorwaarden zijn niet statisch. Aanbieders passen hun voorwaarden soms aan bij nieuwe release-versies. Om bij een controle aan te tonen dat jouw organisatie rechtmatig handelt, dient er voor elk gebruikt model een vast dossier te worden bijgehouden. Dit dossier moet minimaal de volgende elementen bevatten:
- De exacte variant en versienummer van het model (inclusief de specifieke commit-hash van de repository).
- De exacte datum en het tijdstip waarop de modelbestanden zijn gedownload.
- Een lokale kopie van de licentietekst en de voorwaarden zoals deze op het moment van downloaden van kracht waren.
- Een documentatie van de beoogde toepassing, waarin wordt aangetoond dat het gebruik niet valt onder de uitgesloten domeinen.
De rol van tussenpartijen en beheerde hosting
Veel organisaties kiezen ervoor om een open model niet zelf op eigen GPU-hardware te draaien, maar het model af te nemen via een tussenpartij, zoals een cloudprovider of een gespecialiseerd hostingplatform. Het is een veelvoorkomende denkfout dat de tussenpartij daarmee het juridische risico en de voorwaarden overneemt.
Een hostingprovider biedt uitsluitend de infrastructurele faciliteit om het model uit te voeren. Als gebruiker van de API blijf je in de meeste gevallen rechtstreeks gebonden aan de gebruiksrechten van het onderliggende model. Bij het afsluiten van overeenkomsten met tussenpartijen moet je helder krijgen wie de licentievoorwaarden garandeert, of er sprake is van vrijwaring bij inbreuk en hoe de verwerking van gegevens is geregeld. Zie voor contractuele afspraken rondom dienstverlening en garanties ook het overzicht over AI-contracten en SLA's.
Herkomst als het onderliggende risico
Het meest fundamentele risico bij open modellen heeft betrekking op de herkomst (provenance) van de trainingsdata. Een modelmaker kan de gewichten beschikbaar stellen onder een uiterst royale en permissive licentie, maar dat geeft geen enkele garantie over de wettelijke status van het materiaal waarop het model is getraind.
Als een model is getraind op auteursrechtelijk beschermde boeken, artikelen of code repositories zonder dat daarvoor toestemming is verleend, kan een rechthebbende stellen dat het eindproduct of de werking ervan inbreuk maakt op intellectueel eigendom. Een vriendelijke licentie van een modelmaker geeft jou als eindgebruiker geen vrijwaring tegen aanspraken van derden wier data zonder licentie is gebruikt. Voor organisaties met een strikt risicoprofiel is het achterhalen van de datatherkomst daarom een doorslaggevend onderdeel van de leveranciersbeoordeling.
Praktische volgorde voor geschiktheidsanalyse
Om te voorkomen dat een ontwikkelteam weken investeert in het testen van een model dat later op juridische bezwaren stuit, is het raadzaam een vaste Volgorde van Analyse te hanteren. Technische geschiktheid dient pas als laatste stap te worden getoetst.
- Stap 1: Gebruiksbeperkingen toetsen. Controleer of de beoogde toepassing (bijvoorbeeld financiële advisering, personeelsselectie of klantenservice) valt onder een van de expliciet verboden categorieën in de voorwaarden van het model.
- Stap 2: Organisatorische voorwaarden controleren. Ga na of jouw organisatie valt onder een drempelwaarde voor omzet of gebruikersaantallen, en of de vereiste naamsvermelding in te passen is in de productinterface.
- Stap 3: Financiële en kostenstructuur evalueren. Indien het model bij het overschrijden van drempels licentiekosten vereist, of als de eigen hosting hoge infrastructuurkosten met zich meebrengt, moet dit worden gewogen. Zie hiervoor de analyse over de total cost of ownership van open versus gesloten modellen voor een realistisch beeld van het kostenplaatje.
- Stap 4: Technische evaluatie en benchmarking. Pas wanneer vaststaat dat het model juridisch en operationeel mag en kan worden ingezet, start de evaluatie van de nauwkeurigheid, snelheid en technische geschiktheid voor de taak.
Door deze systematische aanpak te hanteren, voorkomen organisaties dat zij afhankelijk worden van modellen die bij opbrengstschaling of audits onverwachte juridische en financiële belemmeringen opleveren.
