За один вечер вы сможете собрать черновик системы, которая сократит выбор кандидатов из кадрового резерва с двух недель до 10 минут. На следующей встрече с руководством вы не просто назовете фамилию, а дадите четкое обоснование своего решения на основе данных. И не на языке HR (который никто кроме HR не понимает), а на языке, на котором говорит Ваш клиент - IT компания.

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

«Золотая рыбка» никуда не делась — она просто обзавелась AI-агентом

В прошлой статье этой серии мы говорили про роль HR Generalist как «золотую рыбку»: исполнителя чужих желаний без собственного продукта, который поэтому не может масштабироваться и дорого стоить. Есть риск, что с приходом AI-агентов эта роль никуда не денется — просто теперь она будет исполнять желания быстрее.

Посмотрите на то, как чаще всего звучат задачи, которые прилетают HR: «срочно, кого из резерва можно назначить на эту роль». Это инцидентная постановка вопроса — разовая, под конкретный момент. Чтобы ответить, приходится бросить всё остальное, провести отдельное исследование, сравнить кандидатов, обосновать выбор. А после того как решение принято и все выдохнули — эта работа никуда не оседает. В следующий раз, когда прилетит похожий запрос, всё начинается заново, с чистого листа.

Соблазн — поручить эту беготню AI-агенту. И это действительно ускорит дело. Но если каждый такой инцидент агент обрабатывает как разовый запрос — собирает данные, формирует ответ, отчитывается — а результат этой работы никуда не сохраняется как переиспользуемая структура, вы получаете не систему, а агента-передатчика: он просто толкает отчёт по каждому отдельному запросу, вместо того чтобы строить конвейер, который сам решает повторяющиеся задачи. Тот же паттерн «золотой рыбки», просто в новой, более технологичной обёртке.

Разница между этими двумя путями и есть тема этой статьи: как построить не одноразового помощника под конкретный пожар, а систему, которая с каждым инцидентом становится умнее — вместо того чтобы каждый раз решать всё заново.

Кейс: то, что уже лежит у вас в компании

Открылась позиция Lead Data Analyst. Классический сценарий: HR открывает внешний поиск, две-три недели переписки с рекрутинговым агентством, десяток собеседований — и в процессе выясняется, что в компании уже есть человек, который тянет похожие задачи полтора года, но о нём никто не подумал, потому что он числится в другом отделе и его никто не сравнивал с требованиями этой роли.

Теперь представим другой сценарий. У вас есть человек — назовём его внутренний эксперт по кадровому резерву — который держит в голове, кто на что способен, у кого какой потенциал, кому чего не хватает для роста. Такой человек за пару дней вспомнит трёх кандидатов внутри компании, прикинет, кому из них ближе новая роль, и предложит, чему нужно доучиться. Хороший HRBP так и работает.

А теперь замените этого человека на AI-агента. Ему нужно ровно то же самое: данные о результатах людей, об их квалификации, и понимание того, куда в принципе можно расти в вашей структуре ролей. Разница не в том, какие знания требуются для рекомендации — она в том, что происходит с этими знаниями дальше: остаются они системой или растворяются вместе с закрытым инцидентом.

Одни и те же знания, разная судьба

Когда экспертизу нарабатывает человек, она остаётся с ним. Он помнит, кто из команды на самом деле тянет сложные задачи, у кого какой потенциал, кому чего не хватает для роста. Уйдёт этот человек — уйдёт и знание. Новому HR или руководителю придётся нарабатывать его заново, месяцами, а иногда и сравнимого результата так и не удаётся достичь — потому что часть контекста уходит вместе с человеком безвозвратно.

Если вы формализуете ровно те же данные и логику принятия решений в виде системы — Playbook, — знание остаётся не в чьей-то голове, а в компании. Это и есть главная причина строить такую систему: не «чтобы было модно с AI», а чтобы экспертиза стала активом, а не риском, привязанным к одному конкретному человеку — и активом, который в конечном счёте принадлежит вам как автору системы, а не растворяется в закрытых тикетах.

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

Из чего складывается эта система

Данных нужно три уровня, и они логически продолжают друг друга.

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

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

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

Сравнение первого и второго с третьим — это и есть тот самый разрыв (gap), на основе которого строится рекомендация: недостающие навыки, узкие места, зоны роста. Никакой магии здесь нет: и человек-эксперт, и агент делают один и тот же расчёт, просто у агента он воспроизводим, не зависит от настроения, забывчивости или того, что эксперт в моменте был перегружен и не подумал о ком-то из менее заметных сотрудников.

