Чому проєкти AI провалюються і як цього уникнути

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

Причиною майже ніколи не була модель. Був процес навколо неї.

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

Вимірювана мета — це конкретне речення: «час обробки одного звернення скорочується з 8 до 3 хвилин у 80% випадків» або «класифікатор направляє 70% запитів до потрібної черги без втручання людини». Таке речення також визначає, коли проєкт готовий перейти з пілоту до продакшену.

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

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

Три симптоми поганих вхідних даних:

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

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

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

Два механізми, які є обов'язковими в кожній продуктивній системі:

Відповідь «не знаю» з ескалацією. Модель, яка не знайде достатньо впевненої відповіді в базі знань, не повинна вгадувати. Вона має сказати прямо: «У мене немає достовірної інформації з цього питання» та запропонувати зв'язок з людиною. Проєктування цього шляху описує стаття про моніторинг та якість агента AI.

Тематичні guardrails. Система, що працює в галузі обслуговування клієнтів інтернет-магазину, не відповідає на юридичні питання, не надає конкретні ціни страхувань, не діагностує медичні проблеми. Guardrails визначаються як список дозволених намірів або заблокованих категорій запитів. Кожна спроба вийти за межі діапазону логується та ескалується.

Відсутність цих механізмів призводить не лише до низької якості відповідей, а й до юридичної відповідальності за контент, який створила система.

Проєкти AI регулярно потрапляють у пастку: дані підключені, модель відповідає, ніхто не перевірив, що саме потрапляє до моделі та де обробляється. Особливо болючі сценарії:

• Персональні дані клієнтів (імена, номери замовлень, адреси) потрапляють у промптах до зовнішніх API без псевдонімізації.
• Логи розмов містять PII у відкритому вигляді та зберігаються без правової підстави.
• Компанія користується хмарним API для моделі, а договір з постачальником не відповідає вимогам ст. 28 RODO (процесор даних).

Мінімальні вимоги безпеки для кожного проєкту AI, що обробляє персональні дані:

1. Маскування PII перед наданням моделі (у роутері, а не в клієнтській програмі).
2. Договір доручення обробки з постачальником моделі або self-hosting у власній інфраструктурі.
3. Зберігання даних з розмов обмежене мінімумом, необхідним для мети, з автоматичним видаленням.
4. Шлях реалізації права на видалення даних (RODO ст. 17), особливо важливий для ембедінгів та векторних баз.

Для процесів високого ризику (медичні, фінансові, кадрові дані) потрібна DPIA перед запуском. Деталі обов'язків компаній у 2026 році описує стаття AI Act та RODO 2026.

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

Human-gate — це не повне вимкнення автоматизації. Це зупинка агента перед незворотним кроком і очікування на явне підтвердження оператора. Підтвердження логується: хто, коли, у контексті якого завдання. На практиці працює модель п'яти питань перед кожною дією високого ризику:

1. Чи змінює дія стан системи у спосіб, важкий для скасування?
2. Чи має помилка в цій дії прямі наслідки для клієнта або фінансові?
3. Чи мала модель доступ до повних даних, необхідних для цього рішення?
4. Чи є результат попереднього кроку певним (не оціненим)?
5. Чи виконувалася ця дія вже в аналогічному контексті з успіхом?

Відповідь «ні» на будь-яке з цих питань — сигнал для зупинки та ескалації. Детальну архітектуру цього механізму описує стаття про роль людини в петлі агента.

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

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

Мінімальний моніторинг для продуктивної системи:

Архітектуру повного моніторингу описує стаття про моніторинг та KPI агента AI. Оцінку якості відповідей RAG методом golden set описує стаття про оцінку RAG.

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

Характеристики процесу, придатного для старту:

• Повторюваність: мінімум 50 подібних випадків на місяць.
• Визначуваність: кожен крок можна описати правилом або схемою рішення.
• Перевіряємість: результат можна перевірити програмно або простою перевіркою.
• Обмежений обсяг рішень: не вимагає контекстних знань поза доступними даними.
• Не є процесом високого ризику в розумінні AI Act Додаток III (або компанія готова до повного комплаєнсу).

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

Серед проєктів, які завершуються впровадженням у продакшен, переважна більшість пройшла етап shadow mode. Агент працює паралельно з людиною протягом 2-4 тижнів: обробляє ті самі дані, генерує ті самі відповіді, але результати не застосовуються. Натомість їх порівнюють з рішеннями людини.

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

Лише після shadow mode з розбіжністю нижче встановленого порогу (зазвичай 5-10% рішень, відмінних від людських) система переходить до етапу пілоту з human-gate. Повний графік і план впровадження крок за кроком описує стаття план впровадження AI.

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

Ні. RAG (пошук на базі знань) добре працює з кількома сотнями до кількох тисяч документів, якщо вони актуальні та узгоджені. Fine-tuning вимагає великих наборів, але більшість проєктів першої фази в ньому не потребують. Ключова якість і актуальність даних, а не їх кількість. Компанія з 200 хорошими документами створить кращу систему, ніж компанія з 20 000 документами, половина з яких застаріла або суперечлива. Аудит даних перед проєктом описує стаття про підготовку корпоративних даних для AI.

Для одного добре обраного процесу: 6-10 тижнів від підписання договору до рішення про перехід у продакшен. Тиждень 1-2: аудит даних та проєктування guardrails. Тижні 3-5: shadow mode. Тижні 6-8: пілот з human-gate та моніторинг. Тижні 9-10: рішення та можливі корективи. Проєкти скорочуються, якщо компанія вже має підготовлені дані та визначену мету. Затягуються при інтеграції з багатьма системами або відсутності доступу до історичних даних. Орієнтовну вартість пілоту розраховує калькулятор ROI.

Перевірте, чи процес кваліфікується як система високого ризику в розумінні AI Act Додаток III. Це стосується сфер: працевлаштування (відбір кандидатів, оцінка працівників), фінансові послуги (кредитний скоринг), освіта, охорона здоров'я та деякі інші. Для таких систем потрібні: DPIA, технічна документація, реєстрація системи в базі ЄС, механізм людського нагляду та прозорість для користувачів. Детальний опис обов'язків у 2026 році містить стаття AI Act та RODO 2026.

Чотири контрольні питання перед переходом з пілоту у продакшен: (1) Показник помилок на golden set нижче встановленого порогу? (2) Guardrails протестовані на реальних крайових випадках, а не лише синтетичних? (3) Шлях ескалації до людини працює та моніториться? (4) Дані в базі знань актуальні та узгоджені з поточною пропозицією або процедурами? Лише коли всі чотири пункти зелені, впровадження у продакшен має сенс. Оцінку готовності підтримує інструмент оцінка готовності.

Так, але це вимагає діагностики причини, а не додавання нових функцій. Найпоширеніші виправлення: оновлення бази знань (якщо проблема — дрейф даних), додавання шару guardrails та шляху «не знаю» (якщо проблема — неконтрольовані відповіді), впровадження моніторингу golden set (якщо проблема — відсутність видимості). Проєкти, які застрягли через неправильний вибір процесу, потребують повернення до кроку вибору та можливого пілоту на іншому процесі. Першим кроком завжди є діагностика, а не переписування з нуля. Напишіть нам через контакт з описом ситуації. Проаналізуємо та запропонуємо шлях виправлення.