Як обрати підрядника для розробки AI-агента: чеклист

Більшість компаній обирають не того вендора — і дізнаються про це вже після запуску

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

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

Чому стандартний процес оцінки вендорів тут не працює

Купити AI-агента — це не те саме, що купити корпоративне ПЗ. З CRM чи ERP ви оцінюєте готовий продукт. З AI-агентом ви оцінюєте здатність команди побудувати те, чого ще не існує в повному вигляді: систему, яка буде міркувати, приймати рішення і діяти всередині вашого конкретного операційного середовища.

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

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

Справжній ризик не в тому, що вендор бреше. Ризик у тому, що він щиро не знає, чого не знає — і ви теж, поки агент не опиниться в продакшні.

Пастка демо

Вендори оптимізуються під демо. Вони будують чистий, «щасливий» сценарій на відфільтрованих даних, без неоднозначних вхідних даних, без конфліктуючих бізнес-правил, без примх застарілих систем. Агент виглядає блискуче. Потім він зустрічає ваш реальний процес закупівель — із сімнадцятьма типами виключень, трьома рівнями погодження, мішаниною PDF-рахунків і рукописних форм — і тріщини з'являються одразу.

Рішення просте, але рідко застосовується: вимагайте від вендора провести proof of concept на ваших даних, у вашому середовищі, на ваших реальних граничних випадках. Не пісочниця. Не симуляція. Ваші справжні, «брудні» вхідні дані. Будь-який вендор, який чинить опір, вже сказав вам щось важливе.

Чеклист: шість критеріїв, які реально передбачають успіх у продакшні

1. Глибина архітектури, а не кількість функцій

Попросіть вендора пояснити, як їхній агент обробляє: вибір і заміну моделі, retrieval-augmented generation (RAG) або управління контекстом, збереження стану в багатокрокових процесах і оркестрацію інструментів. Якщо вони не можуть чітко пройтися по кожному шару — або описують це як «чорну скриньку, яка просто працює» — це жорстке «стоп».

Агент виробничого рівня — це не одна модель із промптом. Це система з компонентами: шар міркування, шар пам'яті, шар використання інструментів і шар оркестрації, який їх координує. Вендори, що будували реальних агентів, описують цю архітектуру простою мовою. Ті, хто не будував, переключаться на розмову про базову модель (GPT-4, Claude, Gemini) — ніби модель і є продуктом.

Щоб краще розуміти, як ці архітектурні рішення впливають на бізнес-результати, перед першим дзвінком із вендором варто прочитати порівняння LangChain, CrewAI та AutoGen — це дасть словник для гостріших запитань.

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

2. Якість інтеграцій — найсильніший одиночний предиктор успіху

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

Запросіть список конекторів вендора письмово. Потім під час proof of concept протестуйте дві інтеграції, найважливіші для вашого процесу, — не ізольовано, а послідовно, так, як агент буде їх реально використовувати. Вендор, що підтримує лише одну «щасливу» інтеграцію, загальмує, щойно ваш стек ускладниться.

Перевірте окремо: як агент автентифікується у ваших системах? Як обробляє закінчення токенів, ліміти запитів і збої API? Що відбувається, коли downstream-система недоступна — агент завершує роботу коректно, передає людині чи мовчки видає неправильний результат?

3. Контроль людини в процесі — рівневий, а не бінарний

Кожне серйозне впровадження AI-агента потребує людського нагляду. Питання не в тому, чи він існує, а в тому, як структурований. Вендор, який трактує human-in-the-loop (HITL) як єдиний перемикач «увімк/вимк», не думав серйозно про виробничі ризики.

