Wanneer logging en bewaarplicht gelden en wat u vervolgens doet

Logging en bewaring gelden niet voor elke SaaS-functie op dezelfde manier. De specifieke artikelen 12, 19 en 26 van de EU AI Act zien op AI-systemen met een hoog risico en hangen af van de rol als aanbieder of gebruiksverantwoordelijke en van de logs waarover de organisatie controle heeft. Andere systemen kunnen gegevens nodig hebben voor beveiliging, privacy, contracten, kwaliteit of incidenten, maar dat zijn niet automatisch de hoogrisicoverplichtingen.

Begin daarom bij de scope: systeem, beoogd doel, workflow, rol, classificatie en bewijsvragen. Leg daarna alleen gebeurtenissen en beslissingen vast die traceerbaarheid, monitoring, toezicht en onderzoek ondersteunen. Beveilig ze, motiveer de termijnen en test of een bevoegde reviewer een materiële gebeurtenis kan reconstrueren.

Wat de AI Act verlangt

Artikel 12 vereist dat hoogrisicosystemen tijdens hun levensduur technisch automatische registratie mogelijk maken. Dit moet passende traceerbaarheid bieden, risico's of ingrijpende wijzigingen helpen herkennen en post-market- en operationele monitoring ondersteunen.

Voor aanbieders is dit een ontwerpeis. Artikel 19 verplicht hen automatisch gegenereerde logs onder hun controle te bewaren; artikel 26 legt een parallelle plicht op aan gebruiksverantwoordelijken. In beginsel geldt minimaal zes maanden, tenzij ander toepasselijk recht anders bepaalt, en de periode moet passen bij het beoogde doel. Los daarvan bewaart de aanbieder bepaalde technische, kwaliteits- en conformiteitsdocumentatie tien jaar.

Er is geen universeel schema. Artikel 12 noemt minimumgegevens voor bepaalde biometrische systemen, maar andere ontwerpen moeten proportioneel zijn. De AI Act-gids voor SaaS-aanbieders behandelt rollen en classificatie.

Wanneer de specifieke plichten gelden

Beantwoord vier vragen: valt de functie onder de definitie van AI-systeem; is zij hoog risico op grond van artikel 6 en bijlage I of III; welke rol heeft het bedrijf; en welke logs controleert het daadwerkelijk? Klassieke regels en automatisering worden niet door gegevensverwerking alleen AI. Het beoogde gebruik en uitzonderingen zijn bepalend.

Een SaaS-bedrijf dat ontwikkelt en onder eigen naam aanbiedt, kan aanbieder zijn. Een organisatie die een systeem van een ander onder eigen gezag gebruikt, kan gebruiksverantwoordelijke zijn. Een nieuw doel, rebranding of ingrijpende wijziging kan de rol wijzigen. Aanbieder en klant beheersen vaak verschillende delen van de bewijsstroom.

De wijziging van 2026 stelde de data op 2 december 2027 voor artikel 6 lid 2 en bijlage III, en 2 augustus 2028 voor artikel 6 lid 1 en bijlage I. Ontwerp tijdig: ontbrekend historisch bewijs ontstaat niet achteraf.

Wanneer andere gegevens toch nodig zijn

Buiten hoog risico kunnen authenticatie-, configuratie- en incidentgebeurtenissen nodig zijn voor beveiliging; toestemming, verzoeken, toegang of verwijdering voor privacy; service- en wijzigingshistorie voor contracten; en versies, evaluaties, goedkeuringen en rollback voor kwaliteit.

Noem per klasse het werkelijke juridische, contractuele, beveiligings- of operationele doel. “Niet hoog risico” betekent niet “niets bewaren”, maar de AI Act rechtvaardigt evenmin onbeperkte opslag van prompts, documenten, outputs en identiteit. Soms volstaat een identifier, beschermde verwijzing, hash, gestructureerde uitkomst of steekproef.

Praktische workflow

1. Leg doel, gebruikers, betrokkenen, beslissing, input, output, omgevingen, integraties, modellen, bronnen, vervolgacties en menselijke beoordeling vast.
2. Documenteer rol, classificatie, feiten, reviewer, goedkeuring, onzekerheid en triggers. Gebruik voor derden de vragen vóór invoering van interne AI-tools.
3. Formuleer bewijsvragen: welke versie leverde de output, welke bron en controles werden gebruikt, vond menselijke review plaats en welke vervolgactie ontstond?
4. Koppel elk antwoord aan minimale records zoals transactie-ID, betrouwbare tijd, versies, context, input- en outputreferenties, controleresultaat, menselijke actie, vervolguitkomst en integriteitsinformatie.
5. Benoem een eindverantwoordelijke en eigenaren voor instrumentatie, toegang, privacy, bewijsverzoeken, uitzonderingen, verwijdering en herstel. Pas sterke authenticatie, versleuteling, exportbeperkingen en monitoring toe.
6. Stel termijnen per klasse vast en test reconstructie en verwijdering afzonderlijk in productie, analytics, exports, archieven en toepasselijke backups.

Fouten en volgende stap

Gewone telemetrie is niet vanzelf een audittrail: beschikbaarheid en latency verklaren zelden configuratie, controles en menselijk handelen. Eén partij beheert niet altijd de hele keten; contracten, documentatie en echte configuratie moeten overeenkomen. Gebruik zes maanden niet voor alles en ontwerp niet alleen voor een audit. Herbeoordeel bij releases, leverancierswijzigingen, risico's en incidenten. Zie veelgemaakte logging- en bewaarfouten.

Kies één belangrijke workflow en maak een systeempagina met grens, doel, rol, classificatie, bronnen, vragen, eigenaren en triggers. Koppel vijf tot tien vragen aan minimale records en voer vóór de volgende release een onafhankelijke reconstructietest uit. Dit sluit aan bij veranderende AI-governanceverwachtingen en door inkopers gevraagde AI-controls.

FAQ

Geldt dit voor elke AI-functie?

Nee. De besproken artikelen gaan over hoogrisicosystemen; andere doelen kunnen toch records vereisen.

Bewaren aanbieder en gebruiksverantwoordelijke dezelfde logs?

Niet per se. Elk bewaart de relevante automatische logs onder eigen controle.

Is zes maanden altijd juist?

Nee. Het is het algemene minimum voor de betrokken hoogrisicologs, behoudens ander recht. Andere gegevens kunnen andere termijnen hebben.

Bronnen

• Verordening (EU) 2024/1689, artikelen 12, 18, 19 en 26.
• Verordening (EU) 2026/1744 over de gewijzigde data.
• Europese Commissie, “AI Act”, actuele tijdlijn.