Инструкция для человека vs инструкция для LLM-агента

Классическая ситуация.

Приходит заказчик: «У нас есть регламент согласования договоров. Страничка текста. Сделайте AI-агента, который будет по нему работать».

Звучит просто. Регламент есть, логика ^[1] понятна. Осталось «написать промпт».

Через месяц — провал. Агент делает ерунду, сотрудники его игнорируют, деньги потрачены.

Почему? Потому что инструкция для человека и инструкция для LLM-агента — два совершенно разных документа. Разница не в формате. Разница в том, что человек додумывает, а машина — нет.

Пример: 6 пунктов для менеджера

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

Инструкция для менеджера:

1. Получить договор от контрагента

2. Проверить реквизиты

3. Отправить юристу на про��ерку

4. Получить правки, отправить контрагенту

5. После согласования — на подпись директору

6. Подписанный скан — в архив

Шесть пунктов. Полстраницы текста. Любой менеджер с опытом ^[2] справится.

Но попробуйте дать эту инструкцию LLM-агенту…

Что «знает» человек, но не написано в инструкции

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

Каналы получения. Договор может прийти на почту, в мессенджер, через ЭДО или вообще в бумажном виде. Если прислали не договор, а «рыбу» — это другой процесс. Если контрагент новый — сначала проверка через службу безопасности.

Проверка реквизитов. Что именно проверять? ИНН, КПП, адрес, банковские реквизиты. Где брать эталонные данные для сверки? Что делать, если реквизиты изменились с прошлого договора?

Юрист. Какому именно юристу отправлять? У нас их трое. В какой форме — письмо, задача в CRM, сообщение в чат? Сколько ждать ответа — день, неделю? А если юрист в отпуске?

Правки и согласование. Как оформлять правки — режим рецензирования, комментарии, отдельный файл? Сколько итераций допустимо? Когда эскалировать на руководителя?

И это я ещё не дошёл до подписи и архива…

Реальный объём инструкции для агента

Чтобы LLM-агент реально работал, каждое неявное знание нужно описать явно. Вот примерная структура:

1. Входные данные и валидация — каналы получения, форматы файлов, правила классификации документа.

2. Классификация договора — типы (поставка, услуги, аренда, NDA и т.д.), критерии определения, маршрут для каждого типа.

3. Проверка контрагента — алгоритм «новый/существующий», источники данных (ЕГРЮЛ, внутренняя база), критерии допуска.

4. Проверка реквизитов — список полей, эталонные источники, правила сопоставления с учётом опечаток, действия при расхождениях.

5. Маршрутизация на юриста — правила выбора по типу договора и загрузке, формат передачи, SLA, эскалация при просрочке, обработка отсутствия.

6. Работа с правками — формат фиксации, лимит итераций, правила эскалации при разногласиях.

7. Подписание — правила выбора подписанта по сумме и типу, интеграция с ЭЦП, обработка отказа.

8. Архивация — именование файлов, структура папок, метаданные, связь с CRM.

9. Исключительные ситуации — срочные договоры, типовые с упрощённым маршрутом, рамочные соглашения, ошибки ^[3] на любом этапе.

Это не полстраницы. Это 10-15 страниц минимум.

Вот как выглядит даже сокращённый конфиг:

# contract_approval_agent.yaml
process: contract_approval

input_validation:
  channels: [email, edo, messenger]
  formats: [docx, pdf, scan]
  classification:
    - pattern: "договор" → type: contract
    - pattern: "счёт" → type: invoice → reject

contractor_check:
  new_contractor:
    actions: [security_check, wait_approval]
    sla_hours: 48
  existing:
    actions: [verify_requisites, check_changes]

requisites_validation:
  fields:
    inn: { source: egrul_api, match: exact }
    kpp: { source: egrul_api, match: exact }
    bank_account: { source: internal_db, match: fuzzy_0.95 }
  on_mismatch: [log, request_clarification]

routing:
  - contract_type: rent → assignee: ivan.petrov
  - contract_type: supply → assignee: maria.sergeeva
  - amount_rub: ">1000000" → additional: cfo_approval

escalation:
  timeout_hours: 48
  levels: [department_head, legal_director, ceo]

exceptions:
  urgent: { marker: "СРОЧНО", sla_multiplier: 0.5 }
  framework: { requires: parent_contract_id, simplified: true }
 [4]

И это без описания интеграций с конкретными системами.

Почему так

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

Когда в регламенте написано «отправить юристу» — менеджер знает, что Иван Петрович специализируется на аренде, Мария Сергеевна — на поставках, а к Алексею лучше не попадать в пятницу после обеда.

LLM-агент не знает ничего из этого. Ему нужно явно прописать: «если тип = аренда, то юрист = Иван Петрович, канал = задача в Битрикс, SLA = 2 рабочих дня».

По сути, каждое решение, которое человек принимает «на автомате», нужно формализовать. Получается, что инструкция для агента — это не перевод регламента на машинный язык. Это полная спецификация процесса со всеми ветвлениями.

Чеклист: готов ли процесс к автоматизации

Прежде чем вкладываться в AI-агента, проверьте пять вещей.

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

Описаны все исключения. Что делать, если контрагент не отвечает неделю? Если юрист нашёл критичные риски? Если директор в командировке? Каждое «а если…» должно быть явно обработано.

Определены интеграции. С какими системами агент будет работать? Почта, CRM, ЭДО, хранилище? Есть ли API? Какие права доступа нужны?

Есть эталонные данные. Где агент возьмёт правильные реквизиты? Актуальный список юристов? Правила маршрутизации? Данные должны храниться и поддерживаться в актуальном состоянии.

Определены границы автономности. Что агент делает сам, а где запрашивает подтверждение? Для договоров это критично — цена ошибки высока.

Если на три и более вопроса ответ «нет» — вы не готовы к автоматизации. Сначала подготовительная работа.

Выводы

Автоматизация через AI — это не «взять регламент и скормить нейросети».

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

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

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

Серия «Почему AI-проекты проваливаются»:

1. 6 проблем, о которых молчат интеграторы ^[5]

2. Инструкция для человека vs инструкция для AI ← вы здесь

3. Кто отвечает за ошибки AI-агента ^[6]

4. Что делать, когда AI-агент «упал» ^[7]

5. Как передать агенту неявные знания ^[8]

6. Пошаговый план внедрения ^[9]

Анатолий Лапков. Telegram: @futex_ai ^[10]