Як спроєктувати схвалення дій ШІ людиною
Резюме рішення: Пов’яжіть схвалення ШІ з конкретним результатом: картка рішення, версії, невідоме надсилання, пілотні тести й передавання відповідальності.
Визначте дію, що потребує схвалення
Асистент пропозицій може класифікувати запит, написати чернетку й показати відповідальній особі. Підготовка та надсилання клієнту — окремі дії. У цьому прикладі надсилання потребує схвалення конкретної пропозиції. Якісний текст не надає повноважень погоджувати комерційні умови.
Для кожної дії визначте власника, наслідок і шлях відновлення. Не об’єднуйте надсилання, видалення й оплату під нечітким «продовжити». Це приклад проєктування, а не виміряний результат клієнта.
Підготуйте картку для рішення
Покажіть одержувача, повний текст, назви й версії вкладень, важливі ціни або дати та наслідок дії. Передбачте схвалення, відмову й запит виправлень. Спершу заповніть відсутні дані.
Згода стосується показаної версії. Зміна одержувача, тексту чи вкладення потребує нового рішення. Фраза «я директор» у листі не підтверджує особу: повноваження визначають перевірений користувач і права застосунку.
Не надсилайте повторно наосліп після тайм-ауту
Надайте кожному наміру надсилання один ідентифікатор. Розрізняйте підготовлено, схвалено, надіслано й результат невідомий. Якщо зв’язок перервався до відповіді провайдера, спершу перевірте його запис або підтвердження. Не ставте невідомий результат автоматично на повторне надсилання.
Якщо підтримуються, використовуйте ті самі ключі ідемпотентності для тієї ж операції та перевіряйте строки їх зберігання. Власний журнал не доводить одноразової обробки в одержувача. Надіслано, доставлено й прочитано — різні докази.
Перевірте нестандартні сценарії
Підготуйте чинну згоду, відмову, зміну одержувача після згоди, прострочену згоду й втрату зв’язку під час надсилання. Запишіть очікувану дію та перевіряльника. П’ять успішних випадків — початок, не доказ безпеки за всіх умов.
Порівнюйте з ручним процесом правильно завершені завдання, виправлення, дублікати й очікування людини. Врахуйте перевірку та відновлення після помилок. Швидша чернетка сама не доводить зростання продуктивності.
Зробіть передавання й зупинку видимими
Кожна черга потребує відповідального та доступного заступника. Строк згоди визначайте за ризиком. Під час передавання показуйте стан, схвалену версію та залишкову невизначеність. Пауза має зупиняти нові зовнішні дії.
OWASP розглядає надмірні повноваження. NIST AI RMF охоплює ролі людського нагляду. Вище наведено нашу пропозицію впровадження. Почніть із реального процесу, його картки та процедури збою.
Методологія
Твердження оцінюються за здійсненністю, вартістю, ризиком і вимірюваністю. Приклади розрахунків є припущеннями; юридичні та безпекові рішення потребують первинних джерел.
Примітка про джерела
Посилання й названі документи — початкові точки. Неперевірені результати клієнтів не публікуються.
Журнал змін
— Нативна редакторська перевірка очікує на шлюзі публікації v3.0.
Поширені запитання
Кожен результат ШІ потребує схвалення?
Вирішуйте за наслідками. Відокремлюйте внутрішні чернетки від зовнішнього надсилання та явно обмежуйте автоматичні дії.
Що робити зі зміною схваленого тексту?
Стара згода не поширюється на новий текст. Покажіть змінену версію уповноваженій людині для нового рішення.
Повторювати надсилання з невідомим результатом?
Спершу перевірте запис провайдера. Автоматична спроба може виконати дію двічі.