Informatie voor belanghebbenden: wat Annex A.8 van ISO 42001 vraagt

Een AI-systeem staat nooit op zichzelf. Er zijn gebruikers die ermee werken, klanten die erop vertrouwen, personen over wie het beslissingen neemt en soms toezichthouders die rapportages verwachten. Annex A.8 van ISO 42001 bundelt de eisen die daarover gaan: welke informatie je aan wie verstrekt, hoe belanghebbenden zorgen kunnen melden en hoe je communiceert als het misgaat. In de praktijk is dit een domein waar organisaties punten laten liggen, omdat de aandacht vooral uitgaat naar het bouwen en beheren van de systemen zelf. Dit artikel loopt de vier controls van A.8 langs, met de afwijkingen die wij als auditors het vaakst zien en de documenten die een certificerende instelling wil inzien.

Waar Annex A.8 over gaat

Annex A van ISO 42001 is opgebouwd uit domeinen, van AI-beleid en interne organisatie tot data en leveranciersrelaties. Het domein rond informatie voor belanghebbenden telt vier controls. A.8.2 vraagt om systeemdocumentatie en informatie voor gebruikers. A.8.3 vraagt om mogelijkheden voor externe partijen om nadelige effecten of zorgen te melden, en om grip op je eigen externe rapportageverplichtingen. A.8.4 vraagt om een gedocumenteerd plan voor het communiceren van incidenten. A.8.5 vraagt om het vaststellen en vastleggen van je verplichtingen om informatie over AI-systemen aan belanghebbenden te verstrekken.

Net als bij de andere Annex A-domeinen bepaal je via de risicobeoordeling en de Statement of Applicability of en hoe deze controls van toepassing zijn. Voor A.8 is de uitkomst zelden dat iets buiten scope valt. Elk AI-systeem heeft gebruikers, en vrijwel elk systeem raakt personen of organisaties buiten het eigen team.

A.8.2: documentatie waar een gebruiker iets aan heeft

De eerste control gaat over de informatie die gebruikers van een AI-systeem nodig hebben om er goed mee te werken. Goede gebruikersdocumentatie beschrijft per systeem het doel en het beoogde gebruik, wat het systeem kan en hoe goed het presteert, en net zo belangrijk: waar het niet goed in is. Bekende beperkingen horen erin, net als de situaties waarin het systeem minder betrouwbaar presteert en de risico's die aan het gebruik kleven.

Het element dat auditors het eerst controleren, is de instructie voor menselijk toezicht. Wanneer moet een gebruiker de uitkomst van het systeem beoordelen, hoe herkent hij twijfelgevallen en hoe overrulet hij een AI-beslissing? Documentatie die alleen de functionaliteit beschrijft en zwijgt over beperkingen en toezicht, is de meest voorkomende afwijking in dit domein. De tweede: documentatie die technisch prima is, maar onleesbaar voor de mensen die er dagelijks mee werken. De doelgroep bepaalt de vorm. Een ontwikkelaar heeft andere informatie nodig dan een klantenservicemedewerker die op AI-suggesties leunt.

Documentatie veroudert bovendien. Wie een model bijtraint of een systeem uitbreidt, moet de gebruikersinformatie mee laten veranderen en gebruikers over de wijziging informeren. Versiebeheer op documentatie klinkt bureaucratisch, maar het is precies wat een auditor opvraagt: laat zien dat de documentatie van dit systeem actueel is en dat gebruikers de laatste versie kennen.

A.8.3: meldkanalen en rapportageverplichtingen

De tweede control heeft twee kanten. De eerste is inkomend: belanghebbenden moeten nadelige effecten of zorgen over je AI-systemen kunnen melden. Dat vraagt om een bereikbaar kanaal, intern en extern, en om een proces dat meldingen serieus oppakt. Een meldadres dat niemand uitleest, telt niet.

De tweede kant is uitgaand: je eigen rapportageverplichtingen. Welke rapportages over je AI-systemen ben je aan wie verschuldigd? Denk aan verplichtingen richting toezichthouders, zoals conformiteitsdocumentatie of incidentmeldingen, aan sectorspecifieke afspraken en aan vrijwillige transparantierapportages, bijvoorbeeld een jaarlijks verslag over verantwoorde AI. De veelvoorkomende afwijking hier is simpel: de organisatie heeft nooit geïnventariseerd wat ze moet rapporteren. Een register van externe rapportageverplichtingen met een kalender erachter lost dat op. Rapportages die de deur uitgaan, horen daarnaast een controle- en goedkeuringsronde te krijgen, zodat er geen cijfers naar buiten gaan die niemand heeft geverifieerd.

