Антон Маруха, 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% завдяки ШІ. За пів року цей показник вже був перевищений. Конкретна цифра спонукає команди самостійно знаходити процеси, де технологія дійсно приносить ефект.
Навчіть людей, а не лише надайте їм інструменти
Ліцензії є необхідними, але самі по собі майже нічого не змінюють. Люди мають розуміти, які завдання варто автоматизувати, як сформулювати вимоги та за якими ознаками перевірити результат.
Ми запустили окреме навчання для технічних спеціалістів, і зараз проходить уже четвертий потік. Навчання проходять і команди, що не є технічними. Керівники департаментів без технічної підготовки після дводенного курсу самостійно створюють агентів. Після цього змінюється сам погляд на роботу. Ручна таблиця, яку щотижня пересилають електронною поштою, вже сприймається як процес, який потребує оптимізації.
Закладіть систему контролю ще до виходу в продакшен
До запуску необхідно визначити, які дані агент може переглядати, які дії виконувати самостійно і де потрібне підтвердження людини.
Система має зберігати історію рішень, контролювати доступ, фіксувати помилки та витрати, а також мати резервний сценарій на випадок збою моделі. Потрібні також механізми перевірки відповідей, які допомагають виявляти потенційно неточні результати.
Саме цей шар відрізняє ефектне демонстраційне рішення від системи, яка стабільно функціонує щодня.
Налаштуйте мультиагентність
У наших продакшн-проєктах один розробник уже може керувати кількома агентами. Один пише код, другий його перевіряє, третій розгортає, четвертий створює юніт-тести, а п’ятий координує їхню роботу. Інженер керує вже цим агентом-координатором.
Але така система працює лише тоді, коли кожен агент має чіткі повноваження, доступ до необхідного контексту та визначений спосіб перевірки. Без цього кілька агентів створюють більше помилок і “шуму”, ніж один.
Саме тому між демонстрацією мультиагентної системи та стабільною роботою на живому продукті досі існує значна дистанція.
Різницю створює не модель
Доступ до потужних моделей сьогодні мають практично всі, тому сам вибір моделі рідко створює стійку конкурентну перевагу. Результат визначає вся система навколо неї: дані, процеси, інтеграції, норми контролю та компетенції команди.
ШІ може взяти на себе значну частину рутинної роботи між постановкою завдання та отриманням готового результату. Чим швидше він проходить цей шлях, тим вагомішою стає якість рішень, прийнятих на його початку.
Тому впровадження варто починати не з переліку моделей, а з аналізу процесів. Де команда повторює однакові дії? Де вже є достатньо даних? Який результат можна об’єктивно верифікувати? Де помилка потребує підтвердження людини?
Відповіді на ці запитання покажуть потенціал ШІ значно точніше, ніж демонстрації. Вони також допоможуть визначити, що у вашій роботі вже готове до прискорення, а що спершу доведеться впорядкувати.