На демонстрации модель получает аккуратный документ и за несколько секунд извлекает из него нужные сведения. Через месяц система встречается с реальными файлами, старыми справочниками, недоступной 1С и исключениями, которых не было в техническом задании. Именно здесь начинается настоящее внедрение.

Успешный пилот искусственного интеллекта производит сильное впечатление. Берём несколько документов, звонков или обращений клиентов. Модель распознаёт содержание, извлекает данные, готовит резюме или предлагает ответ. На обработку уходит несколько секунд вместо десяти минут. После такой демонстрации легко решить, что основная часть проекта уже сделана: осталось подключить модель к корпоративным системам и запустить её на реальном потоке.

По моему опыту, всё почти наоборот.

Пилот отвечает на сравнительно узкий вопрос: может ли модель решить задачу на выбранных примерах? Внедрение отвечает на другой: может ли компания регулярно использовать результат модели в своём рабочем процессе? Между этими вопросами находятся данные, интеграции, ответственность, цена ошибки и эксплуатация. Именно о них часто вспоминают уже после успешного пилота.

Проблема №1. Автоматизировали операцию, но не разобрали процесс

Представим, что модель научилась извлекать из входящего счёта номер, дату, сумму и реквизиты контрагента. Задача решена? Только её небольшой фрагмент.

Карта процесса из пяти шагов: документы → AI-обработка (отмечена как «операция выполнена») → проверка → рабочая система → исключения; внизу подпись «Модель обработала документ. Процесс не завершён»
Извлечь данные из документа — одна операция из цепочки. Проверка, запись в рабочую систему и разбор исключений остаются за её пределами.

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

На демонстрации этого не видно. Модель получила файл и вернула красивую структуру. Но бизнес работает не отдельными ответами модели, а процессами.

До начала внедрения нужно определить:

  • что запускает процесс;
  • какие системы и сотрудники в нём участвуют;
  • какие данные считаются правильными;
  • что происходит после ответа модели;
  • какие исключения возможны;
  • где процесс заканчивается;
  • кто отвечает за итоговый результат.

Если у процесса нет владельца, эту роль незаметно начинает выполнять команда внедрения. Она принимает решения о маршрутах, правилах и допустимых ошибках, хотя это должны делать представители бизнеса. В итоге техническая команда отвечает за систему, а за результат процесса не отвечает никто.

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

Проблема №2. Данные пилота не похожи на рабочий поток

Для пилота почти всегда выбирают относительно понятные примеры. Документы читаются. Записи звонков слышны. Поля заполнены. Специалисты знают правильные ответы и могут быстро оценить результат.

В промышленной эксплуатации появляются другие данные:

  • сканы с печатями поверх текста;
  • фотографии документов, снятые под углом;
  • старые и новые формы одного документа;
  • пустые обязательные поля;
  • дубликаты;
  • сокращения и внутренний жаргон;
  • противоречащие друг другу справочники;
  • документы, к которым у пользователя нет доступа;
  • случаи, которых не было в тестовой выборке.

Модель может хорошо работать на аккуратных данных и заметно хуже — на реальном потоке. Это не обязательно говорит о плохом качестве модели. Возможно, пилот просто проверял другую задачу.

Это подтверждает и отраслевой опыт. IBM в разборе типичных сложностей интеграции данных отмечает, что без управления качеством на всём протяжении интеграции контур способен переносить и даже усиливать уже существующие ошибки, влияя на аналитику и последующие решения. Поэтому вместе с интеграцией нужны правила качества, проверки и понятная ответственность за данные.

Перед внедрением полезно разделить данные хотя бы на несколько групп:

  • типовые случаи;
  • редкие форматы;
  • плохое качество;
  • неполные документы;
  • противоречия;
  • заведомо неподходящие входные данные.

Систему нужно проверять не только на том, что она должна успешно обработать. Не менее важно проверить, умеет ли она распознать ситуацию, в которой продолжать обработку нельзя. Хороший результат — не обязательно заполненная карточка. Иногда правильный ответ выглядит так:

«Не удалось определить сумму: часть документа не читается. Требуется проверка сотрудником».

