RAG для HR-политик: ответы сотрудникам с учётом ролей и версий

RAG-ассистент для HR-политик может помочь сотруднику найти актуальное утверждённое правило, понять, где оно применяется, и получить ответ с цитатами для проверки у владельца policy. Он не должен решать трудовой спор, создавать исключение, раскрывать персональные данные другого сотрудника или выдавать устаревший фрагмент handbook за действующее правило. Полезный результат — проверяемый policy answer: допустимый источник, revision, дата вступления в силу, locator, scope и маршрут эскалации, когда вопрос требует человека.

В статье описан HR-POLICY-8 — практический engineering-контракт для контролируемого внутреннего ассистента. Это не трудовая, юридическая, privacy- или HR-консультация. Правильный результат зависит от локальных норм, договоров, коллективных соглашений и правил конкретной организации. За широкой retrieval-архитектурой переходите к услуге RAG-систем; для разговора о локальной AI-разработке — к AI-специалисту в Армении.

Начните с HR-вопроса, а не со всех файлов в диске

«Спросить у HR всё» — не scope пилота. Рабочий scope называет пользователя, роль и локацию, разрешённое семейство политик, тип ответа, owner и условие остановки. Например: помочь штатному сотруднику найти текущую policy по командировочным расходам для своей страны и показать маршрут согласования. Но не решать, положено ли этому человеку исключение, и не рассчитывать окончательный payroll.

Граница важна: HR-документы часто смешивают общие правила с условиями страны, юридического лица, контракта, manager-level или конкретного сотрудника. Беглость ответа не доказывает eligibility. В интерфейсе источник и его scope должны проверяться проще, чем сгенерированный абзац.

Workflow HR-POLICY-8

HR-POLICY-8 сохраняет явным путь от вопроса к проверяемому ответу:

1. Receive — принять authenticated request, выбранную тему и допустимый контекст: например, юридическое лицо или локацию работодателя.
2. Resolve — определить server-side trusted attributes: роль, manager status, entity, страну, тип занятости и policy audience. Браузер не должен уметь их повышать.
3. Register — зарегистрировать policy sources с owner, document ID, revision, effective interval, audience, lifecycle state, языком и стабильным section locator.
4. Filter — отфильтровать корпус по access, audience, entity, locale и lifecycle до retrieval и до передачи context модели.
5. Retrieve — найти текущие eligible passages и сохранить source ID, revision и locator рядом с каждым candidate.
6. Compose — собрать ограниченный ответ, разделив policy text, простое summary, uncertainty и маршрут к human owner.
7. Verify — проверить citation coverage, актуальность источника, конфликт revisions, недостающие prerequisites и запрещённые поля персональных данных.
8. Route — направить к answer, clarification, policy-owner review или no-answer; никогда автоматически не писать request, record или decision в другую систему.

employee question + trusted role/location
  -> current eligible policy sources
  -> cited policy answer + scope label
  -> answer / clarify / owner-review / no-answer
  -> source-change reconciliation and evaluation

Это service workflow, а не только vector index. Название policy недостаточно: два документа с одинаковым именем могут иметь разные entity, effective date, audience или publication state. В материале про обновление индекса RAG, версии и удаление данных показано, почему изменение source должно стать наблюдаемым изменением retrieval.

Контракты данных и интеграций

До выбора модели или search-provider нужны четыре контракта.

1. Trusted identity и context. Employee identity и нужные policy attributes определяются в server-controlled integration. Не передавайте в retrieval payroll, medical, disciplinary и другие лишние персональные данные только ради «лучшего» результата.
2. Policy lineage. Нужны immutable source ID, revision или hash, owner, effective date, publication state, audience, entity, locale и locator. Superseded policy — lifecycle state, а не менее релевантный поисковый результат.
3. Граница ответа. Citations и scope labels стоят рядом с существенными утверждениями. Ответ различает «policy говорит» и «решение принимает owner». Нельзя выдумывать сроки, eligibility или исключения.
4. Operational receipt. Сохраняйте только минимальную диагностику для расследования policy/evaluation issue: revision источника, версию rule, route и owner. Retention и access определяет организация, а не удобство хранения всех employee queries.

