AI-агент у документообігу: де закінчуються його повноваження
Доручення «опрацюй лист постачальника» звучить просто, поки не доходить до дії в системі. Знайти пов’язаний договір, підготувати заявку, змінити адресу доставки й повідомити контрагента — різні повноваження. Якщо об’єднати їх в одне нечітке завдання, працівникові буде складно зрозуміти, що вже виконано, а що ще чекає на його рішення.
AI-агента корисно проєктувати як учасника процесу з визначеною роботою: що йому доручено, які зміни дозволені та кому він передає винятки. Розберемо таку роль на ілюстративному запиті про зміну адреси доставки. Це запропонована логіка організації роботи, яку можна перевірити під час пілота.
Спочатку доручення, потім автономність
У матеріалі про AI-агентів InBase описує класифікацію вхідних документів, маршрутизацію та підготовку чернеток. Ці приклади підказують корисний початок розмови: яку саме підготовчу роботу організація хоче передати системі?
Anthropic розрізняє наперед задані маршрути виконання та агентів, у яких модель вибирає наступні кроки й інструменти. Компанія рекомендує починати з найпростішого достатнього рішення. Отже, якщо послідовність дій уже відома, потребу в агентському виборі варто обґрунтувати окремо.
Звичайний маршрут теж може викликати мовну модель, наприклад для підготовки тексту. Це ще не робить весь процес агентським. Для пілота назвіть конкретний вибір, який передаєте моделі: визначити, яких матеріалів бракує, або вибрати наступну дозволену перевірку залежно від отриманого результату.
Для нашого прикладу доручення можна сформулювати так: знайти матеріали до листа й підготувати пропозицію зміни для відповідального працівника. Корисний результат — зібрана заявка, з якою можна працювати далі. З’ясуйте, де зараз людина витрачає зусилля: шукає договір, переписує дані чи визначає адресата погодження. Саме цю роботу включіть у перше випробування.
Права описують дієсловами
OWASP пов’язує ризик надмірної агентської автономності з зайвими функціями, дозволами та свободою дій. Серед рекомендацій — мінімально потрібні інструменти, погодження значущих операцій і перевірка авторизації в системах, які ці операції виконують.
Для пілота перетворіть загальне «доступ до документообігу» на перелік конкретних дій. Окремо визначте читання матеріалів, створення чернетки, передавання заявки та зміну робочих даних. Інструкція моделі пояснює задачу; налаштування системи мають забезпечувати її межі. Лист постачальника є вхідними даними й сам по собі не надає додаткових прав.
- Читати: тільки матеріали, потрібні для дорученої заявки.
- Готувати: пропозицію зміни з посиланням на вхідний лист.
- Передавати: завдання визначеному учаснику процесу.
- Змінювати: лише дозволені поля після передбаченого погодження.
Це початкова схема ролі, яку слід уточнити разом із власником процесу. Наприклад, право зареєструвати заявку ще не означає права оновити довідник контрагентів або надіслати зовнішнє повідомлення.
Попросіть показати й заборонену дію в тестовому середовищі. Якщо агент спробує змінити поле поза своєю роллю, система має відхилити операцію. Перевіряйте сам результат відмови й запис про нього, а не лише відповідь асистента про те, що він пам’ятає обмеження.
Один лист проходить кілька передач
Уявімо, що постачальник просить змінити адресу доставки в поточному замовленні. У нашому сценарії агент допомагає знайти замовлення, зіставити повідомлення з наявними даними й підготувати заявку. Перевірка того, хто звернувся і чи має право просити таку зміну, залишається окремим правилом процесу; збіг назви компанії в тексті цього не доводить.
Корисно розділити маршрут на передачі роботи. Так працівник бачить, коли агент збирає інформацію, коли очікує рішення і коли система вже виконала дозволену операцію. Для ілюстративного пілота пропонуємо таку послідовність:
- Прийняти. Зберегти лист і визначити, до якого замовлення належить запит.
- Підготувати. Показати поточну адресу, запропоновану адресу та підставу зміни.
- Передати. Спрямувати заявку працівникові, уповноваженому розглянути її.
- Виконати. Застосувати погоджену зміну та зафіксувати результат операції.
Чернетка заявки тут є окремим робочим записом. Її створення не повинне непомітно змінювати адресу в замовленні. Якщо для рішення бракує додатка або підтвердження від контрагента, корисний результат агента — підготовлений запит на уточнення з позначенням прогалини.
Погоджують зміну, а не впевненість моделі
Microsoft Agent Framework описує механізм, у якому процес надсилає запит людині й очікує відповіді. Для інструмента з вимогою погодження його виклик може створити таку паузу. Її потрібно передбачити явно: сама наявність кількох агентів у маршруті не встановлює людського контролю.
У нашому сценарії екран погодження має відповідати на просте запитання: що зміниться після підтвердження? Радимо показати замовлення, старе й нове значення, підставу та перелік наступних дій. Надсилання повідомлення постачальнику теж варто позначити, якщо воно входить у погоджувану операцію.
- Чи погоджує працівник саме цю адресу для саме цього замовлення?
- Що станеться, якщо дані зміняться, поки заявка чекає на рішення?
Для другого випадку запропонуйте повторну перевірку перед виконанням. Якщо колега вже оновив замовлення, старе погодження не слід автоматично застосовувати до іншого стану даних. Поверніть людині актуальне порівняння. Так вона оцінює конкретну пропозицію, а не натискає абстрактну кнопку «довіряти AI».
Відновити роботу й не створити дубль
У документації Microsoft checkpoints зберігають стан процесу для подальшого відновлення, включно з повідомленнями й очікуваними запитами. Окремо описані різні сховища: стан лише в пам’яті процесу не переживає його перезапуск. Це механізм відновлення роботи; перевірку повторних зовнішніх операцій потрібно продумати додатково.
Попросіть команду випробувати цю ситуацію окремо: перервати відповідь після прийняття операції, відновити процес і перевірити кількість заявок. Позначка «продовжено» в інтерфейсі ще не показує, чи зберігся правильний результат у системі обліку.
Зупинка також має зрозумілий результат
Завдання «передано людині» корисне лише тоді, коли зрозуміло, хто його отримав і що потрібно зробити. Пропонуємо додавати до нього вихідний лист, виконані кроки, підтверджені зміни та причину зупинки. Якщо статус операції невідомий, позначайте це прямо. Працівник не повинен заново відтворювати всю історію.
Для журналу визначте, які події потрібні для розбору: хто запустив процес, який інструмент викликано, що повернула система і хто погодив зміну. Обсяг збережених документів та доступ до журналу налаштуйте окремо. Повний запис службових дій не вимагає безконтрольного копіювання в нього всього листування.
Призначте також власника цієї ролі: працівника, який переглядає винятки й вирішує, чи потрібно змінити правила. Після розширення доступу повторіть перевірки. Дозвіл на нову операцію має супроводжуватися зрозумілою причиною та способом оцінити її результат.
Перед пілотом також домовтеся про ліміт повторних спроб і спосіб зупинити нові дії. Випробуйте звичайний запит, відмову в погодженні, змінені дані та невизначений результат. До обговорення з IQusion підготуйте один маршрут із цими розгалуженнями й перелік дозволених операцій. Це дасть конкретне завдання для автоматизації та зрозумілі умови приймання роботи.
Поширені питання
Чи потрібен агент, якщо маршрут погодження вже описаний?
Спочатку визначте, яка частина роботи потребує вибору наступного кроку за змістом запиту. Для наперед визначеної послідовності може вистачити звичайного маршруту з окремою AI-функцією. Додавати агентську автономність до всього процесу не обов’язково.
Як реагувати на прохання в листі обійти погодження?
Для такого випадку слід зберегти встановлений маршрут і передати запит відповідальному працівникові. Текст зовнішнього листа не надає доступу до нових операцій. Обмеження мають діяти в системі інструментів, а їх дотримання потрібно перевірити в пілоті.
Що вважати успішним результатом, якщо агент зупинився?
Для винятку наперед визначте прийнятний результат: зрозуміла причина зупинки, відсутність подальших непогоджених дій, збережений стан і передане конкретній людині завдання. Швидкість завершення всього процесу варто оцінювати разом із часом такого розбору.
