ИИ-помощник для сотрудников: два слоя

HR-менеджер получает одни и те же вопросы по сотне раз в месяц. «Сколько дней отпуска у меня осталось?» «Когда выплачивается аванс?» «Где взять шаблон заявления?» Каждый ответ занимает минуту-две, но суммарно за квартал это недели живого времени. Руководитель видит задачу: поставить ИИ-ассистента, который снимет поток.

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

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

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

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

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

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

Справочный слой: база знаний и ответ со ссылкой на пункт

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

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

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

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

Персональный слой: зарплата, отпуск, доступы по правам

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

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

Проблема возникает, когда персональный слой строят по той же схеме, что справочный: загружают выгрузку из 1С в базу знаний и позволяют ассистенту искать по ней. Теперь вся зарплатная ведомость лежит в одном индексе, и вопрос «какая зарплата у Петрова?» может дать прямой ответ. Это и есть главная ошибка проекта.

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

Что нельзя отправлять во внешнюю модель

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

Если ассистент построен на внешней модели (YandexGPT, OpenAI API или аналог), в нее уходит контекст: фрагмент документа или данные из учетной системы плюс вопрос пользователя. Если данные перед отправкой не маскируются, внешняя модель получает реальные персональные данные: имена, паспортные данные, ИНН, суммы.

Замер нашего PII-движка на бенчмарке из 2867 текстов и 4585 размеченных сущностей дал покрытие 92,5 %. Там, где у данных строгий формат, детектор берет от 96,7 %: документы, ИНН, СНИЛС, телефон, почта. Там, где формата нет, он проседает: ФИО 87,3 %, адреса 86,5 %, названия организаций 92,8 %. На эти три категории приходится 287 пропусков из 344. Полноту автоматического обнаружения мы не гарантируем: каждый спорный фрагмент подтверждает специалист.

Правило, которое следует из этого: данные из персонального слоя перед отправкой во внешнюю модель должны маскироваться. Модели не нужно знать, что зарплата у Ивана Петрова 87 000 рублей. Ей нужно знать, что запрашиваемый показатель равен числовому значению из записи сотрудника. Маскирование происходит в одной точке, до передачи в API модели.

Мы прошли это на себе. 10 августа 2026 года разбирали собственный канал лидов и обнаружили, что течет не поведение людей, а код уведомления: контакты уходили в сообщение в открытом виде. В базе на тот момент лежало 36 записей. Правка свелась к одной точке: маскирование поставили перед отправкой уведомления, заодно зафиксировали срок хранения записей в 365 дней. Вывод перенесли в проекты ассистентов: смотреть надо туда, где данные выходят наружу, а не туда, где их вводит человек.

Подробнее об организации защищенного канала с учетом требований 152-ФЗ: приказ ФСТЭК и персональные данные в ИИ-канале.

Схема канала: какая система, какое поле, какой запрос

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

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

Схема решает практическую задачу: по ней сразу видно, где возникает риск, а не после того, как система уже работает. Из нашего опыта с 19 агентскими ролями и 23 рутинами в контуре компании: риск почти всегда живет не там, где его ищут. Маскирование в одной правильно выбранной точке закрывает большую часть потока.

Как замерить пользу до и после запуска

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

После запуска те же числа снимаются через 30 дней. Хорошим результатом считается снижение числа повторяющихся вопросов на 40-60 % и сокращение среднего времени ответа с двух минут до нескольких секунд по справочным вопросам. Персональные вопросы требуют отдельного счетчика: рядом со временем ответа смотрим долю успешных ответов без эскалации к человеку.

Полезный индикатор: доля вопросов, на которые ассистент ответил «не знаю» или перенаправил к HR. Если она превышает 20-30 %, база знаний неполная или вопросы неправильно маршрутизируются.

Где такие проекты ломаются

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

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

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

Третья: отсутствие точки маскирования. Данные из учетной системы уходят во внешнюю модель в открытом виде. Это нарушение при работе с персональными данными по 152-ФЗ. Про методы обезличивания по 152-ФЗ есть отдельный разбор.

Четвертая: переоценка автоматики. Заказчик ожидает, что ассистент закроет 100 % вопросов. На практике всегда остается класс нестандартных запросов, где нужен человек. Если маршрутизация к живому специалисту не предусмотрена, сотрудники теряют доверие к системе после первого же неотвеченного вопроса.

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

Сколько это стоит и с чего начать

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

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

Для компаний с персональными данными в потоке отдельным шагом рекомендуем пакет guard-v1 (49 000 руб., 10 рабочих дней, выборка 200 текстов). Он дает реестр того, что уходит во внешнюю модель, и схему точки маскирования. Полноту автоматического обнаружения мы не гарантируем и пишем это в договор: автоматика закрывает один слой, регламент и архитектура закрывают остальные.

Если ИИ-ассистент нужен и для других процессов помимо HR, посмотрите, чем ИИ-агент отличается от чат-бота: там разобрана разница в архитектуре и задачах.

Частые вопросы