A.8.4: een communicatieplan voor incidenten

Incidenten met AI-systemen afhandelen is één ding. Erover communiceren is een tweede, en dat is waar A.8.4 over gaat. De control vraagt om een gedocumenteerd plan dat vastlegt hoe je incidenten communiceert naar de gebruikers van het systeem en andere betrokkenen.

Een werkbaar plan begint met classificatie: welke ernstniveaus onderscheid je, en welke typen incidenten horen daarbij? Juist de AI-specifieke categorieën ontbreken vaak: geconstateerde bias, schadelijke output, een model dat stilletjes slechter is gaan presteren. Per niveau leg je vast wie geïnformeerd wordt: alleen intern escaleren, of ook klanten, getroffen personen of een toezichthouder. Daarbij horen termijnen die aansluiten op wettelijke eisen, afspraken over de inhoud van de communicatie (wat is er gebeurd, wat is de impact, wat doe je eraan) en een goedkeuringsroute langs management en waar nodig juridische toetsing.

De afwijking die wij het vaakst zien: er is een incidentproces, maar communicatie zit er niet in. Bij een oefening of een echt incident blijkt dan dat niemand weet wie de klantcommunicatie opstelt en wie die mag versturen. Een tabletop-oefening rond een fictief AI-incident legt dat genadeloos bloot, en is meteen het bewijs van werking dat een auditor graag ziet.

A.8.5: weten wat je aan wie moet vertellen

De laatste control van het domein vraagt om het vaststellen en documenteren van je verplichtingen om informatie over AI-systemen aan belanghebbenden te verstrekken. In de praktijk komt dat neer op drie lagen.

De eerste laag is het individu dat met een AI-systeem te maken krijgt. Wie chat met een bot of onderworpen wordt aan een geautomatiseerde beoordeling, hoort dat te weten, op het moment zelf en in begrijpelijke taal. Daarbij hoort informatie over rechten: kan iemand een menselijke beoordeling vragen, uitleg krijgen over een beslissing, of die aanvechten? De afwijking die hier het meest voorkomt: personen worden simpelweg niet geïnformeerd dat AI een rol speelt in een beslissing die hen raakt.

De tweede laag zijn klanten en partners. Wie AI verwerkt in een product of dienst, moet afnemers daarover informeren, zodat zij hun eigen afwegingen en verplichtingen kunnen invullen.

De derde laag is het publiek. Steeds meer organisaties publiceren een pagina of rapport over hun omgang met AI: welke principes ze hanteren, welke typen systemen ze inzetten en hoe de governance is belegd. Verplicht is dat niet in alle gevallen, maar het is een sterk signaal richting auditor en markt dat de informatievoorziening proactief is geregeld in plaats van reactief, alleen op verzoek.

Voor organisaties die met de EU AI Act te maken hebben, ligt hier een natuurlijk koppelvlak. De wet kent eigen transparantieverplichtingen, bijvoorbeeld de plicht om personen te informeren dat ze met AI interacteren. Wie A.8.5 op orde heeft, heeft het fundament voor die verplichtingen al liggen. Met onze zelfassessment op /ai-act-check toets je welke AI Act-verplichtingen op jouw organisatie van toepassing zijn.

Wat de auditor wil zien

Wie zich op een certificeringsaudit of interne audit voorbereidt, kan per control aan de volgende bewijslast denken. Voor A.8.2: gebruikersdocumentatie of model cards per systeem, instructies voor menselijk toezicht en bewijs dat documentatie wordt bijgehouden en gecommuniceerd. Voor A.8.3: een register van rapportageverplichtingen, verzonden rapportages met goedkeuringssporen en een werkend meldkanaal. Voor A.8.4: het communicatieplan, classificatiecriteria en, als er incidenten zijn geweest, de verzonden communicatie met tijdlijnen. Voor A.8.5: de vastgelegde informatieverplichtingen, meldingen richting gebruikers, informatie over rechten van betrokkenen en eventuele publieke informatie over je AI-governance.

De rode draad in dit domein: het gaat niet om de vraag of je documenten hebt, maar of de informatie de juiste mensen bereikt in een vorm die zij begrijpen. Een auditor die A.8 toetst, spreekt daarom niet alleen de AI-governance-functie, maar ook een gebruiker. Als die niet weet wat het systeem wel en niet kan, schiet de mooiste documentatie tekort.