Wanneer AI het document bewerkt, wie bezit de wijziging?

Een document kan laten zien wie een zin heeft gewijzigd, maar laat je gissen wie heeft goedgekeurd wat er nu staat. Zodra zowel AI als mensen de formulering hebben aangepast, geeft een naam naast de uiteindelijke bewerking geen antwoord op die vraag.

Stel je een hypothetisch ondersteuningsbeleid voor dat een reactie binnen twee werkdagen belooft. Een AI-herformulering stelt één werkdag voor. Een menselijke redacteur verandert dit in drie, en een teamleider keurt het document goed. Het vrijgegeven bestand ziet er gewoon uit. De geschiedenis bevat een afgewezen voorstel, een menselijke revisie en een beslissing over wat klanten mogen verwachten.

Wie bezit die wijziging? We moeten de bijdragen onderscheiden voordat we verantwoordelijkheid voor het vrijgeven kunnen toewijzen. Anders zegt “AI-ondersteund” ons heel weinig over hoe de uiteindelijke formulering tot stand is gekomen.

Scheiding tussen bewerking en beslissing

Microsofts aankondiging van 29 september 2025 dat Agent Mode in Word begon met de Frontier-uitrol plaatst conversationele bewerking binnen de documentapplicatie, aanvankelijk op het web. Die aankondiging stelt de uitroldatum vast, niet hoe een specifieke organisatie de resulterende wijzigingen beoordeelt.

Voor een team dat AI op deze manier gebruikt, is het nuttige startpunt de persoon die de bewerking aanvraagt. Leg die persoon apart vast van de software die de bewerking genereert. Als iemand vervolgens het voorstel herschrijft, bewaar die bijdrage ook. Goedkeuring is een andere handeling, gekoppeld aan de versie die de beoordelaar daadwerkelijk heeft gezien.

Die rollen vereisen niet per taak verschillende personen. Een redacteur kan een herschrijving aanvragen, deze aanpassen en de bevoegdheid hebben om deze goed te keuren. Het onderscheid blijft belangrijk: het aanvragen van een kortere alinea betekent niet per se dat elke wijziging die de software aanbrengt, wordt goedgekeurd.

Het W3C PROV data model biedt een vocabulaire voor het beschrijven van deze geschiedenis. Documenten en hun versies kunnen worden weergegeven als entiteiten; bewerkingen en goedkeuringen als activiteiten; mensen en software als agenten. Het model beschrijft de relaties tussen hen. Het bepaalt niet de juridische aansprakelijkheid of verifieert wie er in een auteursveld verschijnt.

Voor AI-ondersteunde documentworkflows die technische documentatie of ondersteunend materiaal omvatten, betekent dit dat we moeten definiëren wat elke geregistreerde handeling vertegenwoordigt. Een opmerking identificeert een bijdrage aan de discussie. Een goedkeuring moet toestemming aangeven om specifieke bewoordingen vrij te geven. Als beide dezelfde generieke status “beoordeeld” krijgen, wordt het record minder bruikbaar.

Maak een record voor één gewijzigde passage

Keer terug naar het voorbeeld van de responstijd. Houd vóór het genereren van een herschrijving de goedgekeurde formulering van twee werkdagen en de bijbehorende documentversie vast. Geef de voorgestelde wijziging een identifier en koppel later revisies en beslissingen eraan.

Het volgende is een illustratief ontwerp met verzonnen identifiers. Het is geen output van een getest product of een schema dat elke documenttool ondersteunt.

Bewaar het AI‑voorstel nadat de menselijke revisie het heeft vervangen. Als het record alleen de uiteindelijke bewoording van drie werkdagen behoudt, kan een latere beoordelaar de eerdere suggestie niet uit die vermelding reconstrueren. Afgewezen wijzigingen maken deel uit van de geschiedenis, ook al behoren ze niet tot de gepubliceerde tekst.

NIST’s juli 2024 Generative AI Profile beschrijft provenance als informatie over de oorsprong en geschiedenis van content, inclusief wijzigingen en bronnen. Het beveelt ook aan de relatie tussen provenance‑processen en menselijke beoordelaars te evalueren. De tabel past dat idee toe op een documentworkflow; het is geen NIST‑certificeringschecklist.

U kunt dit record behouden binnen het documentsysteem of in een gekoppelde repository. Hoe dan ook, maak de relatie met de vrijgegeven versie voldoende expliciet zodat iemand het kan ophalen zonder te vertrouwen op het geheugen van de oorspronkelijke redacteur.

Controleer wat de overdracht overleeft

Een geëxporteerd bestand verdient een eigen controle. De geschiedenis die tijdens het bewerken beschikbaar is, kan verschillen van wat een ontvanger kan inzien, afhankelijk van de applicatie, het formaat en de exportinstellingen. Ga er niet van uit dat elke PDF attributie verliest, of dat het behouden van zichtbare opmerkingen elke beoordelingsbeslissing behoudt.

