BCG дослідила, як компанії поєднують AI-інновації з відповідальністю. Один із виявлених розривів — рішення ухвалюють, але не перетворюють на правила для наступних випадків.
Ключові інсайти
Редакційний розбір: знайти повтор у черзі погоджень
Для першої перевірки керівникові не обов’язково перебудовувати всю систему. Візьміть останні звернення щодо використання AI та розділіть їх за тим, яке питання насправді потребувало відповіді. Два запити з різних підрозділів можуть стосуватися однакової роботи з відкритими даними; два зовні схожі запити — мати різний ризик через доступ до клієнтської інформації.
Це редакційний спосіб застосування, а не додатковий результат опитування. Мета розбору — побачити, де компанія повторно оплачує час тих самих фахівців і де новий контекст справді змінює рішення. Самої назви інструмента для цього недостатньо: важливі дані, дія, отримувач результату й наслідок можливої помилки.
Скласти картку дозволеного застосування
Умовна робоча картка може містити завдання, допустимий тип даних, версію або клас інструмента, спосіб перевірки результату та відповідального за процес. Окремо зазначте, що залишається за межами дозволу. Наприклад, підготовка чернетки внутрішнього повідомлення не означає права самостійно надіслати його клієнтові чи завантажити конфіденційний договір.
Для працівника правило має відповідати на просте робоче питання: чи можу я виконати саме цю дію в цих умовах? Якщо відповідь потребує нового листування з кількома функціями, картка поки не зняла невизначеність. У ній варто залишити зрозумілий шлях звернення щодо винятку, а не стимулювати приховане використання поза системою.
Відділити новий контекст від повторного запиту
Потреба нового розгляду виникає не лише тоді, коли змінюється назва моделі. Підставою може бути нове джерело даних, зовнішня аудиторія, доступ до іншої системи або можливість самостійного виконання дії. Команда має знати, які саме зміни припиняють дію попереднього погодження.
Для умовного аналітичного помічника це дозволяє відокремити підготовку матеріалу для людини від автоматичного оновлення виробничого запису. Рівень контролю пов’язують із наслідками, а не з бажанням перевірити абсолютно кожен текст. Водночас повторне використання правила не має скасовувати обов’язкових вимог безпеки, захисту даних чи погоджень, установлених для відповідної бізнес-дії.
Призначити власника самого правила
Після запуску бібліотеки рішень потрібна людина, яка підтримуватиме її придатність до роботи. Визначте, хто отримує повідомлення про помилку, зміну інструмента або непередбачену дію, хто переглядає межі дозволу та як оновлення доходить до користувачів. Без цього документи швидко розходяться з практикою, і працівники повертаються до особистих погоджень.
Для оцінки процесу можна порівнювати час розгляду типового запиту, частку звернень із неповними даними й кількість повторних питань, для яких уже існує відповідь. Ці показники мають допомагати виправляти правило, а не винагороджувати формальне зменшення кількості звернень. Швидкість тут з’являється тоді, коли учасники розуміють межі власного рішення.
Головні тези
- В опитуванні 142 керівників великих компаній лише 26% повідомили, що відповідь на нове AI-питання системно включають у постійні настанови.
- Автори пропонують розділяти сценарії за рівнем ризику, щоб типові завдання не проходили той самий шлях, що й нові критичні рішення.
- Для кожного рішення потрібен визначений відповідальний і задокументовані умови, за яких його можна застосувати повторно.
Що це означає для CEO
Після погодження AI-сценарію запишіть не лише дозвіл, а й межі його повторного застосування та умови нового розгляду.