Коротко
Пилот ИИ за 30 дней нужен не для того, чтобы «пощупать технологию». Он нужен, чтобы принять решение: закрываем, дорабатываем или масштабируем. Если через месяц команда говорит «ну давайте ещё поэкспериментируем», значит пилот был плохо сформулирован.
Для Казахстана хороший пилот обычно очень приземлённый: заявки из WhatsApp в amoCRM, черновики ответов поддержке, поиск по базе знаний, проверка актов, первичный HR-скрининг, ответы регистратуры, контроль пропущенных сделок. Один процесс, один владелец, реальные примеры, ограниченные права агента.
Не надо пытаться за месяц подключить все филиалы, всю 1C, все каналы и всех руководителей. Так пилот превращается в мини-трансформацию, а мини-трансформации редко успевают дать честный результат.
Главное правило месяца
Пилот должен проверять не «может ли ИИ отвечать», а конкретное изменение процесса.
Слабый вопрос: можем ли мы внедрить ИИ в продажи?
Сильный вопрос: может ли агент читать входящие сообщения из WhatsApp, собирать краткое резюме лида, предлагать следующий шаг менеджеру и находить сделки без follow-up в amoCRM?
Слабый вопрос: поможет ли ИИ поддержке?
Сильный вопрос: может ли ассистент находить нужный регламент, готовить короткий ответ оператору, показывать источник и снижать время обработки типовых вопросов без роста ошибок?
Когда вопрос конкретный, пилот становится измеримым.
Неделя 1: выбираем процесс и владельца
Первую неделю нельзя тратить на выбор модели. Её надо тратить на выбор боли.
Подходят процессы, где есть повторяемость, объём и понятная цена ручной работы: HR-заявки, поддержка, продажи, документы, финансы, складские исключения, регистратура. Плохо подходят «давайте сделаем что-нибудь с ИИ» и «пусть агент станет помощником всем отделам».
Назначьте владельца процесса. Это человек, который решает, хороший ответ или плохой, можно ли отдавать действие агенту, какие исключения важны, какие ошибки неприемлемы. Без владельца пилот будет жить в IT, а бизнес потом скажет, что это не то.
Сразу зафиксируйте baseline: сколько кейсов в неделю, сколько времени уходит сейчас, где болит, что считается успехом. Не надо сложной BI-модели. Достаточно честной исходной точки.
Неделя 2: собираем реальные кейсы
Не придумывайте идеальные вопросы в комнате переговоров. Возьмите настоящие.
Для первого пилота обычно хватает 100-300 примеров: переписки, тикеты, резюме, акты, счета, внутренние вопросы, карточки сделок. Важно, чтобы среди них были неудобные случаи: неполные данные, злые клиенты, смешанный русский/казахский, скриншоты, старые инструкции, конфликтующие статусы, просьбы сделать то, что нельзя.
К каждому примеру нужно добавить ожидаемое поведение. Не всегда это ответ. Иногда правильное действие - задать уточняющий вопрос, показать источник, создать черновик задачи, передать человеку или отказаться.
Так появляется основа для evals для AI-проектов. Без неё финал пилота превращается в спор: кому-то понравилось, кому-то нет.
Неделя 3: собираем ограниченную версию
Ограниченная версия не значит бесполезная. Она значит честная.
Один канал. Один набор источников. Один сценарий. Один или два пути интеграции. Если агенту нужен Bitrix24 или amoCRM, начните с чтения и черновиков. Если нужен 1C-статус, на пилоте часто достаточно выгрузки или read-only доступа. Если нужна база знаний, не подключайте весь Google Drive. Возьмите проверенную папку.
Пользователь должен видеть, почему агент предлагает ответ: источник, фрагмент переписки, поле CRM, документ, статус. Иначе доверия не будет.
В эту неделю важно не спрятать ошибки. Наоборот, их надо собирать: не тот источник, неверный статус, слишком длинный ответ, лишняя уверенность, пропущенный риск, неправильная передача человеку, путаница филиалов, плохое понимание shala-Kazakh.
Неделя 4: считаем и решаем
Финальная неделя - не для добавления новых хотелок. Она для решения.
Прогоните тест-набор ещё раз. Сравните результат после исправлений. Посмотрите, сколько ответов проходит без серьёзной правки, где человек всё равно переписывает с нуля, какие ошибки остаются опасными, что нужно для production.
Решение должно быть одним из трёх. Закрываем: задача не стоит разработки, данных мало, риск высокий, пользователи не приняли. Дорабатываем: польза видна, но нужно почистить источники, собрать больше кейсов, изменить границу интеграций или сузить сценарий. Масштабируем: качество, экономика и принятие достаточные, чтобы планировать боевой запуск.
Если решение расплывчатое, пилот не выполнил свою работу.
Что входит, а что нет
Минимальный набор: один процесс, один владелец, 100-300 реальных кейсов, критерии качества, правила передачи человеку, логирование, ограниченный источник данных, понятная граница интеграций, baseline-метрика, финальное решение о масштабе.
Не подключайте все каналы. Не давайте агенту менять деньги, скидки, статусы оплаты, медицинские рекомендации или юридические обещания. Не зовите на пилот всех руководителей, если они не будут принимать решения. Не измеряйте успех количеством сгенерированных сообщений.
Если пилот успешен, впереди всё равно остаётся production-работа: доступы, мониторинг, поддержка, документация, обучение пользователей, владельцы базы знаний, регулярные проверки качества, план развития.
Если агент должен действовать, а не только писать черновики, следующий шаг лучше строить как AI-агента с понятными правами и human-in-the-loop. Если основной риск в данных и источниках, сначала вернитесь к чеклисту что подготовить перед внедрением ИИ. А если после пилота нужно выбирать команду разработки, используйте разбор как выбрать подрядчика по внедрению ИИ.
Как не обмануть себя результатом
Самый частый самообман пилота - смотреть только на удачные ответы. Команда показывает руководству пять красивых диалогов, а двадцать спорных случаев остаются в стороне. Так делать нельзя. В финальном отчёте должны быть и хорошие примеры, и плохие: где агент не понял язык, где взял не тот источник, где слишком уверенно ответил, где оператору пришлось переписать всё заново.
Отдельно посмотрите на скрытую нагрузку. Если агент экономит оператору минуту, но администратор каждый день два часа правит базу знаний вручную, экономика меняется. Если менеджеры игнорируют подсказки, потому что они появляются не в том окне, проблема не в модели, а в продукте. Если все ответы проходят только после долгой проверки, значит система пока не готова к большему уровню автономности.
Хороший пилот не обязан закончиться масштабированием. Иногда лучший результат - честно увидеть, что сначала нужно привести в порядок источники, роли или CRM-дисциплину. Это тоже экономия: вы не строите production поверх слабого фундамента.
FAQ
Можно ли сделать пилот за 30 дней без разработчиков клиента?
Можно, если есть выгрузки и понятный владелец процесса. Но для интеграций с CRM, 1C или внутренними системами технический человек со стороны клиента сильно ускоряет работу.
Сколько кейсов нужно?
Для узкого сценария обычно хватает 100-300. Важно не количество, а разнообразие: обычные, спорные, неполные, рискованные и языково грязные примеры.
Нужно ли подключать 1C сразу?
Не всегда. Если агенту нужен статус оплаты или документ, можно начать с read-only доступа или выгрузки. Право записи лучше давать позже.
Кто должен принимать результат?
Владелец процесса, а не IT в одиночку. Если пилот про продажи, принимает коммерческий блок. Если про HR - HR. Если про документы - финансы, юристы или операционный владелец.