Показательно, что требования к структуре данных со стороны агента и со стороны человека совпадают не только по смыслу, но и почти буквально. Открытый стандарт MCP (Model Context Protocol), описывает доступ AI-агента к данным ровно через три типа объектов: документы и регламенты для чтения (например, описание роли или политику пересмотра грейда), выполняемые действия вроде обновления статуса кандидата или создания заявки, и шаблоны поведения для типовых ситуаций — как формулировать обратную связь, как структурировать план развития. Это тот же набор, который нужен и человеку, выполняющему ту же работу: прочитать факты, выполнить действие, использовать проверенный шаблон, а не изобретать его заново каждый раз.

RAG: как связываются знания и ИИ-агент

RAG (Retrieval-Augmented Generation) в управлении знаниями — это технология, которая дает ИИ-агенту доступ к вашей реальной базе знаний («открытой книге») прямо в момент ответа. Для HR KMS её польза критична: она полностью устраняет галлюцинации нейросети, гарантирует 100% актуальность ответов без дорогостоящего переобучения модели и сохраняет безопасность данных через разграничение прав доступа.

Чтобы построить RAG-систему или подготовить свой HR-продукт к работе с ней, HR-лиду нужно сделать три шага:

1. Навести гигиену данных (Data Layer): перевести разрозненные регламенты, матрицы грейдов и отходы процессов из сканов и переписок в структурированный текстовый формат (Markdown, CSV или чистые статьи в Wiki/Notion).

2. Описать HR Playbook (Context Layer): формализовать правила, стандарты и шаблоны решений (например, «Критерии перехода на грейд Senior» или «Алгоритм создания ИПР»), чтобы у системы был единый источник правды (Single Source of Truth).

3. Задать правила доступа и интеграции (Security & Protocol): разметить чувствительные данные (ЗП, психометрика) ролевой моделью доступа (RBAC) и отдать подготовленный реестр IT-инженерам для векторизации и подключения агента через открытые протоколы (например, MCP).

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

Регулярное и внезапное: почему инциденты не должны оставаться инцидентами

Возвращаясь к «агенту-передатчику» из начала статьи — вот в чём именно разница между ним и системой.

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

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

Ключевая ошибка, которая превращает даже AI-агента в «золотую рыбку» — обрабатывать каждый внезапный запрос изолированно и забывать о нём сразу после ответа. Правильная логика — обратная: каждый инцидент после того, как он закрыт, разбирается на вопрос «а не повторится ли это снова, и что нужно сделать, чтобы в следующий раз не собирать всё заново». Если один и тот же тип инцидента прилетает второй-третий раз — это сигнал, что пора превращать его в регулярный процесс с собственным HR Playbook, а не продолжать каждый раз решать его как в первый раз. Ваша HR KMS (система управления HR знаниями) раскладывается на два слоя:

HR Playbook = архитектурная документация, правила и стандарты (процессы HR-продукта).

HR Runbook = инструкция по ликвидации аварий/инцидентов (Incident Response), которая после разбора (Post-mortem) дописывает Playbook.

Post-mortem для HR: как Runbook превращается в Playbook

В разработке и эксплуатации есть понятие Post-mortem — разбор инцидента после его погашения. Если упал сервер, команда не просто чинит его, а пишет инструкцию (Runbook), чтобы в следующий раз автоматика справилась сама.

В HR-продукте работает тот же принцип.

• HR Playbook — это ваш код и архитектура: матрицы грейдов, стандарты оценки, регулярный процесс performance review.

• HR Runbook — это сценарий реагирования на внезапный инцидент (конфликт, внезапный уход ключевого лида, экстренный оффер).

У меня есть AI агент (оркестратор мульти агентской структуры), который управляет созданием отчета. В первое время он напоминал начальника-передаста, который буквально “проталкивает” каждый отчет. Стоило больших усилий (в основном - самодисциплины) научить его видеть работу над отчетом как конвейер, который должен работать предсказуемо и стабильно. Что надо фиксировать инциденты, разбираться с причинами их возникновения и предлагать решение, обеспечивающее работу конвейера, а не отдельной задачи.  

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

Кому и когда это нужно

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

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

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

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

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

Безопасность и гигиена данных: о чем нужно помнить до запуска агента

ИИ-агент работает строго по принципу «Garbage in — Garbage out» (Мусор на входе — мусор на выходе). Если ваша база знаний состоит из неструктурированных сканов PDF, опечаток в названии должностей в 1С и устаревших на три года отчетов, агент начнет галлюцинировать. Для нормальной работы агенту нужен чистый, понятный текстовый или табличный формат (Markdown, CSV, структурированные Wiki-страницы). Еще раз подчеркну - вопрос не столько в том, чтобы создать базу знаний, сколько в изменении собственного поведения по системной работе с ней. 

Второй критический фактор — Role-Based Access Control (RBAC). Карточка сотрудника содержит чувствительную информацию: результаты психометрики, причины отказа в повышении, текущие ЗП-грейды. В архитектуре KMS доступ агента должен быть жестко ограничен контекстом конкретной задачи. Агент, консультирующий тимлида, не должен иметь доступа к финансовым условиям или приватным психологическим отчетам сотрудников других отделов.