Проблема №3. Результат модели не встроен в рабочие системы

Допустим, модель правильно разобрала документ. Результат появился в отдельном чате или тестовом интерфейсе. Что происходит дальше?

Схема «Подключения корпоративного ИИ»: слева CRM и 1С соединены линиями с центральным блоком AI; справа TMS подключается через пометку «ручной перенос», а ECM показан с замком; внизу подпись «Модель подключена. Сквозной процесс — нет»
Пока результат переносится в 1С или CRM вручную, а часть систем закрыта правами доступа, сквозного процесса нет — есть полезный, но отдельный инструмент.

Если сотрудник копирует сведения из окна ИИ в 1С, CRM (система управления отношениями с клиентами), TMS (система управления перевозками) или систему документооборота, компания получила полезный инструмент. Но сам процесс пока не автоматизирован.

Для полноценной интеграции нужно решить множество прозаических вопросов:

  • как система получает новый документ;
  • как определяет его идентификатор;
  • куда записывает результат;
  • что делает при недоступности корпоративной системы;
  • как предотвращает повторную обработку;
  • как сообщает сотруднику об ошибке;
  • как учитывает права доступа;
  • где хранит исходный файл и результат;
  • можно ли отменить выполненное действие.

В реальной эксплуатации интеграция часто оказывается сложнее самого обращения к модели. Старая система может не иметь подходящего API (программного интерфейса для обмена данными между системами). Один справочник содержит полное название контрагента, другой — сокращённое. Статусы процесса различаются. Обновление данных происходит с задержкой. Формат поля меняется без предупреждения.

В свежем обзоре барьеров корпоративного ИИ IBM отдельно называет совместимость с существующими системами и встраивание технологии в повседневные рабочие процессы: корпоративная среда часто состоит из унаследованных систем и разрозненных процессов, не рассчитанных на новую технологию, и слабая интеграция ограничивает эффект.

Здесь обычно ломается не модель. Ломается связь между моделью и процессом. Полезен простой тест: если после ответа ИИ сотрудник открывает другую систему и вручную переносит туда результат, интеграция ещё не закончена.

Проблема №4. Никто не определил цену ошибки

Фраза «модель показывает точность 90%» мало говорит бизнесу. Ошибки бывают разными.

Если ИИ неверно определил тему внутреннего обращения, сотрудник потратит минуту и выберет другую категорию. Если система ошиблась в сумме платежа или основании для отказа клиенту, последствия будут совсем другими.

Поэтому одной общей метрики недостаточно. Нужно определить:

  • какие поля и решения являются критичными;
  • какие ошибки допустимы;
  • какие ошибки должны блокировать процесс;
  • сколько стоит ручная проверка;
  • какая доля случаев может передаваться человеку;
  • какой эффект останется с учётом этой проверки.

Представим, что модель правильно обрабатывает 95 документов из 100. Выглядит хорошо. Но если пять ошибок приходятся на сумму и реквизиты, автоматическое продолжение процесса опасно. Если же модель ошибается только в необязательном описании, результат может быть вполне пригоден для работы.

Поэтому качество нужно измерять не только в среднем, но и по конкретным полям, типам документов и сценариям. Кроме точности полезно контролировать:

  • долю автоматической обработки;
  • долю передачи сотруднику;
  • количество пропущенных ошибок;
  • время полного цикла;
  • число повторных операций;
  • стоимость ручной проверки;
  • случаи, когда система должна была остановиться, но продолжила работу.

Цена ошибки определяет архитектуру. Где-то достаточно постпроверки нескольких результатов. Где-то каждый ответ должен подтвердить специалист. А некоторые действия вообще не стоит передавать ИИ.

Проблема №5. Пилот некому эксплуатировать

Пилот живёт в спокойной среде. Команда знает, когда он запущен. Разработчики находятся рядом. Если что-то пошло не так, можно открыть журнал, повторить запрос и вручную исправить результат.

