ИИ в HR и рекрутинге: что автоматизировать, а где оставить решение за человеком

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

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

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

1. Скрининг резюме и подготовка карточки кандидата

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

1. Система получает текст резюме и описание открытой вакансии с четким списком обязательных и желательных критериев.
2. Языковая модель извлекает факты в заданную структуру (JSON или поля карточки в ATS): подтвержденный стаж по профилю, владение конкретными программами или оборудованием, готовность к командировкам или сменному графику, указанные ожидания по доходу.
3. Алгоритм подсвечивает несовпадения и формирует 3–5 уточняющих вопросов, которые рекрутеру стоит задать на телефонном интервью.

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

2. Расшифровка телефонных скринингов и технических собеседований

Второй крупный источник рутины — ведение заметок во время интервью и перенос итогов встречи в систему учета кандидатов (ATS). Когда рекрутер одновременно разговаривает с соискателем и пытается подробно конспектировать ответы, страдает либо качество беседы, либо полнота карточки кандидата.

Технически задача решается в два шага: сначала аудиозапись переводится в текст (Speech-to-Text), а затем текстовая модель собирает из расшифровки структурированное резюме встречи.

По данным документации Yandex SpeechKit (проверено 02.11.2026), для перевода речи в текст применяются разные режимы: синхронный режим рассчитан на короткие одноканальные фрагменты до 30 секунд, а для полноценных записей телефонных скринингов и интервью подходит асинхронный режим, который поддерживает многоканальные аудиозаписи длительностью до 4 часов.

Когда расшифровка готова, языковая модель (например, через Yandex AI Studio (проверено 02.11.2026) или GigaChat API (проверено 02.11.2026)) заполняет шаблон по итогам разговора:

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

При этом критически важно отличать расшифровку и пересказ от выводов о личности. Даже специализированные решения для речевой аналитики контакт-центров, такие как Yandex SpeechSense (проверено 02.11.2026), выделяют статистику диалога, ключевые слова и строят сводку с помощью YandexGPT Pro, но наличие тех или иных слов или пауз в речи нельзя выдавать за доказательство неискренности кандидата или гарантированный прогноз его успешности на испытательном сроке. Итоговое резюме встречи всегда проверяет рекрутер перед отправкой нанимающему менеджеру.

3. Внутренняя HR-поддержка, онбординг и поиск по базе знаний

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

Если подключить к корпоративному порталу или мессенджеру обычную языковую модель без привязки к документам компании, она начнет выдавать общие рассуждения или придумывать несуществующие правила (галлюцинировать). Поэтому для внутреннего HR-ассистента используют архитектуру RAG (Retrieval-Augmented Generation) — генерацию ответа с опорой на поиск по проверенным внутренним источникам.

Показательный пример работы такой архитектуры во внутренней поддержке можно увидеть в публичном кейсе компании «Инфосистемы Джет», опубликованном на платформе Yandex Cloud (опубликован 13.02.2025, проверено 03.11.2026). В рамках полуторамесячного пилота решение классифицировало обращения сотрудников примерно по ста типам запросов и искало ответы по корпоративной базе знаний (с использованием Object Storage и OpenSearch), а часть ответов передавало специалисту на проверку. По опубликованным данным компании и поставщика по итогам пилота:

• до 30% обращений обрабатывались автоматически;
• точность классификации по ~100 типам обращений составила 75%;
• корректность ответов языковой модели достигла 80%.

Эти три цифры наглядно показывают реальную практику внедрения: корректность ответов модели в 80% не означает, что 80% всей работы исчезло без участия людей. Автоматически закрывается именно та доля типовых запросов (в данном пилоте — до 30%), где система уверенно находит однозначный ответ в базе знаний, а сложные или неоднозначные случаи маршрутизируются на сотрудника. При этом сам RAG снижает риск выдумок модели, но не дает стопроцентной гарантии правильности, если исходные документы противоречивы или вопрос сформулирован нестандартно.

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

Разграничение прав доступа в базе знаний

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

Частая и опасная ошибка при создании корпоративных ботов — загрузить все документы в общую индексную базу и написать в системной инструкции (промпте) языковой модели: «Не показывай рядовым сотрудникам данные для руководителей». Такой подход ненадежен: промпт не является механизмом информационной безопасности.

