Сделать или купить ИИ-инструменты: как CTO выбирают правильный путь

Какую проблему вы пытаетесь решить

Большинство команд начинают слишком широко. Они говорят, что им нужен «ИИ для компании», хотя на самом деле им нужна помощь с одной повторяющейся задачей, которая каждую неделю отнимает время.

Решение «сделать или купить» для ИИ-инструментов становится проще, когда вы можете назвать эту задачу одним простым предложением. Хорошие примеры: «готовить первые ответы на обращения в поддержку», «сводить записи звонков в CRM» или «проверять pull request’ы на типичные ошибки». Если вы не можете описать работу так ясно, значит, вы всё ещё на стадии идеи.

Потом определите пользователей. Будьте точны. Инструмент для двух операционных менеджеров будет сильно отличаться от инструмента, которым пользуются 40 сотрудников поддержки, пять инженеров и основатель, которому нужен отчёт к пятнице.

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

Прежде чем сравнивать продукты или планировать внутренние ИИ-инструменты, запишите текущие неудобства простыми словами:

• Люди копируют одни и те же данные в три места.
• Менеджеры сутки ждут обновления статуса.
• Сотрудники поддержки переписывают одни и те же ответы.
• Инженеры тратят время на поиск старой документации.
• Основатели проверяют работу, которую вообще не стоило бы проверять.

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

Отделяйте ежедневную боль от приятных идей «на будущее». Ежедневная боль возникает часто, стоит денег и раздражает людей настолько, что они готовы принять решение. А «приятные идеи» хорошо звучат на совещании, а через две недели лежат без дела.

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

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

Когда вы разрабатываете инструмент сами, главное изменение — это соответствие процессу. Вам не нужно подгонять работу под чужие экраны, правила или пункты меню. Вы можете выстроить поток так, как команда уже работает, даже если на бумаге этот процесс выглядит не очень аккуратно.

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

Меняется и контроль над данными. Вы сами решаете, где хранятся промпты, файлы, логи и результаты модели. Если компании нужно держать клиентские данные, исходный код или внутренние заметки в своём облаке или на своих серверах, разработка внутри компании даёт такую возможность.

Вы также сами определяете, сколько данных видит модель. Можно убирать имена перед отправкой текста, блокировать отдельные проекты или делить один процесс на безопасные и чувствительные части. У типовых продуктов редко бывает такой уровень контроля.

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

Например, растущая софтверная компания может сделать ассистента, который читает задачи в GitLab, смотрит прошлые обращения и готовит тест-кейсы для разработчиков. Команда продолжает пользоваться привычными инструментами. Именно о такой работе Oleg Sotnikov часто и говорит: встроить ИИ в существующий стек, а не ставить отдельное приложение посреди процесса.

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

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

Что меняется, когда вы покупаете вендорский продукт

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

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

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

Вы также зависите от дорожной карты вендора. Отсутствующая функция может появиться в следующем квартале, а может и никогда. Если меняются цены, лимиты использования, исчезает интеграция или компания смещается в другой рынок, команде приходится адаптироваться, даже если свои планы не менялись.

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

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

Вендорские продукты лучше всего работают, когда задача типовая, сроки короткие, а команда готова мириться с некоторыми ограничениями. Если вам нужен точный fit под процесс, строгий контроль над данными или глубокое кастомное поведение, покупка может решить сегодняшнюю задачу, но создать потолок на завтра.

Сравните компромиссы бок о бок

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

Полезное правило простое. Разрабатывайте внутри, если процесс уникален, данные чувствительны или инструмент должен глубоко встраиваться в стек. Покупайте, если задача типовая, результат нужен быстро, а продукт уже закрывает примерно 80 процентов потребностей.

Например, компания, которая уже опирается на много внутренних систем — таких как self hosted GitLab, приватные документы, инструменты наблюдаемости и кастомные процессы, — может получить больше пользы от ассистента, подстроенного под этот стек. А отдел продаж, которому уже на следующей неделе нужны заметки по встречам и черновики писем, скорее всего, сначала должен купить решение.

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

Как принять решение

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

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

1. Начните с одной задачи, которая обязательно должна работать хорошо. Сделайте её конкретной. «Готовить ответы поддержки на основе прошлых обращений» — это понятно. «Улучшить клиентский сервис» — нет.
2. Оцените чувствительность данных по простой шкале. Низкая чувствительность — это, например, публичная справка. Высокая — договоры, медицинские данные, исходный код или внутренние финансовые файлы. Чем выше риск, тем больше контроля вам нужно над моделями, хранением, логами и доступом.
3. Оцените время до первого полезного результата. Спросите, когда реальный пользователь сможет попробовать решение и сэкономить время. Вендорский инструмент может дать результат за две недели. Внутренний инструмент может занять два месяца, прежде чем ему начнут доверять.
4. Считайте первый год, а не только первый месяц. Включите настройку, проверку безопасности, трудозатраты сотрудников, использование модели, поддержку, обучение, исправление багов и стоимость поддержания актуальности промптов, интеграций и правил. Внутренние ИИ-инструменты часто выглядят дешёвыми на старте, потому что труд скрыт внутри зарплат.
5. Проведите небольшой пилот с одной командой, одним рабочим процессом и одним ответственным. Дайте ему короткое окно, например 2–4 недели. Отслеживайте простые метрики: сколько времени сэкономили, частоту ошибок, уровень использования и как часто люди возвращаются к ручной работе.

