Sprint Retrospective en AI: waarom verbeteringen niet aan het model kunnen worden gedelegeerd

Dit is het vijfde artikel in de serie over hoe AI de klassieke bijeenkomsten van een cross-functioneel ontwikkelingsteam verandert. In de eerdere delen behandelde ik Backlog Refinement, Sprint Planning, Daily Scrum en Sprint Review. De algemene conclusie wordt geleidelijk strenger: AI verzamelt goed input voor het gesprek, maar mag het gesprek zelf niet vervangen. In de Sprint Retrospective is deze grens extra belangrijk, omdat het team hier niet alleen taken en product bespreekt, maar ook eigen gewoonten, interacties, kwaliteit en het vermogen om te veranderen.

De Sprint Retrospective lijkt een zeer geschikte kandidaat voor AI. Aan het einde van de sprint is er al Jira, Git, pull requests, CI/CD, incidenten, chats, agenda, notities van de Daily Scrum, besluiten van de Sprint Review en soms ook korte enquêtes onder het team. Het model kan snel verzamelen: wat het werk het vaakst vertraagde, waar review-bottlenecks hingen, welke taken van dag tot dag doorschoven, waar de Definition of Done onduidelijk bleek, welke besluiten zich herhaalden, welke onderwerpen in eerdere retro's klonken en niet verdwenen.

Op het eerste gezicht is dit bijna ideale automatisering. Je hoeft de hele sprint niet opnieuw te herinneren. Je hoeft niet te discussiëren of wachten op review een echt probleem was of slechts iemands gevoel. Je hoeft niet handmatig tientallen tickets en discussiedraden door te nemen. AI kan feiten voorbereiden, patronen groeperen, root cause analysis voorstellen en zelfs action items voor de volgende sprint genereren.

Maar juist hier begint het grootste risico.

De Sprint Retrospective bestaat niet om een nette lijst verbeteringen te krijgen. De bedoeling is dat het team eerlijk ziet hoe het werkt, afspraken maakt over wat er moet veranderen en verantwoordelijkheid neemt voor die verandering. Als AI de retro in een lijst aanbevelingen verandert, kan het team een mooi document krijgen en het belangrijkste verliezen: psychologische veiligheid, gedeeld begrip van het probleem en echte follow-through.

“AI kan patronen belichten, maar verbetering begint pas wanneer het team het probleem erkent en zijn gedrag verandert.”

Waarom de Sprint Retrospective nodig is

In de Scrum Guide 2020 wordt de Sprint Retrospective heel praktisch beschreven: het team plant manieren om kwaliteit en effectiviteit te verhogen. Daarvoor inspecteert het Scrum Team hoe de sprint is verlopen vanuit het perspectief van mensen, interacties, processen, tools en de Definition of Done. Het team bespreekt wat goed ging, welke problemen ontstonden en hoe die problemen wel of niet zijn opgelost. Daarna bepaalt het de nuttigste veranderingen, en de meest significante verbeteringen moeten zo snel mogelijk worden aangepakt en kunnen in de Sprint Backlog van de volgende sprint terechtkomen.

De retrospective is dus geen emotionele ontlading aan het einde van de sprint. En ook geen formele ceremonie waarin drie kolommen moeten worden gevuld: wat ging goed, wat ging slecht, wat verbeteren we. Het is een gebeurtenis over het aanpassen van de manier van werken. In die zin is het direct verbonden met de algemene logica van Scrum: transparantie is nodig voor inspectie, inspectie is nodig voor aanpassing, en inspectie zonder aanpassing wordt leeg. De Scrum Guide benadrukt expliciet: de Scrum-gebeurtenissen zijn ontworpen om verandering uit te lokken, niet alleen om protocollen te produceren.

Als aanvullend richtsnoer is de Scrum Guide Expanded v2026.1nuttig, maar juist als companion-bron op basis van de Scrum Guide 2020, niet als een nieuwe canonieke versie van de Scrum Guide. Voor dit artikel is hij om twee redenen belangrijk. Ten eerste zegt hij dat reflectie effectiever is in een psychologisch veilige omgeving. Ten tweede beschrijft hij in het hoofdstuk over AI het model als supervised decision-making partner: AI kan transparantie, inspectie en aanpassing versterken, maar vervangt niet de menselijke verantwoordelijkheid en heft de empirische controle van het proces niet op.

