Большинство провальных проектов по внедрению ИИ выглядят одинаково. Компания подписывает договор с подрядчиком, через два месяца получает «работающего агента», запускает в продакшн, агент ведёт себя непредсказуемо, проект замораживают. Потери: от 200 000 до 1 500 000 ₽ и три месяца времени команды.
Причина почти всегда не в технологии. Технология к тому моменту, когда появился агент, давно решаема. Причина в пропущенных этапах: без бизнес-аудита агент автоматизирует не то, без подготовки данных он галлюцинирует, без тестирования на реальных данных ведёт себя иначе, чем в демо.
Ниже разобран полный цикл: семь этапов с реальными сроками, пять рисков с конкретными решениями для российского контекста и чеклист того, что обязан делать подрядчик.
Глоссарий: четыре термина, без которых разговор с подрядчиком невозможен
Прежде чем говорить об этапах, нужно одинаково понимать термины. Их путают даже в коммерческих предложениях.
LLM (Large Language Model, большая языковая модель) — языковая модель, обученная предсказывать следующий токен в тексте. ChatGPT, Claude, GigaChat — это LLM. Сами по себе модели не выполняют задачи: они принимают текст на вход и возвращают текст на выход. Всё, что они «знают», зашито в веса при обучении.
ИИ-агент — это LLM плюс логика, память и инструменты (доступ к API, CRM, базам данных). Агент не просто отвечает: он получает задачу, планирует действия, выполняет их через подключённые инструменты и проверяет результат. Подробнее о разнице между чат-ботом и агентом: «Chatbot vs ИИ-агент: в чём реальная разница».
RAG (Retrieval-Augmented Generation) — метод, при котором агент перед ответом извлекает релевантные документы из базы знаний компании и включает их в контекст запроса к LLM. Это позволяет работать со специфическими данными бизнеса (прайс-лист, регламенты, нормативная база) без дорогостоящего переобучения модели. При обновлении базы знаний агент сразу использует актуальные данные.
Файн-тюнинг (fine-tuning) — дообучение базовой модели на корпоративных данных для изменения её поведения или усвоения специализированного словаря. Стоит от 300 000 ₽ за итерацию и нужен значительно реже, чем его предлагают. Для большинства задач МСБ RAG решает ту же задачу быстрее и дешевле.
Этап 1: Бизнес-аудит — где больнее всего
Срок: 2–5 дней
Первый вопрос аудита звучит не как «что можно автоматизировать с помощью ИИ», а как «где процесс болит настолько, что это измеримо в деньгах или времени прямо сейчас». Разница принципиальна: первый вопрос ведёт к списку технически возможного, второй — к списку экономически оправданного.
Аудит проходит в три шага.
Первый шаг — карта процессов. Проводятся интервью с руководителями отделов, которые задействованы в потенциальном проекте, плюс наблюдение за реальной работой сотрудников в течение нескольких часов. Цель не список «неэффективностей», а конкретные точки, где человек повторяет одно и то же действие с разными данными изо дня в день.
Второй шаг — квантификация. Каждый кандидат на автоматизацию получает числовую оценку: сколько часов в месяц это занимает, сколько людей вовлечено, во сколько обходится ошибка или задержка. Типичный пример из сегмента бухаутсорса: ввод первичных документов в 1С занимает 4–5 минут на документ (ориентир из описаний вакансий hh.ru, где нагрузку обозначают как «200–400 первичных документов в месяц»). При потоке 2 000 документов в месяц это 160+ часов чистого ввода данных. Это измеримо и сравнимо со стоимостью решения.
Третий шаг — фильтр автоматизируемости. Не каждая болезненная задача поддаётся автоматизации через ИИ. Хорошие кандидаты имеют несколько общих черт: понятный вход и понятный выход, высокая повторяемость, большой объём (от 50 случаев в месяц), типизированные данные. Плохие кандидаты: задачи с размытым критерием результата, требующие согласования нескольких людей по каждому случаю отдельно, или редкие задачи с высокой вариативностью, где стоимость ошибки критична.
Результат аудита: приоритизированный список кандидатов с оценкой потенциальной экономии и сложности реализации. Этот список, а не общие слова про «трансформацию бизнеса», становится основанием для следующего шага.
Этап 2: Выбор пилота — правило Парето для AI
Срок: 1–2 дня (опирается на результаты аудита)
Из списка кандидатов нужно выбрать один процесс для пилота. Соблазн взять сразу несколько велик, и это типичная ошибка. Объяснить её несложно: кажется логичным сразу закрыть три болевые точки за один бюджет. На практике каждый добавленный процесс умножает сложность, а не прибавляет к ней линейно.
Критерии выбора хорошего пилота. Максимальная измеримость результата: до и после должны выражаться в числах (время, деньги, процент ошибок). Минимальные зависимости от других систем: идеально, если пилот затрагивает одну систему и один канал. Быстрая обратная связь: результат виден в течение 2–4 недель после запуска, а не через квартал. Достаточный объём данных: минимум 50–100 реальных примеров для создания тестовой выборки.
Почему важен именно один процесс: при пилоте команда впервые видит, как ведёт себя агент на реальных данных, и неизбежно корректирует сценарий. Агент говорит немного иначе, чем хотелось, критерии эскалации оказываются слишком широкими, или клиенты задают вопросы, которых не было в тестах. Все эти правки нужны и полезны. Если пилотируется один процесс, итерации управляемы. Если три, каждое изменение в одном затрагивает архитектуру других.
Рабочее правило выбора: ищите процесс, который занимает 20% времени команды и создаёт 80% ощущения рутины. В продажах это чаще всего квалификация входящих лидов. В бухгалтерии это ввод первичной документации. В юридическом аутсорсе это первичная проверка договоров на соответствие стандартным условиям.
Этап 3: Подготовка данных — 40% времени проекта
Срок: 1–3 недели (зависит от состояния данных)
Это этап, который чаще всего недооценивают при планировании. По опыту проектов внедрения, особенно при работе с документами и базами знаний, подготовка данных занимает 35–45% общего времени проекта (оценка автора, основана на типичных профилях МСБ-проектов). Заказчики планируют одну неделю, получают три.
Что входит в подготовку данных и почему каждый шаг важен.
Инвентаризация источников. Первый вопрос: где реально хранятся данные, которые агент должен знать? Ответ часто оказывается неприятным. База знаний существует в виде PDF в разных папках на Яндекс.Диске, часть информации находится в головах менеджеров, часть в Excel, часть в CRM, часть в чатах Telegram. Всё это нужно найти, собрать и описать до начала разработки, иначе агент будет знать только то, что подрядчик случайно нашёл.
Очистка и структурирование. Агент работает с тем, что ему дают. Если в базе знаний 20 версий одного регламента, он будет давать противоречивые ответы на один и тот же вопрос. Если в CRM у 30% лидов не заполнены ключевые поля, агент не сможет нормально квалифицировать их по нужным критериям. Проблема здесь в данных, а не в агенте, и решить её надо до начала разработки.
Разметка для тестирования. Для объективной оценки качества агента нужна выборка эталонных примеров: 50–200 случаев с правильными ответами, которые потом используются как тестовый набор. Без этой выборки невозможно сказать, работает ли агент хорошо, потому что у оценщика нет объективного ориентира. «Кажется, отвечает нормально» не является приёмочным критерием.
Обезличивание под 152-ФЗ. Если данные включают персональные данные клиентов (имена, телефоны, паспортные данные), перед передачей в LLM они должны быть обезличены или обработка должна вестись только на российской инфраструктуре. Это требование действующего законодательства для любого бизнеса, а не опциональный шаг для одних лишь крупных компаний.
Типичная ситуация: компания думала, что база знаний готова, потому что «у нас всё записано». При инвентаризации выясняется, что «всё» — это четыре Word-файла разного года, несовместимые регламенты и неструктурированная переписка в Telegram. На приведение в порядок уходит 10–12 рабочих дней вместо запланированных трёх.
Этап 4: Разработка пилота
Срок: 2–4 недели
На этом этапе строится первая работающая версия агента. Она намеренно сужена: один сценарий, одна интеграция, ограниченный набор данных. Широкий функционал добавляется после того, как узкий сценарий доказал работоспособность.
Разработка состоит из нескольких параллельных потоков.
Архитектурный. Выбор LLM (Claude, GigaChat, YandexGPT; выбор зависит от требований к суверенности данных и специфики задачи), оркестратора (n8n для большинства МСБ-проектов), схемы памяти агента и формата хранения данных. Для задач, где важна работа с документами компании, строится RAG-система: база знаний индексируется, при каждом запросе агент сначала ищет релевантные фрагменты, потом формирует ответ на их основе.
Промптинговый. Написание системного промпта — это описание роли агента, доступных инструментов, критериев эскалации на человека и формата ответов. Это не «запрос в ChatGPT». Нормальный системный промпт для бизнес-агента занимает 500–1500 слов и проходит 15–30 итераций правок. Большая часть итераций происходит после первых тестов: агент отвечает чуть не так, чуть не в том формате, чуть слишком многословно или, наоборот, слишком кратко.
Интеграционный. Подключение к CRM, мессенджеру, базе данных — в зависимости от сценария. Каждая интеграция требует настройки авторизации, обработки ошибок и очереди на случай пиковой нагрузки. Подробно об интеграции с AmoCRM и Битрикс24 написано в статье «ИИ-агент для CRM: интеграция с AmoCRM, Битрикс24 и 1С».
К концу этого этапа существует агент, который правильно обрабатывает типовые сценарии на синтетических тестовых данных. Синтетика и реальность устроены по-разному, поэтому следующий этап обязателен.
Этап 5: Тестирование
Срок: 1–2 недели
Тестирование проходит в два слоя, и оба необходимы.
Внутреннее тестирование. Команда разработки прогоняет агента по размеченной выборке из этапа 3 и по стресс-сценариям: нестандартные запросы, пограничные случаи, попытки вывести агента за рамки сценария. Фиксируются три ключевых показателя: процент корректных автономных обработок, процент эскалации на человека и процент явных ошибок.
Нормальные ориентиры для МСБ-пилота: 85–92% корректных автономных обработок на типовых случаях, 5–15% эскалация на человека, 0–3% явных ошибок (оценка автора на основе профиля типовых задач квалификации и документооборота). Если галлюцинации выше 5%, проблема в промпте или в качестве базы знаний. Эта проблема устраняется на этапе разработки, до пользователей она не доходит.
Тест на реальных данных (теневой режим). Агент запускается параллельно с реальной работой сотрудников, но без права самостоятельно действовать. Его ответы сравниваются с тем, что реально сделал человек в тех же ситуациях. Это выявляет случаи, которые не попали в синтетическую выборку, и даёт честную оценку качества на реальном трафике.
Разница между демо и реальностью может быть двукратной. Без теневого режима невозможно заранее знать, с какой долей запросов агент справится в продакшне. Именно поэтому честный подрядчик не пропускает этот шаг, даже если заказчик торопится.
Этап 6: Внедрение в продакшн
Срок: 1–2 недели с постепенным расширением
Выход в продакшн не означает «включили и ушли». Нормальная схема предполагает поэтапное расширение зоны ответственности агента.
Первая неделя: агент работает на 10–20% реального трафика. Каждый его ответ проверяется вручную. Это требует времени от команды, но позволяет перехватить неожиданные паттерны поведения до того, как они стали массовыми. Чаще всего здесь обнаруживаются специфические формулировки клиентов, которых не было в тестовых данных, и граничные случаи, которые агент обрабатывает неоптимально.
Вторая неделя: если точность подтверждена на малом трафике, долю поднимают до 50–70%. Ручные проверки переходят в выборочные: каждый пятый или десятый случай, плюс все случаи эскалации.
Параллельно идёт онбординг команды. Сотрудники, которые работали с этим процессом раньше, должны понимать конкретные вещи: что именно агент делает сам, что передаёт на ручную обработку, как читать флаги и метрики в дашборде, как сообщить об ошибке. Онбординг занимает 2–4 часа и принципиально влияет на принятие нового инструмента командой. Сопротивление команды — один из пяти рисков, о которых написано ниже.
Этап 7: Масштабирование
Срок: от 1 месяца после стабильного продакшна
Масштабирование начинается только после того, как агент показал стабильную работу на полном трафике целевого процесса в течение 2–4 недель. Преждевременное расширение при нестабильном пилоте умножает проблемы, а не решения.
Масштабирование идёт по двум осям.
Горизонтальная. Тот же тип агента на большем объёме данных или в большем количестве каналов. Например, агент квалифицирует лиды из Telegram. Горизонтальное масштабирование: подключить WhatsApp, чат на сайте, звонки через голосовой бот. Архитектура не меняется, добавляются новые входящие каналы.
Вертикальная. Добавление новых сценариев к существующему агенту. Агент квалифицирует лиды. Вертикальное масштабирование: агент дополнительно подбирает планировки из каталога по заданным параметрам, рассчитывает ипотечные варианты по актуальным ставкам, ставит задачи менеджеру в CRM. Для застройщика это стандартная эволюция от базового квалификатора к полноценному агенту продаж. Подробнее о том, как это работает в строительной нише: AI для застройщиков и девелоперов.
Важный технический момент этапа: масштабирование требует пересмотра архитектуры. Агент, который работал для 100 обращений в месяц, при 1 000 может упереться в rate limit LLM-провайдера, в производительность n8n-инстанса или в ограничения CRM API. Это предсказуемая инженерная задача, но её нужно закрывать до роста нагрузки, а не в момент сбоев.
5 рисков и как их закрыть
Риск 1: Галлюцинации модели
LLM иногда уверенно генерирует неверный ответ. Для бизнес-агента это конкретная проблема: если агент сообщит клиенту неверную цену, неверный срок или неверные условия, это претензия или потеря сделки.
Как закрыть. Три механизма используются одновременно. RAG вместо генерации из памяти модели: агент берёт факты из базы знаний компании, а не генерирует их самостоятельно. Явные ограничения в промпте: «если информация не найдена в базе знаний, скажи об этом прямо, не додумывай». Автоматические регрессионные тесты: после каждого обновления базы знаний агент прогоняется по размеченной выборке, и показатели точности сравниваются с предыдущими значениями.
Для критичных бизнес-данных (цены, юридические условия, сроки) добавляют верификационный слой: агент формирует ответ, но перед отправкой клиенту сверяет ключевые цифры с источником и только после этого отправляет.
Риск 2: Нарушение 152-ФЗ
Агент, обрабатывающий персональные данные клиентов через зарубежный LLM-провайдер без обезличивания, нарушает требование локализации персональных данных. После поправок 2023–2024 годов штраф за повторное нарушение достигает 15 000 000 ₽, за нарушение локализации — до 6 000 000 ₽ (КоАП РФ, статья 13.11).
Как закрыть. Есть три подхода, выбор зависит от требований конкретного бизнеса. Первый: обезличивание данных перед передачей в LLM — ФИО, телефоны, паспортные данные заменяются на метки, агент работает с обезличенной версией и не видит идентификаторов реальных людей. Второй: российский LLM-провайдер (Yandex Cloud с YandexGPT, GigaChat от Сбера) — данные остаются в российской инфраструктуре и не выходят за пределы РФ. Третий: on-premise развёртывание — n8n, LLM и все компоненты работают на вашем сервере или в вашем закрытом облаке. Самый дорогой вариант, но снимает все вопросы по 152-ФЗ и требования корпоративной службы безопасности.
Риск 3: Vendor lock-in
Подрядчик строит агента на проприетарной платформе или в архитектуре, которую невозможно поддерживать без него. При смене подрядчика или росте тарифа платформы теряется весь актив: промпты, сценарии, настройки, накопленная база знаний.
Как закрыть. Перед подписанием договора задаются три прямых вопроса: на чьей инфраструктуре работает агент, кому принадлежат промпты и сценарии после сдачи проекта, возможен ли перенос к другому подрядчику без переписки с нуля. Нормальный подрядчик использует open-source оркестраторы (n8n, LangChain), стандартные API LLM-провайдеров и документирует архитектуру так, чтобы другая команда могла разобраться и продолжить работу. Подробнее о критериях выбора подрядчика и красных флагах: «Сколько стоит ИИ-агент: реальные цифры и за что не платить».
Риск 4: Саботаж команды
Внедрение ИИ воспринимается частью сотрудников как угроза рабочему месту. Это приводит к намеренному или неосознанному саботажу: данные агенту передаются неверно или неполно, находятся причины не пользоваться системой, жалобы на «постоянные ошибки» преувеличиваются. По данным McKinsey (The State of AI, 2024), сопротивление персонала входит в топ-3 причин неуспешного внедрения корпоративного ИИ.
Как закрыть. Три шага, которые работают вместе. Первый: вовлечь будущих пользователей ещё на этапе аудита, когда описывается текущий процесс. Сотрудник, который участвовал в описании своей работы, воспринимает агента иначе, чем тот, которому внезапно сообщили об изменениях. Второй: честно объяснить изменения до запуска — что агент делает сам, что остаётся за человеком, как изменится нагрузка. Агент снимает рутину, но не заменяет экспертизу. Третий: позиционировать флаги и ошибки агента как штатный механизм контроля качества, а не как повод для сравнения с человеком.
Риск 5: Неконтролируемый рост операционной стоимости
Стоимость использования LLM зависит от объёма токенов: слов на входе и выходе каждого запроса. При росте трафика расходы могут вырасти нелинейно, если промпты перегружены лишним контекстом или если агент по каждому запросу тянет из базы знаний больше, чем нужно.
Как закрыть. До начала проекта зафиксировать прогноз: какая модель используется, какой объём запросов планируется в месяц, сколько токенов в среднем на один запрос. Это позволяет рассчитать операционные расходы на год вперёд и убедиться, что они не поедают экономию от автоматизации. Для большинства МСБ-задач при объёме 500–2 000 обращений в месяц расходы на токены составляют 3–15 000 ₽/мес (оценка автора), что несущественно на фоне экономии. Но при 20 000 обращений и неоптимизированных промптах та же сумма может вырасти в 10 раз. Дополнительные инструменты снижения стоимости: кеширование повторяющихся запросов и оптимизация промптов под минимальный нужный объём контекста.
Что обязан делать подрядчик: чеклист
Это не набор пожеланий. Это то, без чего проект с высокой вероятностью не доживёт до масштабирования.
До начала работ
- Бизнес-аудит с количественной оценкой кандидатов на автоматизацию. Не «провели интервью», а «вот список с цифрами по каждому процессу».
- Детализированная смета с разбивкой по компонентам: проектирование, разработка, интеграция, тестирование, поддержка. Подрядчик, который даёт только общую сумму, не понимает, что именно делает.
- Прогноз операционных расходов (токены, инфраструктура) при вашем объёме трафика на год вперёд.
- Архитектурное решение по 152-ФЗ, зафиксированное в договоре, а не в устных обещаниях.
В процессе разработки
- Аудит данных до написания первой строки кода. Иначе «неожиданная» задержка с подготовкой данных гарантирована.
- Размеченная тестовая выборка для объективной оценки качества агента, а не субъективного «кажется, работает».
- Теневой режим перед полным выходом в продакшн.
- Документация архитектуры: промпты, схема интеграций, описание логики. Читаемые документы, а не «разберётесь по коду».
После запуска
- Онбординг команды: что агент делает сам, что передаёт людям, как читать метрики и флаги, как сообщить об ошибке.
- Поддержка с фиксированным SLA и явным составом работ. «Будем на связи» — не SLA.
- Прозрачный мониторинг с доступом заказчику: количество обработанных запросов, процент эскалации, процент ошибок. Без метрик невозможно обнаружить деградацию агента.
Пять вопросов для первой встречи с подрядчиком
- Покажите пример агента, которого вы сдавали клиенту, и метрики его работы через 3 месяца после запуска.
- Как решается вопрос 152-ФЗ в нашем конкретном сценарии?
- Кому принадлежат промпты и сценарии агента после сдачи проекта?
- Что происходит с агентом при обновлении нашей CRM или при изменении API LLM-провайдера?
- Какова ваша оценка операционных расходов при нашем объёме трафика?
Если на любой из этих вопросов нет конкретного ответа, это информация для принятия решения о выборе подрядчика.
Следующий шаг в зависимости от вашей ниши
Выбор точки входа в автоматизацию зависит от специфики бизнеса. Строительная и девелоперская отрасль имеет свои болевые точки: скорость квалификации лидов, работа с ипотечными программами, ночной трафик из рекламы. Бухаутсорс — свои: объём первичных документов, интеграция с нетиповыми конфигурациями 1С, требования к точности разнесения. Юридические услуги — свои: первичный скрининг договоров, клиентские вопросы по типовым ситуациям.
Отраслевые разборы с расчётами ROI: AI для строительства и девелопмента, AI для бухаутсорса, AI для юридических фирм.
Если хотите понять стоимость и окупаемость под вашу конкретную задачу — разберём ваш процесс и дадим оценку за 2 рабочих дня: страница с пакетами и составом работ.
Автор: Команда UKLAD. Разрабатываем ИИ-агентов для автоматизации продаж и операционных процессов в малом и среднем бизнесе.