Особенности разработки и внедрения ИИ-ассистентов для бизнеса

Искусственный интеллект для бизнеса и внедрение ИИ обсуждают на профильных конференциях и на советах директоров, но до реальных проектов доходят единицы. 80% внедрений не окупаются. Почему?

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

Большинство компаний начинают знакомство с генеративным искусственным интеллектом одинаково: сотрудники покупают подписку на популярную LLM и пытаются решать с ее помощью рабочие задачи. Сначала это вызывает восторг — нейросеть пишет тексты, суммаризирует встречи и переводит письма. Красота! А потом бизнес пытается масштабировать этот опыт, делегирует ИИ сложные задачи и… наступает отрезвление.

Галлюцинации, выдуманные факты, неловкие калькированные с английского языка (хорошо, если с английского!) выражения. Я много общаюсь с представителями бизнеса и часто слышу от них, что ИИ категорически нельзя доверить ни одного рабочего процесса. Именно из-за галлюцинаций.

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

Вот только тут как с морской свинкой, которая и не морская, и не свинка.

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

Базовая LLM — это просто мощный движок для понимания и генерации текста. Она не имеет доступа к вашим базам данных, не знает специфики ваших регламентов и не умеет нажимать кнопки в вашей CRM. Чтобы ИИ начал приносить реальную пользу бизнесу, он должен перестать быть изолированным чат-ботом и стать полноценным корпоративным ИИ-ассистентом.

Мы в Siberian.pro под внедрением ИИ в бизнес понимаем автономный или полуавтономный ИИ-ассистент, берущий на себя определенный класс бизнес-задач.

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

Архитектура современного ИИ-ассистента базируется на двух ключевых компонентах: RAG и агентских системах.

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

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

1. Пользователь (или сотрудник) задает вопрос.
2. Система не отправляет вопрос сразу в нейросеть. Сначала она обращается к внутренней базе знаний компании (документации, регламентам, базе Jira, SharePoint, Confluence, 1С, СЭД).
3. Векторная база данных мгновенно находит самые релевантные фрагменты текста, которые содержат фактический ответ на этот вопрос.
4. Нейросети передается исходный запрос пользователя вместе с найденными внутренними документами. При этом в промпте дается железобетонная инструкция: «Сформируй ответ только на основе предоставленного текста. Если ответа там нет, скажи, что не знаешь».

Результат работы RAG-системы таков: ИИ начинает отвечать точно. При этом ссылается на конкретный внутренний документ (с указанием страницы или ссылки) и не выдумывает факты. Более подробно о том, что такое RAG-система и как она работает, я рассказал в этой статье.

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

Если RAG дает ассистенту хорошую память, то агентские системы дают ему руки. Я считаю ИИ-агентов едва ли не самым перспективным инструментом для бизнеса. И вот почему.

Бизнесу не всегда нужен просто ответ текстом. Когда менеджер спрашивает: «Че там по договору с ООО Чикибамбони?», он хочет не просто прочитать действующий регламент согласования из СЭД. ИИ в СЭД, конечно, тоже внедряют, но с другими целями.

Бизнес хотел бы, чтобы система проверила статус в 1С, заглянула в CRM, нашла последние письма от контрагента и выдала сводку. А в идеале — еще и предложила кнопку «Сформировать акт сверки» с черновиком наготове.

Другими словами, ИИ-агент — это система, в которой нейросеть выступает в роли диспетчера. Она анализирует запрос пользователя, разбивает его на шаги и сама понимает, какие инструменты ей нужны для выполнения задачи. Агент может:

• Отправить SQL-запрос в базу данных.
• Обратиться по API к внешней ERP-системе или CRM.
• Создать тикет в таск-трекере.
• Отправить email.

Такие мультиагентные системы кардинально меняют операционные процессы в компании.

Яркий пример — энергетическая компания AES, внедрившая ИИ-агентов для автоматизации аудитов безопасности. Передав агентам задачу по сбору, анализу данных и проверке соответствия нормативам (с обязательным человеком в контуре для финальной проверки), компания сократила затраты на аудит на 99% и ускорила процесс в сотни раз — с 14 дней до 1 часа.

Таким образом, полноценный ИИ-ассистент для бизнеса — это оркестратор, который объединяет мощь LLM, надежность фактов из RAG и способность агентов выполнять действия в корпоративных системах. Именно такая связка приносит осязаемый ROI.

Итак, о хорошем поговорили. Переходим к плохому, а именно: если все так замечательно, то почему 80% внедрений ИИ в итоге не окупаются?

На фоне впечатляющих историй успеха существует и другая статистика, о которой вендоры ИИ-решений предпочитают умалчивать (но не Siberian.pro).

По данным опроса двух тысяч CEO, проведенного IBM, лишь около 25% инициатив в области генеративного ИИ приносят ожидаемый возврат инвестиций. Более того, аналитика исследовательских центров, специализирующихся на цифровизации здравоохранения, показывает, что до 95% организаций, разворачивающих ИИ-проекты, сталкиваются с нулевым измеримым ROI.

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

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

ИИ-ассистент, построенный на базе RAG и агентских цепочек, работает как интеллектуальный поисковик. Но если он ищет ответы в хаосе, результат будет соответствующим. В большинстве крупных компаний данные распределены по разрозненным «колодцам» (data silos): клиническая информация хранится в медицинских информационных системах (EHR/МИС), расписания — в отдельном планировщике, а финансовые потоки — в изолированной ERP, и т.д.