Корректное разграничение строится на уровне серверной логики и векторной базы данных. Например, согласно официальной документации векторной СУБД Qdrant (проверено 03.11.2026), система позволяет накладывать строгие фильтры на метаданные (payload) и идентификаторы точек. В документации прямо подчеркивается, что жесткие условия и ограничения не следует заменять смысловой (семантической) близостью векторов, а для полей фильтрации рекомендуется настраивать payload-индексы. На практике это означает, что сначала сервер авторизации определяет роль сотрудника, затем поисковый запрос к базе знаний жестко фильтруется по доступным этой роли документам, и только отфильтрованные фрагменты попадают в контекст языковой модели. Само по себе подключение векторной БД права доступа не настраивает — эту логику должен спроектировать интегратор.

Интеграция с кадровыми системами и корпоративными мессенджерами

Чтобы HR-бот не просто цитировал PDF-регламенты, а совершал полезные действия (например, проверял статус заявки или передавал данные в учетную систему), используют связку агентной логики и прикладных API:

• Оркестрация и инструменты агента. В современных платформах автоматизации, таких как n8n (проверено 03.11.2026), узел AI Agent работает по принципу Tools Agent (выбор старых узкоспециализированных типов агентов устарел начиная с версии 1.82.0): он соединяется с языковой моделью и обязан иметь хотя бы один подключенный инструмент (tool sub-node). При этом сама связь модели с базой данных не создает безопасного процесса — для чтения или записи данных создаются отдельные инструменты с жестко ограниченными правами доступа.
• Стандарт подключения инструментов. Если в компании строится модульная архитектура, для связи модели с внутренними источниками может применяться Model Context Protocol (MCP) (проверено 02.11.2026), связывающий host, client и server через транспорт stdio или Streamable HTTP. Однако сам протокол не является готовым коннектором к кадровой системе: разработчикам все равно нужно реализовать серверную часть, прописать права доступа и методы на стороне учетной программы.
• Связь с 1С. Если кадровый учет ведется в экосистеме 1С, обмен данными часто строят через штатные механизмы платформы. Согласно документации платформы 1С:Предприятие (проверено 02.11.2026), система поддерживает создание произвольных HTTP-сервисов, где разработчик задает шаблоны URL и обработчики методов, управляя заголовками, телом и кодом ответа. Это позволяет открыть для HR-бота строго ограниченный метод (например, получение количества дней накопленного отпуска по табельному номеру), не давая нейросети прямого доступа к базе.
• Интерфейс для сотрудников и кандидатов. Если компания разворачивает чат-бота для сотрудников или соискателей в российском мессенджере MAX, нужно учитывать правила самой платформы. По официальной инструкции MAX для разработчиков (проверено 02.11.2026), создание ботов требует подключения к платформе партнеров и верификации профиля организации, ИП или самозанятого — резидента РФ (организации и ИП могут создать до 5 ботов, самозанятые — до 2; токен выпускается через веб-платформу или мини-приложение «MAX для бизнеса»). Механика здесь отличается от привычного многим Telegram BotFather, что нужно закладывать в план запуска.

Как показывает опыт крупных внедрений в смежных сервисных процессах — например, в сообщении СберТеха от 23 сентября 2026 года (проверено 02.11.2026) о переходе Сбера на мультиагентную обработку обращений на базе Platform V Flow и GigaChat, — устойчивая архитектура строится поэтапно: сначала выстраиваются процессы с четкой детерминированной логикой, и только поверх них подключаются большие языковые модели для работы со свободным текстом. В другом материале команды Сбера на Habr от 26 июня 2024 года (проверено 02.11.2026) об ИИ-тренажере для разбора диалогов (связка SaluteSpeech и GigaChat) также видно, что на этапе MVP задачу сознательно сужали до одного конкретного навыка — отработки возражений, подробно сравнивая подходы к промптам. В HR этот принцип работает точно так же: сначала жесткая маршрутизация и узкая задача, затем расширение сценариев.

Работа HR-отдела практически полностью состоит из обработки персональных данных: ФИО, телефонов, адресов электронной почты, сведений об образовании, месте работы, доходах и паспортных данных. Поэтому любая автоматизация рекрутинга или кадрового сервиса в России должна проверяться на соответствие Федеральному закону № 152-ФЗ «О персональных данных» (по тексту закона, опубликованному на ресурсах Минтруда России (проверено 03.11.2026) и Росгвардии (проверено 02.11.2026)).

При проектировании HR-сценариев с использованием ИИ руководителю и юристу компании необходимо проверить пять ключевых моментов:

