Elke organisatie met enige omvang heeft al een risicostructuur. Een risicocomité, een auditfunctie, een lijn van rapportage naar het bestuur, een format waarin risico's worden ingeschaald en gevolgd. Wie daar een nieuw proces naast zet, specifiek voor AI, met een eigen comité, een eigen kalender en een eigen taal, krijgt binnen een jaar een proces dat niemand meer invult. Niet omdat AI niet belangrijk wordt gevonden, maar omdat een tweede structuur concurreert met de eerste om tijd, aandacht en mandaat. De bestaande structuur wint bijna altijd, want die is ingebed in beoordelingen, functioneringscycli en bestuursagenda's. De nieuwe structuur staat erbuiten.
De vraag is dus niet hoe u een AI-governancestructuur bouwt. De vraag is hoe AI een plek krijgt in de structuur die er al is.
De meeste risicostructuren kennen al een aantal vaste onderdelen: een risico-inventarisatie die periodiek wordt bijgewerkt, een classificatie naar ernst en waarschijnlijkheid, een eigenaar per risico, een escalatielijn naar een hoger niveau als een grens wordt overschreden, en een rapportage aan het bestuur op vaste momenten. Dat is de structuur waarin AI moet passen, niet naast.
Dat betekent dat een AI-toepassing niet in een apart AI-register hoort te staan, maar als risico-item in het bestaande register, met dezelfde velden als elk ander risico: eigenaar, ernst, waarschijnlijkheid, mitigatie, statusdatum. De classificatie naar risiconiveau die bij een inventaris van AI-gebruik horen, moet aansluiten op de schaal die al wordt gebruikt voor operationeel risico, niet op een nieuwe schaal die alleen voor AI is uitgevonden. Wie wat een cio moet weten over ai-risico leest, ziet dat die aansluiting precies is waar het vaak misgaat: een technisch correcte AI-risicoscore die niemand kan vergelijken met de rest van het risicoregister.
Twee dingen maken inbedding lastig. Het eerste is taal. Risicomanagers werken met begrippen als impact, waarschijnlijkheid en mitigerende maatregel. AI-leveranciers en technische teams werken met modelversies, trainingsdata en prestatiemetrieken. Een governance-set die alleen in de technische taal is geschreven, wordt door het risicocomité niet gelezen. Een governance-set die alleen in risicotaal is geschreven, wordt door de technische eigenaar niet ingevuld. De set moet in beide richtingen leesbaar zijn: technisch genoeg om te kloppen, bestuurlijk genoeg om te landen. Dat principe komt terug bij een ai-beleid dat gelezen wordt: een document dat aansluit op hoe mensen al lezen en beslissen, in plaats van een nieuwe leeswijze te vergen.
Het tweede is tempo. Een risicocomité vergadert op een vaste cyclus, vaak kwartaal of maand. AI-gebruik verandert sneller: een team begint deze week met een nieuwe tool, zonder dat daar een vergadering aan voorafgaat. De governance-set moet daarom niet afhankelijk zijn van de vergadercyclus om te functioneren. Er moet een lichter mechanisme zijn dat afwijkingen opvangt tussen de vaste momenten door, en dat pas bij de volgende cyclus formeel wordt bevestigd. Hoe dat mechanisme in de praktijk werkt, staat beschreven bij escalatiepaden die werken: een route die kort genoeg is om gebruikt te worden voordat het volgende kwartaalcomité samenkomt.
Een governance-set die aansluit op een bestaande risicostructuur bevat op hoofdlijnen: een inventarisitem per AI-toepassing met eigenaar en risicoklasse, een koppeling naar het bestaande escalatiepad zodat een afwijking niet in een apart kanaal verdwijnt, en een vaste plek in de periodieke rapportage aan het bestuur. Niet als apart hoofdstuk over AI, maar als regel in de tabel die het bestuur al kent. Hoe die rapportage eruit kan zien zonder een nieuw format te introduceren, staat bij hoe krijgt u een board-rapportage van een pagina ingebed in wat er al circuleert.
De inhoud van de regels zelf, wat precies onder welk risiconiveau valt en welke termijnen daarbij horen, staat elders vastgelegd en verandert; deze pagina gaat over het mechanisme dat die inhoud een plek geeft in de bestaande structuur, niet over de tekst van die regels.
Inbedding lukt alleen als de inventaris eerst klopt. En die klopt alleen als mensen durven zeggen wat ze gebruiken. Wie bij het invullen van het risico-item voelt dat een eerlijk antwoord tot een aantekening in een beoordeling leidt, vult het niet eerlijk in. De governance-set moet daarom vanaf de eerste versie duidelijk maken dat het doel overzicht is, niet sanctie. Zonder die toezegging blijft een deel van het gebruik buiten beeld, en is de aansluiting op de risicostructuur gebouwd op een incomplete lijst. Wat een bestuurder daarover moet weten voordat de eerste inventarisatie start, staat bij wat moet een bestuurder weten over ai-risico.
Deze inbedding gaat over risico, eigenaarschap en rapportage: het zorgt dat wat AI doet, zichtbaar en beheersbaar is binnen de structuur die er al staat. Een andere vraag, die daar logisch op volgt zodra het overzicht er is, is wat AI binnen dat werk daadwerkelijk kan overnemen. De werkscan van FTE TO AI rekent per taak uit welk deel van het werk door AI over te nemen is, als vervolgstap nadat de governance-kant op orde 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.