Wie bezit de code? Licenties, leverancierslock-in en exit-strategie bij AI-bouwers

Wie de code van een AI-gebouwde website of applicatie bezit, hangt af van de platformvoorwaarden, je overeenkomst met het bureau en de rechten op onderdelen van derden. Toegang tot de broncode betekent niet automatisch dat je alle auteursrechten bezit of zonder extra werk kunt overstappen. Maak daarom onderscheid tussen drie vragen: welke rechten krijg je, welke licenties gelden en kan een andere partij het systeem daadwerkelijk overnemen?

Voor Nederlandse MKB-ondernemers is dat geen theoretische discussie. Je wilt je klantportaal, website of interne tool kunnen blijven gebruiken als een leverancier prijzen wijzigt, een dienst stopt of de samenwerking eindigt. In dit artikel lees je hoe je code-eigendom bij vibe coding beoordeelt, welke documenten je nodig hebt en hoe je een uitvoerbare exit-strategie opstelt. Dit is algemene informatie, geen juridisch advies. Laat belangrijke contracten en twijfel over rechten beoordelen door een deskundige.

Code-eigendom in het kort: drie verschillende controles

Vraag	Wat moet je controleren?	Wat is géén voldoende bewijs?
Welke rechten krijg ik?	Platformvoorwaarden, ontwikkelovereenkomst, gebruikslicentie en eventuele auteursrechtoverdracht	Een factuur met alleen ‘website bouwen’
Welke rechten hebben anderen?	Licenties van libraries, templates, afbeeldingen, fonts en overgenomen code	De algemene belofte ‘AI heeft dit gemaakt’
Kan ik overstappen?	Werkende code-export, data-export, accounts, documentatie en een geslaagde hersteltest	Een ZIP-bestand of repository zonder productieconfiguratie

De praktische definitie van een goede exit-strategie: een andere partij kan de applicatie met de afgesproken rechten, benodigde gegevens en overdraagbare diensten herstellen en beheren, binnen vooraf afgesproken grenzen voor tijd en kosten.

Wat betekent ‘jij bezit de code’ bij een AI-bouwer?

Een leverancier kan in zijn voorwaarden vastleggen dat de gemaakte output tussen jou en die leverancier aan jou toekomt. Dat is nuttig, maar het is geen allesomvattende juridische garantie. Een applicatie bestaat meestal uit eigen projectcode, opensourcebibliotheken, platformdiensten en materiaal van derden. Die onderdelen vallen niet automatisch allemaal onder hetzelfde eigendomsregime.

1. Contractuele rechten op de output

Lees wat de leverancier precies toekent: gebruik, aanpassing, commerciële exploitatie, overdracht of rechten op output tussen de contractspartijen. Controleer ook uitzonderingen, toepasselijke abonnementsvoorwaarden en eventuele afwijkende zakelijke afspraken. Als een bureau jouw app bouwt, moeten de afspraken bovendien aansluiten op het contract tussen jou en dat bureau.

2. Auteursrecht op de concrete code

De Europese softwarerichtlijn koppelt bescherming aan oorspronkelijkheid: de eigen intellectuele schepping van de auteur. Een belofte in platformvoorwaarden maakt niet vanzelf auteursrecht dat volgens de wet niet bestaat. Bij AI-ondersteund werk kunnen menselijke ontwerpkeuzes en eigen bewerkingen relevant zijn, maar de bescherming van een concreet resultaat vraagt een beoordeling van dat werk. Schrijf dus niet automatisch alle AI-code af als onbeschermd, en ga ook niet uit van gegarandeerde exclusiviteit.

3. Gebruiksrechten op onderdelen van derden

Een ontwikkelaar kan jou niet méér rechten geven op een opensourcepakket, stockfoto of commercieel component dan de betreffende licentie toestaat. Vraag een overzicht dat eigen projectwerk onderscheidt van bestaande bureaucode en onderdelen van derden. Ook een traditionele maatwerkapp kan deze afhankelijkheden bevatten.

Een praktisch voorbeeld: wat zegt Lovable over code-eigendom?

De geraadpleegde Lovable-voorwaarden delen klantdata, gebouwde projecten en AI-output tussen Lovable en de klant aan de klant toe, met voorbehoud van rechten van derden. Lovable behoudt rechten op zijn eigen dienst en platformmateriaal. De voorwaarden bevatten ook uitsluitingen van garanties, waaronder rond niet-inbreuk, voor zover wettelijk toegestaan. ‘De output is van jou’ betekent dus niet ‘alle code is gegarandeerd exclusief en vrij van rechten van anderen’.

