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