Чтобы создать документ передачи дел с помощью ИИ, сначала определите, что получатель должен уметь делать самостоятельно. Затем соберите утвержденные источники и поручайте ИИ составлять по одному разделу только по этим данным. Владельцы, неизвестные факты, требования к доступу и результаты приемки должны оставаться видимыми.

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

Ключевые выводы

До начала работы определите действия получателя и доказательства приемки.

Зарегистрируйте источники, владельцев, даты, охват и противоречия.

Не помещайте учетные данные в документ; передавайте доступ по утвержденному каналу.

Требуйте от ИИ явно сохранять неизвестные сведения и пробелы.

Проведите проверку без подсказок и зафиксируйте результаты приемки.

Что делает документ передачи дел пригодным к работе?

Пригодный документ позволяет названному получателю понимать текущую ситуацию, выполнять регулярные обязанности, разбирать типовые исключения, находить официальные записи и знать момент эскалации. Руководство GOV.UK Gate 5 рассматривает передачу как переход к обычной эксплуатации и проверяет ответственность, готовность принимающей команды, риски, действия и управление результатами, а не просто наличие файлов.［1］ Это не оглавление папки и не гладкое резюме, а инструмент приемки с прослеживаемыми утверждениями. GovS 008 также требует определить цели перехода, обязанности, знания и данные, этапы, зависимости, риски и критерии приемки.［2］

Начните с таблицы результатов получателя:

Результат получателя	Доказательство приемки	Владелец	Срок	Статус
Провести еженедельный обзор	Получен корректный результат из актуальных источников	Руководитель эксплуатации	Дата	Не проверено
Обработать типовое исключение	Путь эскалации пройден без подсказки	Владелец сервиса	Дата	Не проверено
Найти регламентирующие записи	Открыты действующая политика и журнал изменений	Владелец записей	Дата	Не проверено
Подтвердить доступ	Ролевой доступ проверен через утверждённую систему	Владелец доступа	Дата	Не проверено

Записывайте наблюдаемые результаты. Формулировку «понимает сервис» нельзя принимать единообразно, а «может провести еженедельный обзор, объяснить три известных исключения и назвать владельца эскалации» — можно.

Шаг 1. Определите получателя, охват и критерии

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

Составьте три списка охвата:

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

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

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

Шаг 2. Составьте шаблон передачи дел с ИИ по реестру источников

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

До загрузки или вставки чего-либо составьте реестр источников:

Source ID	Название	Владелец	Дата вступления в силу	Подтверждает	Чувствительность	Конфликт или пробел
S-01	Текущее описание сервиса	Владелец сервиса	Дата	Область и результаты	Внутреннее	Нет известных
S-02	Еженедельная операционная процедура	Владелец процесса	Версия	Регулярная обязанность	Внутреннее	Нет даты проверки
S-03	Журнал решений	Руководитель проекта	Диапазон дат	Причины текущих решений	Ограниченное	Два решения не закрыты

Проверьте каждый источник на актуальность, полномочия и применимость. Недавняя презентация может быть менее авторитетной, чем более старая утвержденная политика. Если записи расходятся, сохраните обе и передайте вопрос уполномоченному владельцу. ИИ не должен решать, какой владелец прав. Preparing for Handover рекомендует готовить сведения и обязанности постепенно, а не выгружать их в самом конце.［3］ Собирайте доказательства поэтапно; если набор источников неполон, документ должен это показать.

До передачи материалов модели удалите ненужные персональные данные и оставьте ограниченные вложения в исходной системе. Privacy Framework NIST помогает системно выявлять и контролировать риски приватности.［4］ Используйте только разрешенную среду ИИ.

Шаг 3. Постройте документ передачи знаний вокруг работы

Выстраивайте документ в том порядке, в каком им будет пользоваться получатель. Практичная структура:

Цель и приемка: получатель, дата вступления в силу, охват, исключения и правила подписания.
Текущее состояние: что работает, что стабильно, что меняется, что приостановлено или зависит от решения.
Обязанности: задача, частота, триггер, вход, результат, владелец, заместитель и эскалация.
Календарь: регулярные обзоры, продления, даты отчетности, обслуживание и точки решений.
Зависимости: команды, поставщики, системы, данные, договоры, допущения на входе и выходе.
Открытые вопросы: проблема, влияние, доказательство, следующее действие, владелец и срок.
Риски и пути эскалации: тревожные признаки, безопасная реакция, граница полномочий и эскалация.
Требования к доступу: система, роль, утверждающий, путь запроса и результат проверки — но никогда не сами учетные данные.
Реестр источников и история изменений: откуда взято каждое утверждение и что изменилось после проверки.
Проверка готовности получателя и запись о приемке: упражнения, результаты, пробелы, действия и подписи.

