LLM для бизнеса: где она приносит пользу и как внедрить без лишних затрат

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

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

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

Что означает LLM в бизнес-процессе

Большая языковая модель (LLM, Large Language Model) это программа, которая работает с текстом: понимает его, продолжает, преобразует. Для бизнеса важны шесть операций, которые она выполняет надёжно:

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

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

Чем LLM отличается от того, что уже стоит в компании:

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

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

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

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

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

Начинать нужно с узкого места, а не с модели

Самая частая ошибка выглядит так: компания решает «нам нужен AI», выбирает модель, покупает подписки и потом ищет, куда это приложить. Итог предсказуем: несколько сервисов, за которые платят, и ни одного процесса, где изменились цифры.

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

Пять вопросов первичного аудита:

1. Какая повторяющаяся операция с текстом или решением отнимает больше всего времени? Ищите то, что делается каждый день десятками раз, а не то, что раздражает громче всего.
2. Каковы текущие объём, длительность цикла и частота ошибок? Без исходных цифр вы потом не докажете эффект даже себе.
3. Какие данные и системы участвуют? Если нужный контекст лежит в голове у сотрудника, а не в системе, автоматизировать пока нечего.
4. Какой результат способен проверить человек? Если проверка результата стоит столько же, сколько ручное выполнение, экономии не будет.
5. Какая метрика докажет ценность пилота? Одна метрика, названная заранее. Не «станет удобнее».

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

Проверка на лишние инструменты

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

1. Какой результат должен существовать в конце операции?
2. В какой системе он должен оказаться?
3. Какие действия всё ещё останутся человеку?
4. Можно ли решить задачу текущими системами и одним AI-компонентом?
5. Какая подписка или ручной шаг исчезнет после внедрения?

Если на пятый вопрос ответа нет, вы не автоматизируете процесс, а добавляете к нему ещё один сервис.

Не уверены, какой процесс автоматизировать первым? Пришлите его краткое описание, и разберём, где LLM даст измеримый эффект, а где она только добавит сложности. Написать в Telegram

Подробно эту процедуру мы проходим в рамках AI-аудита процессов.

Карта применений LLM по функциям бизнеса

Таблица ниже нужна, чтобы найти свой процесс и сразу увидеть, чем за него платят и чем рискуют. Обратите внимание: у каждой строки есть и KPI, и основной риск. Сценарий без названного риска это реклама, а не план.

Дальше разберём три строки, с которых чаще всего начинают.

Поддержка клиентов как первый сценарий

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

Автономность набирается уровнями, и на каждом есть свой смысл остановиться:

1. Суммаризация и классификация. Модель размечает обращения по теме, тональности и срочности. Клиент этого не видит, риск нулевой, а маршрутизация уже ускоряется.
2. Подсказка оператору. Модель готовит черновик, человек правит и отправляет. Экономия времени появляется здесь, ответственность остаётся на человеке.
3. Ответ на основе базы знаний. Система отвечает из ваших регламентов со ссылкой на источник. Требует готовой и актуальной базы.
4. Автономная обработка узких типовых запросов. Только те типы, где вы заранее измерили точность и где ошибка обратима.
5. Передача человеку по уверенности и правилам. Не отдельный уровень, а обязательное условие для всех предыдущих.

На каждом уровне нужны две вещи: резервный сценарий с человеком и измеримые критерии приёмки. Без них уровень 4 наступает случайно, а узнаёте вы об этом из отзыва клиента.

Как это выглядит на практике

Собственный проект Reviews-WB. Обработка отзывов на Wildberries и Ozon: шесть специализированных агентов, маршрутизация по тональности, отдельный шаг проверки на галлюцинации. Ручная обработка отзыва занимала 8-12 минут, конвейер укладывается в 30-60 секунд.

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

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

Документы, переписка и звонки

Второй по частоте сценарий. Здесь LLM закрывает самую неблагодарную работу: превращение неструктурированного текста в структурированную запись.

Конвейер выглядит так:

вход  ->  OCR или транскрибация  ->  извлечение  ->  проверка
      ->  бизнес-действие  ->  журнал аудита

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

Что сюда попадает:

• извлечение реквизитов из счетов, актов и договоров;
• классификация входящей почты по типу и ответственному;
• суммаризация записей звонков с выделением договорённостей;
• преобразование свободного текста в структурированный формат для загрузки в систему;
• создание задачи или записи в CRM после проверки.

Считайте остаточную работу

Это самая недооценённая статья расходов, и о ней стоит сказать отдельно.

Собственный проект MediaUniversal. Конвейер из четырнадцати с лишним агентов, который готовит SEO-материал от анализа конкурентов до финальной редактуры. Ручной цикл занимал 14-20 часов, конвейер отрабатывает примерно за 30 минут. Разбивка по этапам:

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

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

Корпоративный поиск и RAG

RAG (Retrieval-Augmented Generation) это способ привязать ответ модели к вашим документам. Работает он так: система находит подходящие фрагменты в вашей базе, подкладывает их модели как контекст и просит ответить только на их основании, указав источник.

Что придётся продумать:

• поиск фрагментов: как документы режутся на части и по какому признаку находятся;
• формирование контекста: сколько фрагментов уходит в модель и по какому приоритету;
• права доступа: сотрудник должен получать ответы только по тем документам, которые ему открыты;
• актуальность: как быстро правка регламента доходит до индекса;
• ссылки на источник: ответ без ссылки проверить невозможно;
• проверка качества: набор реальных вопросов с эталонными ответами, на котором вы измеряете точность.

