Як ми впровадили AI-агента у HR: архітектура, RAG і автоматизація онбордингу

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Привіт, DOU! Мене звати Ігор, я CTO в SharksCode. Ми створюємо високотехнологічні B2B-платформи та активно інвестуємо в інновації. Сьогодні хочу поділитися своїм кейсом про те, як моїй команді вдалося перетворити HR-відділ на технологічний хаб за допомогою AI-агентів.

Ми почали системно впроваджувати ШІ у другій половині 2025 року. Причина була очевидна: рутинні задачі з’їдали забагато часу. Коли команда замість розвитку продукту витрачає години на відповіді про відпустки чи пошук інструкцій — це треба виправляти.

Сьогодні ж в компанії працюють два ключові AI-агенти: агент з адаптації, що супроводжує кожного новачка з першого дня та внутрішній HR-консультант — база знань, яка постійно вчиться на запитах співробітників.

Ця стаття про наш досвід впровадження ШІ в онбординг та внутрішню підтримку. Розповідаю технічні деталі (архітектуру та стек), а також про стратегію та реальні результати.

Коли «добре» — замало: навіщо ми додали AI в HR

Коли ми з командою почали аналізувати тему AI‑агентів у HR, у компанії вже працювали вибудувані процеси онбордингу, підтримка співробітників і внутрішніх комунікацій. Але ми хотіли зробити їх швидшими, персоналізованішими та масштабованими без лінійного росту HR‑команди.

Ми бачили потенціал у тому, щоб кожен співробітник мав «миттєвий HR‑сервіс» 24/7: замість пошуку документів чи очікування відповіді в чаті — одна точка входу, яка знає політики, контекст людини та вміє діяти прямо у внутрішніх системах. Паралельно ми шукали спосіб вивільнити більше часу HR‑команди для стратегічних задач: роботи з культурою, залученістю, аналітикою та підтримкою лідерів, а не ручного супроводу однотипних запитів.

Важливим викликом було зберегти високі стандарти безпеки й конфіденційності даних, при цьому дати агентам достатньо доступу до HRIS, payroll, календаря та Jira, щоб вони могли бути не просто «чатом над документами», а повноцінними цифровими асистентами.

Результат — поява онбординг‑агента та внутрішнього HR‑консультанта Акулiни, яка зробила взаємодію з HR‑процесами для співробітників відчутно простішою й швидшою: значна частина запитів тепер закривається в self‑service‑форматі за хвилини, без зайвих листів і переписок.

HR‑команда отримала більше простору для роботи «на рівні стратегії», а не операційної рутини, зберігши при цьому контроль над критичними рішеннями та чутливими кейсами. Для новачків онбординг став більш передбачуваним, дружнім і персоналізованим: вони отримують структурований супровід з першого дня, розуміють, що й навіщо відбувається, і швидше виходять на продуктивність.

Чому ми пішли в AI-агенти

Акула — символ компанії, тому нашу AI-помічницю ми назвали Акулиною. Це не просто чат-бот, а повноцінна частина команди. Кожен новачок у свій перший робочий день бачить у календарі зустріч із нею.

Акулина знає все про зарплати, відпустки, day-off, офісні правила та політики. Найважливіше — вона адаптує відповіді під конкретну людину. Якщо вона чогось не знає, то перенаправляє запит на HR-партнера (зазвичай АІ-шки просто вигадують абищо в такому випадку).

Ми постійно тренуємо її звучати по-людськи. Наприклад, коли хтось запитує про відпустку, вона може нагадати, що відпочинок важливий для продуктивності.

Для мене як для CTO важливо, що Акулина розвантажує людей та дає команді відчуття миттєвої допомоги. Ми надали їй голос та можливість створювати задачі в Jira прямо з голосових повідомлень.

Нижче — технічний гайд про те, як ми реалізували AI‑агентів (на прикладі Акулiни) так, щоб це було зрозуміло розробникам та архітекторам.

Архітектурний підхід

Ми одразу пішли від ідеї «чат‑бота» до концепції AI‑агентів як сервісів у продуктовій екосистемі, а не як окремої фічі в HR‑куточку. Це важливо, бо агент працює з внутрішніми процесами, онбордингом, зарплатами, відпустками, оргструктурою, політиками — все це критично до безпеки.

Базовий стек по ролях:

