Når AI redigerer dokumentet, hvem eier endringen?

Et dokument kan vise hvem som endret en setning, men lar deg gjette hvem som godkjente hva den nå sier. Når både AI og mennesker har revidert formuleringen, gir et navn ved den endelige redigeringen ikke svar på det spørsmålet.

Vurder en hypotetisk supportpolicy som lover svar innen to arbeidsdager. En AI‑omskriving foreslår én arbeidsdag. En menneskelig redaktør endrer dette til tre, og en teamleder godkjenner dokumentet. Den utgitte filen ser vanlig ut. Historikken inneholder et avvist forslag, en menneskelig revisjon og en beslutning om hva kundene skal forvente.

Hvem eier den endringen? Vi må skille bidragene før vi kan tildele ansvar for å publisere dem. Ellers forteller «AI‑assistert» oss svært lite om hvordan den endelige formuleringen kom frem.

Skille redigeringen fra beslutningen

Microsofts kunngjøring 29. september 2025 om at Agent Mode i Word begynte sin Frontier-utrulling plasserte konversasjonsredigering i dokumentapplikasjonen, først på nettet. Den kunngjøringen fastsetter utrullingsdatoen, ikke hvordan en bestemt organisasjon gjennomgår de resulterende endringene.

For et team som bruker AI på denne måten, er et nyttig utgangspunkt personen som ber om redigeringen. Registrer den personen separat fra programvaren som genererer den. Hvis noen deretter omskriver forslaget, bevar også dette bidraget. Godkjenning er en annen handling, knyttet til versjonen som gjennomleseren faktisk så.

Disse rollene krever ikke separate personer for hver oppgave. En redaktør kan be om en omskriving, revidere den, og ha myndighet til å godkjenne den. Skillet er fortsatt viktig: Å be om et kortere avsnitt betyr ikke nødvendigvis at man godkjenner hver endring programvaren gjør.

Den W3C PROV data model gir et vokabular for å beskrive denne historikken. Dokumenter og deres versjoner kan representeres som enheter; redigeringer og godkjenninger som aktiviteter; personer og programvare som agenter. Modellen beskriver relasjonene mellom dem. Den fastsetter ikke juridisk ansvar eller autentiserer hvem som står i et forfatterfelt.

For AI-assisted document workflows som involverer teknisk skriving eller støttemateriell, betyr dette at man definerer hva hver registrerte handling representerer. En kommentar identifiserer et bidrag til diskusjonen. En godkjenning bør identifisere tillatelse til å publisere en bestemt formulering. Å gi begge samme generiske «gjennomgått»-status ville gjøre oppføringen mindre nyttig.

Bygg en registrering for ett endret avsnitt

Gå tilbake til eksemplet med responstid. Før du genererer en omskriving, behold den godkjente formuleringen på to arbeidsdager og dens dokumentversjon. Gi den foreslåtte endringen en identifikator, og koble senere revisjoner og beslutninger til den.

Følgende er et illustrativt design med oppdiktede identifikatorer. Det er ikke resultat fra et testet produkt eller et skjema som alle dokumentverktøy støtter.

Behold AI‑forslaget etter at den menneskelige revisjonen erstatter det. Hvis registreringen kun beholder den endelige formuleringen på tre arbeidsdager, kan en senere gjennomleser ikke rekonstruere det tidligere forslaget fra den oppføringen. Avviste endringer er en del av historikken selv om de ikke hører til i den publiserte teksten.

NISTs juli 2024 Generative AI Profile beskriver proveniens som informasjon om innholdets opprinnelse og historie, inkludert endringer og kilder. Den anbefaler også å evaluere forholdet mellom proveniensprosesser og menneskelige gjennomlesere. Tabellen anvender dette konseptet på en dokumentarbeidsflyt; den er ikke en NIST‑sertifiseringssjekkliste.

Du kan beholde denne registreringen i dokumentsystemet eller i et tilknyttet lager. Uansett bør forholdet til den utgitte versjonen gjøres tydelig nok til at noen kan hente den uten å måtte stole på den opprinnelige redaktørens hukommelse.

Kontroller hva som overlever overleveringen

En eksportert fil fortjener sin egen sjekk. Historikken som er tilgjengelig under redigering kan avvike fra det en mottaker kan inspisere, avhengig av programmet, formatet og eksportinnstillingene. Ikke anta at hver PDF mister tilskrivelse, eller at bevaring av synlige kommentarer bevarer hver gjennomgangsbeslutning.

