Лідери думок

Ближчий погляд на етапи впровадження ШІ, що стоять за успіхом корпоративного ШІ

mm
Додайте Unite.AI до бажаних джерел у Google

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

Що розрізняє одну компанію від іншої, так це, наскільки далеко вона просунулася по цьому шляху, і розрив на ринку великий. Глобальне опитування McKinsey 2025 року виявило, що 88 % організацій вже використовують ШІ хоча б у одній бізнес‑функції, близько третини почали масштабувати його, а 7 % стверджують, що ШІ повністю масштабовано. Це означає, що майже кожна компанія розпочала впровадження ШІ, проте дуже небагато з них досягли успіху.

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

П’ять етапів впровадження ШІ та рішення, які просувають компанію вперед

У компаніях, із якими ми працюємо, ці п’ять етапів майже завжди йдуть в однаковому порядку. Зазвичай усе починається з кількох людей, які самостійно користуються інструментами ШІ, а керівництво дізнається про це значно пізніше. Деякі компанії так і не йдуть далі. Ті, що продовжують, зрештою будують сам бізнес навколо можливостей технології. Важливо, що кожен етап вимагає від організації чогось іншого. Рішення, яке допомогло пройти пілотну фазу, часто через рік стримує компанію. Саме тут чимало програм ШІ тихо розпадаються.

1. Розкидане використання без власника

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

Помилка керівників тут — надто рання формалізація, що перетворює справжні експерименти на вправу з управління задовго до розуміння того, що взагалі слід регулювати.

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

2. Фінансовані пілоти зі слабкими критеріями успіху

Пілотний проєкт отримує бюджет, визначеного відповідального й демонстрацію для ради директорів, після чого робота тихо закінчується. Дослідження ініціативи NANDA при MIT виявило, що переважна більшість корпоративних пілотів генеративного ШІ не має вимірюваного впливу на фінансовий результат.

Майже все пояснюють три причини. По-перше, критерії успіху будують навколо точності моделі, а не показника, важливого для бізнесу. По-друге, під демонстрацією немає справжнього конвеєра даних. По-третє, після запуску ніхто не залишається відповідальним за результат. Зсередини цей етап важко помітити, бо він схожий на прогрес: демонстрації поліпшуються, постачальники змагаються за наступну фазу, комітети засідають, але нічого не перетворюється на результат, який фінансовий відділ може порахувати.

Рішення тут: не схвалюйте пілот без бізнес-показника й відповідального, який звітуватиме за нього і через рік. Закривайте ті пілоти, де ніхто не може назвати ні того, ні іншого. Чотири пілоти з такою дисципліною дадуть більше, ніж дванадцять, якими всі захоплюються.

3. Інтеграція у виробництво

Серед усіх етапів запровадження ШІ саме цей завершує найбільше програм. Працівники й клієнти тепер щодня залежать від системи. З’являються вимоги, яких не було на пілоті: моніторинг, передавання випадків людині, керування версіями промптів і моделей, реагування на інциденти й простежуваність даних, що витримає аудит. Документ NIST AI Risk Management Framework докладно описує ці засоби контролю; його варто прочитати до визначення дати запуску.

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

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

4. Спільна спроможність і повторне використання

На цьому етапі ШІ стає інфраструктурою для кількох бізнес-підрозділів. Платформна команда підтримує компоненти багаторазового використання, спільний метод оцінювання та шлях розгортання. Вартість кожного нового сценарію знижується, бо ніхто щоразу не перебудовує основу з нуля.

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

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

5. ШІ всередині операційної моделі

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

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

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

Що трапляється, коли компанія пропускає етап: реальний приклад

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

Що пішло не так

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

Скільки це їх коштувало

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

Чого варто навчитися

Моніторинг і відповідальність здаються накладними витратами, доки не лишишся без них. Їхнє вилучення робить запуск на вигляд дешевшим, ніж він є. Вартість не зникає, а повертається згодом як втрачена довіра замість рядка в бюджеті.

Як визначити поточний етап впровадження ШІ у вашій компанії

  • Чи можете ви назвати бізнес‑метрику, яку змінює кожна впроваджена модель?
  •  Хто отримує сповіщення, коли одна з них деградує?
  • Скільки часу займає новий випадок використання від запиту до виробництва?
  •  Яка частка вашої роботи з ШІ повторно використовує вже створене?

Чіткі відповіді підтверджують досягнутий етап. Непевні прямо вказують, який рівень варто фінансувати наступним, тому вони не менш корисні.

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

Кожна організація вже належить до одного з цих етапів, незалежно від того, чи хтось його назвав. Перевагу мають керівні команди, які знають свій етап і свідомо фінансують наступний крок.

Чандреш Пател є генеральним директором і засновником Bacancy Technology, компанії з розробки корпоративного ШІ. Він заснував її у 2011 році і зараз обслуговує клієнтів у Північній Америці та Європі. Маючи понад 14 років досвіду у впровадженні корпоративного програмного забезпечення, хмарній інженерії та прикладному ШІ, він керував масштабними програмами модернізації технологій у сфері охорони здоров’я, фінансових послуг та страхування.

Його поточний фокус зосереджений на впровадженні корпоративного ШІ, зокрема на переході від окремих пілотних проєктів до систем промислової експлуатації з належним управлінням. Чандреш безпосередньо співпрацює з керівними командами щодо стратегії ШІ, моделей реалізації та організаційних змін, які визначають, чи буде програму ШІ введено в промислову експлуатацію.