Wie is waarvoor verantwoordelijk in de AI-keten? Annex A.10 van ISO 42001

Zodra er iets misgaat met een AI-systeem komt dezelfde vraag boven: wie had dit moeten zien? De leverancier die het model traint, de partij die de data levert, of de organisatie die het systeem in haar eigen proces heeft ingezet. In de meeste contracten staat het antwoord niet, en in de contracten waar het wel staat, blijkt het bij nader inzien over beschikbaarheid en beveiliging te gaan en niet over modelgedrag. Annex A.10 van ISO/IEC 42001 gaat precies hierover.

Wat Annex A.10 dekt

Het domein bestaat uit drie controls. A.10.2 vraagt dat verantwoordelijkheden binnen de levenscyclus van je AI-systemen worden verdeeld tussen de organisatie, haar partners, leveranciers, klanten en andere derden. A.10.3 vraagt om een proces dat borgt dat het gebruik van diensten, producten of materialen van leveranciers past bij je eigen aanpak van verantwoorde ontwikkeling en inzet van AI. A.10.4 vraagt dat je in die aanpak rekening houdt met de verwachtingen en behoeften van je klanten.

Drie controls, twee kanten van de keten: wat je inkoopt en wat je levert. Organisaties richten bijna altijd de eerste kant in en vergeten de tweede.

Verantwoordelijkheden verdelen: welke activiteiten precies

Een verantwoordelijkheidsverdeling die alleen zegt dat de leverancier verantwoordelijk is voor het model en de klant voor het gebruik, lost niets op. De verdeling wordt bruikbaar zodra je hem per activiteit maakt.

Vijf onderwerpen horen er in elk geval in. Wie voert de risicobeoordeling uit en wie implementeert de maatregelen die daaruit volgen. Wie is verantwoordelijk voor datakwaliteit, herkomst van data en naleving van privacyregels. Wie valideert het model, wie meet de prestaties en wie signaleert drift. Wie detecteert een incident, wie meldt het aan wie, en binnen welke termijn. En wie voldoet aan welke regelgevende verplichting, wat vooral speelt wanneer de ene partij aanbieder is en de andere gebruiker onder de EU AI Act.

Gedeelde verantwoordelijkheden zijn het lastigste onderdeel. Het klassieke gat: beide partijen gaan ervan uit dat de ander op bias monitort. Bij gedeelde taken hoort daarom altijd één partij die eigenaar is, ook als beide iets doen.

Wat je vastlegt en waar

De verdeling hoort in het contract of de verwerkersovereenkomst thuis, aangevuld met een verantwoordelijkheidsmatrix per AI-systeem. Generieke IT-dienstverleningsovereenkomsten dekken dit niet: die gaan over beschikbaarheid, support en beveiliging, niet over modelvalidatie of biasmonitoring. Ontbrekende AI-governanceafspraken in leverancierscontracten is een van de vaakst geconstateerde afwijkingen bij A.10.2.

Werk de matrix bij als de relatie of het systeem verandert. Een leverancier die van een eigen model naar een onderliggend model van een derde overstapt, verandert de keten, en daarmee de verdeling.

Leveranciers: verder dan de standaard vragenlijst

A.10.3 vraagt om een proces, niet om een eenmalige beoordeling. Bij aanvang beoordeel je de AI-governancevolwassenheid van de leverancier, zijn omgang met data, zijn beveiliging en zijn naleving van regelgeving. In het contract komen eisen over transparantie, prestatiegaranties, afspraken over biastesten, meldplicht bij incidenten en auditrechten. Daarna volgt monitoring: periodieke prestatiebeoordeling, herbeoordeling bij wijzigingen en diepgaandere toetsing van de leveranciers die er het meest toe doen.

Neem ketenrisico expliciet mee. Afhankelijkheid van één modelaanbieder, het risico dat toegang tot een modelversie vervalt en verslechterende datakwaliteit bij een dataleverancier zijn risico's die zich niet laten oplossen met een clausule. Daar horen scenario's en uitwijkopties bij. Voor de inrichting van de beoordeling zelf is het bestaande derdepartijenbeheer het startpunt; A.10.3 voegt daar de AI-specifieke eisen aan toe.

Klanten: de kant die meestal ontbreekt

A.10.4 is de control waar organisaties het vaakst op worden aangesproken tijdens de audit, omdat er zelden iets ligt. Lever je een product of dienst met AI erin, dan hebben je klanten informatie nodig om die verantwoord te gebruiken.

Concreet betekent dat: benoemen dat er AI in zit en waar. Beschrijven wat het systeem kan en, belangrijker, wat het niet kan en waarvoor het niet bedoeld is. Aangeven welk menselijk toezicht je van de klant verwacht en waarom. De bekende risico's en beperkingen benoemen, inclusief de omstandigheden waarin de prestaties teruglopen. En vastleggen hoe een klant een probleem meldt en wat hij daarna van je mag verwachten.

Er is een tweede reden om dit goed te doen. Klanten die jouw AI-systeem inzetten hebben zelf verplichtingen, bijvoorbeeld als gebruiker onder de EU AI Act. Zonder documentatie van jou kunnen ze daar niet aan voldoen, en dan komt die vraag alsnog bij jou terecht, meestal in een inkooptraject onder tijdsdruk. Een modelbeschrijving, een overzicht van beperkingen en een korte handleiding voor verantwoord gebruik schelen later veel losse vragenlijsten.

Wat een auditor vraagt

Hoe zijn de verantwoordelijkheden verdeeld tussen jou en je AI-leveranciers, en waar staat dat? Hoe controleer je dat een derde partij zijn deel ook echt doet? Welke informatie geef je klanten over de AI in je product, en wie beoordeelt of die informatie nog klopt? Hoe worden door klanten gemelde AI-problemen geregistreerd en opgevolgd? En bij een wijziging in de keten: wanneer is de verdeling voor het laatst herzien?

Op dat laatste punt struikelt het vaak. De matrix is een jaar geleden gemaakt, de leverancier heeft sindsdien twee modelversies uitgerold en er is een nieuwe dataleverancier bijgekomen.

Afwijkingen die auditors noteren

Bij A.10.2: verantwoordelijkheden die niet in contracten zijn belegd, gedeelde taken zonder eigenaar, en geen enkele verificatie of de derde partij zijn afspraken nakomt. Bij A.10.3: geen AI-specifieke due diligence, contracten zonder eisen over transparantie of biastesten, geen leveranciersregister en geen beoordeling van ketenrisico. Bij A.10.4: klanten die niet weten dat er AI in het product zit, documentatie zonder beperkingen en zonder de vereiste vorm van menselijk toezicht, en klantmeldingen die nergens worden bijgehouden.

Documenten die je klaarlegt

Contracten met AI-governanceafspraken, verantwoordelijkheidsmatrices per AI-systeem, de procedure voor leveranciersbeheer, dossiers van uitgevoerde due diligence, een leveranciersregister met risicoclassificatie, monitoringrapportages, de klantdocumentatie met beperkingen en gebruiksvoorwaarden, en het register van klantmeldingen over AI.

Begin bij de systemen die je aan klanten levert. De leverancierskant heb je waarschijnlijk deels staan vanuit je bestaande derdepartijenbeheer; de klantkant staat er in de meeste organisaties helemaal niet, en die kost het meeste tijd om alsnog op te bouwen.