Organisaties denken vaak dat hun rol vaststaat: wij zijn gebruiker, de leverancier is aanbieder, klaar. Die aanname klopt regelmatig niet, of klopt vandaag en morgen niet meer. De rol die een organisatie heeft ten opzichte van een AI-systeem is geen vaste eigenschap van de organisatie. Het is een uitkomst van wat er met het systeem gebeurt: wie het maakt, wie het aanpast, wie het op de markt brengt, en onder welke naam. Verandert een van die factoren, dan verandert mogelijk ook de rol, en daarmee de verplichtingen die daarbij horen.
Dat maakt indeling geen momentopname. Een rol die bij aanschaf correct was vastgesteld, kan een jaar later onjuist zijn zonder dat er intern iets bewust is besloten.
De indeling hangt af van een beperkt aantal factoren, maar die factoren liggen niet allemaal bij de partij die het systeem gebruikt. Relevant is onder meer of een systeem zelf ontwikkeld is of ingekocht, of het ingekochte systeem ongewijzigd wordt ingezet of wordt aangepast, en of aanpassing het risicoprofiel van het systeem raakt. Ook relevant is onder welke naam een systeem naar buiten gaat: een systeem dat wordt doorverkocht of doorontwikkeld onder een eigen merk kan een andere rol met zich meebrengen dan het ongewijzigd laten draaien van een extern product. Voor de precieze grens tussen die twee posities is de pagina over wat er verandert wanneer een organisatie een ingekocht model zelf aanpast relevant, en voor de basisvraag welke van de twee hoofdrollen van toepassing is, is er de pagina die uitlegt waar de keuze tussen aanbieder en gebruiker precies van afhangt.
De indeling is dus niet iets dat een organisatie eenmalig vaststelt en daarna archiveert. Het is een classificatie die opnieuw beoordeeld moet worden zodra de onderliggende feiten wijzigen.
Als de rol wijzigt, wijzigt ook wat er van een organisatie wordt verwacht. Een partij die puur gebruiker is, heeft andere verplichtingen dan een partij die (mede) verantwoordelijk is voor de totstandkoming van een systeem. Dat raakt niet alleen papierwerk. Het raakt ook waar in de organisatie de verantwoordelijkheid voor een systeem behoort te liggen, wie er over rapporteert, en welk niveau van toezicht passend is.
Die verschuiving werkt door naar de vraag hoe zwaar een systeem intern gewogen moet worden. Een rolwijziging kan ertoe leiden dat een systeem dat eerder als beheersbaar werd beschouwd, opnieuw beoordeeld moet worden op risiconiveau — een vraag die apart wordt behandeld op de pagina over wat een hoog risiconiveau betekent voor de organisatie die het systeem gebruikt of aanbiedt. Andersom kan een rolwijziging er ook toe leiden dat een systeem juist buiten het toepassingsgebied van bepaalde verplichtingen valt, of daar net binnen komt. Welke toepassingen precies buiten scope vallen en welke net niet, staat toegelicht op de pagina over welke soorten AI-toepassingen buiten de reikwijdte van de verplichtingen vallen.
De factoren die een rolwijziging veroorzaken, spelen zich meestal af op een niveau waar bestuur, juridische afdeling of risicomanagement geen automatisch zicht op hebben. Een team dat een ingekocht model finetuned op eigen data. Een afdeling die een extern chatbot-product doorzet naar klanten onder een eigen productnaam. Een integratie die een leveranciers-model combineert met eigen regels en die combinatie vervolgens extern aanbiedt. Geen van die stappen loopt automatisch langs een centraal register, en de IT-lijst van goedgekeurde tools registreert dit type wijziging meestal niet, omdat de wijziging niet als "nieuwe aanschaf" wordt herkend maar als aanpassing van iets dat al goedgekeurd was.
Dat is de reden waarom rolwijzigingen vaak pas zichtbaar worden als er iets misgaat, of als er extern om verantwoording wordt gevraagd. De vraag "wat is onze rol bij dit systeem" wordt dan met terugwerkende kracht beantwoord, op een moment dat de ruimte om iets aan te passen kleiner is dan wanneer de vraag eerder was gesteld.
Omdat de indeling kan verschuiven, is het onderscheid tussen wat op dit moment aandacht vraagt en wat op termijn opnieuw beoordeeld moet worden, relevant voor de planning van governance-werk. Niet alles wat een rolwijziging met zich meebrengt, vraagt onmiddellijk actie; een deel is planbaar. Welk deel dat is, en welk deel niet kan wachten, wordt behandeld op de pagina over wat er nu opgepakt moet worden en wat op een later moment ingepland kan worden. Voor een compacte samenvatting van de indelingsvraag zelf, inclusief de belangrijkste omslagpunten, is er de pagina die dieper ingaat op de precieze omstandigheden waaronder een rol wijzigt.
De vraag welke rol een organisatie heeft ten opzichte van een AI-systeem, ligt dicht bij een andere vraag die zelden dezelfde aandacht krijgt: welk deel van het feitelijke werk in de organisatie al door AI wordt gedaan, gepland wordt gedaan, of zonder dat iemand het heeft vastgelegd al wordt overgenomen. Waar de rolvraag gaat over verantwoordelijkheid ten opzichte van een systeem, gaat de werkscan van FTE TO AI over de verdeling van taken zelf: per taak wordt uitgerekend welk deel over te nemen is door AI, los van welke rol de organisatie daarbij formeel inneemt. Die twee vragen raken elkaar, omdat een verschuiving in taakverdeling vaak de aanleiding is voor een verschuiving in rol.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Antwoorden komen uit de kennisbank van deze site. Geen advies op maat, en geen scan van uw bedrijf.