Microsofts nåværende dokumentasjon for redigering med Copilot sier at endringene respekterer Track Changes når den funksjonen er aktivert. Det er en nyttig funksjon. Den fastslår ikke at din komplette godkjenningshistorikk overlever hver påfølgende konvertering eller overlevering.

Test den arbeidsflyten teamet ditt faktisk bruker. Ta eksempeldokumentet gjennom gjennomgang og eksport, og prøv deretter å gjenopprette den aksepterte revisjonen og dens godkjenner ved hjelp av de beholdte registreringene. Hvis den utgitte filen ikke kan bære den historikken, behold en kontrollert journal et annet sted og bevar koblingen mellom dem.

De mindre rettlinjede tilfellene fortjener også oppmerksomhet. Aksepter kun en del av et forslag og undersøk hva registreringen viser. La to gjennomganger jobbe mot samme grunnversjon, og fastslå hvilke endringer som nådde den utgitte filen. Til slutt, rediger avsnittet etter godkjenning og verifiser at den tidligere beslutningen ikke stille har blitt godkjenning av den nye formuleringen.

Et vist forfatternavn bør kunne spores tilbake til en autentisert konto før du stoler på det for identitet. På samme måte kan en fil-digest hjelpe med å identifisere den utgitte artefakten, men den kan ikke fortelle om responstidforpliktelsen er korrekt. Dette er separate kontroller, og gjennomgangsprosessen din må bevare skillet.

Sett godkjenningsgrensen før publisering

Endring av en overskrifts formatering og endring av en kundes forpliktelse trenger ikke følge identiske gjennomgangsstier. Bestem hvilke redigeringer som kan fortsette under en etablert policy, og hvilke som krever godkjenning fra en utpekt person. Det valget bør reflektere hva endringen betyr for brukerne av dokumentet.

Argumentet for eksplicit AI-beslutningsmyndighet blir praktisk her. I vårt eksempel trenger noen myndighet til å godkjenne en tre-arbeidsdagers responstidforpliktelse. Tillatelse til kun å redigere filen bør ikke behandles som bevis på den myndigheten.

Gi den gjennomgiveren nok kontekst til å ta en beslutning. Vis den opprinnelige og foreslåtte formuleringen ved siden av eventuelle mellomliggende menneskelige revisjoner. Gjør uløste konflikter synlige, og identifiser versjonen som er ment for publisering. En gjennomgiveren som kun ser et polert sluttavsnitt, kan mangle grunn til å legge merke til at responstiden ble endret.

Fastsett hvem som eier publiseringen før arbeidsflyten overleveres til brukerne. Den personen trenger ikke utføre hver redigering, men de må ha en måte å fastslå at den nødvendige gjennomgangen har skjedd og gjelder for filen de publiserer. Å la oppgaven være vag gjør det vanskeligere å løse en omstridt endring når dokumentet er klart til bruk.

Dette krever ikke at alle konfidensielle forespørsler beholdes på ubestemt tid. Behold bevisene som trengs for å forklare beslutningen i henhold til organisasjonens tilgangs- og lagringspolicy. Hvis modellversjonsinformasjon ikke er tilgjengelig, registrer begrensningen. En nyttig historikk bør gjøre manglende informasjon tydelig i stedet for å antyde et detaljnivå systemet aldri har fanget.

Publiser kun den versjonen du kan redegjøre for

Før du publiserer en betydningsfull endring, prøv å spore den tilbake gjennom registreringen. Finn det opprinnelige forslaget, fastslå hva den menneskelige redaktøren endret, og hent beslutningen som aksepterte den revisjonen. Sammenlign deretter den godkjente versjonen med filen som leveres.

Hvis den forbindelsen mangler, sett gjennomgangsendringen på vent. Det er ikke nok at noen husker at dokumentet ble «godkjent» for å fastslå hvilken formulering de godkjente.

En redaktør bør kunne forklare sitt bidrag uten å bli tildelt hvert forslag AI-en produserte. Utgivelsesansvarlig må vite nøyaktig hva de autoriserer. Vi kan ikke be folk stå bak endringer uten å gi dem en pålitelig måte å inspisere hvordan endringene ble gjort.