Создать работающий прототип искусственного интеллекта сегодня значительно проще, чем довести его до промышленного внедрения. Современные модели позволяют быстро показать убедительный результат, однако именно после успешного пилота начинается самая сложная часть работы. На основе опыта разработки AI-решений для медицины и юриспруденции я разберу, почему многие проекты так и не становятся полноценными продуктами и какие ошибки чаще всего приводят к этому.
По данным McKinsey «Global Survey 2025», 88% респондентов сообщили, что в их организации регулярно используют AI хотя бы в одной бизнес-функции. При этом почти две трети организаций ещё не начали масштабировать AI на уровне всей компании. Лишь 39% респондентов сообщили о влиянии AI на EBIT на уровне всей организации.
Этот разрыв показателен. Ограничением всё реже становится техническая реализация AI-модели. Основные проблемы начинаются после того, как модель впервые выдала правильный ответ.
Похожая картина видна и в российских данных. В исследовании ИСИЭЗ НИУ ВШЭ «Применение искусственного интеллекта в российских компаниях» отмечается, что среди организаций, использующих ИИ, значимыми барьерами остаются не только затраты, но и инфраструктура, нехватка квалифицированных кадров, дефицит данных, сложность интеграции ИИ в бизнес-процессы, законодательные ограничения и качество данных.
Пилот должен доказать не только техническую возможность, но и три более важные вещи: организация готова платить за продукт, пользователи хотят его применять и решение можно встроить в реальный процесс без потери всей ожидаемой экономии. Если хотя бы одно из этих условий не выполнено, даже сильный ИИ рискует остаться демонстрацией.
Главная причина неудачи большинства AI-проектов — не слабая модель, а разрыв между демонстрацией технологии и ее использованием в реальном рабочем процессе.
Демо оптимизирует ответ, бизнес — весь процесс
На демонстрации AI-продукт обычно получает подготовленные данные и за несколько секунд может сформировать хорошее впечатление. На этом фоне легко решить, что основная часть задачи уже выполнена. Но ответ модели — только один этап рабочего процесса. После него результат необходимо проверить, исправить, согласовать, сохранить в корпоративной системе и использовать для принятия решения. До обращения к модели данные также нужно найти, подготовить и передать в подходящем формате.
Поэтому локальное ускорение одной операции не гарантирует ускорения процесса целиком.
AI ускоряет отдельную операцию. Бизнес оценивает, насколько быстрее завершился весь процесс. Именно здесь чаще всего возникает разрыв между успешным пилотом и реальным внедрением.
Похожий эффект виден в разработке ПО. Исследование NBER по более чем 100 тыс. GitHub-разработчиков показало, что для автономных AI-инструментов рост coding activity составил около 180%, но рост фактически выпущенных релизов — только около 30%. Авторы объясняют разрыв последующими человеческими и производственными ограничениями: проверкой, интеграцией и выпуском.
С похожей ситуацией я сталкивался при разработке AI-решений для медицины и юриспруденции. Даже когда модель демонстрировала высокое качество на тестовых сценариях, этого было недостаточно для внедрения. Основная работа начиналась после получения ответа модели: нужно было встроить систему в существующие процессы, сократить объем ручной проверки и сделать так, чтобы использование AI действительно экономило время специалиста, а не создавало новые этапы работы.
Для отраслевого AI действует тот же принцип. Система может подготовить документ за минуту, но специалисту потребуется значительно больше времени, чтобы проверить факты, источники и применимость результата. Она может предложить решение, которое затем придётся вручную переносить в другую информационную систему. Она может ускорить работу одного сотрудника и одновременно создать дополнительную очередь у следующего участника процесса. Поэтому заказчика интересует не скорость первого ответа, его интересует время до завершенного и проверенного результата.
Перед началом разработки полезно ответить на несколько вопросов: какое действие пользователя должно измениться, какой этап процесса исчезнет или сократится, сколько времени займет проверка, что произойдёт после получения ответа и не возникнет ли новое узкое место дальше по цепочке.
Позднее вовлечение пользователей создает мертворожденные продукты
Одна из самых распространённых ошибок — подключать будущих пользователей только на этапе пилота. Эта ошибка встречается и в начинающих стартапах, и во внутренних командах крупных компаний. Разработчики несколько месяцев создают решение, исходя из собственного представления о работе врача, юриста, бухгалтера, инженера, оператора или менеджера.
На демонстрации всё выглядит убедительно. Данные подготовлены, сценарий заранее выбран, сложные случаи исключены или специально подобраны такие, с которыми решение справляется. Но когда продукт впервые попадает к специалисту, возникают базовые вопросы.
Как вообще пользоваться решением? Как оно будет интегрировано в привычные рабочие инструменты? На чем основан ответ системы? Откуда должны поступать данные? Что делать с ответом? Почему новый сценарий лучше привычного? Кто отвечает, если результат окажется неверным? Будет ли у специалиста время проверять вывод модели?
Если эти вопросы появляются в конце разработки, команда проверяет продуктовую гипотезу слишком поздно. Так возникает демонстрационный долг: набор неподтвержденных предположений о поведении пользователя, данных, интеграциях и ответственности. Чем дольше команда строит продукт, не проверяя эти предположения, тем дороже становится их пересмотр.
Обратная связь специалиста нужна не после создания MVP, а до выбора основного сценария. Недостаточно провести интервью и попросить пользователя перечислить проблемы. Полезнее наблюдать за реальной работой: какие системы он открывает, где копирует данные, что перепроверяет, кому передает результат и в каких случаях действует в обход официального процесса, где сейчас узкое горлышко.
В профессиональных областях пользователь не просто оценивает удобство интерфейса. Он помогает определить саму логику продукта: какие данные обязательны, какие исключения критичны, когда автоматизация допустима, где нужен контроль человека и какие ошибки нельзя пропустить.
Поэтому участие пользователя не должно превращаться в бесконечный сбор пожеланий. Команда должна проверять конкретные гипотезы: возникает ли проблема достаточно часто, меняет ли прототип поведение специалиста, возвращается ли он к продукту без напоминаний, готов ли использовать его на реальных данных и становится ли процесс быстрее или качественнее после проверки результата.
Если ответы отрицательные, продукт нужно менять, а не дополнять новыми функциями. На старте важнее не пытаться создать идеального ИИ-юриста, врача или бухгалтера, а качественно закрыть одну актуальную задачу и только после успешного MVP расширять функциональность. Иначе команда рискует создать продукт-Франкенштейн: он претендует на решение всего сразу, но по факту не закрывает достаточно хорошо ни один сценарий.
На раннем этапе гораздо ценнее решить одну повторяющуюся задачу лучше существующих инструментов, чем пытаться автоматизировать весь процесс сразу. Именно так появляются продукты, которыми специалисты начинают пользоваться каждый день.
Пользователь, эксперт и покупатель — не один человек
Для вертикального AI-продукта недостаточно найти отраслевого эксперта.
На практике я быстро убедился, что понимание профессиональной задачи — только часть работы. Даже если специалисты высоко оценивают решение, это еще не означает, что оно будет внедрено. Для появления продукта в организации должны совпасть интересы сразу нескольких участников процесса.
Эксперт помогает понять процесс, профессиональные требования и цену ошибок. Но он не обязательно распоряжается бюджетом и может не влиять на закупку.
В сложных B2B-продажах вокруг продукта обычно возникает несколько ролей: специалист, который будет им пользоваться; эксперт, помогающий его проектировать; внутренний сторонник, продвигающий решение; владелец бюджета; лицо, подписывающее договор; ИТ и информационная безопасность; юридическая служба и закупки.
Команда может сделать отличный продукт для пользователя, но не иметь доступа к покупателю. В этом случае продажи не начнутся. Обратная ситуация тоже возможна: руководитель видит экономический смысл и готов приобрести решение, хотя часть специалистов относится к нему скептически. Такой сценарий может привести к первому контракту, но не гарантирует регулярного применения.
Первая продажа и устойчивое внедрение — разные задачи. Лицо, принимающее решение, определяет вероятность контракта. Пользователь определяет вероятность регулярного использования, измеримого результата и продления. Продать AI-продукт и добиться его ежедневного использования — две разные задачи. Первый контракт подтверждает интерес рынка. Регулярная работа пользователей подтверждает ценность продукта.
Поэтому до создания полноценного MVP команде полезно составить карту участников: кто испытывает проблему, кто будет пользоваться системой, кто получает экономический эффект, кто выделяет бюджет, кто может заблокировать внедрение и через какой контакт можно выйти на организацию.
В узких B2B- и B2G-сегментах человек, умеющий открывать двери к нужным лицам, иногда решает половину коммерческой задачи. Хороший продукт без канала выхода на покупателя может годами оставаться экспериментом.
Считать нужно стоимость проверенного результата
Экономику AI часто оценивают через стоимость модели и время генерации. Для профессиональных продуктов этого недостаточно. Полная стоимость операции включает получение и подготовку данных, работу модели, проверку человеком, исправление результата, перенос в рабочую систему и ожидаемую стоимость возможных ошибок. Для бизнеса важна не стоимость работы модели, а стоимость получения проверенного результата. Именно этот показатель определяет экономический эффект внедрения.
Особенно важна стоимость проверки. Если специалисту нужно заново прочитать все источники, чтобы убедиться в правильности подготовленного анализа, продукт может почти не экономить время. Если пользователь после автоматической обработки данных вынужден заново собирать структуру результата, автоматизация создает дополнительную работу.
Средняя точность модели здесь тоже мало говорит об экономике. Десятипроцентная доля ошибок может быть приемлемой, если ошибки легко заметить и дёшево исправить. Она может быть недопустимой, если результат выглядит убедительно, ошибка обнаруживается поздно и влияет на последующие решения.
В профессиональных процессах особенно опасны ошибки, которые не выглядят как ошибки. Пользователь видит аккуратно оформленный текст, таблицу или рекомендацию и тратит меньше внимания на проверку. В результате риск смещается с этапа генерации на этап принятия решения.
Поэтому полезнее измерять не только точность модели, но и продуктовые показатели: время до проверенного результата, долю ответов, потребовавших исправления, частоту критических пропусков, долю результатов, принятых пользователем, долю случаев, переданных человеку, и стоимость одного полностью завершенного случая.
Отдельно важно раскладывать процесс на этапы. Недостаточно сказать, что AI-автоматизация улучшила работу специалиста. Нужно понимать, сколько ресурсов уходит на подготовку данных, поиск релевантной информации, проверку источников, формирование итогового ответа, перенос результата в рабочую систему и последующую коммуникацию.
Но сами метрики мало что дают, если процесс рассматривается как единая неделимая задача. Его нужно раскладывать на отдельные операции: подготовку документов, поиск релевантной информации, перепроверку источников, формирование итогового ответа, перенос данных в рабочую систему и последующую коммуникацию.
Такая декомпозиция позволяет понять, какой именно участок ИИ действительно улучшает, а где эффект теряется. Иногда оказывается, что на первом этапе не нужно автоматизировать всю цепочку. Более сильной продуктовой гипотезой может быть узкое решение, которое качественно закрывает один дорогой этап, например, поиск и структурирование релевантной информации для специалиста, оставляя финальный вывод или коммуникацию человеку.
Поэтому главный вопрос для разработчиков должен звучать не «насколько хорошо модель отвечает?», а «насколько качественно и надежно система закрывает выбранный участок реальной задачи и делает ли это выгоднее текущего процесса?»
Пилот должен проверять организацию, а не только технологию
У пилота почти всегда более благоприятные условия, чем у будущего продукта. В нём участвуют мотивированные пользователи, команда разработчиков быстро помогает при сбоях, данные можно подготовить вручную, нестандартные случаи временно исключаются, интеграции заменяются переносом информации между системами. Такой пилот может подтвердить техническую гипотезу, но ничего не сказать о готовности к эксплуатации.
За последние несколько лет я пришел к выводу, что пилот проверяет не столько технологию, сколько готовность организации изменить собственные процессы. Если компания не готова встроить новое решение в ежедневную работу, даже успешная демонстрация не приведет к масштабному внедрению.
Промышленное внедрение требует ответов на другие вопросы: кто отвечает за результат, как система получает реальные данные, как управляются права доступа, кто устраняет сбои, как обучаются новые сотрудники, из какого бюджета оплачивается эксплуатация, что происходит после обновления модели и по каким критериям решение масштабируется или закрывается. Именно эти вопросы часто оказываются важнее качества демонстрации.
Российский аналитический доклад «Индекс готовности приоритетных отраслей экономики Российской Федерации к внедрению искусственного интеллекта» рассматривает готовность к ИИ не только через наличие технологий, но и через нецифровые факторы: государственную политику, регулирование, стратегическое планирование, корпоративное управление, кадры и компетенции, исследования и разработки. Отдельно учитываются цифровые основы: инфраструктура, данные, доверие и безопасность.
На практике это означает, что зрелость AI-проекта определяется всей системой вокруг модели: процессами, ответственностью, инфраструктурой и готовностью сотрудников использовать новый инструмент.
Отдельная проблема — интеграции. Во многих отраслях рабочий процесс уже распределен между несколькими системами. Если AI-инструмент требует от пользователя копировать данные между окнами, вручную переносить результат и отдельно проверять источники, часть экономии исчезает. Кроме того, у разных клиентов могут быть разные вендоры внутрикорпоративных систем. В таком случае именно вопрос интеграции может стать главным узким горлышком всего проекта.
Важно вовремя признать неверную гипотезу
После нескольких кварталов разработки команде становится сложно отказаться от продукта. Уже потрачен бюджет, руководству обещан результат, подготовлены презентации, участники проекта связали с ним свою профессиональную репутацию.
С этой ситуацией сталкиваются и стартапы, и крупные компании. Чем больше времени и ресурсов вложено в проект, тем сложнее объективно оценить, действительно ли он решает проблему пользователя или команда продолжает развивать его по инерции.
Если видно, что продукт не находит ожидаемого рыночного спроса, вместо признания ошибки иногда начинается поиск любого подразделения или внешнего клиента, которому можно предложить уже созданное решение. Команда перестает искать продукт под проблему и начинает искать проблему под продукт. Продажа в таком случае становится способом оправдать предыдущую работу, но необходимо различать проблемы выхода на рынок и отсутствие самой потребности. Самая дорогая ошибка в AI — не отказаться от неверной гипотезы вовремя.
Если специалисты регулярно используют решение, самостоятельно возвращаются к нему и готовы мириться с несовершенствами, но компания не может выйти на владельца бюджета, вероятно, проблема находится в продажах.
Если пользователь открывает продукт только по просьбе команды, не меняет привычный процесс и не замечает его улучшения, проблема, скорее всего, находится в продуктовой гипотезе.
Если покупатель заинтересован, но стоимость интеграции превышает ожидаемый эффект, нужно менять архитектуру или целевой сегмент.
Чтобы не принимать решения под влиянием уже понесенных затрат, проект полезно разделить на последовательные проверки.
Первая проверка — проблема. Подтверждена ли она реальным поведением, а не только интервью?
Вторая — пользователь. Становится ли его работа лучше после проверки результата? Продолжает ли он пользоваться продуктом без напоминания?
Третья — покупатель. Существует ли владелец бюджета и понятный мотив для покупки?
Четвертая — экономика. Сокращается ли полная стоимость процесса? Повышается ли итоговая ценность результата?
Пятая — эксплуатация. Способна ли организация поддерживать решение без постоянного участия команды разработки? Как и на каких условиях будет осуществляться дальнейшее взаимодействие покупателя и разработчика?
После каждого этапа должно оставаться три равноправных варианта: продолжить развитие продукта, изменить направление или остановить проект. Отказ от первоначальной гипотезы — это не поражение, а результат качественной проверки идеи.
На практике успех AI-проекта определяется не тем, насколько быстро команда обучила модель, а тем, насколько рано она получила честные ответы на ключевые вопросы: существует ли проблема, готовы ли специалисты менять свои рабочие процессы, увидит ли бизнес экономический эффект и сможет ли организация поддерживать решение после внедрения.
Именно поэтому главный показатель зрелости AI-команды сегодня — не количество разработанных моделей, а способность вовремя отказаться от неверных предположений и сосредоточиться на задачах, которые действительно создают ценность для пользователей и бизнеса.
Путь от AI-пилота до востребованного продукта начинается не с обучения модели, а с понимания задачи, которую действительно необходимо решить.
