Від AI-пілота до проду: чек-ліст з 12 пунктів, який зазвичай пропускають

Head of Ops у SMB на 220 людей одного разу сказала, що її AI-пілот виглядав ідеально шість тижнів — а потім пішов у прод і тихо зламався за два тижні. Не тому, що модель стала гірша. Тому що нічого довкола неї не було production-ready. Модель — найлегша частина.

Чому AI-пілоти провалюються на гейті проду?

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

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

Визначення: Production gate — конкретна, названа точка перевірки між успіхом пілота і запуском у прод. У кожного гейта — бінарне pass/fail, власник і артефакт (доку, дашборд, runbook).

12-гейтова рамка виглядає як overhead під час пілота. І як найдешевша страховка з тих, що ви купували, — на першому інциденті у проді.

12 гейтів — що покриває кожен?

Шість тем, по два гейти.

Дані

1. Джерело даних задокументоване. Звідки приходить вхід моделі у проді, і чи це те саме джерело, що було у пілоті? Інше джерело = інша поведінка.
2. Якість даних моніториться. Входи у проді дрейфують. Щотижнева перевірка null-rate, schema, розподілу ловить дрейф до того, як виходи стануть дивними.

Безпека

3. Обробка PII / конфіденційних даних. Що бачить модель у проді, і яка контрактна позиція з вендором про training? «Не тренують на ваших даних» — у письмі, не за умовчанням.
4. Access controls + audit log. Хто кличе модель, бачить виходи, змінює промпт? Кожна зміна продового промпту логиться з автором і часом.

Моніторинг

5. Cost-per-task щотижня. Токени по workflow, не за місячним інвойсом. Сплеск cost-per-task — часто перший сигнал prompt drift.
6. Cadence семплінгу якості. Людина ревʼює вибірку з N продових виходів на тиждень, з письмовою рубрикою. Без цього регресія невидима до скарги клієнта.

Fallback

7. Визначений failure mode. Коли модель повертає нонсенс або таймаутить — що відбувається? «Користувач бачить дружню помилку» — ок; «бачить raw exception» — ні.
8. Доступний людський override. Чи можна скасувати, відредагувати, ескалювати будь-яку AI-дію? Для high-stakes дій (відмова, charge, комунікація) — кожне «ні» з людським кліком.

Навчання

9. End-user навчання надано. Люди, що працюють з AI у проді, навчені патернів промптингу, failure modes, ескалації. Не слайдами — через лінзу Augment-don't-replace на реальній практиці.
10. Manager навчання надано. Менеджери, що ревʼюють виходи, знають як побачити AI-assisted роботу і чи це міняє планку ревʼю.

Власник

11. Названий власник. Одна названа людина володіє продом щодня. Не комітет. Не «AI-команда». Конкретне імʼя плюс backup.
12. Decommission criteria. Коли б ви це вимкнули? Якщо не можете відповісти — побудували не систему, а залежність.

Визначення: Decommission criteria — конкретні, письмові умови, за яких AI-систему ставлять на паузу або забирають з проду. Приклади: регресія якості понад X%, cost-per-task понад Y, зміна контракту вендора, регуляторні зрушення.

Якщо хоч один гейт — «розберемось після запуску», цей гейт ви не пройшли. Ви його відклали. Відкладати ок — але запуск їде з ним.

Як виглядає гейт-ревʼю на практиці?

Реальне ревʼю — 60-хвилинна зустріч. Пілотний лід презентує кожен з 12 гейтів з артефактом. Власник (зазвичай COO або Head of Ops) ставить кожному green/yellow/red. Yellow ок для low-stakes гейтів; red на будь-якому — затримка запуску.

Yellow → письмовий план ремедіації з датою. Red → виправляється за тиждень або запуск їде. Дисципліна не каральна — AI-системи у проді мультиплікують помилки, і red на день 1 стає інцидентом до дня 30.

Визначення: Gate review — структурована зустріч, де презентується кожен артефакт гейта, ставиться оцінка, підписується. Output — одна сторінка: 12 рядків, 3 колонки (status, owner, next action).

Шаблон гейт-ревʼю (copy/paste)

Для пілотного ліда і executive sponsor:

AI ПІЛОТ → ПРОД: ГЕЙТ-РЕВ'Ю
Система: ___________________________________
Пілотний лід: ______________________________
Дата: ______________________________________

По кожному гейту: status (green/yellow/red), owner, next action.

ДАНІ
 1. Джерело даних задокументоване:  ____ / Owner: ___ / Next: _____
 2. Якість даних моніториться:       ____ / Owner: ___ / Next: _____

БЕЗПЕКА
 3. Обробка PII / конф. даних:        ____ / Owner: ___ / Next: _____
 4. Access controls + audit log:      ____ / Owner: ___ / Next: _____

МОНІТОРИНГ
 5. Cost-per-task щотижня:            ____ / Owner: ___ / Next: _____
 6. Cadence семплінгу якості:         ____ / Owner: ___ / Next: _____

FALLBACK
 7. Failure mode визначений:          ____ / Owner: ___ / Next: _____
 8. Людський override доступний:      ____ / Owner: ___ / Next: _____

НАВЧАННЯ
 9. End-user навчання:                ____ / Owner: ___ / Next: _____
10. Manager навчання:                 ____ / Owner: ___ / Next: _____

ВЛАСНИК
11. Названий власник:                 ____ / Owner: ___ / Next: _____
12. Decommission criteria:            ____ / Owner: ___ / Next: _____

РІШЕННЯ:
[ ] Все green — запуск цього тижня
[ ] Green або yellow — запуск з планом ремедіації
[ ] Будь-який red — запуск відкладено; re-gate ___________ (дата)

