Успішна AI-демонстрація доводить, що модель здатна видати цікавий результат. Production-система має довести повторюваність, відповідальність, безпеку, контроль вартості й відновлення після помилки.
UK AI Playbook охоплює шлях від рішення про застосовність AI до безпечної розробки, купівлі та експлуатації. Впровадження — це послідовність доказових воріт, а не одна дата запуску.
Етап 1: discovery і базова точка
Опишіть один процес і одного власника. Метод із «Як обрати правильний AI-кейс» допомагає виключити розмиті, незворотні та невимірювані проєкти.
Зафіксуйте обсяг, час циклу, людські витрати, виправлення, винятки та вартість. Без базової точки пілот показує лише активність.
- Результат: односторінковий опис кейса.
- Ворота: узгоджено цінність, власника, базу й умову зупинки.
Етап 2: карта даних і прав
Перелічіть джерела, поля, документи, строки зберігання та ролі. Відокремте необхідні дані від просто доступних.
Зберіть репрезентативний тестовий набір зі звичайними, складними й виключеними випадками. Не змішуйте його з прикладами для розробки промпта.
- Результат: карта даних та eval-набір.
- Ворота: доступ законний, мінімальний, актуальний і технічно можливий.
Етап 3: обмежений прототип
Побудуйте мінімальний шлях для перевірки гіпотези. Використовуйте read-only доступ або приклади й видавайте рекомендації чи чернетки замість зовнішніх дій.
Обирайте чат-бота, workflow чи агента після розуміння шляху; порівняння архітектур пояснює компроміси.
- Результат: робочий прототип із журналом.
- Ворота: основне завдання виконується на репрезентативних прикладах.
Етап 4: пілот на реальній роботі
Запускайте реальні випадки в тіньовому режимі або як чернетки. Перевіряйте кожен підсумок, записуйте типи помилок і витрати на виправлення.
Стежте не лише за середньою якістю, а й за серйозними збоями, відсутністю джерел, неправильними інструментами та пропущеною ескалацією.
- Результат: звіт пілота відносно бази.
- Ворота: досягнуто пороги якості, винятків, безпеки та вартості.
Етап 5: оцінювання й assurance
Посібник уряду Великої Британії пропонує модульно обирати тести під систему й кейс.
Оцінюйте окремо відповідь моделі, навколишній workflow та людську перевірку. Додайте регресійні тести для змін промпта, моделі або даних.
- Результат: версіонований eval-набір і критерії.
- Ворота: результати відтворювані, обмеження задокументовані.
Етап 6: production-інтеграція
Автентифікація, права, валідація, розрахунки, ідемпотентність і запис мають бути в детермінованих сервісах. Модель отримує мінімум інструментів і полів.
Додайте черги, повтори, тайм-аути, захист від дублів і пов'язаний журнал входу, відповіді моделі, рішення людини та зовнішньої дії.
- Результат: production-архітектура й план інциденту.
- Ворота: пройдено безпеку, навантаження й тест відкату.
Етап 7: обмежений запуск
Відкрийте систему невеликій групі, одній команді або частці випадків. Збережіть ручний fallback і порівнюйте production із пілотом.
Послідовність із «AI-автоматизації для малого бізнесу» корисна й у складному проєкті.
- Результат: звіт запуску й підтвердження власника.
- Ворота: якість і вартість залишаються в межах.
Етап 8: моніторинг і керування змінами
NIST AI 800-4 систематизує категорії production-моніторингу та проблеми змінного реального контексту.
Контролюйте drift входів, якість, помилки інструментів, затримку, вартість, скасування людиною, інциденти й поведінку користувачів. Зміни моделі, промпта, джерел і правил слід версіонувати та переоцінювати.
- Результат: dashboard, сповіщення, графік рев'ю та журнал змін.
- Ворота: система має активного власника, а не лише робочий endpoint.
Чотири рішення на кожних воротах
NIST AI RMF використовує Govern, Map, Measure і Manage. На кожному етапі вирішуйте: продовжити, переробити, звузити або зупинити.
Закрити слабкий кейс після discovery — успішне рішення. Відправити його в production через уже витрачений час — ні.
Перехід до production із моєї практики
API-конвеєр блогу почався з ручного тесту однієї чернетки. Спочатку я перевірив справжній endpoint, обов'язкові поля та завантаження зображення без публікації.
Потім додав структуровані payload, повні PUT-оновлення, мовні посилання й вісім перевірок живих сторінок. Статус змінювався лише після створення чернетки, читання назад і явного дозволу.
Головним переходом став не розумніший промпт, а джерело стану, детермінований контроль, зворотний draft і перевірка після публікації.
Запитання та відповіді
Скільки має тривати пілот?
Задайте достатню кількість репрезентативних випадків і винятків, а не лише календарний строк.
Коли прототип готовий до production?
Коли вся система проходить критерії якості, безпеки, вартості, відкату й відповідальності на реальній роботі.
Що моніторити після запуску?
Входи, якість, виклики інструментів, винятки, рішення людини, затримку, вартість, інциденти та зміни.
Чи замінює демонстрація постачальника пілот?
Ні. Вона не перевіряє ваші дані, права, інтеграції, користувачів, винятки й ціну помилки.
Хто володіє production AI-системою?
Призначений бізнес-власник відповідає за підсумок, а технічні, безпекові та правові ролі — за свої контроли.