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

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

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

Такой подход позволяет рассматривать искусственный интеллект не как отдельный IT-продукт, а как один из инструментов автоматизации наряду с BPM, CRM, документооборотом, интеграциями и бизнес-правилами.

От отдельной нейросети к управляемой операции

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

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

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

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

Облако, собственная инфраструктура или гибридная схема

Универсально лучшего варианта нет. Архитектура зависит от характера операции.

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

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

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

Как устроена локальная LLM в корпоративном контуре

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

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

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

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

Вычисления могут выполняться на сервере, виртуальной машине или  рабочем компьютере, данные не передаются во внешние AI-сервисы, а для связи с другими корпоративными системами предусмотрена интеграция через REST API. Решение не требует дорогостоящего GPU-кластера.

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

Доказанный кейс: трудоёмкость обработки обращений снизилась на 90%

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

После внедрения трудоёмкость обработки запросов снизилась на 90%. Кроме того, сократились ошибки классификации обращений.

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

Другой сценарий: звонки и задачи после коммуникаций

Еще один кейс показывает, как в проекте для крупной производственной компании BPM-EXPERT объединил в ELMA365 обработку звонков, подготовку резюме, автоматическое формирование задач и контроль выездных визитов. Реализация заняла два месяца и проходила в два этапа.

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

Где такая автоматизация дает практический эффект

Вместо попытки установить одну нейросеть «для всей компании» полезнее рассматривать отдельные рабочие участки.

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

Какие показатели измерять на пилоте

Пилот полезно начинать с фиксации текущего состояния. Иначе после внедрения будет невозможно объективно сказать, дала ли автоматизация эффект.

Минимальный набор показателей:

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

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

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

Когда локальная LLM действительно оправдана

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

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

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

Когда LLM вообще не нужна

Не каждую операцию следует переносить на генеративные технологии.

Если результат можно однозначно получить обычным бизнес-правилом, справочником, SQL-запросом или стандартным маршрутом BPM, такое решение обычно проще проверить и сопровождать.

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

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

Как начинать внедрение

Практический старт — одна повторяемая и измеримая операция.

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

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

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

Краткий FAQ

Обязательно ли для локальной LLM покупать мощный GPU-сервер?

Нет единого требования для всех сценариев. Необходимые ресурсы зависят от размера и способа оптимизации модели, длины контекста, числа одновременных запросов и требуемой скорости ответа. Для небольшой нагрузки возможны более лёгкие конфигурации; требования корректно подтверждать нагрузочным тестом. Решение BPM-EXPERT — ELMA Локальный Лайт ИИ (ELMA Local Light AI) — может работать на сервере, виртуальной машине или рабочем компьютере и позиционируется как решение, не требующее дорогого GPU-кластера.

Делает ли размещение внутри компании решение безопасным автоматически?

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

Что выбирать первым: модель или бизнес-сценарий?

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

Вывод

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

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

ELMA365 в таких сценариях может выполнять роль оркестрационного слоя: получать исходные сведения, запускать интеллектуальную операцию, сохранять структурированный ответ, применять бизнес-правила и передавать спорные случаи сотруднику. BPM-EXPERT уже использовал подобный подход в проектах обработки звонков и классификации обращений и развивает локальный вариант ELMA Local Light AI.

Не знаете с чего начать?

Оставьте контакт и мы свяжемся с вами в течение 15 минут для подбора оптимального решения!