Перший день AI у компанії: які дані йому можна довірити

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Привіт, спільното DOU!

Мене звати Ярослав Кацалай, я CTO та співзасновник One Service Consulting. Ми допомагаємо компаніям наводити лад у бізнес-процесах, обирати та впроваджувати ERP-системи.

У попередній статті я писав про те, як обирати між кодом, ML, LLM і людиною залежно від бізнес-задачі. Там я кілька разів повертався до одного застереження: якщо на вході неякісні дані, хороша модель ситуацію не врятує.

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

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

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

За дослідженням Cloudera та Harvard Business Review Analytic Services, лише 7% підприємств вважають свої дані повністю готовими до AI, а ще 27% кажуть, що вони не дуже готові або не готові зовсім. В опитуванні взяли участь понад 230 керівників, залучених до рішень щодо даних та AI.

Але мені тут цікавіше інше питання: що взагалі означає «дані готові до AI»?

Бо це дуже легко перетворити на абстрактний ІТ-проєкт: почистити довідники, налаштувати інтеграції, перевірити поля — і поставити галочку. На практиці для AI цього вже недостатньо.

Що змінилося: людина більше не остання лінія захисту

Я займаюся автоматизацією вже 20 років і не маю ілюзій ідеальності. Роками компанії можуть жити з неідеальними даними. Практична юзер-сторі: аналітик відкриває звіт, бачить дивну цифру і думає: «Такого не може бути». Тут беремо до уваги досвідченного аналітика, який дійсно побачить нестиковку і піде перевіряти джерело, питати фінансиста або менеджера, та в кінцевому випадку знайде помилку.

Тобто без AI між поганими даними та бізнес-рішенням майже завжди стоїть людина. З AI-агентами ж ця конструкція змінюється.

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

Це одна з причин, чому Roxane Edjlali, Senior Director Analyst Gartner прогнозує, що протягом 2026 року компанії відмовляться від 60% AI-проєктів, які не забезпечені AI-ready data.

Для себе я розкладаю готовність даних до AI на п’ять вимірів.

1. Якість: чи описують дані реальність

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

У звичайній роботі команда часто знає про ці проблеми й несвідомо їх компенсує. Наприклад, у CRM є два записи одного клієнта: «ТОВ Альфа» та «Альфа, ТОВ». Менеджер знає, що це одна компанія, тому перед відвантаженням перевірить обидві картки.

AI-агент цього «знати» не зобов’язаний. Якщо кредитний ліміт і заборгованість розділилися між двома записами, агент може перевірити лише один і підтвердити відвантаження, яке компанія насправді не повинна була дозволяти.

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

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

Тому краще дивитися в корінь: якщо помилка системна, виправляти варто джерело, а не кожного нового агента окремо вчити з нею жити.

І тут AI, до речі, може бути частиною рішення. Наприклад, регулярно моніторити довідники, знаходити потенційні дублікати або підозрілі записи й передавати їх на перевірку людині. Тобто не маскувати проблеми в даних додатковими промптами, а допомагати поступово їх прибирати.

Тому критерій доволі простий: чи дають дані агенту ту саму картину бізнесу, яку бачить компетентна людина?

Якщо відповідь «ні» — починати варто не з промпта.

2. Доступ: чи бачить агент лише те, що йому дозволено

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

Пілот працює. Усі задоволені. А тимчасові права залишаються назавжди.

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

Технічно система спрацювала правильно. Архітектурно — ні.

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

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

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

3. Контекст: чи знає AI, що означає число

Дані можуть бути абсолютно правильними й водночас непридатними для AI.

Наприклад, у полі записана сума 100 000. Але що це означає? З ПДВ чи без? Гривні, долари чи євро? За яким курсом? Це дохід, оплата чи сума підписаних контрактів?

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

Наприклад, агент бачить зростання виторгу на 18%, хоча частина угод записана в іншій валюті. Після нормалізації реальне зростання — лише 3%. Тут проблема не в галюцинації моделі. Вона цілком чесно порахувала те, що їй дали. Тому готові до AI дані мають не лише значення, а й метадані та правила трактування: джерело, валюту, дату курсу, логіку розрахунку показника.

Іноді правильна відповідь агента має бути не «18%», а «ці дані зараз не можна коректно порівняти».

Для мене друге навіть цінніше.

4. Свіжість: чи бачить агент «зараз», а не «вчора»

Класична BI-аналітика чудово могла жити на нічних вивантаженнях. Якщо керівник вранці дивиться звіт за вчора, дані станом на кінець учорашнього дня абсолютно доречні. З агентами все залежить від конкретного сценарію.

Уявімо AI-помічника, який о 15:00 відповідає клієнту щодо наявності товару. Але залишки він отримує з копії бази, оновленої о 02:00. Товар продали об 11:00. У результаті клієнт отримує автоматичне підтвердження на позицію, якої вже немає. Так, тут помилитися може і людина. Проте якщо ми говоримо про автоматизацію задля уникнення людського фактору, то і специфіку AI теж треба враховувати. Бо виходить, що ми не автоматизували сервіс — ми автоматизували порушення обіцянки.

Тому питання свіжості я б завжди прив’язував до темпу конкретного рішення. Для звіту за місяць дані з затримкою у кілька годин можуть бути нормою. Для залишків, платежів або статусу замовлення — вже ні.

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

5. Прослідковуваність: чи зможемо пояснити рішення через півроку

Мабуть, найменш помітна вимога на старті й одна з найдорожчих, коли про неї згадують після інциденту. Агент ухвалив рішення. Через три місяці клієнт, аудитор або керівник питає: чому саме так? Наприклад, AI відхилив заявку клієнта на товарний кредит. У логах ми бачимо лише факт: «відмовлено», дата і час. Але яких саме клієнтських записів торкнувся агент? Якою була заборгованість на той момент? Яку версію правил він використовував? Які дані отримав? Якщо цього не зберегли, компанія не може нормально ані захистити рішення, ані визнати свою помилку.

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

Не потрібно спочатку «почистити всю компанію»

Тут легко впасти в іншу крайність. Після всього написаного логічний висновок може звучати так: «Добре, спочатку наведемо лад у всіх даних, а вже потім підемо в AI». Але я б цього теж не радив.

У великій компанії «навести лад у всіх даних» — це проєкт без чіткого фіналу. З’являються нові системи, поля, інтеграції, працівники, міграції. Data readiness — не стан, який одного разу отримали й більше до нього не повертаємося.

До речі, актуальні дослідження Gartner теж описують AI-ready data як безперервну, прив’язану до use case практику, а не одноразову підготовку даних.

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

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

Мій короткий тест перед запуском AI-сценарію

Для першої перевірки я б поставив три питання (так, знову у формі таблички, які я так люблю):

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

Замість підсумку

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

Тому для себе я визначаю готовність не фразою «в нас чиста база», а п’ятьма питаннями:

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

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