re-ai-gov Op de wachtlijst

Kennisbank

Wat buiten scope valt, en waarom dat kan verschuiven

Een indelingsvraag, geen lijst

De vraag welke toepassingen buiten scope vallen, klinkt als een vraag om een lijst. Dat is het niet. Of iets binnen of buiten scope valt, is een indeling die afhangt van wat een toepassing doet, in welke context, en voor wie. Dezelfde technologie kan in de ene toepassing buiten beeld blijven en in de andere onder volle aandacht komen. Een vaste lijst van uitgesloten toepassingen bestaat daarom niet — wel een aantal factoren die de indeling bepalen.

Waar de indeling van afhangt

De eerste factor is de functie van de toepassing: wat beslist of adviseert het systeem, en voor wie heeft dat gevolgen. Een tool die interne tekst herschrijft, ligt anders dan een tool die meebeslist over een aanvraag, een sollicitatie of een claim. De tweede factor is het risiconiveau dat aan die functie hangt: naarmate de gevolgen voor mensen groter zijn, verschuift een toepassing eerder richting het zwaardere deel van het spectrum. De derde factor is de rol van de organisatie zelf: wie een systeem alleen gebruikt, wordt anders beoordeeld dan wie het aanpast, doortraint of samenstelt uit onderdelen van anderen. Wat die rolverdeling precies inhoudt en wanneer die verschuift, staat beschreven op de pagina's over het onderscheid tussen aanbieder en gebruiker van een AI-systeem en over het moment waarop een gebruikersrol overgaat in een andere verantwoordelijkheid.

Een vierde factor is technisch van aard, maar juridisch relevant: wat een organisatie zelf wijzigt aan een bestaand model, verandert soms de positie van die organisatie in het geheel. Een model dat ongewijzigd wordt ingekocht, valt anders in het plaatje dan een model dat wordt gefinetuned op eigen data of ingebed in een eigen proces. Die grens — wanneer aanpassen een rolverandering met zich meebrengt — wordt behandeld op de pagina over wat er verandert als een model zelf wordt aangepast.

Wat er verandert als de situatie verandert

Omdat de indeling van deze factoren afhangt, is scope geen vaststaand kenmerk van een tool maar een uitkomst die kan wijzigen. Een chatbot die begon als interne schrijfhulp kan, zodra hij ook klantvragen beantwoordt die tot een besluit leiden, in een ander deel van het spectrum terechtkomen. Een model dat werd ingekocht als kant-en-klaar product kan, na aanpassing op eigen data, een andere rol voor de organisatie met zich meebrengen. Een toepassing die vandaag als low-impact geldt, kan morgen zwaarder wegen omdat de context waarin hij wordt ingezet is veranderd — een ander team, een ander besluit, een andere groep mensen die de uitkomst raakt.

Dit is precies waarom een eenmalige indeling niet voldoet. Een classificatie die is vastgelegd op het moment van invoering, zegt niets over wat een tool een jaar later doet. Wat vandaag onder scope moet komen en wat gepland kan worden voor later, is dan ook zelf een vraag die van de actuele situatie afhangt — uitgewerkt op de pagina over de volgorde tussen wat nu aandacht vraagt en wat later kan volgen.

Waarom dit niet aan de IT-lijst kan worden afgelezen

De indeling in en buiten scope wordt lastiger door een praktisch probleem: de officiële lijst van ingekochte of goedgekeurde tools is niet dezelfde lijst als de tools die daadwerkelijk worden gebruikt. Teams nemen AI-functionaliteit in gebruik zonder dat via een aanvraagproces te laten lopen — niet uit onwil, maar omdat het makkelijk toegankelijk is en een probleem oplost. Die schaduw-AI is precies het deel dat een indeling in scope of buiten scope onmogelijk maakt, zolang niemand weet dat de toepassing bestaat.

Wie dat beeld wil vervolledigen, moet ernaar vragen — en dan zonder dat de vraag als een verkapt verwijt aanvoelt. Zodra een medewerker vermoedt dat een eerlijk antwoord tot een sanctie leidt, blijft het antwoord uit en blijft de tool onder de radar. Een inventaris die op afrekening is gebouwd, levert dus per definitie een incompleet beeld op — en een incompleet beeld maakt elke indeling in scope voorlopig.

Vastleggen wat de indeling was, en waarom

Omdat scope kan verschuiven, is het vastleggen van de indeling minstens zo belangrijk als de indeling zelf. Wie besliste dat een toepassing buiten scope viel, op basis van welke informatie, en op welk moment — dat soort vragen wordt onbeantwoordbaar zodra de vastlegging ontbreekt. Hoe een organisatie dat type besluit inrichtbaar en navolgbaar maakt, staat op de pagina over een besluitenlijst die oversightbeslissingen herleidbaar maakt, en hoe die indeling herkenbaar terugkomt in het document dat medewerkers daadwerkelijk raadplegen, op de pagina over een AI-beleid dat aansluit op wat mensen echt doen.

Van indeling naar inhoud van het werk

De indelingsvraag — wat binnen scope valt en wat niet — gaat over risico en verantwoordelijkheid, niet over wat een toepassing voor het werk zelf betekent. Die tweede vraag, wat een taak precies aan AI kan overlaten, is een aparte rekening. De werkscan van FTE TO AI rekent per taak uit welk deel van het werk over te nemen is, los van de vraag hoe die toepassing in de governance-indeling terechtkomt.

Andrewde assistent van de Responsible AI Scan

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.