Схема «Контур эксплуатации» из пяти шагов: результат AI → правила → цена ошибки → решение человека → аудит; отдельной строкой «Ответственный за процесс: назначен»; внизу подпись «Ошибка модели не должна становиться действием компании»
Эксплуатация — это контур с назначенным владельцем: правила, оценка цены ошибки, решение человека и журнал действий вокруг ответа модели.

После внедрения система начинает работать каждый день. Меняются документы, справочники, инструкции, модели и поведение пользователей. Возникают новые вопросы:

  • кто следит за качеством ответов;
  • кто разбирает исключения;
  • кто обновляет источники;
  • кто согласует изменение правил;
  • кто реагирует на инцидент;
  • кто решает, что систему нужно временно остановить;
  • как вернуться к предыдущей версии;
  • кто отвечает на жалобу пользователя.

Эти обязанности нельзя оставить «команде ИИ». Они распределяются между владельцем процесса, ИТ, безопасностью, специалистами по данным и сотрудниками, которые работают с результатом.

Это согласуется с рамкой управления рисками ИИ. NIST в своём AI Risk Management Framework рекомендует заранее определять роли человека и ИИ, тестировать систему в условиях, близких к эксплуатации, а после запуска непрерывно наблюдать за её поведением; отдельно предусмотрены обработка инцидентов, обжалование и отмена решения, восстановление после сбоя и безопасный вывод системы из эксплуатации (Manage 4.1, Govern 1.7).

Мониторинг здесь нужен не только для технических ошибок. Система может продолжать отвечать быстро и без сбоев, но её качество постепенно снизится. Например, компания обновила шаблон договора, появился новый продукт или сотрудники начали задавать вопросы, которых не было в первоначальной выборке. Технически всё работает. По существу — уже нет.

Поэтому в промышленной эксплуатации нужно отслеживать качество на реальном потоке и регулярно проверять результаты. Такой мониторинг позволяет заметить ухудшение до того, как оно превратится в накопленную проблему — как это устроено на практике, показывает, например, руководство Microsoft по мониторингу генеративного ИИ в продакшене.

Что проверить до начала интеграции

Я бы не переходил от демонстрации сразу к большому проекту. Сначала полезно ответить на несколько вопросов:

  • Понятен ли процесс целиком, а не только операция, которую выполняет модель?
  • Есть ли у процесса владелец, способный принять решение о правилах и исключениях?
  • Насколько тестовые данные похожи на реальный поток?
  • Что произойдёт, если корпоративная система недоступна?
  • Какая ошибка является допустимой, а какая должна остановить процесс?
  • Кому передаётся случай, который ИИ не смог обработать?
  • Кто будет наблюдать за качеством после запуска?

Если на часть вопросов нет ответа, это не означает, что от проекта нужно отказаться. Это означает, что его границы пока не определены.

Как мы подходим к таким проектам в Daturum

В Daturum мы начинаем с конкретного процесса и небольшой выборки реальных данных. Сначала проверяем, способна ли модель выполнить нужную операцию. Затем смотрим шире: откуда приходят данные, как результат попадёт в рабочую систему, какие проверки нужны, где остаётся человек и как будет измеряться эффект. Как этот контур собирается по фазам — от концепции до промышленной эксплуатации — описано в методологии AI Factory.

На первом этапе не обязательно строить полноценную промышленную архитектуру. Важно быстро найти ограничения, которые повлияют на решение. Подход Hyperfast Presale позволяет собрать рабочий прототип на обезличенных данных за 2–24 часа и проверить не только удачные примеры, но и неприятные случаи: плохое качество, неполные сведения, противоречия и отказ внешней системы.

После такой проверки можно обсуждать внедрение предметно. Уже понятно, что умеет модель, какие интеграции понадобятся, сколько случаев потребуют участия сотрудника и есть ли у проекта измеримый смысл. Как это выглядит на реальных системах, видно в реализованных проектах; измеримые обязательства по качеству мы фиксируем в гарантиях с KPI и SLA.

Успешный пилот — это ещё не маленькая промышленная система

Пилот доказывает, что технология способна решить отдельную задачу в контролируемых условиях. Внедрение начинается позже: когда результат модели становится частью процесса, данные проходят проверку, исключения получают маршрут, действия записываются в журнал, а за итог отвечает конкретный человек.