Via de GitHub-integratie kun je projectcode exporteren en synchroniseren, lokaal verder werken en buiten Lovable uitrollen. Bewaar de repository bij voorkeur in een account of organisatie waar jouw bedrijf zeggenschap over heeft. Een gedeelde uitnodiging voor het account van een bureau is iets anders dan zelfstandig accountbeheer.

De documentatie over zelfstandig hosten maakt een belangrijke grens duidelijk: de applicatie kan elders draaien, maar de Lovable-editor en AI-agent zijn een beheerde dienst die je niet zelf meeverhuist. Een database verplaatsen neemt bovendien niet automatisch authenticatie, bestandsopslag en alle andere diensten mee. Welke onderdelen je opnieuw moet inrichten, hangt af van jouw project.

Deze informatie is gecontroleerd voor dit artikel op 9 november 2026. Beoordeel altijd de overeenkomst en documentatie die voor jouw project gelden; voorwaarden en productmogelijkheden kunnen wijzigen.

Laat auteursrecht en gebruiksrechten expliciet vastleggen

Bij ontwikkeling door een extern bureau is alleen betalen niet zonder meer bewijs van auteursrechtoverdracht. De Nederlandse Auteurswet vereist een daartoe bestemde akte voor overdracht. De overeenkomst tot overdracht of verlening van een exclusieve licentie wordt schriftelijk aangegaan. Een gebruikslicentie en eigendomsoverdracht zijn verschillende afspraken; laat beoordelen wat jij werkelijk nodig hebt en hoe dit correct wordt vastgelegd.

• Nieuw projectwerk: beschrijf welke rechten worden overgedragen of gelicentieerd en wanneer dat gebeurt.
• Bestaande bureaucode: leg vast of je die mag blijven gebruiken, wijzigen en door een andere partij laten onderhouden.
• Derdenmateriaal: vraag een lijst van licenties en beperkingen; sluit dit niet stilzwijgend in bij een algemene eigendomsbelofte.
• Beheer na vertrek: regel toegang tot documentatie en de mogelijkheid om een nieuwe beheerder in te schakelen.
• Onderhoud en aansprakelijkheid: spreek afzonderlijk af wie updates, incidenten en rechtenclaims behandelt.

Een exclusieve licentie is niet altijd nodig om een bedrijfsapplicatie goed te kunnen gebruiken. Soms is een ruime, passende gebruikslicentie voldoende. Het gaat om je bedrijfsdoel en risico, niet om de grootste belofte in de offerte. De MKB-scorekaart voor het kiezen van een bureau helpt de overdracht al tijdens selectie bespreekbaar te maken.

Welke licenties moet je controleren bij AI-gegenereerde code?

AI genereert niet noodzakelijk een volledig losstaande oplossing. De app kan bestaande packages gebruiken of code bevatten die op publieke voorbeelden lijkt. Vraag daarom minimaal een inventarisatie met componentnaam, versie, herkomst, licentie en toepasselijke verplichtingen. Een dependency-overzicht of software bill of materials kan hierbij helpen, maar vervangt de beoordeling van de licentieteksten niet.

Onderdeel	Controle	Praktische consequentie
Opensourcebibliotheken	Exacte licentie, versie en manier van gebruik of distributie	Bijvoorbeeld kennisgevingen behouden; andere verplichtingen kunnen gelden afhankelijk van de licentie
Commerciële componenten en templates	Geldigheid voor jouw bedrijf, project, gebruik en eventuele overdracht	Mogelijk een eigen licentie of verlenging nodig
Afbeeldingen, fonts en iconen	Toegestaan webgebruik, herkomst en hergebruik bij migratie	Niet iedere bundellicentie verhuist mee naar een nieuwe omgeving
Gekopieerde of overeenkomende code	Bron, licentie en toestemming voor de gekozen toepassing	Onbekende herkomst eerst onderzoeken of het onderdeel vervangen
Externe API's en AI-diensten	Contract, accountbeheer, gebruiksvoorwaarden en gegevensverwerking	Code-export verhuist het servicecontract en de toegang niet automatisch

Open source betekent niet ‘zonder voorwaarden’. Copyleftlicenties kunnen aanvullende verplichtingen hebben; wanneer die gelden, hangt onder meer af van de concrete licentie en hoe je software gebruikt, combineert en verspreidt. Laat twijfel beoordelen in plaats van alle opensourceonderdelen toe te staan of juist te verbieden.

GitHub Copilot kan verwijzingen naar overeenkomende publieke code tonen, inclusief een gevonden licentie. Een onbekende licentie of ‘NOASSERTION’ betekent niet dat code rechtenvrij is. Andersom bewijst het ontbreken van een melding niet dat alle rechten geregeld zijn. Behandel zulke meldingen als hulpmiddel bij controle, niet als volledige vrijwaring.

