Auditrecht in AI-contracten: leg inspectiebewijs vast

U moet per AI-contract vastleggen welk inspectiebewijs de leverancier levert, binnen welke termijn, met welke bevoegdheden en welke sancties gelden bij weigering of onvolledigheid. Een algemeen auditrecht volstaat niet om een concrete AI-uitkomst achteraf te verifiëren.

De aanleiding is een analyse van 26 oktober 2026 van het contractuele inspectiebewijs dat nodig is om AI-uitkomsten te reconstrueren, die stelt dat een auditclausule die alleen toegang tot algemene documentatie belooft, niet garandeert dat u een specifieke AI-beslissing kunt verklaren. Het voorbeeld is AI-as-a-Service, waar meerdere leveranciers aan één output bijdragen en het bewijs verdampt zodra het auditrecht stopt bij de directe leverancier. In onze inschatting is dit het grootste blinde vlek in bestaande contracten: afnemers regelen vaak een auditrecht met hun directe leverancier, maar niet met diens subprocessors, terwijl juist daar het bewijs ligt.

Waarom een algemeen auditrecht niet volstaat

De Europese Commissie bereidt via een Expert Group on AI Contracting modelcontractvoorwaarden voor. Artikel 25 van de AI-verordening verplicht aanbieders en derde partijen al om bij schriftelijke overeenkomst de noodzakelijke informatie, capaciteiten, technische toegang en bijstand te specificeren. Maar dit is een verplichting tot specificeren van toegang, niet een onbeperkt zelfstandig recht om alles in te specteren.

Een peer-reviewed studie beschrijft hoe AI-as-a-Service een afnemer kan beroven van de telemetrie die nodig is om geautomatiseerde handelingen te verklaren en te corrigeren. Een algemene complianceverklaring bewijst niet dat u een specifieke AI-gebeurtenis achteraf kunt reconstrueren. De Commissie wijst erop dat hoog-risico-systemen traceerbaar en auditeerbaar moeten zijn en dat passende documentatie moet worden bewaard. Een contract dat dit niet afdwingt, laat die traceerbaarheid afhangen van de goede wil van de leverancier.

Welke vijf elementen moet het inspectierecht bevatten

Een afdwingbaar beding benoemt niet alleen een "auditrecht", maar de records en toegang die de leverancier daadwerkelijk moet produceren. Werk uw clausule uit langs deze elementen:

1. Definieer welke records en logs beschikbaar moeten zijn — modelversies, inputgegevens, verwerkingsstappen, outputbeslissingen en toolgebruik per datum en gebruiker.
2. Leg vast welke bewaartermijn geldt — hoe lang de leverancier deze records moet bewaren en binnen welke termijn u ze kunt opvragen.
3. Specificeer de inspectieperiode en steekproef — welke tijdsvensters, welke transacties en welke hoeveelheid gegevens u mag inspecteren.
4. Bepaal wie mag inspecteren en onder welke voorwaarden — interne auditors, externe accountants, regelgevers, en welke vertrouwelijkheidsafspraken gelden.
5. Definieer de remedies bij weigering of onvolledigheid — opschorting van diensten, step-in-rechten, contractbeëindiging of schadevergoeding.

Hoe regelt u transitieve auditrechten naar subprocessors

Bij AI-as-a-Service bijdragen meerdere leveranciers aan één output. Het auditrecht moet meelopen tot bij de onderliggende leverancier die de gewraakte stap uitvoerde. Dit onderscheid tussen een contractueel recht om in te specteren en de concrete records die beschikbaar moeten zijn, bepaalt of u een technische AI-uitleg kunt omzetten in bruikbaar beslisbewijs.

U loopt het risico een AI-beslissing achteraf niet overtuigend te kunnen uitleggen of controleren als u geen transitief auditrecht bedingen. De contractmanager moet daarom de AI-componenten in de leveranciersketen onderzoeken en een auditrecht naar subprocessors vastleggen. Omdat leveranciers verificatie kunnen afwenden met een beroep op bedrijfsgeheimen, is een auditrecht zonder remedie papier. De bestuurder moet opschorting, step-in en beëindiging bij niet-reconstrueerbaarheid als harde sancties laten opnemen.

Wat levert tooling en wat blijft uw eigen oordeel

Modelvoorwaarden, de AI Act en academische frameworks bieden bouwstenen, maar geen universeel auditbeding dat elke afnemer blind kan overnemen. Wie wil doorgronden hoe deze eisen passen in een breder verantwoordingskader, moet ze afstemmen op het risico, de sector, de toepasselijke wetgeving en de feitelijke systeemarchitectuur. Softwaretools kunnen audittrails vastleggen en controlelijsten nakomen, maar kunnen niet bepalen welke records voor uw specifieke casus relevant zijn of welke sancties proportioneel zijn. Die beoordeling blijft uw eigen professionele verantwoordelijkheid.