ZEVRYNTA пояснює
Перш ніж дати ШІ-агенту доступ: п'ять запитань, на які не відповідає демо
Демонстрація Intel і SAP та анонс ідентифікації агентів IBM підводять до практичного питання: що агент може зробити, з чиїм дозволом і як його зупинити?
Успішна демонстрація показує, що завдання можна виконати в обраних для неї умовах. Сама собою вона не доводить, наскільки безпечно чи економічно та сама система працюватиме у вашому бізнесі. Ця різниця особливо важлива, коли програма переходить від пропозиції відповіді до виконання дії.
28 жовтня Intel описала перевірку концепції разом із SAP: SAP Extended Warehouse Management поєднали з периферійним ШІ та робототехнікою на технологіях Intel. За повідомленням Intel, складські запити перетворюються на завдання для роботів, а інформація про виконання повертається до бізнес-системи. Intel заявляє про операційні покращення; ZEVRYNTA незалежно їх не вимірювала.
Окремий анонс IBM від 27 жовтня описує виявлення та ідентифікацію агентів, контроль доступу й оцінювання, зокрема поширення засобів HashiCorp Vault на ШІ-агентів. Це заяви IBM про продукти, а не результати тесту ZEVRYNTA. Анонси стосуються різних систем, проте виявляють спільну проблему закупівлі: здатність агента виконати дію — лише частина того, що потрібно оцінити замовнику.
1. Визначте дію, а не лише амбіцію. Попросіть постачальника перелічити, які системи агент може читати, а які — змінювати. Підготувати замовлення і відправити його — різні дозволи. Корисний пілот одразу визначає дії, які потребують підтвердження людини, та дії, дозволені без нього.
2. З'ясуйте, хто може відкликати повноваження. Попросіть показати, що відбудеться після відкликання доступу, поки завдання ще очікує виконання. Важливо не те, чи обіцяє модель зупинитися, а те, чи відмовить підключений застосунок у виконанні дії. До надання виробничого доступу визначте відповідального оператора та порядок ескалації.
3. Перевірте непоказові збої. Недоступна база, повторний запит або запізніла відповідь можуть розповісти про інтеграцію більше, ніж відшліфоване демо. Запитайте, що станеться з частково виконаним завданням, чи буде повторна спроба та як запобігають дублюванню дій. Для фізичного обладнання окремі засоби безпеки потрібно оцінювати з кваліфікованими операторами; програмна демонстрація не є сертифікацією безпеки.
4. Рахуйте вартість прийнятного завершеного завдання. Порівнюйте повну вартість процесу, включно з виправленнями людиною, інтеграцією та обробкою винятків, а не лише ціну виклику моделі. До пілота погодьте невеликий репрезентативний набір завдань і критерій приймання. Опитування, прогноз або результат демонстрації постачальника не замінює розрахунку для вашого бізнесу.
5. Вимагайте можливості вийти. З'ясуйте, як експортувати історію завдань, знайти незавершену роботу та прибрати доступ після завершення пілота. Зворотний пілот дає змогу навчитися, не перетворюючи рекомендовану постачальником архітектуру на незворотне зобов'язання.
Практичний наступний крок — обмежений пілот із визначеними повноваженнями, сценаріями збоїв, критеріями приймання та процедурою зупинки. Це редакційний перелік запитань для оцінювання, а не рейтинг продуктів Intel, SAP чи IBM. Ми не тестували анонсовані можливості, не підтверджували окупність і не маємо підстав вважати фото з події доказом виробничої готовності.