Як автоматизувати рутинну роботу з ШІ і не створити хаос

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

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

Запишіть процес так, як він працює сьогодні

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

Для кожного кроку позначте:

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

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

Розділіть правила, модель і людину

Стабільні умови краще виконувати кодом: обов’язкове поле, сума понад ліміт, відсутній договір, збіг ідентифікатора. Модель корисна для неструктурованого тексту: визначити тему листа, запропонувати коротке резюме, знайти згадані обмеження. Людина має залишатися там, де наслідок значний або критерій неоднозначний.

Наприклад, для вхідних звернень:

1. Система перевіряє адресу, згоду й обов’язкові поля.
2. Модель пропонує категорію та витягує номер замовлення.
3. Правило перевіряє номер у CRM.
4. Модель готує чернетку лише з дозволеної бази знань.
5. Працівник погоджує відповідь у складних випадках.
6. Система надсилає лист і записує результат.

AI тут не «керує бізнесом». Він обробляє вузькі невизначені фрагменти всередині контрольованого маршруту.

Створіть еталонний набір до налаштування промпта

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

Оцінюйте окремо точність полів, категорії, небезпечні помилки й частку передачі людині. «Текст звучить добре» — слабкий критерій. У фінансовому процесі неправильна сума має іншу вагу, ніж невдала кома.

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

Запускайте спочатку без права діяти

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

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

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

Захистіть систему від зовнішніх інструкцій

Лист, PDF або вебсторінка можуть містити фразу, яка просить модель ігнорувати правила й передати дані. Це prompt injection. Зовнішній контент треба вважати даними, а не надійною інструкцією. Не дозволяйте йому розширювати права інструментів.

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

Вимірюйте результат після запуску

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

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

Перший проєкт має бути маленьким і трохи нудним. Якщо він стабільно економить час і помилки видно до того, як вони завдадуть шкоди, ви отримали основу для наступного. Якщо ні — поверніться до карти процесу. Можливо, проблема була не в нестачі ШІ, а у відсутності зрозумілого правила.