Daarom zou ik het doel van de Sprint Retrospective beschrijven via vijf functies:

• de echte werkpatronen van het team zien, niet alleen de luidste meningen;
• interacties, processen, tools en de Definition of Done bespreken zonder angst voor straf;
• feiten scheiden van interpretaties en vermoedens;
• een klein aantal verbeteringen kiezen die het team echt bereid is te proberen;
• deze verbeteringen naar de volgende sprint brengen zodat ze een owner, een verificatiecriterium en een plek in het werk hebben.

Dit is het kader voor het gesprek over AI. Als een tool het team helpt deze functies beter uit te voeren, is hij nuttig. Als hij alleen een mooiere lijst action items maakt, kan hij handig zijn, maar maakt hij het team niet per se effectiever.

Wat er meestal misgaat

Het probleem met retrospectives is zelden dat het team problemen niet kan benoemen. Meestal zijn de problemen anders. Het team bespreekt opnieuw hetzelfde. Action items schuiven van sprint naar sprint door. Mensen praten voorzichtig, omdat ze niet schuldig willen lijken. De pijnlijkste onderwerpen worden vermeden. De Scrum Master haalt het format eruit, maar niet de verandering. Aan het eind is iedereen het eens met iets als 'laten we beter communiceren', en dat lost al volgende week op.

Onderzoek van Lehtinen, Itkonen en Lassenius in Empirical Software Engineering belicht deze kant van retrospectives goed. De auteurs bestudeerden 37 team-level retrospectives over bijna drie jaar en toonden verschillende belangrijke dingen aan: discussies gaan vaak over onderwerpen die dichtbij en door het team beheersbaar zijn, maar kunnen lijden aan participant bias; zonder hard evidence weerspiegelen ze niet altijd de realiteit; sommige onderwerpen komen lang terug, omdat ze ofwel van nature terugkeren, ofwel het team ze op zijn eigen niveau niet kan oplossen door complexiteit of gebrek aan beheersbaarheid.

Dit is een zeer bruikbaar kader voor AI. Het model kan inderdaad helpen om hard evidence te brengen waar eerder alleen een gevoel was. Bijvoorbeeld, het team zegt: 'reviews vertragen de sprint'. AI kan feiten naar boven halen: hoeveel PR's langer dan een dag wachtten, welke precies bleven hangen, welke opmerkingen zich herhaalden, waar nabewerking na merge plaatsvond. Dat is nuttiger dan discussiëren op basis van geheugen.

Maar ditzelfde kader heeft een keerzijde. Als het team niet over de ongemakkelijke oorzaak wil praten, maakt AI het niet eerlijker. Als het probleem buiten de invloedssfeer van het team ligt, kan het model een action item prachtig formuleren dat toch door niemand wordt uitgevoerd. Als mensen het context niet vertrouwen, discussiëren ze niet meer over het proces, maar over de vraag of AI hun werk correct heeft beschreven.

Waar AI echt helpt

AI heeft in de Sprint Retrospective een sterke zone van nut, als je niet probeert hem de verbetering zelf te laten uitvoeren. Ik zou hem gebruiken vóór de retro en na de retro, niet in plaats van de retro.

Maar hier is het belangrijk niet te veel te beloven. DORA State of AI-assisted Software Development 2025 beschrijft AI als versterker van bestaande sterke en zwakke punten van het organisatiesysteem. Voor een retrospective is dat bijna een ideale formulering: als het team al in staat is om het proces eerlijk te bespreken en verbeteringen tot actie te brengen, maakt AI de input rijker. Als de retro allang een veilig ritueel zonder follow-through is geworden, maakt AI dat ritueel alleen sneller en netter.

Voor de meeting kan AI input voor inspectie voorbereiden:

• terugkerende impediments verzamelen uit Daily Scrum, tickets, pull requests en incident notes;
• plekken vinden waar work items lang wachtten op review, testdata, een beslissing van de Product Owner of een externe afhankelijkheid;
• het plan vergelijken met Sprint Planning, de feitelijke beslissingen tijdens de sprint en het resultaat dat op Sprint Review werd besproken;
• afwijkingen benadrukken tussen de Definition of Done en hoe het team taken feitelijk afsloot;
• oude action items verzamelen en laten zien welke ervan zijn uitgevoerd, vergeten of herhaald;
• kandidaatvragen voor het gesprek formuleren: wat was feit, wat was interpretatie, en wat vereist verificatie.

