Een leverancier levert een boekhoudpakket, een HR-systeem of een klantenservicetool. Er is een contract, een verwerkersovereenkomst, misschien een beveiligingsaudit. Dan voegt de leverancier in een update een AI-functie toe: automatische classificatie, tekstsuggesties, een chatbot die op uw data is losgelaten. De release notes noemen het een verbetering. Niemand in uw organisatie heeft er iets over te zeggen gehad, omdat niemand wist dat het eraan kwam.
Dit is geen uitzondering op hoe software wordt geleverd. Het is de standaard geworden. Leveranciers concurreren op AI-functionaliteit en bouwen die zo snel mogelijk in, vaak als onderdeel van een abonnement dat u al betaalt. De vraag of dit onder uw bestaande afspraken valt, wordt zelden gesteld voordat de functie live gaat.
Een inkoopafdeling toetst een leverancier bij aanschaf. Daarna verschuift de aandacht naar factuur, uptime en support. Functionele updates lopen buiten dat proces om, want ze vallen onder onderhoud, niet onder een nieuwe aanschaf. Wie zou het moeten melden? De leverancier ziet het als productverbetering. De inkoper ziet de update niet, of ziet hem wel en denkt dat het iemand anders aangaat. De gebruiker in de organisatie merkt vooral dat een knop iets slimmers doet en vraagt zich niet af of daar een taalmodel achter zit dat data extern verwerkt.
Het patroon lijkt op wat er gebeurt bij een browserextensie met toegang tot uw mail: de toegang wordt verleend op een moment dat niemand aan AI dacht, en blijft daarna onopgemerkt actief. Bij leveranciers is het schaalprobleem groter, omdat het niet één medewerker betreft maar een hele organisatie die via één contract wordt blootgesteld.
Een contractuele bepaling die meldingsplicht bij AI-functionaliteit afdwingt, helpt bij nieuwe contracten. Bij bestaande contracten is de bepaling er niet, en het is niet vanzelfsprekend dat een leverancier die met terugwerkende kracht accepteert. Bovendien lost een clausule het detectieprobleem niet op: als niemand periodiek controleert wat een leverancier daadwerkelijk heeft toegevoegd, blijft de melding afhankelijk van de bereidheid van de leverancier om zelf te melden.
Wat wel werkt, is een vaste momentopname: een periodieke inventarisatie van wat elke kernleverancier op dit moment aan AI-functionaliteit levert, losgetrokken van wat bij aanschaf is beoordeeld. Dat is geen juridisch instrument maar een feitelijk overzicht, dat vervolgens getoetst kan worden tegen de risicocategorie van het proces waarin de leverancier opereert.
Dezelfde dynamiek die schaduw-AI bij medewerkers in stand houdt, speelt hier ook, alleen dan op leveranciersniveau. Wie de vraag stelt "gebruiken jullie hier AI voor", wil een eerlijk antwoord, niet een verdedigingsreactie van de accountmanager. Dat betekent dat de vraag niet gesteld moet worden als aanloop naar contractontbinding, maar als onderdeel van een vast proces waarin het antwoord geen consequentie heeft behalve classificatie. Zie hoe dat werkt bij medewerkers die een tool gebruiken die niemand heeft goedgekeurd: de bruikbare informatie komt pas los als vragen stellen losstaat van bestraffen.
Een leverancierslijst is een startpunt, geen eindpunt. Voor elke leverancier die toegang heeft tot productie-data, klantdata of personeelsdata is relevant of er inmiddels AI-functionaliteit inzit, wat die functionaliteit met de data doet, en of dat gebruik binnen dezelfde risicocategorie valt als waarvoor de leverancier oorspronkelijk is goedgekeurd. Een leverancier die vijf jaar geleden is beoordeeld als laag risico omdat hij enkel factureert, kan nu een module draaien die facturen automatisch classificeert op basis van een taalmodel dat extern getraind is. Dat is een andere risicocategorie, ook al staat er dezelfde naam op de factuur.
Deze inventarisatie hoort niet apart te staan van de rest van de AI-governance in een organisatie. Dezelfde classificatie die wordt toegepast op intern gebouwde tools of op een proefopstelling die nooit is uitgezet, hoort ook toegepast te worden op wat leveranciers binnenbrengen. Eén overzicht, één risicoschaal, ongeacht of de AI intern is gebouwd, door een medewerker is meegenomen, of door een leverancier is toegevoegd zonder aankondiging.
Zodra duidelijk is welke AI er via leveranciers binnenkomt, ontstaat een vervolgvraag die verder gaat dan risico alleen: wat doet die AI feitelijk met het werk dat nu door mensen wordt gedaan, en waar overlapt dat met taken die toch al voor automatisering in aanmerking komen. De werkscan van FTE TO AI rekent per taak uit welk deel van het werk door AI over te nemen is, los van welke leverancier of welk systeem dat uiteindelijk uitvoert. Dat maakt de inventarisatie die begint bij risico ook bruikbaar voor de vraag die daarna komt: niet alleen wat er draait, maar wat het werk daadwerkelijk waard is.
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.