Когда ИИ редактирует документ, кому принадлежит изменение?

Документ может показывать, кто изменил предложение, но оставлять вас в неведении, кто утвердил то, что теперь в нём написано. После того как ИИ и люди оба отредактировали формулировку, имя рядом с окончательным изменением не отвечает на этот вопрос.

Рассмотрим гипотетическую политику поддержки, обещающую ответ в течение двух рабочих дней. Переписанный ИИ вариант предлагает один рабочий день. Человек‑редактор меняет его на три, а руководитель команды утверждает документ. Выпущенный файл выглядит обычным. Его история содержит отклонённое предложение, человеческую правку и решение о том, чего клиенты должны ожидать.

Кому принадлежит это изменение? Прежде чем можно будет возложить ответственность за их публикацию, необходимо различать вклады. В противном случае «с поддержкой ИИ» мало что говорит о том, как появилась окончательная формулировка.

Отделите правку от решения

Объявление Microsoft от 29 сентября 2025 года, что Agent Mode в Word начал развертывание Frontier, разместило разговорное редактирование внутри приложения для работы с документами, первоначально в веб‑версии. Это объявление фиксирует дату развертывания, а не то, как отдельная организация будет рассматривать получившиеся изменения.

Для команды, использующей ИИ таким образом, полезным отправным пунктом является человек, запрашивающий правку. Записывайте этого человека отдельно от программного обеспечения, которое её генерирует. Если кто‑то затем переписывает предложение, сохраните и этот вклад. Утверждение — это отдельное действие, привязанное к версии, которую рецензент действительно видел.

Эти роли не требуют отдельного человека для каждой задачи. Редактор может запросить переписать текст, изменить его и иметь полномочия утвердить. Различие всё равно важно: запрос на более короткий абзац не обязательно означает одобрение всех изменений, внесённых программой.

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

Для рабочих процессов с поддержкой ИИ в работе с документами, связанных с техническим писательством или материалами поддержки, это означает определение того, что представляет каждое зафиксированное действие. Комментарий указывает вклад в обсуждение. Утверждение должно обозначать разрешение выпустить конкретную формулировку. Присвоение обоим одинакового общего статуса «просмотрено» сделает запись менее полезной.

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

Вернёмся к примеру со временем ответа. Перед генерацией переписки сохраняйте одобренную формулировку «два рабочих дня» и её версию документа. Присвойте предлагаемому изменению идентификатор, а затем привязывайте к нему последующие правки и решения.

Ниже представлена иллюстративная схема с вымышленными идентификаторами. Это не результат работы проверенного продукта и не схема, поддерживаемая всеми инструментами для работы с документами.

Сохраняйте предложение ИИ после того, как его заменит человеческая правка. Если запись содержит только окончательную формулировку «три рабочих дня», последующий рецензент не сможет восстановить предыдущее предложение из этой записи. Отклонённые изменения являются частью истории, хотя они не входят в опубликованный текст.

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

Эту запись можно сохранить в системе документов или в связанном репозитории. В любом случае сделайте связь с выпущенной версией достаточно явной, чтобы её можно было получить без обращения к памяти оригинального редактора.

Проверьте, что сохраняется при передаче

Экспортированный файл заслуживает отдельной проверки. История, доступная во время редактирования, может отличаться от той, которую получатель может просмотреть, в зависимости от приложения, формата и настроек экспорта. Не следует полагать, что каждый PDF теряет атрибуцию, или что сохранение видимых комментариев сохраняет каждое решение рецензирования.

Текущая документация по редактированию с Copilot от Microsoft гласит, что её изменения уважают функцию Track Changes, когда она включена. Это полезный функционал. Однако это не гарантирует, что вся ваша история одобрения сохраняется при каждой последующей конвертации или передаче.

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

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

Отображаемое имя автора должно быть прослеживаемо к аутентифицированной учётной записи, прежде чем полагаться на него в качестве идентификации. Аналогично, хеш‑сумма файла может помочь идентифицировать выпущенный артефакт, но она не может сказать, корректно ли выполнено обязательство по времени отклика. Это отдельные проверки, и ваш процесс рецензирования должен сохранять различие между ними.

Установите границы одобрения перед выпуском

Изменение форматирования заголовка и изменение обязательства перед клиентом не обязаны проходить одинаковые пути проверки. Определите, какие правки могут быть выполнены в рамках установленной политики, а какие требуют одобрения назначенного лица. Этот выбор должен отражать, что изменение значит для людей, использующих документ.

Аргумент в пользу явного контроля над решением ИИ здесь становится практичным. В нашем примере кто‑то нуждается в полномочиях одобрять обязательство ответа в течение трёх рабочих дней. Само разрешение редактировать файл не должно рассматриваться как доказательство наличия этих полномочий.

Предоставьте этому рецензенту достаточный контекст для принятия решения. Покажите оригинальный и предлагаемый текст рядом с любой промежуточной правкой человека. Сделайте неразрешённые конфликты видимыми и укажите версию, предназначенную для выпуска. Рецензент, видящий только отшлифованный финальный абзац, может не заметить, что время отклика изменилось.

Установите, кто отвечает за выпуск, прежде чем передавать рабочий процесс пользователям. Этот человек не обязан выполнять каждое редактирование, но ему нужен способ удостовериться, что необходимый обзор был проведён и относится к файлу, который он выпускает. Неясное назначение усложняет разрешение спорных изменений, когда документ готов к использованию.

Это не требует хранить каждый конфиденциальный запрос бесконечно. Сохраняйте доказательства, необходимые для объяснения решения, в соответствии с политикой доступа и хранения вашей организации. Если информация о версии модели недоступна, зафиксируйте это ограничение. Полезная история должна делать отсутствие информации очевидным, а не подразумевать уровень детализации, который система никогда не фиксировала.

Выпускайте только ту версию, которую можете обосновать

Прежде чем выпускать значимое изменение, попытайтесь проследить его в записях. Найдите исходное предложение, определите, что изменил человек‑редактор, и извлеките решение, принявшее эту правку. Затем сравните одобренную версию с доставляемым файлом.

Если эта связь отсутствует, приостановите изменение в процессе рецензирования. Тот, кто помнит, что документ был «одобрен», недостаточно, чтобы установить, какую формулировку он одобрил.

Редактор должен иметь возможность объяснить свой вклад, не будучи назначенным на каждое предложение, сгенерированное ИИ. Владельцу выпуска необходимо точно знать, что он авторизует. Мы не можем требовать от людей отвечать за изменения, не предоставляя им надёжного способа проверить, как эти изменения были внесены.