Розробка AI-агента для автоматизації бізнес-процесів

Розробка AI-агента: чому прототип не доходить до роботи

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

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

Ламається при цьому не модель. Ламається зв'язка «модель — дані — права доступу»: інтеграція агента з обліковими системами зведена до запиту «дай усе», єдиного ключа між довідниками немає, а сервісному обліковому запису видано повні права.

Агент отримує суперечливі записи, обирає першу у видачі — і віддає відповідь, яку оператор не може прийняти без звірки з першоджерелом.

Якість відповідей агента визначається тим, що він бачить на вході. Без фільтрації за правами він або відповідає «немає даних», або показує зайве; без дедуплікації довідника обирає неактуальний запис; без збереження контексту втрачає нить на третьому уточненні.

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

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

Що змінюється в процесах після впровадження агента

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

Агент працює поверх моделей YandexGPT, тому розбір російськомовних листів і заявок іде без вивантаження даних за контур компанії.

• Частка автоматизованих операцій — типові сценарії (звірка реквізитів, розбір вхідного листа, підготовка вивантаження за регламентом) агент закриває повністю, без оператора. На обмеженому контурі це зазвичай 60–75% обсягу, залишок приходить людині вже зі зібраним контекстом.
• Час обробки звернення — класифікація та первинна відповідь займають секунди замість годин очікування в черзі; нічні та вихідні заявки більше не накопичуються до ранку.
• Помилки введення даних — агент переносить дані з документа в облікову систему напряму, без ручного передруку, і зникає цілий клас дефектів: одруки в реквізитах і суми, що потрапили не в те поле.
• Пропускна здатність відділу — зростає без розширення штату: той самий склад закриває більше звернень у пікові дні, а черга розбирається всередині зміни.
• Адаптація нових співробітників — агент підказує наступний крок за регламентом і підтягує потрібну картку клієнта, тому новачок виходить на норму за тижні, а не за місяці.
• Вартість процесу — падає не за рахунок скорочення людей, а за рахунок того, що рутина перестає вимагати ручних годин: витрати на зберігання та супровід контуру не зростають разом з обсягом.

Важливе застереження: метрики знімаємо на одному й тому самому наборі звернень, інакше порівняння нічого не доводить.

Варіанти виконання агента та їхні обмеження

Варіанти реалізації агента різняться не «розумом» моделі, а тим, до яких систем він підключений і хто відповідає за його поведінку. Готовий конструктор агентів дає швидкий старт, замовний контур — повний контроль над логікою та даними. Вибір зводиться до кількості інтеграцій і потрібної автономності.

Головне обмеження будь-якого варіанта лежить не в моделі, а в доступі: без розмежування прав агент або марний, або небезпечний для даних. Тому ми спочатку описуємо сценарії та точки запису, а вже потім обираємо варіант виконання.

Етапи інженерної роботи: від аудиту до передачі

Розробка AI-агента починається не з коду, а з розбору того, як процес влаштований зараз.

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

За підсумками аудиту процесів фіксуємо, які кроки агент забирає повністю, а які залишає людині з готовою підказкою.

1. Аудит процесів і даних. Проходимо по кожному сценарію обробки, відзначаємо джерела, частоту звернень і типові розгалуження. На виході — карта процесу з вузькими місцями, де ручна робота з'їдає найбільше часу.
2. Схема інтеграції. Визначаємо, до яких систем агент звертається на читання й на запис, як передаються дані, що відбувається при недоступності зовнішнього сервісу. Схема інтеграції узгоджується до початку складання — правки на цьому кроці дешевші, ніж переробка логіки.
3. Налаштування прав і доступів. Агент отримує мінімально необхідний набір прав, дії зі зміни даних проходять через підтвердження, усі звернення пишуться в журнал. Це дозволяє розмежувати, що агент робить сам, а що лише пропонує.
4. Складання сценаріїв. Складаємо логіку за кроками: розбір вхідного запиту, вибір джерела даних, формування відповіді, обробка відмов. Кожен сценарій закінчується зрозумілим результатом — карткою, листом або записом у системі.
5. Перевірка на історичних даних. Проганяємо агента на накопичених зверненнях і порівнюємо відповіді з тим, що робили співробітники. Розбираємо розбіжності: частину закриваємо доопрацюванням сценарію, частину — уточненням правил.
6. Дослідна робота. Запускаємо на обмеженому потоці паралельно з поточним процесом, звіряємо результат і тримаємо ручний контроль на спірних випадках. Так збій в одному сценарії не зачіпає весь обсяг звернень.
7. Передача рішення замовнику. Передаємо налаштовану систему, документацію за сценаріями та журналами, навчаємо команду вносити правки й розбирати інциденти. Після цього супровід іде силами замовника або з нашою підтримкою.

Документація, схеми та регламенти супроводу

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

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

