Нейросети для бизнеса: какие задачи отдавать, а какие — нет

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

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

Список сервисов не решает задачу

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

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

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

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

Карта задач: что отдаём сразу, что — с проверкой, что — никогда

На практике задачи бизнеса делятся не на «можно» и «нельзя», а на три уровня доверия. Я держу эту границу письменно, а не по ощущениям — иначе она сдвигается сама по себе, обычно не в ту сторону.

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

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

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

Как понять, с какой задачи начинать

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

Формула простая: минуты в неделю, которые ест задача, умножить на то, во что обходится одна ошибка. Задача с высоким первым множителем и низким вторым — ваш стартовый полигон.

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

Сколько это стоит на практике

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

Первая цифра — реальный случай из моей практики: сервис интеграций и специалист, который его обслуживал, обходились в 45 тысяч рублей в месяц. Когда связки переписали в обычные скрипты, расход упал до 1–2 тысяч. Разница — не в том, что скрипты бесплатны, а в том, что за подписку в 20 долларов модель написала то, за что раньше платили человеку каждый месяц.

Вторая цифра — из моей текущей практики с сайтами на нейросетевом конвейере: 1–5 тысяч рублей в месяц на боевой проект. Основная статья расходов — не хостинг и не домен, а обращения к модели, и она растёт вместе с объёмом задач, а не разово.

Третья цифра — урок, который дороже первых двух. Больше половины моих запросов уходило на самую сильную модель там, где спокойно справилась бы модель попроще, просто потому, что тяжёлая стояла по умолчанию. Заметил это только когда собрал панель расхода и упёрся в недельный лимит подписки — историю разбирал в отдельной статье про лимиты Claude Code. Отдельно про то, из чего вообще складывается счёт за подписку и когда выгоднее платить по API, — в разборе тарифов.

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

Где ломается: правдоподобное не значит верное

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

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

Что остаётся человеку

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

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

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

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

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

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