Корпоративный ИИ-ассистент: как отвечать по данным компании без утечек и фантазий

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

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

Существующий материал об ИИ поверх CRM (/blog/ii-poverh-crm-analiz-zvonkov-i-processov/) разбирает связь звонков и событий процесса. Здесь другой вопрос: как построить слой корпоративных знаний, чтобы ассистент отвечал по CRM, документам и расшифровкам, не создавая параллельную и неконтролируемую копию данных.

Сначала определите вопросы и границы ответа

Начинать с команды «подключить всю базу знаний» не стоит. Сначала собирают перечень реальных вопросов по ролям. Менеджеру может быть нужно узнать статус обращения и последнее обещанное действие. Руководителю — увидеть причины задержек по отделу. Сотруднику поддержки — найти утверждённый порядок возврата. Клиенту — получить сведения только о собственном заказе.

У каждого класса вопросов фиксируют:

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

Так появляется проверяемая область применения. Ассистент для внутренних регламентов и агент с доступом к клиентским карточкам — разные системы по риску, правам и способу тестирования. Их не следует объединять общей инструкцией «отвечай сотрудникам по данным компании».

Разделите источники по тому, что они действительно подтверждают

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

Класс источника Что подтверждает Главное ограничение
———————— ——————————————————— ——————————————————————
Утверждённый документ Действующее правило, условие или процедуру Нужны версия, владелец и дата действия
CRM / ERP Текущее записанное состояние клиента, заказа или задачи Поле может быть неполным или заполненным с опозданием
Журнал событий Кто, когда и какое действие выполнил Не всегда объясняет причину действия
Расшифровка разговора Что участники сказали во время звонка Слова не равны проверенному факту, возможны ошибки распознавания
Переписка Запрос, обещание или переданную информацию Может быть неформальной, устаревшей или неполной
Аналитический отчёт Расчёт по определённой методике и периоду Нужны формула, дата обновления и исходный набор

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

Подготовьте данные и метаданные до подключения модели

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

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

Для данных CRM и ERP (/crm-erp/) обычно не создают бесконечные текстовые выгрузки. Текущие статусы, суммы, сроки и связи надёжнее получать структурированным запросом в момент ответа. В поисковый индекс имеет смысл помещать знания, а изменяемые транзакционные факты запрашивать через ограниченный сервис.

RAG — это управляемый поиск перед формированием ответа

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

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

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

Проверяйте права до поиска, а не после ответа

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

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

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

Версии, обновление и удаление важнее первичной загрузки

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

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

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

Цитата должна позволять проверить вывод

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

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

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

Если ответ объединяет несколько источников, пользователь должен видеть их роли: правило взято из регламента, текущий статус — из CRM, а обещание — из звонка. Тогда противоречие становится заметным, а не сглаживается связным текстом.

Научите систему показывать противоречия и нехватку данных

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

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

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

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

Ответить на вопрос и изменить рабочую систему — разные возможности. Если ассистент умеет создавать задачи, менять статус или отправлять сообщения, каждая операция оформляется как узкая функция через API. У неё есть допустимые поля, проверка текущего пользователя, бизнес-правила, защита от повторного выполнения и журнал результата.

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

Такой подход соединяет ИИ с автоматизацией бизнеса (/avtomatizaciya-biznesa/): модель разбирает естественный язык, а детерминированный сервис проверяет права и исполняет разрешённое действие. Ошибка ответа не должна автоматически становиться ошибкой в данных.

Составьте тестовый набор из реальных рабочих вопросов

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

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

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

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

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

Учитывайте персональные данные и внешних обработчиков

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

Если участвует внешний поставщик, проверяют договорную роль, использование переданных данных, сроки хранения и расположение инфраструктуры. Для работы с данными граждан России отдельно рассматривают требования 152-ФЗ, локализацию первичного сбора и правила трансграничной передачи. Из текста закона нельзя делать универсальный вывод, что любая зарубежная модель автоматически разрешена или запрещена: оценивать нужно конкретный маршрут данных и основания обработки.

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

Начинайте с одного вопроса, но стройте полный цикл

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

1. Выбрать роль и пять–десять повторяющихся вопросов.
2. Назначить владельцев и приоритеты источников.
3. Описать метаданные, права и жизненный цикл удаления.
4. Собрать проверенный тестовый набор, включая запреты и конфликты.
5. Запустить режим чтения для ограниченной группы.
6. Сохранять найденные источники, ответы и исправления пользователей.
7. Устранить системные ошибки поиска и данных до добавления новых отделов.
8. Подключать действия через отдельные API только после стабильного чтения.

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

Источники

— NIST AI 600-1: Generative Artificial Intelligence Profile (https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence)
— NIST: AI test, evaluation, validation and verification (https://www.nist.gov/ai-test-evaluation-validation-and-verification-tevv)
— OWASP LLM08:2025 — Vector and Embedding Weaknesses (https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/)
— OWASP LLM01:2025 — Prompt Injection (https://genai.owasp.org/llmrisk/llm01-prompt-injection/)
— OWASP LLM02:2025 — Sensitive Information Disclosure (https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/)
— OWASP LLM06:2025 — Excessive Agency (https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)
— Федеральный закон № 152-ФЗ «О персональных данных» (https://www.kremlin.ru/acts/bank/24154/print)
— Федеральный закон № 23-ФЗ об изменениях в обработке персональных данных (https://www.kremlin.ru/acts/bank/51683/print)