Для персональных данных организация заранее определяет purpose, минимизацию, retention, vendor boundary и access controls. Это решения governance, а не автоматические свойства RAG. NIST AI RMF — добровольная рамка, которая может помочь назначить accountability и evaluation work; она не заменяет трудовую, privacy- или юридическую проверку.

Пример входа и результата

INPUT
Actor: authenticated employee
Context: Armenia entity, individual contributor, English locale
Question: Какая актуальная policy описывает согласование бизнес-поездки?
Allowed output: source-linked process summary; без обещания reimbursement

OUTPUT
Sources: TRAVEL-01 rev. 7, section 2.1-2.4; EXP-04 rev. 3, section 1.2
Answer: процитированные шаги и current approval owner с effective dates
Uncertainty: в запросе нет destination и типа поездки
Route: clarification либо указанный finance/HR owner для исключения

В результате нет обещания, что конкретную поездку одобрят или возместят, и нет предположения, что manager может отменить процесс. Если действующий источник отсутствует, есть условие конкретного договора или два current-документа конфликтуют, понятная эскалация безопаснее и полезнее уверенного ответа.

Что проверить до расширения пилота

Соберите маленький evaluation set из реальных, но надлежащим образом защищённых policy-вопросов. Каждый тест фиксирует trusted context, eligible sources, ожидаемый locator и безопасный route. Отдельно нужны normal answers, changed policy, role denial, entity mismatch, locale mismatch, missing source, conflicting revisions и вопросы, требующие human judgment.

Сигналы пилота должны быть проверяемыми: citation coverage, stale-source detection, denied-access результаты, доля owner review, качество no-answer, время исправления источника и аккуратно ограниченное сравнение времени на поиск утверждённой policy. Capacity estimate нельзя превращать в обещание качества HR-решений или замену judgment владельца.

Failure modes, которые надо спроектировать

Типичная проблема — не только invented answer. Passage может быть точно найден, но не подходить сотруднику, быть отозванным, неполным, переведённым для другой аудитории или зависеть от local rule. Нужен явный дизайн для таких случаев:

• Устаревший handbook text: revision policy сменился, но старый текст остался searchable. Храните effective interval и делайте promotion/removal наблюдаемыми.
• Неверная audience: policy для manager, executive benefit или restricted process попадает не тому человеку. Policy filters применяются до ranking.
• Нет prerequisite: неизвестны entity, location, contract type или тема. Запрашивайте минимально необходимое clarification.
• Конфликт policy: два источника выглядят current. Сохраните оба locator и направьте к named policy owner.
• Выход за personal-case границу: общий вопрос превращается в medical, disciplinary, compensation или immigration case. Остановитесь и эскалируйте, а не собирайте sensitive detail.
• Непроверенная автоматизация: answer инициирует leave request, payroll change или manager action. Retrieval output остаётся read-only, пока отдельно не спроектирован и не разрешён такой workflow.

Эти controls не сертифицируют fairness, privacy compliance или соответствие трудовому праву. Они делают поведение тестируемым и дают HR, security и privacy owner конкретный объект для approval или изменения.

Выберите один контролируемый policy lane

Начните с одного семейства политик с named owner, опубликованными revisions, практической внутренней аудиторией и приемлемым no-answer path. Создайте source registry, audience matrix, answer template, evaluation set, escalation map, source-change reconciliation job и rollback decision. Интеграции и чувствительные policy families добавляйте только после доказательства, что ассистент извлекает актуальные разрешённые источники и безопасно маршрутизирует uncertainty.

Если хотите описать controlled pilot внутреннего ассистента, подготовьте проектный бриф. Delivery evidence и engineering boundaries есть в кейcах. Цель — не универсальный HR-чат-бот, а проверяемый путь от policy-вопроса к актуальному источнику и правильному owner.