22 серпня, 2026, 11:40 153
AIN.UA 851 стаття
Антон Маруха, CEO CHI Software, у колонці для AIN пояснює, як підготувати дані, процеси та команду до впровадження ШІ, аби прискорити роботу, а не масштабувати помилки.
Надайте ШІ неповні дані — і він все одно спробує видати готовий результат. Модель не відчуває брак бізнес-контексту й без належних обмежень заповнює прогалини власними припущеннями. Тому одна й та сама технологія одним компаніям приносить багаторазове прискорення, а іншим лише допомагає швидше розмножувати помилки.
ШІ-асистенти поступово стають стандартним інструментом розробки. За прогнозом Gartner, до 2028 року ними користуватиметься приблизно 75% корпоративних інженерів. Коли доступ до технології перестає бути ексклюзивним, перевагу визначає середовище, в яке її інтегрували: дані, процеси, правила контролю та готовність команди до зміни звичного робочого процесу.
Ми в CHI Software зробили ставку на ШІ, дані й машинне навчання ще до того, як це стало поширеним явищем. Наш Data- та ML-департамент функціонує вже кілька років, тож коли з’явилася хвиля agentic-розробки, нам не довелося перевчати команду з нуля. Це дало змогу побачити обидва сценарії: завдання, що скорочуються в рази, і процеси, де автоматизація лише швидше відтворює попередні проблеми.
То де ШІ демонструє реальний результат, де він лише пришвидшує хаос, і що варто зробити, аби потрапити до першої категорії?
ШІ любить рутинну роботу
ШІ демонструє найкращі результати там, де збігаються три умови: наявність великого обсягу повторюваної роботи, достатнього контексту та зрозумілого способу перевірки результату.
Класичний приклад — тестування інтерфейсів. За традиційною схемою дизайнер створює макет, розробник верстає сторінку, тестувальник звіряє її з дизайном та створює завдання на правки в Jira. Після цього процес повторюється.
Сьогодні ШІ може порівнювати сторінку з макетом до пікселя й самостійно доопрацьовувати верстку, доки результат не буде відповідати дизайну. Кілька етапів передачі завдання між людьми скорочуються до одного керованого процесу.
Ще одна сильна сфера — робота з великими обсягами застарілого коду.
Компанія роками може експлуатувати продукт без актуальної документації, написаний на технологіях, які знає невелика кількість спеціалістів. Ми стикалися з таким випадком із системою на COBOL та старих Java-фреймворках. Раніше архітектори могли місяцями вивчати код, щоб відновити його логіку. Тепер агент аналізує кодову базу й генерує зрозумілу для людини специфікацію з діаграмами. Місяць роботи над такими завданнями скорочується до кількох днів.
Ця логіка ефективна й поза сферою розробки. Перед першим контактом з потенційним клієнтом рісерчер, контент-райтер і менеджери раніше окремо збирали інформацію про компанію, її бізнес і потенційні виклики. Тепер агент за хвилини проводить первинний аналіз, готує проєкт презентації та записує дані в CRM.
RFP або стандартний шаблон контракту теж можна спочатку довірити ШІ для швидкого перегляду за ключовими пунктами. Після цього юридичний відділ одразу зосереджується на тому, що справді потребує уваги.
Той самий принцип ми застосовуємо у розробці клієнтських продуктів.
Для європейської фінансової компанії ми розробили ШІ-помічника підтримки. Він обробляє великий обсяг однотипних запитів, використовує контекст з бази знань і надає результат, який можна перевірити. Це прискорило підготовку відповідей до 40%. Для британського медичного сервісу голосовий агент взяв на себе запис пацієнтів і приблизно на 60% скоротив час обробки дзвінків.
У виробника дані про продукцію зберігалися у незручних XML-файлах і майже не використовувалися. Створений нами агент перетворив їх на функціональну базу знань, що допомогло на 50% зменшити кількість повторних звернень до служби підтримки.
У всіх цих прикладах ШІ не визначав зміст завдання з нуля. Він діяв у межах процесу, де вже існували доступні джерела даних, визначені межі операцій та зрозумілі критерії помилок. Саме ця підготовка перетворює модель на ефективний інструмент.
Швидка помилка також може масштабуватися
ШІ скорочує цикл виконання, тому некоректно поставлене завдання можна швидше впровадити у продакшн і так само оперативно масштабувати.
Модель за замовчуванням не володіє внутрішнім контекстом компанії. Вона не виправить суперечливі дані й не визначить самостійно, який із двох бізнес-процесів є правильним. За браку достатнього контексту вона заповнить прогалини припущеннями.
Тому майже кожен серйозний ШІ-проєкт рано чи пізно стикається з базовими питаннями. Де зберігаються дані? Наскільки вони повні? Хто їх актуалізує? Яке джерело вважатиметься остаточним? За яким критерієм результат вважається правильним?
Те саме стосується розробки. ШІ може оперативно писати код, але хтось має визначити архітектуру, правила безпеки та критерії якості, а потім перевірити результат. Чим більше роботи автоматизовано, тим вищою стає вартість помилки: збій агента масштабується разом із його продуктивністю.
Саме тому швидкість не варто розглядати окремо від контролю. Якщо ШІ скорочує термін виконання завдання з місяця до кількох днів, компанія повинна так само швидко перевіряти, чи система рухається у правильному напрямку.
Що має бути готове до впровадження ШІ
З нашого досвіду, різницю між прискоренням роботи та масштабуванням помилок визначають кілька конкретних рішень.
Спочатку впорядкуйте дані, потім впроваджуйте ШІ
Компанії часто прагнуть почати з вибору моделі чи інструмента, хоча фундаментом залишаються дані.
Наприклад, у CHI Software CRM, фінанси, HR, тайм-трекінг і управління проєктами функціонують в єдиному контурі. Завдяки цьому агент може отримувати необхідний контекст і виконувати наскрізні завдання. Коли дані розкидані між десятками таблиць, аркушів і локальних файлів, навіть потужна модель не зможе усунути цю проблему.
Дайте командам вимірювану ціль
Заклик «використовуйте ШІ» є надто абстрактним. Команді необхідний показник, за яким можна буде оцінити результат.
На початку року ми поставили кожному департаменту мету скоротити витрати щонайменше на 10% завдяки ШІ. За пів року цей показник уже перевищили. Конкретна цифра стимулює команди самостійно шукати процеси, де технологія справді демонструє ефективність.
Навчіть людей, а не лише надайте їм інструменти
Ліцензії є необхідними, але самі по собі майже нічого не змінюють. Люди повинні розуміти, які завдання доцільно автоматизувати, як чітко сформулювати вимоги та за якими ознаками перевіряти результат.
Ми запустили спеціалізоване навчання для технічних спеціалістів, і зараз проходить вже четвертий потік. Навчання проходять і команди, які не займаються технічною розробкою. Керівники департаментів без технічного досвіду після дводенного курсу самостійно створюють агентів. Після цього змінюється сам погляд на робочий процес. Ручна таблиця, яку щотижня пересилають електронною поштою, вже сприймається як процес, що потребує реорганізації.
Закладіть систему контролю ще до запуску у продакшн
До впровадження необхідно визначити, до яких даних агент матиме доступ, які дії зможе виконувати самостійно, а де знадобиться підтвердження людини.
Система має зберігати історію прийнятих рішень, контролювати доступ, фіксувати помилки та витрати, а також мати резервний сценарій на випадок збою моделі. Потрібні й механізми перевірки відповідей, які допомагають виявляти потенційно неточні результати.
Саме цей шар забезпечує перехід від ефектного демо до системи, яка стабільно функціонує щодня.
Налаштуйте мультиагентність
У наших продуктових проєктах один розробник вже може керувати кількома агентами. Один пише код, другий його перевіряє, третій розгортає, четвертий створює юніт-тести, а п’ятий координує їхню роботу. Інженер керує вже цим агентом-координатором.
Але така система ефективна лише тоді, коли кожен агент має чіткі повноваження, доступ до необхідного контексту та визначений спосіб перевірки. Без цього кілька агентів створюють більше помилок і плутанини, ніж один.
Саме тому між демонстрацією мультиагентної системи та стабільною роботою на реальному продукті все ще існує значна відстань.
Різницю створює не модель
Доступ до потужних моделей сьогодні мають майже всі, тому сам вибір моделі рідко створює довгострокову перевагу. Результат визначається всією системою навколо неї: даними, процесами, інтеграціями, правилами контролю та компетенціями команди.
ШІ може взяти на себе значну частину рутинної роботи між постановкою завдання та отриманням готового результату. Чим швидше він проходить цей шлях, тим більше значення має якість рішень на його початковому етапі.
Тому впровадження варто починати не з переліку моделей, а з аналізу процесів. Де команда повторює однакові дії? Де вже накопичено достатньо даних? Який результат можна об’єктивно верифікувати? Де помилка потребує людського підтвердження?
Відповіді на ці питання покажуть потенціал ШІ значно точніше, ніж демонстраційні версії. Вони також допоможуть визначити, що у вашій роботі вже готове до прискорення, а що потребуватиме впорядкування насамперед.
Источник: www.ukrinform.ua