Цей аркуш — deliverable. Прикріпіть поруч з runbook. Переробляйте місячно перший квартал у проді.

Tool tip (Course for Business): Навчальні гейти — #9 (end-user) і #10 (manager) — ті, що пілоти тихо провалюють найчастіше. Рамка Augment-don't-replace тут критична: end-users, що відчувають AI як проти них, не використовуватимуть правильно, а менеджери, що не вміють відрізнити AI-assisted, або недо- або переревʼюють. 6-week program будує training gates як артефакти паралельно з технічним пілотом — щоб на 6-му тижні training не був afterthought. AI Champions (1:15-20) — співвідношення, що робить manager training масштабованим: кожен чемпіон підтримує manager-гейт у своїй команді. Подивіться, як training-сторона гейтів запускається: https://course.aiadvisoryboard.me/business.

Team scan (what AI champions report after week 1)

Крос-пілотні патерни тижня 1 у SMB-роллаутах:

• ~70% пілотів мають гейт #1 (джерело даних) red — більшість не записала, звідки приходить вхід
• Гейт #5 (cost-per-task щотижня) — yellow майже у кожному пілоті — місячний інвойс є, тижневого трекінгу нема
• Гейт #11 (названий власник) — найвищий leverage серед пропущених: пілоти без власника валяться на тижні 4-6 щоразу
• Перший сюрприз проду: prompt drift через сплеск cost-per-task до того, як регресія якості видима
• Перше тертя: гейт #3 (PII) yellow, бо opt-out у контракті вендора не задокументований — фікс листом
• Перша перемога: ревʼю виявляє відсутній failure mode (#7), уникнено інциденту на тижні запуску
• Use case #1 за оцінкою ops-лідів: сама зустріч гейт-ревʼю як артефакт, що виправдовує запуск CFO
• Сталий сигнал: пілоти, що пройшли всі 12 гейтів, мають ~3× нижчий incident rate у першому кварталі
• Мораль чемпіонів: найвища, коли ревʼю виносить проблеми, які чемпіон підозрював, але не міг сформулювати

Micro-case (що змінюється за 7-14 днів)

SMB на 90 людей зробила пілот customer-support AI-помічника. Пілот гарний 5 тижнів. Head of Ops наполягла на 12-гейтовому ревʼю до проду — три гейти red: нема названого власника, нема cost-per-task, нема decommission criteria. Команда виправила за 8 днів: support-лід — власник, тижневий дашборд по LLM-провайдеру, три decommission-умови привʼязані до регресії deflection-rate. Через 2 тижні після запуску upstream-зміна політики призвела до ~8% мис-роутингу тікетів. Сплеск cost-per-task видимий на дашборді за 48 годин, власник зловив, команда патчнула промпт, decommission criteria green. Без ревʼю проблема випливла б через скарги клієнтів за 2-3 тижні.

Note on this case: This example is illustrative — based on typical patterns we observe with companies of 30-500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

Tool tip (Course for Business): Production-grade AI-роллаут — це не 12 технічних чекбоксів, а 12 організаційних зобовʼязань. 6-week program будує гейт-артефакти паралельно: технічні пілоти у тижнях 1-4, training у тижнях 2-5, гейт-ревʼю у тижні 6, запуск у тижні 7 якщо все green. Shoulder-to-Shoulder hot seat — там пілотні ліди стрес-тестують кожен гейт проти cohort до формального ревʼю; більшість провалів ловиться тут, не на executive-зустрічі. Augment-don't-replace лишається рамкою для кожного гейта з end-users. Книжте 30-хвилинний мепінг: https://course.aiadvisoryboard.me/business.

FAQ

Чи можна пропустити гейти для low-stakes пілота? Можна понизити red до yellow для low-stakes внутрішнього workflow — внутрішнього research-помічника, наприклад. Але гейт названого власника (#11) і decommission criteria (#12) ніколи не опційні. Пропустити їх — це як зробити внутрішні тули неможливими до retire і неможливими до attribution, коли щось ламається.

Хто проводить ревʼю? Пілотний лід презентує. COO/Head of Ops/sponsor підписує. Власник з #11 присутній. Для пілотів з клієнтськими даними — представник security/IT. Макс 6 людей.

Як часто переробляти після запуску? Місячно перший квартал, далі щоквартально. Будь-яка велика зміна моделі, промпта, джерела, use case — позачергове ревʼю. Vendor-апгрейди моделі — теж велика зміна.

Як це повʼязано з EU AI Act? Для пілотів у регульованих категоріях (HR, кредит, освіта, healthcare) гейт-ревʼю — корисний пре-курсор до AI Act compliance — гейти #3, #6, #7, #8, #12 мапляться на risk-management вимоги. Це не замінює формальну роботу з compliance, але напівписьмова документація compliance буде готова до моменту, коли треба.

Висновок

Висновок MIT — ~95% GenAI-пілотів не доходять до production ROI — це не проблема моделі. Це проблема гейтів. Команди, що успішні, не вибирають кращі моделі — вони відмовляються запускати з red-гейтом. 12 у списку вище — ті, що SMB пропускають найчастіше; візьміть їх, проведіть ревʼю, і рішення про запуск стане однією підписаною сторінкою замість executive-інтуїції з надією.

Виберіть найприоритетніший пілот. Призначте ревʼю на наступну пʼятницю. Підготуйте артефакти. Поставте кожну клітинку. Запускайте на green.

Якщо хочете, щоб кожен співробітник запустив свою першу AI-автоматизацію за 5 днів — книжте 30-хвилинний дзвінок, ми складемо план на перший тиждень: https://course.aiadvisoryboard.me/business.