7 шагов внедрения ИИ для автоматизации бизнес‑процессов
По данным исследования McKinsey & Company в 105 странах, в 2025 году 88% компаний регулярно используют ИИ хотя бы в одной бизнес‑функции. Но только около трети дошли до масштабирования по всей организации, остальные остаются на уровне пилотных проектов.
В этой инструкции — маршрут, который мы обычно используем, чтобы подобрать решение под конкретный процесс. Он помогает не раздувать архитектуру без необходимости, заранее прикинуть экономику и запустить пилот так, чтобы он мог перейти в промышленную эксплуатацию.
Важно: один и тот же процесс в разных компаниях упирается в разное качество данных, ограничения по безопасности, доступную инфраструктуру и реальную нагрузку. Поэтому наш маршрут не претендует на универсальность, но может быть полезен как каркас.
Шаг 1. Зафиксировать целевой результат
Работа обычно начинается с формулировки результата: что система получает на входе и что выдает на выходе. Например, на входе мы подаем список отзывов по товару. На выходе хотим короткий текст для карточки товара: саммари с ключевыми мыслями и тегами.
В постановке мы фиксируем источник и формат входных данных: обращения клиентов, документы, события из CRM или ERP, таблицы, карточки контрагентов и другие источники. Дальше описываем ожидаемый результат. Это может быть классификация, оценка риска, прогноз, саммари, черновик ответа, обновление полей в системе, создание задачи или что‑то еще.
Сразу же в постановке появляется способ проверки качества. Для части задач подходят метрики точности и полноты. Для других важнее доля корректных действий без участия человека, время ответа и перечень ошибок, которые недопустимы.
Бесплатная рассылка: как использовать ИИ в бизнесе
Узнайте, как писать эффективные промпты, создавать ИИ‑агентов для решения бизнес‑задач, и проходите мини‑практикумы в популярных сервисах. Всего — семь писем, которые помогут разобраться, как работать с нейросетями
Во многих компаниях под «ИИ» по умолчанию понимают большие языковые модели и чат‑ботов, хотя значительная часть задач решается классическим ИИ.
Еще один важный момент — степень участия человека. Процессы с ИИ бывают полностью автоматическими и с человеком в контуре. В первом случае система принимает решение и применяет его без ручного подтверждения. Человек подключается по исключениям и через контроль качества. Во втором случае ИИ готовит рекомендацию или черновик, а финальное решение остается за сотрудником.
Классический ИИ. Это прикладные модели, которые решают узкие задачи. Например, рекомендательные системы, поиск аномалий, компьютерное зрение и распознавание. Обычно им не нужны дорогие видеокарты, и они могут выполняться на обычных серверах. Поскольку результат у них формализованный и измеримый, такие модели проще встроить в полностью автоматические сценарии.
Основную долю прибыли компаниям часто приносит именно классический ИИ: рекомендательные системы, компьютерное зрение для оцифровки документов, регрессия по температурным датчикам, например, или по стоимости товара. Это небольшие задачи — для них не нужны дорогие видеокарты и провайдеры больших языковых моделей — все умещается на одном домашнем процессоре
Генеративный ИИ. Генеративный ИИ решает другой класс задач. Он показывает хороший эффект там, где данные плохо формализуются, много текста, контекста и исключений, а раньше в процессе почти всегда участвовал человек. Большие языковые модели умеют интерпретировать входящую информацию, учитывать контекст, формировать объяснения и варианты решений.
На практике для генеративных моделей часто выбирают сценарии с человеком в контуре. Система готовит ответ или рекомендацию, а сотрудник остается на верхнем уровне контроля и подключается, чтобы проверить, утвердить или разобрать исключения.
Если к модели добавить интеграции с рабочими системами и правила выполнения действий, появляется агентный слой. Система не только пишет текст, но и проходит последовательность шагов. Например, запрашивает данные, сверяется с регламентом, обновляет поля во внутренних системах компании, отправляет письмо или фиксирует результат.
Шаг 3. Описать данные и интеграции
На этом этапе мы фиксируем, какими данными компания располагает и какие из них важны для процесса, который мы будем автоматизировать. Это могут быть карточки клиента, истории решений, регламенты, статусы в CRM, видео, потоковые данные или изображения.
Для каждого источника указываем:
- формат;
- актуальность;
- кто отвечает за содержание и правила использования;
- ограничения по доступу.
На практике выходит небольшая таблица. Она обновляется по мере развития проекта. Отдельно или прямо в ней указываем, как именно система читает входные данные: через API, SQL‑запросы, события, выгрузки или как‑то иначе. Такой же список нужен для выхода: куда записывается результат и в каком виде.
Если для автоматизации процесса нужен доступ ко внутренним знаниям компании, что бывает часто, появляется внутренний контекст. Иногда хватает минимального фрагмента: выдержки из регламента, карточки контрагента, части договора.
Оперативные и численные данные обычно проще давать через интеграции, например API или SQL. Текстовые знания из документов и инструкций бывает удобнее подключать через RAG (Retrieval‑Augmented Generation, поиск по базе знаний с генерацией ответов). RAG находит релевантные фрагменты в базе знаний и добавляет их в контекст ответа, чтобы модель опиралась на конкретные источники.
RAG — это архитектурный подход, при котором языковая модель формирует ответы и действия с опорой на фрагменты внутренних данных. Фактически RAG выступает связующим слоем между корпоративными хранилищами и моделью.
В RAG‑сценариях документы и файлы сначала разбивают на смысловые фрагменты и индексируют с помощью эмбеддингов. При запросе система выполняет семантический поиск по индексу, отбирает самые подходящие фрагменты и передает их модели в качестве контекста. Модель использует этот контекст, когда генерирует ответ или принимает решение.
Шаг 4. Спроектировать решение
Прототип решения дает ориентир, как выглядит результат и что именно делает система. Ничего страшного, если он медленный и тяжелый. На этом этапе важнее, чтобы устраивала логика и формат.
Когда мы делаем прототип впервые, можем не думать о параллелизации процессов для обработки больших объемов данных или для большей производительности. Прототип может обрабатывать одну карточку товара за раз, а не 150. Главное — результат
Параллельно с прототипом идет практическая оценка вариантов: что дает нужное качество, сколько решение стоит в эксплуатации и в каком контуре его можно развернуть.
В генеративных сценариях и агентных системах разработчики исследуют рынок провайдеров больших языковых моделей и формулируют требования к среде развертывания. Это влияет на экономику ИИ‑автоматизации для бизнеса.
В классическом ИИ оценка стоимости и размещения считается с другими переменными. Здесь мы сравниваем, где будет выполняться инференс (на устройстве, на CPU‑серверах или на GPU), сколько стоит обработка единицы сигнала (кадра, документа, события), какие требования по задержке. Если используются готовые компоненты, например, OCR или CV‑модуль, практическое исследование сводится к тесту нескольких SDK или моделей на своих данных.
Еще на этапе проектирования полезно решить, как отвечать на вопрос «Почему система так решила». Ведь ответственность частично или полностью перекладывается с человека на алгоритм. Поэтому для каждого решения важно сохранять след. Он поможет понять, на чем оно основано.
Есть и более сложные техники, чем в этих двух примерах. На практике до них редко доходят.
Шаг 5. Создать петлю обратной связи
Особенно если мы говорим про генеративные модели, внедрение автоматизации часто идет в несколько этапов. Эти дополнительные этапы появляются потому, что реальные люди, пользователи, которые хорошо понимают свой бизнес, тестируют систему на настоящих данных и говорят: «У меня есть 10, 20, 30 случаев, когда система отработала неправильно, и я, как эксперт, сел и написал, как должно быть».
Такая выборка — небольшая, но очень ценная именно для вашей системы. Ее можно быстро использовать, чтобы обновить правила, приоритеты или само понимание процесса, который выполняет модель. Для этого есть инструменты, где человек остается в контуре.
Если дать доступ к такому инструменту (например, в Arize Phoenix или Langfuse) уже на этапе проектирования, вы избежите ситуации, когда систему внедрили, а любые улучшения потом идут как отдельная доработка.
Шаг 6. Разработать боеспособную версию
На этом этапе мы доводим прототип до состояния, когда им можно пользоваться в реальном процессе. Прототип уже показал, каким способом получить результат. Теперь работа сводится к тому, чтобы сделать этот результат стабильным и воспроизводимым, а еще встроить его в конкретные системы.
Боеспособная версия отличается от прототипа главным образом тремя вещами:
- Есть настоящий вход, данные подтягиваются из согласованных источников.
- Появляется контроль выхода: фиксируется структура результата, добавляются базовые проверки. Например, длина, обязательные поля, запреты на персональные данные.
- Результат фиксируется в системе, например, в тикете, документе, карточке товара, витрине данных. В том виде, которым действительно будут пользоваться.
Еще в продакшн‑версии часто появляются дополнительные модели безопасности — guardrails, особенно если мы работаем с генеративным ИИ. Guardrails нужны, чтобы ограничивать вход и выход персональных данных, запрещенного и токсичного контента. На этапе прототипирования это не обязательно, потому что мы сами контролируем данные.
Шаг 7. Настроить мониторинг
Для любого продакшн‑решения при внедрении важно настроить мониторинг.
Обычно он включает:
- классический DevOps: исправен ли сервер, на котором работает модель, какое время отклика и какая нагрузка;
- специализированный мониторинг ИИ: например, для генеративных моделей отслеживают пропускную способность и сколько токенов в секунду они генерируют.
На этом же этапе обычно настраивают механизм доставки новых версий модели. Он нужен, чтобы обновлять алгоритм, когда по метрикам видно, что качество работы системы просело или уже не соответствует требованиям.
Чек‑лист: что получится, если пройти маршрут целиком:
- Есть формулировка результата, формат входных данных, ожидаемый выход и критерии качества.
- Зафиксировали, что именно делаем: классический ML, генеративный ИИ, агентный сценарий или гибрид. Понятно, где решение работает автоматически, а где нужен человек в контуре.
- Есть список ключевых источников данных. Мы знаем владельцев и ограничения по доступу. Понятно, как система читает входные данные и куда записывает результат.
- Есть прототип и выбранный вариант реализации: какие компоненты входят, какие модели используем, где они исполняются, какие проверки и ограничения нужны.
- Понятно, как разбирать спорные кейсы: ИИ оставляет след, по которому можно объяснить решения системы.
- Даже если система делает все шаги за раз, человек может подключиться и скорректировать отдельный шаг.
- Есть рабочая версия в продакшене: система работает на реальных данных, у нее стабильный вход, контроль выхода и запись результата в рабочую систему.
- Есть DevOps‑мониторинг (доступность, нагрузка, задержка) и мониторинг качества ИИ (метрики, дрейф, токены и скорость для LLM). Есть механизм выката новых версий и отката.
