AI Act en je leveranciers: waar je contractueel op moet letten

Er is een zin die in vrijwel elk AI-verkoopgesprek voorkomt: "wij zijn volledig AI Act compliant." Hij is meestal waar en vrijwel altijd irrelevant voor jouw positie, en het gat tussen die twee feiten is waar bedrijven in de problemen komen.

De AI Act verdeelt verplichtingen over rollen, niet over facturen. Een aanbieder die een systeem bouwt en op de markt brengt heeft de ene set. Een gebruiker die het in zijn eigen bedrijfsvoering inzet heeft de andere. Kopen bij een aanbieder die voldoet, verplaatst jouw gebruikersverplichtingen niet naar hem, net zomin als het kopen van een goedgekeurde bestelbus je plicht wegneemt om er fatsoenlijk mee te rijden.

Wat van jou blijft, ongeacht bij wie je koopt

Zet je een hoogrisicosysteem in, dan blijven verschillende dingen van jou, wat er ook in het contract staat. Zorgen dat er betekenisvol menselijk toezicht is op hoe het in jouw proces wordt gebruikt. Het gebruiken volgens de instructies van de aanbieder, en aanspreekbaar zijn als je dat niet doet. Volgen hoe het zich gedraagt op jouw echte data, wat niet de data is waarop het is getest. En de vastlegging bijhouden die laat zien dat je die dingen hebt gedaan.

Artikel 26 is het waard om een keer helemaal te lezen, want het is kort en het is het artikel dat jouw positie beschrijft in plaats van die van je leverancier. Er staat onder meer in dat de mensen die je aanwijst voor het toezicht de benodigde bekwaamheid, opleiding en bevoegdheid moeten hebben, dat je de aanbieder informeert over risico's en ernstige incidenten die je signaleert, en dat je de door het systeem gegenereerde logs minimaal zes maanden bewaart voor zover die onder jouw beheer vallen. Dat laatste is concreet, controleerbaar en wordt vaak over het hoofd gezien: staan de logs in het systeem van je leverancier en gooit hij ze na dertig dagen weg, dan kun je niet voldoen aan een verplichting die van jou is.

Er is er nog een die werkgevers specifiek raakt. Zet je een hoogrisicosysteem in op de werkvloer, dan moet je de betrokken medewerkers en hun vertegenwoordiging informeren voordat je het in gebruik neemt. Dat is geen beleefdheid; het staat in het artikel.

Een leverancier kan die niet overnemen, en een leverancier die suggereert van wel is ofwel slordig met taal ofwel begrijpt de verordening niet. Geen van beide is op zichzelf een reden om weg te lopen, maar het vertelt je wel hoe zorgvuldig je de rest van zijn uitspraken moet lezen.

Papierwerk op tafel. Kan je leverancier geen documentatie leveren, dan kun jij niet aan je eigen verplichtingen voldoen.

Zes dingen om in het contract te krijgen

Een: recht op de technische documentatie, niet op een samenvatting ervan. Is jouw systeem hoogrisico, dan heb je documentatie nodig om aan je eigen verplichtingen te voldoen. Levert de leverancier alleen een overzicht op brochureniveau, dan heb je een probleem dat op het slechtst denkbare moment bovenkomt. Vraag erom voor het tekenen, en beschouw terughoudendheid als informatie.

Twee: melding als het model verandert. Dit is de clausule die het vaakst ontbreekt en die de meeste ellende veroorzaakt. Een model dat stilletjes wordt bijgewerkt gedraagt zich anders op jouw data, en heb je het voor die wijziging gevalideerd, dan heb je iets gevalideerd dat niet meer bestaat. Je moet het te horen krijgen, vooraf, op papier.

Drie: een expliciete uitspraak over wat de leverancier garandeert over uitkomsten. Vrijwel altijd is het antwoord niets, en dat is normaal. Waar het om gaat is dat het er staat in plaats van dat het in het midden blijft, want die vaagheid is wat later een conflict oplevert. Zie Wie is aansprakelijk voor wat dat in de praktijk betekent.

