Provider of deployer: welke rol heb je onder de EU AI Act?

De meest bepalende vraag in EU AI Act-compliance is ook de eerste: welke rol heb je? Vrijwel elke verplichting in de verordening wordt toegewezen aan ofwel de provider ofwel de deployer, en de twee sets plichten verschillen sterk in gewicht. Krijg de rol verkeerd en je bouwt ofwel een zwaar compliance-apparaat dat je niet nodig hebt, ofwel je mist de verplichtingen die werkelijk op je van toepassing zijn. Erger nog, het antwoord is niet hetzelfde voor elk AI-systeemAI-systeemEen machinaal systeem dat voor expliciete of impliciete doelen uit invoer afleidt hoe het uitvoer genereert, voorspellingen, inhoud, aanbevelingen of beslissingen, die fysieke of virtuele omgevingen kunnen beïnvloeden. De OESO-achtige definitie die de EU AI Act volgt. Zie algoritme, machine learning.Open full entry → dat een organisatie draait. Eén organisatie is routinematig deployer van sommige systemen en provider van andere, en af en toe beide voor hetzelfde systeem.

Dit artikel zet het onderscheid uiteen, de verplichtingen die elke rol draagt, de situaties waarin de grens echt moeilijk te trekken is, en hoe je je rol per systeem bepaalt. Het is de oriëntatiestap die aan elk ander stuk EU AI Act-werk vooraf zou moeten gaan, omdat de rol bepaalt welke artikelen je vervolgens leest.

De twee rollen, gedefinieerd

De definities staan in Art. 3 van de EU AI Act.

Een provider is een natuurlijke of rechtspersoon die een AI-systeem of een GPAI-model ontwikkelt, of laat ontwikkelen, en het onder eigen naam of merk op de markt brengt of in gebruik stelt, al dan niet tegen betaling. De bepalende handelingen zijn ontwikkelen en onder eigen naam op de markt brengen. Een provider is de partij die het systeem als product tot stand brengt.

Een deployer is een natuurlijke of rechtspersoon die een AI-systeem onder zijn gezag gebruikt, behalve waar het gebruik een persoonlijke, niet-professionele activiteit is. De bepalende handeling is gebruik in een professionele context. Een deployer is de partij die een bestaand systeem neemt en het aan het werk zet.

Het onderscheid is tussen maken en gebruiken. De provider maakt het systeem; de deployer gebruikt het. Dat klinkt schoon, en voor de meeste gevallen is het dat, maar de EU AI Act voegt situaties toe waarin de handelingen van een deployer hem in een provider veranderen, en daar zit de moeilijkheid.

Waarom de rol er zo toe doet: het gewicht van de verplichtingen

De twee rollen dragen geen vergelijkbare lasten. De provider-verplichtingen zijn aanzienlijk zwaarder, omdat de provider de partij is die het best in staat is om veiligheid en compliance in het systeem zelf in te bouwen.

