Juridisch

Wat spreek je af in een contract met een AI-bouwer?

Eigendom, doorlopende kosten, acceptatie en exit: de afspraken die je vóór de bouw vastlegt met een AI-freelancer of -bureau, met tabel en praktijkvoorbeeld.

aiworktalent Redactie · 26 juli 2026 · 10 min leestijd

Je hebt een freelancer of bureau gevonden die een AI-workflow, chatbot of automatisering voor je gaat bouwen. Voordat er één regel code of één workflow-stap wordt aangemaakt, is er een gesprek dat minstens zo belangrijk is als de techniek zelf: wat spreken jullie precies af? Bij gewone software zijn een paar dingen inmiddels vanzelfsprekend. Bij AI-opdrachten gaan bedrijven daar regelmatig op stuk, juist omdat niemand het heeft benoemd: van wie is de workflow eigenlijk, op wiens rekening draait het model, en wanneer is het resultaat goed genoeg als hetzelfde model twee keer een net iets ander antwoord geeft? Dit artikel loopt de afspraken langs die je vóór de start op papier zet.

Waarom een AI-opdracht andere afspraken vraagt

Bij een traditionele maatwerkapplicatie is het beeld meestal simpel: er komt een codebase, die staat in een repository, en bij oplevering krijg jij daar toegang toe. Bij een AI-opdracht is dat beeld vaker versnipperd. Een deel van wat er "gebouwd" wordt, leeft in een account bij een externe partij, zoals een taalmodel-API of een automatiseringsplatform. Er is een doorlopende, variabele kostenpost in plaats van een eenmalige rekening. En het resultaat is een systeem dat met dezelfde invoer niet gegarandeerd exact hetzelfde antwoord geeft, waardoor "het werkt" geen vaste toestand is maar een kwestie van meten. Die drie verschillen zijn de reden dat een aantal afspraken die bij gewone software vanzelf goed komen, bij een AI-opdracht expliciet gemaakt moeten worden.

Eigendom en gebruiksrecht: van wie zijn de workflow, de prompts en de data

De meest fundamentele misvatting bij opdrachtgevers is dat auteursrecht op maatwerk automatisch naar hen overgaat omdat zij ervoor betalen. Dat is niet zo. De Auteurswet bepaalt dat het auteursrecht toekomt aan de maker, en bij een opdracht is de maker de freelancer of het bureau, niet de opdrachtgever. Alleen bij een werknemer in dienstbetrekking geldt een uitzondering (artikel 7 Auteurswet): dan wordt de werkgever als maker aangemerkt, tenzij partijen iets anders afspreken. Bij een zelfstandige of een bureau dat je inhuurt op basis van een overeenkomst van opdracht geldt die uitzondering niet. Wil je dat de rechten naar jou overgaan, dan moet dat expliciet: artikel 2 Auteurswet eist een schriftelijke akte, waarin bovendien staat wát er precies wordt overgedragen. Een verwijzing in algemene voorwaarden is daarvoor niet voldoende; het moet aantoonbaar en concreet zijn afgesproken.

Bij een AI-opdracht is "het opgeleverde" meestal geen enkel bestand maar een stapeling van onderdelen, en voor elk daarvan is het verstandig apart te benoemen wie er straks mee mag doen wat:

• De workflow of automatisering zelf. De opgezette stappen, koppelingen en logica, bijvoorbeeld in een tool als n8n of Zapier, of in maatwerkcode.
• De prompts en instructies. De teksten die bepalen hoe het model zich gedraagt. Die zijn vaak het resultaat van veel testen en bijstellen, en dus waardevoller dan ze op het eerste gezicht lijken.
• De configuratie. Instellingen, koppelingen met je systemen, en de manier waarop alles met elkaar praat.
• De verzamelde data. Gespreksgeschiedenis, klantvragen, voorbeelden die zijn gebruikt om het systeem te testen of te verbeteren.

Leg in de opdrachtbevestiging vast dat het auteursrecht en gebruiksrecht op deze vier onderdelen bij oplevering en volledige betaling overgaan op jou, of dat je in ieder geval een exclusief gebruiksrecht krijgt om ze binnen je eigen bedrijf te gebruiken, aan te passen en te laten onderhouden door een ander. Houd er rekening mee dat een freelancer vaak generieke bouwstenen, zoals een sjabloon voor een categorie automatisering, ook bij een volgende klant wil kunnen hergebruiken. Dat is redelijk, zolang het onderscheid duidelijk is: de generieke bouwsteen is van hem, de specifiek voor jou geconfigureerde versie inclusief jouw prompts en data is van jou.