1. Запрет на решения исключительно на основе автоматизированной обработки (статья 16 152-ФЗ). Закон ограничивает принятие решений, порождающих юридические последствия в отношении субъекта персональных данных или иным образом затрагивающих его права и законные интересы, исключительно на основании автоматизированной обработки (за исключением случаев, прямо предусмотренных законом). Это не означает, что любая предварительная сортировка откликов запрещена, но настраивать процесс так, чтобы алгоритм самостоятельно и окончательно отказывал соискателям в приеме на работу без участия человека, крайне рискованно. Правовую допустимость каждого конкретного сценария должен верифицировать юрист по трудовому праву и ПДн.
2. Локализация и запрет использования зарубежных баз при сборе (часть 5 статьи 18 152-ФЗ). В редакции Федерального закона № 23-ФЗ от 28.02.2025 норма запрещает при сборе персональных данных граждан РФ осуществлять перечисленные в законе операции с использованием баз данных, находящихся за пределами территории РФ (за исключением предусмотренных законом случаев). Нельзя опираться на устаревшие трактовки о том, что данные достаточно «сначала сохранить в России, а потом свободно отправлять в любой зарубежный облачный сервис».
3. Трансграничная передача данных (статья 12 152-ФЗ). Если архитектура решения предполагает передачу персональных данных на территорию иностранного государства (например, в зарубежные API языковых моделей или внешние облачные сервисы автоматизации), закон требует подачи отдельного предварительного уведомления регулятора о намерении осуществлять трансграничную передачу. Обычное уведомление об обработке персональных данных его не заменяет, и сама по себе подача уведомления не легализует автоматически любую передачу в любую юрисдикцию.
4. Правовые основания, согласия и поручение обработки (статьи 6 и 9 152-ФЗ). Обработка данных должна опираться на законные основания (статья 6), а если к обработке привлекается внешний подрядчик, облачный провайдер или интегратор, с ним необходимо оформить корректное поручение оператора с установленными законом требованиями к конфиденциальности и безопасности. Если основанием выступает согласие субъекта (статья 9), оно оформляется отдельно от иных документов, которые подтверждает или подписывает человек. При этом наличие согласия кандидата не отменяет требований по локализации баз и защите информации.
5. Иллюзия «простого обезличивания» (статья 3 152-ФЗ) и локальных серверов (статьи 18.1 и 19 152-ФЗ). В HR часто пытаются обойти требования закона, просто удалив ФИО из текста резюме перед отправкой во внешнюю нейросеть. Однако по статье 3 закона обезличивание предполагает невозможность без использования дополнительной информации определить принадлежность данных конкретному субъекту. Если в тексте резюме остались телефон, ссылки на личные профили, ИНН физлица или уникальная комбинация редких мест работы и должностей, связь с конкретным человеком сохраняется. Точно так же развертывание локальной открытой модели (например, через llama.cpp (проверено 02.11.2026) на собственном или арендованном сервере) само по себе не означает выполнения закона: статьи 18.1 и 19 требуют полноценного комплекса организационных, правовых и технических мер защиты.

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

Стоимость автоматизации HR-процессов никогда не сводится только к цене токенов языковой модели. В реальную смету входят затраты на распознавание и генерацию (или аренду серверных мощностей), лицензии на платформу оркестрации, разработка интеграций с ATS / 1С / мессенджерами и настройка контура безопасности.

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

1. Стоимость работы с текстом и голосом (облачные API в РФ)

Если компания использует российские облачные платформы с оплатой по факту потребления (pay-as-you-go), расходы на обработку резюме и аудиозаписей собеседований можно предварительно прикинуть на условных учебных примерах.

Условный расчет 1: текстовый разбор откликов и работа HR-бота. По официальному прайсу Yandex AI Studio (проверено 02.11.2026), в синхронном режиме стоимость за 1 000 токенов (с НДС) составляет:

• Alice AI LLM Flash: вход — 0,1 ₽, выход — 0,2 ₽;
• YandexGPT Lite: вход — 0,2 ₽, выход — 0,2 ₽;
• YandexGPT Pro 5.1: вход — 0,8 ₽, выход — 0,8 ₽ (при этом кеширование и встроенные инструменты тарифицируются по отдельным правилам).

Допустим, в рамках условного месячного объема отдел подбора и внутренний бот суммарно отправляют в модель YandexGPT Lite 1 млн входных токенов (тексты резюме, описания вакансий, фрагменты регламентов) и получают 200 тыс. выходных токенов (краткие сводки и ответы):

• Вход: (1 000 000 / 1 000) × 0,2 ₽ = 200 ₽.
• Выход: (200 000 / 1 000) × 0,2 ₽ = 40 ₽.
• Итого за саму генерацию: 240 ₽ с НДС (без учета стоимости хранения данных, векторного поиска, серверов и работы интегратора).