• API‑шар (Node.js/TypeScript або Python/FastAPI) як gateway до LLM, векторного сховища та внутрішніх сервісів.
• LLM‑провайдер (хмарний, без власної LLM, але з можливістю функціональних викликів/Tool Calling).
• Векторне сховище (Postgres+pgvector або окремий векторний движок) для реалізації RAG‑підходу по внутрішній базі знань (це коли перед генерацією відповіді модель спочатку шукає релевантну інформацію у зовнішній базі знань, а вже потім формує відповідь на основі знайденого контексту).
• Message‑bus (Kafka/RabbitMQ) для асинхронних задач: логування сесій, аналітика, подальше навчання агента.
• UI‑шари: Slack/Teams/корпоративний месенджер, web‑віджет в порталі, інтеграція з календарем та Jira.

Архітектурно кожен агент — це оркестратор над LLM + RAG + набором функцій («tools»), через які він може ходити у внутрішні сервіси: HRIS (корпоративна структура, призначена для управління персоналом); payroll (система автоматичного розрахунку заробітної плати, яка охоплює облік відпрацьованого часу, нарахування фіксованої, погодинної оплати, бонусів, податків, компенсацій); calendar; Jira.

Це дозволяє нам масштабувати кількість агентів без дубляжу логіки — ми додаємо новий набір політик/ролей/функцій, а не «ще один бот з нуля».

Дані й knowledge base

Першим етапом роботи стала нормалізація HR‑контенту — впорядкування всієї інформації до єдиного формату, з яким взагалі можна ефективно працювати через LLM. Історично документи HR жили у дещо хаотичному середовищі: частина — у Google Docs або Confluence, частина — у PDF чи Slack‑розсилках типу «Колеги, у нас оновилися правила відпусток».

Ми вирішили системно підійти до проблеми й спочатку зібрали все, що мало відношення до HR‑процесів: політики, FAQ, онбординг‑гайди, оргструктуру, описи ролей, інструкції з оформлення лікарняних і дей‑офів, а також гайд із користування офісом.

Після збору даних увесь цей різнорідний масив пройшов через наш технічний пайплайн нормалізації. На першому етапі ми конвертували документи у plain text або Markdown — щоб прибрати зайве форматування та зробити текст придатним для обробки моделлю.

Потім додали семантичний спліттер, який ділить контент не механічно («кожні 512 токенів»), а за логічними абзацами й сенсовими блоками. Для кожного уривку ми згенерували метадані: зазначили тип документа, відповідний відділ, дату останнього оновлення та власника (HR, Legal або Finance).

У фіналі вся ця інформація сформувала структуровану базу знань, яку ми залили у векторне сховище. Там вона індексується за embedding‑векторами, типами документів, конкретними відділами та актуальністю останнього revision — тобто кожен фрагмент не просто збережений, а й контекстно зрозумілий системі. Завдяки цьому ми отримали повноцінний knowledge base, готовий до інтеграції в LLM‑підходи та гнучких HR‑рішень.

Залили це все у векторне сховище з індексами по:

• embedding‑вектору;
• відділу/типу документа;
• актуальності (останній revision).

Після формування бази знань ми отримали RAG‑шар — рівень, який дозволяє агенту працювати з усіма внутрішніми даними в осмислений спосіб. Завдяки йому агент може робити семантичний пошук по корпоративних політиках, об’єднувати кілька запитів в одну відповідь (наприклад, «як оформити відпустку») і водночас утримувати вбудований контекст компанії без потреби щоразу прописувати його вручну в system prompt.

З технічного боку логіка RAG‑флоу й prompt‑дизайну виглядає досить послідовно.

1. Спочатку агент приймає повідомлення від користувача.
2. Потім класифікує намір: це може бути запит про онбординг, HR‑політику, payroll, оргструктуру, емоційну підтримку чи ситуацію, коли краще «перепитати HR‑партнера».
3. Якщо запит належить до домену, який підтримується RAG, система запускає семантичний пошук у векторному сховищі та підтягує top‑N релевантних фрагментів.
4. Далі формується промпт, який складається з кількох ключових блоків: system — визначає роль агента, тон спілкування та обмеження (зокрема, «не вигадувати, якщо немає точної відповіді, а ескалювати до HR‑партнера»); company context — коротке резюме про бренд, корпоративні цінності та кодекс; retrieved context — ті контентні chunk’и, які знайшло векторне сховище; conversation history — уривки попереднього діалогу, обмежені за довжиною, щоб не перевантажувати LLM.
5. Готовий промпт передається в LLM з увімкненим function‑calling, що дозволяє інтегрувати відповідь із сервісами — наприклад, створити запит на відпустку, оновити подію в календарі чи взаємодіяти з Jira.

Ключовим у цій системі стало не лише те, як агент знаходить відповіді, а й як він їх подає. Ми спеціально навчали його спілкуватися «по‑людськи»: підтримувати співробітників у різних ситуаціях («відпочинок важливий, щоб не вигоріти»), пояснювати речі простою, зрозумілою мовою без канцеляризмів і при цьому не створювати враження зверхності чи «всезнання». Такий тон закріплений безпосередньо у system prompt і став частиною корпоративного досвіду взаємодії з агентом.

