Внедрение ИИ под ключ: как выбрать задачу, подрядчика и формат пилота

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть несколько ситуаций, где честный ответ — отложить. Процесс не описан и у каждого сотрудника свой: сначала описание, потом автоматизация, иначе модель выучит противоречия. Архива нет и собирать его неоткуда: пилот превратится в сбор данных, лучше так его и назвать. Задача решается правилами: если критерий формулируется как «если сумма больше миллиона — на согласование», это условие в коде, а не машинное обучение, и оно будет работать точнее и дешевле.

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

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