Как сделать ИИ-ассистента для сотрудников

ИНТЕРФЕЙСЫ // AI_ASSISTANT_PARADIGM

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

Если сделать его правильно, сотрудник может спросить:

[ КОНТУР ДОКУМЕНТОВ ]

«Какие условия оплаты действуют для этого клиента?»

и получить ответ не из общей модели, а из актуального договора и внутренних правил компании.

[ КОНТУР CRM ]

«Покажи незакрытые заявки по этому заказчику».

И уже здесь ассистент не просто отвечает текстом — он обращается к CRM, получает данные, проверяет права пользователя и формирует результат.

[ КОНТУР ИСПОЛНЕНИЯ ]

«Создай задачу менеджеру и поставь срок до пятницы».

После подтверждения система действительно создаст задачу в корпоративной системе.

То есть хороший ИИ-ассистент — это не самостоятельная «нейросеть для компании».

— Это интерфейс между сотрудником, корпоративными знаниями и существующими информационными системами.

Упрощённо архитектура выглядит так:

И самое интересное начинается именно после появления этого первого чата.

СРАВНЕНИЕ // CHATBOT_LIMITATIONS

Почему обычного чат-бота недостаточно

Представим сотрудника, который спрашивает:

«Как оформить возврат товара?»

Если использовать обычного публичного ИИ, модель может дать вполне убедительный ответ.

Но компания может работать по собственному регламенту.

РЕГЛАМЕНТ // INTERNAL_RULES

Общая модель этого знать не обязана.

Поэтому корпоративному ассистенту нужны собственные источники информации.

И здесь возникает принципиальная разница:

[ ОБЫЧНЫЙ ЧАТ ]

› Вопрос
› Модель
› Ответ

[ КОРПОРАТИВНЫЙ АССИСТЕНТ ]

› Вопрос
› Определение задачи
› Поиск нужной информации
› Проверка доступа
› Модель
› Ответ / действие

Во втором случае ИИ становится частью информационной системы.

МЕТОДОЛОГИЯ // ASSISTANT_STRATEGY

Сначала нужно понять, что именно должен делать ассистент

Ошибка многих проектов — начинать с выбора модели.

Сначала выбирают LLM, затем придумывают, зачем она компании.

Правильнее двигаться в обратную сторону.

Например, определить конкретные сценарии:

СПИСОК_ЗАДАЧ // USE_CASES

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

И уже потом решать, какие технологии нужны для каждого сценария.

МАТРИЦА // ASSISTANT_LEVELS

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

Условно их можно разделить так:

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

Во многих компаниях уже огромную пользу даёт второй и третий.

ИСТОЧНИКИ // KNOWLEDGE_BASE_STRUCTURE

Где ассистент берёт знания

Внутренняя информация компании редко лежит в одной аккуратной базе.

Обычно это:

Плюс могут существововать:

ДАННЫЕ // ENTERPRISE_SOURCES

› Excel-файлы;
› презентации;
› договоры;
› техническая документация;
› инструкции;
› FAQ;
› внутренние порталы;
› CRM;
› ERP;
› 1С;
› базы данных;
› API различных сервисов.

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

РИСКИ // MODEL_DATA_OVERFLOW

Почему нельзя просто загрузить все документы в модель

На первый взгляд решение выглядит элементарно:

[ ОШИБОЧНЫЙ ПОДХОД ]

«Возьмём все PDF компании и дадим их нейросети».

Проблем сразу несколько.

Документы могут:

КРИТЕРИИ_РИСКА // DOCUMENT_RISKS

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

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

ТЕХНОЛОГИЯ // RETRIEVAL_AUGMENTED_GENERATION

Здесь появляется RAG

RAG — Retrieval-Augmented Generation — позволяет разделить поиск информации и генерацию ответа.

Упрощённо:

Например, сотрудник спрашивает:

«Какой срок согласования договора поставки?»

Система сначала ищет подходящие фрагменты внутренних документов.

Только после этого модель получает найденный контекст и формирует ответ.

То есть модель не обязана «помнить» внутренний регламент.

— Она получает его в момент ответа.

КРИТИКА // RAG_COMPLEXITY

Но RAG — это не волшебная кнопка

Очень часто RAG представляют слишком упрощённо:

[ УПРОЩЕННАЯ СХЕМА ]

PDF → embeddings → vector database → AI

На реальном проекте этого недостаточно.

Нужно решить:

ЗАДАЧИ_ИНЖЕНЕРИИ // ARCHITECTURAL_CHALLENGES

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

