# AI-генератор SOP: как превратить факты в проверенную процедуру

> Практический процесс создания SOP с помощью AI без выдуманных команд, контактов и rollback-шагов. Пакет источников, промпт, ревью и проверка.
> Author: Roman Belov · Published: 2026-03-11 · Source: https://futurecraft.pro/ru/blog/sop-generator-ai-documentation/

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

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

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

## Из чего состоит рабочий SOP

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

- Кто владелец и кто её утверждает?
- Для каких систем, окружений и ситуаций она предназначена?
- Кто вправе её выполнять и какие права нужны?
- Что должно быть готово до первого действия?
- Какой результат ожидается после каждого шага?
- При каком условии нужно остановиться, а не импровизировать?
- Как восстановиться, откатиться или эскалировать проблему?
- Какие подтверждения выполнения нужно сохранить?
- Какие изменения запускают новое ревью?

Для incident response эта структура особенно важна. [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final) связывает подготовку, обнаружение, реагирование, восстановление и улучшение с управлением киберрисками. В руководстве Google SRE по [управлению инцидентами](https://sre.google/sre-book/managing-incidents/) отдельно выделены роли, координация, коммуникация и подготовленные заранее процедуры.

## Шаг 0. Классифицируйте процесс и данные

Сделайте это до сбора транскриптов и логов.

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

Запись экрана не становится безопасной только потому, что в ней нет исходного кода. В неё могут попасть:

- токены доступа и одноразовые коды;
- история терминала и переменные окружения;
- имена клиентов, тикеты и production-данные;
- приватные hostname, URL репозиториев и дашбордов;
- уведомления из посторонних переписок.

По возможности записывайте прохождение в staging. Закройте лишние приложения, используйте тестовые данные, захватывайте только нужное окно, затем просмотрите и очистите запись. Фраза «будьте осторожны» не заменяет контроль доступа. В руководстве OWASP по [управлению секретами](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) рекомендуются least privilege, контролируемый жизненный цикл, аудит и запрет открытых секретов в логах.

## Шаг 1. Выберите подходящий процесс

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

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

Одна частота - плохой фильтр. Disaster recovery выполняется редко, но требует проверенной процедуры. А для частой задачи, основанной на экспертном суждении, могут быть полезнее принципы и обучение, а не жёсткий SOP.

Ранжируйте кандидатов по принятой в команде модели риска. Запишите причину выбора. Не просите модель выдать точный балл приоритета из неполного контекста.

## Шаг 2. Соберите пакет доказательств

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

Для технического процесса пакет может включать:

1. актуальную автоматизацию или конфигурацию на зафиксированном commit;
2. официальную документацию для установленной версии;
3. вывод справки команд из одобренного окружения;
4. существующий runbook, тикет или архитектурное решение;
5. очищенное прохождение в staging;
6. известные сценарии отказа и утверждённые способы восстановления;
7. реального владельца и маршрут эскалации.

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

Это прикладной [context engineering](/ru/blog/context-engineering-guide/): отобрать авторитетный контекст, подписать источники и явно указать их границы.

## Шаг 3. Сгенерируйте проверяемый черновик

Промпт должен запрещать правдоподобные выдумки:

```text
Создай ЧЕРНОВИК SOP, используя только материалы ниже.

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

Не придумывай команды, флаги, пути, контакты, права,
оценки времени, severity, ожидаемый вывод и восстановление.
Не превращай CI-конфигурацию в инструкцию ручного деплоя.
Перед разрушительным или production-действием добавь
ТРЕБУЕТСЯ СОГЛАСОВАНИЕ и условие остановки.

Структура:
- ID документа, статус, владелец, утверждающий, аудитория
- область применения и что не входит в неё
- система/окружение и commit источников или дата актуальности
- необходимые права, входные данные и prerequisites
- нумерованные шаги: действие, ожидаемый результат,
  ссылка на доказательство и условие остановки
- ветвления решений
- восстановление/rollback и эскалация
- сохраняемые подтверждения
- нерешённые вопросы
- триггеры ревью

Материалы:
[контролируемый список источников]
```

Требуйте точные ссылки: файл и диапазон строк, раздел документа, тикет или timestamp записи. Если ответа в источнике нет, правильный результат - `[нет данных]`.

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

## Шаг 4. Проведите ревью с владельцем

Человек, который знает систему, проверяет не только язык. Нужны:

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

CI-файл может описывать автоматизированный happy path. Он редко доказывает безопасный ручной деплой или rollback. Не разрешайте модели закрывать этот пробел. Если восстановление не спроектировано или не проверено, так и напишите и назначьте владельца задачи.

Для incident response используйте настоящую модель severity, роли, контакты и каналы команды. Глава Google SRE Workbook про [реагирование на инциденты](https://sre.google/workbook/incident-response/) описывает координацию, коммуникацию, контроль, распределение ролей и регулярную практику. Простое копирование названий ролей без адаптации к вашей организации не создаст рабочий план.

## Шаг 5. Проведите clean-room проверку

Передайте черновик представителю целевой аудитории, который не участвовал в написании. Выполните процедуру в staging, одноразовом окружении или в формате tabletop exercise - выбор зависит от риска.

Зафиксируйте:

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

Заранее определите область и критерии успеха упражнения. [NIST SP 800-34 Rev. 1](https://www.nist.gov/publications/contingency-planning-guide-federal-information-systems) рекомендует задавать явные цели, критерии успеха, scope, сценарий, логистику, участников и расписание теста contingency plan.

Не проверяйте разрушительные rollback-шаги случайным запуском в production. Используйте одобренное окружение и согласованный план упражнения.

## Шаг 6. Публикуйте как контролируемый документ

Технический SOP стоит хранить достаточно близко к системе, чтобы изменения были видны. Репозиторий часто подходит: pull request показывает diff, обсуждение, ревью и автоматические проверки. Документация GitHub о [pull request](https://docs.github.com/en/pull-requests/get-started/about-pull-requests) описывает такой процесс проверки.

Безопасная автоматизация может:

1. заметить изменение связанного кода или конфигурации;
2. открыть draft pull request с правкой документации;
3. перечислить затронутые разделы и источники;
4. запросить ревью владельца и специалиста по безопасности;
5. оставить публикацию людям и обязательным проверкам.

Она не должна автоматически переписывать и публиковать операционную процедуру.

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

## Измеряйте, работает ли процедура

Число документов и слов ничего не говорит о качестве. Следите за поведением:

- clean-room выполнение без незаписанной помощи;
- число вопросов и отклонений на одно выполнение;
- ошибочные или двусмысленные шаги;
- время до безопасной остановки или восстановления в упражнении;
- непроверенные, просроченные и оставшиеся без владельца процедуры;
- инциденты, где инструкция помогла или помешала.

Эти сигналы показывают, передаёт ли документ операционные знания. Для этого не нужна выдуманная цифра о десятикратном ускорении документации.

## Типичные ошибки

**Модель заполняет пробелы.** Правдоподобная команда остаётся неподтверждённой. Требуйте `[нет данных]` и отправляйте вопрос владельцу.

**Исходники раскрывают данные.** Минимизируйте и очищайте материал до загрузки. Редактировать только финальный SOP уже поздно.

**Черновик путает автоматизацию с ручным путём.** Объясняйте только то, что подтверждает конфигурация. Аварийный процесс проектируйте отдельно.

**Проверяется только happy path.** В контролируемой среде нужно отработать остановку, эскалацию и восстановление.

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

## Безопасный первый запуск

Возьмите ограниченный неразрушительный процесс, например настройку локального окружения с тестовыми учётными данными.

1. Назначьте владельца и целевого читателя.
2. Классифицируйте данные и подготовьте очищенный пакет источников.
3. Создайте черновик с метками наблюдений, предположений и пробелов.
4. Закройте все предположения и пробелы вместе с владельцем.
5. Попросите другого человека выполнить шаги в чистом окружении.
6. Проведите документ через обычное ревью.
7. Запишите изменения, которые должны открыть его снова.

Только после этого переходите к деплою, управлению доступами, backup или incident response. В production-системах дополняйте SOP мониторингом и средствами восстановления, например [LLM observability](/ru/blog/llm-observability-langfuse/) или проверенным [circuit breaker](/ru/blog/circuit-breaker-deno-edge-functions/). Документация помогает принять обоснованное решение, но сама по себе не делает систему безопасной.