Если рассматривать модели Сбера, важно учитывать категорию подключения. По официальной документации GigaChat API для юрлиц (страница обновлена 07.10.2026, проверено 02.11.2026), для действующих клиентов «СалютДевайсы» / «Салют для Бизнеса» синхронный тариф pay-as-you-go за 1 000 токенов с НДС составляет: GigaChat Lite — 0,065 ₽, Pro — 0,5 ₽, Max — 0,65 ₽ (при фактическом использовании минимальная сумма составляет 600 ₽ в месяц; если запросов не было, плата не списывается). Однако для новых клиентов с 1 сентября 2026 года подключение и оплата осуществляются через платформу cloud.ru, и актуальные тарифы для нового юрлица необходимо запрашивать непосредственно там — автоматически переносить старые расценки на новый договор нельзя.

Условный расчет 2: расшифровка аудиозаписей телефонных интервью. По прайсу Yandex SpeechKit (проверено 03.11.2026), стандартное асинхронное распознавание двухканального аудио стоит 0,1515 ₽ за 15 секунд с НДС (минимум 15 секунд, далее тарификация посекундная; отложенное асинхронное распознавание — 0,0381 ₽ за 15 секунд, а синхронное/потоковое одноканальное — 0,1626 ₽ за 15 секунд). Предположим, рекрутеры провели за месяц 1 000 коротких телефонных скринингов по 5 минут (300 секунд) в двухканальной записи:

• Расчет: 1 000 файлов × (300 сек / 15 сек) × 0,1515 ₽ = 3 030 ₽ с НДС. Это стоимость только перевода голоса в текст. За последующую суммаризацию текста через LLM, хранение аудиофайлов в облаке и передачу карточек в ATS нужно платить отдельно.

Если же компании нужна не просто расшифровка, а готовая платформа речевой аналитики с дашбордами DataLens и встроенной обработкой части записей ИИ-ассистентом, порядок цен другой: например, пакеты Yandex SpeechSense (проверено 03.11.2026) стоят от 45 000 ₽ в календарный месяц с НДС за тариф Basic (10 000 минут), 90 000 ₽ за Standard (30 000 минут) и 260 000 ₽ за Advanced (100 000 минут).

2. Инфраструктура: оркестраторы и серверы с GPU для локальных моделей

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

• Оценка памяти под локальную модель. Для запуска открытых моделей (например, через llama.cpp (проверено 02.11.2026)) объем видеопамяти только под сами веса модели предварительно оценивают по формуле: число параметров × битность квантования / 8. Например, для модели на 8 млрд параметров в 4-битном квантовании сами веса займут 8 × 4 / 8 = 4 млрд байт (около 3,73 GiB). Но в реальной работе сверх этого объема потребуется память под контекст (KV-кеш, который растет при загрузке длинных резюме и регламентов) и служебные буферы. Для более крупных моделей ориентируются на карты с большим объемом VRAM — к примеру, спецификация NVIDIA GeForce RTX 5090 (проверено 02.11.2026) предусматривает 32 GB памяти GDDR7 (что само по себе является лишь характеристикой карты и не гарантирует нужную скорость генерации под любой нагрузкой).
• Аренда серверов с GPU. По публичным данным хостинг-провайдера FirstVDS (проверено 02.11.2026), стартовая стоимость аренды vGPU (на базе L40S) начинается от 299 ₽ в сутки, а выделенной видеокарты в режиме GPU Passthrough (в линейке представлены конфигурации с L4, RTX 4090, RTX 5090, L40S — цена зависит от конкретной карты) — от 1 150 ₽ в сутки. В условном пересчете на 30 суток по нижней границе это составляет от 8 970 ₽ и от 34 500 ₽ соответственно (конкретную конфигурацию, объем выделенной видеопамяти, наличие и налоговые условия нужно уточнять при заказе; бесплатного тестового периода нет, минимальный срок оплаты — 1 сутки).
• Платформы автоматизации сценариев. При выборе облачной версии n8n (проверено 02.11.2026) тариф Starter при годовой оплате составляет эквивалент 20 евро в месяц за 2 500 исполнений сценариев (workflow executions), Pro — 50 евро в месяц за 10 000 исполнений. В Make (проверено 02.11.2026) тарификация идет по-другому — в кредитах за отдельные действия модулей внутри сценария (есть бесплатный лимит 1 000 кредитов в месяц), поэтому один запуск сложного HR-процесса из десяти шагов в n8n и Make расходует лимиты совершенно по-разному. Для российских компаний также важно заранее проверять возможность оплаты зарубежных облачных подписок или сразу закладывать self-hosted развертывание на собственной инфраструктуре.

3. Разработка и внедрение «под ключ»

