Een escalatiepad voor AI-incidenten dat naast de bestaande structuur wordt neergelegd, wordt in de praktijk overgeslagen. Niet omdat niemand het wil gebruiken, maar omdat er al een pad is: voor datalekken, voor klachten, voor operationele storingen. Wie op het moment van een incident moet kiezen tussen twee routes, kiest de route die hij al kent. Een tweede proces naast het eerste is geen extra zekerheid, het is een vertakking die bij de eerste onder druk verdwijnt.
De vraag is niet of er een escalatiepad moet zijn. De vraag is waar het inhaakt. Een escalatiepad voor AI werkt wanneer het geen nieuw loket opent, maar een bestaand loket een extra ingang geeft. Dat betekent: dezelfde meldstructuur die al gebruikt wordt voor incidenten, aangevuld met een vraag die aangeeft of AI een rol speelde. Dezelfde eigenaar die al verantwoordelijk is voor risico-afhandeling, met een duidelijk beeld van wanneer een AI-gerelateerd signaal bij hem terecht moet komen. Dezelfde rapportagelijn naar boven, zonder een aparte AI-lijn ernaast.
Wat erin hoort, is daarmee minder een lijst met stappen en meer een set aansluitpunten: wie meldt, waar het binnenkomt, wie beoordeelt of het escaleert, en naar wie. Bij elk van die punten is de vraag niet "hoe zou dit moeten werken" maar "waar gebeurt dit al, en wat moet daar aan toegevoegd worden om AI mee te nemen". Een escalatiepad dat op die manier is opgebouwd, heeft geen aparte instructie nodig, omdat het geen ander gedrag vraagt dan wat al bekend is.
Er is een herkenbaar patroon: een organisatie maakt een AI-specifiek proces, met een eigen formulier, een eigen commissie, een eigen rapportagemoment. Op papier is dat compleet. In de praktijk wordt het genegeerd, en niet uit onwil. Een tweede proces vraagt dat iemand op het moment van een incident eerst bepaalt of het om AI gaat voordat hij weet welke weg te volgen. Die extra stap valt weg zodra er tijdsdruk is, en het bestaande pad — het pad dat toch al gebruikt wordt voor vergelijkbare situaties — wint.
Daar komt bij dat een los AI-proces meestal een aparte eigenaar krijgt, los van degene die al verantwoordelijk is voor risico-escalatie in het algemeen. Dat splitst het overzicht op een moment waarop overzicht nodig is. Wie een signaal ontvangt over een AI-systeem dat niet werkt zoals bedoeld, moet dat kunnen plaatsen naast andere risicosignalen, niet in een geïsoleerd kanaal waar het los van de rest van de organisatie wordt beoordeeld.
Inbedden betekent dat het escalatiepad voor AI geen zichtbaar apart onderdeel is, maar een uitbreiding van wat al bestaat. Dat vraagt om een paar concrete keuzes, ongeacht de sector: welk bestaand meldkanaal krijgt de vraag over AI-betrokkenheid toegevoegd, welke bestaande risico-eigenaar krijgt de bevoegdheid om te beoordelen of iets verder moet, en op welk bestaand rapportagemoment wordt AI meegenomen in plaats van er een nieuw moment naast te zetten.
Die keuzes hangen af van hoe de organisatie al is ingericht. Een organisatie met een sterke compliance-functie legt de beoordeling daar; een organisatie waar risicomanagement is ondergebracht bij de operationele lijn, legt het daar. Er is geen vast schema dat voor elke organisatie hetzelfde escalatiepad oplevert, omdat het escalatiepad per definitie een afspiegeling is van de structuur waarin het wordt gelegd.
Deze inbedding raakt aan hoe risico's al worden ingedeeld — hoe dat aansluiten op de bestaande risicostructuur eruitziet, is uitgewerkt op de pagina over aansluiten bij bestaande risicoclassificatie — en aan wat er met een escalatie gebeurt zodra die de bestuurstafel bereikt, zoals beschreven op de pagina over een board-rapportage die op één pagina past. Zonder die aansluiting blijft een escalatiepad een document dat ergens ligt, in plaats van een route die iemand daadwerkelijk volgt op het moment dat het nodig is.
Een escalatiepad is pas nuttig als er iets is dat escaleert. Dat vraagt een vorm van monitoring die signalen oplevert voordat een incident zich voltrekt, niet alleen een reconstructie achteraf. Hoe dat monitoring-onderdeel wordt ingericht zonder dat het een nieuwe rapportagelast wordt, staat op de pagina over monitoring die aansluit op bestaande rapportage in plaats van een nieuwe laag toe te voegen. Samen vormen inventarisatie, monitoring en escalatie een keten: zonder een van de drie werkt de rest ook niet volledig.
Wie deze route uittekent, doet dat meestal vanuit een rol met verantwoordelijkheid voor risico of governance. Wat een bestuurder in dit verband moet weten, staat samengevat op de pagina wat een bestuurder moet weten over AI-risico; de technische en operationele kant van dezelfde vraag is te vinden op de pagina wat een CIO moet weten over AI-risico. Beide invalshoeken komen samen in het escalatiepad zelf, dat werkt op het snijpunt van bestuurlijke verantwoordelijkheid en operationele uitvoering.
Deze pagina beschrijft het mechanisme; de precieze inrichting hangt af van de organisatie en wordt niet hier vastgelegd. FTE TO AI werkt aan gereedschap dat deze inbedding ondersteunt; wie hier nu al mee bezig is, kan zich aanmelden voor de wachtlijst.
Een escalatiepad regelt wat er gebeurt zodra iets misgaat of dreigt mis te gaan. Een andere vraag, die er vaak los naast blijft staan, is wat AI dagelijks al doet in het gewone werk. De werkscan van FTE TO AI rekent per taak uit welk deel van het werk over te nemen is door AI, en geeft daarmee een beeld van de kant van AI-gebruik die niet incidenteel is, maar structureel — een beeld dat nuttig is naast de risico-inventarisatie waar deze pagina over gaat.
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.