Er ligt vaak al een document met de titel escalatieprocedure. Er staat een schema in met pijlen, een rij namen, en een paar drempelwaarden. Het probleem is niet dat het document ontbreekt. Het probleem is dat niemand het opent op het moment dat het nodig is.
Dat gebeurt niet uit onwil. Het gebeurt omdat er al een pad is waarlangs problemen naar boven komen: de lijnmanager die het IT-incident meldt, de compliance-officer die met de business praat, de teamlead die zijn probleem bij zijn eigen leidinggevende neerlegt. Dat pad bestaat, wordt dagelijks gebruikt, en werkt — voor de dingen waarvoor het bedoeld is. Een nieuw escalatiepad specifiek voor AI-incidenten is dan een tweede route naast een route die al loopt. Bij twijfel kiest iedereen de route die hij kent.
Een escalatiepad dat los staat van de bestaande structuur vraagt van de medewerker dat hij eerst herkent dat iets een AI-incident is, dan onthoudt dat daarvoor een ander proces geldt, en dan de moeite neemt dat proces te volgen in plaats van gewoon zijn leidinggevende te bellen. Elke stap in die keten is een moment waarop het pad wordt losgelaten.
Daarbij komt een tweede reden, minder zichtbaar maar net zo bepalend: wie een afwijking meldt, wil niet meteen op het incidentenformulier van de organisatie staan. Als escaleren gelijk staat aan afrekening, wordt er niet geëscaleerd. Dat geldt voor een medewerker die een AI-tool gebruikte die niet was goedgekeurd, en het geldt voor een manager die een model liet draaien zonder dat iemand ervan wist. Een escalatiepad dat wél wordt gebruikt, is een pad waarbij de eerste melding geen oordeel is, maar een signaal.
Een escalatiepad dat werkt, beschrijft drie dingen, en niet meer dan dat.
Wie iets waarneemt — een medewerker, een klant, een externe partij — moet weten bij wie hij terecht kan zonder dat hij eerst moet uitzoeken of het een AI-kwestie is of een gewone operationele kwestie. Het pad sluit aan bij het meldpunt dat al bestaat, met een extra vertakking op het moment dat blijkt dat AI erbij betrokken is.
Wie de beslissing neemt — of iets wordt stopgezet, wordt aangepast, of wordt gemeld aan een toezichthouder — moet vastliggen voordat het incident zich voordoet. Niet als abstracte functietitel, maar als naam, met een vervanger. Escalatie die vastloopt bij een leeg mandaat, is geen escalatie.
Wat er daarna gebeurt met de melder, moet helder zijn. Als een tweede proces alleen bestaat uit een meldplicht zonder duidelijkheid over de consequenties voor wie meldt, wordt het gemeden. Dat is precies waar schaduw-AI zich verbergt: niet in de systemen die IT kent, maar in de tools die iemand is gaan gebruiken zonder dat te melden, omdat melden voelde als bekennen.
De oplossing is niet een dikker document. Het is een escalatiepad dat gebruikmaakt van de structuur die er al is — het meldpunt, de escalatielijn, het risicocomité — en daar een AI-specifieke vertakking aan toevoegt op de punten waar het onderscheid maakt. Hoe dat aansluiten precies werkt, ook voor het bredere beleid en de besluitenlijst van het oversightorgaan, staat beschreven in hoe u een AI-beleid krijgt dat wordt gelezen omdat het is ingebed in wat er al is en in hoe u een oversight-besluitenlijst krijgt die aansluit op het bestaande besluitvormingsritme. Beide documenten raken hetzelfde punt: een proces dat naast de organisatie staat, wordt genegeerd; een proces dat erin ligt, wordt gevolgd.
Dit uitgangspunt geldt niet alleen voor escalatie. Het geldt voor de hele governance-structuur rond AI. Wie wil weten hoe dat er breder uitziet — hoe risicoclassificatie aansluit op bestaande risicocategorieën, hoe aansluiten op de bestaande risicostructuur voorkomt dat er een parallelle bureaucratie ontstaat — vindt daar het onderliggende principe. Hetzelfde geldt voor rapportage naar boven: een board-rapportage van een pagina werkt alleen als de escalaties die erin staan, ook echt zijn gemeld. En zonder doorlopende waarneming van wat er verandert, veroudert elk escalatiepad binnen een jaar; wat dat in de praktijk betekent, staat toegelicht op monitoring die iets oplevert.
Een escalatiepad is pas te schrijven wanneer bekend is wat er kan escaleren. Zolang niemand weet welke AI er in de organisatie draait — inclusief wat niet werd goedgekeurd — blijft het document theoretisch. De Responsible AI Scan begint daarom niet bij het escalatiepad, maar bij de inventaris: wat draait er, wie gebruikt het, en welk risiconiveau past daarbij. Pas op basis daarvan is een escalatiepad te schrijven dat aansluit op wat er al bestaat, in plaats van op wat er op papier zou moeten bestaan.
Escalatiepaden gaan over wat er misgaat met AI die al wordt gebruikt. Een andere vraag, net zo onderbelicht, is waar AI het werk zelf zou kunnen overnemen. De werkscan van FTE TO AI rekent per taak uit welk deel van het werk daarvoor in aanmerking komt, los van de vraag of dat al gebeurt of nog moet worden ingericht.
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.