Сотрудник копирует письмо клиента в нейросеть, получает хороший ответ и переносит его в CRM (система управления отношениями с клиентами). Работа ускорилась, но процесс остался прежним. Настоящее внедрение начинается, когда ИИ сам получает нужный контекст, соблюдает правила, возвращает результат в рабочую систему и передаёт исключения человеку.
По моим наблюдениям, использование нейросетей в повседневной работе стало обычным делом: сотрудники готовят письма, пересказывают документы, ищут идеи, составляют протоколы встреч и анализируют тексты. Это полезный и сравнительно простой способ познакомиться с технологией. Но между использованием чата и внедрением ИИ в бизнес-процесс есть существенная разница.
В первом случае сотрудник сам собирает данные, формулирует запрос, проверяет ответ и переносит результат в рабочую систему. Нейросеть помогает ему выполнить отдельную операцию. Во втором случае ИИ становится управляемым компонентом процесса: он получает задачу по событию, использует корпоративные данные, возвращает структурированный результат, проходит проверки и действует в пределах заданных полномочий.
Коротко эту разницу можно сформулировать так:
Чат отвечает сотруднику. Встроенный ИИ передаёт контролируемый результат следующему этапу процесса.
Чат полезен, но решает другую задачу
Не стоит относиться к отдельному чату как к чему-то несерьёзному. Он хорошо подходит для личных задач, экспериментов и ситуаций, в которых человек полностью контролирует результат: сотрудник сам выбирает, какие данные передать модели, оценивает ответ и решает, что с ним делать.
Проблемы появляются, когда такой способ работы пытаются масштабировать на целое подразделение. Каждый сотрудник формулирует запрос по-своему: один прикладывает договор, другой ограничивается фрагментом письма. Кто-то тщательно проверяет результат, кто-то доверяет уверенной формулировке модели. Получившийся ответ остаётся в истории диалога и не всегда связан с карточкой клиента, документом или операцией.
В результате компания не может надёжно ответить на несколько простых вопросов:
- какие данные использовала модель;
- какую инструкцию она получила;
- проверил ли сотрудник результат;
- какая версия ответа попала в рабочую систему;
- что произошло после ответа;
- можно ли восстановить ход операции.
Для личного помощника это может быть приемлемо. Для регулярного корпоративного процесса — уже нет.
Проверка на Ctrl+C и Ctrl+V
Есть простой способ понять, встроен ли ИИ в процесс. Посмотрите, сколько раз сотрудник нажимает Ctrl+C и Ctrl+V.
Например, оператор получает письмо клиента. Он копирует текст в нейросеть, просит определить тему обращения и подготовить ответ. Затем открывает CRM, находит карточку клиента, проверяет заказ, исправляет ответ модели и переносит его обратно в систему.
ИИ помог написать текст быстрее. Но сотрудник по-прежнему:
- переключается между несколькими окнами;
- вручную собирает контекст;
- переносит данные;
- проверяет правила;
- выбирает дальнейшее действие;
- фиксирует результат.
Здесь автоматизирована генерация текста, а не бизнес-процесс. Более того, появляется новая операция: правильно объяснить задачу модели и проверить её ответ. Если этого не учесть, компания может переоценить экономический эффект.
Я бы не называл такую схему бесполезной. Это хороший промежуточный этап и источник данных для будущего проекта. Но важно честно понимать его границы.
Как выглядит встроенный ИИ
Разберём тот же пример с обращением клиента. Клиент пишет:
«В четверг принять груз не сможем. Можно перенести доставку на пятницу после обеда?»
В варианте с отдельным чатом всю работу вокруг модели выполняет оператор. Во встроенном процессе последовательность выглядит иначе.
1. Система получает событие
Новое письмо автоматически создаёт или обновляет обращение в CRM. У процесса появляется идентификатор. Система знает, от какого клиента пришёл запрос, к какому заказу он относится и кто отвечает за обработку. Сотруднику не нужно вручную переносить письмо в другой интерфейс.
2. Автоматически собирается контекст
До обращения к модели система получает необходимые сведения:
- карточку клиента;
- номер и статус заказа;
- текущую дату доставки;
- условия договора;
- доступные интервалы;
- историю предыдущих обращений;
- правила изменения заказа.
Модель работает не с вырванным из переписки предложением, а с контекстом конкретной операции.
При этом права доступа должны действовать и для ИИ. Если сотрудник не имеет права видеть определённые сведения, модель тоже не должна их получать.
3. ИИ выполняет ограниченную задачу
Модели не поручают «разобраться с клиентом». Задачу формулируют точнее:
- определить намерение клиента;
- извлечь желаемую дату и время;
- найти номер заказа в контексте;
- подготовить проект ответа;
- отметить недостающие сведения.
Результат возвращается в установленном формате, а не в виде свободного рассуждения. Например:
Тип обращения: перенос доставки
Желаемая дата: пятница
Желаемое время: после 14:00
Заказ: найден
Необходима проверка расписания: да
Проект ответа: подготовлен
Такой результат можно передать следующему этапу процесса.
4. Обычная программа проверяет правила
ИИ понял содержание письма, но не должен самостоятельно решать, можно ли изменить доставку. Система проверяет:
- существует ли заказ;
- допускает ли его статус изменение;
- свободен ли нужный интервал;
- не нарушены ли договорные сроки;
- требуется ли дополнительное согласование;
- нет ли ограничений по маршруту.
Это детерминированные правила — те, что при одних и тех же входных данных всегда дают один и тот же результат. Для них не нужна языковая модель.
Если перенос разрешён, система готовит изменение. Если возникло исключение, обращение передаётся сотруднику с уже собранным контекстом.
5. Человек подтверждает значимое действие
ИИ может предложить ответ и подготовить изменение заказа. Но окончательное подтверждение зависит от цены ошибки. Для типового переноса в пределах доступного расписания может быть достаточно быстрой проверки оператором. Если изменение влияет на стоимость, обязательства перед клиентом или работу нескольких подразделений, решение передаётся ответственному сотруднику.
Тот же принцип заложен в отраслевые рамки управления рисками. В ядре AI Risk Management Framework NIST прямо предусмотрено, что организация заранее определяет роли и ответственность в связках «человек — ИИ» и порядок надзора за системой (Govern 3.2), документирует пределы знаний системы и то, как её результат может использоваться и контролироваться человеком (Map 2.2), а сами процессы человеческого надзора описывает, оценивает и фиксирует документально (Map 3.5).
Надпись «проверено человеком» сама по себе ничего не решает. Сотруднику нужно показать исходное обращение, найденные данные, предлагаемые изменения и причину, по которой система просит подтверждение.
6. Результат возвращается в рабочую систему
После подтверждения CRM или TMS (система управления перевозками) обновляет заказ, сохраняет ответ клиенту и создаёт необходимые задачи. Сотрудник не переносит сведения вручную.
Если целевая система недоступна, процесс не должен терять результат или молча завершаться. Операция получает статус ошибки, повторяется по установленному правилу либо передаётся ответственному специалисту.
7. Действия записываются в журнал
Для каждой операции сохраняются:
- исходное обращение;
- использованный контекст;
- версия модели;
- результат ИИ;
- результаты проверок;
- исправления сотрудника;
- выполненное действие;
- время и участники операции.
Так компания может разбирать ошибки, оценивать качество и понимать, где система действительно экономит время.
От автоматизации задачи к оркестрации процесса
Отдельная модель выполняет одну операцию: классифицирует письмо, извлекает сведения или создаёт текст. Полный процесс состоит из множества связанных действий. Нужно получить событие, собрать данные, вызвать модель, проверить результат, обновить систему, отправить уведомление и обработать исключение.
Координацию этих действий обычно называют оркестрацией рабочего процесса — согласованным выполнением нескольких автоматизированных задач по всей цепочке приложений и сервисов. IBM в разборе оркестрации рабочих процессов прямо разделяет два уровня: автоматизация отдельного рабочего процесса нацелена на отдельные задачи, тогда как оркестрация создаёт связанную структуру, в которой автоматизированные задачи взаимодействуют между собой, следуют логической последовательности и интегрируются с другими системами ради сквозного бизнес-процесса.
Именно оркестрация превращает удачный ответ модели в повторяемую операцию бизнеса.
В такой архитектуре ИИ не управляет всем процессом без ограничений. Он выполняет те шаги, где требуется работа с текстом, речью, документами или неоднозначным контекстом. Остальные компоненты отвечают за:
- запуск процесса;
- права доступа;
- бизнес-правила;
- интеграции;
- сохранение состояния;
- повторные попытки;
- уведомления;
- подтверждение человеком;
- аудит.
Получается сочетание вероятностного ИИ и предсказуемого рабочего процесса.
Что должно оставаться вне модели
У языковой модели есть сильная сторона: она умеет интерпретировать разнообразные человеческие формулировки. Но не все задачи требуют интерпретации.
Я бы не передавал модели то, что можно надёжно выполнить обычной программой:
- точные расчёты;
- проверку обязательных полей;
- применение лимитов;
- выбор значения из корпоративного справочника;
- проверку прав доступа;
- изменение статуса по формальному условию;
- регистрацию операции;
- контроль повторной обработки.
Например, модель может извлечь сумму из нестандартного документа. Но проверить арифметику, валюту, лимит и совпадение с заявкой должна обычная программа.
Этот принцип делает систему не только надёжнее, но и дешевле. Нет смысла каждый раз обращаться к большой модели, чтобы проверить условие, которое помещается в одну строку кода.
Встроенный интерфейс тоже имеет значение
Интеграция не обязательно означает полностью автономную работу. Часто лучший вариант — встроить ИИ-ассистента непосредственно в привычную систему сотрудника.
В карточке обращения могут появиться:
- краткое содержание переписки;
- предполагаемая тема;
- найденные документы;
- проект ответа;
- обнаруженные расхождения;
- рекомендуемое следующее действие.
Сотрудник видит результат рядом с исходными данными, может исправить его и продолжить работу, не переключаясь между окнами. Это по-прежнему human-in-the-loop — схема, при которой значимое решение остаётся за человеком, — но уже без ручного сбора контекста и переноса результата.
Хороший интерфейс не скрывает неопределённость модели. Он показывает, на каких данных построен ответ, где есть сомнение и что именно изменится после подтверждения.
Без наблюдения процесс снова превращается в эксперимент
После запуска нужно контролировать не только доступность модели. Важно видеть весь путь операции:
- какое событие запустило процесс;
- какие данные удалось получить;
- какие источники использовались;
- сколько времени занял каждый этап;
- где возникла ошибка;
- какое действие предложил ИИ;
- что изменил сотрудник;
- чем завершился процесс.
Современные инструменты наблюдаемости рассчитаны именно на это. В документации AWS по наблюдаемости генеративного ИИ в Amazon CloudWatch отслеживаемыми объектами названы не только вызовы модели, но и агенты, базы знаний, ограничители (guardrails) и инструменты, а сквозная трассировка запроса нужна, чтобы быстро определить, в каком именно компоненте возникла проблема.
Это важно, потому что пользователь видит только итоговый ответ. Причина ошибки может находиться совсем в другом месте: поиск вернул старый документ, CRM не отдала статус заказа или правило маршрутизации выбрало неправильную ветку.
Без сквозного журнала команда будет пытаться исправить модель там, где сломалась интеграция.
Как понять, что ИИ действительно встроен в процесс
Есть несколько практических признаков.
- Сотрудник не переносит запрос и результат между системами вручную.
- Контекст собирается автоматически с учётом прав доступа.
- ИИ выполняет ограниченную и явно описанную задачу.
- Результат возвращается в структурированном формате.
- Точные правила проверяются программно.
- Исключения получают понятный маршрут.
- Критичные действия подтверждает уполномоченный сотрудник.
- Вся операция восстанавливается по журналу.
- Эффект измеряется по полному процессу, а не по скорости одного ответа модели.
Если эти условия выполнены, можно говорить о внедрении. Если нет, перед нами, скорее всего, хороший личный инструмент или полезный пилот.
Как мы подходим к этому в Daturum
В Daturum мы не начинаем с идеи «давайте добавим чат». Сначала выбираем конкретный процесс и смотрим, где сотрудник тратит время на чтение, поиск, сверку или подготовку ответа. Затем определяем, какие данные нужны модели, откуда их получать и куда должен вернуться результат. Как этот путь разложен по фазам — от концепции до промышленной эксплуатации — описано в методологии AI Factory.
На небольшом прототипе проверяем всю цепочку:
событие → данные → ИИ → проверки → человек → рабочая система.
Чтобы проверить возможность такого внедрения, не обязательно сразу перестраивать весь процесс. Можно выбрать один участок, взять 20–50 реальных примеров и собрать прототип, который получает данные, выполняет ограниченную задачу и возвращает результат в рабочий контур. Именно так устроен Hyperfast Presale — прототип на данных заказчика собирается за 2–24 часа, и после него видно, есть ли эффект и что потребуется для полноценной интеграции.
Такой подход быстро показывает, где технология даёт эффект, а где появляются ограничения по данным, интеграциям или цене ошибки. Иногда результатом становится встроенный ассистент для сотрудника. Иногда ИИ автоматически обрабатывает типовые случаи и передаёт исключения человеку. А иногда выясняется, что достаточно обычной интеграции без языковой модели. Как такие контуры выглядят на реальных системах, видно в реализованных проектах, а измеримые обязательства по качеству мы фиксируем в гарантиях с KPI и SLA.
Главное, чтобы менялся процесс, а не только появлялось новое окно.
Хороший ответ ещё не результат бизнеса
Чат сокращает время отдельной операции. Встроенная система меняет способ выполнения работы.
Разница становится особенно заметной при масштабировании. Пока нейросетью пользуются несколько опытных сотрудников, ручной контекст и проверка могут работать. Когда через систему проходят тысячи обращений, документов или звонков, нужны правила, интеграции, маршруты исключений и аудит.
Поэтому корпоративный ИИ начинается не там, где сотрудник получил убедительный ответ. Он начинается там, где бизнес-процесс получил контролируемый результат.
Частые вопросы
Чем встроенный ИИ отличается от корпоративного чата с нейросетью?
В чате сотрудник сам собирает контекст, формулирует запрос, проверяет ответ и переносит результат в рабочую систему — автоматизирована генерация текста. Встроенный ИИ получает задачу по событию, забирает корпоративные данные с учётом прав доступа, возвращает результат в заданном формате, проходит программные проверки и передаёт исключения человеку, после чего результат сам попадает в рабочую систему и фиксируется в журнале.
Как быстро проверить, встроен ли ИИ в процесс?
Посчитайте ручные копирования. Если между ответом модели и рабочей системой стоит буфер обмена, интеграции ещё нет. Дополнительные признаки встроенности: контекст собирается автоматически с учётом прав доступа, задача модели описана узко, результат структурирован, точные правила проверяются программно, исключения имеют маршрут, а вся операция восстанавливается по журналу.
Что нельзя поручать языковой модели в бизнес-процессе?
Всё, что надёжно выполняет обычная программа: точные расчёты, проверку обязательных полей, применение лимитов, выбор значения из корпоративного справочника, проверку прав доступа, изменение статуса по формальному условию, регистрацию операции и контроль повторной обработки. Модель может извлечь сумму из нестандартного документа, но проверять арифметику, валюту и лимит должен детерминированный код — это надёжнее и дешевле.
Обязательно ли подтверждение человеком на каждом шаге?
Нет, объём подтверждения определяется ценой ошибки. Для типового действия в пределах установленных правил может хватить быстрой проверки оператором, а изменение, влияющее на стоимость, обязательства перед клиентом или работу нескольких подразделений, передаётся ответственному сотруднику. Формальная отметка «проверено человеком» не заменяет интерфейса, в котором видны исходные данные, предлагаемое изменение и причина запроса на подтверждение.
Что нужно отслеживать после запуска ИИ в процессе?
Не только доступность модели, а весь путь операции: событие-триггер, полученные данные, использованные источники, длительность этапов, место ошибки, предложенное ИИ действие, правку сотрудника и итог. Иначе команда будет чинить модель там, где сломалась интеграция: поиск вернул старый документ, CRM не отдала статус заказа, правило маршрутизации выбрало неверную ветку.
Источники
- NIST. AI Risk Management Framework, ядро (функции Govern, Map, Measure, Manage) — определение ролей и надзора в связках «человек — ИИ» (Govern 3.2), документирование пределов знаний системы и порядка использования её результата человеком (Map 2.2), описанные и оценённые процессы человеческого надзора (Map 3.5). https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
- IBM. What is workflow orchestration? — разграничение автоматизации отдельных задач и оркестрации как связанной структуры, интегрированной с корпоративными системами. Опубликовано 27.02.2025, обновлено 01.04.2026. https://www.ibm.com/think/topics/workflow-orchestration
- AWS. Generative AI observability — Amazon CloudWatch — состав отслеживаемых объектов (вызовы модели, агенты, базы знаний, ограничители, инструменты) и сквозная трассировка запроса для локализации ошибки. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/GenAI-observability.html
Опубликовано 28 июля 2026 года. Источники проверены 29 июля 2026 года.