Leverancierslock-in zit vaak buiten de code

Leverancierslock-in ontstaat wanneer overstappen technisch, contractueel of financieel moeilijk is. Dat kan ook met volledig toegankelijke broncode. Een repository zonder data, accounts en werkende koppelingen levert nog geen bruikbaar klantportaal op.

• Code: platformspecifieke functies of ontbrekende bouwinstructies kunnen vervangend werk vereisen.
• Data: je hebt niet alleen tabellen nodig, maar ook bestanden, relaties en een bruikbaar exportformaat.
• Authenticatie: onderzoek of en hoe gebruikersaccounts kunnen worden overgezet; soms is een nieuwe aanmeld- of resetprocedure nodig.
• Diensten: mail, betalingen, AI, opslag en geplande taken vragen eigen configuratie en toegang.
• Accounts: domein, DNS, hosting en repository moeten onder aantoonbare zeggenschap van je bedrijf vallen.
• Kennis: ongedocumenteerde bedrijfsregels maken ook een traditioneel bureau moeilijk vervangbaar.

Voor bestaande websites hoort daar ook behoud van URL's, redirects en zoekresultaatteksten bij. Lees het migratieplan voor een bestaande MKB-site en onze dienst WordPress naar Lovable als je een website wilt overzetten zonder onnodige SEO-verliezen.

Exit-strategie voor AI-bouwers: een stappenplan in zeven stappen

1. Leg het overdrachtsdoel vast. Beschrijf wat een opvolger moet kunnen: beheren, doorontwikkelen, elders hosten en gegevens herstellen. Spreek vooraf een acceptabel herstelvenster en budget af.
2. Controleer rechten en licenties. Verzamel toepasselijke voorwaarden, bureauafspraken, overdrachtsdocumenten en een overzicht van derdenonderdelen. Bewaar een gedateerde versie.
3. Organiseer bedrijfsaccounts. Leg eigenaren, beheerders en herstelmogelijkheden vast voor repository, domein, hosting en kritieke diensten. Verleen anderen alleen noodzakelijke toegang.
4. Maak een compleet overdrachtspakket. Voeg bouwinstructies, databasebeschrijving, koppelingen, operationele taken en een lijst benodigde configuratievariabelen toe. Bewaar geheime sleutels apart en draag ze veilig over; zet ze niet in de repository.
5. Test gegevensherstel. Herstel code, database en bestanden in een afgeschermde testomgeving. Gebruik waar mogelijk testgegevens; noodzakelijke klantdata vraagt passende toegang en beveiliging.
6. Laat een andere partij de app draaien. Test inloggen, rechten, formulieren, uploads en kritieke integraties buiten de oorspronkelijke bouwomgeving. Leg ontbrekende onderdelen en vervangingswerk vast.
7. Regel de daadwerkelijke overdracht. Plan omschakeling, controles, terugvalmogelijkheid, overdrachtsondersteuning en veilige intrekking van oude toegang. Vernieuw sleutels waar nodig en herhaal de exit-test na grote wijzigingen.

Gebruik de acceptatiechecklist voor websites en webapplicaties om overdracht niet pas na oplevering te bespreken. De overgang van prototype naar productie is het moment om beheer en exit aantoonbaar te regelen.

Fictief MKB-voorbeeld: een installatiebedrijf met een klantportaal

Dit voorbeeld is verzonnen en beschrijft geen klantcase. Een installatiebedrijf laat met een AI-bouwer een portaal maken waarin klanten onderhoud aanvragen en foto's uploaden. In de offerte staat dat het bedrijf de code krijgt. Na een jaar wil het een ander bureau inschakelen.

De repository blijkt beschikbaar, maar de uploadbestanden staan in een apart opslagaccount, e-mail loopt via het bureau en niemand heeft het herstel van gebruikersaccounts getest. De code kan worden gebouwd, maar het portaal werkt daardoor nog niet volledig. Het eigendomsstatement heeft de operationele afhankelijkheid niet opgelost.

Het bedrijf vraagt vervolgens een accountoverzicht, een licentielijst en een hersteltest. Een nieuwe beheerder draait een testversie, controleert klantrechten en herstelt voorbeeldbestanden. Daarna worden e-mail en overige koppelingen ingericht onder bedrijfsbeheer. Pas wanneer deze controles slagen, wordt de omschakeling gepland. De les: beoordeel exitbaarheid aan de hand van een werkende overdracht, niet alleen aan de hand van een codebestand.

Zes vragen die je vóór de opdracht stelt

