Я давно смотрела на hr ai ассистент не как на модную игрушку, а как на единственный способ перестать тонуть в резюме, согласиях и локальных Excel на сетевых дисках. В России это особенно весело: 152-ФЗ, Роскомнадзор, локализация, уведомления, журналы, акты уничтожения — и всё это сваливается на HR, у которого и так день расписан по полчаса. В этой статье я разберу, как подойти к созданию ai ассистента для HR с RAG-доступом к базе знаний так, чтобы не было «магии», было по закону и реально экономило часы. Рассказываю на своём опыте, в российских реалиях 2026 года, с опорой на 152-ФЗ, регуляторку и нормальные инструменты вроде n8n и отечественных LLM. Материал подойдёт тем, кто в России работает в HR, автоматизации, управляет ИТ- или продуктовой командой, а также тем, кто хочет собрать ai ассистента для базы знаний компании и не боится слов «журнал учёта» и «актуализация политики обработки ПДн».
Время чтения: примерно 15 минут
Зачем HR сейчас свой AI-ассистент по базе знаний
Я заметила, что разговоры про создание ai ассистента для HR обычно начинаются с «сократить косты» и «поднять эффективность», а у меня в голове сразу всплывает другое: «как бы мне спокойно спать, когда придёт проверка Роскомнадзора». После 2025 года в России всё, что связано с персональными данными, особенно в HR, живёт в другой реальности: нужно быть оператором ПДн, держать базы в РФ, прописывать цели обработки так, чтобы юрист не плакал, и при этом как-то успевать подбирать людей. В такой обстановке простой чат-бот в Телеграме уже не спасает, нужен hr ai ассистент, который не только отвечает на вопросы по политике отпуска или грейдам, но и аккуратно ходит в вашу базу знаний, не таща данные в какой-нибудь зарубежный облак. Это критично, потому что количество автоматических проверок сайтов, форм и политик растёт, и уже сложно отмахнуться «ой, мы маленькие, нас не тронут».
В обычный рабочий день HR, особенно в московской компании человек на 200-500, выглядит примерно так: утром — расхламление почты с резюме, потом беготня между руководителями с вопросами «а этот Java-разработчик вам подходит или мы слишком много хотим», дальше — согласия, договоры, изменения в ТК РФ, которые надо как-то донести до сотрудников, и под вечер — попытки обновить внутренние регламенты. В этот момент идея сделать создание ai ассистента обученным на вашей базе знаний перестаёт быть хайпом и становится вопросом выживания: ассистент отвечает сотрудникам в корпоративном мессенджере на типовые вопросы, подсказывает HR, какие пункты в политике ПДн обновить, а ещё помогает искать кандидатов по стекам и опыту, опираясь на уже имеющиеся резюме и карточки. Получается, что он становится таким вменяемым «внутренним консультантом», который не уходит в отпуск и не забывает, где лежит последняя версия инструкции.
Когда я первый раз столкнулась с этой темой, меня больше всего нервировало слово RAG. Звучит как что-то из академических статей, а по сути это очень приземлённая история: у вас есть база документов (резюме, регламенты, договоры, инструкции, FAQ), вы их индексируете в векторной базе, а затем модель не придумывает ответы из воздуха, а подтягивает кусочки именно из этих документов и уже на их основе формирует ответ. Если коротко, это как очень быстрый и вежливый библиотекарь, который никогда не говорит «я думаю», а только «вот тут в пункте 3.2 вы сами написали вот так». Я постепенно увидела в этом не только способ снизить галлюцинации, но и способ юридически обосновать использование ИИ: модель не создаёт новую базу ПДн, не уносит данные за периметр, а просто облегчает доступ к уже существующей системе, которую вы и так обязаны защищать.
Чтобы было понятнее, я часто привожу бытовую картинку: вечером, когда домой пришла уже без сил, в голове вспоминается, что завтра нужно ответить сотрудникам по поводу новой политики удалёнки. Раньше я бы открывала общий диск, искала актуальную редакцию, сверялась с правками юриста, а потом сочиняла письмо. Сейчас я в внутреннем чате пишу ассистенту: «Сформулируй текст объявления по новой политике удалённой работы для сотрудников, с отсылкой на приказ от 12.01.2026», и через минуту получаю аккуратный текст с цитатами из приказа и внутреннего регламента. Кофе за это время успевает только чуть остыть, а не превратиться в ледяной сироп, как раньше. Это означает, что ассистент не заменяет голову, но экономит огромное количество микродвижений по поиску и сверке информации, которые раньше съедали полдня.
Чтобы не превращать всё это в теоретический разговор, я сознательно строю эту статью как практический гайд: от того, как подготовить white-data и базу знаний так, чтобы не нарушить 152-ФЗ, до того, какие платформы для создания ai ассистента в России сейчас более-менее адекватны по сочетанию функций и требований по локализации. По пути зацепим и вопрос, как аккуратно прикрутить его к телеграмм боту, если вам нужен лучший ai ассистент для создания телеграмм бота, и при этом не уронить защиту ПДн. Для расстановки акцентов в начале мне удобнее выделить одну фразу отдельным акцентом.
RAG-ассистент для HR в российской компании — это не про «моду на ИИ», а про снижение рутинной нагрузки и одновременное соблюдение 152-ФЗ, когда ИИ становится надстройкой над уже законной инфраструктурой, а не серой схемой.
Как изменилась жизнь HR после ужесточения 152-ФЗ
Когда я разговариваю с HR-руководителями в 2026 году, в один момент все начинают говорить одинаково: раньше 152-ФЗ был где-то фоном, а теперь он сидит рядом с ними за столом. После ужесточения требований Роскомнадзора любое хранение данных кандидатов — от ФИО и номера телефона до школьной олимпиады 2010 года — превращается в управляемый процесс с паспортом ИСПДн, журналами, актами и регистрацией в реестре операторов. Это критично, потому что hr ai ассистент, как бы он ни назывался, начинает оперировать внутри этой же экосистемы, и если сделать его «на коленке» в зарубежном облаке, он превращается в потенциальный повод для штрафа на несколько миллионов. При этом потребность в автоматизации никуда не девается: резюме идут, вакансии открываются, согласия надо отслеживать, а сотрудники всё так же задают одинаковые вопросы по отпускам и больничным.
Получается забавный парадокс: чем больше компания растёт, тем сильнее HR задыхается от бумажной и электронной рутины и тем опаснее становится импровизация с инструментами. Когда я первый раз помогала настраивать создание ai ассистента для базы знаний компании в одной IT-команде, обнаружилось, что у них часть резюме лежит в ATS, часть облаком на зарубежном диске, а часть — в личных почтах рекрутеров. Юрист в этот момент просто замолчал и долго смотрел в окно. RAG здесь оказался хорошей точкой входа к порядку: чтобы ассистент заработал, базу пришлось собрать, обезличить, положить в правильный дата-центр в РФ и описать в документах, которые потом с чистой совестью показали на проверке.
Я поняла, что HR-ассистент становится поводом «пересобрать» данные. По дороге к ИИ вы вдруг обнаруживаете, что половину того, что вы привыкли хранить годами, можно уничтожить с актом и спокойно жить дальше, а вторую половину стоит обезличить и оставить только то, что нужно для поиска и аналитики. Это освобождает не только серверы, но и голову: меньше риска, что где-то всплывёт старый Excel с паспортами, который когда-то делали «на всякий случай». Для HR, которые и так разрываются между подбором, адаптацией и внутренними коммуникациями, этот эффект почти терапевтический. Здесь я хочу подчеркнуть одну деталь, которой часто пренебрегают.
RAG логично начинать не с выбора модели, а с ревизии данных и понимания, какие атрибуты кандидатов и сотрудников вам действительно нужны для поиска и анализа.
Почему ручной HR-процесс больше не выдерживает реальности
Если разложить обычный HR-процесс на шаги, становится грустно: входящие резюме, ручная проверка, поиск по ключевым словам в почте или ATS, переписка с руководителями, ответы кандидатам, обновление статусов, параллельно — ответы сотрудникам в чате по отпускам, справкам, новым локальным актам. Я неоднократно измеряла, сколько времени уходит у HR-специалиста на типовые операции в течение недели, и стабильно получалось, что до 30-40 процентов дня съедают однотипные запросы, которые вообще не требуют человеческого решения, а только поиска по базе. Это означает, что создание ai ассистента обучение которого построено на фактических документах компании, способно вернуть HR-специалисту несколько часов в день, которые он может потратить хотя бы на осмысленное общение с людьми, а не на охоту за файлами.
Особенно ярко это проявляется в компаниях, где исторически много старых регламентов и версий документов. Один отдел хранит свою версию «Положения о премировании», другой — свою, и когда сотрудник спрашивает «почему мне начислили так, а не иначе», HR вынужден проверять два-три источника, а иногда и звонить бухгалтерии. RAG-ассистент в такой истории начинает выступать в роли единообразного «фронта» к этим документам: он знает, где какая версия лежит, какие пункты действуют, и может дать цитату с отсылкой на актуальный документ. Тут я обычно добавляю, что RAG не волшебная палочка — если в базе бардак, он будет только ускоренно доставлять вам бардак, но это отличный повод этот бардак расчистить.
На практике это приводит к любопытному сдвигу: HR впервые смотрит на свои процессы глазами ИТ и ИБ. Появляются вопросы про уровни доступа, роли, логирование действий, сроки хранения, регулярное уничтожение устаревших данных. В момент, когда вы начинаете обсуждать с безопасником, нужна ли роль «Рекрутер-стажёр» в системе и что он может видеть в RAG, вы вдруг понимаете, что ваш HR-процесс стал частью большой информационной системы компании, а не просто набором документов на сетевом диске. Чтобы не потерять эту мысль, я иногда подчёркиваю её отдельно (да, я сейчас тоже).
Когда HR-процесс становится частью ИТ-инфраструктуры через RAG-ассистента, к нему автоматически подтягиваются требования по логам, ролям и защите, и это хорошо — хаос перестаёт быть нормой.
Как устроен RAG-ассистент для HR в России по шагам
Если отойти от страшных терминов, работа hr ai ассистента на RAG в российской компании сводится к трём понятным штукам: подготовить данные так, чтобы они были законны и полезны, выбрать российскую модель и инфраструктуру с локализацией, и связать всё это через цепочку «запрос — поиск по базе — генерация ответа». Здесь мне важно расписать путь последовательно, потому что многие на середине пути устуют и уходят в сторону просто чат-бота без доступа к знаниям, а потом разочаровываются, что ИИ «ничего не знает про наши процессы». Я попробую пройти по шагам, как это происходило у меня и моих клиентов, с правками на типичные косяки.
Первый шаг всегда начинается не в коде, а в папках: нужно собрать и классифицировать базу знаний. Это не только политики и регламенты, но и реальные диалоги HR с сотрудниками, внутренняя база FAQ, обучающие материалы для новичков, шаблоны ответов кандидатам, иногда — обезличенные карточки кандидатов. Я сознательно говорю «обезличенные», потому что в России нам приходится жить в white-data-режиме для обучения и тестирования: никаких паспортов, телефонов, e-mail, только абстрактные «кандидат №123, опыт 5 лет в Python, уровень заработной платы такой-то диапазон». Для RAG это не проблема, ему для поиска нужны смысловые куски текста, а не ФИО. Здесь же обычно возникает первый конфликт с HR: «но тогда мы же не сможем искать по фамилии», и это правда, зато сможем спать спокойнее после проверок.
Следующий шаг — заведение всей этой истории в векторную базу. Если объяснить на бытовом языке: мы нарезаем документы на логические фрагменты (абзацы, пункты регламентов, описания вакансий), прогоняем их через специальную модель, которая превращает текст в числовой вектор, и складываем это в специальное хранилище, где можно быстро искать похожие кусочки по смыслу. Когда HR потом пишет ассистенту «найди мне кандидатов с опытом в Salesforce не меньше трёх лет», RAG не шарит по всей базе в лоб, а сопоставляет запрос с векторами и вытаскивает топ-5-10 подходящих отрывков. В России такие векторные базы уже есть у крупных облачных провайдеров, и многие из них сертифицированы или хотя бы физически расположены в РФ, что позволяет не переживать за локализацию.
Третий элемент — крупная языковая модель, которая будет «склеивать» ответ. Я чаще всего вижу комбинации вроде GigaChat, YandexGPT или решений на базе SberCloud, которые поддерживают RAG-сценарии и при этом декларируют хранение данных в российских дата-центрах. Самое важное, что модель в RAG-связке не живёт в вакууме: ей не надо знать всё про мир, ей нужно уметь вежливо и логично формулировать ответ, опираясь на те фрагменты, которые система извлекла из вашей базы. Это снижает требования к «мощности» модели, а ещё даёт хороший аргумент для службы безопасности: мы не отправляем в облако сырые резюме, мы отправляем только нужные кусочки, да ещё и обезличенные.
Четвёртый компонент — связующая логика. Здесь на сцену выходят такие инструменты, как n8n, Make.com (где-то его ещё можно пристроить даже в российских реалиях) или собственные микросервисы. Я часто использую n8n как мост между ATS, векторной базой и LLM: он принимает запрос от пользователя (из внутреннего портала, корпоративного мессенджера или телеграмм бота), обогащает его контекстом (роль пользователя, его отдел, язык), делает запрос в векторную базу, а затем передаёт найденные фрагменты в LLM с аккуратной подсказкой, как именно нужно ответить. Чтобы нагляднее показать состав таких шагов, я один раз попробую оформить их в виде перечня.
- Собрать и обезличить базу знаний (регламенты, FAQ, резюме, шаблоны писем).
- Развернуть или выбрать векторную базу данных в российском облаке с локализацией.
- Подключить российскую LLM с поддержкой RAG (GigaChat, YandexGPT, решения на SberCloud).
- Настроить n8n или аналог для маршрутизации запросов HR и сотрудников к RAG-цепочке.
- Прописать роли, уровни доступа и сценарии логирования действий в ИСПДн.
Как выглядит запрос к RAG-ассистенту глазами HR
Я люблю мысленно ставить себя на место конечного пользователя. Представь себе ситуацию: рекрутер открывает привычный интерфейс — это может быть виджет на внутреннем портале, отдельный чат в корпоративном мессенджере или тот же телеграмм бот, за которым стоит лучший ai ассистент для создания телеграмм бота на базе вашей компании. Рекрутер пишет: «Подскажи кандидатов на вакансию middle Python, опыт от 3 лет, желательно банковский опыт, с согласием на обработку ПДн не старше года». Дальше начинается магия, которая для него невидима, но которую мы как архитекторы должны хорошо понимать: n8n принимает запрос, добавляет информацию о том, к какому отделу принадлежит рекрутер и какие у него права, затем отправляет запрос в векторную базу, где хранятся обезличенные фрагменты резюме и тегов согласий.
Векторная база подбирает фрагменты, которые по смыслу соответствуют запросу: упоминания Python, работы в банке, стажа, дат согласий. Эти фрагменты вместе с метаданными (ID кандидата в ATS, ссылка на карточку, дата последнего общения) упаковываются в контекст и отправляются в LLM с инструкцией «сформируй список кандидатов с краткими резюме и укажи, на основании каких документов сделан вывод». Модель возвращает аккуратный текст: «Подходят кандидаты №123, №456, №789. У всех опыт в Python от 3 лет, у двух — опыт в банке, у всех действующие согласия на обработку ПДн». HR видит структурированный ответ и может сразу переходить к действиям, а не тратить время на поиск и проверку, и только при необходимости кликает в ATS, чтобы открыть полную карточку кандидата.
Аналогично работает и внутренний ассистент для сотрудников. Сотрудник пишет в чат: «Сколько дней отпуска у меня осталось и по какой политике это считается». Ассистент сначала авторизует пользователя, смотрит его карточку в кадровой системе, подтягивает актуальное положение об отпусках, ищет информацию о том, не менялись ли правила в этом году, и только потом формирует ответ. Важно, что модель не сама решает, сколько дней отпуска у человека, она берёт числа из кадровой системы, правила — из положения, а дальше только складывает это в понятный текст. Я не устаю повторять, что это как хороший ассистент, который помнит, где лежит всё, что вы сами ему однажды отдали.
На практике такая цепочка очень быстро приучает HR думать категориями «запрос — контекст — ответ», а не «подожди, я сейчас найду где-то этот файл». В первое время многие коллеги стеснялись писать ассистенту «неформально», а потом обнаружили, что разговорным языком формулировать запрос даже удобнее, чем прокликивать фильтры в ATS. RAG при этом остаётся надёжной подушкой безопасности: он подтягивает только то, что есть в вашей базе знаний, и не начинает импровизировать про Трудовой кодекс, как это иногда бывает с открытыми моделями. Чтобы немного зафиксировать эту мысль на уровне ощущения, мне нравится вводить короткую цитату.
RAG в HR — это привычный поиск в собственных документах, только ускоренный до секунд и дополненный человеческим языком, без претензии модели знать, как «правильно по жизни».
Как юридически вписать RAG-ассистента в 152-ФЗ
Юридическая часть самая скучная на первый взгляд, но без неё создание ai ассистента на яндекс или любой другой платформе для создания ai ассистента превращается в рискованный эксперимент. В России по 152-ФЗ любое автоматизированное использование ПДн требует понятной цели, основания, уведомления Роскомнадзора и описания ИСПДн. Когда мы добавляем RAG-ассистента поверх уже существующей кадровой системы, формально мы не создаём новую ИСПДн, если ассистент не хранит свои собственные копии данных, а только обращается к уже существующей базе и журналирует доступ. Это удобный аргумент перед юристами и безопасниками: мы не размножаем ПДн, а только добавляем ещё один «фронт» к той же системе с жёсткой авторизацией.
При этом придётся обновить документы: положение об обработке персональных данных, согласия кандидатов и сотрудников, угрозы безопасности в модели угроз, паспорт ИСПДн. В согласиях я обычно добавляю формулировку о том, что данные могут обрабатываться с использованием автоматизированных средств в целях подбора персонала, кадрового учёта и улучшения процессов обслуживания сотрудников. В политике — уточнение, что доступ к данным может осуществляться через внутренние сервисы на базе технологий искусственного интеллекта, при этом все серверы и хранилища находятся в РФ, а доступ контролируется по ролям. Юристам это нравится, потому что всё поименовано, а HR — потому что они не остаются один на один с формулировками.
Отдельный момент — локализация. Я категорически не рекомендую использовать зарубежные облака для хранения хоть каких-то фрагментов ПДн, даже в обезличенном виде, если есть риск сопоставления. Вопрос «но ведь у нас только вектора и ID кандидатов, это же не ПДн» может закончиться плохо на проверке, особенно если ID можно связать с конкретными людьми через другие системы. Поэтому я выбираю только российские облака и провайдеров, у которых есть понятная официальная позиция про хранение данных в РФ. Да, это иногда ограничивает выбор по функционалу, но это тот случай, когда спокойный сон дороже пары лишних фишек интерфейса.
Ещё один юридически важный момент — сроки хранения и уничтожения. RAG-технология технически позволяет хранить векторные представления документов сколько угодно, но по 152-ФЗ мы обязаны удалять персональные данные, как только цель достигнута или согласие отозвано. Это значит, что вместе с удалением резюме из ATS мы должны удалять соответствующие фрагменты из векторной базы, а ассистент обязан «забывать» этих кандидатов. Поэтому в архитектуре нужно закладывать процедуры синхронизации удаления, логи этих операций и акты уничтожения. Эту мысль я обычно подчёркиваю отдельно, потому что про неё проще всего забыть, а потом долго краснеть.
Если система «забывает» удалять вектора кандидатов вместе с резюме, она тихо нарушает 152-ФЗ, даже если интерфейс красиво показывает, что «всё удалено».
Какие инструменты использовать для создания ai ассистента
Когда базовая картина складывается, у всех возникает один и тот же вопрос: на чём это собирать, какие конкретно сервисы и платформы использовать, если ты живёшь и работаешь в России. Я в какой-то момент смирилась с тем, что идеальной «волшебной кнопки» нет, но комбинации, которые относительно быстро собираются и выдерживают требования 152-ФЗ, уже существуют. Расскажу, какие компоненты я обычно беру в работу и чем они отличаются, чтобы можно было примерить под свой стек и бюджет. Здесь речь не про рекламу, а про приземление: когда перед тобой не просто слово «RAG», а набор сервисов с тарифами, сертификацией и нормальной поддержкой.
Начну с языковых моделей. Сейчас в России для RAG-сценариев в HR чаще всего используют GigaChat, YandexGPT и решения на базе SberCloud. У всех трёх есть варианты развёртывания в облаке, у кого-то — on-premise-версии для крупных компаний. Я смотрю на три вещи: где физически хранятся данные, есть ли ограничения на использование для ПДн (иногда в пользовательском соглашении могут быть сюрпризы) и насколько модель дружелюбна к русскому деловому языку. GigaChat, например, хорошо чувствует российский контекст и документы, YandexGPT удобно встраивается в экосистему Яндекса, а SberCloud хорош, когда нужна более гибкая конфигурация и высокая нагрузка. Я не ищу «лучшую модель в мире», мне нужна достаточно стабильная, понятная юристам и ИТ.
Следующий элемент — векторная база. В российских условиях это либо сервисы в составе облачных платформ (у того же Сбера, Яндекса, VK), либо отдельные решения, которые можно развернуть на собственных серверах. Я смотрю на поддержку шифрования, возможность разграничения доступа, удобство интеграции через API и, честно, на внятность документации. HR-ассистенту потом жить годами, и чем прозрачнее будут описаны методы записи и удаления векторов, тем меньше сюрпризов будет у разработчиков при сопровождении. Иногда компании, которые уже активно сидят на 1С или Bitrix24, пробуют «встроить» RAG в их экосистемы через кастомные модули, и это тоже рабочий путь, если ИТ-команда готова этим заниматься.
Связующая логика для меня почти всегда означает n8n, особенно если в компании уже есть люди, которые умеют собирать автоматизации и интеграции. В редких случаях берут Make.com или аналогичные сервисы, но их судьба в России чуть менее предсказуема, поэтому для долгоживущих процессов я всё же предпочитаю то, что можно при необходимости поднять внутри периметра. В n8n удобно строить цепочки: триггер от бота или веб-формы, проверка прав пользователя, запрос к ATS, формирование поискового запроса к векторной базе, обращение к LLM, форматирование ответа и логирование. Плюс, HR-отдел через какое-то время начинает сам просить маленькие автоматизации поверх ассистента, и это можно реализовать в том же инструменте, не привлекая каждый раз разработчиков.
Отдельное место занимают интерфейсы. Я видела рабочие варианты и в виде простых веб-чатов на внутреннем портале, и в виде мини-приложений в корпоративных мессенджерах, и через телеграмм боты, которые подключаются к внутренней API. Вопрос «на яндекс или в Телеграм» здесь вторичен: критично, чтобы сам ассистент жил в инфраструктуре, где нет риска ухода ПДн наружу. При этом телеграмм сам по себе в России давно превратился в стандарт рабочего общения, и HR-ассистент в виде бота часто заходит гораздо легче, чем новый раздел на портале. Я не отрицаю и формат, когда у компании есть отдельный сайт про автоматизацию, вроде проекты по AI-автоматизации на promaren.ru, и там показывают кейсы, как именно собирали такие ассистенты — это помогает объяснять идею не только внутри, но и партнёрам.
И последнее — мониторинг и логи. Это не самая романтичная часть, но без неё мы не узнаем, как ассистент работает, где ошибается и не делает ли чего-нибудь лишнего. Я всегда закладываю в архитектуру журналы запросов (без лишних ПДн), логи обращений к ИСПДн, трекинг удаления данных, а также элементарную аналитику: сколько вопросов в день, какие темы самые частые, где пользователи поправляют ассистента. Это не только помогает улучшать промпты и базу знаний, но и подготавливает аргументы для диалога с руководством: можно показать не картинку «у нас тут ИИ», а «мы сократили среднее время ответа на запрос сотрудника в два раза и одновременно снизили нагрузку на HR-линию». Чтобы зафиксировать критерии выбора инструментов, мне удобно сформулировать их в одной сжатой фразе.
При выборе инструментов для HR RAG-ассистента я смотрю на три вещи: локализация и законность, удобство интеграции с уже живущими HR-системами и понятность интерфейсов для не-технарей.
Как не запутаться в платформах для создания ai ассистента
Рынок сейчас любит бросаться фразой «платформа для создания ai ассистента», но под этим может скрываться очень разный зоопарк: от простых конструкторов Q&A-ботов до серьёзных систем управления интеллектуальными агентами. Я каждый раз уточняю, что именно нужно HR-команде: только быстрые ответы на частые вопросы или ещё и поддержка RAG, роли, маршрутизация, логи, интеграции с ATS и кадровыми системами. Если нужен именно доступ к внутренней базе знаний компании, без этого RAG никуда, а значит платформа должна поддерживать подключение к вашим хранилищам, векторизация документов и настройку retrieval-процессов. Простые «чат-боты по FAQ» здесь не подходят, они хороши на старте, но дальше становятся узким горлышком.
Иногда ко мне приходят с запросом «нам нужен ассистент на Яндексе, потому что у нас всё остальное уже там» и спрашивают, реально ли построить полноценное создание ai ассистента на яндекс инфраструктуре. В большинстве случаев ответ «да, но»: да, если использовать их LLM и облако, поднять отдельную векторную базу и связать это с вашей ATS или CRM. «Но» в том, что придётся тщательно разбирать пользовательские соглашения, настройки приватности и схему аутентификации, чтобы не получилось, что ассистент «тащит» куда-то лишнее. Зато интеграция с остальными сервисами Яндекса (почта, диск, формы) может дать очень удобные сценарии: от автоматического разбора резюме до обновления внутренних регламентов через знакомые инструменты.
В более сложных случаях, когда речь идёт о холдингах или компаниях с жёсткими требованиями по ИБ, выбирают гибридный путь: LLM и векторная база живут в отдельном частном сегменте, на который никто извне не смотрит, а интерфейсы к ассистенту строятся уже поверх, как витрины. Платформы в стиле «агентских систем» иногда берут на уровне группы компаний, чтобы управлять не одним ассистентом, а целым зоопарком (HR, финансы, закупки, IT-поддержка), и там HR-ассистент становится одним из модулей. Это уже другая лига по сложности, но принципы те же: локализация, прозрачный доступ к базе знаний, понятные роли, вменяемые логи. Для тех, кто только заходит в тему, я честно советую начинать не с «суперплатформы», а с одной хорошо настроенной RAG-цепочки под конкретный процесс: например, поиск кандидатов и ответы на вопросы сотрудников по отпускам.
На этом этапе ещё полезно заранее договориться, кто будет «хозяином» ассистента: HR, ИТ, ИБ или совместно. Если этим занимается только ИТ, есть риск, что через полгода HR скажет «нам неудобно», но никто не заложил ресурсы на доработку. Если только HR — ассистент может остаться без нормального мониторинга и сопровождения. Идеальная связка для меня выглядит так: HR формулирует потребности и сценарии, ИТ отвечает за архитектуру и интеграции, ИБ — за контроль доступа и риски, а кто-то один (хотя бы 0.25 ставки) получает роль «продукт-оунер ассистента». Удивительно, но когда это проговариваешь вначале, потом меньше разговоров «а кто это должен править». Для наглядности одну мысль я подчеркну.
Платформа не спасёт, если у ассистента нет «хозяина» и понятного владельца процесса — тогда он превращается в ещё один забытый проект, а не в рабочий инструмент HR.
Как проходит процесс внедрения в реальном HR-отделе
На практике внедрение RAG-ассистента в HR-отделе гораздо меньше похоже на установку программы и гораздо больше — на неторопливый ремонт в квартире, где вы продолжаете жить. Всё вроде бы работает и без ассистента, но хочется сделать лучше, и при этом никто не даст остановить найм, оформлять людей и отвечать на вопросы сотрудников. Я обычно разбиваю внедрение на несколько волн, чтобы не свести всех с ума: сначала пилот на одном-двух сценариях, потом расширение, потом постепенная интеграция в повседневную жизнь HR. При этом многие неожиданности вылезают не на уровне технологий, а на уровне привычек людей, и это нормально.
Первая волна почти всегда посвящена подготовке данных и согласованию прав доступа. Мы выбираем один понятный сценарий: например, поиск кандидатов по стеку и стажу для IT-подбора или ответы сотрудникам на вопросы об отпусках по внутреннему регламенту. Собираем документы, чистим их, обезличиваем резюме, описываем форматы хранения, настраиваем векторизацию и проверяем, что из RAG никто не может вытащить больше, чем ему положено по роли. HR в этот момент чуть переживает, потому что им кажется, что мы «отбираем» у них доступы, но потом они же говорят спасибо, когда видят аккуратные разграничения и понимают, что любой доступ теперь осознанный и зафиксирован в журнале.
Вторая волна — обучение HR-пользователей и тестирование сценариев. Здесь всплывает масса бытовых мелочей: кто-то пишет ассистенту длинными сообщениями, как человеку, кто-то — короткими ключевыми словами, кто-то вообще боится «нагружать систему». Я в этот момент не читаю нотации, а показываю, как запросы превращаются в действия: вот вы написали так — вот какие документы ассистент подтянул, вот почему он ответил именно этой фразой. Один из любимых моментов: когда рекрутер понимает, что можно задать комплексный вопрос в духе «подбери мне кандидатов для финтех-проекта на Python, которые не откликались в последний месяц и готовы к релокации в Казань», и получить вполне осмысленный список, а не ковыряться в фильтрах. К этому люди привыкают, но первая реакция всегда чуть удивлённая.
Третья волна — интеграция в реальные процессы. Здесь ассистент «выпускается в продакшн»: его подключают к боевой ATS, внутреннему порталу, корпоративному мессенджеру. Мы включаем детальное логирование, договариваемся с ИБ, что первые месяцы они могут смотреть на логи с особым вниманием, и собираем обратную связь от HR и сотрудников. На этом этапе особенно полезно увидеть, какие вопросы и запросы ассистент не вытягивает: это подсвечивает дыры в базе знаний или плохо описанные процессы. Например, если ассистент постоянно путается в вариантах оформления удалёнки, значит, в регламентах или в кадровой системе нет чёткой, однозначной логики, и это стоит исправить не в ассистенте, а в самой политике.
Четвёртая волна — расширение сценариев. Когда базовые вещи отработаны, HR-отдел обычно приходит с новыми идеями: «а давай он ещё будет подсказывать, какие вопросы задать кандидату на собеседовании, исходя из его опыта», «а давай он будет помогать готовить оффер с правильными формулировками и выдержками из внутренних положений», «а можно ли, чтобы он напоминал про истечение согласий ПДн». На этом этапе особенно удобно иметь гибкую автоматизацию через n8n или аналоги: можно докручивать новые ветки логики без полного пересбора системы. И, конечно, всё это возвращает к тем самым журналам и актам: чем больше сценариев, тем важнее, чтобы всё, что связано с ПДн, было прозрачно и аккуратно описано в документах.
Чтобы чуть структурировать типичный путь внедрения по ощущениям HR, я однажды нарисовала себе такую внутреннюю «шкалу принятия ассистента», и до сих пор вижу, что она примерно совпадает с реальностью: сначала лёгкий скепсис, потом осторожное любопытство, потом «а что, так можно было», и дальше уже обида, если ассистент вдруг временно не работает. Чтобы поймать это ощущение, мне нравится оформить его в виде небольшой цитаты, которую я часто повторяю на внутренних встречах.
Первые месяцы HR относятся к ассистенту как к эксперименту, а через полгода — как к воде в кулере: он просто всегда должен быть под рукой, и только по его отсутствию понимаешь, как сильно он врос в повседневность.
Как перестроить процессы HR под ассистента, а не наоборот
Одна из типичных ошибок — пытаться натянуть ассистент на старые процессы, где всё держится на неформальных договорённостях и «мы всегда так делали». Я поняла, что гораздо продуктивнее использовать создание ai ассистента для базы знаний компании как повод аккуратно перестроить сами процессы: убрать дублирующие шаги, стандартизировать форматы, договориться о едином месте хранения документов. Например, если до этого часть согласий кандидатов хранилась в ATS, часть — в почте, часть — в бумажных папках, то для RAG такой зоопарк неприемлем: мы должны решительно выбрать один источник истины и всё туда свести. Ассистент, по сути, подсвечивает эти рассинхроны: там, где ему трудно, обычно и людям было трудно, просто они уже привыкли мириться.
Я стараюсь начинать с описания целевых пользовательских историй: как рекрутер будет искать кандидата, как HR-генералист будет отвечать сотруднику по отпускам, как руководитель будет получать аналитику по закрытию вакансий. Мы рисуем эти истории буквально на доске, без технологий, а потом смотрим, какие шаги можно убрать, какие — автоматизировать, какие — отдать ассистенту. Например, если раньше рекрутер сначала вручную смотрел, есть ли согласие у кандидата, а потом уже писал ему, то теперь ассистент может сразу отсеять тех, у кого согласие истекло, и предложить шаблон письма о продлении. Это освобождает время и одновременно снижает риск забыть про законность общения.
Второй момент — обучение команды задавать вопросы ассистенту правильно. Не в смысле идеального формата, а в смысле осознанности: если ассистент должен опираться только на вашу базу знаний, имеет смысл явно указывать, чего вы от него хотите. Вместо «подскажи по отпускам» — «подскажи, сколько дней отпуска осталось у меня по состоянию на сегодня и какие пункты положения на это влияют». Вместо «найди кандидатов» — «найди кандидатов с опытом от трёх лет в backend на Java, с опытом в телекоме, с действующим согласием на обработку ПДн, которых мы ещё не звали на собеседование в этом месяце». Это не магия промптов, а обычная логика: чем яснее запрос, тем полезнее ответ.
Третий момент — формализация обратной связи. Я всегда прошу HR в первые недели помечать, где ассистент ошибся, не дотянул или, наоборот, приятно удивил. Это можно делать через простые кнопки «полезно/не полезно» в интерфейсе или через отдельный чат для комментариев. Потом мы раз в неделю садимся и разбираем эти случаи: где нужно докинуть документы в базу знаний, где поправить промпты, где изменить бизнес-логику. В итоге ассистент постепенно становится действительно «своим», а не навязанным чёрным ящиком, и HR начинает ощущать, что у него есть влияние на то, как он работает. Эту часть процесса я люблю подчёркивать, потому что от неё напрямую зависит принятие технологии командой.
RAG-ассистент хорошо работает там, где HR-команда воспринимает его как совместный проект, а не как навязанную сверху игрушку, которую «просто надо терпеть».
Какие подводные камни ждут по 152-ФЗ и где чаще всего ошибаются
Как человек с корнями во внутреннем аудите и ИТ-рисках, я не могу пройти мимо подводных камней. В HR-автоматизации на базе RAG они появляются ровно на стыке «нам хочется быстро и удобно» и «закон просит медленно и аккуратно». Я собрала несколько типичных ошибок, которые встречала в российских компаниях 2024-2026 годов, и каждый раз удивлялась, насколько они похожи между собой. Хорошая новость — почти все из них лечатся, если вспомнить про риски в начале проекта, а не в момент первой проверки Роскомнадзора.
Первая ошибка — игнорирование локализации. Да, я уже говорила, но повторю: как только в цепочке появляется зарубежный облачный сервис, который хоть как-то касается ПДн (пусть даже через обезличенные вектора), вы автоматически попадаете в зону риска по 152-ФЗ. Одна компания решила не заморачиваться и использовала модный зарубежный сервис для векторной базы, мотивируя это тем, что «там только вектора, а ID кандидатов мы хэшируем». На проверке вопрос решили жёстко: «можно ли по этому ID восстановить личность через ваши же системы», и ответ оказался «да». Штраф, пересбор архитектуры, много испорченных нервов. Здесь RAG сам по себе не виноват, виновата тяга к «красивым игрушкам» без юридической экспертизы.
Вторая ошибка — отсутствие внятных ролей и журнала действий. В одном пилоте ассистент был построен так, что любой HR-специалист мог через него увидеть резюме любых кандидатов и сотрудников, независимо от своего функционала. Это удобно в первый день, а потом превращается в классический инцидент: стажёр случайно находит в истории ассистента информацию о зарплате сотрудника из другого отдела. Формально это утечка ПДн и нарушение принципа минимально необходимого доступа. Пришлось экстренно вводить разграничения по отделам, ролям и сценариям, а журналов действий на тот момент ещё не вели. Здесь RAG опять ни при чём, просто стал ускорителем уже существующего беспорядка.
Третья ошибка — неаккуратная работа с согласием и сроками хранения. Многие HR-команды до сих пор воспринимают согласие кандидата как «один раз подписал — и дальше мы можем хранить резюме вечно». 152-ФЗ давно так не считает, а с цифровизацией согласий через Госуслуги всё ещё резче: человек может централизованно отозвать согласие, и оператор обязан прекратить обработку в разумный срок. В RAG-системе это означает, что нужно синхронизировать истечение согласи и удаление векторов, и не только в ATS, но и во всех связанных системах. Одно из самых неприятных ощущений — когда выясняется, что ассистент продолжает «знать» о кандидатах, которых вы формально уже удалили. Поэтому у меня внутреннее правило: сценарии удаления и отзывов согласий проектируем раньше, чем сценарии поиска и подбора.
Четвёртая ошибка — переоценка «анонимности» обезличенных данных. В одном проекте HR уверяли, что база для обучения и тестирования ассистента полностью белая: только должности, навыки и описания опыта. Потом выяснилось, что в части описаний люди упоминали уникальные проекты, названия вузов и годы выпуска, а ещё редкие сертификации. В совокупности это позволяло легко идентифицировать конкретного человека внутри узкого рынка. Юрист, конечно, был не в восторге. Пришлось дополнительно прогонять данные через механизмы маскировки и генерализации: уходить от точных дат к диапазонам, от специфичных названий к категориям. RAG всё это переварил нормально, а вот HR поначалу переживали за качество поиска, пока не увидели, что смысловые сигналы никуда не делись.
Чтобы чуть систематизировать эти подводные камни, я однажды свела их в одну фразу, которую теперь повторяю почти автоматически при обсуждении рисков с заказчиками. Для наглядности оформлю её как отдельный акцент — пусть будет как небольшой напоминатель на полке.
RAG не избавляет от требований 152-ФЗ, он только усиливает последствия любых нарушений, потому что делает доступ к данным быстрее и шире.
Как минимизировать риски при проектировании HR-ассистента
На практике минимизация рисков начинает работать, когда за столом одновременно оказываются HR, ИТ и ИБ, а не когда каждый сидит в своём углу. Я обычно прошу команду вместе ответить на несколько вопросов: какие категории ПДн будут проходить через ассистента, какие операции он будет делать (поиск, просмотр, генерация писем), кто именно и в каких сценариях будет им пользоваться, какие регистры и журналы уже ведутся и какие нужно добавить. Это не про создание «папки для проверяющих», а про понимание того, что ассистент не должен расширять зону риска, а наоборот, помогать её контролировать. После этого складается список конкретных мер: шифрование, разграничение доступа, логирование, процедуры удаления, регламенты для пользователей.
Один из самых эффективных приёмов — рисовать «карту данных ассистента»: откуда данные приходят, где и в каком виде хранятся, что именно уходит в LLM, какие метаданные логируются. Когда это всё лежит на одной схеме, становится легче спорить с собой: правда ли нам нужно передавать в контекст ассистента полные карьерные треки кандидатов или достаточно краткого описания навыков, стажа и отрасли. Часто после такого упражнения количество передаваемых данных сокращается в разы, а качество ответов остаётся достаточным. Это и есть тот самый white-data-подход, который позволяет спать спокойнее и HR, и DPO.
Не стоит забывать и про обучение пользователей с точки зрения безопасности. HR-специалистам важно проговорить простые вещи: ассистент не должен использоваться для пересылки сканов документов, обсуждения чувствительных персональных данных (здоровье, политические взгляды, религия), передачи паролей и прочих радостей. Я обычно делаю короткое «code of conduct» по работе с ассистентом: что ок, что не ок, какие примеры запросов лучше избегать. Это не превращается в толстую инструкцию, но снижает шанс, что кто-то по привычке скинет ассистенту полную медицинскую справку кандидата, чтобы «посмотреть, что ИИ скажет».
И, конечно, нужен сценарий на случай инцидента. Как только мы автоматически логируем обращения к ассистенту, становится легче восстанавливать картину, если что-то пошло не так: кто запросил, какие данные были затронуты, было ли превышение прав, как быстро мы можем отреагировать и уведомить Роскомнадзор, если это требуется. Я всегда настаиваю на том, чтобы этот сценарий был описан в документах и хотя бы один раз проигран в формате учений: да, звучит театрально, но лучше провести репетицию с участием HR, ИТ и ИБ, чем репетировать вживую с проверяющими. В конце концов, RAG-ассистент — это не только про скорость и удобство, но и про ответственность.
Если у HR-ассистента нет плана на случай инцидента, то это не ассистент, а ещё один непредсказуемый участник системы, который может подвести в самый плохой момент.
Что даёт RAG-ассистент HR в цифрах и в чувствах
Иногда мне говорят: «ну ладно, всё законно и аккуратно, но где польза, кроме ощущения технологичности». Здесь я возвращаюсь к любимому занятию — считать, сколько времени и сил съедает ручная работа. В типичном HR-отделе средней московской компании (человек 300-500) рекрутеры и HR-генералисты тратят до трети рабочего времени на поиск информации: резюме, статусов кандидатов, регламентов, ответов на повторяющиеся вопросы сотрудников. Когда появляется hr ai ассистент, который берёт на себя большую часть этих поисков, время на типичные операции падает в среднем на 20-40 процентов. Кто-то тратил 20 минут на поиск нужных кандидатов в ATS, теперь это занимает 1-2 минуты. Кто-то полчаса формулировал письмо с выдержками из положения, теперь ассистент за пару минут даёт черновик, который нужно только проверить.
История из реального кейса: в IT-компании с плотным наймом разработчиков рекрутеры вечно не успевали обрабатывать отклики. После запуска RAG-ассистента на базе обезличенных резюме и внутренних шаблонов писем среднее время от появления подходящего отклика до первого ответа кандидату сократилось с 3 дней до нескольких часов. Ассистент не только помогал быстро находить тех, кто подходит под стек и опыт, но и генерировал персонализированные письма на основе шаблонов компании. HR перестали чувствовать, что всё время «догоняют» кандидатов, и могли больше внимания уделять самим собеседованиям. Субъективное ощущение команды было очень простым: стало чуть свободнее дышать.
Внутренний ассистент для сотрудников даёт другой эффект — снижение количества повторяющихся вопросов к HR. В одной компании, где мы его внедряли, до запуска ассистента около 60 процентов обращений в HR-чат были про одно и то же: отпуска, больничные, справки, график выплат, премии. После того, как ассистент научился отвечать на эти вопросы, нагрузка на HR-чат снизилась примерно вдвое, а качество вопросов повысилось: люди стали приходить с более осмысленными ситуациями, а не с типовыми «а сколько у меня дней отпуска». HR-специалисты начали использовать освободившееся время на более глубокие беседы с сотрудниками, работу с вовлечённостью и обучением, а не только на «пожаротушение».
Финальная картинка в цифрах обычно выглядит так: экономия 20-30 процентов времени на типовых операциях, сокращение времени ответа сотрудникам в 2 раза, снижение доли ошибок, связанных с устаревшими версиями документов (ассистент всегда тянет актуальную). При этом не стоит ждать волшебных ROI в стиле «1000 процентов за месяц»: RAG-ассистент возвращает часы, делает процессы прозрачнее и снижает риски, но не превращает HR в принца из сказки. Для меня важнее другое: люди перестают ненавидеть ту часть работы, которая связана с бесконечным поиском файлов и цитат, и могут сосредоточиться на живом общении и принятии решений. Чтобы не потерять этот акцент, я однажды сформулировала его в короткой фразе и теперь держу в голове как напоминание, ради чего всё это.
Самый честный эффект HR-ассистента — не цифра в отчёте, а момент, когда рекрутер вечером ловит себя на мысли, что устал от общения с людьми, а не от поиска структурированных данных.
Как измерять полезность ассистента, а не только «красоту технологии»
На практике полезно заранее договориться, по каким метрикам вы будете оценивать ассистента. Я обычно предлагаю сочетание трёх типов показателей: количественные (время, количество операций), качественные (удовлетворённость пользователей, качество ответов) и рисковые (количество инцидентов, связанных с данными, и близких к этому ситуаций). Количественные вещи измерить проще всего: до внедрения и через пару месяцев после смотрим среднее время на поиск кандидатов, подготовку писем, ответы на типовые вопросы сотрудников, а также количество таких операций на человека. Если появилась автоматизация через n8n, можно даже прямо в логах смотреть, сколько workflow проходит через ассистента и что он реально разгружает.
Качественные показатели требуют чуть больше внимания. Я часто запускаю небольшие опросы для HR и сотрудников: насколько удобен ассистент, насколько часто его ответы помогают без дополнительного поиска, где он ошибается или «тянет одеяло на себя». Никакой красоты в виде индекса NPS здесь не нужно, достаточно простых шкал и открытых комментариев. По этим комментариям потом отлично видно, где надо доучить ассистента, где скорректировать базу знаний, а где — честно сказать «это пока лучше решать живым HR». Иногда самые полезные инсайты приходят из фраз вроде «я всё равно пишу Коле, потому что он точно знает, как у нас принято», и это повод либо оцифровать знания Коли, либо признать, что часть вопросов действительно выходит за рамки формализуемого.
Рисковые метрики в HR-ассистенте связаны с тем, чего не произошло. Сколько раз ассистент не дал лишнюю информацию человеку без нужных прав, сколько инцидентов с рассылкой неверных версий документов удалось избежать благодаря тому, что ассистент всегда тянул последнюю редакцию, сколько раз система подсветила отсутствие согласия у кандидата до того, как ему написали. Это не те числа, которыми принято хвастаться в презентациях, но они очень важны для внутреннего спокойствия и для разговора с ИБ и юридическим блоком. Здесь же удобно фиксировать количество и характер инцидентов, если они всё-таки происходят, и смотреть, как меняется ситуация после доработок.
Мне важно, чтобы метрики не превращались в отдельный культ. Ассистент — это инструмент, а не новый KPI-объект, который нужно «кормить» цифрами. Но без измерения легко уйти в ощущения и спорить, полезен он или нет. Я обычно встраиваю метрики в уже существующую отчётность HR: не создаю отдельный ритуал, а просто добавляю пару показателей в те таблицы и дашборды, которые команда и так использует. Тогда ассистент органично вплетается в картину, а не висит отдельно как непонятный эксперимент. Одну мысль про метрики я люблю выделить отдельно, как небольшой противовес избыточной увлечённости цифрами.
Метрики ассистента нужны не для того, чтобы «доказать его окупаемость любой ценой», а чтобы вовремя заметить, где он реально помогает людям, а где мешает и требует доработки.
Куда двигаться дальше и как не утонуть в автоматизации
После первых удачных запусков у команд часто появляется соблазн: давайте теперь всё автоматизируем, пусть ассистент сам ведёт собеседования, пишет офферы, увольняет людей и вообще заменит половину HR. В этот момент я обычно делаю глубокий вдох, ставлю кружку с уже остывшим кофе подальше от клавиатуры и аккуратно говорю: нет. HR-процессы содержат очень много человеческого, контекстного, этического, и пытаться переложить это на алгоритм — прямой путь к потере доверия. HR ai ассистент хорош там, где он усиливает человека, а не пытается им стать: он облегчает доступ к данным, помогает формулировать мысли, напоминает о регламентах, но не принимает финальные решения и не выдаёт вердиктов про людей.
Я вижу развитие HR-ассистентов в России в сторону более глубокой интеграции с другими системами и более аккуратного использования данных, а не в сторону замены HR. Например, RAG-ассистент может помогать готовить отчёты по найму: анализировать, какие источники резюме дают лучших кандидатов, где стопорится воронка, какие компетенции чаще всего встречаются у тех, кто остаётся в компании больше года. При этом он всё равно будет опираться на обезличенные данные, агрегированные показатели и внутренние регламенты. В перспективе появятся связки между HR-ассистентом и ассистентами в финансах, обучении, управлении проектами, и это нормально: компания будет разговаривать с собой через связку умных интерфейсов.
Ещё одно направление развития — персонализация под роль. Ассистент для рекрутера, HR-генералиста, руководителя команды и топ-менеджера будет собирать и показывать разные вещи, хотя ядро RAG и база знаний останутся общими. Для рекрутера — удобный поиск кандидатов и шаблоны коммуникации. Для HR-генералиста — быстрый доступ к регламентам и формулировкам. Для руководителя — подсказки по грейдам, опционам, политике премирования. Для топ-менеджера — краткие выжимки о том, что происходит с рынком труда и внутренними метриками. Везде ассистент остаётся тем же «библиотекарем», просто подбирает книжки с учётом того, кто именно пришёл к стойке.
Чтобы не утонуть во всём этом, я советую честно ограничивать масштаб: выбирать один-два новых сценария в квартал и качественно их внедрять, вместо того чтобы пытаться охватить десятки направлений сразу. Хорошо работает практика «дорожной карты ассистента»: список сценариев, отсортированный по полезности и сложности. Вверху — то, что даст максимум выгоды при минимальном усилии (ответы на частые вопросы сотрудников, поиск по резюме), ниже — более сложные вещи (подготовка аналитики, интеграция с обучением, поддержка сложных кадровых процедур). Так ассистент развивается по спирали, а не взрывается от попытки сделать всё сразу. В этом месте мне хочется сделать маленький человеческий акцент.
AI-ассистент в HR — не цель, а способ вернуть себе время и немного ясности в хаос процессов; если в его погоне времени становится меньше, а хаоса больше, значит, где-то мы свернули не туда.
Где искать поддержку и как продолжать учиться
Жизнь с AI-ассистентом не заканчивается на моменте запуска, она только начинается. Технологии обновляются, регуляторка в России не стоит на месте, внутренние процессы компаний тоже меняются, и ассистенту нужно помогать за этим успевать. Я для себя выбрала стратегию «не быть одной» в этой теме: обсуждать кейсы с коллегами, читать отчёты по проверкам, смотреть, как меняются требования к обработке ПДн и как на это реагируют разные компании. Часть этого опыта я разбираю в своём телеграмм-канале, где мы с подписчиками периодически разбираем реальные сценарии автоматизации и ai ассистентов, включая RAG и связки с n8n — кому интересно, можно заглянуть в канал MAREN про AI и автоматизацию.
Есть смысл выстраивать и внутренние сообщества в компании: не только HR, но и ИТ, ИБ, аналитики данных. Совместные встречи раз в месяц, на которых разбираются кейсы использования ассистента, улучшаются процессы, обсуждаются риски, дают гораздо больше, чем разовая презентация при запуске. При желании можно привлекать внешних консультантов на точечные задачи — от аудита 152-ФЗ до настройки RAG-цепочек, — но ядро компетенций лучше постепенно растить внутри. В России уже есть достаточно материалов, конференций и сообществ, где тему RAG и HR-автоматизации обсуждают без лишнего хайпа и с реальными примерами, и это сильно облегчает жизнь тем, кто только начинает этот путь.
Для структурирования собственных знаний я часто использую простой приём: после каждого проекта или крупной доработки ассистента записываю 5-7 наблюдений, что сработало хорошо, что пошло не так, что бы я сделала иначе. Со временем из этого вырастает собственное «руководство по эксплуатации ассистента» именно в контексте вашей компании. Это, кстати, отличный материал для внутреннего обучения новых сотрудников и для объяснения партнёрам, как у вас всё устроено. Если хочется системно подойти к теме, можно заглянуть на мой сайт promaren.ru с описанием проектов MAREN в AI governance и посмотреть, как я структурирую похожие истории в других отраслях — возможно, какие-то практики окажутся переносимыми и в ваш HR-контекст.
Меня часто спрашивают, не надоедает ли всё время копаться в документах, журналах, vector search и промптах. Честно — иногда надоедает, особенно на третьем часу описания модели угроз для очередной ИСПДн. Но когда я вижу, как у HR-команды через пару месяцев появляется чуть больше воздуха в графике, как они меньше боятся проверок и больше разговаривают с людьми, вместо того чтобы искать файлы, я понимаю, что игра стоила свеч. И да, иногда ассистент ошибается, иногда n8n падает на странном символе в имени файла, иногда приходится по ночам править промпты перед демо для руководства. Но это всё мелочи по сравнению с тем, что в результате контент и процессы начинают работать на людей, а не наоборот.
Если после внедрения HR-ассистента ты хотя бы пару раз в неделю ловишь себя на мысли «я успела больше и меньше нервничала», значит, всё движется в правильном направлении, даже если в логах ещё много жёлтого цвета.
Что ещё важно знать
Как создать hr ai ассистента, если в компании ещё нет нормальной базы знаний
Я бы начала с малого и параллельно. Сначала описать один-два ключевых процесса (например, отпуска и найм в IT), собрать по ним все документы и шаблоны, привести их к единой структуре. Потом на этой небольшой, но чистой базе запускать пилот RAG-ассистента и по ходу его работы наращивать объём знаний. Не стоит ждать идеальной базы знаний, ассистент как раз помогает подсветить, чего в ней не хватает.
Можно ли использовать бесплатные зарубежные модели и сервисы для RAG в HR в России
Для реальной работы с персональными данными я бы этого не делала. Даже если сервис кажется технически удобным, отсутствие гарантированной локализации данных в РФ и соответствия 152-ФЗ создаёт высокий риск штрафов и блокировок. Такие решения можно использовать только в учебных целях или на полностью синтетических данных, но не на реальных HR-процессах.
Что делать, если сотрудники не доверяют AI-ассистенту и продолжают писать только живым HR
Сначала имеет смысл показать прозрачность работы ассистента: откуда он берёт ответы, какие документы использует, как устроены права доступа. Затем выбрать пару удобных сценариев, где ассистент точно полезен (типовые вопросы по отпускам, справкам) и мягко направлять туда людей. Со временем, когда они увидят стабильные и точные ответы, доверие вырастет, а HR всё равно останется живым каналом для сложных случаев.
Как понять, что создание ai ассистента для базы знаний компании уже окупилось
Я бы смотрела на сочетание количественных и качественных признаков. Если время на типовые операции у HR заметно сократилось, нагрузка на чат с повторами вопросов упала, а сами HR говорят, что стали меньше тратить время на поиск документов и больше — на общение и решения, значит, ассистент выполняет свою задачу. Финансовые расчёты можно делать по экономии человеко-часов относительно затрат на внедрение.
Можно ли поручать HR-ассистенту принятие решений по кандидатам
Я бы этого не делала и не рекомендовала. Ассистент отлично подходит для поиска, анализа, подготовки материалов и подсказок, но решение о найме, отказе, условиях оффера должно оставаться за человеком. И с точки зрения этики, и с точки зрения закона ответственность за такие решения несут конкретные должностные лица, а не алгоритмы.
Что делать, если Роскомнадзор заинтересовался AI-ассистентом в HR
В этом случае помогает заранее сделанная домашняя работа: уведомление об ИСПДн, описанная архитектура, модель угроз, паспорта, журналы доступа, регламенты по использованию ассистента и сценарии удаления данных. Чем прозрачнее вы можете показать, что ассистент — это надстройка над уже законной системой, а не отдельная «чёрная коробка», тем спокойнее проходит общение. Если чего-то из этого ещё нет, лучше подготовить заранее, а не в пожарном режиме.
Метки: ai-agents, rag, персональные-данные