Коли ШІ редагує документ, кому належить зміна?

Документ може показати, хто змінив речення, залишаючи вас у здогадках, хто затвердив те, що воно тепер говорить. Коли ШІ та люди обидва відредагували формулювання, ім’я поруч із остаточною правкою не відповідає на це питання.

Розгляньте гіпотетичну політику підтримки, яка обіцяє відповідь протягом двох робочих днів. Переписування ШІ пропонує один робочий день. Людський редактор змінює це на три, і керівник команди затверджує документ. Опублікований файл виглядає звичайним. Його історія містить відхилену пропозицію, людську редакцію та рішення щодо того, чого клієнти мають очікувати.

Хто володіє цією зміною? Перш ніж ми зможемо призначити відповідальність за їх випуск, треба розрізнити внески. Інакше «з підтримкою ШІ» розповідає нам дуже мало про те, як з’явилося остаточне формулювання.

Відокремте правку від рішення

Оголошення Microsoft від 29 вересня 2025 року, що Agent Mode у Word починав розгортання Frontier, розмістило розмовне редагування всередині застосунку для документів, спочатку в веб-версії. Це оголошення встановлює дату розгортання, а не те, як окрема організація переглядає отримані зміни.

Для команди, яка використовує ШІ таким чином, корисним початковим пунктом є особа, яка запитує правку. Записуйте цю особу окремо від програмного забезпечення, що її генерує. Якщо хтось потім переписує пропозицію, збережіть і цей внесок. Затвердження — це інша дія, прив’язана до версії, яку рецензент фактично бачив.

Ці ролі не потребують окремих людей для кожного завдання. Редактор може запросити переписування, відредагувати його та мати повноваження затвердити. Розрізнення все ж важливе: запит на скорочення абзацу не обов’язково означає схвалення кожної зміни, яку вносить програмне забезпечення.

Модель даних W3C PROV data model надає словник для опису цієї історії. Документи та їхні версії можна представляти як сутності; правки та затвердження — як дії; люди та програмне забезпечення — як агенти. Модель описує взаємозв’язки між ними. Вона не визначає юридичну відповідальність і не автентифікує того, хто вказаний у полі автора.

Для робочих процесів з документами, підтримуваних ШІ, що включають технічне писання або матеріали підтримки, це означає визначити, що представляє кожна зафіксована дія. Коментар ідентифікує внесок у дискусію. Затвердження має вказувати дозвіл на випуск конкретного формулювання. Надання обом однакового загального статусу «переглянуто» зробить запис менш корисним.

Створіть запис для одного зміненого фрагмента

Повернімося до прикладу часу відповіді. Перед створенням переписування збережіть затверджене формулювання з двома робочими днями та його версію документа. Дайте пропозиції зміни ідентифікатор, а потім зв’яжіть з нею подальші редакції та рішення.

Нижче наведено ілюстративний дизайн з вигаданими ідентифікаторами. Це не результат роботи випробуваного продукту чи схеми, яку підтримує кожен інструмент для документів.

Збережіть пропозицію ШІ після того, як її замінить людська редакція. Якщо запис містить лише остаточне формулювання з трьома робочими днями, пізніший рецензент не зможе відновити попередню пропозицію з цього запису. Відхилені зміни є частиною історії, навіть якщо вони не входять до опублікованого тексту.

Липневий 2024 рік NIST Generative AI Profile описує походження як інформацію про джерело та історію вмісту, включаючи модифікації та джерела. Він також рекомендує оцінювати взаємозв’язок між процесами походження та людськими рецензентами. Таблиця застосовує цю ідею до робочого процесу з документами; це не контрольний список сертифікації NIST.

Ви можете зберігати цей запис у системі документів або в підключеному сховищі. У будь-якому випадку зробіть зв’язок з випущеною версією достатньо явним, щоб хтось міг його отримати без покладання на пам’ять оригінального редактора.

Перевірте, що залишилося після передачі

Експортований файл заслуговує окремої перевірки. Історія, доступна під час редагування, може відрізнятися від того, що одержувач може переглянути, залежно від програми, формату та налаштувань експорту. Не слід припускати, що кожен PDF втрачає атрибуцію, або що збереження видимих коментарів зберігає кожне рішення під час перегляду.

