Art. 12 EU AI Act: registratie en logging voor hoog-risico AI

Bijgewerkt: juni 2026

Dit is een expliciete provider-verplichting onder de EU AI Act. De logging-capaciteit moet door de provider worden ingebouwd; deployers dragen de bijbehorende bewaarplicht voor logs onder Art. 26.6.

Inleiding: het systeem door constructie auditeerbaar maken

Art. 12 is de verplichting die een hoog-risicorisicoIn de termen van de EU AI Act de combinatie van de waarschijnlijkheid dat een schade optreedt en de ernst ervan als dat gebeurt. De schakel tussen een principe (via de schade die het zou schenden) en een control (de maatregel die het vermindert). Het benoemen van de schade en het inschatten van het risico is op grond van Art. 9 vereist voordat een maatregel wordt gekozen. Zie schade, control, restrisico.Open full entry → AI-systeemAI-systeemEen machinaal systeem dat voor expliciete of impliciete doelen uit invoer afleidt hoe het uitvoer genereert, voorspellingen, inhoud, aanbevelingen of beslissingen, die fysieke of virtuele omgevingen kunnen beïnvloeden. De OESO-achtige definitie die de EU AI Act volgt. Zie algoritme, machine learning.Open full entry → van een black boxblack boxInformele naam voor een systeem waarvan de interne beslislogica niet kan worden ingezien of betekenisvol uitgelegd. Zie uitlegbaarheid.Open full entry → in een auditeerbaar systeem verandert. Het vereist dat het systeem technisch de automatische registratie van gebeurtenissen, logs, mogelijk maakt gedurende zijn levensduur. Dit is een ontwerpeis voor de provider: de mogelijkheid om te loggen moet in het systeem worden gebouwd, niet achteraf door de deployer worden aangebracht. Zonder die mogelijkheid kan geen van de downstream-verantwoordingsverplichtingen worden vervuld, omdat er geen verslag is om te onderzoeken.

Het doel van de logging is traceerbaarheid. De logs moeten het mogelijk maken te reconstrueren hoe het systeem functioneerde, op een detailniveau passend bij het beoogde doel, zodat een deployer, een auditor of een toezichthouder kan begrijpen wat het systeem deed en waarom. Logging is het bewijsfundament waarop toezicht, incidentonderzoek en conformiteit alle rusten.

Wat de logs moeten vastleggen

Art. 12 vereist dat de logging-capaciteit gebeurtenissen registreert die relevant zijn voor het identificeren van situaties die ertoe kunnen leiden dat het systeem een risico vormt of een substantiële wijzigingsubstantiële wijzigingEen verandering aan een uitgerold AI-systeem die zijn functie of doel wezenlijk wijzigt, in staat om de verplichtingen van de aanbieder naar de wijzigende partij te verschuiven. Zie aanbieder, AI-verplichtingen, herbestemming.Open full entry → ondergaat, voor het faciliteren van post-market monitoringpost-market monitoringDe plicht aan de aanbiederszijde om ervaring met systemen in gebruik systematisch te verzamelen en erop te handelen, de productregelgevingshelft van doorlopende monitoring. Zie doorlopende monitoring, aanbieder.Open full entry →, en voor het bewaken van de werking van het systeem. Voor de hoog-risico systemen waar het het strengst geldt, moet de logging minimaal vastleggen: de periode van elk gebruik, de referentiedata waartegen inputs zijn gecontroleerd, de inputdata, en de identificatie van de personen die betrokken waren bij de verificatie van de resultaten.

Het leidende principeprincipeEen van de zeven waarden van verantwoorde AI waaraan een bestuurd systeem zou moeten voldoen (eerlijkheid, veiligheid en betrouwbaarheid, privacy, beveiliging en robuustheid, transparantie en uitlegbaarheid, verantwoording, menselijk toezicht). Een principe is abstract: het benoemt een uitkomst, geen knop die je kunt omzetten. Het wordt bestuurbaar door de schade te benoemen die het zou schenden, het risico van die schade in te schatten, en controls tegen dat risico te plaatsen. Wanneer GovCompass een principe zo borgt, noemt het dat een pijler. Zie pijler, schade, risico.Open full entry → is dat de logs voldoende moeten zijn om de werking van het systeem te reconstrueren in de mate die het risico van het gebruiksgeval vereist. Een systeem dat ingrijpende beslissingen over mensen neemt, vereist logging die gedetailleerd genoeg is om een individuele beslissing te reconstrueren; een systeem met lagere inzet vereist minder.

Waarom immutability ertoe doet

