Is de AI-leverancier die je op het punt staat te adopteren betrouwbaar? SOC 2, ISO 42001 en wat je vraagt voor je tekent

Wanneer een mkb-bedrijf AI adopteert, bouwt het bijna nooit het model: het adopteert een tool — een salescopiloot, een agentplatform voor de klantenservice, een contentgenerator. En die tool is in de overgrote meerderheid van de gevallen een SaaS van derden, vaak Amerikaans. Voor je tekent is de juiste vraag er maar één: «kan ik deze leverancier vertrouwen?». Het antwoord dat je krijgt is bijna altijd hetzelfde: «we zijn SOC 2 Type II gecertificeerd». Het klinkt geruststellend. Maar sluit het de kwestie echt af?

Het eerlijke antwoord is nee — niet op zichzelf. SOC 2 zegt iets nuttigs, maar het zegt veel minder dan het woord «gecertificeerd» laat vermoeden, en over alles wat specifiek de AI betreft zegt het bijna niets. Dat is de moeite waard om te begrijpen voor je een stuk van je proces — en je gegevens — aan een leverancier toevertrouwt.

Wat SOC 2 echt is (en wat niet)

Eerste misverstand om uit de weg te ruimen: SOC 2 is geen wet. Het is een attest, afgegeven door een onafhankelijke auditor volgens een schema van de AICPA (de Amerikaanse beroepsorganisatie van accountants), dat de controles van een leverancier meet aan vijf Trust Services Criteria: beveiliging (altijd binnen de scope), beschikbaarheid, integriteit van de verwerking, vertrouwelijkheid en privacy. Het is een goed signaal van beveiligingshygiëne, geen keurmerk van Europese conformiteit.

Tweede punt, datgene wat een echt signaal scheidt van een schijnsignaal: SOC 2 bestaat in twee types, en het verschil is alles.

• Type I — attesteert dat de controles bestaan op een bepaald moment. Het is een momentopname: op de dag van de audit waren ze er. Op zichzelf is het een zwak signaal.
• Type II — attesteert dat die controles echt hebben gewerkt gedurende een venster van zes tot twaalf maanden. Het is de film, niet de foto: het is het enige van de twee dat iets betekenisvols zegt over hoe de leverancier in de tijd werkt.

Als een leverancier je zegt «we hebben SOC 2» zonder te specificeren, is de eerste vraag: Type I of Type II?. Een Type I dat als garantie wordt gezwaaid is vaak een marketingsluiproute. Eis het Type II — en het rapport, niet alleen het attest.

De vragen die je stelt voor je tekent

Een SOC 2-rapport «heb» je of «heb» je niet: je leest het. En het deel dat voor jou telt — de AI — zit bijna altijd verstopt in de details van de scope. Voor je tekent zijn dit de poorten die de leverancier moet passeren, niet het woord «gecertificeerd»:

De drie dingen die SOC 2 je nooit zal vertellen

Hier zit de grens die geen enkele hoeveelheid «Type II» dicht. SOC 2 is ontstaan voor de beveiliging en de betrouwbaarheid van de infrastructuur: servers, toegangen, continuïteit. Het is niet bedacht voor AI, en inderdaad heeft de AICPA in juli 2026 geen enkel SOC 2-criterium gepubliceerd dat specifiek is voor kunstmatige intelligentie: de auditors passen de generieke criteria van 2017 toe met het gebruikelijke oordeel over informatiebeveiliging (Schellman). Vertaald: hoe onberispelijk het rapport ook is, er zijn dingen over de AI die het je nooit zal vertellen.

• De bias van het model — of de antwoorden discrimineren, meet SOC 2 niet.
• De verklaarbaarheid — waarom het model zo besliste, blijft buiten de scope.
• Het hallucinatierisico en de informatie-integriteit — dat het model met stelligheid iets verzint, is geen controle die een beveiligingsaudit onderschept.

«SOC 2 Type II compliant» is geen bewijs van de beveiliging van de AI noch van governancevolwassenheid: dat is heel ander terrein. De twee verwarren is de duurste fout van deze fase — want het geeft je een gevoel van dekking juist daar waar je die niet hebt.

De juiste standaard om te vragen is een andere: ISO/IEC 42001

Als de vraag is «beheert deze leverancier de AI op een volwassen manier?», dan is de standaard die je moet noemen niet SOC 2, maar de ISO/IEC 42001:2023, gepubliceerd in december 2023: de eerste certificeerbare standaard voor een systeem voor het beheer van AI. Waar SOC 2 naar de infrastructuur kijkt, kijkt ISO 42001 naar de AI als zodanig — een AI-beleid en verantwoordelijkheid bij de directie, een inventaris van de AI-systemen met risicoclassificatie, impactbeoordelingen, governance van de trainingsdata, controles over de hele levenscyclus van het model, beheer van bias en van non-conformiteiten.

