Внедрение ИИ в бизнес: с чего начать и как довести до результата

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

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

Что вообще можно поручить ИИ в бизнесе

Работа с обращениями клиентов

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

Работа с документами и базой знаний

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

Работа внутри рабочих систем

Здесь ассистент перестаёт быть справочной и начинает менять данные. Появляются права доступа, подтверждение действий человеком и проверка того, что действие реально прошло, а не вернуло «принято».

Анализ: звонки, продажи, деньги

Расшифровка разговоров, разметка возражений, сводки по воронке. Ограничение известное: качество зависит от записи, а выводы всё равно делает человек.

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

С чего начать: как выбрать первый процесс

Четыре признака, и они проверяются без специальных знаний:

• Задача повторяется каждый день или хотя бы несколько раз в неделю. Автоматизация окупается объёмом, а не сложностью.
• Результат можно измерить. Доля правильно разобранных заявок, время до первого ответа, число обращений, закрытых без человека. Метрика выбирается до начала работы.
• Под задачу есть данные. Ассистент отвечает по документам, а не вместо них. Если ответы живут в головах, сначала их надо достать.
• Ошибка не стоит критических денег. Первый процесс не берут там, где промах означает потерю клиента или штраф.

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

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

Если процессов много и непонятно, какой брать первым, для этого есть аудит процессов: одна-две недели, карта с оценкой эффекта по каждому.

Как это делается: этапы

Разбор процесса

Смотрят не регламент, а фактический ход работы: кто начинает, куда передаёт, где застревает, что делают при отклонении. Описание «сверху» и реальность расходятся почти всегда.

Пилот на одном участке

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

Проверка на реальных данных

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

Запуск с человеком в контуре

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

Расширение

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

Полный цикл под одним исполнителем - это внедрение под ключ со сроками от полутора месяцев.

Как ставить задачу подрядчику

Хорошее техническое задание отвечает на семь вопросов:

1. Какой процесс меняем.
2. Как выглядит «сделано».
3. Откуда берутся данные.
4. Что система делать не должна.
5. Кто утверждает.
6. Как проверяется выполнение.
7. Что происходит при ошибке.

Документ не обязан быть длинным - две страницы работают лучше двадцати. Главное, чтобы критерий приёмки был измеримым: не «работает корректно», а «85% заявок разбираются без правки на выборке из 200 штук». Разбор с формулировками и шаблоном - в материале про техническое задание.

С одинаковым ТЗ можно пойти к трём подрядчикам и получить сравнимые предложения. Без него вы получите три описания разных работ. Что ещё спросить до договора, собрано в списке как выбрать подрядчика.

Сколько это стоит

Порядок цен на 2026 год:

• Разбор процесса - бесплатно, тридцать минут.
• Аудит процессов - 60 000 ₽.
• Пилот - от 150 000 ₽.
• Внедрение под ключ - от 450 000 ₽.
• Сопровождение - от 50 000 ₽ в месяц.

Аудит и пилот засчитываются в стоимость внедрения полностью, если оно начинается по их итогам и по той же задаче.

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

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

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

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

Почему проекты не доходят до результата

Четыре группы причин, и ни одна не про качество моделей.

• Задачу выбрали неправильно: взяли процесс, где хватило бы обычной программы, или где ИИ не может знать ответ, или сразу слишком большой.
• Результат никто не проверяет: проверка ответа стоит дороже самой работы, а в отчётах растут цифры активности вместо исхода.
• Интеграция выглядит рабочей: сервер отвечает «принято», а данные не меняются, и обнаруживается это через недели.
• Эксплуатацию не спроектировали: не определили, что такое «сделано», не назначили владельца, база знаний устарела.

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

Что происходит после запуска

Система требует внимания, и это надо планировать заранее.

• Кто-то должен разбирать очередь исключений: задачи, на которых цепочка остановилась. Конкретный человек с именем и выделенным временем, а не «служба поддержки».
• Кто-то должен обновлять документы, по которым отвечает ассистент. Устаревшая база знаний хуже отсутствующей: ассистент отвечает уверенно и неверно, и ему верят.
• Кто-то должен следить за расходом на вызовы модели. Бюджет на месяц выгорает за неделю, если в процесс попал поток, которого никто не считал.
• Система должна пережить изменение процесса. Регламенты меняются, поля в системах переименовывают, отделы переезжают. Без сопровождения система тихо расходится с реальностью при формально работающем коде.

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

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

Данные и безопасность

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

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

Оператором персональных данных остаётся компания всегда: ответственность нельзя передать вместе с проектом. Что это значит на практике и что нужно сделать до запуска, разобрано в разделе про требования 152-ФЗ.

Люди: сопротивление и обучение

Техническая часть внедрения обычно проще человеческой.

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

Второй источник сопротивления - страх увольнения. Он снимается не заверениями, а фактом: система забирает объём, а решения остаются за человеком. Формулировка «машина делает объём, человек - вкус» работает лучше любых презентаций, если она подтверждается тем, что видно в работе.

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

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

Примеры

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

Первый - мои собственные проекты: конвейеры обработки данных, серверы для ИИ-инструментов, веб-приложения. Двадцать три штуки, часть с исходным кодом. Смотреть их можно на странице проектов.

Второй - разбор типовых сценариев внедрения без привязки к конкретным компаниям: что именно меняется в работе отдела, какие цифры считать и на что смотреть через три месяца. Он собран на странице кейсы внедрения ИИ, и там же честно объяснено, почему эта страница устроена именно так.

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

С чего начать внедрение ИИ, если ничего не автоматизировано?

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

Сколько времени занимает внедрение ИИ?

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

Нужны ли для внедрения свои разработчики?

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

Можно ли обойтись готовыми сервисами?

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

Что делать, если данные в беспорядке?

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

Как понять, что внедрение окупилось?

Сравнить стоимость одного обращения до и после и умножить разницу на месячный объём. В расчёт обязательно включить время человека на проверку: в первый месяц оно съедает большую часть экономии, так и задумано. Разница становится видна к третьему-четвёртому месяцу, когда подтверждение снимается с шагов, где ошибок не осталось. Если к полугоду её нет, автоматизировали не тот процесс.

Что дальше

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

Написать можно в Telegram или на почту hi@za-ai.ru.