Потрібна рівнева логіка погодження: дії з низькими ставками і зворотним ефектом (підготовка документа, формування звіту) виконуються автономно; дії з середніми ставками (відправка зовнішньої комунікації, оновлення запису) запускають сповіщення; дії з високими ставками і незворотними наслідками (фінансові зобов'язання, комплаєнс-подання, виконання контракту) вимагають явного дозволу людини перед тим, як агент діє.

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

4. Безпека, комплаєнс і управління даними

Це базовий рівень, але деталі важливі. Мінімум — вимагайте сертифікацію SOC 2 Type II. Залежно від галузі, можуть знадобитися відповідність GDPR, контролі HIPAA або вирівнювання за PCI-DSS. Запитайте прямо: куди потрапляють ваші дані, коли агент їх обробляє? Чи використовуються вони для навчання базової моделі? Де зберігаються і в якій юрисдикції?

Окрім сертифікатів, перевірте підхід вендора до prompt injection — класу атак, де шкідливі вхідні дані змушують агента виконувати ненавмисні дії. Будь-який вендор, що будує агентів, які взаємодіють із зовнішніми джерелами даних (листи, документи, вебконтент), повинен мати задокументований підхід до обробки ворожих вхідних даних. Якщо при цьому питанні вони дивляться в порожнечу — вони не готові до продакшну.

Вимагайте, щоб усі зобов'язання щодо аудит-треку та управління даними були в контракті, а не лише в презентації. Маркетингові обіцянки не зобов'язують. Пункти контракту — так.

5. Стійкість вендора і умови виходу

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

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

6. Підтримка, моніторинг і управління дрейфом моделі

AI-агент — це не ПЗ, яке розгортають і забувають. Моделі дрейфують. API змінюються. Бізнес-правила еволюціонують. Робота вендора не закінчується на запуску — вона там починається.

Запитайте конкретно: хто моніторить продуктивність агента після запуску? Які метрики відстежуються — відсоток виконаних завдань, частота ескалацій, частота помилок, затримка? Як вони виявляють деградацію точності агента? Яке SLA для реагування на інциденти і що вважається інцидентом?

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

Реальний кейс: що відбувається, коли ігноруєш чеклист

Klarna, компанія з ринку buy-now-pay-later, розгорнула AI-агента для клієнтського сервісу на базі OpenAI на початку 2024 року. Вже в перший місяць роботи агент обробляв близько 2,3 мільйона розмов із клієнтами — еквівалент навантаження 700 штатних співробітників. Час відповіді скоротився з середніх 11 хвилин до менш ніж 2 хвилин. Частота повторних звернень впала на 25%. Оцінюваний річний вплив на прибуток: $40 мільйонів.

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

Протилежна картина — та, що повторюється знову і знову в компаніях середнього ринку: вендора обирають після переконливого демо, proof of concept пропускають заради економії часу, інтеграцію вважають другорядним питанням, а агент іде в продакшн без жодного фреймворку моніторингу. Через шість місяців агент обробляє 30% запланованого обсягу, решта все одно падає на людей, а бізнес витратив удвічі більше початкового бюджету, намагаючись залатати прогалини.

Різниця між цими двома результатами майже повністю в процесі оцінки — конкретно в тому, чи ставив покупець правильні питання до підписання.

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

Червоні прапори: йдіть, коли бачите це

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

• Вендор не може пояснити режими відмов. Якщо на питання «що відбувається, коли агент зустрічає вхідні дані, які не може обробити?» відповідь розмита або оптимістична — у агента немає коректної деградації. У продакшні це означає тихі помилки.
• Аудит-трек описується як «оцінки впевненості». Оцінка впевненості — це не аудит-трек. Вона показує, наскільки модель була впевнена, а не що вона зробила, чому і які дані використала. Регульовані середовища вимагають саме останнього.
• Контрактні зобов'язання відсутні в контракті. Якщо зобов'язання щодо управління, резидентності даних і продуктивності існують лише в презентації — вони не існують.
• Вендор чинить опір proof of concept на ваших даних. Це найчіткіший сигнал того, що демо-середовище і виробниче середовище — не одне й те саме.
• Немає названих виробничих референсів. Вендори без виручки і лише з design-partner-угодами не готові до закупівель для бізнесу з реальними операційними ставками. Вимагайте щонайменше трьох названих клієнтів, які запускають агента в продакшні прямо зараз.

Як структурувати процес оцінки

Добре організована оцінка вендора для AI-агента не мусить бути тривалою — але має бути структурованою. Реалістичний таймлайн від початкового RFP до вибору вендора — вісім-дванадцять тижнів: приблизно два тижні на відповіді вендорів, два тижні на внутрішнє оцінювання, два тижні на сфокусовані демо за найсильнішими відповідями і два тижні на proof of concept на ваших реальних даних.

Остання фаза — proof of concept — це місце, де більшість оцінок руйнуються. Покупці пропускають її, щоб прискорити таймлайн, або вендори виторговують її скасування. Не дозволяйте ні того, ні іншого. POC — єдиний момент до підписання контракту, коли ви можете побачити, як агент реально поводиться у вашому середовищі. Все до цього — театр.

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

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

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

---

FAQ

Скільки часу зазвичай займає оцінка і вибір вендора AI-агента? Структурована оцінка — від RFP до вибору вендора — зазвичай займає вісім-дванадцять тижнів. Прискорення цього таймлайну, особливо за рахунок пропуску фази proof of concept, — одна з найпоширеніших і найдорожчих помилок у закупівлях AI.

Чим AI-агент відрізняється від звичайного чат-бота або RPA-інструменту? Чат-бот слідує фіксованому сценарію і обробляє заздалегідь визначені вхідні дані. RPA-інструмент виконує засновані на правилах послідовності на структурованих даних. AI-агент міркує над неоднозначними вхідними даними, динамічно використовує інструменти, зберігає стан у багатокрокових процесах і приймає рішення — включно з рішенням ескалювати до людини. Критерії оцінки відповідно суворіші.

Чи варто вимагати, щоб код належав нам, або прийнятний managed service? Обидві моделі можуть працювати, але профіль ризику різний. З managed service ви залежите від вендора щодо безперервності — якщо його куплять або він закриється, ваш агент може перестати працювати. З правом власності на код ви зберігаєте можливість самостійно підтримувати і розвивати систему. Мінімум — вимагайте задокументованого процесу виходу і гарантії повернення даних незалежно від обраної моделі.

Які сертифікати безпеки вимагати як базовий рівень? SOC 2 Type II — базовий рівень для більшості корпоративних впроваджень. Залежно від галузі, можуть знадобитися документація відповідності GDPR, контролі HIPAA або вирівнювання за PCI-DSS. ISO 42001 — стандарт, що формується для систем управління AI, — дедалі більше актуальний для вендорів, що будують агентів у регульованих середовищах.

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

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

---

Цифри Klarna — $40 мільйонів річного впливу на прибуток, еквівалент 700 штатних співробітників, суттєво швидший час відповіді — реальні. Але вони також є результатом впровадження, яке з самого початку було побудовано правильно, а не врятовано після невдалого запуску. Перш ніж підписати з вендором, пройдіться по шести критеріях вище і чесно запитайте себе: я тестував це у своєму середовищі, чи бачив лише в їхньому? Відповідь на це питання визначить, по який бік розподілу результатів ви опинитеся.

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