Na de meeting kan AI helpen met follow-through: de gekozen action items zorgvuldig vastleggen, een owner toevoegen, een verificatiecriterium, een koppeling met de Sprint Backlog en een herinnering voor de volgende retrospective. Dat is vooral waardevol omdat het zwakke punt van veel retro's niet in de discussie zit, maar erin dat verbeteringen de volgende sprint niet halen.

Maar in al deze scenario's blijft AI een voorbereidende en ondersteunende laag. Het mag niet beslissen welk probleem het belangrijkst is. Het mag geen schuldigen aanwijzen. Het mag root cause niet als feit vaststellen. En het mag zeker niet automatisch een 'verbeterplan van het team' schrijven zonder levende verificatie.

Waarom AI de retrospective niet voor het team moet uitvoeren

De gevaarlijkste versie van een AI-assisted Retrospective ziet er volwassen uit. Het model verzamelt alle data, analyseert de stemming van het team, vindt 'de drie belangrijkste oorzaken van problemen', stelt action items voor en stuurt een samenvatting naar Slack of Confluence. Iedereen leest het, knikt, zet reacties, en de retro wordt korter. Soms begint het team zelfs te denken: als AI alles al heeft geanalyseerd, waarom zouden we een uur aan het gesprek besteden?

Het probleem is dat een retrospective niet alleen waardevol is door de conclusie. Ze is waardevol door het proces van gezamenlijk begrip. Het is voor het team belangrijk niet alleen de bewering 'review kost te veel tijd' te krijgen. Het moet het eens worden over waarom dat gebeurt, wat het team bereid is te veranderen, welke afweging het accepteert en wie de actie op zich neemt. Soms komt in dat gesprek naar boven wat niet uit data blijkt: angst om met een sterke developer in discussie te gaan, irritatie door onduidelijke product context, vermoeidheid door constante urgente taken, stilzwijgende onenigheid met de huidige Definition of Done.

Het klassieke werk van Amy Edmondson over psychologische veiligheid en leergedrag is hier belangrijk, niet als modieus buzzwoord, maar als praktisch richtsnoer. Als mensen niet het gevoel hebben dat ze problemen kunnen bespreken zonder interpersoonlijk risico, verwordt de retrospective tot veilige formuleringen. AI kan in zo'n situatie het protocol soepeler maken, maar het team niet eerlijker maken.

Sterker nog, AI kan de eerlijkheid verslechteren als het team het als monitoring ervaart. Als het model Slack, Jira, PR-commentaren en de agenda leest en vervolgens schrijft 'Aleksej reageert traag op reviews' of 'QA vertraagt vaak de datagereedheid', is dat geen ondersteuning van de retrospective meer. Dat is performance management onder het mom van procesverbetering. In zo'n omgeving gaan mensen zichtbare activiteit optimaliseren, met het model in discussie gaan en hun reputatie verdedigen in plaats van het echte proces te bespreken.

Daarom zijn bronnen zoals NIST Generative AI Profile, OWASP Top 10 for LLM Applications 2025, EDPB Opinion 28/2024 en ICO-materiaal over monitoring at work hier relevant. Niet als juridisch hoofdstuk van het artikel, maar als herinnering: retrospectieve data worden gemakkelijk gevoelig. Ze gaan over mensen, gedrag, conflicten, fouten, vertragingen, correspondentie en soms zwakke plekken in het management.

De praktische grens is simpel: AI in de retro moet work and system analyseren, not people. Dus vastgelopen werk, terugkerende verwachtingen, onduidelijke regels, hiaten in de Definition of Done, slechte handoffs, overbelaste procespunten. Niet 'wie heeft er slecht gewerkt', maar 'wat in het systeem zorgt ervoor dat we steeds weer op hetzelfde resultaat uitkomen'.

“Goede AI-input voor een retro kijkt naar vastgelopen werk en terugkerende patronen. Slechte AI-input verandert mensen in regels van een rapport.”

We vervolgen de casus: B2B LMS en e-mailherinneringen

