Je AI-inventaris is waarschijnlijk groter dan je lijst met chatbots

Vraag een directieteam welke AI ze gebruiken en je krijgt een kort lijstje. ChatGPT. Copilot. Misschien Claude of Gemini. Iemand noemt een proef bij marketing.

Kijk daarna naar wat de organisatie werkelijk draait. Het beveiligingsplatform scoort meldingen met een model. Het wervingssysteem rangschikt kandidaten. De servicedesk stelt antwoorden voor. Het CRM voorspelt welke klanten opzeggen. En een leverancier heeft in zijn laatste release een samenvatfunctie toegevoegd, aangekondigd in een changelog die niemand las.

Niets daarvan kwam binnen als besluit. Het kwam binnen als functie.

Je kunt geen AI besturen waarvan je niet weet dat je hem gebruikt. Dat is geen governance-spreuk maar de reden dat de meeste AI-trajecten in maand twee stilvallen. Het beleid staat er, de werkgroep vergadert, en niemand kan de eerste vraag van een auditor beantwoorden: waar zit het, en wat doet het?

De meeste AI was nooit een besluit

Dat weegt zwaarder dan het klinkt. Komt AI binnen via inkoop, dan is er een moment waarop iemand vragen kan stellen. Komt hij binnen via een release, dan is dat moment er niet.

Het resultaat is een AI-landschap dat groeide zonder risicoanalyse, zonder eigenaar, en vaak zonder dat iemand bij security wist dat er iets veranderde. Je eigen beveiligingstooling is trouwens een goede plek om te beginnen: dat is vaak de meest AI-rijke software in het gebouw, en de minst waarschijnlijke kandidaat op iemands AI-lijst.

Inventariseer geen tools maar use cases

Er zit een wezenlijk verschil tussen twee vragen. “Gebruiken we Microsoft Copilot?” levert een licentieoverzicht. “Waar beïnvloedt AI onze data, mensen, besluiten of operatie?” levert iets waar je op kunt sturen.

Eén tool kan vijf use cases herbergen met totaal verschillend risico. Dezelfde assistent die interne verslagen schrijft, stelt misschien ook klantbrieven op en vat personeelsdossiers samen. Zelfde licentie, zelfde leverancier, drie gesprekken die je apart moet voeren.

Inventariseer de use case, niet het logo op de factuur.

Wat hoort er in een AI-inventaris?

Een bruikbare inventaris beantwoordt vier vragen per use case. Geen achttien velden omdat een sjabloon dat zei — vier vragen die, eerlijk beantwoord, laten zien of je een probleem hebt.

Wie is eigenaar, en wie gebruikt het

Elke wezenlijke use case heeft een eigenaar met naam: iemand die verantwoordelijk is voor het doel, het risico en of het ding blijft draaien. Geen afdeling. Een persoon. Leg ook vast wie het feitelijk gebruikt — vaak een bredere groep dan bedoeld — en welke processen ervan afhangen.

Welke data erin gaat

Wat gaat erin, en waar komt het vandaan? Persoonsgegevens, klantgegevens, broncode, contracttekst, incidentinformatie. De invoer bepaalt het grootste deel van je privacy- en vertrouwelijkheidsrisico, en het is het veld dat het slordigst wordt ingevuld.

Waar de data heen gaat

Welk model of welke aanbieder verwerkt het, verlaat het de organisatie, welke derde partijen ontvangen het, en waar belandt de uitvoer. Daarover hieronder meer, want dit is het deel waar de meeste inventarissen misgaan.

Hoe ver het zelfstandig kan gaan

Informeert het, adviseert het, beslist het, of handelt het? Kan de uitvoer een ander systeem in gang zetten? Zit er een mens tussen de uitvoer en het gevolg — en heeft die mens de informatie én het mandaat om nee te zeggen?

De volledige veldenlijst is langer, en die hoort in een document dat je invult, niet in een artikel dat je leest. Daar is de Quick Check voor.

Volg de data, niet het model

De meeste gesprekken over AI-governance blijven hangen bij het model. Het interessante risico zit meestal in de keten eromheen. Volg hem van begin tot eind: invoer → verwerking → model of aanbieder → uitvoer → besluit of actie.