Een provider van een hoog-risicorisicoIn de termen van de EU AI Act de combinatie van de waarschijnlijkheid dat een schade optreedt en de ernst ervan als dat gebeurt. De schakel tussen een principe (via de schade die het zou schenden) en een control (de maatregel die het vermindert). Het benoemen van de schade en het inschatten van het risico is op grond van Art. 9 vereist voordat een maatregel wordt gekozen. Zie schade, control, restrisico.Open full entry → AI-systeem draagt het volledige technische apparaat: een risicobeheerssysteem (Art. 9), datagovernance (Art. 10), technische documentatietechnische documentatieRegistraties die een aanbieder voor een hoog-risico-AI-systeem moet samenstellen en bewaren om conformiteit aan te tonen, met dekking van het ontwerp, de data, het testen, het risicobeheer en de monitoring. Zie aanbieder, bewijs, model card.Open full entry → (Art. 11), automatische logging-capaciteit (Art. 12), transparantietransparantieOpenheid over het feit dát AI wordt gebruikt en hoe het in het algemeen werkt: openbaarmakingen, documentatie, kennisgevingen. Vormt een paar met uitlegbaarheid, die over individuele uitkomsten gaat. Zie uitlegbaarheid, principe.Open full entry → en gebruiksinstructies (Art. 13), menselijk toezichtmenselijk toezichtHet ingebouwde vermogen van een mens om een AI-systeem te monitoren, erin in te grijpen, het te overrulen of stil te leggen, alleen betekenisvol wanneer de mens de bevoegdheid, de informatie en de tijd heeft om te handelen. Zie principe, human-in-the-loop, human-on-the-loop.Open full entry → via ontwerp (Art. 14), nauwkeurigheid, robuustheidrobuustheidHet vermogen van een systeem om betrouwbaar te presteren onder realistische omstandigheden, inclusief ruis, randgevallen en tegenwerkende druk, de technische kern van het principe veiligheid en betrouwbaarheid. Zie beveiliging en robuustheid, principe.Open full entry → en cyberbeveiliging (Art. 15), een kwaliteitsmanagementsysteem (Art. 17), logbewaring (Art. 19), conformiteitsbeoordelingconformiteitsbeoordelingHet proces vóór markttoelating waarmee wordt aangetoond dat een hoog-risico-AI-systeem voldoet aan de eisen van de EU AI Act, leidend tot CE-markering en registratie. Zie CE-markering, aangemelde instantie.Open full entry → (Art. 43), de EU-conformiteitsverklaringconformiteitsverklaringDe ondertekende verklaring van de aanbieder dat een hoog-risico-AI-systeem aan de eisen van de AI Act voldoet, opgesteld voordat het systeem op de markt wordt gebracht. Zie aanbieder, conformiteitsbeoordeling.Open full entry → en CE-markeringCE-markeringDe markering die op producten (waaronder hoog-risico-AI-systemen) wordt aangebracht en aangeeft dat ze voldoen aan de toepasselijke EU-eisen. Zie conformiteitsbeoordeling, conformiteitsverklaring.Open full entry → (Art. 47, 48), registratie in de EU-database (Art. 49), en post-market monitoringpost-market monitoringDe plicht aan de aanbiederszijde om ervaring met systemen in gebruik systematisch te verzamelen en erop te handelen, de productregelgevingshelft van doorlopende monitoring. Zie doorlopende monitoring, aanbieder.Open full entry → (Art. 72). Dit is de zware kant van de verordening.

Een deployer van datzelfde hoog-risico systeem draagt een lichtere, operationele set: gebruik het systeem conform de instructies (Art. 26.1), borg menselijk toezicht (Art. 26.2), zorg dat inputdata relevant is (Art. 26.4), bewaak de werking (Art. 26.5), bewaar de logs (Art. 26.6), informeer betrokkenenbetrokkenenDe individuen of groepen die onderworpen zijn aan of geraakt worden door de uitkomsten of beslissingen van een AI-systeem, en wier rechten het governance-regime beoogt te beschermen. Zie schade, belanghebbendenanalyse.Open full entry → (Art. 26.7), en, voor bepaalde deployers, voer een Fundamental Rights Impact Assessment uit (Art. 27). Dit zijn echte verplichtingen, maar ze zijn operationeel in plaats van constructief, en ze zijn haalbaar zonder het systeem te bouwen.

De kloof is ruwweg drie tot vier keer het werkvolume. Daarom is het correct bepalen van de rol geen formaliteit: het is het verschil tussen een hanteerbaar operationeel programma en een volledige product-conformiteitsinspanning.

Wanneer een deployer een provider wordt

Het moeilijkste deel van het onderscheid is de reeks situaties waarin een deployer de grens overschrijdt en provider-verplichtingen op zich neemt. Art. 25 zet deze uiteen. Een deployer (of andere derde partij) wordt provider van een hoog-risico systeem als hij:

• Zijn eigen naam of merk plaatst op een hoog-risico AI-systeem dat al op de markt is. Als je andermans systeem herlabelt als het jouwe, word je de provider ervan.
• Een substantiële wijzigingsubstantiële wijzigingEen verandering aan een uitgerold AI-systeem die zijn functie of doel wezenlijk wijzigt, in staat om de verplichtingen van de aanbieder naar de wijzigende partij te verschuiven. Zie aanbieder, AI-verplichtingen, herbestemming.Open full entry → aanbrengt in een hoog-risico systeem op een manier waardoor het hoog-risico blijft. Significante veranderingen in hoe het systeem werkt, kunnen je de provider maken van het gewijzigde systeem.
• Het beoogde doel wijzigt van een AI-systeem, ook een GPAI-systeem, zodat het hoog-risico wordt. Als je een algemeen systeem neemt en het inzet voor een hoog-risico doel waarvoor het niet op de markt is gebracht, kun je de provider worden van dat hoog-risico gebruik.

Deze laatste route is degene die organisaties vangt die GPAI integreren. Een applicatie bouwen op een GPAI-model en die inzetten voor een hoog-risico gebruiksgeval, zoals CV-screening of kredietbeoordeling, kan je de provider maken van een hoog-risico AI-systeem, met alle provider-verplichtingen die daarbij horen, ook al heb je het onderliggende model niet getraind. De oorspronkelijke modelprovider blijft verantwoordelijk voor het model; jij wordt verantwoordelijk voor de hoog-risico applicatie die je erop bouwde.

De dubbele-rol-realiteit

De meeste organisaties van enige omvang zijn beide, provider en deployer, over hun AI-portfolio. Het patroon is gangbaar: een bedrijf is deployer van Microsoft Copilot, deployer van een externe CV-screening-tool, en provider van de klantgerichte chatbot die het op een GPAI-model bouwde. Drie systemen, twee rollen, één organisatie.

Daarom wordt de rolvraag per systeem beantwoord, niet per organisatie. Er is geen enkel correct antwoord op "zijn wij provider of deployer"; er is alleen een correct antwoord op "wat is onze rol voor dit specifieke systeem". Een AI-inventarisAI-inventarisEen register van alle AI-systemen die een organisatie bouwt, koopt of inbedt, met eigenaren en risicoklassen, de voorwaarde om er ook maar één te kunnen besturen. Zie risico, governance.Open full entry → die de rol per systeem niet vastlegt, mist het veld dat bepaalt welke verplichtingen van toepassing zijn.

Je rol bepalen: een test per systeem

Werk voor elk AI-systeem in je inventaris de vragen op volgorde af:

1. Hebben wij dit systeem ontwikkeld, of laten ontwikkelen, en op de markt of in gebruik gesteld onder onze eigen naam? Zo ja, ben je de provider.
2. Hebben wij onze naam of merk geplaatst op een systeem dat iemand anders op de markt bracht? Zo ja, ben je de provider (Art. 25).
3. Hebben wij een hoog-risico systeem substantieel gewijzigd, of een systeem herbestemd voor een hoog-risico gebruik waarvoor het niet bedoeld was? Zo ja, ben je waarschijnlijk de provider van het gewijzigde of herbestemde systeem (Art. 25).
4. Gebruiken wij een systeem dat door iemand anders is ontwikkeld en op de markt gebracht, in onze professionele hoedanigheid, zonder het bovenstaande? Zo ja, ben je de deployer.

De uitkomst is een rollabel voor elk systeem, dat vervolgens wijst naar de verplichtingen die van toepassing zijn. Leg het vast in de inventaris naast de risicoclassificatie, omdat de twee samen de volledige compliance-scope voor dat systeem bepalen.

Waarom dit de oriëntatiestap is

Elk ander stuk EU AI Act-werk hangt af van de rol. De risicoclassificatie onder Art. 6 vertelt je of de verplichtingen zwaar of licht zijn; de rol vertelt je welke set verplichtingen het zijn. Een deployer leest de Art. 26-serie; een provider leest Art. 9 tot en met 15 en de conformiteitsartikelen. De verkeerde set lezen is in het beste geval verspilde moeite en in het slechtste geval een compliance-gat.

Dit is ook waarom de provider-artikelen en de deployer-artikelen in deze kennisbank op rol zijn getagd. Zodra je je rol voor een systeem kent, vertelt het rollabel je welke artikelen de jouwe zijn. De rol bepalen is geen voorbereiding op compliance-werk; het is de eerste daad ervan.