AI-governance in een mkb-bedrijf: de controles die een use-case verdedigbaar maken

Er is een vraag die vóór de toolkeuze komt en een die erna komt. De eerste — „moet ik me aanpassen aan de AI Act? ben ik verplicht?” — behandelden we in het artikel over de EU AI Act voor het mkb, en voor de meeste bedrijven is het antwoord geruststellender dan verwacht. Dit is de andere: zodra u besloten hebt een use-case in productie te nemen — een copilot voor verkoop, een supportbot, een automatisering in de administratie — hoe bestuurt u hem zodat hij standhoudt? Standhoudt bij een controle van de Garante, bij een verzoek van een klant, bij een incident, bij de ongemakkelijke vraag van een auditor.

Het is een andere vraag dan formele compliance, en die waarbij we de meeste lichtzinnigheid zien. Niet „ben ik in orde met de wet?”, maar „als er iets misgaat, wat kan ik dan tonen?”. Het verschil tussen die twee is de hele governance. We proberen het op orde te brengen, in heldere taal, zonder paniekzaaierij en zonder het te veranderen in het gebruikelijke document van twintig pagina's dat niemand leest.

Governance is geen document: het is een blok dat elke use-case vergezelt

De meest voorkomende fout is AI-governance zien als een algemene policy — een PDF die principes verklaart en in een map belandt. Zo werkt het niet, want het risico leeft niet abstract in het bedrijf: het leeft in de afzonderlijke workflow. Een copilot die antwoorden voor support voorstelt en een systeem dat binnenkomende cv's filtert, hebben hetzelfde „niveau van bedrijfsaandacht”, maar een onvergelijkbaar risicoprofiel. Serieuze governance haakt zich vast aan de use-case, niet aan de organisatie.

Wat we gebruiken — en het is de structuur die we elk mkb-bedrijf aanraden, ook zonder ons — is een kort en herhaalbaar blok dat elk workflowontwerp vergezelt. Vijf regels, altijd dezelfde:

• Risiconiveau — waar de use-case valt op de schaal van de AI Act (bijna altijd minimaal of beperkt; hoog alleen voor personeel, krediet, biometrie).
• Is een DPIA nodig? — de GDPR-controle op de verwerking van de betrokken persoonsgegevens (zie hieronder: wanneer die aangaat en waarom de „standaard”-variant niet volstaat).
• Risicolabels — een classificatie van de manieren waarop die workflow kan falen, met een gedeeld vocabulaire in plaats van in losse woorden (zie de MIT-taxonomie verderop).
• Mitigaties — wat we rond het risico zetten: drempels, autonomiegrenzen, menselijke review, dataminimalisatie.
• Toezicht en traceerbaarheid — wie de werking bewaakt en wat er geregistreerd blijft, en hoe lang.

De waarde van dit blok is niet formeel: het is operationeel. Wanneer de Garante, een klant of een auditor vraagt „hoe beheert u dit systeem?”, antwoordt u niet met een filosofie — u opent het blok van de specifieke workflow en toont de vijf regels. Het is het verschil tussen verklaren dat u governance hebt en het echt zijn.

De DPIA voor AI: wanneer die nodig is, en waarom de „standaard”-variant niet volstaat

De gegevensbeschermingseffectbeoordeling (DPIA, art. 35 GDPR) is het eerste concrete instrument van de governance, maar ook het meest misbegrepen. Ze is niet altijd nodig: ze wordt verplicht wanneer de verwerking „waarschijnlijk hoog risico” is. Drie gevallen maken haar automatisch — geautomatiseerde beslissingen met juridische of aanmerkelijke gevolgen voor de persoon, verwerking op grote schaal van bijzondere gegevens (gezondheid, opvattingen, biometrie), en systematische monitoring van openbaar toegankelijke ruimten — waaraan de EDPB negen aanvullende criteria toevoegt (profilering, beoordeling, gebruik van innovatieve technologieën). De meeste zakelijke AI-deployments raken er minstens één.