Ми навмисно заклали правило: якщо у retrieved context немає достатньо впевненості або релевантних документів, агент повинен: чесно сказати, що не знає; зібрати короткий summary запиту; перекинути питання до HR‑партнера, створивши ticket або відправивши нотифікацію (Slack/email). Це реалізовано як окрему функцію‑tool, яку LLM може викликати.

Інтеграції з HRIS, календарем та Jira

Щоб Акулiна не обмежувалася роллю «чат над документами», а стала справжнім агентом дій, ми надали їй набір чітко визначених інтеграцій для function calling. LLM тепер може самостійно викликати потрібні сервіси, перетворюючи слова на реальні операції.

Основні функції, які ми реалізували:

• get_employee_profile(user_id) — повертає базову картку співробітника: грейд, відділ, менеджер, статус probation.
• request_vacation(user_id, dates, type) — створює заявку на відпустку безпосередньо в HRIS/ERP.
• get_vacation_policy(country, contract_type) — витягує актуальні правила для конкретного типу контракту та країни.
• create_onboarding_meeting(user_id) — автоматично створює подію в календарі «Зустріч з Акулiною» на перший робочий день новачка.
• create_jira_task(project_key, summary, description, assignee) — дозволяє ставити задачі словами, без ручного заповнення полів.

Технічно це працює так: ми описуємо JSON‑схеми функцій у стилі OpenAPI (назва, параметри, типи, обов’язковість), передаємо їх LLM як доступні інструменти. Модель самостійно визначає, коли й яку функцію викликати — наприклад, на фразу «постав мені, будь ласка, задачу в Jira по оновленню онбординг‑гайду».

Наш gateway‑сервіс приймає function call, виконує реальний HTTP/RPC-запит до внутрішнього сервісу й повертає результат назад у LLM як додатковий контекст для фінальної відповіді. Цей патерн ми вже масштабували на інших агентів — HR‑консультанта, внутрішні продукт‑асистенти та подібні.

Онбординг як інтегрований процес

Ми вбудували Акулiну в онбординг як обов’язковий етап core‑флоу:

• Коли в HRIS створюється новий співробітник, тригериться event new_hire_created .
• Наш AI‑onboarding‑сервіс автоматично: створює зустріч «Знайомство з Акулiною» в календарі новачка на перший робочий день; надсилає welcome‑повідомлення в обраний канал (email, Slack чи портал); ініціалізує персональний контекст: роль, команда, менеджер, офіс/remote, мова комунікації.

Під час розмови агент динамічно підтягує релевантні блоки знань (про цінності, структуру, політики), відповідає на будь-які уточнення й моніторить поведінку користувача. Якщо бачить ознаки плутанини — довгі паузи, повторення питань чи запит на «живу людину» — автоматично ескалює до HR.

Навчання на реальних запитах

Замість класичного ML‑тренінгу (у нас немає власної LLM) ми побудували контур ітеративного вдосконалення на основі живих запитів.

Як це реалізовано: кожна сесія логиться з анонімізацією PII — фіксуються запит, retrieved контекст, відповідь та факт ескалації до HR. HR‑команда має адмін‑панель, де бачить проблемні кейси: часті «я не знаю», ескалації чи low rating від співробітників. Вони можуть додати новий Q&A або оновити політику прямо там.

Коли HR додає нову відповідь, текст проходить пайплайн нормалізації/індексації, векторна база оновлюється, і наступні подібні запити агент закриває сам. Паралельно ми оптимізували промпти на реальних діалогах: прибрали надмірну «over‑politeness» для швидкості, додали патерни TL;DR + деталізація, підправили тон — щоб звучало як розмова з адекватним колегою, а не офіційний лист від HR.

Безпека, доступи та пермішени

Окремий пріоритет — контроль того, що агент бачить і що може сказати. З онбординг‑ та HR‑агентами легко випадково відкрити чутливі дані, тому ми заклали багатошаровий захист:

Що реалізовано:

• Весь доступ до сервісів йде через API‑gateway із сервісними акаунтами, без «загальних токенів» від HRIS.
• Кожна функція перевіряє контекст користувача: user_id , роль, відділ, рівень доступу — наприклад, не можна подивитися зарплату колеги, але можна свою.
• RAG‑шар фільтрує за ACL: спочатку формується «candidate set» доступних для користувача документів, і тільки поверх нього йде similarity search.

Конфіденційність на рівні логів:

• Діалоги зберігаються в ізольованому сховищі з retention-політикою (6-12 місяців).
• Чутливі поля (payroll, health data) або не логуються, або хешуються/маскуються.

Моя роль як CTO у цій інтеграції:

З продуктової позиції я бачу AI не як окрему «фічу», а як горизонтальний шар, що пришвидшує рішення, персоналізує досвід і стає must‑have для продактів.

Організаційно: ініціатива йде від CTO та стрім‑лідів — ми формуємо roadmap, де агенти вшиті в core‑флоу, а не як демо для презентацій. Я відповідав за:

• вибір LLM‑провайдера з фокусом на безпеку, latency та вартість;
• архітектуру інтеграцій (gateway, RAG, функції);
• технічний борг і масштабованість, щоб через рік не переписувати все з нуля.

Ми не рахуємо ROI «по центам за токен», але дивимось на:

• редукцію часу HR‑команди на повторювані питання;
• швидкість онбордингу;
• NPS/CSAT внутрішнього сервісу;
• швидкість постановки задач і прийняття рішень у продакт‑стрімах.

Фактично, для нас це про те, наскільки агент знімає операційний шум і відчутно покращує досвід людей та темп роботи команд.

AI як підсилювач, а не заміна

Для мене штучний інтелект — це частина продуктової стратегії. Ми використовуємо його майже всюди: у фінансах, дизайні, розробці, маркетингу, HR. Це дозволяє будь-якій компанії бути конкурентними та робити більше за той самий час.

Зараз ми фіналізуємо HR-стратегію на 2026 рік, де ШІ буде фундаментом. Ми поки не трекаємо ROI цих впроваджень занадто жорстко, бо для нас це стратегічна інвестиція в ефективність.

Чи залишить ШІ людей без роботи? Моя відповідь — ні. У мене є чудова метафора: AI — це як мультиварка чи аерогриль на кухні. Вони сильно економять час на рутині, але шеф-кухар залишається незамінним. Тільки людина може створити новий смак, відчути настрій гостя чи розробити концепцію ресторану. ШІ готує базу, а ми додаємо сенси та творчість.

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

Людина залишається головною цінністю. AI просто забирає нудну роботу, дозволяючи нам фокусуватися на стратегії, розвитку культури та складних креативних завданнях.

Що далі

Коли ми впроваджували AI-агента Акулину в HR-процеси, то спочатку просто хотіли оптимізувати онбординг — той самий рутинний потік запитів від новачків, який забирав години в команди. Але те, що сталося далі, перевершило всі очікування.

В результаті Акулина взяла на себе мінімум 504 онбординги на рік — це одразу 45% усіх процесів, які раніше тягнулися вручну. Час адаптації співробітників скоротився вдвічі: з тижнів до кількох днів, бо кожен новачок отримує миттєві, точні відповіді на будь-які питання про політики, інструменти чи корпоративні нюанси. А операційні витрати HR впали на 30-40%, адже рутина просто зникла.

Найкрутіше — це надлюдські якості Акулини. Вона ніколи не втрачає дані, бо вся база знань лежить у векторній пам’яті з пошуком на 99.9% точності. Не хворіє, не йде у відпустку, не має форс-мажорів — працює 24/7, навіть під час блекаутів, завдяки офлайн-режиму на наших локальних серверах з Kubernetes. Може одночасно відповідати сотням людей без затримок, повторюючи один і той же гайд тисячу разів без помилок, і завжди персоналізує відповіді, витягаючи з історії конкретного співробітника потрібний контекст через RAG-архітектуру.

Результат? Retention зріс на 20-25%, бо новачки швидше вливаються в проєкти й відчувають підтримку з першого дня. HR тепер фокусується на стратегії, а не на FAQ. Ми вже бачимо повний ROI за 4 місяці. Акулина стала game changer для всієї команди.

Після успіху Акулини наступні кроки розвитку логічно випливають із наших поточних можливостей: спочатку AI‑агент для рекрутерів, який допомагає шукати кандидатів, пріоритизує за релевантністю, а людям залишає тільки інтерв’ю та презентацію компанії. Паралельно ми плануємо продуктових агентів, які агрегуватимуть дані по воронках, ретеншну та LTV, формуватимуть draft‑гіпотези й спліт‑тести, а також допомагатимуть із формалізацією вимог — перетворюватимуть ідеї на user stories та acceptance criteria в тому форматі, до якого звикла наша команда розробки.

А як у вас з AI в HR чи продукті — вже є агенти на RAG + Kubernetes чи тільки плануєте? Поділіться стеком, результатами чи болями впровадження — придумаємо разом наступні кроки для ваших команд чи моєї. Чекаю на реальні історії та фідбек у коментарях!

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.