Bij elke stap één vraag:

• Welke data gaat erin, en waar komt die vandaan?
• Waar wordt het verwerkt, en verlaat het de organisatie?
• Welke derde partijen zien het, inclusief subverwerkers waarmee je nooit rechtstreeks een contract sloot?
• Wat komt eruit, en waar wordt die uitvoer gebruikt?
• Kan die uitvoer een ander systeem aansturen zonder dat er een mens aan te pas komt?

Die laatste is waar governance en security elkaar raken. Een AI die een ticket aanmaakt, een mail verstuurt, een firewallregel wijzigt of een record bijwerkt, is van adviseren naar handelen gegaan — en het risicoprofiel is meeverhuisd.

Autonomie bepaalt het risico

Hieronder een eenvoudige opbouw die wij in de praktijk gebruiken. Het is een CyberBusters-model om toenemende autonomie uit te leggen, geen ISO-terminologie en geen indeling die enige norm voorschrijft.

• Informeren — samenvatten, opzoeken, uitleggen. Risico: iemand handelt naar een verkeerde samenvatting.
• Adviseren — stelt een handelwijze voor. Risico: het advies wordt gevolgd zonder toetsing.
• Beslissen — neemt binnen kaders zelf het besluit. Risico: een fout besluit, snel en op schaal.
• Handelen — zet iets in gang in een ander systeem. Risico: het gevolg is er vóór iemand meekijkt.

Twee systemen kunnen hetzelfde model gebruiken en twee niveaus uit elkaar liggen. De vraag is nooit “hoe goed is het model” maar wat kan het doen zonder te vragen.

Dezelfde techniek, vier andere risico's

Neem één samenvatmodel en zet het op vier plekken. Interne verslagen samenvatten is vooral een kwaliteitsprobleem. Klachten samenvatten voor een rapportage aan een toezichthouder is een compliancevraagstuk. Cv's samenvatten tot een shortlist raakt arbeidsrecht en gelijke behandeling. En beveiligingsmeldingen samenvatten om te bepalen wat opgeschaald wordt is operationeel — want wat het weglaat ziet niemand.

Zelfde techniek. Vier verschillende beoordelingen. Daarom zegt een risicoregister op tool-niveau vrijwel niets, en een register op use case-niveau precies waar je aandacht heen moet.

Beoordeel gevolgen voor mensen, bedrijfsvoering, security, privacy, juridische en toezichtrisico's, reputatie, financiën, veiligheid waar dat speelt, en continuïteit — wat gebeurt er met het proces als de AI maandag simpelweg niet beschikbaar is.

Menselijk toezicht is een maatregel, geen slogan

“Er zit een mens tussen” is de meest herhaalde en minst getoetste uitspraak in AI-governance. Ertussen zitten is niet hetzelfde als kunnen ingrijpen.

Toezicht is operationeel als je dit kunt beantwoorden:

• Wanneer is toetsing verplicht — altijd, boven een drempel, bij uitzonderingen?
• Wie doet dat, en heeft die persoon de positie om het oneens te zijn?
• Wat ziet die persoon: alleen de uitvoer, of ook de invoer en de onderbouwing?
• Kan de uitvoer afgewezen worden, en houdt die afwijzing het ook echt tegen?
• Kan een actie teruggedraaid worden nadat hij is begonnen?
• Kan het systeem gestopt worden — en wie heeft die knop?
• Wordt het besluit vastgelegd, zodat je het later kunt reconstrueren?

Een beoordelaar die alleen de uitvoer ziet, onder tijdsdruk, zonder route naar escalatie, is een stempel met een functietitel.

Je hebt het model niet in de hand

AI-governance houdt niet op bij je eigen grens. Externe modellen, AI-functies in SaaS, API's, modelaanbieders en hun subverwerkers horen erbij, en vrijwel niets daarvan beweegt op jouw tempo.

Wat gebeurt er als het model, de aanbieder of de AI-functionaliteit verandert zonder dat jouw organisatie daartoe besloot?

Een aanbieder zet een modelversie uit. De kwaliteit van de uitvoer verschuift. Een functie waarvan je afhankelijk bent verhuist naar een duurder abonnement. Een leverancier wijzigt zijn lijst met subverwerkers. Een API is zes uur uit de lucht in je drukste week.

