Monitoring na het in de handel brengen (AI Act)

Wat is monitoring na het in de handel brengen?

Monitoring na het in de handel brengen is de plicht om een AI-systeem met een hoog risico te blijven opvolgen nadat het in gebruik is, in plaats van het een keer na te kijken voor het live gaat en er daarna van uit te gaan dat het blijft zoals je het achterliet. Artikel 3, punt 25 van de AI Act omschrijft het als alle activiteiten van een aanbieder om "ervaring die is opgedaan met het gebruik van door hen in de handel gebrachte of in gebruik gestelde AI-systemen" te verzamelen en te evalueren, zodat je op tijd merkt dat er iets bijgestuurd moet worden.

De plicht ligt verdeeld over twee bedrijven. Artikel 72 legt bij de aanbieder een monitoringsysteem en een geschreven plan. Artikel 26, lid 5 legt bij de gebruiksverantwoordelijke, het bedrijf dat het systeem onder eigen verantwoordelijkheid inzet, de plicht om de werking op te volgen en de aanbieder te laten weten wat het ziet. Artikel 26, lid 6 voegt het stuk toe waar bedrijven vroeg of laat naar gevraagd worden: de logs die het systeem automatisch aanmaakt minstens zes maanden bewaren. In welke rol je zit, wordt per systeem beslist, en het lemma over aanbieder en gebruiksverantwoordelijke werkt die toets uit.

Het raakt niet elke AI-tool die je in huis hebt, want alles hangt vast aan de hoog-risico klasse. Een chatbot op je website valt buiten artikel 72, een systeem dat sollicitanten rangschikt niet. Dat hoog-risico regime is zelf verschoven: verordening (EU) 2026/1744, de digitale omnibus rond AI, van kracht sinds 27 juli 2026, duwde losstaande systemen uit bijlage III naar 2 december 2027 en AI die in producten uit bijlage I zit naar 2 augustus 2028.

Waarom een controle voor de lancering niet volstaat

Gewone productveiligheid werkt omdat een transportband die volgens plan gebouwd is, zich als een transportband blijft gedragen. Een AI-systeem geeft je die zekerheid niet. Wat het doet, hangt af van de data die het tegenkomt, en die data is de wereld, en die beweegt. Een systeem kan dus eerlijk door zijn beoordeling geraken en zes maanden later slechter presteren zonder dat iemand er iets aan veranderd heeft. De mix van mensen die solliciteert is veranderd, er is een productlijn bijgekomen, een veld in een formulier kreeg een andere naam en de helft van de invoer komt nu leeg binnen. Het model antwoordt met dezelfde zekerheid als op dag een, en net dat maakt de achteruitgang van buitenaf moeilijk te zien. Model drift en data drift zijn de lemma's over dat mechanisme zelf.

Overweging 155 zegt waarom het er staat: het monitoringsysteem moet ervoor zorgen dat risico's van systemen die na hun ingebruikname blijven bijleren op tijd aangepakt raken. Een systeem dat zichzelf blijft bijwerken is de scherpe versie. Een bevroren model in een bewegende wereld is de versie die je in een Belgisch bedrijf het vaakst tegenkomt.

Wat de aanbieder moet bouwen

Artikel 72, lid 1 vraagt de aanbieder om een monitoringsysteem op te zetten en te documenteren, in verhouding tot de technologie en tot de risico's. Lid 2 zegt wat het moet doen: "actief en systematisch relevante data verzamelen, documenteren en analyseren" over hoe het systeem gedurende zijn hele levensduur presteert, data die van gebruiksverantwoordelijken kan komen of uit andere bronnen. Actief sluit uit dat je wacht tot er klachten binnenkomen, en het doel ervan is beoordelen of het systeem nog altijd voldoet aan de eisen waaraan het bij aanvang getoetst werd: datakwaliteit, nauwkeurigheid, menselijk toezicht, logging. Lid 3 maakt daar een document van, het plan voor monitoring na het in de handel brengen, dat bij de technische documentatie van bijlage IV hoort.

