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

ELMA Cortex позволяет использовать искусственный интеллект внутри экосистемы ELMA365: создавать AI-агентов, встраивать AI-операции в процессы и приложения, а также подключать интеллектуальный поиск по корпоративным данным. Сервер ELMA Cortex устанавливается в инфраструктуре клиента, а для работы AI-компонентов могут подключаться различные языковые модели.

Однако перечень возможностей платформы сам по себе мало говорит о том, как спроектировать рабочий сценарий. Разберём Cortex с позиции бизнес-процесса: когда нужен агент, когда достаточно AI-операции, где появляется RAG, какие данные и инструменты следует предоставить модели и где должен оставаться человек.

Сначала бизнес-операция, потом AI

Корпоративный AI имеет смысл рассматривать не как отдельный чат, а как компонент конкретной операции.

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

Тот же подход применим к обращениям, документам и базе знаний.

Рис.1.

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

Если эти вопросы не имеют ответа, добавление LLM обычно лишь переносит неопределенность из ручного процесса в автоматизированный.

AI-агент и AI-операция: в чём разница

В ELMA Cortex предусмотрены два близких, но разных способа включить AI в работу компании.

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

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

Поэтому выбирать между ними только по принципу «агент умный, операция простая» неправильно.

Рис.2.

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

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

Из чего состоит рабочий AI-сценарий:

Самой LLM недостаточно. В корпоративной системе результат определяется всей цепочкой:

Рис.3.

Событие:

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

Данные:

Следующий вопрос — что модель получает на вход.

Это могут быть:

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

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

Языковая модель:

Выбирать LLM имеет смысл не по популярности и не только по числу параметров. Для корпоративного сценария важны:

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

В Cortex могут использоваться разные провайдеры моделей. Это позволяет не привязывать архитектуру всей системы к одной LLM.

Инструменты:

Инструменты превращают модель из генератора текста в компонент информационной системы.

С их помощью AI-агент или операция может получать дополнительные данные и выполнять разрешённые действия. ELMA Cortex поддерживает инструменты для взаимодействия с ELMA365, а также возможность подключения внешних функций через MCP (Model Context Protocol).

Именно на этом уровне особенно важно разделять две задачи:

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

Когда нужен RAG:

Ещё одна типичная ошибка — подключать корпоративную базу знаний к любому AI-сценарию.

Рис.4.

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

При RAG документы не «записываются в знания LLM навсегда». Во время выполнения запроса система находит релевантные фрагменты корпоративных источников и передаёт их модели как дополнительный контекст. ELMA именно так описывает механизм расширения знаний агентов в Cortex.

Практическое следствие: качество RAG зависит не только от LLM, но и от:

• качества документов,
• их актуальности,
• индексации,
• поиска,
• прав доступа.

Полномочия AI: читать, готовить или выполнять

Чем больше инструментов получает агент, тем важнее определить не только то, что он может сделать, но и что ему разрешено.

Удобно разделить действия на три уровня.

Read (Чтение):

AI получает данные, ищет информацию и анализирует её, но не изменяет объекты системы.

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

Prepare (Подготовка):

AI готовит результат, который человек проверяет.

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

Execute (Исполнение):

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

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

В Cortex предусмотрены механизмы Guardrails (ограничителей) и маскирования чувствительной информации; доступ сотрудников к агентам также настраивается отдельно.

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

Три примера разных AI-сценариев

Массовые обращения – AI как операция процесса

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

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

По данным опубликованного кейса, трудоёмкость обработки запросов была снижена на 90%. Это показатель конкретного проекта, а не универсальная гарантия для любого AI-сценария.

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

Клиентские звонки: AI плюс обычная процессная логика

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

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

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

Корпоративная база знаний: AI плюс RAG

Третий тип сценария возникает, когда сотруднику нужен ответ не из общей модели, а из внутренних документов.

В таком случае архитектура может выглядеть так:
запрос пользователя → проверка доступного контекста → поиск по корпоративным источникам → передача релевантных фрагментов модели → ответ → ссылки на использованные источники.

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

Как проверить AI до масштабирования

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

Перед промышленным использованием желательно сформировать набор реальных примеров и заранее определить критерии качества.

Рис.5.

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

Когда AI применять не стоит

Корпоративная AI-платформа расширяет инструментарий автоматизации, но это не означает, что LLM нужна в каждом процессе.

Лучше использовать обычные правила, скрипты или BPM-логику, если:

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

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

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

Чек-лист – готов ли процесс к AI

Перед созданием AI-агента или AI-операции проверьте десять вопросов.

Рис.6.

Если на большую часть вопросов ответ «нет», начинать стоит не с выбора LLM и не с настройки агента, а с анализа самого процесса.

Вывод

ELMA Cortex даёт ELMA365 слой корпоративного AI: AI-агентов, AI-операции, инструменты работы с системами и механизм использования корпоративных знаний. Но наличие платформы не заменяет архитектурного решения.

Рабочий AI-сценарий начинается с конкретной бизнес-операции. После этого определяются данные, формат результата, необходимость RAG, модель, инструменты и допустимые действия. Чем больше автономности получает AI, тем важнее права, human-in-the-loop, журналирование и измерение качества.

Поэтому главный вопрос при проектировании корпоративного AI звучит не «какого агента создать», а «какую именно операцию процесса мы хотим изменить, какой результат должен дать AI и как компания проверит, что этот результат действительно лучше текущего способа работы?»