We nemen dezelfde casus uit de eerdere artikelen: een B2B LMS-platform, verplichte cursussen, e-mailherinneringen aan medewerkers die de verplichte cursus niet voor de deadline hebben afgerond. Tijdens de Sprint Planning koos het team een nauw Sprint Goal: het systeem stuurt één correcte herinnering aan actieve medewerkers met een onafgeronde verplichte cursus voor de deadline en bewaart een verifieerbare verzendgeschiedenis. Tijdens de Daily Scrum volgde het team risico's rond deduplicatie, tijdzones en testdata. Tijdens de Sprint Review besprak het team wat dit verandert voor het product en de Product Backlog.

Nu komt de Sprint Retrospective. Zonder AI kan het gesprek snel vervallen in de gebruikelijke gevoelens. De backend zegt: 'we werden opgehouden door verduidelijkingen over eligibility'. QA zegt: 'de testdata kwam te laat'. De frontend zegt: 'de API veranderde midden in de sprint'. De product owner zegt: 'we hadden niet zoveel vragen over expiredverwacht'. De Scrum Master noteert: 'communicatie verbeteren', 'data eerder klaar hebben', 'minder eisen wijzigen'. De retro lijkt gedaan.

AI kan de input concreter maken. Het haalt de sprintgeschiedenis op en laat zien:

• vier PR's wachtten meer dan een dag op review, en allemaal hingen ze samen met retry logic en idempotency;
• drie keer veranderde de interpretatie van eligibility voor gedeactiveerde gebruikers;
• QA-data kwam drie dagen later dan het team bij de planning had verwacht;
• de Definition of Done vereiste geen verifieerbare verzendgeschiedenis voor negatieve scenario's;
• de oude action item 'kleinere PR's' was niet uitgevoerd en kwam terug als probleem;
• een deel van de discussies in Slack ging niet over de implementatie, maar over het ontbreken van een eenduidige beslissing over expired.

Dit is een goede input. Maar dit is nog geen retrospective.

De retrospective begint wanneer het team bespreekt wat hiervan echt moet veranderen. Bijvoorbeeld: niet 'eerder communiceren', maar 'bij de planning expliciet betwiste eligibility-statussen en hun product owner-beslissing vastleggen'. Niet 'QA moet sneller data klaar hebben', maar 'in de Sprint Backlog komt een apart work item voor testdata vóór de start van de implementatie van het kritieke scenario'. Niet 'minder PR's doen', maar 'voor wijzigingen in de notification architecture moet een PR in één review-scenario passen en vóór de start van het werk een review-owner hebben'. Niet 'de DoD verbeteren', maar 'de Definition of Done omvat nu een verifieerbare verzendgeschiedenis voor negatieve herinneringsscenario's'.

Dát zijn action items. Ze zijn concreet, verifieerbaar en gekoppeld aan de volgende sprint. AI hielp patronen zien. Het team koos de verandering.

Anti-patterns

Hieronder staan enkele anti-patterns die ik bij de invoering van AI in de Sprint Retrospective apart in de gaten zou houden.

1. AI-samenvatting vervangt het echte gesprek

Als het team alleen een gegenereerde samenvatting leest en ermee instemt, verliest de retro het belangrijkste. De goede vraag is niet 'heeft AI de sprint precies beschreven?', maar 'wat hiervan zijn we bereid in ons werk te veranderen?'.

2. Sentimentanalyse wordt de waarheid over het team

Toonanalyse kan een nuttig zwak signaal zijn, maar kent de context niet. Sarcasme, vermoeidheid, een lokaal conflict, een grap, stilte en een voorzichtige formulering laten zich slecht omzetten in een metriek. De stemming van het team kun je niet tot een grafiek reduceren.

3. AI zoekt schuldigen in plaats van systemische patronen

Zodra het model mensen gaat rangschikken op snelheid, activiteit of het aantal "gecreëerde blockers", verandert de retrospective in monitoring. Dit ondermijnt de psychologische veiligheid en verslechtert de kwaliteit van de informatie die mensen bereid zijn te delen.

4. Root cause wordt zonder verificatie aangenomen

Het model kan met vertrouwen schrijven: "de belangrijkste oorzaak van vertragingen zijn onduidelijke eisen". Maar dat kan slechts het zichtbare deel zijn. De werkelijke oorzaak kan liggen in architecturale schuld, conflicterende prioriteiten, ontbrekende testdata of angst om een probleem te escaleren. Root cause van AI is een hypothese, geen feit.

5. Action items worden te algemeen