Ссылайтесь на действующую процедуру, а не копируйте ее. Документ передачи объясняет, когда она применяется, кто ею владеет и проверил ли ее получатель. Сама процедура должна оставаться в каноническом месте, чтобы последующие обновления не создали две конкурирующие версии.

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

Шаг 4. Как создать документ передачи дел с помощью ИИ по одному контролируемому разделу

Передайте модели структуру, ограниченный пакет источников и строгое правило доказательств. Если писать весь документ одним запросом, пропуски и выдуманные связи заметить труднее.

Полезный контракт запроса:

Напиши раздел «Регулярные обязанности» для названного получателя. Используй только источники S-01–S-03. Для каждой обязанности верни триггер, частоту, вход, результат, владельца, заместителя, условие эскалации и ID источника. Сохраняй даты и имена в точности. Неподтвержденные или противоречивые сведения помещай в раздел «Неизвестное и конфликты». Не выдумывай шаги доступа, учетные данные, согласования, уровни сервиса или причины.

Рядом с текстом попросите таблицу утверждений:

Claim ID	Черновое утверждение	Source ID	Прямой факт или вывод	Решение проверяющего
C-01	Еженедельный обзор проходит каждый понедельник	S-02	Прямой факт	Ожидает решения
C-02	Заместитель доступен	Нет	Не подтверждено	Удалить

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

ИИ может находить и структурные пробелы: какие обязательные поля пусты, у каких обязанностей нет заместителя, какие даты противоречат друг другу, какие термины не определены. Считайте это очередью на проверку, а не истиной: пустое поле может быть намеренным, а кажущееся противоречие — отражать две допустимые области.

Шаг 5. Сохраните неизвестное и проведите проверку владельцев

Неизвестное — часть результата. Используйте единообразную запись:

ID неизвестного	Вопрос	Почему это важно	Лучшее текущее доказательство	Владелец	Срок	Временное правило
U-01	Кто утверждает исключение в нерабочее время?	У получателя может не быть полномочий	S-03 неоднозначен	Владелец сервиса	Дата	Эскалировать; не продолжать

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

Проведите проверку владельцев по полям: предыдущий владелец проверяет точность и полноту; владельцы процессов и доступа — свои поля; специалисты по приватности или праву — ограниченные данные; получатель — понятность. Записывайте проверяющего, дату, решение и внесенное изменение. Используйте простой набор решений: принять, исправить, удалить, отложить с владельцем или исключить из охвата. «Выглядит нормально» — не доказательство: проверка должна относиться к конкретным утверждениям, строкам или разделам.

Шаг 6. Проверьте чек-лист передачи операционной деятельности и оформите приемку

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

Проверка	Ожидаемый результат	Фактический результат	Пробел	Владелец	Повторная проверка
Подготовить еженедельный обзор	Использованы верный шаблон и актуальные данные	Выбран старый шаблон	Неясна каноническая ссылка	Владелец процесса	Дата

Исправляйте документ по наблюдаемым сбоям и повторяйте неудачные тесты. Любая необходимая устная подсказка становится подтвержденным дополнением или отдельным обучением. В подписи укажите принятый охват, остаточные действия, владельцев, дату вступления и условия пересмотра. Ответственность продолжается и после перехода в обычную эксплуатацию.［1］

Итоги

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

Часто задаваемые вопросы (FAQ)

Что включить в документ передачи дел?

Охват, текущее состояние, обязанности, календарь, зависимости, открытые вопросы, риски, пути эскалации, требования к доступу, источники и доказательства приемки. Ссылайтесь на канонические процедуры, а не дублируйте их.

Можно ли составить его только по заметкам встреч?

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

Следует ли включать пароли?

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

Какой длины должен быть документ?

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

Как доказать приемку получателем?

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

Что делать при конфликте документов для передачи дел?

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

Это то же самое, что SOP?

Нет. Передача переносит ответственность, контекст и приемку; SOP описывает выполнение повторяемого процесса; документ передачи должен ссылаться на актуальный SOP.

Кто обновляет документ после передачи?

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

Источники

GOV.UK, Gate Review 5: Operational Review and Benefits Realisation — https://www.gov.uk/government/publications/gate-review-5-operations-review-and-benefit-realisation/gate-review-5-operational-review-and-benefits-realisation
GOV.UK, Government Functional Standard GovS 008: Commercial — https://www.gov.uk/government/publications/government-functional-standard-govs-008-commercial-and-commercial-continuous-improvement-assessment-framework/government-functional-standard-govs-008-commercial-html
GOV.UK, Preparing for Handover — https://assets.publishing.service.gov.uk/media/5a7cbaff40f0b6629523b74d/Preparing-for-Handover.pdf
NIST, Privacy Framework — https://www.nist.gov/privacy-framework

Sources checked 30 августа 2026 г.

Рекомендуемые статьи:

Как создать документ передачи дел с помощью ИИ