Разработка ИИ под задачу бизнеса: от гипотезы до промышленной системы

Разработка ИИ — это сборка системы вокруг модели, а не обучение модели: данные, поиск по ним, оркестрация, интерфейс, наблюдаемость и права доступа. В проектах, которые я видел, на саму модель приходится меньше трети усилий, остальное — данные и интеграция с тем, что у компании уже работает. Ниже — развилка «купить готовое / собрать на API / дообучить / обучить своё», архитектура по слоям, сроки по типам решений и 12 вопросов, которые отсеивают слабого подрядчика за один звонок.

Разработка ИИ, AI-разработка и разработка с помощью ИИ — три разных проекта

За одним словом прячутся три несовместимых заказа. Разработка ИИ — это создание системы, которая принимает решение или производит результат вместо человека. Разработка с помощью ИИ — это ускорение обычной разработки ПО ассистентами и генерацией кода. AI-разработка в коммерческих предложениях означает то одно, то другое, и именно здесь заказчик и исполнитель расходятся в понимании на месяцы работы и на весь бюджет.

Я видел ситуации, где компания платила за «AI-разработку», ожидая систему принятия решений, а получала ускоренную фабрику кода: подрядчик честно сделал то, что понял. Поэтому первый артефакт любого такого проекта — не архитектура, а одно предложение о том, какой человеческий труд заменяется или усиливается.

Третья строка почти никогда не нужна коммерческой компании. Разработки в сфере ИИ такого уровня требуют вычислительных мощностей и исследовательской команды, окупаемость которых считается годами и не через P&L одного бизнеса.

Про вторую строку — как ИИ меняет разработку кода и что реально даёт AI-driven процесс: там метрики продуктивности, ограничения и ответ на вопрос, как использовать ИИ для разработки, не сломав инженерную культуру. Если ваша задача — научиться использовать ИИ в разработке ПО, вам туда. Дальше в этой статье речь идёт только о первом значении: разработка ИИ для бизнеса как инженерный проект с измеримым результатом. Разработка с использованием ИИ внутри вашей же ИТ-команды измеряется другими метриками и почти не пересекается с этим проектом ни по людям, ни по бюджету.

Ещё одно уточнение терминов. AI-разработка, искусственный интеллект и машинное обучение в тендерной документации часто стоят рядом как синонимы, хотя это разные уровни: нейросеть — способ реализации, ИИ — свойство системы, LLM — один класс моделей. Разработка, связанная с ИИ, начинается не с выбора между ними, а с описания процесса, который вы хотите изменить.

Из чего состоит разработка ИИ-решений: шесть слоёв, из которых модель — один

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

• Слой данных. Источники, права, качество, история, регулярность обновления. Здесь выясняется, что нужного поля нет ни в одной системе или что оно заполняется руками в трети случаев.
• Слой извлечения (retrieval). Индексы, разбиение документов, поиск нужного фрагмента. Без него модель отвечает по общим знаниям, а не по вашим регламентам и договорам.
• Слой модели. Готовая через API, open-source на своём сервере, дообученная под задачу или классическая ML-модель. Взаимозаменяемый слой — и это хорошая новость.
• Слой оркестрации. Правила: когда вызывать модель, когда отдать человеку, что делать при низкой уверенности, как логировать решение. Здесь живёт бизнес-логика, а не в промпте.
• Слой интерфейса. Экран в CRM, кнопка в 1С, строка в отчёте, сообщение в мессенджере. Решение, которое некуда положить, не используется.
• Слой наблюдаемости. Метрики качества, стоимость обращения, доля ручных правок, алерты на деградацию. Без него система тихо портится за два–три месяца, и никто не замечает.

Цифры выше — оценки по проектам, которые я видел и разбирал, а не отраслевая статистика. Их полезно использовать как ориентир при планировании, а не как обещание.

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

Развилка: купить готовое, собрать на API, дообучить или обучить своё

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

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

Про разницу между дообучением и промптингом — когда обучать своё, когда дообучать, а когда хватит правильно собранного контекста. В моей практике дообучение реально нужно примерно в одном проекте из пяти-шести, а заявляют о нём в каждом втором техзадании.

Типы ИИ-решений: что именно вы собираетесь построить