"Communicatie verbeteren", "sneller reviewen", "beter voorbereiden" veranderen bijna nooit gedrag. Een goede action item moet antwoord geven op de vragen: wie doet het, wat verandert er precies, waar is dat zichtbaar in de volgende sprint en hoe verifieert het team het effect.

6. Verbeteringen belanden niet in de Sprint Backlog

De Scrum Guide staat toe dat de belangrijkste verbeteringen in de Sprint Backlog van de volgende sprint terechtkomen. Als het team een verbetering heeft gekozen, maar er geen aandacht, owner en plek in het werk aan heeft gegeven, is het geen improvement. Het is een wens.

Hoe de rollen veranderen

AI heft de verantwoordelijkheidsgebieden binnen het Scrum Team niet op, maar verandert de voorbereiding op het gesprek. Minder waarde in het handmatig reconstrueren van de sprintgeschiedenis. Meer waarde in eerlijke interpretatie, het kiezen van een klein experiment en het doorvoeren van de verbetering tot een resultaat.

Rol	Risico bij een slecht AI-scenario	Volwassen gebruik van AI
Ontwikkelaars	Discussieren met de AI-beoordeling van hun activiteit en verdedigen hun reputatie in plaats van het proces te bespreken.	Gebruiken feiten en patronen als input, maar kiezen zelf wat ze veranderen in engineering practices, review, DoD en handoffs.
Product Owner	Leest de AI-retro als een rapport over de prestaties van het team en drukt op snelheid.	Helpt productonduidelijkheid wegnemen, beslissingen verduidelijken die het team afremden en verbeteringen ondersteunen in de volgende Sprint Backlog.
Scrum Master	Draagt de facilitatie over aan het model en krijgt een net protocol in plaats van een eerlijk gesprek.	Gebruikt AI-input voor de voorbereiding, maar beschermt de psychologische veiligheid, de focus op het systeem en de follow-through van gekozen action items.
Quality Engineer / QA-engineer	Krijgt de rol van "bron van vertragingen" als het model problemen oppervlakkig aan testen koppelt.	Helpt kwaliteitssignalen te vertalen naar wijzigingen in de Definition of Done, test-data ownership en observeerbaarheid.
UX/UI-ontwerper	Valt buiten de retro, omdat AI vooral code, PR's en ontwikkeltaken analyseert.	Belicht interacties, beslissingen en gebruikerscontext die van invloed waren op de kwaliteit van het werk van het team en het product.
Engineering Lead / Tech Lead	Gebruikt de AI-retro als dashboard voor controle over engineers.	Helpt systemische engineering bottlenecks te onderscheiden van individuele activiteit en kiest een technische verbetering die echt in de volgende sprint past.

Praktisch filter voor een AI-assisted Retrospective

Ik zou niet beginnen met het idee "laat AI de retro leiden". Ik zou beginnen met een nauwere vraag: welke input helpt het team eerlijker de manier van werken te inspecteren en een of twee verbeteringen te kiezen die het daadwerkelijk uitvoert?

AI-input voor de Sprint Retrospective is nuttig als het helpt antwoord te geven op de vragen:

• welke problemen herhaalden zich en welke waren eenmalig;
• welke feiten het thema bevestigen en welke een mening of emotionele beoordeling zijn;
• wat binnen de invloedssfeer van het team ligt en wat hulp vereist van Supporters, management of een ander team;
• welke oude action items niet zijn uitgevoerd en waarom;
• welk ene proces, instrument, working agreement of Definition of Done het waard is om in de volgende sprint te wijzigen;
• hoe het team verifieert dat de wijziging heeft gewerkt.

En omgekeerd: als AI-input vooral antwoord geeft op de vraag "wie was de bottleneck", is dat een gevaarlijk signaal. De retrospective moet het team helpen het werksysteem te verbeteren, niet een verborgen ranglijst van deelnemers produceren.

Data en grenzen

De Sprint Retrospective is bijzonder gevoelig voor data, omdat AI gemakkelijk begint te verzamelen wat mensen als persoonlijk ervaren: chatberichten, reactiesnelheid, toon van commentaren, reactietijd op PR's, deelname aan meetings, terugkerende fouten, conflicten in discussies. Hoe breder de toegang, hoe overtuigender de analyse. Maar hoe hoger het risico op lekken van gevoelige context, overmatige afhankelijkheid van de modeloutput en het veranderen van de retro in employee monitoring.