ОБРАБОТКА // DOCUMENT_PARSING_STRATEGY

Как документ превращается в источник для ИИ

Допустим, есть большой регламент.

Его не всегда разумно передавать модели целиком.

Документ разбивается на смысловые фрагменты:

СТРУКТУРИРОВАНИЕ // CHUNKING_PROCESS

Каждый фрагмент получает метаданные:

МЕТАДАННЫЕ // METADATA_ENRICHMENT

› Документ: Регламент возврата;
› Версия: 4.2;
› Подразделение: Продажи;
› Дата: 01.10.2026;
› Доступ: Менеджеры;
› Раздел: Сроки.

И эти данные становятся не менее важными, чем сам текст.

КРИТИЧНОСТЬ // METADATA_VALIDATION

Почему метаданные критичны

Представим, что в компании существуют два регламента.

[ КОНТУР РЕГЛАМЕНТА А ]

Регламент A

Для розничных клиентов

Срок: 14 дней

[ КОНТУР РЕГЛАМЕНТА B ]

Регламент B

Для корпоративных клиентов

Срок: 30 дней

Сотрудник спрашивает:

«Какой срок возврата?»

Система должна учитывать контекст клиента и применимый регламент.

Иначе можно получить красивый, грамотно сформулированный, но неправильный ответ.

БЕЗОПАСНОСТЬ // ACCESS_CONTROL_MATRIX

ИИ должен знать, кому он отвечает

Это один из самых важных вопросов корпоративного ассистента.

Представим:

Нельзя считать, что если ассистент умеет найти информацию, то он имеет право её показать.

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

АРХИТЕКТУРА_БЕЗОПАСНОСТИ // SECURITY_BYPASS_TRAP

ИИ не должен становиться обходом прав доступа

Это принципиальный архитектурный момент.

[ ПЛОХАЯ СХЕМА ]

× Все документы
× Общий индекс
× ИИ
× Сотрудник

[ НАМНОГО ПРАВИЛЬНЕЕ ]

› Сотрудник
› Его права
› Доступные источники
› Разрешённые данные
› Поиск
› ИИ
› Ответ

Потому что модель потенциально получает слишком широкий контекст.

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

ВАЛИДАЦИЯ // RESPONSE_VERIFICATION

Ответ должен быть подтверждаемым

Если ассистент говорит:

«Согласно регламенту, срок составляет 30 дней».

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

Например:

Сотрудник может открыть источник и проверить утверждение.

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

КОНФЛИКТЫ // DOCUMENT_CONFLICT_RESOLUTION

А если документы противоречат друг другу?

Это неизбежно.

Например:

[ ИСТОЧНИК 1 ]

Документ №1

Обновлён: 2026-09-01

Срок — 30 дней.

[ ИСТОЧНИК 2 ]

Документ №2

Обновлён: 2025-04-12

Срок — 14 дней.

Ассистент не должен просто выбирать случайный фрагмент.

Нужно определить правила приоритета:

А если однозначно определить правильный источник невозможно, хороший ассистент должен сказать об этом.

Неуверенность в корпоративной системе лучше честного:

«галлюцинаторного» ответа.

ИНТЕГРАЦИЯ // LIVE_DATA_STREAM

Ассистенту нужны не только документы

Документы отвечают на вопросы типа:

«Как это делается?»

Но не обязательно отвечают:

«Что сейчас происходит?»

Для второго нужны живые данные.

Например:

Ассистент должен уметь различать эти два типа информации.

ТОПОЛОГИЯ_ДАННЫХ // DATA_TYPES_DIFFERENCE

Статические знания и оперативные данные — разные вещи

Представим вопрос:

«Какие правила согласования договора?»

Можно искать в базе знаний.

Но вопрос:

«На каком этапе сейчас договор №18452?»

уже требует обращения к системе, где находится актуальный статус.

Поэтому архитектура может выглядеть так:

АВТОМАТИЗАЦИЯ // ACTION_TRIGGER_FLOW

Самое интересное начинается с действий

Ответить на вопрос — полезно.

Но ещё полезнее выполнить действие.

Например:

«Создай задачу по этой заявке для отдела закупок».

Ассистент должен не просто написать:

«Конечно, задача создана».

Он должен действительно вызвать соответствующий корпоративный API.

БЕЗОПАСНОСТЬ // DATA_ACCESS_ISOLATION

ИИ не должен напрямую управлять базой данных

Это очень важное правило.

