ИИ-трансформация: собственная разработка — мифы и реальность

Эта статья — вторая часть цикла «Три подхода к ИИ-трансформации». В первой публикации мы разобрали «подводную часть айсберга»: подготовку данных, архитектуры и процессов, без которых любая стратегия превращается в лотерею. Теперь переходим к первому из трех подходов — собственной разработке (Build).

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

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

Развенчание мифов: что на самом деле означает «построить самим»

Миф первый: «Построим сами — сэкономим на лицензиях и подрядчиках»

Логистическая компания хотела внедрить систему маршрутизации с машинным обучением. Платить несколько миллионов рублей в год за лицензии они сочли грабежом. «Наши программисты справятся не хуже, а обойдется дешевле», — решило руководство.

Полтора года спустя картина выглядела иначе. Команда постоянно отвлекалась на текущие задачи, пришлось нанять дополнительных специалистов. Любое изменение в бизнес-логике требовало программирования: новый тип груза, изменение правил доставки, учет пробок. То, что в готовом решении настраивается через интерфейс, здесь превращалось в задачу для разработчиков. Экономия превратилась в постоянные расходы на поддержку.

Этот подход редко бывает дешевле покупки. Главные причины выбрать этот путь: контроль над изменениями, уникальные требования или стратегическая важность системы для бизнеса.

Миф второй: «Наши данные уникальны, поэтому нужно строить с нуля»

Уникальность данных не означает необходимость собственной разработки. Нефтехимический холдинг был уверен, что их производственные процессы настолько специфичны, что никакая готовая система не подойдет. Но когда провели детальный анализ, оказалось, что стандартные алгоритмы мониторинга и предиктивной аналитики легко адаптируются под их оборудование через настройки и правила.

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

Этот подход оправдан, когда уникальна логика обработки данных и требуется ее частое изменение.

Миф третий: «Построим платформу — будем использовать везде, а может и продавать»

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

Успешные попытки превратить внутренний инструмент в продукт крайне редки и требуют изначального фокуса на коммерциализацию, а не попытки «монетизировать то, что получилось». Успешные внутренние платформы растут снизу вверх, начиная с одной задачи.

Три сценария, где собственная разработка действительно оправдана

Анализ успешных и провальных кейсов показывает: собственная разработка работает в трех четко определенных ситуациях.

Сценарий 1: Система как конкурентное преимущество

Признаки: ИИ-решение напрямую влияет на выручку, маржинальность или ключевые показатели качества. Логика и данные не должны уходить наружу.

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

Сценарий 2: Высокая частота изменений при строгих требованиях

Признаки: Бизнес-логика меняется чаще 8-12 раз в квартал, при этом есть жесткие требования к безопасности, аудиту или производительности.

Крупный российский банк создал собственную систему скоринга для экспресс-кредитования. Модели обновляются еженедельно на основе новых данных о мошенничестве и изменений в экономике. Готовые решения не обеспечивали нужную скорость адаптации при соблюдении требований ЦБ к объяснимости решений. Внешние подрядчики тоже не подходили — слишком высокие требования к информационной безопасности.

Сегодня банк выпускает еженедельные релизы (8–12 существенных изменений в квартал), каждый из которых проходит автоматизированную валидацию и тестирование на исторических данных. Такую скорость изменений не могла бы обеспечить ни одна внешняя команда.

Сценарий 3: Платформа для масштабирования проверенного решения

Признаки: У компании уже есть успешно работающее ИИ-решение для одной задачи, и теперь нужно применить аналогичный подход в 5-10 других областях.

Телекоммуникационная компания начала с системы предсказания оттока клиентов. Когда она доказала свою эффективность, стало понятно, что похожие подходы можно применить для оптимизации сети, планирования нагрузки, персонализации тарифов и прогнозирования спроса на новые услуги. Вместо покупки четырех разных продуктов компания создала внутреннюю платформу машинного обучения.

Ключевое отличие от неудачного примера с IT-директором — платформа выросла из реального работающего решения, а не была спроектирована «на вырост».

Скрытые затраты: о чем забывают при планировании собственной разработки

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

Стоимость команды — это только начало

Зарплата разработчиков, дата-сайентистов и DevOps-инженеров видна сразу. Но есть масса скрытых ролей: продуктовый менеджер, архитектор, специалист по информационной безопасности, эксперты по предметной области. Промышленная компания, планировавшая команду из шести человек, в итоге привлекла еще восемь специалистов — бюджет вырос в 2,3 раза.

Инфраструктура не ограничивается серверами

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

Промышленная компания потратила месяцы на настройку системы для предиктивного обслуживания. Купили серверы, но оказалось, что нужна сложная экосистема дополнительных систем. IT-отдел потратил больше времени на изучение MLOps-инструментов, чем на саму разработку алгоритмов.

