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

Bijgewerkt: juni 2026

Dit is een expliciete providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry →-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-risico AI-systeem van een black boxblack boxInformal name for a system whose internal decision logic cannot be inspected or meaningfully explained.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 deployerdeployerAn organization using an AI system under its own authority in its activities — carrying operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → 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 wijziging ondergaat, voor het faciliteren van post-market monitoringpost-market monitoringProvider-side duty to systematically collect and act on experience from systems in use — the product-regulation half of continuous monitoring.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 principe 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 bewijs 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 toezicht 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 pseudonimisering 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?