Veel organisaties gaan ervan uit dat hun rol vaststaat: zij zijn gebruiker van een systeem dat een leverancier heeft gebouwd, en de verplichtingen die daarbij horen zijn duidelijk en blijvend. Die aanname klopt vaak, maar niet altijd. De rol die een organisatie heeft ten aanzien van een AI-systeem is geen vast label. Het is een uitkomst van wat er feitelijk met het systeem gebeurt, en die uitkomst kan verschuiven zonder dat er een nieuw contract wordt getekend of een nieuwe aankoop wordt gedaan.
De indeling van een rol hangt af van een aantal feitelijke elementen, niet van hoe een leverancier het systeem noemt of hoe een interne afdeling het systeem intern positioneert. Relevant is onder meer wie het systeem op de markt heeft gebracht, wie het systeem daadwerkelijk gebruikt binnen een eigen proces, en wie het systeem heeft aangepast na oplevering. Ook telt mee onder welke naam het systeem naar buiten wordt gebracht, en of een organisatie het systeem doorlevert aan anderen zonder het zelf te gebruiken. Deze elementen bepalen samen of een organisatie optreedt als aanbieder, als gebruiker, of als partij die ergens tussenin valt.
De reden dat dit relevant is voor governance, is dat de rol bepaalt welke verplichtingen bij welke partij liggen. Een organisatie die alleen gebruiker is, heeft andere verantwoordelijkheden dan een organisatie die feitelijk als aanbieder handelt. Wat er precies van elke rol wordt verwacht, staat elders beschreven; hier gaat het om het mechanisme dat bepaalt welke rol van toepassing is, en om het signaleren van het moment waarop dat mechanisme een andere uitkomst geeft dan voorheen.
Een rol is niet gekoppeld aan een systeem voor de hele levensduur ervan. Ze is gekoppeld aan wat er op een bepaald moment feitelijk gebeurt. Dat betekent dat dezelfde organisatie voor hetzelfde systeem op twee momenten in een andere rol kan vallen. Een paar situaties waarin dat gebeurt: een team dat een ingekocht model finetunet op eigen data, een afdeling die een systeem herlabelt en onder eigen naam aan andere afdelingen aanbiedt, of een organisatie die een systeem dat oorspronkelijk voor intern gebruik was bedoeld, doorlevert aan een klant of partner. In elk van die gevallen verschuift de feitelijke rol, ook al verandert er aan de buitenkant weinig.
Wat er in de praktijk verandert, is niet abstract. Het bepaalt wie verantwoordelijk is voor documentatie, wie aantoonbaar moet maken dat een systeem doet wat het beweert te doen, en wie moet reageren als er iets misgaat. Meer over wat er precies verandert als een model wordt aangepast, staat beschreven op de pagina over aanpassingen aan een model. Die verschuiving is een van de duidelijkste voorbeelden van hoe een rol kantelt zonder dat er een bewuste beslissing aan voorafgaat.
De reden dat dit onderwerp niet alleen juridisch, maar ook organisatorisch relevant is, is dat een rolwijziging vaak onopgemerkt gebeurt. Een team dat een model aanpast, denkt aan een technische verbetering, niet aan een verandering in verantwoordelijkheid. Een afdeling die een tool doorzet naar een andere afdeling, denkt aan gemak, niet aan een nieuwe rol als verstrekker. Governance die alleen kijkt naar wat is ingekocht, mist deze verschuivingen systematisch.
Dit hangt samen met de vraag welke toepassingen precies onder een regeling vallen en welke niet; die grens wordt behandeld op de pagina over de reikwijdte van toepassingen. Een systeem dat buiten scope viel toen het werd ingekocht, kan binnen scope komen zodra de rol van de organisatie verschuift. Dat maakt het niet genoeg om bij aankoop eenmalig te toetsen; de toetsing moet meebewegen met wat er feitelijk met een systeem gebeurt.
Ook het risiconiveau van een toepassing kan meebewegen met een rolwijziging. Wat een hoog risiconiveau precies betekent voor de verplichtingen van een organisatie, en waarvan dat afhangt, staat toegelicht op de pagina over de gevolgen van een hoog risiconiveau. Een organisatie die door een rolwijziging plotseling als aanbieder geldt van een systeem met een hoog risiconiveau, draagt andere verantwoordelijkheden dan toen ze alleen gebruiker was van datzelfde systeem.
Om rolwijzigingen te signaleren voordat ze een probleem worden, moet een organisatie weten welke systemen er zijn, wie ze aanpast, en wie ze doorzet naar wie. Dat vraagt om een inventaris die verder gaat dan de lijst die IT heeft goedgekeurd, en om een vaste plek waar beslissingen over aanpassing, doorzet en herlabeling worden vastgelegd. Zo'n vaste plek, en de vragen die daarbij horen, staan beschreven op de pagina over een oversight-besluitenlijst.
De Responsible AI Scan is gebouwd om deze verschuivingen zichtbaar te maken: welke systemen er feitelijk draaien, wie ze gebruikt, wie ze heeft aangepast, en welke rol daaruit volgt op dit moment. De tool die dit ondersteunt is in aanbouw; wie hier gebruik van wil maken, kan zich aanmelden voor de wachtlijst.
Een rolwijziging raakt niet alleen governance. Als een systeem verschuift van los hulpmiddel naar iets dat structureel een deel van een taak overneemt, verandert ook de vraag hoeveel werk dat systeem eigenlijk doet en hoeveel er nog bij mensen ligt. De werkscan van FTE TO AI rekent per taak uit welk deel van het werk door AI over te nemen is, en maakt zo inzichtelijk waar een rolwijziging in governance samenvalt met een feitelijke verschuiving in de verdeling van werk.
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.