Чому підприємницький AI ламається після розгортання – і що з цим робити

Попередження: Проблема не в моделі

У 2023 році місто Нью-Йорк запустило чат-бот MyCity, щоб допомогти підприємствам орієнтуватися в складних правилах. Ідея була простою: зробити юридичну інформацію легше доступною.

На практиці система давала відповіді, які були не тільки неправильними, але й юридично оманливими – від правил чаювання до дискримінації в житлі та правил оплати.

Пізніше аудит показав, що 71,4% відгуків користувачів були негативними. Замість того, щоб виправити основні проблеми, реакцією було додати застереження. Чат-бот навіть залишався у “бета-версії” понад два роки, перш ніж його вимкнули.

Недолік не був технічним. Система зламалася у виробництві, оскільки не було механізму, щоб забезпечити точність, не було ясної відповідальності та не було способу втрутитися, коли щось пішло не так.

Це той самий шаблон, який спостерігається у підприємницькому AI сьогодні: технологія працює, але організації не створені для надійного її використання, коли вона вже запущена.

Від пілотного проекту до виробництва: Де все розвалилося

Створення пілотного проекту досить просте – виберіть випадок використання, виберіть модель, підготуйте дані, знайдіть спонсора. Запуск системи у виробництві – це зовсім інша ліга.

Пропуск подібний до різниці між стрибком у басейн і стрибком з стратосфери, як це зробив Фелікс Баумгартнер у 2012 році. Та сама базова фізика, зовсім різні умови – і зовсім різні наслідки у разі невдачі.

У виробництві AI вступає у реальні потоки прийняття рішень, взаємодіє з клієнтами та створює юридичні та оперативні наслідки. Саме там починають з’являтися пробіли – не у моделі, а у тому, як вона керується.

Європа робить це видимим раніше, ніж більшість регіонів. Регуляції, такі як закон ЄС про AI, GDPR та NIS2, не сповільнюють впровадження – вони показують, чи можуть організації експлуатувати системи AI під реальними обмеженнями.

У 2025 році 55% великих підприємств ЄС вже використовували AI. Впровадження вже відбувається у великому масштабі. Проблема полягає в тому, що відбувається після розгортання.

На цьому етапі починають з’являтися базові оперативні питання. І часто ніхто не може відповісти на них: Хто відповідає за вивід AI та автономні рішення? Що відбувається, коли система поводиться несподіваним чином? І хто зупинить її, перш ніж шкода дійде до ЗМІ?

Відповідальність лежить на компанії, а не на технології. Чат-бот Air Canada дав клієнту неправильну інформацію про тарифи на жалобу. Клієнт довіряв йому і пізніше був відмовлений у поверненні коштів. Трибунал постановив, що авіакомпанія була відповідальною – чат-бот не був окремою сутністю.

Та сама проблема, інший кут: система McHire McDonald’s виявила конфіденційну інформацію майже 64 000 заяв. Причина не була складним нападом – адміністративний логін використовував “admin” і “123456”. Система виглядала сучасною. Недолік був елементарним.

Коли ви прикріплюєте керування до живої системи, це вже запізно. Розгортання системи – це технічне рішення. Надійне її використання – це організаційне рішення. І це та частина, яку більшість компаній недооцінюють.

Хто насправді володіє ризиком AI? Ні хто.

Це є ядро проблеми, і парадоксально, що це найменш обговорювана проблема. Відділ IT керує інфраструктурою. Юридичний відділ займається дотриманням законодавства. Бізнес-команди просувають випадки використання. Але ніхто не володіє ризиком AI з кінця в кінець.

Це створює дві негайні проблеми. Рішення про “пуск” сповільнюється – тому що ніхто не хоче взяти на себе відповідальність. І рішення про “зупинку” сповільнюється однаково – тому що ніхто не знає, хто може.

Дані показують це. Менше 10% випадків використання AI переходять від пілотного проекту до виробництва, і більшість організацій борються з генерацією вимірюваного бізнес-ефекту. Водночас багато вже розгортають AI – але згідно з звітом про зрілість керування, тільки 7% мали добре структуроване та послідовно застосовуване керування.

Чому це відбувається так послідовно? Тому що більшість рамок і корпоративних політик визначають, що повинно статися – не хто відповідає, коли це має значення. Коли система починає давати неправильні виводи о 24:00 у п’ятницю, питання не є теоретичним. Хто діє? І хто має повноваження вирішувати?

Це тільки погіршується з масштабом. Одну систему можна керувати неформально. Коли у вас їх тридцять, відповідальність фрагментується по командах, і ніхто не має повної картини.

Банк Commonwealth Bank of Australia дає чіткий приклад. Банк замінив 45 працівників служби клієнтів на AI-боти, сподіваючись, що попит зменшиться. Це не сталося. Об’єми дзвінків збільшувалися, менеджери втручаються для обробки переповнення, і банку довелося знову найняти всіх 45 працівників. Коли їх викликали до відповідальності, вони не змогли продемонструвати, що автоматизація зменшила навантаження.

Ніхто не перевіряв припущення до розгортання. Ніхто не володів результатом, коли ці припущення зазнали невдачі. Це той самий вакуум відповідальності, який спостерігається на практиці.

Мати правила недостатньо. Вам потрібен механізм