Здесь нужно сказать прямо, потому что вокруг RAG много завышенных ожиданий. RAG привязывает ответ к вашим данным, но не гарантирует его истинность. Модель может неверно понять найденный фрагмент, склеить два несвязанных документа или уверенно ответить по устаревшей версии регламента. Ссылка на источник существует именно для того, чтобы человек мог это поймать.

Собственный проект Gemini Light RAG 2.0. Командная база знаний с AI-чатом для команд от двух до десяти человек: индексация документов, семантические ответы с отслеживанием источников, ролевой доступ на трёх уровнях. Задача, которую он закрывает: 2-4 часа в день, которые команда из пяти человек тратила на поиск по инструкциям и регламентам.

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

Подробный разбор внедрения корпоративного поиска есть в отдельном материале: RAG для бизнеса: корпоративный поиск по базе знаний.

Один запрос, ассистент, рабочий процесс или AI-агент

Четыре разных архитектуры, которые в разговорах регулярно называют одним словом «AI». Разница между ними в стоимости, предсказуемости и рисках, поэтому её стоит держать в голове.

Правило, которое экономит бюджеты:

Используйте наименее автономную архитектуру, которая обеспечивает нужный бизнес-результат.

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

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

Развёрнутое сравнение с примерами: AI-агент или чат-бот: чем отличаются и что нужно бизнесу. Проектированием и внедрением занимаемся в рамках направления AI-агенты и автоматизация.

Данные и интеграции

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

Что предстоит решить:

• подключения: CRM, ERP, helpdesk, хранилища документов, почта, телефония;
• качество и владельцы данных: кто отвечает за то, что справочник контрагентов актуален;
• идентификация и права: система должна знать, от чьего имени она действует и что этому человеку доступно;
• обратная запись: результат должен попадать в рабочую систему через API, а не в отдельный файл;
• идемпотентность: повторный запуск не должен создавать вторую задачу или второй платёж;
• журналы аудита: кто, когда, на основании чего получил результат.

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

Безопасность и конфиденциальность

Тема, где ошибки обнаруживаются позже всего и стоят дороже всего. Меры удобно разложить по слоям.

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

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

Маскирование персональных данных. Замена реальных значений на заглушки до отправки и обратная подстановка после.

Хранение и сроки удаления. Что сохраняется в журналах, как долго живёт, кто может прочитать.

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

Журналы, аудит и реагирование. Заранее описанный порядок действий при инциденте.

Юридическая проверка. Требования отличаются по стране и отрасли, и статья в блоге их не заменяет.

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

Разбор мер и условий выбора приватного контура: Безопасность LLM в компании: данные, доступы, приватный контур.

Как выбрать архитектуру

Четыре варианта, от самого быстрого к самому тяжёлому.

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

Про собственный LLM-кластер

Вариант, который часто обсуждают раньше времени. Он оправдан при совпадении нескольких условий:

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

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

Дорожную карту перехода от текущего состояния к целевому строим в рамках направления AI-стратегия для бизнеса.

Качество, галлюцинации и оценка

Раздел, который в большинстве материалов про LLM либо отсутствует, либо сводится к фразе «модели иногда ошибаются». Между тем именно здесь решается, доедет проект до продакшена или останется демонстрацией.

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

Что нужно построить:

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

Критерии правильности. Общие (ответ по делу, без выдумок, со ссылкой) и специфичные для вашей задачи (сумма совпадает с документом, контрагент есть в справочнике).

Жёсткие проверки критичных полей. Всё, что можно проверить кодом, должно проверяться кодом. Формат даты, диапазон суммы, наличие в справочнике. Модель предлагает, детерминированная проверка пропускает.

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

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

Откат и резервное поведение. Что происходит, когда модель недоступна или отвечает плохо. Ответ «процесс останавливается» тоже годится, если он выбран осознанно.

Критерий готовности пилота

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

событие  ->  контекст  ->  действие LLM  ->  проверки  ->  результат
         ->  подтверждение или исключение  ->  запись в рабочую систему

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

Пошаговая схема внедрения

Шесть этапов. У каждого свой результат и условие перехода дальше. Без них проект превращается в бесконечную доработку.

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

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

ROI и экономика проекта

Считать нужно до старта, иначе решение о масштабировании будет приниматься на ощущениях.

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

Ежемесячный чистый эффект
= ежемесячная выгода
- стоимость модели или API
- стоимость инфраструктуры и сопровождения
- стоимость остаточной ручной работы

Срок окупаемости
= стоимость внедрения, делённая на ежемесячный чистый эффект

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

Что нужно учесть, кроме очевидной стоимости токенов:

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

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

Методика расчёта с примерами разобрана отдельно: Сколько стоит внедрение LLM и как считать окупаемость.

Зачем отдельное внедрение, если AI-сервисов уже десятки

Резонный вопрос, и он звучит почти на каждой первой встрече. Отвечу прямо.

Доступ к модели сегодня стоит дёшево и доступен всем. Покупая подписку, вы получаете именно его. Дальше начинается работа, которую подписка не делает:

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

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

С чего начать

Коротко, по пунктам:

1. Выберите один процесс, который повторяется от сотни раз в месяц.
2. Измерьте его сегодня: объём, время цикла, частота ошибок.
3. Проверьте пятью вопросами из раздела про лишние инструменты.
4. Начните с наименее автономной архитектуры, которая решает задачу.
5. Соберите тестовый набор до запуска, а не после.
6. Заложите в расчёт остаточную ручную работу.
7. Определите одну метрику, по которой примете решение о масштабировании.

Примеры реализованных конвейеров, MCP-серверов и RAG-систем собраны в разделе проектов.

Нужна консультация по внедрению LLM в бизнес?

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

Напишите мне в Telegram: https://t.me/dtamarov

Чтобы разговор был предметным, подготовьте заранее:

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

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