В інтерв’ю McKinsey Тіффані Сін’юй Ван пропонує перевіряти постачальників AI через конкретні збої: як їх стримують і як повідомляють клієнта.
Ключові інсайти
Практичне застосування: перевірка збою до підписання договору
Редакційний розбір Inside the CEO: цей підхід можна перетворити на окреме приймальне випробування, а не залишати запитанням наприкінці демонстрації. Команда обирає робочий сценарій, який хоче передати системі, та описує небажаний результат. Далі просить показати весь ланцюг: як помилку помітили, хто отримав сигнал, які наступні дії були заблоковані та як відновили правильний стан процесу. Пояснення варто прив’язати до конкретної функції сервісу й відповідального, а не до загальної презентації про безпеку.
Окремо слід розрізняти історію вже розібраного інциденту та демонстраційний тест. Для першого потрібні обставини й висновки без розкриття чужих даних; для другого — погоджені умови та запис результату. Якщо постачальник не може показати реальний випадок, це не привід вигадувати його: можна перевірити узгоджений сценарій помилки в тестовому середовищі. Так покупець отримує перевірюваний матеріал для рішення, а не лише обіцянку, що проблем не буде.
Чернетка й дія потребують різних прав доступу
Порівняймо дві можливі задачі: підготувати чернетку відповіді клієнту та самостійно надіслати її з комерційною пропозицією. Це редакційний приклад, не кейс з інтерв’ю. У першій задачі людина може перевірити текст до відправлення. У другій помилка вже виходить за межі внутрішньої роботи й потребує іншого порядку погодження. Тому рішення про закупівлю корисно розкласти на конкретні дозволи: читати інформацію, формувати рекомендацію, змінювати запис у системі чи виконувати зовнішню дію.
Для кожного дозволу можна записати умову його надання та спосіб відкликання. Наприклад, доступ до створення чернетки не повинен непомітно перетворюватися на право відправляти повідомлення. Окреме рішення потрібне й тоді, коли до вже випробуваного сценарію додають іншу базу даних або новий канал взаємодії. Така карта дозволів допомагає обговорювати предмет закупівлі з операційною командою: не абстрактного помічника для всіх, а визначену дію в зрозумілих межах.
Закріпити приймання сервісу за власником процесу
У запропонованій нами перевірці технічна команда відповідає за підключення й обмеження доступу, а керівник процесу — за те, чи придатний результат до використання. До запуску вони разом погоджують, яку помилку можна виправити всередині процесу, а яка потребує його призупинення. Також визначають, хто має право повернути роботу людям і хто повідомляє тих, кого вже зачепив неправильний результат. Без розподілу цих ролей навіть помічений збій може залишитися між двома службами підтримки.
Корисним результатом приймання буде короткий документ із завданням, дозволеними діями, перевіреним сценарієм помилки, контактами відповідальних і порядком відновлення. Його потрібно звірити з тим, що компанія фактично купує: які функції доступні в обраному пакеті, яка підтримка передбачена та що відбувається після зміни версії. Це дає керівнику основу для вибору між запуском, обмеженим випробуванням і відкладенням закупівлі через конкретну прогалину, яку постачальник ще має закрити.
Головні тези
- Компетентність моделі й доречність її використання в конкретній ситуації — різні критерії перевірки.
- Покупцеві потрібен приклад невдачі, спосіб її локалізації та зрозумілий порядок реагування.
- Підприємство саме визначає, які дані й робочі системи стають доступними для AI.
Що це означає для CEO
До запуску погодьте приймальний тест і назвіть того, хто може зупинити процес та повернути його до роботи після помилки.