Когда LLM, пусть даже усиленная грамотно спроектированной RAG-системой, пытается извлечь из этого хаотичного массива точный ответ для пользователя, она сталкивается с противоречивой или неполной информацией. В результате и ассистент, созданный на базе LLM+RAG, начинает выдавать ненадежные ответы. Сотрудники теряют к нему доверие, а проект в конечном итоге отправляется на полку с формулировкой «ИИ-ассистенты — это пустой хайп, ничего не работает».

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

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

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

Следующий вопрос, касающийся разработки ИИ-ассистентов для бизнеса, — безопасность.

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

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

Первый эшелон защиты — это изоляция контура. Для крупного бизнеса ассистенты разворачиваются либо полностью на собственных серверах компании (On-Premise) с использованием open-source моделей, либо в защищенных частных облаках (Private Cloud), таких как MWS Cloud. При таком подходе ни один байт корпоративной информации не покидает периметр компании. Алгоритм не использует ваши данные для самообучения, он работает исключительно как вычислитель внутри вашего защищенного «пузыря».

Второй, не менее важный эшелон — это ролевая модель доступа (RBAC), встроенная прямо в логику RAG-системы. Это критический момент: ИИ-ассистент не должен знать всё обо всем. И уж тем более не должен это самое «всё» рассказывать первому встречному.

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

Например, индийская медицинская платформа Apollo 24/7 успешно развернула клинический ИИ-движок с RAG, который помогает врачам анализировать историю болезни, соблюдая строгую конфиденциальность.

Аналогично, муниципальный совет Западного Сассекса (Великобритания) внедрил 14 уникальных генеративных ИИ-агентов для различных внутренних департаментов. Сотрудники социальной опеки получили мгновенный и безопасный доступ к базам нормативных актов, что радикально сократило время на поиск инструкций и законодательных норм.

У Siberian.pro есть свой кейс внедрения ИИ-ассистента в муниципальные службы. Мы разработали ИИ-помощника для контроля расходования бюджетных средств в коммунальной сфере.

Внедрение ИИ-решений в такие чувствительные направления требует комплексного подхода, который выходит далеко за рамки написания промптов. Команда Siberian.pro при разработке корпоративных ИИ-ассистентов выстраивает всю цепочку: от подготовки защищенной инфраструктуры и векторизации закрытых баз знаний до тонкой настройки ролевых моделей и оркестрации агентов. Безопасность закладывается изначально на уровне архитектуры.

В последней части этой статьи я коротко расскажу про этапы разработки ИИ-ассистентов для бизнеса. Не переключайтесь!

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

Этап 1. Аудит инфраструктуры данных и бизнес-процессов. Самый важный шаг. Команда анализирует, где лежат ваши данные, насколько они структурированы и чисты. На этом же этапе определяются бизнес-метрики: что именно должен ускорить или удешевить ассистент, чтобы проект показал ROI. Аудит мы предлагаем как отдельную услугу. Помогает быстро и недорого оценить, насколько вообще ваша организация готова к внедрению ИИ-решений.

Этап 2. Проектирование RAG-пайплайна. Сырые документы превращаются в машиночитаемый формат. Тексты разбиваются на фрагменты (это называется чанкинг), переводятся в математические векторы (эмбеддинги) и загружаются в векторную базу данных. Здесь же настраивается гибридный поиск, чтобы ассистент мог находить данные и по смыслу, и по точным ключевым словам (например, по номеру ГОСТа или реквизитам).

Этап 3. Разработка и оркестрация агентов На этом этапе ассистенту «пришивают руки». Разработчики пишут коннекторы к вашим корпоративным системам — ERP, таск-трекерам, CRM. Агенты обучаются правильной последовательности действий: например, как правильно дернуть API 1С, чтобы проверить остатки на складе, не обрушив при этом систему избыточными запросами.

Этап 4. Внедрение ролевой модели и тестирование Настройка прав доступа (RBAC), о которой мы говорили выше. Тестировщики проводят стресс-тесты, пытаясь заставить ассистента выдать коммерческую тайну или сгаллюцинировать. Только после жестких проверок система разворачивается в закрытом контуре.

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

Подробный разбор факторов, влияющих на стоимость разработки ИИ-решений, я привел в отдельном материале: Сколько стоит разработка ИИ-ассистента для бизнеса.

Если вы задумываетесь о внедрении искусственного интеллекта, начните с фундамента — с оценки того, готовы ли ваши данные к эпохе ИИ.

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

Не проще. Дообучение (Fine-tuning) стоит дорого, долго выполняется и не гарантирует отсутствия галлюцинаций. Кроме того, обученная модель не умеет забывать: если у вас обновился регламент, нейросеть придется переучивать. RAG решает эту проблему изящнее: вы просто удаляете старый документ из базы и загружаете новый, и ассистент мгновенно начинает работать с актуальными данными.

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

Пока нет, и это не должно быть целью. ИИ-агенты забирают на себя рутину: классификацию обращений, поиск инструкций, ответы на типовые вопросы и сбор первичных данных (например, проверку статуса заказа в ERP). Это позволяет сократить время обработки тикета на 40–60%, а сложные нестандартные случаи по-прежнему передаются людям.

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