Поточна документація щодо редагування за допомогою Copilot Microsoft стверджує, що її зміни поважають Track Changes, коли ця функція ввімкнена. Це корисна функція. Однак це не підтверджує, що вся ваша історія схвалень зберігається після кожного подальшого перетворення або передачі.

Перевірте шлях, яким ваша команда дійсно користується. Пройдіть прикладний документ через процес перегляду та експорту, а потім спробуйте відновити прийняту редакцію та її затверджувача, використовуючи збережені записи. Якщо випущений файл не може містити цю історію, зберігайте контрольований запис в іншому місці та підтримуйте зв’язок між ними.

Менш очевидні випадки теж заслуговують уваги. Приймайте лише частину пропозиції та перевіряйте, що запис говорить. Нехай два рецензенти працюють над однією базовою версією, а потім визначте, які зміни потрапили у випущений файл. Нарешті, відредагуйте фрагмент після схвалення і переконайтеся, що раніше прийняте рішення не стало беззвучно схваленням нової формулювання.

Відображуване ім’я автора має бути простежуваним до автентифікованого облікового запису, перш ніж ви покладаєтеся на нього як на ідентифікатор. Аналогічно, хеш-файл може допомогти ідентифікувати випущений артефакт, але не може сказати, чи правильне зобов’язання щодо часу відповіді. Це окремі перевірки, і ваш процес перегляду має зберігати цю різницю.

Встановіть межу схвалення перед випуском

Зміна форматування заголовка та зміна зобов’язання перед клієнтом не обов’язково мають проходити однакові шляхи перегляду. Визначте, які правки можуть здійснюватися згідно встановленої політики, а які потребують затвердження визначеної особи. Це рішення має відображати, що зміна означає для користувачів документа.

Аргумент на користь явної влади AI у прийнятті рішень стає практичним тут. У нашому прикладі комусь потрібна повноваження затвердити зобов’язання щодо відповіді протягом трьох робочих днів. Само дозвіл редагувати файл не слід розглядати як доказ цих повноважень.

Надайте цьому рецензенту достатньо контексту для прийняття рішення. Показуйте оригінальний та запропонований текст поруч із будь-якими проміжними людськими правками. Зробіть незв’язані конфлікти видимими та визначте версію, призначену для випуску. Рецензент, який бачить лише відшліфований фінальний абзац, може не помітити, що час відповіді змінився.

Визначте, хто володіє випуском, перед тим як передати робочий процес користувачам. Ця особа не зобов’язана виконувати кожне редагування, проте їй потрібен спосіб підтвердити, що необхідний перегляд відбувся і застосовується до файлу, який вона випускає. Неясне призначення ускладнює вирішення спірної зміни, коли документ готовий до випуску.

Для цього не потрібно зберігати кожен конфіденційний запит назавжди. Зберігайте докази, необхідні для пояснення рішення, відповідно до політики доступу та збереження вашої організації. Якщо інформація про версію моделі недоступна, зафіксуйте це обмеження. Корисна історія повинна робити відсутню інформацію очевидною, а не створювати враження про рівень деталізації, який система ніколи не фіксувала.

Випускайте лише ту версію, яку ви можете обґрунтувати

Перед випуском суттєвої зміни спробуйте відстежити її у записах. Знайдіть оригінальну пропозицію, визначте, що змінив людський редактор, і отримайте рішення про прийняття цієї редакції. Потім порівняйте схвалену версію з файлом, який буде доставлений.

Якщо цей зв’язок відсутній, зупиніть зміну перегляду. Той, хто лише пам’ятає, що документ був «затверджений», не дає достатньо підстав, щоб визначити, яке саме формулювання було схвалено.

Редактор повинен мати можливість пояснити свій внесок, не отримуючи всі пропозиції, створені ШІ. Власник випуску має точно знати, що саме він уповноважує. Ми не можемо вимагати від людей підтримувати зміни, не надаючи їм надійного способу перевірити, як ці зміни були здійснені.