Если пилот работает — расширяйтесь. Если буксует — измените один элемент или остановитесь. Такая дисциплина экономит месяцы расползания и не даёт CTO оплачивать инструмент, которым никто не пользуется.

Что на самом деле стоит поддержка в долгую

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

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

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

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

Постоянная работа знакома: кто-то следит за ежемесячным использованием и ловит скачки затрат, кто-то ищет причину слабых ответов в промптах или данных, кто-то обновляет правила при изменении политики, а кто-то отвечает на одни и те же вопросы сотрудников, пока процесс не станет привычным.

Обучение — ещё одна скрытая статья. Новым сотрудникам нужны примеры, рамки безопасности и чёткое понимание, когда можно доверять инструменту, а когда нужно остановиться и проверить. Даже после запуска люди каждую неделю задают одни и те же вопросы: «Почему он ответил именно так?» и «Можно ли использовать его для этого клиента?» Эти отвлечения накапливаются.

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

Если инструмент влияет на реальную операционную работу, заложите в бюджет ответственного владельца. Это может быть продакт-менеджер, руководитель операций или fractional CTO, который отслеживает расходы, качество и изменения процесса до того, как они превратятся в большую проблему. Без такого владельца сопровождение превращается в случайную уборку, а случайная уборка всегда обходится дорого.

Простой пример из растущей компании

В SaaS-компании на 40 человек служба поддержки хочет отвечать быстрее. Команда обрабатывает около 800 обращений в неделю, и многие вопросы повторяются: сброс пароля, путаница с оплатой, лимиты тарифа и шаги настройки. Ответы вежливые, но слишком медленные, и клиенты ждут.

Один вариант — взять вендорский инструмент. Руководитель поддержки подключает его за два дня, загружает прошлые ответы и получает черновики прямо в help desk. Сотрудники поддержки почти сразу экономят время.

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

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

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

Этой компании не стоит спрашивать, какой вариант выглядит умнее. Ей стоит спросить, какая стоимость будет меньше мешать в течение следующего года.

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

Если каждый сотрудник поддержки экономит по 20 минут в день, шесть недель разработки могут быстро окупиться. Если команда маленькая и уже перегружена, сначала купить решение обычно безопаснее.

Ошибки, которые ведут команды не туда

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

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

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

Правила по данным тоже часто игнорируют до поздних согласований. Это дорого. Команды запускают тест на клиентской переписке или договорах, а потом безопасность, юристы или compliance блокируют внедрение. Чем раньше вы проверите хранение данных, контроль доступа и политику модели, тем меньше переделок создадите.

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

Одни и те же тревожные сигналы повторяются снова и снова:

• Никто не согласовал один показатель успеха.
• Пользователям нужно вручную копировать данные, чтобы получить пользу.
• Проверка данных начинается уже после запуска пилота.
• В модели стоимости внутренний труд считается бесплатным.
• После запуска за результат никто не отвечает.

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

Быстрые проверки и ваш следующий шаг

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

Прежде чем выбирать между «сделать» и «купить» ИИ-инструменты, проведите четыре быстрой проверки:

• Назовите одного человека, который отвечает и за решение, и за результат. Если решение делят product, security и engineering, значит, по сути, за него не отвечает никто.
• Спросите, смогут ли реальные пользователи попробовать что-то в течение 30 дней. Если нет, план, скорее всего, слишком большой.
• Проверьте стоимость выхода до старта. Вам нужен пилот, который можно остановить с ограниченными затратами, а не путь, который загоняет вас в кастомный код, длинные контракты или данные, которые трудно перенести.
• Посмотрите, насколько далеко распространяется это решение. Если оно одновременно влияет на поведение продукта, данные клиентов и инфраструктуру, относитесь к нему как к архитектурному решению, а не как к обычной покупке софта.

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

Держите в голове одно правило: начинайте с самого маленького теста, который способен либо доказать идею, либо её опровергнуть. Выберите один сценарий, одного ответственного, один показатель успеха и одну дату остановки. Это делает работу честной.

Если выбор одновременно затрагивает продукт, данные и инфраструктуру, второе мнение может сэкономить много переделок. Oleg Sotnikov делится таким fractional CTO-подходом через oleg.is, особенно для стартапов и небольших команд, которым нужно соотнести внедрение ИИ со стоимостью сопровождения.

А потом сделайте следующий шаг простым. Одобрите короткий пилот, сразу назначьте дату остановки и заранее решите, какой результат означает «продолжаем», а какой — «выходим».