Один банк потратил $200 тысяч на GPU-серверы для обучения моделей, но забыл про системы резервного копирования для терабайтов обучающих данных. Когда случился сбой, полтора месяца работы по подготовке данных пришлось повторять с нуля.

Техническое обслуживание и развитие

Модели машинного обучения не работают сами по себе. Данные меняются, бизнес-процессы эволюционируют, появляются новые требования регуляторов. Каждую модель нужно регулярно переобучать, валидировать и обновлять.

Ритейлер, построивший систему динамического ценообразования, первые два года был в восторге от результатов. На третий год эффект начал снижаться — модель перестала адаптироваться к изменившемуся поведению покупателей. Готовые решения могли бы получить обновления от вендора, но здесь всю работу пришлось делать самим.

Эмпирическое правило: планируйте тратить на поддержку и развитие ежегодно 25-30% от первоначальных затрат. Если готовы на это — собственная разработка может окупиться.

Как снизить риски при собственной разработке

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

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

Никогда не запускайте новую модель сразу на весь объем операций. Начните с 1-5% трафика, постепенно увеличивая долю при подтверждении стабильности показателей. Обязательно предусмотрите возможность мгновенного отката к предыдущей версии или ручному режиму. Энергетическая компания, внедрявшая ИИ для управления энергосетью, создала систему, которая за 30 секунд может переключиться на ручное управление при любых аномалиях в работе алгоритмов.

Одна из главных причин провала собственной разработки — команда берется за ИИ-проекты без понимания реальных потребностей и возможностей технологии. «У нас есть хорошие программисты, разберутся», — типичная ошибка руководителей. Многие успешные компании начинают не с собственной разработки, а с обучения сотрудников работе с готовыми ИИ-инструментами. Такой подход помогает команде понять возможности и ограничения ИИ, научиться формулировать требования и оценивать качество результатов. Когда приходит время создавать собственные системы, сбор бизнес-требований идет легче, а ценность ИИ-решений уже доказана.

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

To build or not to build

Похожий вопрос, который мучил принца датского в несколько иных обстоятельствах, в мире ИТ звучит не менее драматично. Неудачное решение о собственной разработке может поставить под угрозу весь бизнес — достаточно вспомнить американский маркетплейс недвижимости Zillow, который запустил программу мгновенного выкупа домов на основе собственных алгоритмов оценки. Провал этих алгоритмов привел к систематической переплате за недвижимость и убыткам в $380 миллионов, едва не обрушив успешную двадцатилетнюю компанию.

Прежде чем запускать проект собственной разработки, честно ответьте на несколько критически важных вопросов. Влияет ли система на показатели бизнеса — выручку, маржинальность, качество? Даст ли владение системой конкурентное преимущество? Готовы ли вы инвестировать в ее развитие минимум 3-5 лет?

Нужно ли выпускать существенные изменения не реже раза в неделю? Есть ли внутренние эксперты, которые могут быстро оценить качество изменений? Критична ли скорость выпуска обновлений для бизнеса?

Есть ли команда, способная поддерживать систему круглосуточно? Готовы ли вы тратить 25-30% от стоимости разработки ежегодно на поддержку? Можете ли привлечь независимую экспертизу для валидации критических решений? Предусмотрены ли поэтапный запуск, аварийное отключение и стресс-тесты?

Сможете ли применить разработанные компоненты минимум в трех других проектах? Есть ли план создания внутренней платформы на базе первого решения?

Если большинство ответов «нет» — собственная разработка с высокой вероятностью не окупится. К выбору альтернатив вернемся в следующих частях цикла.

Границы разумного: что не стоит строить самим

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

Используйте готовые решения для базовой инфраструктуры (контейнеризация, мониторинг, базы данных), фундаментальных моделей (языковые модели как основа для дообучения), стандартных модулей (OCR, распознавание речи, переводы) и универсальных платформ (ECM, BPM, BI-системы).

Тестирование ИИ-систем требует особых компетенций — от проверки качества моделей до нагрузочных тестов. Это отдельная экспертиза, которую разумно получить извне. Не стройте собственные аналоги универсальных систем «заодно» — сосредоточьтесь на том, что действительно создает конкурентное преимущество.

Заключение

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

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

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

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

В случае выбора стратегии собственной разработки заказчики привлекают внешних технических партнеров для сопровождения проектов. У FabricaONE.AI (акционер — ГК Softline) есть опыт участия в таких проектах и предоставления компаниям комплексной поддержки — от образовательных программ до консалтинговых услуг и технического аудита без вывода данных из контура и с передачей артефактов (IaC, тест-наборы, отчеты валидации).

Собственная разработка не означает полную изоляцию — наоборот, правильное сочетание внутренних ресурсов и внешней экспертизы дает наилучшие результаты.

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