Geen van die dingen is jouw besluit, en allemaal zijn ze jouw probleem. Leg de afhankelijkheid vast zoals je elk ander concentratierisico bij een leverancier vastlegt, want dat is precies wat het is.

Wat verandert er, en wie ziet dat

AI-systemen schuiven op manieren waarop gewone software dat niet doet. Twee vragen houd je uit elkaar: doet het nog wat het hoorde te doen — kwaliteit, fouten, drift — en heeft iemand er iets aan veranderd — model, prompts, koppelingen, autonomie, beoogd gebruik.

Die tweede is de stille. Een systeem dat is goedgekeurd om te adviseren en later is ingericht om te handelen, is een nieuw systeem met de goedkeuring van het oude. Wezenlijke wijziging hoort een herbeoordeling uit te lokken, en iemand moet eigenaar zijn van het opmerken ervan.

Van inventaris naar governance

De volgorde die wij aanhouden is bewust weinig spannend: ontdekken → indelen → beoordelen → beheersen → monitoren → herzien. Ontdek wat er is. Deel in naar use case, data en autonomie. Beoordeel het risico per use case. Zet maatregelen in verhouding tot dat risico. Kijk of het zich nog gedraagt zoals bedoeld. Herzie als er iets verandert.

Een inventaris is stap één. Het is geen governancesysteem, en een spreadsheet is geen antwoord aan een toezichthouder. Maar niets ná stap één werkt zonder.

Waar ISO/IEC 42001 binnenkomt

ISO/IEC 42001 is een managementsysteemnorm voor kunstmatige intelligentie. Hij beschrijft hoe een organisatie een systeem voor het besturen van AI opzet, laat werken en verbetert — dezelfde denklijn als ISO/IEC 27001 voor informatiebeveiliging, toegepast op wat bij AI specifiek anders is.

Hij wordt relevant op een herkenbaar moment: als je meer AI-use cases hebt dan één persoon kan onthouden, als iemand van buiten begint te vragen hoe je ze bestuurt, of als het antwoord een personeelswissel moet overleven.

Een paar eerlijke grenzen. De norm schrijft niet de velden uit dit artikel voor, niet het autonomiemodel hierboven, en geen specifieke scoremethode — dat zijn praktische keuzes, geen eisen. En een inventaris, hoe goed ook, is geen AI-managementsysteem. Het is één invoer voor één onderdeel daarvan.

Tien vragen voor deze week

1. Weten we waar AI wordt gebruikt, en waarvoor?
2. Heeft elke wezenlijke use case een eigenaar met naam?
3. Kennen we de datastromen erin en eruit?
4. Weten we hoe autonoom elke use case is?
5. Zijn de risico's beoordeeld voor de use case, niet voor de tool?
6. Is menselijk toezicht ingericht in verhouding tot risico en autonomie?
7. Kennen we onze afhankelijkheid van modellen, platforms en leveranciers?
8. Controleren we of het systeem nog doet wat het hoort te doen?
9. Worden wezenlijke wijzigingen beheerst en opnieuw beoordeeld?
10. Kunnen we met bewijs laten zien hoe het systeem wordt bestuurd?

Word je bij meer dan drie ongemakkelijk, dan is dat bruikbare informatie — en het normale startpunt, geen onvoldoende. Vul hem bij voorkeur met iemand uit een ander vakgebied erbij: alleen ingevuld wordt het een zelfbeoordeling, met z'n tweeën wordt het een gesprek.

Waar te beginnen

Begin bij ontdekken, en kleiner dan bevredigend voelt. Pak de tien use cases waar AI klanten, personeelsbesluiten, geld of security raakt, en beantwoord daarvoor de vier vragen. Je leert in één middag meer dan in een kwartaal beleidswerk.

Wil je van losse AI-maatregelen naar een gestructureerd AI-managementsysteem? Dan is ISO/IEC 42001 het kader waar je naartoe werkt, en begint het bij precies dezelfde ontdekfase. Zo pakken wij dat aan bij AI-governance en ISO 42001; loop je het liever een keer door tegen je eigen situatie, neem dan gerust contact op.