AI-агент як внутрішній policy Q&A бот — економія 5-10 год/тиж

Коли Head of Ops компанії на 140 людей сказала, що її перебивають 30+ разів на день із "яка наша політика carryover PTO?", а HR-менеджера ще 30 разів, — ми побудували для неї policy Q&A бот за 4 дні. Найскладніше було не AI; найскладніше — знайти, яка версія handbook реально актуальна.

Що це за агент

Policy Q&A бот — це retrieval-augmented LLM (RAG), підключена до невеликої бібліотеки довірених документів — handbook, HR-політики, IT/security, expense, відпустки тощо. Співробітник питає звичайною мовою. Агент дістає релевантні фрагменти й відповідає, цитуючи документ і розділ.

Визначення: RAG (Retrieval-Augmented Generation) — архітектура, де перед відповіддю LLM крок retrieval витягує найбільш релевантні фрагменти з вашої бібліотеки в prompt. Модель "читає" ваші документи, а не запам'ятовує їх.

Це не заміна HR. Це вбивця перебивань для 80% питань, відповідь на які буквально написана десь — але жоден співробітник не може знайти. HR/Ops закриває 20% edge-case і чутливих.

Чому це правильний "перший агент" для SMB

Більшість SMB тягнуться спочатку до customer-facing агента (sales, support) — і впираються у складні проблеми: галюцинації перед клієнтом, прогалини ескалації, brand-exposure. Policy Q&A бот:

• Дивиться на внутрішніх юзерів (нижча ставка, швидше прощення помилок).
• Закритий корпус знань (ваші документи, скінченний).
• Ясна поведінка "не знаю" / ескалація (у HR/Ops Slack).
• Не вимагає складного tool-use чи multi-step reasoning.

Це агент-аналог "тренувальних коліщат" — реальна цінність, низький ризик, правильна стартова складність.

Збірка за 1 тиждень (без enterprise SSO)

День 1 — Аудит документів-джерел: яка версія кожної політики реально актуальна?
        Відповідь — письмово. Застарілі — в /archive.
День 2 — Платформа. SMB-friendly:
        • Microsoft Copilot Studio (якщо M365)
        • Google NotebookLM Enterprise (якщо Workspace)
        • OpenAI Custom GPT або Claude Project (≤50 юзерів)
        • Managed RAG (Glean, Sana, Coveo) для більших SMB
День 3 — Завантаження. Очищений набір docs. Citations on.
День 4 — Налаштування retrieval. 20 реальних питань.
        Де промазує — лагодимо джерело (зазвичай chunking).
День 5 — Ескалація. "Якщо юзер питає X — у HR Slack".
        Disclaimer: "це policy info, не legal/HR advice".
День 6-7 — Soft launch на 1 відділ. Збираємо звіти "неправильна відповідь".
          Ітеруємо retrieval. Розширюємо.

Ви не отримаєте ідеального бота на день 7. Ви отримаєте 70%-доброго бота на день 7, що стане 90%-добрим за 30 днів.

Налаштування retrieval — єдиний крок, що має значення

Якщо бот неправильний, причина майже завжди в retrieval, не в моделі. Три речі:

1. Chunking — як документи нарізаються до embedding. Завеликі — розмиває релевантність; замалі — фрагментує контекст. Старт: ~500-800 токенів на chunk, 100-токенне overlap.
2. Метадані — кожен chunk тегований назвою, розділом, effective date. Фільтр "current" перед retrieval.
3. Reformulation питання — "чи можу працювати з дому в п'ятницю?" система переписує в "remote work policy" перед retrieval. Більшість сучасних платформ роблять це автоматично; перевірте, що увімкнено.

Визначення: Embedding — числова репрезентація фрагмента тексту, що захоплює сенс. Retrieval порівнює embedding питання з усіма embedding-ами фрагментів і витягує найближчі.

Tool tip (Course for Business): Зібрати це власноруч — ідеальний "ship у тижні 1" проєкт для 5-денки. Ми рамуємо як Augment, don't replace — бот не замінює HR, він прибирає 20 переривань на день, що з'їдали HR-deep work. П'ятнична cohort-лабораторія — там співробітники справді підключають агента до політик своєї команди. https://course.aiadvisoryboard.me/business

Питання ескалації — різниця між корисним і небезпечним

Наївний бот намагається відповісти на все. Корисний знає, чого не знає — і маршрутизує.