Кто принимает решение

Важная оговорка, без которой не стоит двигаться дальше: агент не назначает людей на должности. Он готовит рекомендацию и обоснование — какие данные учтены и почему предложен именно этот кандидат, а не другой. Решение — «да» или «нет» — всегда остаётся за человеком: руководителем, HRBP, тем, кто несёт ответственность за результат этого решения. Это не техническое ограничение сегодняшних технологий, а принципиальная граница: ответственность за судьбу конкретного человека и его карьеру не делегируется алгоритму, каким бы точным он ни казался.

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

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

HR KMS  - это сам по себе продукт

Главное, что стоит понять с самого начала: такая система — это продукт, а не документ, который один раз написали и забыли. У неё есть свои фичи (какие данные собираются, в каком виде, как часто обновляются), есть план того, что делать в первую очередь, а что — потом, и есть гипотезы, которые нужно проверять на практике: сработала рекомендация или нет, вырос ли человек так, как предполагал план развития. Часть гипотез подтвердится, часть — нет, и это нормальная часть работы с продуктом.

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

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

Что сделать на этой неделе

Возьмём для примера самый частый инцидент — «кого назначить из кадрового резерва». Вот как выглядит минимальная инфраструктура и минимальный набор данных под именно эту задачу — не абстрактно, а с конкретными источниками, откуда что взять.

Минимальная инфраструктура — без покупки чего-либо

Не нужен ни Naumen KMS, ни Huntflow AI, ни отдельный сервер. Для старта достаточно:

• Одна таблица (Google Таблицы, Excel или база в Notion) — реестр людей и ролей. Это ваш будущий слой Records.

• Одна страница-справочник ролей и грейдов — даже если сейчас это два абзаца текста, а не формальная матрица.

• Один документ-шаблон для фиксации решения по инциденту — кого рассмотрели, почему выбрали, что решили по итогу (SOP - стандарт операционной процедуры). Это то, что превращает разовый инцидент в переиспользуемую запись.

Если в компании уже есть Notion, Confluence, Битрикс24 или Яндекс Wiki — заведите реестр там, а не создавайте параллельную систему. Задача этой недели — не выбрать идеальный инструмент, а начать записывать в любой, до которого не лень будет дотянуться в следующий раз.

Минимальный набор данных — и где его взять

По каждому из трёх уровней, о которых шла речь выше, для старта достаточно совсем немного:

• Результаты (что человек уже сделал). Не нужен полноценный дашборд KPI — на старте достаточно последней оценки по итогам performance review или обратной связи от руководителя, если она хоть как-то зафиксирована в переписке или в HRM-системе (1С, Битрикс24, любая используемая в компании CRM для кадров). Если формальной оценки нет вовсе — попросите у трёх-четырёх руководителей короткий список: кто в их команде тянет больше своей роли.

• Квалификация (что человек умеет). Источники: пройденные курсы и сертификаты — обычно уже есть в личном деле или в LMS, если она используется; результаты технических тестов — если компания их проводит при найме или аттестации, эти данные почти всегда уже где-то лежат, просто не сведены вместе. Если тестов нет — на старте достаточно самооценки сотрудника по ключевым навыкам роли, собранной через простую форму. Потом добавить оценку руководителя. И т.д.

• Роли и грейды (куда можно расти). Если формальной матрицы грейдов нет — не нужно проектировать её с нуля. Возьмите три-четыре роли, которые чаще всего открываются или обсуждаются, и опишите для каждой в двух-трёх пунктах: что человек должен уметь, чтобы на неё претендовать. Это черновая версия библиотеки ролей, которую можно дорабатывать по ходу дела.

Отдельно, если хотите сразу включить внешний резерв — соберите в тот же реестр данные по кандидатам, которые дошли до финальных этапов на прошлые вакансии, но не были наняты. Обычно это уже есть в почте рекрутера, в ATS (если она есть) или в экспортах с hh.ru — задача не собрать заново, а один раз выгрузить то, что уже есть, в общий формат.

Три шага на эту неделю

На еженедельных встречах HR Product Owners Club мы выработали следующий простой алгоритм первых шагов. Выпишите один тип инцидента, который повторяется чаще всего — «кого назначить», «кого включить в резерв», «кому дать повышение» — и посмотрите, сколько раз за последние полгода вы решали его с нуля.

Соберите по этому типу задач один уровень данных (проще всего начать с ролей и грейдов — это меньше всего зависит от того, есть ли в компании формальная система оценки) в одну таблицу или страницу, а не в разрозненные файлы и переписку.

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

Это не построит вам AI-агента за неделю. Но это превратит один повторяющийся пожар в первый элемент системы — а дальше она будет расти сама, инцидент за инцидентом, вместо того чтобы каждый раз сгорать заново.

А как у Вас устроена HR KMS и помогает ли они в работе с кадровым резервом?