Автоматизація з агентами AI рідко полягає в тому, що модель чогось не вміє. Вона полягає в тому, що зробила щось, чого ніхто їй прямо не заборонив, а ніхто не встиг перевірити перед наслідком. Відправила повідомлення клієнту. Закрила заявку. Перезаписала поле в системі ERP. Кожна з цих речей окремо є незначною. Престає бути, коли стосується трьохсот записів одночасно.
Питання «чи людина мусить це затвердити» є питанням проєктним, а не філософським. І має погану відповідь, яка звучить розсудливо: «завжди». Якщо оператор клікає «акцептовати» сорок разів на день, то через тиждень клікає без читання. Автоматизація нічого не прискорила, а контроль є позорним, бо в журналі з'являється «затверджено», хоча ніхто цього не прочитав.
Три питання, які вирішують, де поставити брамку
Перше: чи наслідок можна скасувати. Запис до тестової бази скасується одним командом, переказ і повідомлення, відправлене клієнту, не скасується взагалі. Друге: чи наслідок виходить за межі фірми. Внутрішня проблема виправляється тихо, зовні виправляється вибаченнями. Третє: скільки коштує помилка у порівнянні з вартістю очікування. Якщо помилка коштує годину праці, а очікування на акцептацію добу, брамка дорожча, ніж те, від чого вона захищає.
Ці три питання зазвичай дають дивно мало місць, в яких людина дійсно потрібна. У процесі, що нараховує сорок кроків, буває їх кілька.
Як ми розділили це у себе
Кордон проходить у нас по зовнішньому ефекту. Внутрішня робота, тобто аналіз коду, підготовка змін, запуск тестів, створення тестового середовища, відбувається автоматично і ніхто її по дорозі не кликає. Все, що виходить назовні, тобто повідомлення клієнту, публікація, передача даних зовнішній службі, вимагає явної згоди людини. Без винятку "дрібна справа".
Впровадження у виробництво має окрему брамку, бо ефект бачать одразу всі користувачі. Перед нею: копія даних і позначка версії, повний комплект автоматичних тестів, план відміни, підготовлений заздалегідь, не написаний у паніці. Тільки потім приймається рішення про перемикання потоку. Приймає його людина, дивлячись на результати тестів, а не на запевнення агента, що все пройшло добре.
Добра брамка показує ефект, не намір
Повідомлення "агент хоче відправити повідомлення контрагентам, затвердити?" є безкорисним, бо затвердник не знає, що підписує. Брамка стає корисною, коли показує: скільки записів охопить операція, три прикладові результати у остаточній формі, перелік різниць у порівнянні з поточним станом та те, чого операція не торкнеться.
До цього три речі, які легко пропустити при першому впровадженні:
- за замовчуванням відповідь повинна бути безпечною: відсутність реакції означає "не роби", ніколи "роби",
- одна брамка на операцію, не п'ять поспіль, бо п'ять вчить клікувати наосліп,
- запис хто, коли та що затвердив, зберігався окремо від самого процесу; при спорі або контролі це єдиний доказ того, що рішення прийняв людина.
Антивзори, які найчастіше трапляються
Бланкетна згода на весь робочий день агента. Підтвердження після факту, тобто повідомлення «відправлено, підтвердіть», яке не є контролем, а лише архівом. І найпохитріше: сповіщення у каналі, яке всі вимкнули.
Останнє коштувало нам тридцять один день затримки у публікації. Повідомлення повторювало ту саму інформацію протягом багатьох днів, тому було вимкнено як шум. Річ у тім, що в певний момент інформація припинила бути правдивою: перешкода відступила, а повідомлення виглядало ідентично, як і раніше. Принцип, який ми з цього зробили: вимикати можна стан, з яким і так нічого не зробиш, ніколи стан, який щойно став здійсненним.
Коли нагляд людини перестає бути вибором
При системах високого ризику у розумінні EU AI Act нагляд людини є обов'язком з статті 14: особа, яка здійснює нагляд, повинна розуміти результат системи, мати можливість його проігнорувати і мати можливість зупинити систему. Це вимагає інтерфейсу, який на це дозволяє, не абзацу в процедурі.
Друге правило, про яке компанії пам'ятають рідше, це стаття 22 GDPR. Якщо рішення ґрунтується виключно на автоматизованому обробленні та викликає щодо особи юридичні наслідки або подібні, цій особі належить право на втручання людини. Набір працівників, оцінка кредитоспроможності, відмова у задоволенні рекламації. Брамка підтвердження тоді є не такою доброю практикою, як елементом відповідності. Про самі обов'язки прозорості ми писали ширше у переліку вимог відповідності AI для МСП.
Одна зауваження
Проєктування брамок подовжує впровадження. Звичайно, на кілька днів аналізу, бо потрібно пройти процес крок за кроком і для кожного кроку відповісти на три питання з початку тексту. Компанії, які цей етап опускають, впроваджують швидше і зазвичай повертаються до нього після першої інциденту, тільки тоді під тиском і з гіршим результатом.
FAQ
Які брамки є занадто великими?
Практичний тест: якщо особа, яка затверджує, не може з пам'яті сказати, що останнє вона затвердила і чому, брамок є занадто багато або вони показують занадто мало змісту. Краще мати три, які хтось читає, ніж двадцять, які натискуються автоматично.
Чи можна це додати до автоматизації, яка вже працює?
Так, і зазвичай саме так це виглядає, бо потреба в брамці виявляється лише на реальних даних. Умова одна: процес повинен мати чітко відокремлений момент "підготовлено" від "виконано". Якщо агент рахує і посилає в одному kroku, цей крок потрібно спочатку розділити.
Хто повинен затверджувати, технічна особа чи власник процесу?
Власник процесу, коли рішення стосується змісту: чи ця повідомлення має піти до клієнта. Технічна особа, коли стосується способу виконання: чи ця зміна може піти на виробництво. Змішування цих ролей закінчується тим, що технічний затверджує зміст, на якому він не знається, тому затверджує все.
Перейдіть через Ваш процес
Якщо у Вас є автоматизація, при якій не відомо, де поставити межу затверджування, найпростіше перейти цей процес разом, крок за кроком, і вказати ці кілька місць, які фактично потребують людини. Замовте безплатну консультацію через контактну форму.