Een log is alleen bewijsbewijsHet concrete bewijs dat een control is ontworpen, geïmplementeerd en werkt: een testrapport, een audit trail, een impactassessment, een monitoringlog. Elke schakel in de governance-keten levert een artefact op, en samen zijn ze wat een organisatie overhandigt aan haar eigen bestuur, een toezichthouder, een klant of een betrokkene om te tonen, niet te zeggen, dat een systeem bestuurd is. De afwezigheid ervan is zelf het falen: een risicoregister zonder testresultaten, of een maatregel die wordt geclaimd zonder validatie, is een governance-gat, geen papierwerk-gat. De sluitende schakel van de governance-keten. Zie control, governance.Open full entry → als die niet stilletjes kan worden gewijzigd. Dit is het punt dat echte registratie scheidt van de schijn ervan. Databaselogs die een beheerder kan bewerken kwalificeren niet als een fraudebestendig auditspoor, omdat een verslag dat achteraf kan worden gewijzigd niets bewijst over wat er werkelijk is gebeurd. De logging die Art. 12 voor ogen heeft, is automatisch gegenereerd, fraude-aantoonbaar (tamper-evident) en bewaard, zodat het verslag dat aan een toezichthouder wordt voorgelegd het verslag is van wat er gebeurde, niet een versie die aangepast had kunnen worden.

Dit is het verschil tussen beleid als document en compliance als geïnstrumenteerd systeem. Een organisatie die onveranderlijke, automatisch gegenereerde logs kan overleggen, toont controle aan op het niveau dat een toezichthouder kan verifiëren. Een die bewerkbare databasetabellen biedt, biedt een bewering, geen bewijs.

De relatie met Art. 19 en Art. 26

Art. 12 is de ontwerpverplichting; twee andere artikelen maken het plaatje compleet. Art. 19 verplicht providers om de automatisch gegenereerde logs die onder hun controle staan, gedurende een passende periode te bewaren. Art. 26.6 legt de bewaarplicht bij deployers: bewaar de logs die het hoog-risico systeem genereert minimaal zes maanden, tenzij andere wetgeving een langere termijn vereist. Samen zorgt Art. 12 dat de logs bestaan, zorgen Art. 19 en Art. 26.6 dat ze worden bewaard, en zorgt de combinatie dat bij een incident of audit het bewijs beschikbaar is.

Waarom het ertoe doet

Voor de deployer zijn de logs het primaire bewijs dat het systeem conform de instructies en onder behoorlijk menselijk toezichtmenselijk toezichtHet ingebouwde vermogen van een mens om een AI-systeem te monitoren, erin in te grijpen, het te overrulen of stil te leggen, alleen betekenisvol wanneer de mens de bevoegdheid, de informatie en de tijd heeft om te handelen. Zie principe, human-in-the-loop, human-on-the-loop.Open full entry → is gebruikt. Wanneer een toezichthouder vraagt hoe een bepaalde beslissing tot stand kwam, of of het toezicht reëel was, zijn de logs het antwoord. Een deployer die ze niet kan overleggen, kan compliance niet aantonen, ongeacht hoe goed de rest van het programma is ingericht.

Registratie besturen

De controls zorgen dat de logging-capaciteit bestaat, fraudebestendig is, en lang genoeg wordt bewaard om zijn doel te dienen.

Bij inkoop bevestigt de deployer dat het hoog-risico systeem de Art. 12-logging-capaciteit biedt en dat de logs exporteerbaar zijn in een bruikbaar formaat, omdat een bewaarplicht niet kan worden vervuld voor logs die niet kunnen worden geëxtraheerd. In gebruik zorgt de deployer dat de logs worden vastgelegd, beschermd tegen wijziging, en bewaard voor de Art. 26.6-minimumtermijn of langer waar andere wetgeving geldt. Het retentie-ontwerp balanceert de zesmaandse logging-ondergrens tegen het AVG-minimalisatiebeginsel via pseudonimiseringpseudonimiseringIdentificerende velden vervangen zodat data niet aan een persoon kan worden toegeschreven zonder afzonderlijke informatie, een minimalisatie- en beveiligingstechniek die data onder de AVG persoonsgegevens houdt. Zie dataminimalisatie.Open full entry → waar de logs persoonsgegevens bevatten.

Checklist

1. Biedt elk hoog-risico systeem een automatische logging-capaciteit zoals vereist door Art. 12?
2. Zijn de logs gedetailleerd genoeg om de werking van het systeem te reconstrueren op het niveau dat het gebruiksgeval vereist?
3. Zijn de logs fraudebestendig, zodat een beheerder ze niet stilletjes kan bewerken?
4. Zijn de logs exporteerbaar in een bruikbaar formaat zodat de bewaarplicht kan worden vervuld?
5. Worden de logs minimaal zes maanden bewaard (Art. 26.6), of langer waar andere wetgeving dat vereist?
6. Waar logs persoonsgegevens bevatten, is de bewaring verzoend met het AVG-minimalisatiebeginsel via pseudonimisering?