Technische documentatie onder de AI-wetgeving

Wat de documentatieverplichting eigenlijk omvat

Artikel 11 en Bijlage IV bepalen de documentatie-inhoud voor systeem met hoog risico. Het pakket omvat het beoogde doel, ontwerpkeuzes, ontwikkelings- en testgeschiedenis, prestatieclaims en de risicobeheersmaatregelen die u daadwerkelijk heeft uitgevoerd.

De bindende tekst is de verordening zelf op EUR-Lex (Verordening (EU) 2024/1689). Secundaire blogs en presentatiedekken zijn alleen nuttig nadat u naar het artikel en de bijlagerij kunt verwijzen die elke claim ondersteunt. Ik behandelt documentatie als een levend bestand onder versiebeheer, niet als een eenmalig PDF-bestand dat de week voor een demo wordt geëxporteerd.

Levenscyclus, geen freeze-frame

Als het model verandert, de trainingsset wordt vernieuwd of een veiligheidscontrole opnieuw wordt ingesteld, moet de documentatie de delta laten zien. Wijzigingsnotities, eigenaren en datums zijn net zo belangrijk als de eerste opzet. Wanneer een implementeerder vraagt "welke build was op dinsdag in productie?", moet u antwoorden vanuit hetzelfde record dat de conformiteit ondersteunt — niet vanuit een Slack-thread.

Stap-voor-stap-workflow die we gebruiken voordat we een pakket "klaar" noemen

- Bevestig dat het systeem een hoog risico heeft (of als zodanig wordt behandeld) onder Artikel 6 / Bijlage III voordat u een documentatieboom uitvindt. Als het geen hoog risico heeft, claim dan niet ten onrechte de volledigheid van Bijlage IV in verkoopkopie. - Open Bijlage IV en maak één map of ticket per thema: algemene beschrijving, ontwerpspecificaties, ontwikkelproces, gegevens, risicobeheer, testen, monitoring en menselijke toezicht. - Wijs één eigenaar toe per thema. Gedeelde eigendom zonder naam is hoe secties leeg blijven. - Maak een ontwerp met product en engineering in de kamer. Juridische beoordelingen controleren claims; ingenieurs leveren bewijsroutes (configuraties, dashboards, testrapporten). - Koppel elke claim aan een artifact: een datasetsamenvatting, een loggingschema, een runbook, een risicoregisterrij. Ongekoppelde proza is een geur. - Loop het pakket tegen het live-systeem: komt de logconfiguratie overeen met de claims in Artikel 12? Komt het override-pad in de UI overeen met de tekst in Artikel 14? - Plan een refresh-trigger: modelversiebump, materiële datasetwijziging, nieuwe deployerklasse of ernstig-incident-near-miss.

VendorVet zet deze thema's om in een werkende checklist. Het vervangt geen geïnformeerde lichaamsoordeel of -advies. Gebruik het product om weglatingen vroeg te detecteren; gebruik het Publicatieblad om discussies te beslechten.

Samenvattingen van datasets die teams overslaan (Artikel 10)

Artikel 10 verwacht gegevensbeheer: trainings-, validatie- en testgegevens moeten relevant en representatief zijn voor het beoogde doel, met onderzoek naar vooroordelen en lacunes die de prestaties voor de personen die door het systeem worden beïnvloed, zouden schaden. Auditors zoeken naar een samenvatting van de gebruikte gegevens en hoe deze zijn onderzocht - niet een marketingmodelkaart met drie bijvoeglijke naamwoorden.

Een rij in de controlelijst die zegt "gegevens beoordeeld" zonder samenvatting erachter, faalt de eerste serieuze beoordeling. Schrijf de samenvatting zodat een nieuwe ingenieur kan antwoorden: bron domeinen, tijdsvensters, bekende scheeftrekken, uitsluitingsregels en hoe labels zijn geproduceerd of gecontroleerd. Als persoonsgegevens in de pijplijn zitten, houd uw GDPR-rollen en -bases consistent met hoe u de verwerking elders beschrijft; de EDPB-richtlijnenbibliotheek is de praktische controlemiddel voor die taal (EDPB-richtlijnen en beste praktijken).

Controlelijst - gegevensevidence

- Inventaris van trainings-/validatie-/testsets met eigendom en laatste vernieuwingsdatum - Notities over representativiteit gekoppeld aan het beoogde doel (wie valt binnen het bereik, wie valt erbuiten) - Methode voor onderzoek naar vooroordelen en fouten - zelfs als deze onvolmaakt is - met resterend risico vermeld - Label- of annotatieproces, inclusief kwaliteitscontroles - Regels voor opslag en toegang tot de datasets zelf

Ontwerp van menselijke toezicht (Artikel 14)

Artikel 14 vraagt om zinvolle menselijke toezicht: interfaces en controles die een persoon in staat stellen om uitvoer te monitoren, te interpreteren en indien nodig in te grijpen. "Mensen blijven in de lus" is geen mechanisme. Documenteer het specifieke ingrijppad, wie het kan uitoefenen, hoe het systeem aangeeft dat een mens moet ingrijpen en wat er gebeurt wanneer de mens onbeschikbaar is.

Bij agentproducten houdt dit vaak een harde stop in voordat een gevolgrijke actie wordt uitgevoerd (publicatie van een shortlist voor het aannemen van personeel, verzending van een kredietbeslissing, bijwerken van een dossier), en niet een decoratieve goedkeuringsknop die automatisch na drie seconden wordt geactiveerd. Koppel de UI-beschrijving aan het runtimebeleid: welke rollen, welke omgevingen, welke auditgebeurtenissen worden geactiveerd wanneer de override wordt gebruikt.

Controlelijst — bewijs van toezicht

