Где бизнесу реально нужен AI и ML, а где это дорогой хайп

Тест из трёх условий

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

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

Третий вопрос самый неудобный: допустима ли ошибка? Любая модель ошибается, вопрос лишь в том, насколько часто и что происходит после ошибки. Реалистичный ориентир для хорошо поставленной задачи — 85–95% правильных ответов, и это означает, что каждый десятый-двадцатый результат неверен. Если такой результат можно поправить на следующем шаге или он просто чуть хуже случайного, внедрение имеет смысл. Если каждая ошибка требует разбирательства и стоит дороже, чем экономия от автоматизации, ответ отрицательный.

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

• Повторяемость: решение принимается от сотен раз в месяц и по сопоставимым правилам.
• Данные: от тысячи размеченных примеров на класс, отражающих реальные, а не идеальные случаи.
• Терпимость к ошибке: 5–15% неверных результатов не создают недопустимых последствий.
• Владелец процесса: есть человек, который отвечает за результат и готов менять процесс под него.

Задачи, которые действительно окупаются

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

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

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

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

Где ИИ — неправильный инструмент

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

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

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

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

Проверка данных: что обычно значит «у нас есть данные»

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

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

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

• Объём: сколько записей реально пригодны, а не сколько строк в выгрузке.
• Полнота: доля записей с заполненными ключевыми полями.
• Разметка: есть ли готовые категории в системах и сколько нужно доразметить.
• Актуальность: отражают ли данные текущие процессы или процессы двухлетней давности.
• Права: персональные данные, ограничения 152-ФЗ, условия договоров с контрагентами.

Своё, готовое или API

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

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

Собственная разработка оправдана в трёх случаях: задача специфична для вашего бизнеса и готового решения не существует; данные нельзя выпускать наружу; объём запросов такой, что помесячная оплата внешнего API превышает стоимость собственной модели. Третий случай стоит считать заранее — он наступает быстрее, чем ожидают, и об этом следующий раздел. Разработка AI/ML в Veltos.Tech начинается от 180 000 ₽, и это, как правило, пилот на одном процессе, а не полноценная платформа.

Модель затрат: разработка против эксплуатации

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

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

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

Пилот, который даёт настоящий ответ

Правильный пилот устроен так: один процесс, 4–6 недель, критерии успеха согласованы до начала. Все три условия обязательны. Один процесс — потому что пилот на трёх задачах сразу не даёт понять, что сработало; 4–6 недель — потому что за меньший срок не собрать данных о работе, а за больший теряется управляемость и энтузиазм; критерии до начала — потому что критерии после начала всегда подгоняются под полученный результат, и это происходит без всякого злого умысла.

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

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

И последнее: у пилота должен быть заранее описанный отрицательный исход. Что мы делаем, если точность окажется 70% вместо 88%? Ответ «дообучим ещё месяц» допустим один раз, но не бесконечно. Готовность закрыть пилот с отрицательным результатом — признак зрелого подхода, а не поражения: вы потратили несколько недель и получили ответ вместо того, чтобы потратить год и получить работающую систему, которая не решает вашу задачу.

Частые вопросы

Услуги по теме

• Разработка AI и ML-решенийМы делаем AI, который решает конкретную задачу и окупается, а не демо ради демо. Классификаторы, рекомендации, обработка текста и документов, ассистенты на LLM, интеграция моделей в существующий продукт.
• AI-стратегия для бизнесаБольшинство компаний уже запустили хотя бы один пилот с ИИ. Меньшинство довело хоть один пилот до устойчивой эксплуатации. Разница обычно не в модели, а в том, выбрали ли процесс с измеримым эффектом и посчитали ли реальную стоимость эксплуатации до старта. Мы помогаем выбрать правильную точку входа и не потратить бюджет на демо, которое так и останется демо.
• Разработка веб-приложений и Telegram Mini AppКогда сайта уже мало и нужен продукт: личный кабинет, дашборд, внутренний сервис или Mini App внутри Telegram. Проектируем архитектуру, пишем бэкенд и фронтенд, доводим до релиза.

Читать дальше

• ИИ-ассистент на своей базе знаний: как работает RAG и сколько стоит внедрениеРазбираем, чем RAG-ассистент отличается от бота с кнопками и от LLM без данных, откуда берутся галлюцинации и что их реально снижает, сколько стоит SaaS против кастомной разработки и на каком месяце проект выходит в ноль.
• Как выбрать стек технологий для проекта: критерии, а не модаСтек выбирают на 3–5 лет вперёд, а решают за один созвон. Разбираем, в каком порядке принимать решения, какие критерии реально имеют вес, какие стеки работают для шести типов проектов и сколько стоит ошибка.
• MVP в 2026: реальные сроки, бюджет и что резать без потерьMVP перестал означать «дёшево и криво»: плохой прототип сегодня даёт ложноотрицательный результат и хоронит рабочую идею. Разбираем четыре уровня MVP с ценами и сроками, методику резки объёма и то, что вырезать нельзя ни при каком бюджете.