Коммерческая разработка ИИ сводится к семи типам решений, и каждый требует своего типа данных и своей метрики качества. Смешение типов в одном ТЗ — частая причина, по которой проект не сдаётся: «умный помощник» внутри оказывается четырьмя разными системами с четырьмя разными сроками.

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

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

Разработка ИИ-моделей и разработка ИИ-систем — разные профессии

Разработка ИИ-модели — это получение алгоритма, который выдаёт предсказание с нужной точностью на тестовой выборке. Разработка ИИ-системы — это обеспечение того, что предсказание доходит до сотрудника вовремя, в понятном виде, с логом и с возможностью отката. Первое умеет data scientist, второе — инженерная команда, и подмена одного другим стоит проекту квартала.

Модель без процесса — это дорогой прогноз, который некому исполнить.Владимир Герасимов

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

Стек и среда разработки: на чём это собирают

Стандартный стек разработки ИИ на 2026 год — Python на стороне моделей, привычный бэкенд компании на стороне сервиса и одна база с векторным индексом для поиска по документам. Область AI-разработки за последние два года заметно стандартизовалась, и экзотика в этом слое почти всегда означает, что подрядчик решает свою задачу, а не вашу: чем скучнее стек, тем дешевле его поддерживать вашей же ИТ-службе через год.

• Язык и библиотеки. Разработка ИИ на Python — отраслевой стандарт: экосистема, кадры, примеры. Обучение классических моделей — на табличных библиотеках, работа с LLM — через SDK провайдера или локальный сервер инференса.
• Хранение и поиск. Обычная реляционная база плюс векторный индекс. Отдельная специализированная база нужна, когда объём документов идёт на миллионы, а не на тысячи.
• Оркестрация данных. Планировщик задач и версионирование датасетов. Без версий вы не воспроизведёте результат через три месяца и не докажете, почему система приняла именно такое решение.
• Среды. Три контура: разработка, тест на реальных данных с маскированием, промышленный. Без тестового контура на боевых данных приёмка превращается в спор о вкусе.
• Наблюдаемость. Логи каждого обращения с версией промпта и модели, стоимость, задержка, доля обращений с ручной правкой.

Бесплатные ИИ для разработки: где они уместны, а где опасны

Бесплатные ИИ для разработки — это open-source модели и бесплатные тарифы облачных провайдеров, и на этапе проверки гипотезы они полностью закрывают задачу. Прототип на бесплатных инструментах даёт ответ на главный вопрос — «получается ли требуемое качество в принципе» — за дни и без закупочных процедур.

Опасность начинается при переносе прототипа в продакшен. Бесплатный тариф не даёт гарантий доступности, лимиты меняются, а лицензия open-source модели может запрещать коммерческое использование или требовать раскрытия. Перед тем как строить на бесплатном компоненте выручку, проверьте лицензию, лимиты и путь миграции — это тридцать минут работы юриста против переписывания сервиса.

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

Про то, как ИИ в разработку интегрировать так, чтобы он жил внутри 1С, Битрикс24, CRM или ERP, а не рядом с ними, — способы подключения, локальные модели и контур безопасности. Это отдельный и самый недооценённый по трудоёмкости слой проекта.

Как поставить задачу: ТЗ, которое можно проверить

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

1. Процесс и его цифраКакой процесс меняется, кто его владелец, какой показатель должен сдвинуться: время обработки, доля ошибок, стоимость обращения, конверсия.
2. Тип задачиКлассификация, прогноз, извлечение, генерация, рекомендация, зрение или речь. Один тип — один блок ТЗ.
3. Данные и праваИсточники, объём, глубина истории, кто владелец, что можно выносить за периметр, что нельзя ни при каких условиях.
4. Эталонная выборка100–300 реальных случаев с правильными ответами, подготовленных заказчиком. Это главный документ проекта: на нём считается приёмка.
5. Порог приёмкиЦифра, при которой решение считается принятым, и цифра, при которой процесс возвращается человеку.
6. Сценарии отказаЧто происходит при недоступности модели, при низкой уверенности, при подозрении на ошибку. Кто и как узнаёт об инциденте.
7. Передача и поддержкаКому передаются исходники, доступы, паспорт решения; кто отвечает за качество через полгода и по какому регламенту.

Эталонная выборка решает больше половины споров на приёмке. Её нельзя делегировать подрядчику: если исполнитель сам придумывает правильные ответы, он сдаёт себе свою же работу. Собирает её предметный эксперт заказчика — обычно за 2–5 рабочих дней.

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