Как видно из расчетов выше, сами запросы к российским облачным API при умеренном потоке кандидатов стоят единицы тысяч рублей в месяц. Основную часть бюджета на старте составляет работа инженеров и аналитиков. Для ориентира по рынку: в публичном прайсе подрядчика Goose AI (проверено 02.11.2026) внедрение одного готового агента из каталога со сценариями, интеграциями и тестированием оценивается в диапазоне 150 000–300 000 ₽ (это предложение конкретного игрока рынка, а не универсальный тариф для любой архитектуры).

Чтобы рассчитать бюджет под вашу кадровую систему и объем подбора, ориентируйтесь на следующие составляющие сметы (подробные условия работы нашей команды приведены на странице цен и форматов внедрения):

Чтобы проект автоматизации в HR не застрял на стадии бесконечного согласования и не привел к ошибкам в работе с кандидатами, двигаться лучше короткими итерациями:

1. Выберите один узкий и измеримый процесс. Не пытайтесь сразу объединить рекрутинг, кадровое делопроизводство, оценку эффективности и внутренний портал. Начните либо с суммаризации записей интервью и заполнения карточек в ATS, либо с бота-справочника по 10–15 самым частым кадровым регламентам.
2. Разделите задачи для детерминированной логики и для ИИ. Если сотруднику нужно получить стандартную справку по фиксированному шаблону или подать заявление по форме, используйте обычные кнопочные сценарии и алгоритмические правила. Языковую модель подключайте только там, где входные данные приходят в свободной текстовой или голосовой форме.
3. Согласуйте контур обработки персональных данных до написания кода. Определите, какие именно поля из резюме или кадровой базы передаются в модель, где физически расположены серверы и базы данных (с учетом ч. 5 ст. 18 и ст. 12 152-ФЗ), как оформлены поручения подрядчикам и где в процессе находится точка обязательного контроля человеком (ст. 16 152-ФЗ).
4. Соберите проверочную выборку (датасет) из 30–50 реальных примеров. Для рекрутинга возьмите реальные описания вакансий и отклики с известным вердиктом сильного рекрутера; для внутреннего HR-бота — список реальных вопросов сотрудников из чатов и правильные ответы со ссылками на пункты положений.
5. Запустите пилот в режиме «черновика для сотрудника». На первых неделях работы система не должна отправлять ответы напрямую соискателям или менять статусы в базе без подтверждения. Пусть агент готовит проект ответа или карточку разбора резюме, а рекрутер или кадровик подтверждает действие в один клик или правит неточности. Когда доля корректных черновиков достигнет стабильного уровня, рутину можно переводить в более автономный режим.

Можно ли поручить ИИ полностью проводить первичные собеседования и сразу отказывать неподходящим кандидатам? Технически голосовые и текстовые боты способны задать анкетные вопросы и зафиксировать ответы, но правовую допустимость окончательного отказа без участия человека нужно проверять отдельно. Здесь важны два ограничения. Во-первых, статья 16 152-ФЗ ограничивает принятие решений, затрагивающих права и законные интересы человека, исключительно на основании автоматизированной обработки, с предусмотренными законом исключениями. Во-вторых, ошибка языковой модели в интерпретации нестандартного опыта отсеет подходящего специалиста. Оптимальная схема — бот собирает ответы и готовит сводку, а решение принимает рекрутер.

Достаточно ли удалить ФИО из резюме, чтобы спокойно отправлять его в любые внешние нейросети? Нет. По статье 3 152-ФЗ обезличивание означает, что без дополнительной информации определить принадлежность данных конкретному человеку невозможно. В резюме помимо имени почти всегда есть телефон, e-mail, ссылки на портфолио, точные названия прошлых работодателей, редкие должности и достижения, по которым личность соискателя легко устанавливается.

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

Как не допустить ситуации, чтобы корпоративный HR-бот рассказал рядовому сотруднику закрытую информацию для руководителей? Нельзя загружать открытые и конфиденциальные регламенты в общий поисковый контур без фильтрации и надеяться на текстовый запрет в промпте. Права доступа проверяются на уровне сервера авторизации и жестких фильтров метаданных в базе знаний (например, через payload-фильтры в Qdrant) еще до того, как фрагменты документов попадут в контекст языковой модели.

Если вы хотите разгрузить рекрутеров и кадровую службу от рутинной вычитки резюме, расшифровки интервью и однообразных вопросов сотрудников, мы поможем спроектировать и запустить надежное решение. Подберем архитектуру под ваш стек (1С, корпоративные порталы, ATS, мессенджеры), настроим поиск по внутренним регламентам с разграничением прав доступа и учтем ограничения по работе с персональными данными.

Ознакомиться с архитектурой решений и оставить заявку на разбор вашей задачи можно на странице услуги разработки и внедрения ИИ-агентов.