Поэтому после красивой демонстрации я бы задавал не вопрос «когда запускаем?», а пять других:

  • какой процесс мы меняем;
  • на каких данных будет работать система;
  • куда попадёт результат;
  • сколько стоит ошибка;
  • кто отвечает за эксплуатацию.

Если на них есть ясные ответы, пилот действительно может стать рабочей системой. Если ответов нет, интегрировать пока нечего — есть только удачная демонстрация модели.

Частые вопросы

Чем внедрение ИИ отличается от пилота?

Пилот проверяет, может ли модель решить задачу на выбранных примерах. Внедрение проверяет, может ли компания регулярно использовать результат модели в рабочем процессе. Между ними — качество данных боевого потока, интеграция с корпоративными системами, цена ошибки по каждому полю, маршруты исключений и ответственность за эксплуатацию.

Почему модель хорошо работает на пилоте и хуже в эксплуатации?

Чаще всего дело не в качестве модели, а в данных. Для пилота выбирают понятные примеры, а в бою появляются сканы с печатями, снятые под углом фотографии, устаревшие и противоречивые справочники, пустые обязательные поля и случаи, которых не было в тестовой выборке. Систему нужно проверять и на способности распознать случай, в котором продолжать обработку нельзя.

Как измерять качество ИИ-системы, кроме точности?

Одной средней точности недостаточно, потому что ошибки стоят по-разному. Стоит измерять качество по конкретным полям и типам документов и контролировать долю автоматической обработки, долю передачи человеку, количество пропущенных ошибок, время полного цикла, стоимость ручной проверки и случаи, когда система должна была остановиться, но продолжила работу.

Когда интеграцию можно считать завершённой?

Простой признак незавершённости: если после ответа ИИ сотрудник открывает другую систему и вручную переносит туда результат, интеграция ещё не закончена. Полная интеграция решает, как система получает документ, куда записывает результат, что делает при недоступности корпоративной системы, как предотвращает повторную обработку и учитывает права доступа.

Кто должен отвечать за ИИ-систему после запуска?

Не «команда ИИ». Обязанности распределяются между владельцем процесса, ИТ, безопасностью, специалистами по данным и сотрудниками, которые работают с результатом: кто-то следит за качеством ответов, разбирает исключения, обновляет источники, согласует изменение правил, реагирует на инцидент и может безопасно остановить систему.

Источники

  • IBM. Data integration challenges — без управления качеством интеграционный контур переносит и усиливает существующие ошибки данных, влияя на последующие решения. Опубликовано 19.12.2025. https://www.ibm.com/think/insights/data-integration-challenges
  • IBM. The biggest AI adoption challenges for 2026 — совместимость с существующими системами и встраивание ИИ в повседневные рабочие процессы как отдельные барьеры внедрения. Обновление документа: 29.05.2026. https://www.ibm.com/think/insights/ai-adoption-challenges
  • NIST. AI Risk Management Framework (ядро: функции Govern, Map, Measure, Manage) — определение ролей человека и ИИ, тестирование в условиях, близких к эксплуатации, мониторинг в продакшене, обработка инцидентов, обжалование и отмена решения, восстановление после сбоя и безопасный вывод системы из эксплуатации (Manage 4.1, Govern 1.7). https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
  • Microsoft Learn (Azure Databricks). Monitor GenAI apps in production — пример организации мониторинга качества генеративного ИИ в эксплуатации. https://learn.microsoft.com/en-us/azure/databricks/mlflow3/genai/eval-monitor/production-monitoring

Опубликовано 25 июля 2026 года. Источники проверены 28 июля 2026 года.

Об авторе

Роман Ткачёв — сооснователь Daturum. Более 25 лет в корпоративной автоматизации. Участвовал более чем в 80 крупных проектах в банках, страховых компаниях, телекомах, на транспорте, в госсекторе, промышленности и ритейле; реализовал более 50 коммерческих BPM-внедрений.

До Daturum — директор BPM-департамента и Центра инноваций «Т1 Консалтинг».

Полная биография