Praktisch zou ik een paar regels vastleggen voordat AI in de retro wordt ingevoerd:

• gebruik een minimale set bronnen die nodig is voor de vraag van de retro;
• analyseer geen persoonlijke berichten zonder expliciete afspraak en noodzaak;
• bouw geen persoonlijke ranglijsten, scores en conclusies over performance management;
• laat het team zien welke data is gebruikt en welke is uitgesloten;
• scheid feiten van gegenereerde interpretaties;
• verifieer belangrijke conclusies aan de primaire bron;
• verwijder of beperk de opslag van AI-samenvattingen als ze gevoelige teamcontext bevatten.

Dit is geen bureaucratie. Het is een voorwaarde voor een eerlijk gesprek. Als mensen niet begrijpen wat de model precies leest en hoe de output vervolgens wordt gebruikt, zullen ze voorzichtiger spreken. En een voorzichtige retrospectie levert bijna altijd veilige maar zwakke verbeteringen op.

Wat er echt verandert

AI kan een Sprint Retrospective inderdaad nuttiger maken. Het kan de voorbereidingskosten verlagen, feiten in het gesprek brengen, terugkerende patronen laten zien, herinneren aan niet-afgeronde action items, afwijkingen van de Definition of Done uitlichten en helpen om een vaag 'het moet beter' om te zetten in een concreet next-sprint experiment.

Maar dat werkt alleen als het team de grens begrijpt: AI bereidt materiaal voor de inspectie voor, maar voert de adaptatie niet voor het team uit. Het helpt data te zien, maar creëert geen psychologische veiligheid. Het kan een root cause voorstellen, maar weet niet waar mensen bang zijn om over te praten. Het kan een action item schrijven, maar neemt geen owner en verandert het gedrag in de volgende sprint niet.

Daarom zou ik de hoofdstelling zo formuleren: AI moet de kosten van het reconstrueren van feiten verlagen, zodat het team meer aandacht overhoudt voor een eerlijk gesprek en de keuze van een kleine verbetering. Als het omgekeerde gebeurt en de Sprint Retrospective verandert in een automatisch gegenereerde lijst aanbevelingen, verliest het team precies dat waarvoor het event bestaat: gezamenlijk leren, verantwoordelijkheid voor verandering en het vermogen om de kwaliteit van werk te verhogen.

Een volwassen team vraagt niet: 'kunnen we AI de retrospective laten uitvoeren?'. Het vraagt anders: 'welk deel van de voorbereiding kan AI overnemen, zodat onze retrospective eerlijker, concreter wordt en beter tot actie leidt?'. Dat is een minder spectaculaire vraag. Maar juist die ligt dichter bij echte continuous improvement.

Bronnen en richtlijnen

• Scrum Guide 2020 — Sprint Retrospective, kwaliteit en effectiviteit, mensen / interacties / processen / tools / Definition of Done, de nuttigste verbeteringen en de koppeling met de Sprint Backlog.
• Scrum Guide Expanded v2026.1 — companion-bron op basis van de Scrum Guide 2020: psychological safety, meaningful continuous improvement follow-through en AI als supervised decision-making partner.
• Scrum.org: Introduction to the Sprint Retrospective — praktische toelichting op de Sprint Retrospective als event voor inspection and adaptation van de werkpraktijken van het team.
• Lehtinen, Itkonen & Lassenius: Recurring opinions or productive improvements — empirisch onderzoek naar 37 retrospectives over bijna drie jaar: participant bias, hard evidence, terugkerende onderwerpen en corrective actions.
• Amy Edmondson: Psychological Safety and Learning Behavior in Work Teams — klassieke bron over psychologische veiligheid als voorwaarde voor team learning.
• NIST Generative AI Profile — confabulation, data privacy, human-AI configuration, overreliance, information integrity en andere risico's van generatieve AI.
• OWASP Top 10 for LLM Applications 2025 — sensitive information disclosure, excessive agency, misinformation en operationele risico's van LLM-applicaties.
• DORA State of AI-assisted Software Development 2025 — AI als versterker van bestaande sterke en zwakke punten van het organisatiesysteem.
• EDPB Opinion 28/2024 en ICO monitoring at work guidance impact assessment — richtlijnen over persoonsgegevens, transparantie, proportionaliteit en de grenzen van workplace monitoring.