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