Сколько стоит разработка ИИ-решения и почему смета «зависит»
Когда фаундер спрашивает, сколько стоит разработка ИИ-решения, честный инженер отвечает «зависит», и это раздражает. Смета плывёт, пока размыты границы задачи: объём данных, число интеграций, планка качества, нужда в дообучении и формат поддержки. Зафиксируйте границы — и «зависит» превратится в диапазон. Сама языковая модель весит в этой сумме меньше всего.
Короткий ответ: «зависит» означает размытый scope
Слово «зависит» звучит как уклонение, хотя за ним стоит честная инженерия. Цена разработки собирается из объёма работы, а объём работы задаёте вы сами через границы задачи. Пока эти границы плавают, любая цифра — гадание. Подрядчик, который называет точную сумму до разговора о ваших данных и системах, либо угадывает вслепую, либо прячет в смете огромный запас на собственные риски.
Разница между этим разбором и общим разговором про факторы цены в том, что здесь я смотрю на саму разработку: что инженер собирает руками, сколько связок проектирует и тестирует, где проходит граница между «готовым решением» и «вечной стройкой». Дальше я покажу, какие пять вводных превращают «зависит» в конкретный диапазон и как зафиксировать их так, чтобы смета перестала плыть.
Почему инженер честно отвечает «зависит»
В работе с фаундерами я регулярно вижу одну и ту же сцену. Человек описывает задачу одной фразой — «хочу, чтобы ИИ обрабатывал заявки» — и ждёт цифру в ответ. За этой фразой прячется десяток развилок: сколько заявок в день, в каком виде они приходят, куда писать результат, какая цена ошибки, кто проверяет спорные случаи. Каждая развилка двигает объём разработки, и пока они открыты, сумма честно остаётся диапазоном от скромного до серьёзного.
Размытая постановка работает против вас дважды. Сначала она мешает получить честную цифру, потому что инженер закладывает запас на туман. Потом она же ломает приёмку: вы ждали одно, подрядчик сделал другое, и спор о том, что входило в работу, тянется неделями. Поэтому первый шаг к понятной смете лежит в фиксации границ, и делать его выгоднее вам, чем подрядчику.
Есть и обратная сторона честного «зависит». За ним стоит инженер, который уже мысленно прошёл вашу задачу до краевых случаев и понял, что под одной фразой прячется три разных проекта с разной ценой. Подрядчик, который выпаливает сумму за десять секунд, пропустил вопрос о ваших данных и потом будет добирать деньги через дополнительные счета. Вопрос «зависит от чего именно?» отделяет инженера, который думает о вашем результате, от продавца, который думает о подписанном договоре.
Пять вводных, которые превращают «зависит» в диапазон
Разработка решения собирается слоями, и каждый слой можно сделать тонким или толстым. Я держу в голове пять вводных и проверяю их на первом же созвоне, потому что они задают вилку точнее, чем абстрактная «сложность проекта». Когда фаундер приходит с ответами на эти пять вопросов, разговор о бюджете перестаёт быть гаданием за минуту.
| Вводная | Как она двигает цену разработки |
|---|---|
| Объём и состояние данных | Чистая структурированная выгрузка — узкая задача. Разрозненные письма, дубли и таблицы в разных форматах требуют недель сбора и разметки через RAG ещё до первого запроса к модели. |
| Число интеграций | Решение, которое живёт в чате, дёшево. Каждая система в цепочке — CRM, склад, бухгалтерия — добавляет отдельную связку, чужой API, права доступа и краевые случаи. |
| Планка качества | Черновик для человека и автономный ответ клиенту требуют разной инженерии. Высокая планка тянет за собой проверки, тесты и защиту от ошибок, и каждый процент точности дорожает к концу шкалы. |
| Нужда в дообучении | Базовая модель с грамотным промптом покрывает большинство задач. Дообучение под вашу специфику оправдано на узкой задаче с тысячами повторов и добавляет к смете заметную строку. |
| Формат поддержки | Решение ломается, когда меняются ваши данные или внешний API. Разовая сдача и месячное сопровождение — две разные цены, и вторую закладывают сразу. |
Планку качества я держу отдельно, потому что её недооценивают регулярно, и ошибка здесь стоит дороже всех остальных. Поднять решение с восьмидесяти процентов точности до девяноста стоит умеренно, а вытянуть последние проценты до уровня, где решение отвечает почти без человека в контуре, обходится дороже всей предыдущей работы. Поэтому я всегда спрашиваю, какая планка вам реально нужна, потому что лишние проценты вы оплачиваете полной ценой.
Эти пять вводных связаны между собой, и в этом главная хитрость сметы. Грязные данные поднимают планку инженерной работы ещё до интеграций, потому что модель на мусоре ошибается, и приходится достраивать защиту от ошибок. Высокая планка качества тянет за собой дообучение, дообучение требует размеченных данных, разметка возвращает вас к первому пункту. Поэтому я смотрю на пять вводных как на единый узел: связка, дешёвая на бумаге, дорожает, когда одна вводная тянет за собой соседнюю.
Как зафиксировать scope и получить диапазон
Перед тем как просить оценку, пройдитесь по своим вводным сами. Это займёт час и отрежет половину тумана, потому что вы придёте на созвон с готовыми ответами на те самые вопросы, которые двигают цену разработки. Вот порядок, по которому я предлагаю фаундерам собирать границы задачи в один документ.
- Опишите один процесс целиком: что приходит на вход, что должно появиться на выходе, сколько раз в день он повторяется. Один чёткий процесс оценивается точнее, чем размытое «автоматизируйте нам всё».
- Зафиксируйте данные: где они лежат, в каком виде, кто ими владеет. Чистая таблица — зелёный свет, устные договорённости и разрозненные письма — повод заранее заложить строку на сбор.
- Перечислите системы для интеграции поимённо. Каждая система в списке — это отдельная связка, и подрядчик должен видеть их все до того, как назовёт цену.
- Назовите планку качества словами вашего бизнеса: где результат читает человек, а где решение отвечает само и ошибка стоит денег. Это определяет глубину тестов и защиты.
- Решите про дообучение честно: задача узкая и повторяется тысячи раз — дообучение окупится; задач много и они разные — хватит базовой модели с промптом.
- Заложите формат поддержки сразу как строку. Решение без сопровождения тихо деградирует, а команда без обучения его игнорирует, и обе ошибки сжигают вложенные деньги.
Когда эти шесть пунктов закрыты, вы держите в руках scope — зафиксированные границы задачи. С таким документом подрядчик называет диапазон с обоснованием, а вы видите, какая строка отвечает за какую сумму и где вы сами можете срезать объём. Точные цифры по нашим программам и форматам работы сверьтесь на сайте, потому что они зависят от объёма задачи и меняются.
Документ со scope даёт вам ещё один рычаг, о котором фаундеры думают редко. Он превращает разговор с подрядчиком из обсуждения цены в обсуждение объёма. Когда вы видите, что автономный ответ клиенту удваивает смету против черновика для человека, у вас появляется выбор: оплатить полную автономию или начать с проверки человеком и поднять планку позже на живых цифрах. Без зафиксированного scope этот выбор невидим, и вы платите за максимальную версию решения, даже когда вам хватило бы простой.
Где модель в этой смете и куда идти дальше
Главная ловушка в оценке разработки — поставить знак равенства между ценой решения и тарифом модели. Тариф легко загуглить за минуту, поэтому он притягивает внимание, хотя весит в смете меньше всего. Окупаемость, или ROI ИИ, считается по всей разработке целиком: сбор данных, проектирование связок, тесты, интеграция и поддержка. Модель в этом списке почти всегда самая дешёвая часть.
- Расход на цену за токен измеряется в долларах за тысячи запросов и зависит от реальной нагрузки вашего решения.
- Подготовка данных и интеграция измеряются неделями инженерной работы и дают самый большой разброс в смете.
- Планка качества определяет, сколько уйдёт на тесты и защиту от ошибок, и последние проценты точности дорожают круче всего.
- Поддержку закладывают отдельной строкой сразу, потому что решение без сопровождения деградирует вместе с вашими данными и внешними API.
- Снижать цену выгоднее через сужение scope и порядок в данных, потому что выбор более слабой модели сэкономит лишь копейки.
Я веду эту тему на практике в наших программах: мы берём один процесс конкретной компании, фиксируем его границы, считаем расход на запросы на реальной нагрузке и решаем, во что обойдётся первый разумный шаг. Загляните в наши программы и приходите на разбор — мы соберём ваш scope вместе и превратим размытую смету в понятный диапазон.
Частые вопросы
Почему подрядчик отвечает «зависит» вместо цифры?
«Зависит» означает, что инженер видит вилку и отказывается врать вам точной суммой. Цена разработки собирается из объёма работы, а объём задаёте вы через границы задачи: число процессов, состояние данных, планку качества. Пока границы размыты, любая цифра — гадание. Зафиксируйте scope в одном документе, и «зависит» станет диапазоном с обоснованием.
Что такое scope и зачем его фиксировать до сметы?
Scope — это зафиксированные границы задачи: какой процесс автоматизируете, где лежат данные, какие системы интегрируете, какая планка качества и формат поддержки. Документ со scope даёт две выгоды разом. Подрядчик называет диапазон с обоснованием, а приёмка проходит без споров о том, что входило в работу.
Сколько в стоимости разработки занимает сама модель?
Тариф модели занимает малую долю сметы. Основные деньги уходят на сбор и разметку данных, проектирование связок, тесты, интеграцию с вашими системами и поддержку. Расход на запросы измеряется в долларах за тысячи обращений, а инженерная работа вокруг модели измеряется неделями. Поэтому экономия на модели даёт копейки.
Почему высокая планка качества так дорожает?
Поднять решение с восьмидесяти процентов точности до девяноста стоит умеренно, а вытянуть последние проценты до уровня автономного ответа обходится дороже всей предыдущей работы. Высокая планка тянет за собой тесты, защиту от ошибок и проверку человеком на спорных случаях. Назовите планку, которая вам реально нужна, потому что лишние проценты вы оплатите полной ценой.
Можно ли удешевить разработку, сузив задачу?
Сужение задачи — главный рычаг экономии. Один чёткий процесс вместо размытого «автоматизируйте всё» режет смету сильнее любого выбора модели. Меньше интеграций и реалистичная планка качества дают тот же эффект. Решение с дешёвой моделью на чистых данных и узким scope обыграет дорогую модель на хаосе из систем и завышенных требований.
Зачем закладывать поддержку в смету сразу?
Решение ломается, когда меняются ваши данные или внешний API, и без сопровождения оно тихо деградирует. Месячная поддержка держит связку в рабочем виде и стоит отдельных денег, поэтому её закладывают как строку сметы с самого начала. Решение без поддержки и команда без обучения сжигают вложенные в запуск деньги. Точные форматы сопровождения сверьтесь на сайте.
Разберём вашу ситуацию на Discovery-созвоне
Один час на Discovery-созвоне — и вы увидите, какие задачи в вашем случае отдать ИИ, какие оставить команде.
Прийти на Discovery-созвон →