Data-flywheel: eigen correcties als trainingsmateriaal (dat nooit weggaat)

Een data-flywheel is een zichzelf versterkende lus: het gebruik van je AI levert data op, die data verbetert de AI, en die betere AI levert weer meer bruikbare data op [1]. In een verslagsysteem is die data heel concreet: elke keer dat een medewerker een concept-verslag corrigeert vóór goedkeuring — een verkeerd gespelde achternaam, een vakterm die de spraakherkenning miste, een zin die net anders moest — is dat een gelabeld voorbeeld van hoe het wél moet. Die correcties zijn het waardevolste trainingsmateriaal dat er bestaat, omdat ze uit jouw echte gesprekken komen en door jouw mensen zijn goedgekeurd [1]. De kern van dit artikel zit in de ondertitel: dat nooit weggaat. Bij een clouddienst verdwijnen jouw correcties in het model van de leverancier, waar ze iedereen verbeteren en waar je ze niet meeneemt als je vertrekt. Bij een lokale opstelling blijft die groeiende verzameling correcties fysiek in je eigen pand, als bezit dat van jou is en van jou blijft. Hieronder lees je hoe die flywheel werkt, welke twee manieren er zijn om ervan te leren, en waarom locatie hier alles bepaalt.

Wat een data-flywheel is

De term komt uit de wereld van AI-productontwikkeling. NVIDIA omschrijft een data-flywheel als "een zelfverbeterende lus waarin data uit AI-interacties wordt gebruikt om AI-modellen doorlopend bij te stellen, wat betere uitkomsten en waardevoller data oplevert voor verdere verbetering" [1]. De metafoor is een vliegwiel: het kost moeite om het op gang te krijgen, maar zodra het draait, houdt het zichzelf in beweging. Meer gebruik levert meer data op, meer data maakt het model beter, en een beter model wordt meer gebruikt.

Niet alle data in die lus is even nuttig. NVIDIA benoemt expliciet welke signalen het meeste opleveren: het systeem "verzamelt data met een hoog signaal — zoals onjuiste voorspellingen, uitkomsten met lage zekerheid, of veranderend gebruikersgedrag — en gebruikt die om toekomstige modelversies te verbeteren" [1]. Vertaald naar verslaglegging: de plekken waar een mens iets moest rechtzetten, zijn precies de plekken waar het model nog tekortschoot. Een correctie is dus geen ruis maar een leerpunt, keurig aangewezen door iemand die het gesprek zelf heeft gevoerd.

Waarom jouw correcties het beste trainingsmateriaal zijn

Elk AI-verslag is een concept tot een mens het heeft gecontroleerd en goedgekeurd. Dat reviewmoment is niet alleen een kwaliteitscontrole — het is de plek waar de flywheel zijn brandstof tankt. Op het moment dat een reviewer "Bakerhof" corrigeert naar "Bakkerhof", of de afkorting "MDO" op de juiste plek zet, ontstaat een paar: de ruwe uitkomst van de AI én het door een mens goedgekeurde juiste antwoord. Dat is exact het formaat waarin AI-modellen leren.

De reden dat dit zo waardevol is, zit in de aard van de fouten. Algemene spraakherkenning presteert slechter op woorden die weinig in de trainingsdata voorkomen: eigennamen, technisch jargon en organisatiespecifieke termen. Onderzoek naar domeinspecifieke transcriptie laat zien dat je die zwakke plek gericht kunt wegwerken: door het model te sturen richting een eigen woordenlijst daalde de woordfoutscore fors — bij een middelgroot Whisper-model van 27,82% naar 11,12% — en steeg de nauwkeurigheid van het herkennen van de juiste termen in een vervolgtaak van 67% naar 98% [3]. De les is duidelijk: generieke modellen kennen de wereld, maar niet jouw wereld. Jouw correcties vullen precies dat gat, cliëntnaam voor cliëntnaam, vakterm voor vakterm. Hoe goed spraakherkenning uit de doos al is en waar ze steken laat vallen, lees je in Hoe goed is spraakherkenning op een Mac Mini?

Twee manieren om te leren: woordenboek of fine-tuning

Er zijn grofweg twee manieren om die correcties terug te laten vloeien in het systeem, van licht naar zwaar.

De lichte manier is het model sturen zonder het te hertrainen. Je legt een organisatie-woordenboek aan met de namen, afkortingen en vaktermen die bij jou voorkomen, en de spraakherkenning gebruikt die lijst als hint. Het genoemde onderzoek noemt dit contextual biasing: het bereikt "betere transcriptienauwkeurigheid zonder expliciete fine-tuning of het aanpassen van modelparameters, met een relatief kleine trainingsset" [3]. Groot voordeel: het is direct, veilig en makkelijk te controleren — je ziet precies welke woorden je hebt toegevoegd, en er verandert niets aan het model zelf.

De zware manier is echte fine-tuning: je past de modelgewichten zelf aan op basis van je verzamelde voorbeelden. Dat hoeft tegenwoordig niet meer in een datacenter. Met Apple's MLX-bibliotheek kun je een taalmodel lokaal op een Mac bijstellen, waarbij "geen cloud nodig is en er nooit data van je machine af gaat" [2]. In de praktijk gebeurt dat meestal met lage-rang-adapters (LoRA): je bevriest het oorspronkelijke model en traint alleen een klein aantal nieuwe parameters erbovenop, wat het "sneller, lichter en vaak geheugenzuiniger maakt, juist op lokale hardware" [2]. Apple noemt de reden waarom dit lokaal moet met zoveel woorden: fine-tunen in de cloud is "vaak niet ideaal wanneer je met privé- of gevoelige data werkt" [2]. Precies dat is aan de orde bij zorg- en cliëntgesprekken.

