AI contract-clausules voor inkoop en levering van AI-tools.

Waarom een standaard-AVG-DPA niet genoeg is voor AI.

Veel MKB-organisaties denken dat een standaard AVG-verwerkersovereenkomst (DPA) afdoende contract-fundament is bij AI-diensten. Dat klopt voor persoonsgegevens-verwerking in enge zin, maar dekt de AI Act-specifieke onderwerpen niet. De AI Act (Verordening 2024/1689) introduceert een ander regime met eigen verplichtingen, rollen en aansprakelijkheden. Die passen niet netjes in een DPA die 2018 is ontworpen rondom AVG Artikel 28.

Deze gids behandelt drie scenarios. Ben je inkopende partij (deployer)? Dan lees je welke clausules je van je leverancier eist. Ben je leverende partij (aanbieder)? Dan lees je welke clausules je in je klantcontract vastlegt. Ben je integrator? Dan heb je een dubbele rol en een dubbel contract-pakket. Per scenario concrete clausule-tekst, onderhandel-punten en red-flags. We sluiten af met drie use-case-contracten (SaaS-AI, custom-AI, GPAI-API) en een review-checklist van 40+ items.

Bovenaan elke AI-contract-exercitie staat Artikel 25 AI Act: substantiele modificatie door de klant kan de klant als aanbieder herkwalificeren. Dat betekent dat alle aanbieder-verplichtingen (technisch dossier, conformity assessment, CE-markering) naar de klant verschuiven. Het artikel laat expliciet ruimte voor contractuele allocatie: "zonder afbreuk te doen aan contractuele arrangementen die obligaties anders toewijzen". Zonder clausule val je standaard terug op wetswerking, en dat is zelden wat beide partijen willen. Voor bredere context: zie onze AI Act compliance roadmap.

Drie contract-strategieen voor Artikel 25.

Strategie A - Modificatie verbieden. Contract bepaalt dat klant geen substantiele modificatie mag uitvoeren. Doorbreek is contract-breuk. Geschikt voor SaaS-AI waar klant alleen gebruikt. Simpel, maar beperkt klant-flexibiliteit.

Strategie B - Modificatie toestaan, rol bij klant. Klant mag modificeren, wordt dan expliciet aanbieder met alle verplichtingen. Leverancier levert informatie en technische medewerking tegen uurtarief of vast bedrag. Geschikt voor platform-AI met klant-customization. Klant moet bewust aanbieder-last accepteren.

Strategie C - Modificatie toestaan, rol bij leverancier. Klant modificeert, maar leverancier blijft aanbieder (via contractuele allocatie conform Artikel 25). Leverancier draagt dan volledige aanbieder-last voor alle klant-varianten. Geschikt voor managed-service AI. Premium-pricing gerechtvaardigd.

Welke strategie past hangt af van klant-autonomie-behoefte en leverancier-risicotolerantie. In alle drie geldt: contract moet substantiele modificatie definieren (wat telt, wat niet), notificatie-plicht regelen, en informatie-overdracht beschrijven. Voor de klant-kant: zie onze risicoclassificatie-pagina.

Kruiscontroles. Bij use-case 2 en 3 krijg je te maken met cascading contracts: de bouwer of integrator heeft zelf weer contracten met derden. Check in je contract een "flow-down"-clausule die essentiele AI Act-clausules doorwerkt naar sub-leveranciers. Zonder deze clausule ben je afhankelijk van wat jouw directe leverancier met derden heeft afgesproken, en kan Artikel 25-risico verborgen zitten in de keten. Voor documentatie-eisen: zie onze documentatie-pagina.

Vijf fouten die AI-contracten laten falen.

1. Alleen standaard-DPA zonder AI-addendum.

MKB-organisatie tekent leveranciers-template met standaard AVG-DPA en denkt gedekt te zijn. Bij eerste audit of incident ontbreken classificatie, IFU-levering, logs-toegang, rol-wissel. Oplossing: AI-addendum altijd afsluiten, ook bij kleine AI-tools. Templates verkrijgbaar; onder begeleiding eenmalig op maat, daarna hergebruiken per leverancier.

2. Artikel 25 niet geadresseerd.

Contract zwijgt over substantiele modificatie. Klant fine-tunet model op eigen data of wijzigt doel; wordt ongemerkt aanbieder. Bij audit: aanbieder-verplichtingen niet uitgevoerd. Oplossing: Artikel 25-clausule verplicht, met definitie van substantiele modificatie, procedure bij wijziging, informatie-overdracht door oude aanbieder.

3. Data-gebruik-clausule te vaag.

"Leverancier mag data gebruiken voor productverbetering" lijkt onschuldig maar dekt training op klantdata. Bij GenAI: klant-prompts en output belanden in training-set van volgende model-generatie. Oplossing: expliciet training-verbod, met ruimte voor anoniem-aggregaat-telemetrie mits klant-toestemming, duidelijke scope en opt-out.

4. Aansprakelijkheids-cap te laag.

Cap op vast bedrag of zes-maands-fee, terwijl AI Act-boetes tot 35 miljoen euro of 7% wereldomzet lopen (Artikel 99). Oplossing: aansprakelijkheids-cap minimaal 1x jaarcontractwaarde, met uitzondering voor opzet en grove nalatigheid (ongelimiteerd), AVG-boete expliciet gedekt.

5. Exit-clausules ontbreken of zijn open-ended.

Contract eindigt; klant heeft geen format-afspraak en krijgt data als JSON-dump zonder context, of logs worden niet overgedragen voor bewaartermijn. Oplossing: exit-clausule met standaardformaat, transitie-periode minimum 3 maanden, verwijderings-verklaring, assistance tegen vast tarief, documentatie en logs 10 jaar bewaartermijn borgen.

Verdieping per deelonderwerp.

AI-contracten zijn een afgeleide van rol, classificatie en documentatie. Voor diepere duiding op deze aangrenzende onderwerpen:

• AI Act uitgelegd: wat de wet betekent voor jouw bedrijf, inclusief rolbepaling en classificatie.
• Artikel 25 AI Act: wanneer wordt een deployer aanbieder bij substantiele modificatie.
• Artikel 10 AI Act: data governance-eisen voor training-, validatie- en test-datasets.
• Risicoclassificatie AI Act: werkflow om te bepalen of jouw AI high-risk of limited-risk is.
• Documentatie-verplichtingen: Artikel 11 technisch dossier en Artikel 13 Instructions for Use uitgelegd.

Externe bronnen voor verificatie: AI Act Verordening 2024/1689 op EUR-Lex, Artikel 25 samenvatting, Artikel 50 samenvatting, AP AI-en-algoritmes-pagina.