Більшість організацій не缺ують політики. Вони缺ують системи, які працюють, коли щось пішло не так.

Політика визначає, що повинно статися. Механізм визначає, що насправді відбувається – коли модель дає неправильні виводи, коли постачальник змінює щось на задньому плані або коли система починає поводитися несподіваним чином.

Ця різниця стає видимою у виробництві – коли рішення повинні прийматися під реальними умовами.

Ці невдачі слідують послідовній динаміці. У кожному випадку ті самі оперативні пробіли з’являються – тільки у різних формах.

Відповідальність перш за все

Кожна розгорнута система AI потребує явного власника – однієї особи, а не команди чи відділу, з повноваженням схвалити, призупинити та вимкнути її.

Без цього ні швидкого розгортання, ні безпечного втручання не можливі. Як видно з прикладу Commonwealth Bank, відсутність ясної відповідальності веде безпосередньо до оперативної невдачі.

Дані та юридична ясність часто відсутні

Багато систем запускаються без задокументованих потоків даних, перевіреного юридичного підстави або ясності щодо того, які зобов’язання застосовуються, коли система запущена у виробництві.

Дія італійського регулятора проти DeepSeek у 2025 році ілюструє це чітко. Проблема не полягала у якості моделі – а у відсутності пояснення, як обробляються особисті дані. Результатом стала раптова перерва у роботі служби для європейських користувачів.

Тестування рідко відображає реальне використання

Системи часто оцінюються за сценаріями, у яких вони працюють добре, але не за випадками, коли невдача матиме найбільше значення.

Чат-бот MyCity – це чіткий приклад. Базові краї випадків – навколо трудового законодавства, дискримінації в житлі чи правил оплати – не були виявлені до розгортання. Як тільки система була відкрита для реальних користувачів, ці невдачі стали публічними одразу.

Тестування не тільки про продуктивність – воно про виявлення, де система зазнає невдачі, перш ніж це зроблять користувачі, регулятори чи журналісти.

Втручання неясне або занадто повільне

ЕVEN коли проблеми видно, часто немає ясного триггера чи повноважень для призупинення чи вимкнення системи.

Zillow Offers демонструє це у великому масштабі. Система використовувала алгоритм для визначення ціни та покупки будинків. Коли ринок охолов у 2021 році, система продовжувала купувати за завищеними цінами. Не було механізму для виявлення зсуву вчасно, і не було ясного рішення про зупинку. Результатом стали збитки понад 880 мільйонів доларів і закриття всього підрозділу.

Моніторинг не є відповідальністю

Моніторинг часто зводиться до панелей, але це не те, що запобігає невдачам.

Що має значення, це визначена відповідальність: хто відстежує сигнали, що викликає ескалацію, і хто очікується діяти.

Деліотт Австралія показує, що відбувається, коли цього немає. Урядовий звіт включав вигадані цитати та неправильні юридичні посилання, оскільки ніхто явно не був відповідальним за перевірку виводів до доставки. Результатом стала часткова повернення коштів та репутаційна шкода.

Agentic AI: Що прийде, буде ще складніше

Генеративний AI виробляє виводи. Agentic AI приймає дії. Це змінює ризик повністю.

Замість однієї відповіді для оцінки, одна інструкція може викликати ланцюжок рішень по системах – виклики API, доступ до даних, транзакції, оновлення – часто без втручання людини на кожному етапі.

Коли щось пішло не так, проблема вже не полягає у точності. Це слідування. Який крок викликав проблему? Які дані були використані? Хто авторизував дію? У багатьох випадках ці питання важко відповісти після факту.

Там існуючі пробіли стають критичними. Неясна відповідальність, слабкий моніторинг та відсутність втручання не тільки зберігаються – вони посилюються. Неправильна відповідь можна виправити. Неправильна дія може створити наслідки, перш ніж хто-небудь помітить.

Ранній сигнал вже вказує у цьому напрямку. Gartner передбачає, що понад 40% проектів agentic AI будуть скасовані до 2027 року – не через обмеження моделі, а тому що організації борються з контролем витрат, ризиків та результатів. Це той самий шаблон, який ми бачимо з генеративним AI після розгортання. Только з більш високими ставками.

Регулятори вже реагують простим принципом: автоматизація не усуває відповідальність. Для організацій це створює ясний наслідок: якщо відповідальність та контроль неясні сьогодні, масштабування в агентичні системи не розв’яже проблему. Це посилить її.

Керуйте нею – або втрачайте

AI вже не є обмеженням. Моделі широко доступні, здатні та дедалі більше комодифікуються. Реальна різниця не полягає у тому, чи може організація побудувати AI – а у тому, чи вона може керувати ним надійно, коли він уже запущений.

Саме там відбуваються більшість невдач – у тому, як системи керуються, а не у тому, як вони будуються. Організації, які успішно керуватимуть, не будуть тими, у яких є найрозвітліші моделі. Це будуть організації, у яких є найясніші оперативні структури навколо них.

Це можна перевірити безпосередньо. Візьміть свою найважливішу систему AI та відповісті на три питання:

• Хто може її вимкнути?
• Як ви знаєте, коли вона зазнає невдачі?
• Що відбувається, коли вона зазнає невдачі?

Якщо ці відповіді неясні, система не готова до виробництва.

Модель може бути. Організація – ні.