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 providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry → ofwel de deployerdeployerAn organization using an AI system under its own authority in its activities — carrying operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry →, 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-systeem 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-risico AI-systeem draagt het volledige technische apparaat: een risicobeheerssysteem (Art. 9), datagovernance (Art. 10), technische documentatie (Art. 11), automatische logging-capaciteit (Art. 12), transparantie en gebruiksinstructies (Art. 13), menselijk toezicht via ontwerp (Art. 14), nauwkeurigheid, robuustheid en cyberbeveiliging (Art. 15), een kwaliteitsmanagementsysteem (Art. 17), logbewaring (Art. 19), conformiteitsbeoordeling (Art. 43), de EU-conformiteitsverklaring en CE-markering (Art. 47, 48), registratie in de EU-database (Art. 49), en post-market monitoringpost-market monitoringProvider-side duty to systematically collect and act on experience from systems in use — the product-regulation half of continuous monitoring.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 betrokkenen (Art. 26.7), en, voor bepaalde deployers, voer een Fundamental Rights Impact Assessmentimpact assessmentThe design-time discipline of describing a system, mapping stakeholders, identifying harms, rating probability × severity, choosing mitigations and documenting a signed decision — the skeleton under DPIAs, FRIAs and AIAs.Open full entry → 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 wijziging 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-inventaris 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.