Від пілоту AI до продакшену: що насправді змінюється

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

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

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

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

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

• Моніторинг та алерти. Без observability ви знаєте лише, що агент «відповідає», а не те, чи відповідає добре. Потрібні метрики якості, затримки p50/p95, вартість на справу та алерти, які розбудять когось, перш ніж це зробить клієнт. Докладніше розбираємо це в тексті про моніторинг якості агента AI.
• Guardrails. Guardrails — це шар, який блокує спроби ін’єкції інструкцій, витоку даних та відповідей поза межами компетенції. У пілоті ніхто не атакує агента; у продакшені хтось спробує першого дня. Механіку описуємо в статті про безпеку агентів AI.
• Людина в циклі. Нагляд людини та чіткий шлях ескалації вирішують, коли агент передає справу далі. Це не провал системи — це умова, щоб взагалі запустити її в продакшен.
• Контроль витрат. Ліміти на день, бюджети за каналами та router LLM, який обирає дешеву модель для простих завдань. Без цього рахунок росте лінійно з трафіком і стає непередбачуваним.
• Rollback. Можливість миттєво повернутися до попередньої версії промпту, бази знань або моделі, якщо зміна погіршила якість. У продакшені кожна зміна — це ризик, поки її не можна відкотити за хвилину.
• Обробка крайніх випадків. Що робить агент, коли база знань не має відповіді, запит двозначний, інтеграція не відповідає. У пілоті ці шляхи не з’являються; у продакшені вони — щоденна рутина.

Операційний шар — це різниця між «запустили» та «контролюємо». Три механізми, які варто мати з першого дня продакшену.

Моніторинг починається з роутера, через який проходять усі виклики моделі. Кожен логує мітку часу, модель, кількість токенів, затримку та результат guardrails (пропущено / заблоковано / ескалація). З цього будуєте всі метрики та алерти — без цього логу немає даних, лише враження.

Контроль витрат — це ліміти та fallback. Добовий ліміт за каналом обмежує витрати, коли трафік вибухає, а роутер спрямовує прості завдання (класифікація, маршрутизація) на малу модель, а велику резервує для складних випадків. Реальні ставки та спосіб розрахунку одиничної вартості розбираємо в тексті про те, скільки коштує агент AI.

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

SLA змінює вимоги якісно. Демо працює, коли хтось дивиться; продакшен має працювати цілодобово, з певним часом відповіді та планом на випадок, коли модель у хмарі перестає відповідати. Це вимагає fallback, черг та чітких правил деградації — що робить агент, коли не може відповісти в межах SLA.

Guardrails у продакшені багатошарові, а не одноразовий фільтр. Перевіряємо вхідний запит (спроби ін’єкції, витік даних), контролюємо обсяг відповіді та логуємо кожне блокування в аудит-трейс. Найважливіше — захисні патерни мають покривати всі мови обслуговування — атака іншою мовою, ніж українська, пройде, якщо правила охоплюють лише українську. Повний огляд шарів дає аудит безпеки асистента AI.

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

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

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

Бо пілот працював на легкому, підібраному трафіку, без SLA і без нетипових запитів. Продакшен додає повний хвіст дивних випадків, більший обсяг і реальні наслідки помилки. Це не регрес моделі, а виявлення операційного шару, якого в пілоті не було.

Моніторинг і guardrails. Без моніторингу не знаєте, чи агент працює добре, а не просто відповідає; без guardrails перший нетиповий трафік може закінчитися витоком даних або хибною відповіддю. Контроль витрат і rollback йдуть слідом, перш ніж трафік зросте.

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

Це залежить від кількості інтеграцій та необхідного SLA, тому наводимо діапазон, а не конкретне число. Для вузького, одного каналу реально кілька тижнів; широкий продакшен, інтегрований з багатьма системами, — це більший проект, який рахується місяцями. Поетапний підхід дозволяє доставляти цінність вже на ранніх кроках, не чекаючи на все.

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