Logging en bewaarplicht: praktische gids voor SaaS-teams

Logging en bewaring zijn onder de EU AI Act traceerbaarheidscontroles, geen opdracht om elk denkbaar gegeven onbeperkt te verzamelen. Voor AI-systemen met een hoog risico eist artikel 12 dat het systeem gedurende de levenscyclus technisch automatische registratie van gebeurtenissen mogelijk maakt. Aanbieders en gebruiksverantwoordelijken moeten automatisch gegenereerde logs onder hun controle bewaren gedurende een doelmatige periode en in beginsel minstens zes maanden, tenzij ander toepasselijk recht anders bepaalt.

Dit geldt niet automatisch voor elke AI-functie of SaaS-onderneming. Het team moet eerst systeem, beoogd doel, eigen rol en hoog-risicoclassificatie vaststellen. Ook moet het onderscheid maken tussen logs van de aanbieder en gegevens onder controle van klant of upstreamleverancier. Het doel is een proportionele bewijsketen waarmee een bevoegde reviewer een relevante gebeurtenis kan verbinden aan systeemversie, input- en outputcontext, menselijke actie, controle en besluit.

Ook vóór toepasselijkheid van de hoog-risicoregels helpt deze discipline bij incidentonderzoek, beveiligingsmonitoring, klantvragen, wijzigingsbeheer en verdedigbare productbesluiten. Het antwoord is geen willekeurige surveillance, maar doelbewuste logging met vastgelegde doelen, toegang, reviewtriggers en grenzen.

Begin met de scope, niet met het platform

Documenteer productfunctie, modellen en diensten van derden, doel, gebruikers, betrokken personen, inputs, outputs, integraties, omgevingen en beïnvloede besluiten. Alleen de API-aanroep naar een foundation model loggen kan retrievaldata, bedrijfsregels, overrides of vervolgacties missen die samen de SaaS-workflow vormen.

Bepaal daarna de rol. Wie onder eigen naam een hoog-risicosysteem ontwikkelt of verkoopt, kan aanbieder zijn; een klant die andermans systeem gebruikt kan gebruiksverantwoordelijke zijn. Rebranding, een wezenlijke wijziging of een ander doel kan verantwoordelijkheden verschuiven. Contractlabels beslissen dit niet.

Beoordeel vervolgens de classificatie. Artikel 6 omvat systemen bij producten in bijlage I en toepassingen in bijlage III, met voorwaarden en uitzonderingen. Sollicitanten rangschikken vraagt een andere analyse dan interne marketingtekst opstellen. Leg reden, reviewer, datum, aannames en herbeoordelingstriggers vast. Zie ook hoe AI-governance complianceverwachtingen verandert.

Wat de AI Act eist

Volgens de AI Act vereist artikel 12 automatische gebeurtenisregistratie gedurende de levenscyclus. De functies moeten passende traceerbaarheid bieden, risico's of wezenlijke wijzigingen helpen herkennen, post-market monitoring ondersteunen en gebruiksverantwoordelijken de werking laten bewaken.

Welke gebeurtenissen nodig zijn hangt van het systeem af. Voor bepaalde biometrische identificatiesystemen in bijlage III noemt artikel 12 extra minimuminformatie. Dat specialistische schema kopiëren naar een ander product bewijst geen compliance. Leid events af uit doel, risico's, prestatielimieten, menselijk toezicht, instructies en monitoringplan.

Artikel 19 verplicht aanbieders automatisch gegenereerde logs onder hun controle gedurende een passende periode van minstens zes maanden te bewaren, tenzij EU- of nationaal recht, vooral gegevensbescherming, anders bepaalt. Artikel 26 bevat een parallel minimum voor gebruiksverantwoordelijken. Dit is geen toestemming tot onbeperkte opslag. Het schema moet traceerbaarheid verenigen met minimalisatie, opslagbeperking, beveiliging, arbeids- en sectorregels, contracten en incidentbehoeften.

Na Verordening (EU) 2026/1744 gelden deze eisen vanaf 2 december 2027 voor bijlage III en vanaf 2 augustus 2028 voor systemen in gereguleerde producten van bijlage I. De tijdlijn van de Commissie toont deze data.

Wat moet worden vastgelegd

Een nuttig event beantwoordt een reviewvraag en bewijst niet alleen dat een server draaide:

1. Systeem en versie: stabiele ID, model of component, configuratie, omgeving en release.
2. Tijd en correlatie: betrouwbare tijdstempel, request- of transactie-ID en koppelingen.
3. Operationele context: functie, beoogde workflow, gebruikers- of servicerol en relevante instellingen.
4. Input en output: verwijzingen, hashes, gestructureerde samenvattingen of beschermde snapshots wanneer reconstructie gerechtvaardigd is.
5. Menselijk toezicht: review, goedkeuring, afwijzing, override, escalatie en bevoegdheid.
6. Controles: beleidschecks, drempels, filters, toegang, fouten, fallbacks en resultaat.
7. Wijziging en monitoring: deployments, model- of datawijzigingen, drift, incidenten, klachten en correcties.
8. Integriteit: bron, toegangshistorie, bewaring en transformatie of verwijdering.

