Внедрение ИИ в бизнес: купить, разработать или собрать

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

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

«Купить или разработать» — ложная дихотомия

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

Третий путь — сборка — не компромисс между первыми двумя. Это отдельная позиция владения со своей экономикой. Собрать AI-возможность значит развернуть оркестрационную платформу — движок, который выстраивает шаги в последовательность, держит состояние и обрабатывает повторные попытки, — подключить её к арендованным API моделей (платите за вызов, не владеете и не обслуживаете саму модель) и положить сверху собственную логику процесса: последовательность исследования, генерации, проверки и доставки, которая соответствует тому, как реально работает именно ваше агентство, а не тому, как это представляет себе типовой инструмент.

Это не то же самое, что no-code-хайп. No-code-инструменты обещают, что любой человек соберёт production-систему из нескольких блоков перетаскиванием. Сборка требует почти того же, что и разработка, минус часть, которая вас не отличает: вы не пишете языковую модель, не поддерживаете GPU-инфраструктуру, не строите планировщик или движок повторных попыток — оркестрационная платформа уже сделала эту работу и делает её лучше, чем первая самостоятельная попытка. Вы владеете тем, что делает воркфлоу именно вашим: ветвлением, вставкой голоса бренда, правилами проверки, обработкой сбоев. Вы арендуете commodity-слой и владеете дифференцирующим слоем — в этом вся идея, и именно поэтому граница владения важнее самой этикетки «купить или разработать».

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

Что реально даёт покупка готового

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

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

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

Ценообразование по объёму. Модели pricing за место или за генерацию рассчитаны на умеренное индивидуальное использование. Продакшен-объём агентства не такой: он рваный, сконцентрирован у нескольких человек, которые в горячий период обращаются к инструменту десятки раз в день, а остальное время почти не пользуются им, и растёт вместе с числом клиентов, а не штатом. Экономика, которая выглядела разумно на демо-звонке, начинает давить в тот момент, когда инструмент должен нести реальную пропускную способность клиентской работы.

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

Ничего из перечисленного не упрёк конкретному продукту. Это уровень категории: покупайте там, где задача одиночная и стандартная, и ждите стену в тот момент, когда в картину входит объём, число голосов или ветвление воркфлоу.

Что реально стоит разработка

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

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

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

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

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

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

Путь сборки

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

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

Самое точное измерение, которое у нас есть, — производство кейсов. Мы разбирали пайплайн детально в материале «Пайплайн кейсов»: от сбора исходников, разбросанных по почте, звонкам и заметкам, до драфта, внутреннего согласования, правок и форматирования подготовка кейса занимает 9–17 часов вручную. После сборки на оркестрационной платформе — 4–7 часов с AI. Это не десятикратный выигрыш, который рисуют в рекламных материалах, а честные «в 2–3 раза» — на трудоёмких этапах сбора исходников и черновика, при этом каждое суждение, требующее решения человека — какую структуру брать, что вырезать, что согласовать с клиентом, — остаётся за человеком.

Сборка не решает всё, и стоит быть точным насчёт того, что она оставляет нерешённым. Вы всё равно владеете швами — точками, где один воркфлоу передаёт эстафету следующему, где правило проверки нужно обновить, потому что клиент поменял процесс согласования, где поведение API модели чуть сместилось и downstream-проверку нужно перенастроить. Это владение — реальная, постоянная работа, и она требует конкретного навыка в команде: человека, который умеет прочитать воркфлоу, понять, где он ветвится, и починить его, не считая всю систему чёрным ящиком. Грамотность в оркестрационной платформе — реальный фактор при найме, а не сноска: команда без опыта работы с такими инструментами почувствует кривую обучения раньше, чем отдачу от неё. Насколько глубоко стоит уходить в собственную инфраструктуру под эту грамотность — вопрос отдельный, и мы разбираем его в материале «Self-hosted AI на Yandex Cloud».

Рамка решения

Уберите со стола интересы вендора с одной стороны и интересы подрядчика с другой — и решение сводится к трём вопросам, заданным по порядку, а не взвешенным одновременно.

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

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

Чувствительность данных — третий вопрос. Когда материал, проходящий через воркфлоу, конфиденциален для клиента — из тех данных, которые регулируются условиями обработки данных клиента или законом, в российской юрисдикции это 152-ФЗ, — расчёт смещается в сторону контролируемого контура даже там, где первые две оси указывали на покупку: от managed-сервиса в РФ-юрисдикции до self-hosted, в зависимости от категории данных. Развёрнуто это разобрано в материале «152-ФЗ и AI: что можно и что нельзя выгружать» и в архитектурном разборе «Суверенный AI-стек». Это не призыв в принципе избегать вендоров — это призыв точно знать, какие данные пересекают какую границу, прежде чем воркфлоу уходит в production, и взвешивать это против того, насколько дифференцирующая и насколько высокообъёмная перед вами задача.

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

Цены трёх путей

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

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

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

Сборка находится между двумя крайностями, и это путь, о котором мы можем говорить наиболее прямо, потому что это то, на чём мы работаем: умеренная стоимость настройки на проектирование и сборку первых нескольких воркфлоу как следует, текущий счёт за платформу и API, который растёт с объёмом использования, а не с числом мест, и эксплуатационная нагрузка, реальная, но ограниченная — ограниченная потому, что платформа несёт часть (расписание, повторные попытки, история выполнения), которая иначе была бы самой дорогой частью разработки с нуля. Честный компромисс против покупки — время на настройку и потребность в человеке в команде, которому комфортно внутри платформы оркестрации; честный компромисс против разработки — вы не владеете самим оркестрационным слоем, что нормально, потому что владение им не было тем, где живёт ценность.

Как оценивать вендора, когда все демо хороши

Демо любого AI-вендора выглядит убедительно. Для этого демо и делают. Проблема в том, что демо строится показать happy path с чистым вводом, одним пользователем, одним контекстом — ровно те условия, которые не описывают продакшен-работу агентства. Разрыв между убедительным получасовым демо и инструментом, который переживёт восемь клиентов, неровный ввод и вторник с тремя дедлайнами одновременно, — это ровно тот разрыв, о котором весь этот текст и написан, и он невидим на sales-звонке.

Три вопроса раскрывают этот разрыв надёжнее полного чек-листа функций.

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

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

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

Рамка в трёх предложениях

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