Регламент, написанный за выходные и забытый через месяц, стоит компании дороже, чем отсутствие регламента вообще. Языковые модели ускорили написание таких документов в десятки раз, и это создало новую проблему, потому что скорость генерации текста никак не связана с качеством описанного процесса. Я работаю с внедрением ИИ в операционные процессы компаний и вижу одну и ту же картину в большинстве проектов. Документ выглядит безупречно, структура логичная, формулировки гладкие, а сотрудники продолжают спрашивать у коллег, как на самом деле делается работа.
Какие задачи с регламентами и инструкциями ИИ решает хорошо, а какие плохо
Языковая модель не знает ваш процесс. Она знает усреднённый процесс, собранный из миллионов документов разных компаний, и при недостатке данных достраивает пробелы наиболее вероятным содержанием. Именно поэтому запрос на регламент обработки входящей заявки без дополнительного контекста выдаст текст про менеджера, который фиксирует обращение в системе и связывается с клиентом в течение пятнадцати минут. Выглядит разумно. К вашей воронке продаж, вашим ролям и вашей системе учёта это отношения не имеет.
Распределение сил выглядит примерно так. Модель сильна там, где нужна структура, формулировка и полнота изложения, и слаба там, где нужно знание фактов о конкретной организации.
Задачи, которые ИИ закрывает уверенно:
- Превращение сырых заметок, расшифровки совещания или голосовой диктовки руководителя в связный структурированный документ.
- Приведение десяти разнородных инструкций к единой структуре и единой терминологии.
- Переписывание тяжёлого канцелярского текста в язык, понятный новичку без отраслевого опыта.
- Создание нескольких версий одного документа под разные роли, когда из общего регламента нужно вытащить памятку для кладовщика и чек-лист для его руководителя.
- Поиск логических разрывов в готовом регламенте, где шаг начинается с данных, которые нигде до этого не появлялись.
- Генерация вопросов, которые нужно задать владельцу процесса, чтобы описание стало полным.
- Подготовка проверочных материалов, тестов и сценариев аттестации по готовому документу.
Задачи, где результат почти всегда требует серьёзной переработки:
- Любые сроки, нормативы и показатели, если вы их не задали сами. Модель поставит правдоподобные цифры, и они будут взяты из ниоткуда.
- Регламенты с юридическими последствиями, где нужны ссылки на действующие нормы трудового законодательства или отраслевые требования.
- Описание процессов, завязанных на особенности вашей учётной системы, настройки прав и реальные маршруты согласования.
- Инструкции по работе с оборудованием, где ошибка в последовательности действий создаёт риск для человека.
- Процессы, которые в компании не формализованы и живут в головах двух опытных сотрудников.
Генеративная модель не источник знаний о вашей компании. Это редактор и структуратор, которому вы передаёте знание. Качество документа на выходе определяется полнотой того, что вы передали на входе.
Почему гладкий регламент от ИИ часто оказывается мёртвым
Есть неочевидная причина, по которой сгенерированные документы не приживаются. Модель оптимизирует текст под связность и полноту, а реальный регламент работает за счёт конкретности и границ ответственности. Фраза о том, что менеджер оперативно информирует руководителя о проблемной сделке, выглядит нормально в документе и бесполезна в работе, потому что не определено ни что считается проблемной сделкой, ни в какой форме происходит информирование, ни что делает руководитель после этого.
Вторая причина глубже и связана с организационной психологией. Сотрудник выполняет инструкцию, если понимает, зачем она существует и что произойдёт при отклонении. Сгенерированный текст по умолчанию описывает идеальный ход процесса и почти никогда не описывает развилки, конфликты интересов и ситуации нехватки времени. В итоге документ описывает мир, в котором сотрудник не работает, и теряет авторитет после первого же столкновения с реальностью.
Отсюда практический вывод, который определяет всю дальнейшую работу. Основное усилие тратится не на промпт и не на выбор модели, а на предварительную фиксацию процесса. На моих проектах это соотношение держится в районе семидесяти процентов времени на подготовку данных и тридцати на генерацию с доработкой.
Подготовка данных перед генерацией
Задача этого этапа не в том, чтобы написать черновик вручную. Задача в том, чтобы собрать факты, которые модель не может знать, и зафиксировать их в виде, пригодном для передачи. Чем грубее и честнее заметки, тем лучше результат. Попытка сразу формулировать красиво мешает, потому что вы начинаете описывать процесс таким, каким он должен быть, а не таким, каким он является.
Как зафиксировать бизнес-процесс
Самый дешёвый и точный способ получить исходник — это разговор с человеком, который выполняет работу руками. Не с руководителем отдела, а с исполнителем. Запишите беседу на двадцать минут, расшифруйте её и отдайте расшифровку модели как первичный материал. Современные модели хорошо работают с неструктурированной речью, включая оговорки и перескоки с темы на тему.
Вопросы, которые стоит задать в этом разговоре:
- С чего для тебя начинается эта работа. Что должно произойти, чтобы ты понял, что пора действовать.
- Где ты берёшь данные и куда записываешь результат. Назови конкретные системы, папки и таблицы.
- Какие шаги ты делаешь по порядку. Проговаривай вплоть до нажатия кнопок, если это важно.
- Что ты делаешь, когда данных не хватает. К кому идёшь и сколько ждёшь ответа.
- Какие три ситуации чаще всего ломают обычный порядок.
- Что здесь делают неправильно новые сотрудники в первый месяц.
- Какое решение ты принимаешь сам, а какое согласуешь.
- Чем заканчивается работа. Как ты понимаешь, что результат принят.
Последние четыре вопроса дают больше половины ценности документа. Именно в них прячется то, чего модель не достроит сама и что потом превращается в разделы про исключения, зоны ответственности и критерии готовности.
Если процесс уже частично оцифрован, добавьте к расшифровке объективные источники. Выгрузка статусов сделок из системы учёта показывает фактическую последовательность этапов, которая часто расходится с тем, как её описывает отдел. Переписка по типовой задаче в рабочем мессенджере показывает реальные точки согласования. История правок в общем документе показывает, кто на самом деле принимает решение.
Разбивка процесса на шаги, сроки и ответственных
Сырую расшифровку полезно свести в таблицу до того, как вы начнёте генерировать текст. Это не бюрократия, а способ обнаружить дыры. Для каждого шага зафиксируйте пять параметров.
- Что происходит, одним глаголом в действительном залоге.
- Кто выполняет, по роли, а не по имени сотрудника.
- Что нужно на входе, включая конкретные документы и доступы.
- Что получается на выходе и где это фиксируется.
- Сколько времени отведено и от какого момента считается срок.
Пятый параметр почти всегда вызывает сопротивление, и именно поэтому его нужно заполнять. Пока срок не назван, шаг не управляем. Формулировка о сроке в один рабочий день бессмысленна без точки отсчёта, потому что непонятно, идёт ли отсчёт от поступления заявки, от её распределения или от момента, когда исполнитель её увидел.
Отдельно пройдите по таблице и проверьте стыки. Выход каждого шага должен совпадать со входом следующего. Если на третьем шаге сотруднику нужен расчёт стоимости, а ни один предыдущий шаг его не производит, у вас в процессе невидимая работа, которую кто-то делает неформально. Такие находки ценнее самого регламента, потому что они указывают на места, где процесс рвётся.
Регламент не описывает работу. Регламент описывает передачу ответственности между людьми. Там, где нет чёткой точки передачи, никакая формулировка не спасёт.
Исключения и граничные условия
Документ начинает работать тогда, когда отвечает на вопросы, возникающие в нестандартной ситуации. Сотрудник не читает регламент, когда всё идёт по плану, он открывает его в момент затруднения. Поэтому перед генерацией соберите список отклонений, и пусть он будет коротким, но настоящим.
Минимальный набор граничных условий для большинства процессов:
- Что делать, если ответственный недоступен. Кто замещает и как это оформляется.
- Что делать, если срок уже нарушен. Нужно ли догонять по обычной схеме или включается другой порядок.
- Что делать при неполных входных данных. Остановить работу, запросить информацию или продолжить с пометкой.
- Где граница самостоятельности. При какой сумме, объёме или степени риска решение поднимается выше.
- Что считается отказом. Как закрывается работа, которая не будет выполнена.
- Как фиксируется отклонение от регламента, если оно было оправданным.
Последний пункт встречается в документах редко, а на практике снимает основную часть конфликтов. Любой жёсткий порядок рано или поздно противоречит интересам дела, и если у сотрудника нет легального способа отступить от правила с фиксацией причины, он отступит без фиксации. После этого регламент перестаёт отражать реальность, и отследить это будет уже невозможно.
Как составить промпт для регламента
Промпт для такого документа не похож на обычный запрос к чату. Это техническое задание, в котором больше фактов, чем инструкций. Хороший промпт на создание регламента занимает от тридцати строк, и большую часть этого объёма составляют данные о процессе, собранные на предыдущем этапе.
Обязательные элементы промпта
Структура, которая устойчиво даёт пригодный черновик, состоит из семи частей.
- Роль и задача. Укажите, что модель выступает как методолог по описанию процессов, и назовите тип документа, который нужен на выходе. Регламент процесса, должностная инструкция и памятка новичку устроены по-разному, и смешивать их нельзя.
- Контекст организации. Отрасль, размер компании, в каких системах ведётся работа, кто читатель документа и каков его уровень подготовки. Инструкция для студента на стажировке и для специалиста с пятилетним опытом отличаются объёмом пояснений.
- Данные процесса. Та самая таблица шагов с ролями, входами, выходами и сроками, перенесённая в текст как есть. Здесь не нужна литературная обработка.
- Исключения. Список граничных условий отдельным блоком, чтобы модель не растворила их внутри основных шагов.
- Требуемая структура документа. Перечислите разделы в нужном порядке. Если этого не сделать, модель выберет структуру сама, и при следующей генерации она будет другой.
- Ограничения. Запрет на выдумывание сроков, нормативов, названий систем и ссылок на законодательство. Требование помечать места, где данных не хватает, вместо их достраивания.
- Формат вывода. Нумерация пунктов, длина абзацев, язык формулировок, наличие таблицы ответственности.
Шестой пункт заслуживает отдельного внимания, потому что он меняет поведение модели сильнее остальных. Прямое указание не домысливать отсутствующие данные и вместо них ставить явную пометку о нехватке информации превращает генерацию в диагностику. Вы получаете не только черновик, но и карту пробелов в собственном понимании процесса.
Генерация с нуля и по готовому образцу
Два режима работы требуют разных промптов, и путаница между ними портит результат чаще, чем выбор модели.
Генерация с нуля применяется, когда процесс есть, а описания нет. В этом режиме вы опираетесь на собранные данные и просите модель построить структуру. Риск здесь в том, что документ получится формально правильным и не похожим на остальные документы компании, что создаёт проблему при сведении базы знаний.
Работа по образцу применяется, когда у вас уже есть утверждённые документы и нужно сохранить единый вид. Тогда в промпт добавляется готовый регламент по другому процессу с указанием воспроизвести его структуру, стиль и уровень детализации, но наполнить новыми данными. Такой подход даёт ощутимо более высокую приживаемость документа внутри компании, потому что сотрудники не тратят силы на освоение новой формы.
Отдельно существует смешанный вариант, который я считаю оптимальным для компаний, выстраивающих систему документов впервые. Сначала вы вместе с моделью создаёте один эталонный регламент и доводите его вручную до состояния, которое вас полностью устраивает. Дальше этот документ работает как образец для всех остальных, а промпт сводится к передаче нового набора данных и ссылки на эталон. Время на второй и последующие документы падает в несколько раз.
Ошибки в промптах, из-за которых регламент получается общим
Почти все жалобы на бесполезность сгенерированных регламентов сводятся к небольшому набору повторяющихся дефектов запроса.
- Запрос в одну строку без данных о процессе. Модель получает только название документа и выдаёт обобщённый шаблон из обучающих данных.
- Роли названы обезличенно. Формулировка про ответственное лицо вместо конкретной должности лишает документ управляемости.
- Не задан читатель. Без указания уровня подготовки модель выбирает нейтрально-канцелярский регистр, который плохо читается на рабочем месте.
- Нет требования к объёму. Запрос на подробный регламент даёт двадцать страниц воды, запрос на краткий даёт бесполезные тезисы. Указывайте ориентир в знаках или в количестве пунктов.
- Процесс описан результатами, а не действиями. Если во входных данных сказано, что заявка обрабатывается, модель сама придумает, из чего состоит обработка.
- Всё в одном запросе. Попытка получить регламент, должностную инструкцию, чек-лист и форму отчёта за один проход размывает каждый из документов.
- Нет запрета на выдумывание. Без прямого ограничения модель заполнит пустоты правдоподобными цифрами, и проверять придётся каждую.
Есть ещё одна ошибка, которая не видна сразу. Люди пишут промпт один раз и выбрасывают его, оставляя только результат. При следующем документе работа начинается заново. Промпт для регламента стоит хранить как рабочий инструмент, потому что после трёх-четырёх итераций он превращается в шаблон, который закрывает основную часть документов компании с заменой блока данных.
Готовые промпты
Ниже три рабочих заготовки, которые закрывают основную часть потребностей компании. Они написаны так, чтобы вы подставляли свои данные в обозначенные блоки и не переписывали остальное. Все три содержат ограничение на домысливание, потому что без него любой промпт деградирует до генератора правдоподобного текста.
Важная деталь по работе с этими заготовками. Не отправляйте промпт одним сообщением, если данных много. Сначала отправьте модели контекст и данные процесса с пометкой, что это материал для последующей работы и отвечать пока не нужно. Вторым сообщением отправьте задачу и требования к структуре. Так модель удерживает факты точнее и реже смешивает ваши данные с общими представлениями о процессе.
Регламент бизнес-процесса
Этот промпт описывает процесс целиком, со всеми участниками и передачами ответственности. Он не подходит для описания одной должности, потому что регламент процесса идёт по горизонтали, через отделы.
- Ты методолог по описанию бизнес-процессов. Твоя задача — составить регламент процесса на основе данных, которые я передал. Ты не добавляешь факты от себя.
- Контекст. Компания работает в сфере [отрасль], численность [число] человек. Учёт ведётся в [система], коммуникации в [система]. Читатель документа — сотрудники отделов [перечислить] с опытом от [срок].
- Название процесса. [Название].
- Границы процесса. Начинается с [событие-триггер], заканчивается [результат и место его фиксации].
- Участники и роли. [Перечислить роли без имён].
- Шаги процесса. [Вставить таблицу шагов с полями что происходит, кто, вход, выход, срок и точка отсчёта].
- Исключения и граничные условия. [Вставить список отклонений].
- Структура документа. Назначение и область применения, термины, роли и зоны ответственности, последовательность шагов с нумерацией, таблица ответственности по шагам, порядок действий при отклонениях, порядок фиксации обоснованного отступления от регламента, контроль исполнения.
- Ограничения. Не придумывай сроки, нормативы, названия систем, должности и ссылки на законодательство. Если данных для шага не хватает, вставь строку с пометкой о нехватке информации и сформулируй конкретный вопрос ко мне.
- Формат. Пункты нумерованные, не более трёх предложений на пункт, формулировки в действительном залоге, без канцелярита. Объём до [число] знаков.
- После основного текста выведи отдельным блоком список всех вопросов, на которые тебе не хватило данных.
Одиннадцатый пункт даёт больше пользы, чем сам черновик. На первой итерации вы обычно получаете от восьми до двадцати вопросов, и это точный перечень того, что в компании не определено. Регламент без ответов на них будет описывать несуществующий порядок.
Должностная инструкция
Должностная инструкция идёт по вертикали и описывает одного человека во всех процессах, где он участвует. Если вы попросите модель сделать её из регламента процесса, получится пересказ, а не документ. Нужен отдельный запрос с другой логикой входных данных.
- Ты специалист по кадровому документообороту и описанию должностей. Составь должностную инструкцию строго по переданным данным.
- Должность. [Название], подразделение [название], непосредственный руководитель [должность].
- Место в процессах. Сотрудник участвует в следующих процессах с такими функциями. [Перечислить процессы и роль в каждом].
- Результаты, за которые отвечает. [Перечислить измеримые результаты, а не виды деятельности].
- Полномочия и границы самостоятельности. Принимает решения самостоятельно по [перечислить]. Согласовывает с руководителем [перечислить]. Не имеет права [перечислить].
- Требования к квалификации. [Образование, опыт, навыки, знание систем].
- Взаимодействие. С кем обменивается информацией, в какой форме и с какой периодичностью. [Перечислить].
- Структура документа. Общие положения, квалификационные требования, функции и зоны ответственности, права, порядок взаимодействия, оценка результатов работы, ответственность.
- Ограничения. Не добавляй обязанности, которых нет в переданных данных. Не формулируй ответственность через ссылки на статьи законов. Раздел об ответственности оставь в общем виде с пометкой, что формулировки требуют проверки кадровой службой и юристом.
- Формат. Каждая функция — отдельный пункт с указанием результата, по которому проверяется её выполнение.
Девятый пункт здесь не формальность. Должностная инструкция в России может стать частью трудовых отношений и использоваться при спорах, поэтому сгенерированные формулировки об ответственности и основаниях для взысканий недопустимо переносить в утверждаемый документ без проверки специалистом. Модель воспроизводит обобщённые шаблоны, часть из которых опирается на устаревшие редакции норм.
| Параметр | Регламент процесса | Должностная инструкция | Памятка новичку |
|---|---|---|---|
| Направление описания | Горизонтально, через отделы | Вертикально, одна роль | Одна задача целиком |
| Основа содержания | Последовательность шагов и передач | Функции и результаты роли | Действия и типовые ошибки |
| Кто утверждает | Владелец процесса | Кадровая служба и руководитель | Наставник или руководитель |
| Срок пересмотра | При изменении процесса | При изменении функций | Постоянно, по обратной связи |
| Пригодность генерации ИИ | Высокая при полных данных | Средняя, нужна проверка юриста | Высокая |
Памятка для нового сотрудника
Памятка решает другую задачу. Она не фиксирует договорённости, а помогает человеку выполнить работу в первый раз. Поэтому в ней допустимы пояснения, подсказки и описание того, как выглядит правильный результат. Для генерации памятки лучшим исходником служит не регламент, а список ошибок новичков из разговора с опытным исполнителем.
- Ты наставник, который объясняет работу человеку в его первую неделю. Составь памятку по задаче [название] на основе переданных данных.
- Читатель. Опыт в этой сфере [нет или сколько], знаком с системами [перечислить], не знаком с [перечислить].
- Что нужно сделать. [Описание результата, который сотрудник должен получить].
- Порядок действий. [Шаги, вплоть до названий кнопок и полей, если это важно].
- Типовые ошибки новичков. [Перечислить из опроса исполнителя, с указанием последствий каждой].
- К кому обращаться. [Роль, по какому вопросу, каким способом].
- Структура. Короткое пояснение зачем нужна задача, подготовка перед началом, пошаговый порядок, как проверить себя перед сдачей, частые ошибки с последствиями, к кому идти с вопросами.
- Формат. Простой разговорный язык без канцелярита, короткие предложения, пункты не длиннее двух строк, объём до [число] знаков. Терминологию поясняй при первом упоминании.
- Ограничения. Не придумывай названия полей, кнопок и систем, которых нет в данных. Не добавляй ошибок, которых я не перечислил.
Блок про самопроверку перед сдачей работы — главная ценность памятки. Он снижает количество обращений к наставнику заметно сильнее, чем подробное описание шагов, потому что отвечает на вопрос, который новичок боится задать вслух.
Регламент нужен компании, чтобы спорить о ответственности. Памятка нужна сотруднику, чтобы сделать работу. Это два разных документа, и попытка совместить их даёт текст, непригодный ни для того, ни для другого.
Проверка и доработка черновика
Черновик от модели выглядит готовым документом, и в этом основная ловушка. Гладкая структура и уверенный тон маскируют пропуски, которые при чтении по диагонали не видны. Проверка должна быть процедурой, а не просто внимательным чтением, иначе вы будете находить ошибки формулировок и пропускать ошибки логики.
Правило трёх проходов: логика, полнота, формулировки
Три прохода делаются раздельно и в строгом порядке. Смешивание проходов приводит к тому, что вы правите слова в пункте, который вообще не должен существовать.
Первый проход проверяет логику и делается только человеком, знающим процесс. Вы читаете документ как исполнитель и на каждом шаге задаёте один вопрос. Могу ли я выполнить этот шаг, имея только то, что появилось в предыдущих шагах. Разрывы обнаруживаются быстро. Типичный пример, когда в пункте о согласовании сметы не сказано, откуда взялась смета и кто её составил.
Второй проход проверяет полноту и здесь уместно привлечь модель, но в роли критика, а не автора. Отдайте ей готовый черновик в новом диалоге и попросите найти пробелы, не исправляя текст.
- Найди шаги, у которых не определён ответственный или срок.
- Найди места, где не указано, что происходит при отрицательном исходе шага.
- Перечисли ситуации из практики такого процесса, которые документ не покрывает.
- Укажи пункты, которые можно выполнить двумя разными способами из-за неоднозначной формулировки.
- Проверь, совпадает ли выход каждого шага со входом следующего.
- Найди термины, использованные в разных значениях в разных частях документа.
Запрос в новом диалоге принципиален. Если просить критику в том же окне, модель защищает собственный текст и выдаёт мягкие замечания, потому что опирается на предыдущий контекст как на согласованный результат.
Третий проход касается языка. Здесь модель работает хорошо и быстро. Просите убрать отглагольные существительные, заменить страдательный залог на действительный, сократить пункты длиннее трёх строк и привести терминологию к единому словарю. Один приём стоит отдельного упоминания. Попросите переписать документ так, чтобы его понял человек, впервые пришедший в отрасль, а затем сравните две версии. Все места, где после упрощения смысл изменился, содержат скрытую неоднозначность.
Проверка юридически значимых пунктов
Существует набор формулировок, которые нельзя оставлять в документе без участия юриста и кадровой службы. Модель воспроизводит их уверенно и часто с ошибками в деталях, потому что обучающие данные содержат документы разных лет и разных юрисдикций.
- Любые ссылки на статьи трудового законодательства и отраслевых нормативных актов. Проверяйте по действующей редакции, а не по тексту от модели.
- Основания для дисциплинарных взысканий и формулировки об ответственности сотрудника.
- Положения о материальной ответственности и о возмещении ущерба.
- Пункты о работе с персональными данными, доступах и подписании согласий.
- Требования охраны труда и промышленной безопасности. Здесь генерация допустима только как черновик для специалиста по охране труда.
- Условия, влияющие на оплату, премирование и депремирование.
- Обязательства о коммерческой тайне и перечень сведений, которые к ней отнесены.
Практичный приём для таких блоков состоит в том, чтобы вообще запретить модели их генерировать. В промпте указывается, что в соответствующих разделах нужно поставить пометку о необходимости заполнения специалистом и перечислить, какие именно вопросы предстоит решить. Документ приходит с явными пропусками, и это честнее, чем правдоподобный текст, который легко пропустить при утверждении.
Что убрать из текста ИИ
Сгенерированные регламенты имеют узнаваемый набор лишнего. Он не делает документ неверным, но увеличивает объём и снижает вероятность, что текст прочитают до конца.
- Вступительные рассуждения о важности процесса для эффективности компании. Назначение документа формулируется одним абзацем.
- Дублирование одних и тех же требований в разделах о правах, обязанностях и ответственности.
- Пункты про соблюдение корпоративной этики и повышение квалификации, если за ними не стоит конкретное требование.
- Избыточная терминология в начале, где поясняются очевидные для отрасли слова.
- Фразы про своевременное и качественное выполнение, которые невозможно проверить.
- Разделы о взаимодействии, сводящиеся к утверждению, что сотрудник взаимодействует со всеми подразделениями по вопросам своей деятельности.
- Повторы структуры, когда модель дублирует шаги в виде таблицы и сразу текстом.
Ориентир по объёму помогает держать документ живым. Регламент одного процесса, который реально используется, обычно укладывается в три-пять страниц, памятка — в одну-две. Если черновик вышел на двенадцать страниц, почти наверняка в нём описан не один процесс, а несколько, и его следует разделить. Длинный документ не читают, а нечитаемый регламент не отличается от отсутствующего, при этом создаёт иллюзию управляемости.
Внедрение регламента в работу
Документ начинает существовать не в момент утверждения, а в момент, когда по нему выполнили работу. Между этими событиями обычно обнаруживается, что половина формулировок понимается иначе, чем задумывал автор. Этап внедрения стоит планировать так же серьёзно, как написание, иначе весь выигрыш от быстрой генерации уйдёт в накопление мёртвых файлов в общей папке.
Тест на реальном сотруднике
Самая дешёвая проверка качества выглядит так. Дайте документ человеку, который этот процесс не выполнял, и попросите пройти его по тексту без подсказок. Рядом сидит владелец процесса и молча фиксирует каждое место, где исполнитель остановился, переспросил или сделал не то. Двадцать минут такого наблюдения дают больше правок, чем три круга согласований по почте.
Что именно нужно записывать во время теста:
- Пункты, на которых человек задал вопрос. Каждый вопрос — это недостающая часть документа.
- Места, где он сделал действие правильно, но не по инструкции. Значит, реальный порядок удобнее описанного.
- Шаги, которые он пропустил, потому что не понял их необходимости.
- Термины, которые пришлось объяснять словами.
- Моменты, когда он искал информацию вне документа, в чате или в системе учёта.
- Общее время прохождения по сравнению с временем у опытного сотрудника.
Расшифровку этих наблюдений можно отдать модели как материал для доработки. Запрос формулируется просто. Вот документ, вот список мест, где исполнитель запнулся, перепиши соответствующие пункты так, чтобы вопросы не возникали, остальной текст не трогай. Последнее условие важно, иначе модель перепишет весь документ заново и потеряет уже согласованные формулировки.
Отдельная польза теста в том, что он снимает спор о детализации. Руководители часто считают регламент слишком подробным, а исполнители слишком общим. Наблюдение за реальным прохождением закрывает дискуссию фактами, потому что видно, где не хватает деталей, а где они избыточны.
Утверждение и актуализация документа
Утверждение превращает текст в обязательный к исполнению. Процедура зависит от типа документа и от того, как в компании устроен документооборот, но несколько правил работают везде.
- У каждого документа один владелец, и это не кадровая служба и не ИИ-методолог, а руководитель, отвечающий за результат процесса.
- В документе указаны дата введения в действие, номер версии и дата следующего плановой проверки актуальности.
- Есть журнал изменений, где видно, что именно поменялось в новой версии. Сотрудник не должен перечитывать документ целиком, чтобы найти правку.
- Старые версии не удаляются, а переводятся в архив. При разборе спорной ситуации важно знать, какая редакция действовала в момент события.
- Ознакомление фиксируется. Способ может быть любым от подписи до отметки в корпоративной системе, но факт должен быть зафиксирован.
- У сотрудников есть один легальный канал для предложений по изменению документа. Без него правки будут происходить неформально, через устные договорённости.
Актуализация — то место, где ИИ приносит наибольшую пользу после внедрения, и её почти всегда недооценивают. Процессы меняются непрерывно, а пересмотр документов требует времени, которого нет. Модель сокращает эту работу радикально. Передайте ей текущую версию регламента и описание изменения, например переход на другую систему учёта или появление новой роли, и попросите выдать не новый документ, а перечень пунктов, которые затрагивает изменение, с предложенными формулировками для каждого. Вы получаете точечную правку вместо переписывания.
Второй сценарий работает на уровне всей базы документов. Когда регламентов становится несколько десятков, они начинают противоречить друг другу. Загрузите весь набор и попросите найти расхождения в сроках, в названиях ролей, в описании одних и тех же шагов в разных документах и в терминологии. Такая сверка вручную занимает недели, модель проходит её за один сеанс, и результат требует только проверки, а не поиска.
Регламент, который не пересматривался год, описывает процесс, которого уже нет. Главная ценность ИИ в этой области не в скорости первой генерации, а в том, что поддержание документов в живом состоянии перестаёт быть неподъёмной задачей.
Нейросети и сервисы для работы с регламентами
Выбор инструмента зависит от того, какая задача решается и насколько чувствительны данные. Для разовой генерации документа достаточно универсального чата. Для работы с базой знаний на сотни файлов нужна другая архитектура. Для проверки документов на соответствие требованиям — третья.
Универсальные чат-модели
Это основной рабочий инструмент для написания и редактирования документов. На российском рынке доступны как отечественные решения вроде GigaChat от Сбера и YandexGPT, так и зарубежные модели семейств GPT, Claude и Gemini, включая DeepSeek и модели Qwen. Доступ к зарубежным моделям для компаний чаще организуется через агрегаторы и промежуточные сервисы, что добавляет ещё одно звено к вопросу конфиденциальности.
Практические соображения при выборе:
- Размер контекстного окна. Если вы работаете с длинными документами или загружаете несколько регламентов сразу, это главный параметр. Модели с окном от двухсот тысяч токенов позволяют держать всю базу в одном диалоге.
- Качество работы с русским языком в формальном регистре. Разница между моделями здесь ощутимая, особенно в части канцелярита и согласования длинных конструкций.
- Способность следовать жёстким ограничениям. Это ключевое для нашей задачи. Проверяйте модель простым тестом: дайте неполные данные и запрет на домысливание. Хорошая модель вернёт пометки о нехватке информации, слабая заполнит пробелы сама.
- Работа с файлами. Загрузка документов целиком экономит много времени по сравнению с копированием текста в окно.
- Юридический статус обработки данных. Где находятся серверы, есть ли договор, обучается ли модель на ваших запросах.
- Стабильность доступа. Для встроенного в процесс инструмента это важнее качества генерации.
Для компаний, работающих с данными ограниченного доступа, существует вариант развёртывания открытых моделей на собственной инфраструктуре. Качество уступает ведущим коммерческим моделям, но для структурирования документов и приведения их к единому виду оказывается достаточным, а данные не покидают контур организации.
Корпоративные ИИ-ассистенты и базы знаний на RAG
Когда документов становится много, меняется сама задача. Создание отходит на второй план, на первый выходит поиск ответа. Сотруднику не нужен регламент целиком, ему нужно знать, кто согласовывает закупку на определённую сумму.
Обычный чат для этого не подходит, потому что он не знает содержания ваших документов, а загружать всю базу в каждый запрос нерационально. Решение строится по схеме поиска с дополнением контекста, известной как RAG. Работает она в три такта.
- Все документы разбиваются на фрагменты и индексируются в векторной базе, где близкие по смыслу тексты располагаются рядом.
- На вопрос сотрудника система находит релевантные фрагменты, не полагаясь на точное совпадение слов.
- Найденные фрагменты передаются модели вместе с вопросом, и ответ формируется только на их основе, со ссылкой на источник.
Ссылка на источник — обязательное требование. Ответ без указания документа и пункта невозможно проверить, а в вопросах регламентов непроверяемый ответ хуже отсутствия ответа. Хорошо настроенный ассистент отвечает примерно так: согласование требуется при сумме свыше указанного порога, основание — пункт такой-то регламента закупок в редакции от такой-то даты.
Что определяет успех такого внедрения на практике:
- Качество исходных документов. Система, построенная на противоречивой базе, будет уверенно выдавать противоречивые ответы. Сначала порядок в документах, потом ассистент.
- Актуальность индекса. Устаревшая версия в базе опаснее, чем её отсутствие.
- Разграничение доступа. Ассистент не должен выдавать сотруднику содержание документов, к которым у него нет прав. Это ломает большинство простых реализаций.
- Явный отказ отвечать. Модель должна сообщать, что в базе нет информации по вопросу, вместо выдачи общего правдоподобного ответа.
- Логирование вопросов. Анализ того, что спрашивают чаще всего, точно показывает, какие регламенты написаны плохо.
Пятый пункт обычно оказывается неожиданным побочным результатом. Журнал обращений к ассистенту работает как карта непонятных мест в документах, которую невозможно получить никаким опросом сотрудников.
Автоматическая проверка документов (нормоконтроль)
Третий класс задач — проверка готовых документов на соответствие требованиям. Здесь модель работает не как автор, а как контролёр, и справляется заметно лучше, чем при генерации, потому что проверка опирается на переданный текст, а не на внутренние представления.
Что реально поддаётся автоматической проверке:
- Соответствие структуры документа принятому в компании шаблону. Отсутствующие разделы находятся надёжно.
- Единство терминологии в рамках одного документа и по всей базе.
- Полнота обязательных реквизитов, включая версию, дату, владельца и порядок пересмотра.
- Наличие ответственного и срока для каждого шага.
- Внутренние противоречия, когда один пункт отменяет другой или устанавливает иной срок.
- Формулировки, не поддающиеся проверке исполнения.
- Ссылки на отменённые внутренние документы, если база загружена целиком.
Чего ждать от такой проверки не стоит. Модель не даёт юридического заключения и не подтверждает соответствие законодательству. Она способна указать на место, требующее внимания юриста, и это уже существенная экономия, но решение остаётся за специалистом. Формулировка о том, что документ проверен ИИ и соответствует требованиям, не имеет ни правового, ни практического смысла.
Для регулярного нормоконтроля удобно собрать отдельный промпт-чеклист, где перечислены все ваши требования к документам, и прогонять через него каждый новый регламент перед утверждением. Пять минут работы снимают основную часть замечаний, которые иначе всплыли бы на согласовании.
Конфиденциальность и ограничения при работе с внутренними документами
Регламенты содержат описание того, как устроена компания изнутри. Это чувствительная информация даже тогда, когда в тексте нет ни персональных данных, ни коммерческой тайны в юридическом смысле. Схема согласования закупок, пороги самостоятельности сотрудников и слабые места контроля представляют интерес для недобросовестных конкурентов и для внутренних злоупотреблений.
Базовые правила, которые стоит зафиксировать до начала работы с любыми моделями:
- Определите категории документов, которые нельзя передавать во внешние сервисы. Обычно это документы с персональными данными, с коммерческой тайной и регламенты в области информационной безопасности.
- Для остальных документов проверьте условия сервиса в части обучения на пользовательских данных. В бесплатных и потребительских версиях обучение чаще всего включено по умолчанию, в корпоративных тарифах его как правило можно отключить.
- Обезличивайте данные перед передачей. Имена заменяйте должностями, названия контрагентов и внутренних систем — обозначениями вида система учёта и поставщик. Смысл процесса при этом не теряется.
- Не загружайте во внешние сервисы выгрузки из рабочих систем, содержащие сведения о сотрудниках, клиентах, ценах и условиях договоров.
- Учитывайте требования законодательства о персональных данных при выборе сервиса, в том числе в части места обработки информации.
- Закрепите правила в отдельном внутреннем документе о применении ИИ. Без него сотрудники будут использовать первые доступные сервисы со своих личных аккаунтов, и контроль станет невозможным.
- Для работы с чувствительными документами рассматривайте решения в собственном контуре или корпоративные версии с договором об обработке данных.
Шестой пункт на практике оказывается самым результативным. Запретительный подход не работает, потому что выгода от использования моделей слишком очевидна для сотрудников. Работающий вариант — назвать разрешённые сервисы, описать, какие данные в них можно передавать, и дать понятную процедуру для спорных случаев. Такой документ, кстати, тоже удобно составить с помощью модели, предварительно собрав требования службы безопасности и юристов.
Ограничения, которые не снимаются настройкой
Есть несколько границ, за которые текущее поколение моделей не выходит, и понимание этих границ избавляет от разочарований.
- Модель не отвечает за документ. Ответственность за содержание регламента всегда на человеке, который его утвердил.
- Модель не знает контекста решений. Она не понимает, почему в вашей компании согласование устроено именно так, и будет предлагать упрощения, ломающие важные контрольные точки.
- Модель не чувствует политическую сторону вопроса. Перераспределение зон ответственности между подразделениями затрагивает интересы людей, и это не решается формулировками.
- Модель не может достоверно подтвердить соответствие нормам. Любые ссылки на законодательство требуют проверки по первоисточнику.
- Модель не заменяет разговор с исполнителем. Без первичных данных о реальной работе любая генерация остаётся качественным описанием усреднённого процесса.
Частые вопросы
Какие регламенты лучше всего получаются с помощью ИИ
Повторяющиеся процессы с чёткой последовательностью шагов и небольшим числом участников. Введение нового сотрудника в должность, обработка обращения клиента, подготовка регулярного отчёта, согласование типового документа, порядок передачи дел на время отпуска. Хуже всего получаются процессы творческие, с большим количеством развилок и неформальных договорённостей.
Сколько времени занимает создание одного регламента
При готовых данных о процессе от получаса до двух часов, включая проверку. Основное время уходит не на генерацию, а на сбор фактов. Разговор с исполнителем, сведение шагов в таблицу и выяснение исключений занимают от двух до четырёх часов на процесс средней сложности. Второй и последующие документы по шаблону идут в два-три раза быстрее.
Что делать, если сгенерированный регламент слишком общий
Причина почти всегда во входных данных, а не в модели. Проверьте, описаны ли шаги действиями, а не результатами, названы ли роли конкретными должностями, заданы ли сроки с точкой отсчёта. Добавьте в промпт требование помечать места нехватки данных и задавать вопросы. Повторная генерация с тем же промптом и просьбой сделать подробнее результата не улучшает.
Можно ли сделать регламент по образцу существующего документа
Да, и это предпочтительный путь при наличии утверждённых документов. Загрузите образец, укажите воспроизвести его структуру, стиль и уровень детализации, передайте данные нового процесса. Так новый документ не выбивается из базы и сотрудники читают его без адаптации к новой форме.
Нужно ли разбивать большой регламент на части
Если документ вышел длиннее пяти-шести страниц, скорее всего в нём описано несколько процессов. Разделите по границам ответственности или по этапам с явными точками передачи. Общую часть с терминами и ролями можно вынести в отдельный документ, на который ссылаются остальные.
Как проверить, что регламент понятен без доработок
Единственный надёжный способ — дать его человеку, не выполнявшему этот процесс, и наблюдать прохождение. Все вопросы, которые он задаст, указывают на пробелы. Дополнительно можно попросить модель пересказать документ своими словами и сравнить пересказ с тем, что вы имели в виду.
Может ли ИИ составить регламент межотделского взаимодействия
Технически да, но такие документы требуют данных от всех участвующих подразделений. Опрос только одной стороны даст перекошенное описание, где чужие обязанности сформулированы шире собственных. Соберите данные от каждого отдела отдельно, затем передайте модели оба описания и попросите найти расхождения. Это самая ценная часть работы.
Нужно ли сообщать сотрудникам, что документ составлен с помощью ИИ
Содержание документа важнее способа его создания, и формально такого требования нет. На практике полезно обозначить, что текст прошёл проверку владельцем процесса и утверждён руководителем. Это снимает вопрос доверия, который неизбежно возникает, когда сотрудники узнают о генерации окольным путём.
Какие документы не стоит создавать с помощью ИИ вообще
Инструкции по охране труда и промышленной безопасности, документы с юридическими последствиями для сотрудника без участия юриста, положения об обработке персональных данных и внутренние документы по информационной безопасности. В этих областях модель допустима как помощник для структурирования, но не как источник содержания.
Искусственный интеллект не пишет за вас регламенты. Он снимает с вас работу по оформлению и поддержанию документов, оставляя то, что всегда было главным и всегда делалось плохо из-за нехватки времени, — честное понимание того, как в вашей компании действительно устроена работа.