Tot hier is het klassieke GDPR. Het punt dat bijna geen enkel model in overweging neemt, is dat een generieke DPIA, bedacht voor een database of een boekhoudsysteem, de AI-eigen risico's mist. Een model is geen tabel: het heeft gedrag dat een traditionele beoordeling niet voorziet. In een DPIA voor AI moeten, als aparte sectie, minstens vier punten worden toegevoegd die elders niet bestaan:

• Opaciteit van het model — de beslissing kan niet regel voor regel verklaarbaar zijn. Als de workflow een persoon raakt, is „ik weet niet waarom het zo besliste” een complianceprobleem, niet louter een technisch.
• Drift — een model dat goed werkte, degradeert in de loop van de tijd als de invoergegevens veranderen. Een controle die eenmalig bij de lancering is gedaan volstaat niet: ze moet opnieuw.
• Memorisatie van de trainingsdata — een model kan fragmenten van de data waarmee het is getraind terug uitbraken, inclusief persoonsgegevens. Het is een inbreukvector die een database niet heeft.
• Conflict met het recht op vergetelheid — een persoonsgegeven uit een database wissen is triviaal; een gegeven „ontleren” uit een reeds getraind model vaak niet. De DPIA moet zeggen wat er gebeurt wanneer dat verzoek binnenkomt.

Als uw consultant u de DPIA voorstelt die hij voor eender welke software zou gebruiken, zonder deze sectie, geeft hij u een formulier, geen beoordeling. En als de DPIA een hoog risico vaststelt dat u niet kunt mitigeren, vraagt de GDPR (art. 36) om de toezichthoudende autoriteit te raadplegen vóór u doorgaat: zeldzaam voor een mkb-bedrijf, maar het moet als escalatietak voorzien zijn, niet ontdekt wanneer het incident al gebeurd is.

Een gedeeld vocabulaire voor het risico, in plaats van losse woorden

„Dit systeem is riskant” is geen nuttige informatie: het is een indruk. De kwaliteitssprong in governance is de overgang van vage proza naar een herhaalbaar en citeerbaar label, hetzelfde voor alle workflows, zodat twee verschillende use-cases vergelijkbaar worden. Daarom gebruiken we als referentievocabulaire de AI Risk Repository van MIT, die het risico op twee assen classificeert:

• Hoe het risico ontstaat (causale as): de entiteit die het genereert (mens / AI / anders), de intentie (opzettelijk / onopzettelijk), het moment (vóór of na de release).
• Welk type risico het is (domein-as): zeven domeinen — discriminatie, privacy en beveiliging, desinformatie, kwaadwillig gebruik, mens-machine-interactie, sociaal-economische effecten, storingen en beperkingen van het systeem.

Een voorbeeld maakt de methode concreet. Een copilot voor verkoop die af en toe een detail over een product „verzint” — de klassieke hallucinatie — wordt gelabeld als (entiteit: AI · intentie: onopzettelijk · moment: na de release) × (domein: desinformatie). Het is geen academische tic: dat label zegt u waar u moet ingrijpen (stroomafwaarts, met een menselijke controle op de output vóór die de klant bereikt) en geeft u een gemeenschappelijk woord om erover te praten met wie het model niet begrijpt. Het proza doet dat niet: het label wel.

De twee operationele controles die zwaarder wegen dan alle andere

Men kan een uitgewerkte governance schrijven en blootgesteld blijven; of een slanke aanhouden met twee solide controles en echt verdedigbaar zijn. In bijna elke use-case van een mkb-bedrijf maken deze twee het verschil.

De eerste is de mens in de lus. Niet als slogan, maar als architectuur: wie de werking van het systeem bewaakt, met welke bevoegdheid om het te stoppen, en bij welke beslissingen zijn tussenkomst verplicht is. Het is hetzelfde principe dat een agent in administratie en finance verdedigbaar maakt — waar de uitkomst onomkeerbaar is omdat er geld wordt verplaatst — maar het geldt overal waar een beslissing een persoon raakt. De praktische regel die we geven: verleen het systeem autonomie alleen waar de uitkomst omkeerbaar en verifieerbaar is; al de rest gaat langs een mens.