Vier: waar je data heen gaat, en of er iets mee getraind wordt. Niet alleen vanwege privacywetgeving, wat een ander regime is dan de AI Act, maar omdat "jouw invoer kan gebruikt worden om onze dienstverlening te verbeteren" een zin is met zeer grote gevolgen voor een bedrijf met vertrouwelijke klantgegevens.

Vijf: een uitgang die daadwerkelijk werkt. Je data eruit, in een bruikbaar formaat, binnen een afgesproken termijn, zonder een vergoeding die vertrekken theoretisch maakt. Een leverancier die vertrouwen heeft in zijn product heeft geen reden om hier moeilijk over te doen.

Zes: wie wat doet als een toezichthouder aanklopt. Zeldzaam, maar het moment om dat af te spreken is niet terwijl het gebeurt.

Gestapelde zeecontainers. Een stack waar je een laag uit kunt wisselen is een stack die je nog in de hand hebt.

De zes clausules, en wat er zonder elke misgaat

Geen van deze zes vraagt technische kennis om naar te vragen. Alle zes zijn ze eenvoudiger te krijgen voor ondertekening dan erna, en hoe moeilijk ze erna te krijgen zijn is ruwweg evenredig aan hoe hard je ze nodig hebt.

Waarom kunnen vertrekken een nalevingsvraag is en niet alleen een commerciele

Dit is het deel dat meestal wordt behandeld als een inkoopvoorkeur en dat beter verdient, want het raakt je positie richting de regelgeving rechtstreeks.

Verandert een leverancier zijn voorwaarden, verhoogt hij de prijs, wordt hij overgenomen, of blijkt hij niet te voldoen aan iets waar jij van afhankelijk bent, dan worden je mogelijkheden volledig bepaald door hoe moeilijk hij te vervangen is. Een bedrijf dat niet kan wisselen heeft geen positie en geen remedie; het kan alleen meebewegen met wat de leverancier vervolgens besluit. Dat is geen sterke plek om te staan als datgene waar je van hem afhankelijk bent je eigen naleving is.

Daarom bouwen wij zoals we bouwen, en het is het waard om dat gewoon te zeggen omdat het een echt onderscheid is en geen leus. Elke laag van de stack die wij neerzetten hoort in dagen vervangbaar te zijn in plaats van in kwartalen: het model, de opslag, de interface, de hosting. Niet omdat we verwachten ze te vervangen, maar omdat het kunnen vervangen is wat de keuze bij jou houdt. Een semantische laag die jouw bedrijf beschrijft in plaats van het schema van een leverancier, zoals behandeld in Je data op orde krijgen, is hetzelfde principe toegepast op data: de definities overleven een systeemvervanging omdat ze nooit aan dat systeem vastzaten.

Overdraagbaarheid is het punt. Hosting in de EU is een nuttige eigenschap, en het is niet hetzelfde als zeggenschap. Een systeem dat in Frankfurt draait en dat je niet kunt verlaten is nog steeds een systeem waar je geen zeggenschap over hebt.

Vragen om te stellen voor je tekent

Vier vragen, geen ervan vraagt technische kennis, en alle vier zijn ze lastig vaag te beantwoorden:

Welke besluiten neemt jullie gereedschap zonder dat een mens er eerst naar kijkt? Wat gebeurt er, concreet, als het fout zit? Wat garanderen jullie over de juistheid van de uitkomsten, op papier? Als we over achttien maanden willen vertrekken, wat krijgen we dan precies terug en hoe lang duurt dat?

Die vierde verandert de toon van het gesprek meer dan de andere drie bij elkaar, en hoe een leverancier erop reageert is oprecht informatief.

Over deze pagina

Het onderscheid tussen aanbieder en gebruiker is de structuur die de AI Act zelf hanteert; het punt dat verplichtingen rollen volgen in plaats van aankopen is de correcte formulering en is de reden dat "wij voldoen" van een leverancier jouw positie niet regelt. Het overdraagbaarheidsargument weerspiegelt hoe Radical bouwt en is onze eigen positie, geen eis uit de regelgeving. Privacywetgeving en de AI Act zijn verschillende regimes en worden hier ook zo behandeld. Dit is geen juridisch advies; betrek voor een specifiek contract je eigen jurist. Geschreven door Radicals eigen team; er is geen klantdata gebruikt.