Как выбрать компанию для разработки ИИ: 12 вопросов подрядчику

Разработка ИИ компанией-подрядчиком отличается от обычной ИТ-разработки тем, что результат вероятностный: гарантировать точность до начала работы с данными нельзя. Поэтому выбор исполнителя — это проверка не портфолио, а того, как он ведёт себя в неопределённости. Двенадцать вопросов ниже я задаю на первом же звонке, и они закрывают тему быстрее, чем презентация на сорок слайдов.

1. На каких данных вы будете обучать или настраивать решение и что делаете, если нужных данных у нас нет?
2. Как вы измеряете качество и на какой выборке — вашей или нашей?
3. Какой порог точности вы готовы зафиксировать в договоре после этапа исследования данных?
4. Что происходит с проектом, если после аудита данных задача окажется нерешаемой в заявленной постановке?
5. Кто в вашей команде отвечает за интеграцию, а кто за модель? Это одни и те же люди?
6. Какие данные уходят за периметр компании и куда именно; возможен ли полностью локальный контур?
7. Кому принадлежат исходный код, промпты, датасеты и дообученные веса после сдачи?
8. Как выглядит стоимость эксплуатации в месяц при нашем объёме обращений и от чего она растёт?
9. Что вы передаёте нашей ИТ-службе, чтобы поддерживать решение без вас?
10. Покажите проект, где вы не получили нужного качества. Что вы сделали и чем закончилось?
11. Какой минимальный кусок работы вы готовы сделать первым, чтобы мы проверили друг друга?
12. Кто конкретно будет работать в проекте и какая доля их времени в нём занята?

• Точность обещана в процентах до знакомства с вашими данными.
• Ответ на вопрос про неудачный проект — «у нас таких не было».
• Договор без критерия приёмки: сдача «по факту демонстрации работоспособности».
• Права на дообученные веса и датасеты остаются у исполнителя.
• Слово «интеграция» в смете отсутствует или занимает менее десятой части бюджета.
• Команда «подберётся после подписания».

Профильные AI-компании, разработка у которых поставлена на поток, отвечают на эти вопросы без пауз и обычно сами предлагают начать с оплачиваемого аудита данных на 2–4 недели. Это хороший знак: исполнитель защищает себя от невыполнимого обязательства, а вас — от контракта на решение, которое не взлетит.

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

Своя команда или разработка ИИ на заказ

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

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

Сроки: сколько занимает разработка ИИ по типам задач

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

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

Если решение предполагает автономность и цепочку действий, а не один ответ, сроки другие и риски другие — чем ИИ-агент отличается от ассистента и что ломается при передаче ему прав в процессах.

Почему «разработка ИИ с нуля» почти всегда ошибка — и что делать вместо неё

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

• Собственная модель устаревает за 6–12 месяцев, и её нужно переобучать за свой счёт, пока рынок обновляет открытые модели бесплатно.
• Команда исследователей стоит как отдел, но не производит выручку напрямую — её приходится защищать на каждом бюджетном комитете.
• Данных нетехнологической компании обычно хватает на дообучение, но не на обучение с нуля: разница в объёме — порядки.
• Пока идёт обучение своей модели, конкурент запускает третий контур на готовой и собирает обратную связь от пользователей.

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

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

Компании обычно проигрывают не потому, что выбрали не ту модель, а потому, что выбрали не тот процесс.Владимир Герасимов

С чего начать на этой неделе

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

1. Выпишите пять процессовТе, где люди делают однотипную работу с текстом, документами, заявками или прогнозами. Для каждого — объём операций в месяц и стоимость одной.
2. Оцените цену ошибкиГде ошибка стоит денег или клиента, там ИИ окупается быстрее и там же жёстче требования к контролю.
3. Проверьте данныеЕсть ли история за 1–3 года, в одной ли системе, заполняется ли поле руками. Процесс без данных отправляется в конец очереди.
4. Соберите эталонную выборку100–300 реальных случаев с правильными ответами по выбранному процессу. Это займёт несколько дней и станет основой любого договора.
5. Посчитайте потолок эффектаДаже при идеальной работе системы — сколько это рублей в год. Если меньше стоимости годовой эксплуатации, процесс не тот.
6. Выберите сценарий из четырёхКупить, собрать на API, дообучить, обучить своё — по таблице выше, а не по презентации подрядчика.

