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

Внедрим ИИ в работу вашей компании
Бесплатно разберём процессы и подготовим план запуска ИИ.

Принесите всем подрядчикам одинаковую задачу
Опишите один процесс: например, входящие заявки из формы и мессенджера, которые должны попасть в CRM. Дайте ожидаемый объём, текущую схему, обезличенные примеры и ограничения по доступам. Не раскрывайте лишние персональные данные на этапе выбора. Если каждому исполнителю дать разное описание, сравнение цен и сроков будет бессмысленным.
Попросите объяснить, что команда сделает до разработки: как проверит качество данных, кто утвердит категории, какие случаи оставит человеку. Подрядчик, который сразу обещает «автоматизировать всё», ещё не показал, что понимает ваш процесс.
Пять доказательств вместо демонстрации
| Что попросить | Что это показывает |
|---|---|
| План пилота на одном процессе | Где проходит граница первого запуска |
| Набор тестовых случаев | Как команда ищет ошибки и исключения |
| Схему доступа и журнал действий | Кто увидит данные и как восстановить событие |
| Смету запуска и эксплуатации | Что оплачивается один раз и ежемесячно |
| План поддержки и отката | Что произойдёт после изменения процесса или сбоя |
Кейс другого клиента полезен как свидетельство опыта, но не заменяет проверку на ваших данных. Попросите показать не только процент «автоматизации», но и определение метрики, объём выборки и условия, при которых кейс сработал.
Сравните архитектуру с правами системы
Какие документы читает агент? Может ли отправлять сообщения или менять записи? Где живут ключи доступа? Что попадает в логи и кто их видит? Ответ «у нас безопасная модель» не раскрывает архитектуру. Профиль NIST по генеративному ИИ помогает сформулировать управление рисками, но договор должен описывать ваши конкретные роли и процедуры.
Если поставщик предлагает один и тот же стек всем клиентам, спросите, как он будет работать с вашей CRM, телефонией и базой знаний. Интеграция — это не скриншот соединённых логотипов, а права, ошибки, повторы и проверяемый результат.
Проверьте коммерческое предложение
Разделите стоимость диагностики, пилота, доработок, инфраструктуры, вызовов моделей и поддержки. Уточните, кому принадлежат сценарии и данные после завершения договора, можно ли выгрузить журнал и продолжить работу с другой командой. Опишите порядок изменения цены при росте нагрузки.
Сильный вопрос: «Если за месяц объём заявок удвоится и появится новая категория, что вы измените, сколько это займёт и как проверите качество?» Ответ покажет зрелость поддержки лучше общего обещания «масштабируется».
Приёмка: что должно работать на реальном потоке
До старта согласуйте базовую метрику, тестовый набор и ответственных за приёмку. На пилоте измерьте долю корректно обработанных случаев, ошибочные действия, время человека на исправление и стоимость завершённой задачи. Отдельно убедитесь, что заявки не теряются при недоступной интеграции, а сотрудник может вернуть ручной режим.
Если результат не достигнут, договор должен позволять сузить объём, исправить проблему или остановить пилот без обязательства покупать масштабный этап. Такое условие защищает и заказчика, и добросовестного исполнителя от расплывчатого «вроде работает».
Как принять решение
Выбирайте предложение, которое делает риски и следующий шаг понятными. Лучший поставщик может не обещать максимальную автоматизацию с первого дня, зато покажет проверяемый путь от задачи до устойчивого процесса. После встречи у вас должны остаться не впечатления от презентации, а список действий, владельцев, сроков, критериев и общей стоимости.
Красные флаги в первом разговоре
Подрядчик обещает точность без тестовой выборки, не спрашивает о правах доступа, показывает только успешные демонстрации или не может объяснить, как передаст случай человеку. Любой из этих сигналов не доказывает недобросовестность, но требует уточнения до договора. Особое внимание уделите фразе «система сама научится на ваших данных»: спросите, какие именно данные используются, где они хранятся и кто проверяет изменения.
Хороший ответ может звучать осторожно: «Сначала проверим 30 типичных случаев, часть действий оставим менеджеру, затем решим, что автоматизировать дальше». Это меньше впечатляет на презентации, зато даёт проверяемые обязательства.
Одинаковая демонстрационная задача для всех кандидатов
Дайте подрядчикам три обезличенных примера: простая заявка с полными данными, неполная заявка и спорный случай с двумя версиями документа. Попросите описать не только ответ агента, но и маршрут данных, границу самостоятельных действий и способ исправить ошибку. Не требуйте бесплатно строить полноценный продукт на этапе выбора; достаточно схемы и логики решения.
Сравнивайте ответы по одним критериям: уточняет ли команда правила, видит ли риск конфликта источников, различает ли черновик и отправленное клиенту сообщение, предлагает ли проверку на реальном потоке. Это даёт больше информации, чем сравнение слайдов о «революции эффективности».
Кто будет владельцем результата после запуска
Спросите, кто в компании обновляет инструкции, кто разбирает жалобы, кто меняет лимит расходов и кто имеет право отключить агента. Подрядчик может поддерживать технологию, но бизнес-правило о скидке или сроке должен утверждать заказчик. Если это не определено, проект зависнет на первом изменении продукта.
Попросите показать формат передачи: документация по источникам и правам, тестовый набор, журнал известных ограничений, описание ручного режима и контакты поддержки. Красивый код без этих материалов сложно безопасно эксплуатировать.
Как читать обещания об окупаемости
Если подрядчик обещает процент экономии, попросите базовый период, объём задач, способ оценки качества и перечень исключённых расходов. Экономия времени сотрудника не всегда равна экономии бюджета; обработка может ускориться, но потребовать нового этапа проверки. Требуйте расчёт стоимости завершённой полезной задачи, а не число обработанных запросов.
Хорошая оценка содержит диапазон и допущения: сколько заявок придёт, какая часть окажется сложной, сколько времени менеджер потратит на проверку. После пилота замените допущения реальными измерениями. Если результат не подтвердился, это причина пересмотреть сценарий, а не повод подкрутить определение успеха задним числом.
Итоговая карточка выбора
По каждому кандидату запишите одну строку с шестью оценками: понимание процесса, качество пилота, безопасность данных, прозрачность сметы, поддержка после запуска и возможность выхода. Рядом укажите не балл «по ощущениям», а доказательство: документ, тест, ответ на конкретный вопрос. Если доказательства нет, оставьте поле пустым.
После сравнения проведите короткую встречу с будущим владельцем процесса и сотрудниками, которым предстоит пользоваться результатом. Они могут заметить неудобство, которое не видно закупке и IT. Финальное решение должно опираться на предстоящую эксплуатацию, а не только на стоимость контракта.
О материале и источниках
Материал подготовлен редакцией Потока с участием ИИ. Первоисточники проверены 27 сентября 2026 года. Учебные ситуации и расчёты не являются результатами испытания продуктов редакцией. Иллюстрация создана через ImageGen и не документирует реальное событие.
- NIST — Generative AI Profile
Источник для постановки вопросов об управлении рисками.
Опубликовано