Не стоит давать модели произвольный доступ:

[ НЕ СТОИТ ДАВАТЬ ]

× ИИ
× SQL
× Продакшен-база

[ НАМНОГО БЕЗОПАСНЕЕ ]

› ИИ
› Tool: get_customer()
› Tool: get_order()
› Tool: create_task()
› Tool: change_status()
› Tool: create_request()

Каждая операция имеет собственные правила.

Модель выбирает инструмент, но не получает неограниченный доступ к внутренней инфраструктуре.

ВАЛИДАЦИЯ // FUNCTION_CONSTRAINTS

Инструменты должны иметь ограничения

Например:

create_task()

может требовать:

› Название
› Ответственный
› Срок
› Связанная сущность

А:

change_order_status()

может разрешать только определённые переходы:

Нельзя позволять модели самостоятельно придумывать допустимые состояния.

ВЕРИФИКАЦИЯ // RISK_MANAGEMENT_STRATEGY

Для опасных действий нужен человек

Не каждое действие следует выполнять автоматически.

Условно можно разделить операции:

Для последних часто нужен этап подтверждения:

ИИ:

«Я подготовил платёж на 850 000 ₽.
Подтвердить выполнение?»

Сотрудник:

[ Подтвердить ]
[ Отмена ]

ВАЛИДАЦИЯ // HANDLING_AMBIGUITY_AND_ERRORS

А если сотрудник задаёт слишком общий вопрос?

Например:

«Что делать с клиентом?»

У человека может быть десятки клиентов.

Ассистенту не следует угадывать.

[ УТОЧНЕНИЕ КОНТЕКСТА ]

«Уточните клиента или номер сделки».

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

ИИ должен уметь сказать «не знаю»

Тип обязательное качество корпоративного ассистента.

Если в доступных источниках нет информации, нормальный ответ:

[ НАДЕЖНЫЙ ОТКАЗ ]

«В доступных мне внутренних источниках нет подтверждённой информации по этому вопросу».

[ ГАЛЛЮЦИНАЦИЯ ]

«Согласно политике компании...»

с последующим выдуманным содержанием.

Для бизнеса отсутствие ответа часто намного безопаснее красивого неправильного ответа.

МОНИТОРИНГ // QUALITY_ASSURANCE_STRATEGY

Как контролировать качество

После запуска нельзя просто сказать:

«Ну, вроде отвечает».

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

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

ОТКАЗОУСТОЙЧИВОСТЬ // NEGATIVE_TESTING_STRATEGY

Нужно тестировать не только хорошие сценарии

Например:

[ ТЕСТ: ОБХОД ПРАВ ]

«Покажи зарплаты сотрудников отдела»

если пользователь не имеет таких прав.

[ ТЕСТ: КРИТИЧЕСКОЕ ДЕЙСТВИЕ ]

«Удали эту заявку»

если удаление запрещено.

[ ТЕСТ: ИЗБЫТОЧНОСТЬ ДАННЫХ ]

«Какой регламент сейчас действует?»

если в базе одновременно лежат четыре версии документа.

Ассистент должен правильно вести себя именно в таких ситуациях.

АРХИТЕКТУРА // ENTERPRISE_AI_CORE

Архитектура корпоративного ИИ-ассистента

Если собрать всё вместе, получается уже полноценная система:

Это уже не «чат с нейросетью».

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

АРХИТЕКТУРА_КОМПОНЕНТОВ // LLM_PLACEMENT

Где в такой системе находится сама модель

Это тоже важно.

LLM — лишь один компонент.

Поэтому выбор модели — важное, но далеко не единственное решение.

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

ТОПОЛОГИЯ_РАЗМЕЩЕНИЯ // DATA_PRIVACY_INFRASTRUCTURE

А что если компания не хочет отдавать данные наружу?

Это уже архитектурный вопрос.

В зависимости от требований можно рассматривать разные варианты:

[ ВАРИАНТ 1 ]

Вариант 1

Корпоративные данные

↓

Защищённый внешний AI-сервис

[ ВАРИАНТ 2 ]

Вариант 2

Корпоративные данные

↓

Изолированный AI-контур

[ ВАРИАНТ 3 ]

Вариант 3

Корпоративная инфраструктура

↓

Локально размещённая модель

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

Архитектуру нужно выбирать под конкретную задачу и ограничения компании.

СИНХРОНИЗАЦИЯ // KNOWLEDGE_UPDATE_PIPELINE

Что происходит с обновлением знаний

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