• Документація на агента — схема потоків даних: які системи віддають дані, де агент бере базу знань, куди пише результат, які зовнішні виклики можуть не відповісти і як обробляється відмова.
• Опис сценаріїв і промптів — за кожним типом звернення: що запускає агента, які кроки він проходить, де закінчуються його повноваження і за якою умовою діалог переходить до оператора.
• Матриця доступу — перелік облікових записів і прав агента в кожній системі, явні заборони, власник доступу та порядок його відкликання при зміні співробітника.
• Набір тестових сценаріїв — розмічені звернення з еталонними відповідями: прогін перед кожним оновленням показує, що нова версія не зламала раніше робочі гілки.
• Інструкція для підтримки — що робити при типових збоях: мовчання зовнішньої системи, порожня або нерелевантна відповідь, неправильна маршрутизація, ручний перевід діалогу на людину.
• Регламент супроводу — періодичність перевірок якості, порядок правки промпту, правила відкату на попередню версію, відповідальні та строк реакції на звернення.
• Журнал змін — версія, суть правки, причина та на яких тестах вона перевірялася.

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

Кейс: як агент розвантажив обробку вхідних заявок

Де процес упирався

Служба обробки звернень працювала на межі: у пікові дні в черзі висіло до 400 нерозібраних заявок, а першу відповідь клієнт отримував через 6–9 годин. Більше половини запитів були типовими — статус заявки, продовження доступу, комплект закривальних документів.

Оператор вручну збирав дані з трьох систем, переносив їх у відповідь і все одно повертав на доопрацювання кожне п'яте звернення: у тексті не вистачало контексту, і клієнт писав повторно.

Що саме зробили

Агента вбудували не «над» процесом, а всередину нього. На вході він розбирає текст звернення, визначає тип запиту та витягує сутності — номер договору, контрагента, період.

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

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

Правила версіонуються, будь-яка дія агента логується, помилкова відповідь відкочується і переводиться в ручний режим.

Метрики після трьох місяців

Частка автоматичних закриттів заявок вийшла на 43% від усього вхідного потоку. Час першої відповіді скоротився з 6–9 годин до 4 хвилин у робочі години і до 15 хвилин уночі.

Частка повернень на доопрацювання впала з 21% до 6% — переважно за рахунок того, що оператор отримує звернення вже зі зібраним контекстом. Навантаження на зміну знизилося приблизно на третину, і ті самі люди стали розбирати спірні випадки замість копіювання даних між вікнами.

Що робити, якщо прототип агента вже зібраний на платформі

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

Звідси й вибір із двох — доопрацювання замість переписування або перенесення логіки в керований контур.

Ревізія прототипу — це прогін готового прототипу агента на справжніх зверненнях за минулий період, а не на підготовлених прикладах.

Дивимося частку відповідей, прийнятих співробітником без правки, поведінку на порожньому, суперечливому та занадто довгому вводі і число звернень до моделі на одну задачу: останнє визначає, як агент поведеться при зростанні навантаження.

Далі рахуємо технічний борг. Типовий набір: промпти та правила живуть у коді без версіонування, стан діалогу зберігається в пам'яті процесу і втрачається при перезапуску, немає журналу викликів і розмежування прав на інструменти, відкат можливий лише повним вимкненням. Кожен пункт — окремий клас відмов у роботі, а не косметика.

Доопрацювання замість переписування виправдане, коли сценарії підтверджені, а борг локальний і знімається поверх наявного коду.

Перенесення в керований контур потрібне, якщо прототип зібрали на платформі-конструкторі на кшталт n8n і він уперся в її рамки: немає тонкої обробки помилок, складно розвести середовища, не зібрати регресійний набір. Критерій один — що простіше утримувати в робочому стані.

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

Вмикаємо поетапно: спочатку один процес із ручною перевіркою результату, далі — у міру зростання частки прийнятих відповідей.

Часті технічні сумніви перед стартом проєкту

Сумніви на вході майже завжди ті самі — знімаємо їх архітектурою, а не обіцянками.

Які права отримує агент?

Окремий сервісний обліковий запис із мінімально потрібними правами: читання довідників, створення чернетки, передача на погодження. Зміна та видалення залишаються за людиною — підтвердження вбудовано в сценарій обов'язковим кроком.

Як перевірити якість відповідей?

До запуску збираємо еталонні сценарії з очікуваним результатом і проганяємо їх при кожній правці інструкцій або зміні моделі. Відповідь без опори на документ агент не віддає — при нестачі контексту діалог переходить до оператора.

Чи не прив'яжемося до одного постачальника моделі?

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

Хто відповідає за результат після передачі?

Передаємо сценарії, інструкції та спостережуваність: журнали викликів, метрики якості, порядок відкату на попередню версію. Ваші інженери навчаються на своєму контурі; гарантійний період покриває дефекти реалізації, далі — підтримка за регламентом.

Що підготувати, щоб ми повернулися з оцінкою та планом

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

• Межі процесу: з якої події він починається, яким результатом завершується і хто в ньому бере участь.
• Системи-джерела даних і спосіб доступу до них — програмний інтерфейс, вивантаження файлом, база, доступ лише на читання.
• Приклади реальних вхідних даних: 10–20 знеособлених звернень або документів з очікуваним результатом — за ними визначається метрика якості.
• Що агент робить сам, а що підтверджує людина: де обов'язковий оператор, де допустима автоматична дія.
• Обмеження: персональні дані, вимоги до зберігання та журналювання, контур розгортання — своя інфраструктура або хмара.
• Обсяг: скільки звернень на добу, пікове навантаження, число сценаріїв і типів документів.
• Критерій приймання: частка коректних відповідей, час обробки, частка задач, знятих з оператора.

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

Порядок взаємодії фіксуємо заздалегідь: де показуємо проміжний результат, хто на вашій стороні приймає його і на якому етапі підключається команда супроводу.