- Genoemde toezichthoudende rollen en escalatiepad - UI- of API-controles die de AI-actie daadwerkelijk pauzeren of omkeren - Signalen / drempels die om menselijke beoordeling vragen - Training of runbook voor de mensen die toezicht houden - Bewijs dat override-gebeurtenissen worden gelogd

Post-marktbewaking en loggen (Artikelen 12 en 72)

Artikel 12 vereist automatische loggen die voldoende zijn voor traceerbaarheid, met een minimumbewaartermijn van zes maanden voor systeem met hoog risico. Artikel 72 voegt serieuze-incidentenrapportageplichten toe. Teams documenteren het model en vergeten het runtime-bewijsplan. Koppel de documentatie aan de daadwerkelijke logconfiguratie, zodat de twee overeenkomen.

Als u al GenAI-observabiliteit uitvoert, koppelt u spans en events aan de vragen die een post-marktbeoordeling zal stellen: welke invoerklasse, welke modelversie, welk beleidsbesluit, welke menselijke actie. De GenAI-conventies van OpenTelemetry zijn een praktische technische referentie voor het consistent noemen van die velden over services heen (OpenTelemetry — GenAI-observabiliteit). De wet eist OTel niet; consistente sporen maken het echter gemakkelijker om Artikel 12-aanspraken te verdedigen.

Thema | Artikel-/bijlagehaak | Vaak voorkomende missers | Bewijs dat telt Algemene beschrijving en doel | Art. 11 / Bijlage IV | Marketingpitch in plaats van beoogd doel | Doelverklaring + buiten-scope-gebruiken Gegevensbeheer | Art. 10 | "Dataset beoordeeld" zonder samenvatting | Dataset-inventaris + voorbeelden van vooroordelen Risicobeheer | Art. 9 | Statische risicopdf van vorig jaar | Levend register met eigenaren en resterend risico Loggen | Art. 12 | Loggen worden geclaimd, maar bewaartermijn < 6 maanden | Schema + bewaarconfiguratie-screenshot/export Menselijke toezicht | Art. 14 | Slogan zonder omleidingspad | UI/runbook + rolmatrix Post-markt / incidenten | Art. 72 | Geen serieuze-incidentenplaybook | Triggerdefinities + rapportagecontacten

Gangbare fouten die we zien in documentatiepakketten

- Schrijven voor de brochure, niet voor de bijlage. Mooie diagrammen die nooit verwijzen naar de thema's van bijlage IV verspillen beoordelingstijd. - Kopiëren van een US RMF-werkblad en het hernoemen naar "AI Act-pakket". Het AI Risk Management Framework van NIST is nuttig voor procesvocabulaire (NIST AI RMF), maar het is geen vervanging voor de inhoud van artikel 11 / bijlage IV. - Documenteren van gisterens model. De productie is al verhuisd; het pakket niet. - Deployer-instructies leeg laten. Transparantie naar deployers zoals vereist in artikel 13 is gemakkelijk over te slaan wanneer het provider-team alleen met zichzelf praat. - Een controlelijst "gecertificeerd" noemen. Die taal is overdreven. Controlelijsten verminderen het risico op weglating; ze garanderen geen conformiteit.

Beslissingscriteria: het pakket verzenden versus blijven ontwerpen

Behandel het pakket als release-blokkerend voor een lancering met hoog risico wanneer een van de volgende voorwaarden waar is:

- Geen datasetsamenvatting die een derde partij kan volgen - Geen beschreven mechanisme voor menselijke toezicht gekoppeld aan een echte controle - Logboekretentie van minder dan zes maanden, of logboeken die geen beslissing kunnen reconstructeren - Risicoregister met geen eigenaren van resterend risico - Beoogd doel zo vaag dat toewijzing aan Bijlage III onmogelijk is

U kunt nog steeds interne prototypes verzenden die nooit EU-hoogrisicogebruik aanraken. Wees eerlijk over de reikwijdte in uw schriftelijke tekst. Dubbelzinnige taal als "we voldoen aan de geest" is erger dan een duidelijke status "nog niet hoogrisico / nog niet op de EU-markt".

Wat dit niet is

Deze pagina is geen juridisch advies, geen beoordeling door een aangemelde instantie en geen garantie dat uw systeem voldoet aan Verordening (EU) 2024/1689. VendorVet beweert geen 100% dekking, verzint geen klantwinstpercentages en vervangt geen juridisch advies of een conformiteitsbeoordeling waar deze vereist is. Een checklist helpt u bij het samenstellen en verifiëren van thema's; de bindende verplichting blijft de in Artikel 11 en Bijlage IV beschreven documentatie, die eigendom is van gekwalificeerde personen binnen uw organisatie.

Afronding

Begin met de tekst van het Publicatieblad, kaart de thema's van Bijlage IV toe aan de eigenaren, vul vervolgens de drie lacunes die auditors het eerst openen: gegevens, toezicht en loggen. Houd de pack versiegebonden met het systeem. Wanneer het model of de dataset wordt verplaatst, verplaats de documentatie in dezelfde release-trein. Voor het risicoklassebesluit dat stroomopwaarts van al dit zit, lees onze zusterprimer over EU AI Act-risicoklassen.

Referenties

- Verordening (EU) 2024/1689 (EUR-Lex) - Europese Commissie — AI Act - EU AI Act — Implementatie-tijdlijn - NIST AI Risk Management Framework - EDPB — GDPR-richtlijnen en best practices - OpenTelemetry — GenAI-observatie

Gerelateerde artikelen

- EU AI Act-risicogroepen: een handleiding voor de praktijk (2026) - Verken de volledige AI micro-SaaS-onderwerpmatrix →