Внедрение ИИ в компании: с чего начать

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

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

Почему пилоты не доживают

Три причины, и все три закладываются до первой строчки кода.

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

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

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

Какой процесс брать первым

Признаки хорошего первого процесса, по убыванию важности:

1. Результат проверяется быстрее, чем делается. Черновик письма читается за минуту, а пишется за десять. Разметка обращений проверяется взглядом. Поиск по своим документам проверяется переходом к источнику.
2. Ошибка обратима. Никакой отправки наружу, никаких денег, никакого удаления на первом контуре.
3. Процесс повторяется часто. Раз в квартал — не тот случай: выигрыш не накопится, а поддерживать придётся.
4. Есть люди, которые уже делают это руками. Они и станут теми, кто скажет, стало ли лучше.

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

План на первые шесть недель

Реалистичный, без «трансформации».

Неделя 1 — выбор процесса и постановка. Описать вход, выход, критерий готовности и владельца. Результат недели — формулировка, которую можно провалить.

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

Недели 3–4 — сборка и замер. Промпт, схема вывода, проверки. Выбор модели делается здесь, а не в начале, и занимает полдня по процедуре.

Неделя 5 — работа с людьми. Не «обучение нейросетям», а разбор конкретных случаев с теми, кто будет принимать результат. Здесь обычно и вскрывается, что «правильный ответ» разные сотрудники понимают по-разному.

Неделя 6 — ограниченный запуск. Один отдел, обратимые операции, журнал действий. Не пилот ради демонстрации, а рабочий контур в малом объёме.

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

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

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

Условие несогласия

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

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

Чего я делать не стал бы

Не стал бы начинать с закупки платформы. Инструмент выбирается под задачу, и почти всегда оказывается, что первую задачу закрывает то, что уже есть.

Не стал бы делать первым контуром общение с клиентом. Там дорогая ошибка и медленная обратная связь — худшее сочетание для обучения на своих промахах.

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

Открытый вопрос

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

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