Пилотный проект ИИ в компании: как ограничить риск

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

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

Когда процесс подходит для пилота

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

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

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

Как устроен пилотный проект ИИ: шесть шагов

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

1. Описание задачи. Вы своими словами рассказываете, кто выполняет процесс, что делается руками и какой результат нужен. Техническое задание не требуется.
2. Оценка. Проверяем, подходит ли задача для ИИ и доступны ли интерфейсы систем, называем состав работ, диапазон часов и лимит бюджета.
3. Договор и доступы. Фиксируем предмет, порядок приёмки и права на результат, согласуем площадку и классы данных с вашей ИТ-службой.
4. Сборка. Архитектура, агент, интеграции с 1С, CRM, почтой или Telegram. Промежуточные версии показываем на ограниченных данных.
5. Проверка. Прогоняем типовые, ошибочные и рискованные сценарии, настраиваем журналы действий и передачу спорных случаев человеку. До выпуска в отдел агент работает в стендовой группе.
6. Запуск и сопровождение. Инструкции, обучение сотрудников, регламент сопровождения.

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

Какие данные и доступы нужны для MVP ИИ

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

Три решения согласуются с ИТ и ИБ до того, как агент увидит первый документ: где работает система (ваш сервер или арендованная площадка в России, с учётом требований 152-ФЗ), какие данные видит модель (классы данных фиксируются политикой проекта, а тексты документов могут оставаться на сервере с локальной моделью эмбеддингов) и что агент может изменить сам, а что ждёт подтверждения человека.

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

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

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

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

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

Пример сценария: обработка входящих заявок

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

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

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

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

Критерии остановки: когда пилот закрывают

Критерии формулируют до старта, а не в конце. Пилот закрывают или пересматривают, если:

• агент даёт ответы, которые нельзя проверить по вашим данным;
• доля операций с ручной переделкой не ниже, чем без агента;
• спорные случаи разбирать дольше, чем выполнять операцию вручную;
• доступы и классы данных не согласованы ИБ, а обойти ограничение нельзя;
• расход на модели и API превышает полезный эффект, а лимиты не настроены;
• сотрудники обходят инструмент и ведут работу по-старому.

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

Как измерить результат и решить о масштабировании

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

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

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

С чего начать

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

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