Het cruciale verschil: lokaal versus cloud

Nu komt de ondertitel tot leven. Een data-flywheel bestaat bij elke serieuze AI-dienst — óók bij clouddiensten. Het verschil zit niet in óf er geleerd wordt, maar in voor wie en waar.

Bij een clouddienst gaan jouw correcties naar de servers van de leverancier. Daar verbeteren ze doorgaans één centraal model dat álle klanten bedienen. Je levert dus gratis mee aan een gedeeld product — en, belangrijker, je krijgt die bijdrage nooit terug als je overstapt. De verzameling verbeteringen die jóuw organisatie heeft opgebouwd, zit vast in het model van de ander. Vertrek je, dan begin je bij een volgende leverancier weer bij nul. Dát is wat er "weggaat".

Bij een lokale opstelling gebeurt het omgekeerde. De correcties, het woordenboek en eventuele adapters staan op je eigen machine — bij Verbinn is dat de Kern, één Apple Silicon-Mac in je eigen pand. Ze verbeteren alleen jouw systeem, ze verlaten het pand niet, en ze blijven van jou. Die verzameling wordt een bezit dat met de jaren groeit in plaats van een bijdrage die je weggeeft. En omdat alles lokaal blijft, is het controleerbaar: de Kern toont zijn uitgaande verbindingen, en geen daarvan draagt gespreksinhoud. Dat de modellen zelf óók lokaal bijgewerkt kunnen worden zonder cloud, beschrijven we in Updates zonder cloud: hoe software veilig bijblijft in een gesloten netwerk. In de opstelling van Verbinn is het organisatie-woordenboek de eerste, eenvoudigste vorm van deze lokale leerlus: elke goedgekeurde correctie kan je eigen termenlijst voeden, zonder dat er iets naar buiten gaat.

Wat de AVG hiervan vindt: corrigeren is óók verwerken

Een flywheel klinkt onschuldig, maar er zit een privacykant aan die je niet mag overslaan: correcties gebruiken om een model te verbeteren is zélf een verwerking van persoonsgegevens. Je traint immers op teksten die uit echte gesprekken komen. De Autoriteit Persoonsgegevens wijst op twee beginselen die hier direct spelen: dataminimalisatie — je verwerkt alleen gegevens die aantoonbaar nodig zijn voor het doel — en het uitgangspunt dat belangrijke besluiten menselijke tussenkomst houden [4]. Data die je voor het ene doel hebt verzameld, mag je niet zomaar voor een nieuw doel (modeltraining) inzetten; elk nieuw doel vraagt om een eigen rechtsgrond.

Op Europees niveau boog de European Data Protection Board zich hier eind 2024 over in Opinie 28/2024. De kern: het gebruik van persoonsgegevens voor AI-training is "niet op voorhand uitgesloten" van een beroep op gerechtvaardigd belang, maar of het mag hangt sterk af van de context, de aard van de data, de redelijke verwachtingen van de betrokkenen en de beschermende maatregelen die je treft [5]. Met andere woorden: het kán, mits je het zorgvuldig en aantoonbaar doet. Een lokale opstelling maakt dat verhaal aanzienlijk eenvoudiger. Er is geen doorgifte naar het buitenland, geen verwerker in de keten en geen datastroom die je aan je functionaris gegevensbescherming moet uitleggen — de leerlus blijft binnen dezelfde muren als het oorspronkelijke gesprek. Let op: dit maakt een DPIA niet overbodig, want je verwerkt nog steeds gevoelige gegevens. Het maakt de uitkomst ervan alleen gunstiger.

Hoe je de flywheel bouwt zonder risico

Je hoeft geen datawetenschapper te zijn om deze lus goed op te zetten. Een paar praktische principes houden hem veilig en verdedigbaar:

• Vang correcties op het reviewmoment. Het goedkeuren van een concept is de natuurlijke plek waar de "juiste" versie ontstaat. Leg daar het verschil vast tussen wat de AI voorstelde en wat de mens goedkeurde — dat is je trainingsmateriaal, zonder extra werk.
• Begin licht, ga pas zwaar als het nodig is. Een organisatie-woordenboek lost de meeste naam- en jargonfouten al op, zonder één modelparameter aan te raken [3]. Fine-tuning met LoRA is de volgende stap, niet de eerste.
• Houd de mens in de lus. Een flywheel mag nooit betekenen dat de AI zichzelf definitief maakt. Elk verslag blijft een concept tot een mens het goedkeurt; het leren gebeurt ná, niet in plaats van, die menselijke controle [4].
• Log wat er verandert. Een append-only auditlog van wat er is toegevoegd aan het woordenboek of waarop is bijgesteld, maakt de leerlus controleerbaar — voor jezelf en voor je toezichthouder.
• Houd alles lokaal. Zolang de data, de correcties en het trainen op je eigen machine blijven, is de privacyvraag beheersbaar en de winst van jou [2].

Zo verandert een lastige bijkomstigheid — dat AI fouten maakt en gecorrigeerd moet worden — in het motortje dat je systeem ieder kwartaal beter maakt op precies jouw manier van werken. Niet met een belofte van foutloosheid, maar met een groeiend, controleerbaar bezit dat je nergens anders krijgt en dat niemand van je afpakt.