Внедрение ИИ в компании: с чего начинать, чтобы не сжечь бюджет

Главная ошибка — начинать с технологии

Типичный сценарий выглядит так. Руководитель прочитал в тг-канале, что у кого-то нейросеть за минуту разбирает договор. Возникает задача: «внедрить ИИ». Дальше ищут подрядчика, обсуждают модели, спорят про облако и локальный сервер, согласовывают, согласовывают, согласовывают — и через шесть месяцев получают работающую систему, которой никто не пользуется. Деньги потрачены, коммерческого эффекта ноль.

Сломалось всё на первом шаге. В постановке «внедрить ИИ» нет ни одного числа: сколько документов в месяц, сколько времени уходит сейчас, кто именно этим занят, что произойдёт, если система ошибётся.

Хорошая постановка звучит скучно. «Три менеджера тратят примерно по два часа в день на перенос данных из писем в CRM. Ошибаются редко, но исправление стоит дорого». Здесь уже видно всё: объём, стоимость часа, цена ошибки. Такую задачу можно оценить — и можно понять, что ИИ в ней окупится за считанные месяцы. Или что не окупится, и это тоже полезный ответ.

Есть и вторая формулировка. Она встречается чаще, а звучит менее удобно: «Три менеджера вносят данные в CRM как придётся. Кто-то в конце недели, кто-то только через сделку, кто-то не вносит вовсе — потому что это мешает им продавать».

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

Люди здесь не ленятся. Они выбирают между своим основным процессом и чужим требованием — и выбирают предсказуемо. Регламентом это не чинится: указание «вносить аккуратно» проигрывает живому разговору с клиентом всегда, в любой компании, независимо от строгости руководителя.

И вот тут ИИ уместен — но не в той роли, в которой его обычно предлагают. Не «помочь менеджеру быстрее заполнить карточку», а убрать саму форму. Менеджер пишет в телеграм обычным человеческим сообщением: «заведи сделку, компания такая-то, контакт такой-то, обсуждали поставку на второй квартал, следующий шаг — созвон в четверг». Система разбирает это на поля, создаёт запись в CRM и отвечает тем же сообщением: вот что записал, вот чего не хватает. Если не хватает обязательного поля — переспрашивает одним вопросом, а не отправляет заполнять форму.

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

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

Разница между двумя постановками кажется косметической, а стоит по-разному. «Ускорить ввод» — задача про интерфейс. «Перестать заставлять открывать CRM» — задача про интеграцию с мессенджером, разбор свободного текста и правило, что делать, когда система не уверена. Дороже на старте, осмысленнее на дистанции.

Есть и побочный эффект, ради которого за это часто и берутся. Пока данные в CRM неполные, поверх них нельзя построить ничего: ни аналитику, ни прогноз, ни ассистента. Сначала чинится источник — потом всё остальное. К этому мы ещё вернёмся.

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

Где ИИ окупается, а где — нет

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

Теперь про обратную сторону, о которой на конференциях говорят реже.

ИИ бесполезен, если объёма нет. Автоматизировать обработку пяти заявок в месяц — дороже, чем обрабатывать их руками, и так будет всегда. Инструмент имеет смысл там, где рутина измеряется часами в неделю, а не минутами.

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

И самое частое: ИИ бесполезен, если данных нет. Не «мало» — а нет в пригодном виде. К этому стоит отнестись серьёзнее всего.

Данные решают исход раньше, чем архитектура

С документами происходит ровно то же, что с CRM из первого раздела, только заметно это позже. Ассистент, отвечающий по базе знаний компании, звучит как задача про нейросеть. На практике это задача про порядок в документах.

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

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

Куда на самом деле уходит бюджет

Здесь ожидания расходятся с реальностью сильнее всего. В голове у заказчика бюджет внедрения — это стоимость нейросети. На практике обращения к модели чаще всего оказываются самой мелкой строкой сметы.

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

Отдельно стоит сказать про интеграции. Подключиться к 1С, CRM или внутреннему порталу — это редко про «взять API и подключиться». Там будут ограничения по количеству запросов, поля, которые называются одинаково, но означают разное, и данные, которые формально есть, но заполняются как придётся. Мы делали внутренний портал промышленной компании — с интеграцией в 1С и процессами, смоделированными в BPMN. Большая часть работы там была не в интерфейсе, а в стыковке с тем, что уже работало. Между порталом и учётной системой пришлось построить промежуточный слой: он сводил справочники, достраивал недостающее и приводил записи, заполнявшиеся по-разному в разные годы, к виду, пригодному для показа пользователю. По объёму этот слой обошёлся примерно как ещё один портал. Причина обычная и встречается почти везде: живые работающие системы никто не проектировал под будущую витрину — они складывались годами, как получалось.

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

Почему ИИ выдумывает — и почему это лечится

Главное возражение звучит так: нейросеть уверенно врёт, значит доверять ей нельзя. Возражение справедливое. Но проблема решается не выбором «более умной» модели, а тем, как построена система вокруг неё.

Работает это так. Ответ собирается не из памяти модели, а из ваших документов: система сначала находит подходящие фрагменты, потом просит модель ответить строго по ним. К ответу прикладывается ссылка на источник — конкретный документ и место в нём. Если подходящих фрагментов не нашлось, правильный ответ системы — «не знаю», а не догадка. И на всякий случай остаётся выход на человека.

Ссылка на источник здесь — не украшение. Это единственный способ проверить ответ за десять секунд вместо десяти минут. Без неё пользователь либо проверяет всё вручную (и тогда экономии нет), либо не проверяет ничего (и тогда есть риск). Мы считаем трассируемость обязательной, а не опциональной, — и если её нельзя обеспечить, честнее не делать такой сценарий вовсе.

Пилот, у которого есть границы

Разумный первый шаг — не система, а пилот. Но пилот работает только тогда, когда у него заранее оговорены четыре вещи: один сценарий, реальные данные, срок и критерий успеха.

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

Критерий не обязан быть сложным. «Система корректно разбирает восемь заявок из десяти, остальные уходят человеку» — нормальный критерий. «Работает хорошо» — нет.

Пользоваться будут люди

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

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

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

Коротко

Начинайте не с «внедрить ИИ», а с процесса, который можно измерить: объём, время, цена ошибки. Бюджет уходит не на модель, а на данные, интеграции и поддержку — закладывайте их сразу. Требуйте от системы ссылку на источник и право сказать «не знаю». И берите первым тот сценарий, который сотрудники и так ненавидят делать руками.

Если у вас есть такая задача — опишите её в двух абзацах, без подготовки и брифа. Вернёмся с оценкой объёма и сроков за два рабочих дня. Мы одинаково спокойно говорим и «это окупится», и «здесь ИИ не нужен, вам нужна интеграция».