Три правила ескалації в system prompt:

• "Якщо питання про конкретну особу (медичне, performance, конфлікт) — не відповідай. Маршрут у HR з питанням."
• "Якщо confidence retrieval нижче порогу — скажи 'я не впевнений — маршрутизую до правильної особи' і постни в HR Slack."
• "Якщо питання — legal/contractual — додай 'це policy info, не legal advice — звірте з HR/Legal'."

Klarna walked-back-AI-CSR — повчальна історія тут. Klarna відкотила свого AI customer-service агента в 2025 після падіння CSAT — прогалина була в ескалації, не в моделі. Будуйте ескалацію з дня 1.

Team scan (що чемпіони доповідають після тижня 1)

• Адопція: ~60-80% персоналу пробує бот хоча б раз у тижні 1, якщо анонсовано на all-hands.
• Топ-категорії питань: PTO/відпустка (40%), expense (20%), benefits (15%), IT/security (10%), інше (15%).
• Зекономлений час (ілюстративно): 5-10 год/тиж — HR (3-5), Ops/manager перебивання (2-4), онбординг нових (1-2).
• Найбільше джерело неправильних відповідей у тижні 1: застарілі документи. Лагодити документи, не модель.
• Топ-причина не-адопції: "не знав, що існує" — внутрішній launch важливіший за збірку.
• Виграш поза Q&A: ramp-час нових падає, бо бот відповідає на "дурні" питання, які соромно питати у менеджера.
• Чемпіон: щотижня тріажить bad-answer reports, лагодить документи.
• Сюрприз: менеджери самі використовують бот (вони теж не пам'ятають кожну політику).

Micro-case (що змінюється за 7-14 днів)

Professional services фірма на 180 співробітників побудувала бот за тиждень на наявному M365 + Copilot Studio. До дня 10 HR-менеджер повідомила відчутне падіння ad-hoc перебивань — особливо за expense і PTO carryover (60% її inbound). Нові співробітники у week-1 онбордингу ставили боту ~15 питань кожен до того, як йти до менеджера. До тижня 4 — лог із 11 неправильних відповідей; 9 — застарілі документи, 2 — retrieval tuning. Бот закривав ~75% policy-питань без ескалації.

Примітка щодо кейсу: Приклад ілюстративний — типові патерни компаній 30-500 людей, не конкретний клієнт. Числа — округлені діапазони, не гарантії.

Tool tip (Course for Business): Policy Q&A бот — підручниковий Shoulder-to-Shoulder проєкт тижня 1: кожен лід відділу в парі з AI-чемпіоном засовує політики, тюнить retrieval, шипить. До п'ятниці кожен відділ має свій шматок бота. 6-week program — ітерація неправильних відповідей у cohort-review, не в ізоляції. https://course.aiadvisoryboard.me/business

FAQ

Чи потрібен enterprise SSO і data-команда? Ні. SMB успішно шипить policy Q&A боти на Microsoft Copilot Studio, Google NotebookLM або OpenAI Custom GPT для малих команд. SSO корисний на 200+; нижче — наявний M365/Workspace login достатній.

А якщо політики розкидані по SharePoint, Google Drive і wiki? Аудит дня 1 це лагодить. Централізуйте канонічну версію в одне місце, решту — в архів. Бот наскільки добрий, наскільки корпус.

А HR-чутливі відповіді (harassment, performance)? Жорсткі правила ескалації — ніколи не відповідати. Бот каже "потрібна людина, ось як зв'язатись" і постить питання у потрібний HR-канал.

Чи довірятимуть співробітники AI у policy? Більше, ніж питати менеджера, який може помилитись. Citations критичні — бот має цитувати "Employee Handbook §4.2", щоб юзер міг звірити. Без citations довіра падає.

Це "AI агент" чи просто чатбот? Лінія розмита. З retrieval + ескалаційними діями (post у Slack, ticket) — це агент. Назвіть як любите; архітектура та сама.

Що зробити цього тижня

Якщо HR, Ops чи менеджери ловлять одні й ті ж 20 питань щотижня — ваш перший агент — policy Q&A бот, і він може бути живим за тиждень. Складне — не AI, а аудит документів.

Якщо ви хочете, щоб кожен співробітник впровадив свою першу AI-автоматизацію за 5 днів — забронюйте 30-хвилинний дзвінок: https://course.aiadvisoryboard.me/business