Microsofts huidige documentatie voor bewerken met Copilot stelt dat de wijzigingen Track Changes respecteren wanneer die functie is ingeschakeld. Dat is een nuttige functionaliteit. Het bewijst niet dat uw volledige goedkeuringsgeschiedenis elke daaropvolgende conversie of overdracht overleeft.

Test de route die uw team daadwerkelijk gebruikt. Neem het voorbeelddocument door de review en export, en probeer vervolgens de geaccepteerde revisie en de goedkeurder te herstellen met behulp van de bewaarde gegevens. Als het vrijgegeven bestand die geschiedenis niet kan dragen, bewaar dan elders een gecontroleerd register en behoud de verbinding daartussen.

De minder eenvoudige gevallen verdienen ook aandacht. Accepteer slechts een deel van een suggestie en controleer wat het record aangeeft. Laat twee beoordelaars tegen dezelfde basisversie werken, en bepaal vervolgens welke wijzigingen het vrijgegeven bestand hebben bereikt. Bewerk tenslotte de passage na goedkeuring en verifieer dat de eerdere beslissing niet stilletjes is uitgegroeid tot goedkeuring van de nieuwe formulering.

Een weergegeven auteursnaam moet terug te voeren zijn op een geauthenticeerd account voordat u erop vertrouwt voor identificatie. Evenzo kan een bestandsdigest helpen het vrijgegeven artefact te identificeren, maar het kan u niet vertellen of de responstijdverbintenis correct is. Dit zijn afzonderlijke controles, en uw reviewproces moet het onderscheid behouden.

Stel de goedkeuringsgrens in vóór release

Het wijzigen van de opmaak van een kop en het wijzigen van een klantverbintenis hoeven niet dezelfde reviewtrajecten te volgen. Bepaal welke bewerkingen kunnen doorgaan onder een vastgesteld beleid en welke een goedkeuring van een aangewezen persoon vereisen. Die keuze moet weerspiegelen wat de wijziging betekent voor de gebruikers van het document.

Het argument voor expliciete AI-beslissingsautoriteit wordt hier praktisch. In ons voorbeeld heeft iemand autoriteit nodig om een responstijdverbintenis van drie werkdagen goed te keuren. Alleen toestemming om het bestand te bewerken mag niet worden beschouwd als bewijs van die autoriteit.

Geef die beoordelaar voldoende context om een beslissing te nemen. Toon de oorspronkelijke en voorgestelde formulering naast eventuele tussenliggende menselijke revisies. Maak onopgeloste conflicten zichtbaar en identificeer de versie die voor release bedoeld is. Een beoordelaar die alleen een gepolijste eindparagraaf ziet, heeft mogelijk geen reden om op te merken dat de responstijd is gewijzigd.

Bepaal wie de release bezit voordat u de workflow aan gebruikers overdraagt. Die persoon hoeft niet elke bewerking uit te voeren, maar moet wel kunnen aantonen dat de vereiste review heeft plaatsgevonden en van toepassing is op het bestand dat hij of zij vrijgeeft. Een vage toewijzing maakt het moeilijker om een betwiste wijziging op te lossen wanneer het document klaar is voor gebruik.

Dit vereist niet dat elke vertrouwelijke prompt onbepaald bewaard blijft. Bewaar het bewijs dat nodig is om de beslissing te verklaren volgens het toegangs- en retentiebeleid van uw organisatie. Als modelversie‑informatie niet beschikbaar is, noteer dan de beperking. Een bruikbare geschiedenis moet ontbrekende informatie duidelijk maken in plaats van een detailniveau te suggereren dat het systeem nooit heeft vastgelegd.

Release alleen de versie waarvoor u verantwoording kunt afleggen

Voordat u een ingrijpende wijziging vrijgeeft, probeer deze terug te traceren via het register. Zoek de oorspronkelijke suggestie, bepaal wat de menselijke redacteur heeft aangepast, en haal de beslissing op die die revisie accepteerde. Vergelijk vervolgens de goedgekeurde versie met het te leveren bestand.

Als die verbinding ontbreekt, houd dan de reviewwijziging vast. Iemand die zich herinnert dat het document “goedgekeurd” was, is niet voldoende om vast te stellen welke formulering zij hebben goedgekeurd.

Een redacteur moet zijn of haar bijdrage kunnen uitleggen zonder dat elke suggestie die de AI heeft gegenereerd aan hem of haar wordt toegewezen. De release‑eigenaar moet precies weten wat hij of zij autoriseert. We kunnen mensen niet vragen achter wijzigingen te staan terwijl we hen geen betrouwbare manier bieden om te inspecteren hoe die wijzigingen tot stand zijn gekomen.