De verordening gaf de Commissie tot 2 februari 2026 om daar een sjabloon voor vast te leggen. De AI Act-pagina van de Commissie zelf, laatst bijgewerkt op 3 augustus 2026, somt de richtsnoeren en praktijkcodes op die ze gepubliceerd heeft, en dat sjabloon zit er niet bij. Als koper kan je er wel naar vragen, of minstens naar het stuk dat zegt welke gegevens je leverancier van jou verwacht en hoe. Een leverancier die daar geen antwoord op heeft, heeft er waarschijnlijk geen geschreven.

Wat jij moet doen als gebruiksverantwoordelijke

Artikel 26, lid 5 is een zin: gebruiksverantwoordelijken volgen de werking van het hoog-risico AI-systeem op aan de hand van de gebruiksaanwijzing en brengen, waar relevant, de aanbieder op de hoogte overeenkomstig artikel 72. Daar volgen twee dingen uit die makkelijk over het hoofd gezien worden.

Het eerste is dat de gebruiksaanwijzing de meetlat is, niet jouw eigen idee van goed presteren. Lees die tekst dus en haal eruit waarvoor het systeem dient, waar het zwak zit, en welke maatregelen de aanbieder van jou verwacht. Staat daar niets over in, dan zit dat gat bij de leverancier. Het tweede is dat jij een gegevensbron bent voor de monitoring van iemand anders, want wat jij ziet, ziet de aanbieder meestal niet: welke dossiers je mensen overruled hebben en waarom, welke klachten binnenkwamen, welke output nooit iemand gebruikt heeft.

Dan artikel 26, lid 6: de logs die het systeem automatisch aanmaakt bewaar je, voor zover ze onder jouw controle staan, gedurende een periode die past bij het beoogde doel en in elk geval minstens zes maanden. Zes maanden is een ondergrens en geen streefcijfer. Kan een beslissing waar het systeem aan meewerkt een jaar later nog betwist worden, en bij aanwervingen en kredieten kan dat, dan geven zes maanden logs geen antwoord op de vraag die je krijgt. Aanbieders dragen dezelfde plicht in artikel 19, met hetzelfde minimum. En "voor zover ze onder jouw controle staan" is de zinsnede om op te letten bij cloudsoftware: de logs staan bij de leverancier, dus wie ze kan exporteren en wat er gebeurt op de dag dat je stopt met betalen, zijn contractvragen.

Opvolgen en melden zijn twee verschillende plichten

Opvolgen loopt continu en levert meestal niets spectaculairs op. Melden is wat gebeurt als er iets over een grens gaat. Artikel 73 legt de drempels en de klokken vast voor ernstige incidenten, en het lemma AI-incident werkt uit wat meetelt, wie meldt en hoe snel. Het verband dat je moet onthouden: door op te volgen merk je het, en dankzij de logs kan je daarna zeggen wie er geraakt is.

Waar je effectief naar kijkt

Artikel 12 zegt dat een hoog-risico systeem technisch de automatische registratie van gebeurtenissen gedurende zijn levensduur mogelijk moet maken, en noemt waar die logs voor dienen: situaties herkennen waarin het systeem een risico vormt of substantieel gewijzigd is, de monitoring van de aanbieder voeden, en jou de werking laten opvolgen. Dat is de vorm van wat je in de gaten houdt.

• Doet het nog wat de documentatie zegt. Meet tegen de nauwkeurigheid die de aanbieder claimt, niet tegen een cijfer dat je zelf verzonnen hebt.

• Is de populatie verschoven. De output kan er prima uitzien terwijl de invoer stilaan niet meer lijkt op waarvoor het systeem gebouwd is.

• Wat overrulen je mensen. Overrules zijn het goedkoopste signaal dat je krijgt, want een mens heeft de analyse al gedaan. Nul op zes maanden betekent meestal dat er niemand echt kijkt, en daar gaat het lemma menselijk toezicht dieper op in.

• Waarover klagen mensen. Artikel 85 laat iedereen klacht neerleggen bij de markttoezichtautoriteit, en een klacht die je zelf afgehandeld hebt, is er een die daar nooit terechtkomt.

• Elk incident en elk bijna-ongeval, ook die binnen de muren gebleven zijn.