De juiste manier om ze samen te houden is ze te zien als twee afzonderlijke lagen, niet als alternatieven (BARR Advisory): SOC 2 is de vloer van de beveiliging, ISO 42001 is de verdieping van de AI-governance daarbovenop. De beste praktijk is beide te hebben; als een leverancier je alleen SOC 2 toont en over «verantwoorde AI» spreekt, is de volgende vraag vanzelfsprekend: en met ISO 42001, hoe ver staan jullie?.

Pas op voor de sluiproutes: de «SOC for AI»

Op het web circuleert het idee van een «SOC for AI», een vermeend AI-specifiek schema. Het is de moeite waard dit te weten om er niet in te trappen: het blijkt niet door de AICPA gepubliceerd — haar officiële pagina over de SOC-diensten vermeldt het niet, en de bronnen die erover spreken gaan terug op content zonder auteur en zonder link naar een primaire bron. Behandel het als een onbevestigd gerucht, niet als een vereiste om te eisen of om mee te pronken. Op dit terrein, waar de regels nog in de maak zijn, is voorzichtigheid: vraag de standaarden die echt bestaan — niet die met de meest geruststellende naam.

In Italië vervangt SOC 2 niets

Een punt dat te veel commerciële presentaties in het vage laten: in Italië en in Europa heeft SOC 2 geen kracht van wet. Het is geen Europese vereiste en het vervangt niets van wat de GDPR en de EU AI Act je vragen (Comp AI). Een leverancier met een uitstekende SOC 2 kan alsnog niet volstaan, als jouw gebruik van die tool een gegevensbeschermingseffectbeoordeling vereist.

Waar telt het dan echt? Als één input, één van vele, in de stap beoordeling van het leveranciersrisico van je DPIA: wanneer de tool een Amerikaanse SaaS is, is SOC 2 een nuttig bewijs over de beveiliging van de verwerking (in de logica van artikel 32 van de GDPR). Maar het blijft ondergeschikt aan de analyse onder GDPR en AI Act, het vervangt die niet. Het is precies de plaats die we het geven in onze compliance-overlay: de diligentie op de leverancier is een bouwsteen van het governanceblok dat elk gebruiksscenario begeleidt, nooit een vervanging van de analyse die telt.

Wat je nu doet, in de praktijk

Je hoeft geen auditor te worden. Voor een mkb-bedrijf dat een AI-tool aan het kiezen is, is de redelijke diligentie kort en concreet:

• Eis het Type II, en het rapport. Een Type I-attest dat als garantie wordt gezwaaid is een zwak signaal; vraag het Type II-rapport en lees het, blijf niet steken bij de verklaring.
• Controleer dat de scope de AI noemt. Als de scope alleen over «het Platform» spreekt en niet over de AI/agent-functies, dan dekt het rapport juist het deel niet dat jou aangaat.
• Vraag de lijst van subleveranciers en het lot van je gegevens. Welke modelleverancier er achter zit, of je gegevens de training voeden, en met welke garanties — schriftelijk vastgelegd in het contract.
• Vraag ISO 42001, niet alleen SOC 2. Als de leverancier «verantwoorde AI» verkoopt, is de standaard die dat aantoont die ene — of minstens een traject ernaartoe.
• Laat alles samenkomen in de DPIA, waar SOC 2 geldt als een van de elementen van de beveiliging van de verwerking, niet als het eindoordeel.

Nog voor je een afzonderlijke leverancier beoordeelt, is het echter verstandig te weten welk proces je wilt automatiseren en met welke controles eromheen: daaruit volgt wat je aan de leverancier vraagt. Onze AI-readiness-beoordeling helpt de juiste processen op een rij te zetten en de controles die je moet eisen; als je precies aan het kiezen bent tussen zelf bouwen en kopen, kadert het artikel over kopen of bouwen de beslissing stroomopwaarts, en de controles die een gebruiksscenario verdedigbaar maken vervolledigen het beeld stroomafwaarts.

We hebben de eerste stap omgezet in een gratis, self-service beoordeling: een paar vragen en een aanwijzing over waar te beginnen, met welke controles — en welke vragen aan de leverancier — rond de eerste stroom. Doe de AI-readiness-beoordeling — en dan, als het zin heeft, praten we.

Dit artikel is louter ter oriëntatie en vormt geen juridisch advies noch een conformiteitsbeoordeling. SOC 2 is een attest van de AICPA (geen Europese wet) over de Trust Services Criteria van 2017; het onderscheid Type I / Type II, de afwezigheid — in juli 2026 — van AI-specifieke SOC 2-criteria van de AICPA, en de rol van de ISO/IEC 42001:2023 als certificeerbare standaard voor AI-beheer weerspiegelen sectorbronnen die op die datum actueel zijn en moeten worden herbekeken op de vigerende tekst. Voor de concrete verplichtingen van je onderneming verwijs je naar de GDPR, de tekst van de EU AI Act, de aanwijzingen van de toezichthouder en gekwalificeerde juridische bijstand.