Дальше — либо внутренняя команда, либо разработка ИИ на заказ. Что происходит после запуска и почему четыре пилота из пяти не доходят до прибыли, я разбирал в материале о внедрении ИИ на языке P&L. Разработка AI-решений без этого разговора превращается в покупку технологии ради технологии — а это самая дорогая из возможных покупок.

Частые вопросы

Сколько стоит разработка ИИ для бизнеса?

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

Структуру бюджета и формулу расчёта эффекта я разбираю в материале о стоимости внедрения ИИ и ROI.

Есть ли бесплатные ИИ для разработки и можно ли собрать систему на них?

Да: бесплатные ИИ для разработки — это open-source модели и бесплатные тарифы облачных провайдеров, и на этапе прототипа они закрывают задачу полностью. Проблемы начинаются в продакшене: бесплатный тариф не даёт гарантий доступности, лимиты меняются, а лицензия открытой модели может ограничивать коммерческое использование. Проверяйте лицензию, лимиты и путь миграции до того, как строить на бесплатном компоненте выручку.

Чем разработка ИИ-моделей отличается от разработки ИИ-систем?

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

Нужна ли разработка собственного ИИ, если есть готовые модели?

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

Сколько времени занимает разработка ИИ на заказ?

Первый работающий контур — от 3 до 16 недель в зависимости от типа задачи: классификация быстрее, компьютерное зрение и рекомендации дольше. До промышленной эксплуатации с интеграцией, правами и мониторингом обычно проходит 4–7 месяцев. Главный множитель срока — состояние данных, а не сложность модели: несогласованные справочники в двух системах добавляют к проекту месяц-полтора.

Как выбрать компанию для разработки ИИ и не ошибиться?

Разработка ИИ компанией-подрядчиком проверяется не портфолио, а поведением в неопределённости: спросите, на каких данных будет настраиваться решение, на чьей выборке измеряется качество, какой порог точности исполнитель готов зафиксировать после аудита данных и кому принадлежат код, промпты и дообученные веса. Хороший признак — предложение начать с оплачиваемого аудита данных на 2–4 недели. Плохой — обещание процентов точности до знакомства с вашими данными и смета, где интеграция занимает менее десятой части бюджета.

Какие данные нужны, чтобы начать разработку ИИ-решений для компаний?

Минимум — эталонная выборка из 100–300 реальных случаев с правильными ответами, подготовленная предметным экспертом заказчика: на ней считается приёмка. Для прогнозных задач нужна история за 2–3 года с сохранённым контекстом, для классификации — от одной до пяти тысяч размеченных примеров, для извлечения данных — сотни образцов документов всех встречающихся форм. Если нужного поля нет ни в одной системе или оно заполняется свободным текстом, сначала решается это, а не выбор модели.

Можно ли ИИ в разработку интегрировать без замены текущих систем?

Да, и это стандартный сценарий: ИИ-сервис подключается к 1С, CRM, ERP или сайту через API и работает как ещё один источник данных и подсказок, не заменяя учётную систему. Локальный контур используется, когда данные нельзя выносить за периметр: тогда модель разворачивается на своих серверах. Способы подключения и типовые ошибки разобраны в статье об интеграции ИИ в существующие системы.

Как ИИ меняет разработку ПО и нужно ли команде этому учиться?

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

Читать дальше

ИИ-агенты и ассистенты для бизнеса

Чем агент отличается от чат-бота, где он окупается, как устроен внутри и что ломается при внедрении в процессы.

Интеграция ИИ в существующие системы

1С, Битрикс24, CRM, ERP, сайт, Excel. Способы подключения, локальные модели, контур безопасности и типовые ошибки.

Внедрение ИИ в бизнес

Что такое внедрение ИИ на языке P&L, почему четыре пилота из пяти не доходят до прибыли и как выбрать первый процесс.

ИИ для разработки ПО и инженерии

Как ИИ меняет разработку кода, сайтов, приложений и игр. AI-driven процесс, метрики продуктивности, инженерные ограничения.

Стоимость внедрения ИИ и расчёт ROI

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

Внедрение нейросетей

Нейросеть, ИИ, LLM — что чем является. Когда обучать своё, когда дообучать, когда хватит промпта.