Het meeste daarvan overlapt met wat een bedrijf al draait. Heb je LLM-observability of een AgentOps-opzet, dan worden invoer, uitvoer, doorlooptijd en kost al gelogd. Draait een dataploeg driftcontroles, dan is de helft van de populatievraag beantwoord, en de klachten van de klantendienst staan al ergens genoteerd. Het werk zit zelden in iets nieuws bouwen. Het zit in beslissen welke daarvan het officiële spoor is, het lang genoeg bijhouden, en een naam zetten op wie het leest.

Monitoring na het in de handel brengen tegenover de conformiteitsbeoordeling

De twee worden in een adem genoemd en beantwoorden een andere vraag. Wat ze uit elkaar houdt, is het moment in het leven van het systeem waarop ze gebeuren.

De conformiteitsbeoordeling is een poort. Ze gebeurt voor het systeem in de handel gebracht wordt, ze is werk voor de aanbieder, ze beoordeelt het systeem op een moment, en ze eindigt in een EU-conformiteitsverklaring en een CE-markering. Erdoor geraken is een voorwaarde om te mogen verkopen. Monitoring na het in de handel brengen is een plicht die loopt. Ze begint waar die poort eindigt en duurt zolang het systeem bestaat, en artikel 72, lid 2 noemt als doel het beoordelen van de blijvende conformiteit met diezelfde eisen. Dezelfde meetlat, een ander moment. Een substantiële wijziging stuurt het systeem trouwens terug door een nieuwe beoordeling, en door op te volgen merk je dat er een gebeurd is.

Voor een gebruiksverantwoordelijke is de vertaling kort: de beoordeling is iets waarvan je nakijkt of de leverancier ze gedaan heeft, de monitoring is iets wat je zelf doet, zolang het systeem aanstaat.

Een jaar later om bewijs gevraagd

Een transportbedrijf met negentig mensen gebruikt een tool die sollicitaties voor magazijn- en chauffeursvacatures scoort. Aanwerving staat in bijlage III, dus het systeem heeft een hoog risico en het bedrijf is gebruiksverantwoordelijke. In maart wordt een kandidate afgewezen. In februari van het jaar erna schrijft haar advocaat, en de vraag is terecht: op welke basis, en heeft er een mens naar gekeken.

Het antwoord moet uit stukken komen, en de lijst is langer dan ze lijkt. De logregel van die sollicitatie, met wat erin ging, welke score eruit kwam en wanneer. De versie van het systeem die die dag draaide, want de leverancier heeft het model in juni bijgewerkt. Het bewijs dat de hr-verantwoordelijke in maart aangeduid was als toezichthouder en dit dossier bekeken heeft en niet enkel de hele lichting, of ze de score overruled heeft, en zo niet, wat ze te zien kreeg toen ze ermee akkoord ging. De gebruiksaanwijzing in de versie die toen gold. En de melding die de kandidate gekregen heeft dat er een systeem in het spel was, wat artikel 26, lid 11 verplicht.

Elf maanden later is die ondergrens van zes maanden al lang voorbij. Een bedrijf dat niets meer bijhield dan het minimum heeft geen logs van maart, ziet in het portaal van de leverancier alleen de huidige modelversie staan, en zijn eerlijke antwoord is dat het het niet weet. Daar is niets technisch misgelopen. Er is een bewaartermijn die niemand gekozen heeft.

De versie die wel werkt, weegt niet veel zwaarder. De tool exporteert zijn logs maandelijks naar een map die mee in de back-up zit en bewaard blijft zolang er over die beslissing nog een claim kan komen, en bij een aanwerving is dat jaren en geen maanden. Elke export draagt het versienummer dat de leverancier die maand publiceerde. De beslissing van wie nakeek is een lijn: akkoord, overruled of opzijgelegd, met een reden in een paar woorden. Dat opzetten is een voormiddag werk.

Daarom is de beslissing die eerst moet vallen niet welke metriek je gaat volgen. Het is waar de logs staan en hoelang ze bewaard blijven. Een metriek die je niet volgde, kan je morgen beginnen volgen. Een maand die je niet bewaard hebt, is weg.