Voordat een risiconiveau, een verplichting of een governance-maatregel betekenis krijgt, moet vaststaan welke rol uw organisatie speelt. Wie een AI-systeem op de markt brengt, heeft andere verantwoordelijkheden dan wie een systeem inzet dat door een ander is gebouwd. De term die daarvoor gebruikt wordt, is bekend: aanbieder tegenover gebruiker. Maar de indeling zelf ligt niet vast in een organigram. Ze hangt af van wat een organisatie met een specifiek systeem doet, en dat kan per systeem, per afdeling en per moment verschillen.
De kernvraag is niet wie het systeem heeft gekocht of geïnstalleerd, maar wie het op de markt heeft gebracht of onder eigen naam beschikbaar stelt. Een organisatie die software inkoopt en gebruikt zoals geleverd, is doorgaans gebruiker. Een organisatie die een systeem ontwikkelt, laat ontwikkelen onder haar naam, of een bestaand systeem zodanig aanpast dat het functioneel iets anders wordt, kan daarmee in de rol van aanbieder terechtkomen. Dat laatste is vaak het punt waar organisaties zich verkijken: een model finetunen, een eigen laag bovenop een extern systeem bouwen, of een chatbot trainen op eigen data kan de rol laten verschuiven zonder dat iemand dat als een bewuste keuze heeft ervaren. Wat daarbij precies telt als een aanpassing die de rol verandert, staat beschreven op wat verandert er als u een model zelf aanpast.
De meeste organisaties zijn niet uitsluitend aanbieder of uitsluitend gebruiker. Een bank die een extern taalmodel inzet voor klantenservice is daarin gebruiker, maar als diezelfde bank een intern ontwikkeld risicomodel aan een andere afdeling of aan een klant beschikbaar stelt, ontstaat voor dat systeem een aanbiedersrol. Dit betekent dat de indeling per toepassing gemaakt moet worden, niet één keer voor de hele organisatie. Een inventaris die per systeem vastlegt wie het heeft gebouwd, wie het heeft aangepast en wie het gebruikt, is daarom de enige manier om deze vraag structureel te beantwoorden in plaats van incidenteel.
De rol is geen vaste eigenschap van een organisatie maar een status die aan verandering onderhevig is. Een leverancier kan zijn systeem wijzigen op een manier die het risicoprofiel raakt. Een interne ontwikkelaar kan een intern hulpmiddel doorontwikkelen tot iets dat buiten de organisatie wordt aangeboden. Een systeem dat ooit als eenvoudige tool binnenkwam, kan na een update taken uitvoeren die het in een andere risicocategorie plaatsen. Op welke momenten deze verschuiving concreet optreedt en wat dat betekent voor wie er dan verantwoordelijk is, staat toegelicht op wanneer verandert uw rol. Voor organisaties die willen begrijpen wat een verschuiving richting een hoger risiconiveau in de praktijk met zich meebrengt, biedt wat betekent een hoog risiconiveau voor uw organisatie een verdere uitwerking.
Niet elke toepassing die met kunstmatige intelligentie wordt aangeduid, valt binnen het kader waarvoor de rolverdeling relevant is. Sommige systemen vallen buiten de scope waarvoor deze indeling gemaakt is, en het is voor een organisatie net zo belangrijk om te weten wat buiten de scope valt als om te weten wat erbinnen valt. Anders wordt tijd besteed aan classificatie van iets dat geen classificatie nodig had, of wordt iets over het hoofd gezien omdat het te klein leek. Welke toepassingen buiten dit kader vallen en waarom, staat beschreven op welke toepassingen vallen buiten scope.
Het vaststellen van de rol is een eerste stap, niet de uitkomst van een governance-traject. Na de indeling volgt de vraag wat er voor elke rol en elk risiconiveau feitelijk moet gebeuren, en die vraag valt uiteen in twee categorieën: wat direct aandacht vraagt en wat op een langere termijn kan worden ingepland. Die twee categorieën worden vaak door elkaar gehaald, met als gevolg dat urgente zaken blijven liggen terwijl er tijd gaat naar iets dat nog niet acuut is. Een overzicht van wat daarin prioriteit heeft, staat op wat moet er nu en wat kan gepland worden. Wie de vraag naar de rolverdeling nog verder wil uitdiepen, met de precieze criteria die de grens tussen aanbieder en gebruiker bepalen, vindt die uitwerking op bent u aanbieder of gebruiker: waar hangt dat van af.
Deze indeling is alleen zinvol als ze wordt toegepast op wat er werkelijk in de organisatie draait, niet op wat er op een goedgekeurde lijst staat. Systemen die zonder toestemming zijn ingevoerd, tellen evengoed mee, en de rol die daarbij hoort moet net zo goed worden vastgesteld. Dat vraagt om een inventaris die verder gaat dan de IT-administratie.
Zodra duidelijk is welke rol een organisatie per systeem speelt, verschuift de aandacht vanzelf naar een andere vraag: wat doen deze systemen eigenlijk, en welk deel van het werk nemen ze over. Die vraag ligt buiten de governance-scan, maar sluit er direct op aan. De werkscan van FTE TO AI rekent per taak uit welk deel van het werk door AI over te nemen is, en geeft daarmee een beeld van de impact van een systeem naast het beeld van de verplichtingen die er bij horen.
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.