Bewaar niet automatisch volledige prompts, documenten, antwoorden of identiteiten. Soms is inhoud nodig voor een onderzoek; elders volstaan pseudoniem, hash, categorie, metriek of beschermd voorbeeld. Beslis per veld op basis van gedocumenteerde doelen en risico's.

Praktische workflow

1. Leg de loggingbeslissing vast

Noteer per systeem scope, doel, rol, classificatie, plichten, monitoringdoelen, datacategorieën en eigenaren. Scheid eigen logs van leverancier- of klantafhankelijke gegevens. Vermeld aannames en triggers.

2. Koppel vragen aan events

Begin met vragen: welke versie maakte dit resultaat? Was menselijke review vereist en uitgevoerd? Ging een controle af? Paste het gebruik bij het doel? Wat veranderde vóór de achteruitgang? Koppel minimale betrouwbare velden en bronnen.

3. Verdeel eigenaarschap

Engineering bezit meestal instrumentatie en kwaliteit; security toegang, integriteit, alerts en bewaring; product workflow en releases; data/ML model-, dataset- en evaluatie-ID's; privacy rechtmatigheid en minimalisatie; compliance de eisenkaart. Eén eigenaar coördineert zonder feiten namens anderen te verzinnen.

4. Stel toegang en bewaring vast

Scheid operationele toegang van onderzoekstoegang. Gebruik least privilege, authenticatie, toegangslogging, encryptie en exportcontrole. Definieer start, verwijdering, uitzonderingen, holds en backups, plus afspraken tussen aanbieder en gebruiksverantwoordelijke.

5. Verbind reviews aan triggers

Herbeoordeel na relevante wijzigingen aan model, prompt, retrieval, drempel, data, integratie, doel of toezicht en na incident, klacht, onverwachte prestatie, ongeoorloofd gebruik of leveranciersmelding. Koppel de uitkomst aan de productieversie.

6. Test reconstructie en verwijdering

Laat een onafhankelijke reviewer versie, controles, menselijke acties en opvolging reconstrueren. Test daarna verwijdering uit primaire opslag, analytics, exports en backups. Beide hebben bewijs nodig.

Veelgemaakte fouten

Alles standaard loggen. Meer data kan privacy-, beveiligings-, proces- en kostenrisico's vergroten zonder traceerbaarheid.

Telemetrie verwarren met een AI-audittrail. Uptime en errors identificeren zelden model, configuratie, toezicht en bewijs achter een resultaat.

Zes maanden op elk record toepassen. Het minimum ziet op automatische hoog-risicologs onder controle van de operator en blijft onderworpen aan ander recht.

Controlegrenzen negeren. Een aanbieder bewaart niet wat hij nooit ontvangt; de gebruiksverantwoordelijke mag niet aannemen dat een vendor zijn context bewaart.

Gevoelige inhoud zonder waarborgen verzamelen. Prompts en outputs kunnen persoonsgegevens of geheimen bevatten. Minimaliseer, scheid, versleutel en monitor.

Onbegrijpelijke events bewaren. Zonder schema, tijd, versie of correlatie kunnen zij nutteloos zijn.

Voorbeeld: AI-ondersteunde werving

Een SaaS-aanbieder rangschikt sollicitaties. Het team documenteert doel, systeemgrens, rol en classificatie. Events verbinden productiemodel en configuratie met elke ranking, inputverwijzingen, outputcontext, drempels, waarschuwingen, menselijke review, override en eindactie.

Toegang tot inhoud is beperkt tot bevoegd onderzoek; routinemonitoring gebruikt waar mogelijk aggregaten. De bewaartermijn licht artikel 19, gegevensgrenzen, klantverantwoordelijkheid en sectorale termijnen toe. Een wijziging in model, drempel of review activeert een beoordeling en bewaart de koppeling tussen oud en nieuw bewijs.

Dit ontwerp garandeert op zichzelf geen compliance, maar maakt wel toetsbaar of het systeem gedocumenteerd werkte, mensen toezicht uitoefenden en wijzigingen of incidenten verantwoord werden behandeld.

FAQ

Wat is het praktische doel?

Relevante systeemactiviteit traceerbaar maken door event, versie, context, controles, menselijke acties en opvolging te verbinden zonder irrelevante data.

Wanneer gelden de plichten voor SaaS-teams?

Artikelen 12, 19 en 26 zien op hoog-risicosystemen en verdelen eisen naar rol en controle. Bevestig systeem, doel, classificatie en rol.

Moet elke prompt en respons worden bewaard?

Nee. Passende traceerbaarheid is geen willekeurige opslag. Kies noodzakelijke velden en bescherm ze.

Hoe lang moeten logs worden bewaard?

Automatische hoog-risicologs onder controle van aanbieders of gebruiksverantwoordelijken worden in beginsel passend en minstens zes maanden bewaard. Andere wetgeving kan een andere duur eisen of beperken.

Waar begint een team?

Inventariseer systeem, rol, classificatie, bronnen en vragen. Definieer daarna minimaal schema, eigenaarschap, toegang, bewaring, triggers en reconstructietest.

Bronnen

• Verordening (EU) 2024/1689, vooral artikelen 6, 12, 19 en 26.
• Verordening (EU) 2026/1744 en gewijzigde data.
• Europese Commissie, “AI Act”, tijdlijn en hoog-risicoverplichtingen.