Doorlopende kosten: de meest onderschatte valkuil

Waar reguliere software na oplevering meestal op je eigen server of in je eigen abonnement draait, hangt een AI-oplossing vaak af van een account bij een derde partij: een taalmodel-API, een automatiseringsplatform, soms een aparte dienst voor spraak of beeldherkenning. De vraag die te vaak ongesteld blijft: op wiens naam staat dat account, en wie betaalt het verbruik dat maandelijks binnenkomt?

Er zijn in de praktijk drie opzetten. De freelancer bouwt op zijn eigen account en rekent het verbruik aan jou door, al dan niet met een opslag. Jij zet vanaf de start eigen accounts op, en de freelancer configureert daarbinnen. Of het is een mix, waarbij sommige onderdelen bij jou draaien en andere bij de bouwer. De eerste opzet is het snelst om mee te beginnen, maar maakt je afhankelijk van iemand anders' account voor een proces dat inmiddels misschien onmisbaar is in je bedrijfsvoering. Spreek daarom vooraf af: op wiens naam de accounts en abonnementen staan, hoe het verbruik wordt gefactureerd en met welke frequentie, en, misschien wel het belangrijkste, wat er gebeurt met de accounts, API-sleutels en toegang zodra de samenwerking eindigt. Gaan ze over naar jou, of vervallen ze, en heb je dan nog een werkend systeem?

Een voorbeeld uit de praktijk

Onderstaand voorbeeld is fictief, ter illustratie. Een mkb-groothandel laat een freelancer een automatisering bouwen die inkomende bestelmails leest, de gegevens overneemt in het orderbeheersysteem en een ontvangstbevestiging terugstuurt. De freelancer zet dit snel op, op zijn eigen account bij het taalmodel en zijn eigen abonnement op het automatiseringsplatform, en stuurt de groothandel maandelijks een factuur voor het verbruik. Na acht maanden werkt het systeem prima en verwerkt het dagelijks tientallen bestellingen. Dan besluit de freelancer te stoppen met dit type opdrachten. De groothandel blijkt geen toegang te hebben tot het platform, geen kopie van de prompts, en geen overzicht van hoe de workflow precies in elkaar zit. Het systeem blijft nog even draaien op het account van de freelancer, tot die het opzegt, en dan valt het bestelproces terug op volledig handwerk. Een nieuwe freelancer moet alles vanaf nul opnieuw uitzoeken, omdat er niets is overgedragen. Was vooraf vastgelegd op wiens account het systeem draait en wat er bij einde van de samenwerking wordt overgedragen, dan was dit een kwestie van een paar dagen overdracht geweest in plaats van een noodgedwongen herbouw.

Resultaatafspraken bij een technologie die niet altijd hetzelfde antwoord geeft

"Het moet foutloos werken" klinkt als een logische eis, maar is bij een AI-oplossing een onbruikbare afspraak. Een taalmodel geeft bij dezelfde vraag niet gegarandeerd exact hetzelfde antwoord, en ook los daarvan is "foutloos" geen meetbaar begrip: fout volgens wie, gemeten hoe, op welke gevallen? Zonder concretisering wordt de oplevering een discussie over gevoel, waarbij de opdrachtgever teleurgesteld raakt over iets dat nooit precies was afgesproken en de bouwer meent te hebben geleverd wat er gevraagd was.

Wat wél werkt, is twee dingen vooraf vastleggen. Ten eerste een afgesproken meetmethode: hoe wordt getoetst of het resultaat goed genoeg is, en door wie. Ten tweede een acceptatiecriterium op basis van een testset: een vooraf samengestelde set representatieve voorbeelden, inclusief een paar lastige of randgevallen, waarop een percentage wordt afgesproken. Bijvoorbeeld: van de vijftig testcases wordt minstens 85 procent correct afgehandeld zonder handmatige correctie. Zo'n testset stel je het liefst samen met echte, eerdere voorbeelden uit je eigen praktijk, niet met een paar makkelijke schoolvoorbeelden die de bouwer zelf aandraagt. Een systeem dat in een demo met drie zorgvuldig gekozen voorbeelden foutloos oogt, hoeft in het dagelijkse gebruik nog niet te presteren; zie waarom een AI-pilot in productie vaak alsnog vastloopt voor hoe dat verschil ontstaat.