• Welke rechten krijgen wij op nieuw werk en welke onderdelen blijven van jullie of van derden?
• Mag een ander bureau de volledige oplossing onderhouden, aanpassen en elders hosten?
• Welke code, data en instellingen zijn exporteerbaar, en wat blijft buiten de export?
• Wie beheert de accounts en hoe krijgen wij zelfstandig toegang bij beëindiging?
• Welke ondersteuning en kosten horen bij vertrek, en binnen welke termijn leveren jullie de overdracht?
• Kunnen jullie vóór oplevering een hersteltest door een andere beheerder laten uitvoeren?

Neem de antwoorden op in de overeenkomst en opleveringscriteria. Vergelijk ook de totale kosten, inclusief migratie en beheer, zoals uitgewerkt in vibe coding versus traditioneel ontwikkelen.

Wat betekent dit voor SEO en GEO?

Voor een website is een geslaagde code-export niet het einde van de migratie. Controleer dat content, bestaande URL's, canonicals, interne links en structured data behouden blijven. Anders kan een overstap de vindbaarheid schaden, ook al zijn de rechten correct geregeld. Voor GEO helpt het om dezelfde bedrijfsgegevens en duidelijke, controleerbare informatie beschikbaar te houden; een verhuizing garandeert geen vermelding in AI-antwoorden.

Onze rol als AI marketing bureau is om bouw, overdracht en vindbaarheid samen te beoordelen. Wil je een website bouwen met AI? Maak rechten, beheer en vertrekbaarheid dan onderdeel van de opdracht, niet van een discussie achteraf.

Veelgestelde vragen over code-eigendom bij AI-bouwers

Ben ik automatisch eigenaar van code die AI voor mij maakt?

Nee. De contractuele rechten hangen af van de voorwaarden en jouw afspraken. Daarnaast moet je afzonderlijk beoordelen welke auteursrechten bestaan en welke rechten van derden gelden. Een outputbelofte regelt die vragen niet allemaal tegelijk.

Kan ik een Lovable-applicatie buiten Lovable hosten?

Volgens de geraadpleegde documentatie kun je de applicatiecode exporteren en elders hosten. De Lovable-editor en AI-agent zelf verhuizen niet mee. Data, authenticatie, opslag en andere diensten kunnen afzonderlijke migratiestappen vereisen.

Is een GitHub-repository voldoende om leverancierslock-in te voorkomen?

Nee. Een repository helpt bij toegang tot code, maar je hebt ook gegevens, documentatie, bedrijfsaccounts en werkende koppelingen nodig. Laat een andere beheerder een hersteltest uitvoeren om de daadwerkelijke overdraagbaarheid te beoordelen.

Krijg ik alle auteursrechten als ik een bureau betaal?

Betaling is niet zonder meer bewijs van auteursrechtoverdracht. Nederlands auteursrecht vereist een daartoe bestemde akte voor overdracht. Een gebruikslicentie kan een andere passende oplossing zijn; laat de afspraken juridisch beoordelen.

Mag AI-gegenereerde code opensourceonderdelen bevatten?

Dat kan, mits het gebruik voldoet aan de toepasselijke licenties. Controleer herkomst, versies, kennisgevingen en eventuele verdere verplichtingen. Open source betekent niet dat code zonder voorwaarden kan worden gebruikt.

Wat moet er minimaal in mijn exit-plan staan?

Leg rechten, exports, accountbeheer, benodigde diensten, veilige overdracht van toegang, ondersteuning en omschakelafspraken vast. Voeg een geslaagde hersteltest toe en spreek vooraf grenzen voor tijd en kosten af.

Is een AI-gebouwde applicatie moeilijker overdraagbaar dan maatwerk?

Niet noodzakelijk. Overdraagbaarheid hangt af van architectuur, platformafhankelijkheden, licenties, accounts en documentatie. Ook traditioneel maatwerk kan veel lock-in bevatten. Vergelijk oplossingen met dezelfde concrete overdrachtscriteria.

Bronnen en verantwoording

Geraadpleegd op 9 november 2026. Platformdocumentatie beschrijft mogelijkheden en voorwaarden, geen garantie voor jouw concrete project. De auteursrechtelijke beoordeling hangt af van de feiten en de toepasselijke overeenkomst.

• Lovable Terms — rechten op klantdata, output, platformmateriaal en voorbehouden.
• Lovable Docs — GitHub-export en synchronisatie.
• Lovable Docs — zelfstandig hosten en migratie van diensten.
• GitHub Docs — publieke-codematches en licentieverwijzingen.
• Richtlijn 2009/24/EG — bescherming van computerprogramma's, artikelen 1 en 2.
• Auteurswet — artikel 2 over overdracht en licenties. De formulering is tevens gecontroleerd via de weergave van artikel 2 op Concordans.