Разработать ИИ-решение или купить готовое: как выбрать

Как только задача для ИИ выбрана, возникает вопрос: покупать готовый сервис, дорабатывать платформу или строить своё решение. Ошибка в любую сторону стоит дорого. Своя разработка там, где есть зрелый рынок, съедает год и команду. Готовый продукт там, где задача уникальна, даёт средний результат и зависимость от поставщика. Ниже – как это решение принимают компании, у которых получилось.

Анализ внедрений из открытой базы кейсов ИИ на platforms.su, где собрано более 1300 кейсов, показывает, что выбор определяется не размером компании, а типом задачи.

Типовые задачи с проверенным рынком – готовое решение

Задача: анализ медицинских снимков, распознавание документов, речевая аналитика, контроль выкладки, видеоаналитика безопасности. Здесь готовые сервисы уже обучены на больших объёмах данных и проверены у десятков заказчиков. Компании закупают их по подписке или через отраслевые витрины решений, а основные затраты несут на интеграцию со своими системами. Срок запуска – недели и месяцы, а не годы. Облачная речевая аналитика, например, в кейсах снижает стоимость обработки минуты звонка в разы по сравнению с прежними решениями.

Ассистенты по внутренним знаниям – платформа плюс свои данные

Задача: ответы сотрудникам по регламентам, продуктам, нормативке. Технологию (LLM и поиск по документам) берут готовой у поставщика платформы, а ценность создаёт собственная база знаний и настройка под процесс. Своя работа – подготовка документов, проверка качества ответов, встраивание в рабочее место. В кейсах банков и промышленности такие ассистенты окупаются за счёт сокращения времени поиска информации в разы.

Ядро бизнеса и уникальные данные – своя разработка

Задача: антифрод, ценообразование, рекомендации, управление ценностью клиента, оптимизация технологических режимов. Здесь модель напрямую определяет выручку или потери, а данные есть только у компании. Банки, операторы связи и крупные промышленные холдинги строят такие решения сами и развивают их годами. Готовый продукт здесь не даёт конкурентного преимущества.

Замена ушедшего зарубежного ПО – по ситуации

Задача: восстановить функциональность систем, поддержку которых прекратил иностранный поставщик. Часть компаний перешла на российские аналоги, часть сделала своё. В одном из промышленных кейсов собственное ML-решение запустили за три месяца против обычных для отрасли 12–18 месяцев внедрения коробочной системы. Это сработало, потому что у компании была своя команда и глубокое знание процесса.

Оборудование и роботы – сервисная модель

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

• Даёт ли решение конкурентное преимущество. Если задача одинакова у всех компаний отрасли, своя разработка редко оправдана. Если от модели зависит то, чем компания отличается от конкурентов, стоит развивать собственные компетенции.
• Есть ли зрелый рынок. Пять и более поставщиков с внедрениями у похожих заказчиков – сильный аргумент в пользу готового решения.
• Есть ли своя команда. Своя разработка требует не только создания модели, но и её сопровождения годами. Небольшая команда может закрыть узкую задачу: в одном из кейсов систему распознавания для полевых сотрудников сделали силами одного разработчика. Но платформа для десятков сценариев требует постоянной команды.
• Требования к данным и контуру. Если данные нельзя выносить за периметр, круг готовых облачных сервисов сужается, и выбор смещается к решениям для установки в собственной инфраструктуре.
• Риск зависимости. Опыт ухода зарубежных поставщиков сделал этот критерий для многих компаний главным. Важно не только кто поставщик, но и можно ли забрать модель, данные и настройки.
• Стоимость владения за 3–5 лет. Подписка кажется дешёвой на старте, но растёт с объёмом. Своя разработка дорога на старте, но может обходиться дешевле на масштабе. Компании, отказавшиеся от внешних лицензий в пользу своих платформ, в кейсах экономят десятки миллионов рублей в год.

• Строить своё ради статуса. Собственная LLM или своя платформа агентов без чёткой бизнес-задачи – дорогой эксперимент.
• Выбирать по демонстрации. Демо на данных поставщика ничего не говорит о работе на данных заказчика. Нужен пилот на собственном потоке.
• Выбирать модель по публичным рейтингам. Тестирование на собственных задачах регулярно показывает, что небольшие открытые модели справляются с узкими задачами не хуже крупных, а стоят в эксплуатации в разы дешевле.
• Не учитывать интеграцию. У готового решения сама модель часто стоит меньше, чем встраивание в учётные системы и рабочие места.
• Не прописывать в договоре права на данные и модель. Без этого смена поставщика означает старт с нуля.

1. Определить задачу и показатели. Что именно должен делать ИИ, какой эффект ожидается, какие ограничения по данным и безопасности.
2. Оценить стратегическую значимость. Является ли задача источником отличия от конкурентов или это типовая операция.
3. Провести обзор рынка. 5–10 поставщиков, внедрения у похожих заказчиков, модель поставки: облако, установка у себя, сервис.
4. Оценить свои возможности. Есть ли команда, данные, инфраструктура и готовность сопровождать решение годами.
5. Посчитать стоимость владения. Сравнить 2–3 варианта на горизонте 3–5 лет, включая интеграцию, вычисления, поддержку и выход из договора.
6. Провести короткий пилот. 2–3 варианта на одних и тех же реальных данных, с одинаковыми критериями оценки.

• У каких заказчиков с похожими задачами и данными решение работает в промышленном режиме?
• Можно ли развернуть решение в нашем контуре и что для этого потребуется?
• Кому принадлежат дообученная модель, настройки и результаты обработки данных?
• Как изменится стоимость при росте объёма в 5–10 раз?
• Что будет, если поставщик прекратит поддержку, и как мигрировать на другое решение?
• Сколько людей нужно для сопровождения своей разработки через два года после запуска?
• Какие доработки поставщик готов сделать под наш процесс и на каких условиях?

Типовые задачи выгоднее закрывать готовыми решениями и тратить силы на интеграцию. Задачи, которые определяют отличие от конкурентов, стоит строить самим или на открытых моделях, сохраняя контроль над данными. Центр компетенций ИИ помогает сравнить варианты, провести пилот на реальных данных и проверить договор с поставщиком.