Oplevering en overdracht: documentatie en toegang

Een AI-oplossing is pas echt opgeleverd als iemand anders dan de bouwer hem zou kunnen overnemen. Spreek daarom af wat er bij oplevering wordt meegeleverd: een beknopte beschrijving van hoe het systeem in elkaar zit en welke onderdelen met elkaar praten, een overzicht van alle gebruikte accounts, koppelingen en toegangsgegevens met heldere eigendomsafspraken erbij, en een exportbestand of kopie van de workflow zelf zodat je niet afhankelijk bent van het account van de bouwer om bij je eigen systeem te kunnen. Test dit voor jezelf met een simpele vraag: als deze freelancer morgen niet meer bereikbaar is, kan een ander dan met deze documentatie en toegang verder? Is het antwoord nee, dan ontbreekt er nog iets aan de oplevering.

Onderhoud na oplevering: wie repareert het, en tegen welk tarief

AI-tools en de modellen eronder veranderen vaker dan de meeste reguliere software. Een API wordt uitgefaseerd, een leverancier past prijzen aan, of een modelupdate verandert net genoeg aan het gedrag van je workflow om iets te laten haperen. Wie dat oplost, en tegen welk tarief, is iets om vooraf te regelen in plaats van pas te bespreken op het moment dat het misgaat. Spreek af of er een vaste onderhoudsafspraak is, bijvoorbeeld een aantal uur per maand tegen een vast tarief, of dat reparatie per incident wordt gefactureerd tegen het reguliere uurtarief. Leg ook vast binnen welke termijn je een reactie mag verwachten als iets uitvalt, en of er iemand actief in de gaten houdt of het systeem nog goed werkt, of dat jij het pas merkt als een klant erover klaagt.

Aansprakelijkheid, geheimhouding en de verwerkersovereenkomst

Drie punten die in een gewoon freelancecontract ook al thuishoren, maar bij een AI-opdracht extra gewicht krijgen. Spreek een redelijke aansprakelijkheidsbeperking af, bijvoorbeeld tot de hoogte van het opdrachtbedrag, zodat een fout in de automatisering niet tot een onbeperkte schadeclaim leidt. Neem een geheimhoudingsbepaling op: de bouwer ziet vaak mee in je klantgegevens, interne processen en soms gevoelige bedrijfsinformatie om het systeem te kunnen bouwen. En verwerkt de oplossing persoonsgegevens, wat bij klantcommunicatie of orderdata bijna altijd het geval is, dan is een verwerkersovereenkomst geen formaliteit maar een wettelijke verplichting op grond van de AVG. Zie wat de AVG in de praktijk van je vraagt voor de basis daarvan.

Schijnzelfstandigheid: let op bij langdurige, fulltime inhuur

Een laatste punt hoort eigenlijk niet bij de bouwafspraken zelf, maar bij hoe je de samenwerking vormgeeft. Huur je één AI-bouwer voor een afgebakend project met een duidelijk resultaat in, dan speelt schijnzelfstandigheid nauwelijks. Ga je diezelfde persoon langdurig en fulltime inzetten alsof hij in dienst is, met vaste uren en dagelijkse aansturing, dan verschuift dat beeld en kan de Belastingdienst de relatie als een verkapt dienstverband beoordelen. Dat is een uitgebreider vraagstuk dan dit artikel behandelt; zie AI-freelancer inhuren: zo doe je het juridisch veilig voor hoe je dat risico beoordeelt en beperkt.

Overzicht: wat je vastlegt en wat er misgaat als je het niet doet

Een goede opdrachtbevestiging voor een AI-bouwer regelt vier dingen die bij gewone software vanzelf goed komen: wie de rechten krijgt, wie de doorlopende kosten draagt, hoe je "goed genoeg" meet, en wat er gebeurt als de samenwerking eindigt. Regel het vooraf, niet bij de eerste discussie. Zie ook de complete gids voor het inhuren van een AI-expert. Op aiworktalent loopt de opdracht, en desgewenst de betaling, via het platform.