Как разработать корпоративный AI-ассистент на основе LLM: от архитектуры до пилота

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

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

Чаще всего такой ассистент работает в крупных компаниях, где штат сотрудников насчитывает более 300 человек, для поддержки сотрудников, HR, закупок, юридического блока, клиентского сервиса, ИТ-эксплуатации и внутреннего комплаенса.

Чем он полезен для крупных компаний:

Результат — скорость и управляемость процессов, что оправдывает внедрение в корпоративной среде.

Корпоративный AI-ассистент отличается от публичных моделей тем, что работает под контролем компании, с ограничением доступа, корпоративными источниками и требованиями 152-ФЗ.

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

Для корпоративного AI-ассистента обычно используют три подхода:

• RAG — поиск с генерацией;
• fine-tuning — дообучение модели;
• prompt engineering — проектирование запросов.

В проектах чаще всего работает связка из RAG и prompt engineering, а fine-tuning нужен не всегда.

Конкретные инструменты зависят от подхода.

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

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

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

Для запуска нужны актуальные документы, базы знаний, FAQ, регламенты, шаблоны ответов, тикеты поддержки и, при необходимости, выгрузки из корпоративных систем. Формат зависит от источника: PDF, DOCX, XLSX, HTML, записи из базы данных, структурированные поля из CRM или Service Desk.

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

Это основная причина, почему пилоты не дают результата: данные не готовы.

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

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

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

Алгоритм запуска:

1. Выберите один процесс.
2. Возьмите один источник данных.
3. Определите одну группу пользователей.
4. Измерьте одну-две метрики.
5. Только потом расширяйте на другие процессы.

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

Данные для пилота должны быть ограниченными по объему, но чистыми по качеству. Достаточно 1–3 источников, если они реально используются сотрудниками. Слишком широкий набор данных на старте только мешает.

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

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

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

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

Юридическая часть не добавляет функциональности, но без нее проект рискует быстро завершиться.

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

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

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

Корпоративный AI-ассистент — это инфраструктурный проект, результат которого зависит от качества данных. Запуск строится на одном процессе, одном источнике данных и одной измеримой метрике. Расширение сразу на несколько сценариев и покупка модели без предварительной подготовки документов — типичные причины провала пилота. Юридическое согласование проходит до запуска. Масштабирование, интеграции и дообучение имеют смысл только после того, как первое внедрение работает стабильно 2–4 недели подряд.

Сколько стоит разработка корпоративного AI-ассистента?

Стоимость зависит от архитектуры, объема источников данных, требований к интеграциям и контуру размещения. Пилотный проект на одном процессе обходится от 1,5–3 млн ₽, полноценное внедрение с несколькими сценариями и интеграциями — от 5 млн ₽ и выше. Основная статья затрат в корпоративных проектах — подготовка данных и интеграции.

Какую модель выбрать: открытую или закрытую?

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

Можно ли использовать зарубежные облачные модели в российской компании?

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

Как долго длится пилот?

Пилот на одном процессе с подготовленными данными занимает 4–8 недель. Если данные требуют очистки и структурирования, срок увеличивается. Самая частая причина затяжного пилота — отсутствие владельца данных и неопределенные критерии успеха.

Что делать, если модель дает неточные ответы?

Сначала проверить источники. Устаревшие, дублирующиеся или плохо структурированные документы дают неточные ответы вне зависимости от качества модели. Если источники в порядке, скорректировать prompt engineering и настройки поиска. В крайнем случае — добавить слой верификации ответов человеком для критичных сценариев.

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

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