ИИ-узел в конструкторе выглядит как обычный шаг: выбрал модель, вписал инструкцию, подключил вход и выход. Разница обнаруживается на второй неделе. Все остальные узлы сценария детерминированы: при одинаковом входе они дают одинаковый выход сегодня, завтра и через год. ИИ-узел на том же входе может ответить иначе — другим порядком полей, другой формулировкой, изредка другим смыслом. В автоматизации именно этого свойства всегда избегали, и не зря.
Из этого не следует, что модель в сценарии не нужна. Следует другое: ИИ-узел ставится только в паре с проверкой результата, и стоимость проверки надо закладывать сразу, а не после первого разбора. В модельном расчёте на 10 000 обращений в месяц узел обходится в 15 804 ₽, и сама модель в этой сумме — меньше четверти.
Ниже — три роли, в которых модель полезна и её ошибки дёшевы, три роли, в которых узел ставить нельзя, схема проверки из трёх рубежей, расчёт счёта и то, что изменилось в требованиях с 1 сентября 2026 года.
Что меняется, когда в сценарий ставят ИИ-узел
Шаг сценария, который на одинаковом входе не гарантирует одинаковый выход. Для сценария это означает, что нельзя воспроизвести прогон и нельзя доказать, что вчера система поступила так же, как сегодня. Все инженерные приёмы вокруг ИИ-узла — схема ответа, валидация, порог уверенности — существуют ровно для того, чтобы вернуть предсказуемость на границе узла, раз внутри её нет.
Практическое следствие одно, и оно важнее любых рассуждений о качестве моделей. Обычный сбой в сценарии громкий: узел упал, прогон остановился, пришёл алерт, порядок разбора мы описывали в материале про обработку ошибок в сценариях. Сбой ИИ-узла тихий: он возвращает правдоподобный ответ, сценарий считает его корректным и едет дальше. Ошибка обнаруживается не в логах, а в карточке клиента через месяц.
Поэтому вопрос при проектировании звучит не «справится ли модель», а «что произойдёт, если она ошибётся, и кто это заметит». Если ответ — «ничего страшного, менеджер исправит одним кликом», узел уместен. Если ответ — «уйдёт в учёт и всплывёт на сверке», узел на это место не ставят ни при какой точности.
Три роли, в которых модели можно доверять
У всех трёх общее свойство: результат виден человеку до того, как становится необратимым, а цена ошибки — один клик. Это и есть критерий отбора, а не сложность задачи.
- 1Классификация: разложить входящее по полкам
Обращение, письмо, заявка получают тему, срочность и адресата. Ошибка означает, что письмо попало не в ту очередь и его переложат руками. Это дешевле, чем чтение всей почты человеком, и заметно надёжнее ключевых слов: «не приходит доступ» и «не могу зайти» модель кладёт в одну корзину, а список стоп-слов — в разные. Механику и цену готового контура мы разбирали на странице классификации обращений.
- 2Извлечение полей: достать из текста то, что дальше поедет структурой
Из письма поставщика — номер счёта, сумма, срок; из заявки — телефон, адрес, состав. Роль безопасна при одном условии: каждое извлечённое поле проверяется формально — телефон на длину и формат, ИНН на контрольную сумму, сумма на диапазон. Поле, для которого проверку придумать нельзя, отдаётся человеку, а не берётся на веру.
- 3Черновик текста, который читает человек
Ответ клиенту, описание товара, письмо по шаблону. Ключевое слово — черновик: модель готовит, сотрудник читает и отправляет. Эффект здесь не в качестве текста, а в том, что пустой экран заменяется правкой готового, и это устойчиво быстрее. Как только сообщение уходит без чтения человеком, роль перестаёт быть безопасной и превращается в четвёртую строку следующего раздела.
Три роли, в которых узел ставить нельзя
Запретов тоже три, и объединяет их обратное свойство: ошибка не видна на глаз и не отменяется одним действием.
| Роль | Как выглядит ошибка | Почему её не поймать | Чем заменить |
|---|---|---|---|
| Расчёты: суммы, скидки, остатки, сроки | Число правдоподобное, но неверное на несколько процентов | Модель воспроизводит форму вычисления, а не выполняет его; проверить можно только пересчётом | Обычный узел с формулой или запрос в учётную систему |
| Юридические и нормативные выводы | Уверенная ссылка на норму, которой нет или которая изменилась | Формулировка звучит компетентно, и неспециалист не отличает её от верной | Проверка человеком с квалификацией, модель — только на подготовку черновика |
| Необратимые действия без подтверждения | Отправленное письмо, проведённый документ, списанный резерв | Ошибка обнаруживается на стороне клиента или на сверке, откатить уже нельзя | Тот же шаг, но с подтверждением человека перед действием |
Модель охотно посчитает скидку, пересортицу и срок доставки, и в девяти случаях из десяти попадёт. Десятый выглядит точно так же, как остальные девять, — и уезжает в документ. Правило простое: всё, что можно посчитать формулой, считается формулой. Модель применяется к тексту, а не к числам; её место — понять, что клиент просит рассрочку, а не вычислить её график.
Отдельно про необратимые действия. Граница проходит не по важности операции, а по возможности отката. Создать черновик письма — обратимо. Отправить — нет. Записать заявку в CRM — обратимо. Провести реализацию и снять остаток — нет. Практический приём: между ИИ-узлом и любым необратимым шагом ставится узел ожидания подтверждения, и это единственное место в сценарии, где задержка в минуты полезнее скорости. Подробнее эту развилку мы разбирали в материале про человека в контуре принятия решений.
Схема потоков данных слева направо. Блок «Входящее обращение» → блок «ИИ-узел: классификация и извлечение полей». От него выход в три последовательных ромба-рубежа: «1. Ответ уложился в схему?», «2. Поля прошли формальную проверку?», «3. Уверенность выше порога?». Ветка «да» с каждого рубежа идёт дальше по горизонтали и в конце входит в блок «Запись в CRM». Ветки «нет» с первого рубежа уходят вверх в блок «Повторный запрос, 4 % обращений», со второго и третьего — вниз в общий блок «Человеку по низкой уверенности: 10–15 % обращений». Под схемой подпись «10 000 обращений в месяц, выборочный контроль 5 % прошедших автоматически». Чертёжный стиль, подписи по-русски.
Три рубежа проверки, без которых узел не ставят
Проверка результата — не одна галочка, а три независимых рубежа. Каждый ловит свой класс ошибок, и пропуск любого из них означает, что этот класс поедет дальше молча.
- 1Схема ответа. Узел обязан вернуть строго заданный набор полей, а не свободный текст. Просьба в инструкции «отвечай в заданном формате» гарантии не даёт: она держится примерно на 99 ответах из 100. Гарантию даёт проверка на стороне сценария — не прошло, значит повторный запрос. Что именно ломается и как это стоит, мы посчитали в материале про строгий формат ответа агента.
- 2Формальная проверка полей. Каждое поле проходит правило, которое не зависит от модели: телефон — длина и код, ИНН — контрольная сумма, дата — календарный диапазон, сумма — коридор от и до. Поле, к которому такого правила придумать нельзя, помечается как «требует человека» ещё на этапе проектирования.
- 3Порог уверенности и передача человеку. Узел возвращает не только результат, но и признак сомнения: несколько подходящих категорий, пустое обязательное поле, текст короче осмысленного. Ниже порога сценарий не угадывает, а кладёт запись в очередь оператора. Доля таких обращений в рабочем контуре — 10–15 %, и это здоровое число, а не признак плохой настройки.
Четвёртый элемент формально не рубеж, но без него первые три слепнут: выборочный контроль качества. Раз в неделю человек читает случайные 5 % прошедших автоматически записей и отмечает ошибки. Это единственный способ заметить, что качество поехало, — а оно едет, когда меняется поток обращений, обновляется модель или кто-то поправил инструкцию «на минутку». Час в неделю на выборку стоит дешевле любого другого способа узнать об этом.
Сколько стоит узел: 10 000 обращений в месяц
Считаем узел классификации и извлечения полей на потоке 10 000 обращений в месяц. Модельные вводные: 1,2 тысячи токенов на обращение (инструкция, текст обращения и короткий структурированный ответ), цена расчёта 0,32 ₽ за 1 000 токенов по состоянию на сентябрь 2026 года, цена операции конструктора 0,15 ₽, четыре операции на обращение — вызов модели, проверка схемы, ветвление и запись.
Структура счёта важнее его размера. Модель — 3 840 ₽, то есть 24 %. Операции конструктора — 6 000 ₽, 38 %. Выборочный контроль качества — 5 810 ₽, 37 %. Повторные запросы — 154 ₽, около 1 %. Три четверти суммы не имеют отношения к тому, какую модель вы выбрали.
Главный вывод из этой структуры практический: экономить на модели почти бессмысленно. Вдвое более дешёвая модель снимет со счёта 1 920 ₽ и почти наверняка поднимет долю передач человеку, а каждый лишний процент передач — это 100 обращений в месяц, которые читает оператор: 2,5 часа и 1 750 ₽. Экономия исчезает на втором проценте. Мы разбирали эту арифметику подробно в материале о том, почему экономия на выборе модели ничего не даёт. Настоящие рычаги — число операций на обращение и объём передаваемого в модель текста.
Столбчатая диаграмма с накоплением, один столбец высотой 15 804 ₽, разбитый на четыре сегмента снизу вверх с подписями и долями: «Расчёт модели — 3 840 ₽, 24 %», «Операции конструктора — 6 000 ₽, 38 %», «Повторные запросы — 154 ₽, 1 %», «Выборочный контроль качества — 5 810 ₽, 37 %». Справа от столбца вертикальная скобка на трёх верхних сегментах с подписью «не зависит от выбора модели». Внизу подпись «10 000 обращений в месяц, 1,58 ₽ за обращение». Ось — рубли в месяц. Чертёжный стиль, подписи по-русски.
Какие модели реально доступны из России на сентябрь 2026 года. В облаке — GigaChat 3 и GigaChat 3.1 Ultra вместе с корпоративной платформой GigaChat Enterprise, YandexGPT 5 и Yandex AI Studio, T-Lite и T-Pro, Cotype Pro. Сравнение двух главных платформ по семи проектным параметрам у нас есть отдельно — GigaChat или YandexGPT. На своём сервере — Qwen 3, Llama, DeepSeek и Mistral через Ollama; этот вариант выбирают тогда, когда через узел проходят персональные данные и они не должны покидать периметр. Прямая оплата OpenAI и Anthropic из России невозможна: доступ идёт через рублёвые прокси и агрегаторы, и в проекте это подаётся как риск — смена условий у посредника обрывает контур в любой момент, — а не как рекомендация.
Когда ИИ-узел ставить не надо
Прежде чем про случаи — про обязательный фон. С 1 сентября 2026 года действует регулирование использования искусственного интеллекта: маркировка ИИ-контента, требования к моделям и к обработке персональных данных. Для сценария с ИИ-узлом это означает три конкретные вещи. Первая: если узел формирует текст, который уходит внешнему человеку, вопрос маркировки решается до запуска, а не после — какие материалы и какой формулировкой, мы разобрали в материале что помечать как ИИ-контент. Вторая: через узел не должны идти данные, для которых у вас нет основания на такую обработку, а облачная модель — это передача данных третьему лицу. Третья: компании рекомендуется завести внутреннюю политику использования ИИ — это самый дешёвый пункт подготовки и первый в чек-листе из 12 пунктов.
- Задача решается правилом. Если письма делятся по адресу отправителя, а заявки — по значению поля формы, обычное ветвление сделает это точнее, бесплатно и навсегда одинаково. Модель ставят там, где вход — свободный текст человека, а не структура.
- Поток меньше 500 обращений в месяц. Настройка узла, схемы, проверок и выборочного контроля занимает 16–24 часа независимо от объёма — это 48 000–72 000 ₽ по ставке 3 000 ₽/час. На 500 обращениях такая сумма тратится ради экономии, которую менеджер сделает за час в неделю руками.
- Ошибку никто не увидит до сверки. Узел на пути к проведённому документу, к отгрузке или к платежу не ставится, даже если результат проверяется схемой: схема ловит форму, а не смысл. Такие места закрываются формулой и подтверждением человека.
- Через узел пойдут паспортные данные, сведения о здоровье или платёжные реквизиты. В облачный узел такие поля не передают вовсе: вместо значения едет идентификатор записи, а само значение остаётся в вашем контуре. Если задача без них не решается — модель разворачивают на своём сервере, и это уже другой бюджет.
- Никто не готов раз в неделю читать выборку. Узел без контроля качества деградирует незаметно: он продолжает отвечать так же уверенно и так же быстро. Если в компании нет человека, который берёт на себя этот час в неделю, честнее не ставить узел вовсе.
Модель хорошо понимает текст и плохо считает числа. Всё проектирование ИИ-узла держится на этой одной фразе.
