Обычно деньги начинают теряться раньше – когда бизнес формулирует задачу слишком широко, выбирает подрядчика по презентации и соглашается на архитектуру, которую внутри компании некому оценить.
На старте многое выглядит убедительно. Подрядчик показывает демо, обещает быстрый пилот, использует знакомые названия моделей и платформ. Через несколько месяцев выясняется, что для промышленной работы не хватает данных, интеграции не учтены, стоимость эксплуатации выше ожиданий, а качество результата невозможно нормально измерить.
Большинство таких проблем можно увидеть еще до разработки. Для этого заказчику нужна собственная рамка проверки проекта, а не только техническое задание от будущего подрядчика.

Начинать с бизнес-результата
Первый вопрос – какой конкретный процесс должен измениться. «Внедрить ИИ в продажи» или «сделать корпоративного ассистента» для технического задания недостаточно.
Нужно понимать исходный процесс, объем операций, стоимость ручной работы, допустимый уровень ошибки и ожидаемый эффект. Если результат нельзя измерить, после запуска неизбежно возникает спор о том, работает решение или нет.
На этом же этапе стоит проверить, нужен ли здесь вообще ИИ. Иногда задачу дешевле и надежнее решает обычная автоматизация, интеграция систем или изменение процесса.

Проверить данные до подписания договора
Следующий вопрос – на чем решение будет работать. Где находятся данные, насколько они полны, структурированы и актуальны, кто имеет к ним доступ, можно ли передавать их модели или подрядчику.
Особенно рискованны проекты, где информация распределена между несколькими системами. То, что сотрудник сегодня собирает вручную из Excel, почты, 1С и CRM, модель сама по себе не превращает в надежный цифровой процесс.
До старта нужно определить источники данных, правила доступа, качество информации и необходимые интеграции. Иначе работа над ИИ начнется раньше, чем появится фундамент для него.

Провести техническое интервью
Коммерческой встречи с подрядчиком для серьезного проекта недостаточно. В нашей практике выбор команды разработки включал несколько раундов технических интервью. Мы отдельно разбирали с командами архитектуру будущего решения и проверяли, насколько предложенный подход выдерживает реальные ограничения проекта.
На техническом интервью нужно обсуждать используемые модели, инфраструктуру, безопасность, интеграции, хранение данных, ограничения технологии, стоимость эксплуатации и дальнейшее масштабирование.
Сильная команда умеет объяснить свои решения и спокойно говорит об ограничениях. Если сложные вопросы закрываются фразой «это решит нейросеть», а устройство проекта остается черным ящиком для заказчика, риск слишком высок.

Заранее определить приемку
Еще одна дорогая ошибка – согласовать функциональность без критериев приемки.
Фраза «система должна качественно отвечать на вопросы» непроверяема. До начала разработки нужны тестовый набор, метрики, допустимые ошибки, требования к скорости и стабильности, сценарии отказа и порядок действий человека в спорных случаях.
Приемка ИИ-системы отличается от приемки обычного ПО. Интерфейс может работать идеально, а ответы модели оставаться нестабильными. Проверять приходится всю цепочку: данные, логику обработки, качество результата, интеграции и поведение на реальных сценариях.

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

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