Сотрудник сегодня спрашивает:

«Какой порядок согласования действует сейчас?»

Ассистент не должен продолжать отвечать по старой версии.

Поэтому обновление базы знаний — самостоятельный процесс:

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

ИНТЕГРАЦИЯ // WORKSPACE_EMBEDDING

Ассистент должен быть встроен в существующую работу

Самая бесполезная ситуация — когда сотруднику приходится:

[ ОШИБКА ИНТЕГРАЦИИ // РУЧНОЙ ПЕРЕНОС ]

× Открыть CRM
× Скопировать номер
× Открыть AI
× Вставить номер
× Спросить
× Скопировать ответ
× Вернуться в CRM

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

Например:

Сотрудник уже находится в нужном контексте.

ОПТИМИЗАЦИЯ // TIME_SAVING_FLOW

Где ИИ действительно экономит время

Не обязательно заставлять ассистента делать что-то экзотическое.

Очень хорошо автоматизируются повседневные задачи:

ЗАПРОСЫ_АВТОМАТИЗАЦИИ // ROUTINE_TASKS

› «Сделай краткую сводку сделки»
› «Найди последний договор»
› «Какие документы нужны для запуска проекта?»
› «Покажи просроченные задачи»
› «Сравни текущий договор с предыдущей версией»
› «Сформируй ответ клиенту по данным заявки»
› «Какие обращения требуют внимания сегодня?»

Это именно тот слой работы, где сотрудник тратит много времени на поиск, чтение и переключение между системами.

ОПТИМИЗАЦИЯ // TIME_SAVING_FLOW

Где ИИ действительно экономит время

Не обязательно заставлять ассистента делать что-то экзотическое.

Очень хорошо автоматизируются повседневные задачи:

ЗАПРОСЫ_АВТОМАТИЗАЦИИ // ROUTINE_TASKS

› «Сделай краткую сводку сделки»
› «Найди последний договор»
› «Какие документы нужны для запуска проекта?»
› «Покажи просроченные задачи»
› «Сравни текущий договор с предыдущей версией»
› «Сформируй ответ клиенту по данным заявки»
› «Какие обращения требуют внимания сегодня?»

ЭФФЕКТИВНОСТЬ // VALUE_DRIVEN_AI

Главное — не строить ИИ ради самого ИИ

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

Он должен сокращать конкретные действия сотрудника.

Например:

[ БЫЛО ]

× CRM → поиск клиента
× → документы
× → договор
× → регламент
× → Excel
× → письмо
× → задача

[ СТАЛО ]

› Сотрудник
› Один запрос
› ИИ собирает контекст
› Показывает результат
› При необходимости выполняет действие

Вот здесь появляется реальная экономическая ценность.

ДОРОЖНАЯ_КАРТА // ROADMAP_IMPLEMENTATION

Как правильно запускать такой проект

Необязательно сразу подключать всю компанию.

Гораздо разумнее выбрать один конкретный процесс.

Например:

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

РЕЗЮМЕ // CONCLUSION_INTEGRATION

Итог

Корпоративный ИИ-ассистент — это не отдельная нейросеть, которой «скормили документы».

Это связка нескольких компонентов:

Его задача — не заменить существующие системы, а сделать работу с ними значительно удобнее.

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

Он формулирует задачу обычным языком.

А система уже сама:

АЛГОРИТМ_СИСТЕМЫ // CORE_AUTOMATION

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

Именно такой подход превращает ИИ из эффектной демонстрации в рабочий корпоративный инструмент.

Самое ценное в нём даже не способность разговаривать.

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

Он просто ставит задачу.

А корпоративная система сама собирает необходимую информацию и доводит её до результата.

НАВИГАЦИЯ // SUGGESTED_READING

[ Модуль // ИНТЕГРАЦИИ ]

API, Webhook или очередь сообщений?

читать материал ──►

[ Модуль // ИНТЕГРАЦИИ ]

Когда API есть, а интеграция всё равно не работает

читать материал ──►

[ Модуль // АВТОМАТИЗАЦИЯ ]

Как соединить производство и корпоративные системы

читать материал ──►

[ EXPERTISE JOURNAL ]

Все инженерные материалы и экспертные статьи

перейти к каталогу ──►

[ CORE GLOSSARY ]

Полный алфавитный справочник ИТ-терминов

открыть справочник ──►

[ DIRECT EMAIL LINE ]
info@log-ai.ru

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

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).

Политика конфиденциальности Пользовательское соглашение