Статьи

Ограничения ИИ в бизнесе: четыре барьера между чат-ботом и рабочим процессом

2026-08-21 13:42 Искуственный интеллект Методология
Доступ к языковой модели можно получить за несколько минут. Это ещё не автоматизация. Чтобы ИИ стал частью рабочего процесса, ему нужны данные, разрешённые действия, логи и понятный момент возврата задачи человеку. Без этого у компании появляется ещё одно окно с чатом: порой полезное, но не меняющее саму работу.
Обычно препятствия возникают по очереди. Сначала компания решает вопрос с инфраструктурой. Потом выясняется, что чат и агент — разные вещи. Следом начинаются инженерные задачи, а за ними самая трудная часть: перестройка процесса.

Барьер 1. Инфраструктура: где будет работать модель и какие данные ей можно доверить

Первый вопрос обычно звучит так: какую модель выбрать — облачную или локальную? За ним сразу появляются другие. Какие данные можно передавать во внешний сервис? Какие действия агент вправе выполнять в учётной системе? Кто отвечает за доступы, журналирование и стоимость запросов?
Ошибка — начинать с названия модели. Сначала нужно описать рабочий сценарий: какие данные он использует, откуда их получает, что делает с результатом и где требуется подтверждение человека. После этого проще выбрать вариант размещения: доступ по API или локальную модель в закрытом контуре.
Для подключения ИИ-приложений к данным и инструментам можно использовать MCP, Model Context Protocol. Через него агент получает доступ к нужным источникам и операциям без замены действующих систем. Но сама интеграция не решает вопросы безопасности. Права на чтение и запись, согласование чувствительных действий и контроль результатов всё равно проектируются отдельно.
Хорошая инфраструктура не обязательно самая дорогая. Она соответствует сценарию, уровню конфиденциальности и допустимому риску. Для одной задачи подойдёт доступ к модели по API. Для другой потребуется локальное размещение и жёсткое разделение прав.

Барьер 2. Непонимание возможностей: чат принимают за готового агента

Чат с моделью отвечает на запрос сотрудника. Это может быть полезно, но такой диалог ещё не меняет процесс. Сотрудник по-прежнему сам ищет данные, переносит результат в систему, проверяет его и запускает следующий шаг.
ИИ-агент устроен иначе. Он получает задачу, обращается к разрешённым источникам, выбирает инструмент, выполняет действие и фиксирует результат. Например, не просто объясняет, как собрать отчёт, а получает данные из учётной системы, формирует нужный разрез и передаёт результат ответственному сотруднику.
Поэтому демонстрация модели не заменяет проектирование сценария. До пилота нужно ответить на пять вопросов:
  1. Что запускает процесс?
  2. Какие данные нужны агенту?
  3. Какие решения и действия ему разрешены?
  4. В каких случаях задача возвращается человеку?
  5. По какой метрике мы поймём, что стало лучше?
Без этих ответов пилот легко превращается в набор эффектных, но разрозненных примеров.

Барьер 3. Инженерия агентов: одной инструкции недостаточно

Даже сильная модель не превращается в надёжного исполнителя после одного удачного промпта. Рабочий агент — это система. В неё входят инструкции и сценарии, модель, память, база знаний, интеграции, детерминированные инструменты, триггеры, логи и точки передачи задачи человеку. В сложных процессах добавляются связи с другими агентами. Безопасность проходит через все компоненты: от прав доступа до ограничений на действия.
Здесь проявляется одно из главных ограничений ИИ. Языковой модели можно поручить разбор запроса и выбор способа действия. Расчёты, проводки и другие операции с жёсткими правилами лучше отдавать обычному коду. Модель рассуждает, инструмент выполняет, система проверяет ограничения.
У агента должны быть логи и измеримые показатели: сколько задач он завершил, где ошибся, сколько решений исправили сотрудники, какие исключения повторяются. Иначе команда видит только отдельные ответы и не может понять, становится ли процесс устойчивее.

Барьер 4. Трансформация процессов: агент появился, а работа осталась прежней

Самый сложный барьер находится не в модели и не в интеграции. Компания подключает агента, но оставляет прежний порядок работы. Сотрудник получает ещё один интерфейс, копирует данные между системами и проверяет каждый шаг. Время на отдельную операцию сокращается, а общая трудоёмкость почти не меняется.
Чтобы получить экономический эффект, ИИ должен забирать целостные повторяемые операции, а не стоять рядом с человеком в роли советчика. Профессиональная ответственность, решения с высоким риском и нестандартные случаи остаются у специалиста.
Переход лучше строить постепенно. На старте действует модель «человек в контуре» — Human-in-the-Loop, HITL. В процесс ставят точки проверки: сотрудник подтверждает решение, исправляет ошибку или принимает исключение. Затем команда разбирает причины правок, уточняет инструкции и дорабатывает инструменты. Когда качество подтверждено на реальных данных, часть проверок можно заменить мониторингом. Человек остаётся над контуром — Human-on-the-Loop, HOTL — и вмешивается при отклонениях.
Сокращать проверки по календарю нельзя. Основанием должны быть факты: доля исправлений снижается, критические ошибки не повторяются, исключения распознаются, а ответственные видят состояние процесса. Роли людей, порядок надзора и постоянный мониторинг определяют заранее, а не после сбоя.

Как AI-аудит связывает четыре барьера

Четыре барьера нельзя снимать четырьмя независимыми проектами. Выбранная модель влияет на инфраструктуру, права доступа — на интеграции, а точки контроля — на сам порядок работы. Нужна единая схема процесса.
Такую схему можно собрать на AI-аудите. Его предмет — не языковая модель сама по себе, а работа компании после внедрения агентов. Для каждого процесса определяют сценарии, данные, память, базы знаний, интеграции, Human-Gate и операции, которые остаются у человека.
На выходе нужны три связанных результата:
  1. Целевая модель процессов с концепцией агента для каждого выбранного участка.
  2. Календарно-ресурсная оценка разработки и запуска.
  3. Технические требования к моделям, программному обеспечению и инфраструктуре.
С такой основой пилот можно оценивать не по эффектной демонстрации, а по тому, как меняются трудозатраты, качество и нагрузка на точки проверки.

С чего начать: не с модели, а с одного процесса

Для первого пилота лучше выбрать процесс, который:
  • регулярно повторяется и отнимает заметное время;
  • оставляет цифровой след в системах и документах;
  • имеет понятный результат и измеримую метрику;
  • допускает передачу исключений человеку без остановки всей работы.
Это может быть подготовка регулярного отчёта, проверка документов, сверка данных или обработка типового запроса. Важно ограничить контур, зафиксировать исходные трудозатраты и заранее определить, какие ошибки недопустимы.
После такого пилота у компании появляется не презентация о возможностях ИИ, а основание для решения: что масштабировать, что доработать и где технология пока не окупается.
Четыре барьера удобно использовать как карту проекта. Сначала определить инфраструктуру и правила доступа. Затем описать реальный сценарий. После этого спроектировать агента как систему и встроить его в процесс с управляемым участием человека. Только в такой последовательности ИИ начинает сокращать рутину, а не добавлять её.

Обсудить процесс для AI-аудита

Эксперты «Первого Бита» помогут выбрать процесс, оценить данные и интеграции, определить точки контроля и критерии результата. Следующий шаг — разобрать один сценарий на данных вашей компании и понять, что потребуется для аудита и пилота.
Обсудить задачу с экспертом