In het kort
- Een agentregister veroudert zodra agents veranderen. Laat elke wijziging melden en vergelijk met de goedgekeurde versie.
- Schuift het doel op naar hoog-risico, dan bent u vanaf 2 december 2027 aanbieder (Artikel 25, lid 1, onder c).
- Onder de AVG kan een wijziging de doelbinding, de DPIA (Artikel 35, lid 11) en het verwerkingsregister raken.
- Geef elke agent een vaste sleutel en beoordeel per veld wat er verandert, op elk platform.
Hoe houdt u AI-agents bij die na hun registratie veranderen? Het korte antwoord: laat elke wijziging melden en vergelijk die met de versie die u goedkeurde. Een register dat alleen de eerste aanmelding vastlegt, klopt na een paar maanden niet meer. En een wijziging kan een agent onder zwaardere regels brengen.
Waarom een agentregister na een paar maanden veroudert
Een agent blijft niet hetzelfde. De bouwer koppelt er een extra systeem aan, de agent mag ineens zelf mails versturen in plaats van concepten klaarzetten, of hij krijgt een taak bij een andere afdeling. Bij gewone software loopt zo'n aanpassing via een releaseproces. Maar agents ontstaan vaak buiten IT: in Copilot Studio bij finance, in n8n bij marketing, met een AI-bouwtool bij een collega die geen ontwikkelaar is.
Het gevolg is een register dat de eerste versie van elke agent beschrijft. Wie het opent voor een audit of voor een vraag van de functionaris gegevensbescherming, leest wat de agent in het voorjaar deed. Hoe u zo'n register opzet, staat in AI-agentregister opzetten. Dit artikel gaat over wat er daarna gebeurt.
Wanneer telt een wijziging onder de AI Act?
De AI Act kent geen apart regime voor agents. Het risico volgt wat het systeem doet (Artikel 6), dus een wijziging telt zodra hij verandert wat de agent doet, voor wie, of met hoeveel zelfstandigheid. Twee bepalingen maken dat concreet.
Het doel schuift opWijzigt een organisatie het beoogde doel van een AI-systeem dat niet als hoog-risico was geclassificeerd, zodanig dat het systeem hoog-risico wordt, dan wordt zij zelf als aanbieder beschouwd, met de plichten van Artikel 16 (Artikel 25, lid 1, onder c). Een agent die eerst vacatureteksten opstelde en nu sollicitaties filtert en kandidaten rangschikt, kan zo onder Bijlage III, punt 4, onder a vallen.
De werking verandertBij een hoog-risicosysteem monitort de gebruiksverantwoordelijke de werking op basis van de gebruiksaanwijzing (Artikel 26, lid 5). Daarvoor moet u weten dat een agent is aangepast.
Beide plichten gelden voor Bijlage III-systemen vanaf 2 december 2027. Draaide een systeem vóór die datum al, dan gaan de hoog-risicoregels voor dat systeem pas gelden zodra het vanaf die datum aanzienlijk in zijn ontwerp wordt gewijzigd (Artikel 111, lid 2). Dan moet u kunnen laten zien wat er veranderde en wanneer.
Wat een wijziging betekent onder de AVG
Verwerkt de agent persoonsgegevens, dan raakt een wijziging ook de AVG. Op drie plekken moet u dan iets doen.
Doelbinding
Persoonsgegevens mogen niet verder worden verwerkt op een manier die onverenigbaar is met het doel waarvoor ze zijn verzameld (Artikel 5, lid 1, onder b, AVG). Krijgt de agent een nieuwe taak, dan toetst u of dat doel verenigbaar is. Artikel 6, lid 4, AVG noemt waar u op let.
DPIA
Hoort bij de agent een gegevensbeschermingseffectbeoordeling, dan toetst u of de verwerking nog volgens die beoordeling loopt, ten minste wanneer het risico verandert (Artikel 35, lid 11, AVG).
Verwerkingsregister
Een nieuw doel, een nieuwe categorie persoonsgegevens of een nieuwe ontvanger, bijvoorbeeld via een extra koppeling, hoort terug te komen in het register van verwerkingsactiviteiten (Artikel 30, lid 1, AVG). Hoe dat register zich tot uw AI-register verhoudt, leest u in Moet een AI-systeem in het verwerkingsregister staan?
Agents op verschillende platforms en afdelingen
Het lastige is zelden één agent. Het zijn er twintig, gebouwd door vijf afdelingen op vier platforms. Elke afdeling houdt een eigen lijstje bij, als dat al gebeurt. Een centraal register blijft alleen actueel als de melding vanzelf gaat, op het moment dat iemand iets aanpast. Een jaarlijkse inventarisatie loopt achter op de dag dat hij af is.
Teams mogen daarbij elk hun eigen platform houden. Wat ze delen, is één vaste manier om een agent te beschrijven: dezelfde velden met dezelfde betekenis, of de agent nu in Copilot Studio, n8n of eigen code draait.
Zo richt u wijzigingsbeheer voor agents in
Geef elke agent een vaste sleutel
Een naam verandert en een eigenaar vertrekt. Een vaste sleutel, bijvoorbeeld de repo plus de map waarin de agent staat, zorgt dat een latere melding bij dezelfde agent terechtkomt.
Leg de gegevens vast naast de agent
Een klein bestand met doel, eigenaar, koppelingen, mate van zelfstandigheid en toezicht. Wie de agent aanpast, past dat bestand mee aan.
Laat elke wijziging melden
Bij oplevering en daarna bij elke aanpassing van dat bestand. Een melding zonder inhoudelijke verandering hoort niets in gang te zetten.
Beoordeel het verschil per veld
Wie een wijziging goedkeurt, ziet per veld wat er anders is. Tot de beslissing blijft de goedgekeurde versie gelden.
Plan een review na elke goedgekeurde wijziging
Een agent die meer mag, kan anders geclassificeerd moeten worden. Loop de classificatie, de DPIA en het verwerkingsregister na zodra de wijziging is goedgekeurd.
Drie manieren om een agent te laten melden
Welke route past, hangt af van hoe een team bouwt. De drie werken naast elkaar.
Zonder code
Wie met een AI-bouwtool of een low-code platform werkt, meldt de agent via het vaste aanvraagkanaal van de organisatie. Of hij zet een instructie in de projectinstructies van die tool, zodat de tool de melding doet.
Per repo
Een ontwikkelaar laat de pipeline van de repo het bestand melden bij elke wijziging. Dat kan in GitHub, GitLab en Azure DevOps.
Centraal
Bouwen veel teams in één GitHub-organisatie, dan loopt één centrale workflow dagelijks alle repo's langs en meldt elk bestand. Teams zetten dan alleen nog het bestand naast hun agent.
Wie beslist over een wijziging?
Een melding komt van de bouwer zelf. Wie iets bouwt, kan het gunstiger beschrijven dan het is. Leg vast wie een wijziging beoordeelt. Meestal is dat de eigenaar van het register, met de functionaris gegevensbescherming erbij zodra persoonsgegevens of een nieuw doel in het spel zijn. Raakt de wijziging een hoog-risicotoepassing, betrek dan ook de persoon aan wie u het menselijk toezicht hebt opgedragen (Artikel 26, lid 2).
Veelgestelde vragen
Moet ik een gewijzigde AI-agent opnieuw registreren onder de AI Act?
Nee, een intern register schrijft de AI Act nergens voor. Wel kan een wijziging van het beoogde doel uw organisatie tot aanbieder maken (Artikel 25, lid 1, onder c). Tot de plichten van Artikel 16 hoort dan registratie in de EU-databank voor een Bijlage III-systeem (Artikel 16, onder i, plus Artikel 49, lid 1). Een overheidsinstantie die zo'n systeem gebruikt, registreert daarnaast zelf het gebruik (Artikel 49, lid 3). Beide gelden vanaf 2 december 2027.
Telt een nieuwe versie van het taalmodel als wijziging?
Nee, alleen als het verandert wat de agent doet of voor wie. Een ander model dat dezelfde taak op dezelfde manier uitvoert, laat dat gelijk. Bij een hoog-risicosysteem kan een modelwissel wel een substantiële wijziging zijn (Artikel 3, punt 23). Brengt u die zelf aan in een systeem dat u alleen gebruikte, dan wordt u aanbieder (Artikel 25, lid 1, onder b). Leg een modelwissel vast.
Hoe vaak moet ik een AI-agent opnieuw beoordelen?
Eén keer na elke inhoudelijke wijziging, plus een vaste review. De wet laat de termijn open. Voor agents die zelf handelen is een review per kwartaal of per halfjaar een werkbare afspraak. Voor een agent die alleen voorstellen doet volstaat vaak een jaar.
Is een afdeling zelf verantwoordelijk als zij een agent aanpast?
Nee, de verantwoordelijkheid ligt bij de organisatie. De AI Act legt de plichten bij de aanbieder en de gebruiksverantwoordelijke. Dat is de organisatie als geheel: bij een bedrijf de rechtspersoon, bij de overheid de instantie (Artikel 3, punten 3 en 4). Intern wijst u per agent een eigenaar aan die wijzigingen meldt.
Wijzigingen bijhouden in één register
In AIComplianceHub meldt een agent zich bij elke wijziging opnieuw aan, ook vanuit een pipeline of met één centrale workflow voor een hele GitHub-organisatie. Is er inhoudelijk iets veranderd, dan ziet de beoordelaar per veld het verschil en geldt tot de beslissing de goedgekeurde versie. Zo werkt agent-governance in het platform.