Binnen veel organisaties bestaat een vaste lijst van toepassingen die "buiten scope" zouden vallen. Een tekstsuggestie in een tekstverwerker, een spamfilter, een chatbot die alleen antwoordt op basis van een vaste FAQ. De aanname is dat deze toepassingen te klein, te oud of te onschuldig zijn om onder governance te vallen. Die aanname klopt soms. Ze klopt niet altijd, en ze klopt zelden blijvend.
Of iets buiten scope valt, is geen eigenschap van de technologie. Het is een indeling die volgt uit wat het systeem doet, voor wie, en met welk effect als het fout gaat. Dezelfde tekstsuggestie die vandaag buiten scope valt omdat ze een medewerker alleen een woord voorstelt, kan morgen binnen scope vallen zodra ze automatisch e-mails afrondt en verstuurt zonder tussenkomst.
Drie factoren bepalen samen of een toepassing binnen of buiten scope valt.
De eerste is de functie: neemt het systeem een besluit, of levert het alleen informatie die een mens beoordeelt? Een tool die sollicitanten rangschikt zit dichter bij scope dan een tool die alleen cv's doorzoekbaar maakt. Op welke plek in dat spectrum een toepassing precies staat en waarom, leest u in de analyse van wat betekent een hoog risiconiveau voor uw organisatie.
De tweede is de rol van de organisatie zelf. Wie een systeem koopt en ongewijzigd gebruikt, staat er anders in dan wie het zelf bouwt, traint of aanpast. Diezelfde toepassing kan voor de ene organisatie buiten scope vallen en voor de andere niet, puur op basis van wie welke verantwoordelijkheid draagt. Deze verdeling wordt uitgewerkt in de vraag of u aanbieder of gebruiker bent, en verandert zodra iemand in de organisatie een model aanpast of hertraint, zoals beschreven in wat er verandert als u een model zelf aanpast.
De derde factor is tijd. Een systeem dat nu buiten scope valt, kan dat een jaar later niet meer zijn, niet omdat de regels veranderd zijn, maar omdat het gebruik veranderde. Een chatbot die begon als informatiebron kan uitgroeien tot een systeem dat klachten afhandelt. De rol van een team of afdeling ten opzichte van zo'n systeem verschuift dan mee, en wanneer dat gebeurt, staat beschreven in wanneer uw rol verandert en waar dat van afhangt.
Het gevolg van deze drie factoren is dat "buiten scope" nooit een permanente status is. Het is een momentopname die opnieuw bekeken moet worden zodra de functie van een systeem verandert, zodra de organisatie een andere rol krijgt ten opzichte van dat systeem, of zodra het gebruik zich uitbreidt naar iets wat bij de aanschaf niet voorzien was.
Dit is precies waar schaduw-AI de indeling verstoort. Een toepassing die op de IT-lijst als "buiten scope" genoteerd staat, kan in de praktijk gebruikt worden op een manier die daar niet meer bij past. Een team dat een taalmodel inzet om klantcommunicatie te concept-schrijven, gebruikt het misschien ook om definitieve antwoorden te versturen zonder daarover te melden. De classificatie op papier en het gebruik in de praktijk lopen dan uiteen, en niemand die alleen naar de ingekochte licenties kijkt, ziet dat verschil.
De enige manier om daar zicht op te krijgen is vragen. Niet aan een systeem, maar aan de mensen die het gebruiken. Dat werkt alleen als vragen stellen niet gelijk staat aan afrekenen: wie bang is voor consequenties, past zijn antwoord aan of geeft er geen. Een indeling die uitsluitend op ingekochte licenties berust, mist daarom systematisch de toepassingen die zijn ontstaan uit praktisch gebruik, en die zijn vaak precies de toepassingen waarvan niemand meer weet of ze nog buiten scope vallen of er inmiddels ver binnen zitten.
De vraag "valt dit buiten scope" kan dus niet los beantwoord worden van de vraag wat er precies gebeurt, wie erover beslist, en hoe lang die situatie al zo is. Een inventaris die deze drie factoren per toepassing vastlegt, levert een indeling op die aansluit bij de werkelijke situatie in plaats van bij de aanname waarmee een systeem ooit werd aangeschaft. Wat daarbij nu al aandacht vraagt en wat rustig gepland kan worden, hangt af van dezelfde factoren en wordt behandeld in het onderscheid tussen wat nu moet en wat gepland kan worden.
Zodra duidelijk is welke toepassingen binnen scope vallen en welke rol uw organisatie daarbij speelt, ontstaat een vervolgvraag die niet over governance gaat maar over werk: welk deel van een taak wordt eigenlijk door zo'n toepassing overgenomen, en welk deel blijft mensenwerk? Die vraag beantwoordt de governance-scan niet. Daarvoor is de werkscan van FTE TO AI bedoeld, die per taak uitrekent welk deel van het werk door AI over te nemen is, en zo een beeld geeft van de inzet die achter de classificatie schuilgaat.
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.