De tweede is de traceerbaarheid. Voor de hoog-risicotoepassingen vraagt artikel 26 van de AI Act de deployer om de logs minstens zes maanden te bewaren en ernstige incidenten te melden; maar ook buiten dat bereik is het bijhouden van wat het systeem heeft beslist, op welke data en wie heeft goedgekeurd, wat „we vertrouwen erop” verandert in „we kunnen het aantonen”. Een register dat een controle doorstaat, geen prompt. Het is de goedkoopste controle om te plaatsen en de duurste om niet te hebben wanneer het nodig is.

Het Italiaanse kader: compliance is een levend gebied, geen vakje

Wie u een governance „voor eens en altijd” verkoopt, kijkt niet naar wat er in Italië gebeurt. De Wet 132/2025 heeft de algemene nationale principes over AI ingevoerd en verruimt het bereik van de DPIA voor toepassingen van kunstmatige intelligentie voorbij de GDPR-basis — wat betekent dat de actuele vereisten geverifieerd moeten worden vóór u ze aan een klant citeert, want de tekst is recent en de materie is in beweging. Aan de controlekant heeft de Italiaanse privacytoezichthouder (Garante Privacy) met het besluit van 30 december 2025 voor januari–juli 2026 minstens 40 inspecties ingepland, en tot de genoemde gebieden behoren uitdrukkelijk controles op AI-hulpmiddelen die in het onderwijs worden gebruikt. Ook als uw use-case ver van het onderwijs af staat, zegt dat iets wat telt: inspecties rond AI staan al ingepland, ze zijn geen hypothese. De AI-pagina van de Garante is de canonieke bron om bij elk project opnieuw te controleren, want de richtsnoeren worden vaak bijgewerkt.

De praktische lezing: governance is geen document dat u tekent en archiveert, het is een praktijk die u herziet. Een model drijft af, een norm verandert, een use-case breidt uit — en het blok van vijf regels moet opnieuw open. Wie het u verkoopt als een eenmaal afgevinkt vakje, stelt u gerust, hij beschermt u niet.

Van oriënteren naar doen, in de praktijk

Als u op het punt staat een use-case in productie te nemen en wilt dat hij standhoudt, is het traject kort en geordend:

• Haak het blok aan de workflow, niet aan het bedrijf — risiconiveau, DPIA ja/nee, labels, mitigaties, toezicht. Vijf regels per use-case, geen PDF voor de hele onderneming.
• Als een DPIA nodig is, gebruik er een met de AI-sectie — opaciteit, drift, memorisatie, recht op vergetelheid. Zonder die punten is het geen AI-beoordeling, het is een formulier.
• Geef het risico een label, geen bijvoeglijk naamwoord — een gedeeld vocabulaire maakt de cases vergelijkbaar en de mitigaties vanzelfsprekend.
• Zet mens-in-de-lus en traceerbaarheid vanaf de eerste dag — ze vertragen het project niet: ze maken het verdedigbaar. Het zijn de twee controles die meer waard zijn dan alle geschreven policy.
• Behandel het als levend — controleer het model, de Italiaanse norm en het gebruiksbereik met intervallen opnieuw, niet één keer bij de lancering.

Nog daarvóór is het echter goed te weten waar u staat: onze AI-readiness-beoordeling helpt te begrijpen met welke afdeling u met meer rendement en minder wrijving begint, en welke controles u rond de eerste workflow zet. Het is precies dit governanceblok dat onze compliance-overlay aan elk ontwerp dat we maken vasthaakt — geen apart document, maar de controles ín de workflow.

We hebben de eerste stap omgezet in een self-service en gratis beoordeling: een paar vragen en een aanwijzing over waar te beginnen, met welke controles eromheen. Doe de AI-readiness-beoordeling — en als het thema de governance is van een use-case die u op het punt staat te adopteren, schrijf ons en we praten erover.

Dit artikel is bedoeld ter oriëntatie en vormt geen juridisch advies. Het regelgevende kader rond AI Act, GDPR en de Italiaanse wet is in ontwikkeling — in het bijzonder deadlines, het bereik van de DPIA en de richtsnoeren van de Garante kunnen veranderen: ze moeten op de vigerende tekst worden geverifieerd voor het concrete geval van het individuele bedrijf.