[Канал відповідності] Генератори застосунків і AI-IDE: поріг розробки впав, але 5 барʼєрів до даних користувача — ні — Трансформація програмної інженерії в епоху AI — Повільне навчання AI 176

Поріг створення застосунків упав, а поріг доступу до даних користувачів — ні

Керівники середніх платформ в електронній комерції останнім часом ставлять мені одне й те саме питання: бізнес-підрозділи за тиждень власноруч збирають три внутрішні інструменти за допомогою AI, а в IT черга на розробку розписана аж до наступного кварталу. Де саме тут вузьке місце?

Наша відповідь — один єдиний висновок: поріг розробки впав, а поріг доступу до даних користувачів — ні.

За цим твердженням стоять дві події, які відбуваються одночасно.

Bolt.new — це продукт компанії StackBlitz, тихо запущений у жовтні 2024 року через один твіт. За п’ять місяців він досяг $40 млн річного регулярного доходу (ARR). Sacra та Growth Unhinged відстежують його як другий за швидкістю зростання продукт в історії (після ChatGPT). Наприкінці фінансового 2026 року CEO StackBlitz Ерік Саймонс повідомив у LinkedIn: Bolt.new уже використовують три чверті компаній зі списку Fortune 500, а корпоративний ARR зріс у 10 разів рік до року (офіційний пост Еріка Саймонса, підсумки фінансового 2026 року). Lovable — це команда зі Стокгольма (засновник — Антон Осіка). У листопаді 2025 року компанія залучила $200 млн у раунді A за оцінки $1.8 млрд, а вже наприкінці грудня 2025 року — раунд B за оцінки $6.6 млрд. Тобто за пів року оцінка зросла майже вчетверо (дані підтверджуються Forbes, CNBC, Bloomberg, TechCrunch). У червні 2026 року ARR Lovable перевищив $500 млн (репортаж Forbes, паралельно опубліковано TechCrunch 2026-06-09). Того ж дня Forbes, посилаючись на чотирьох обізнаних співрозмовників, повідомив, що компанія веде новий раунд фінансування за оцінки $12 млрд (тобто майже вдвічі більше). Інструменти цього класу скорочують шлях від ідеї до робочого застосунку з «кількох місяців роботи команди» до «одного дня однієї людини».

Але разом із тим, як бар’єр входу в розробку впав, найдорожчі та найбільш блокуючі етапи у вашій компанії залишилися недоторканими: оцінка трансферу даних за кордон, атестація захищеності (КСЗІ Держспецзв’язку — аналог MLPS у КНР), реєстрація алгоритмів, погодження змін (Change Advisory Board), звірка та аудит. Ці етапи майже не пов’язані з самим кодом, але кожен із них забирає тижні. Генератори застосунків відчинили перші двері — бізнес-підрозділи тепер можуть створювати власні застосунки. Але другі двері — хто має право достукатися до виробничих даних, хто може змінювати критичні транзакції — залишилися зачиненими.

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

Реальний сценарій, з яким ми стикалися (електронна комерція, дані знеособлені): Команда з роботи з блогерами одного з найбільших українських маркетплейсів (Rozetka / Allo / Prom.ua — типовий представник) за два місяці самостійно зібрала 7 внутрішніх інструментів за допомогою Lovable: підбір блогерів, розрахунок комісій, відстеження хітів, атрибуція повернень. Технічний відділ про це не повідомляли. Під час піврічної інвентаризації Shadow IT з’ясувалося, що 4 з цих інструментів читають широкі таблиці замовлень із номерами телефонів та адресами доставки, а 2 експортують дані в особисті хмарні сховища Google Drive / Dropbox. Це типова ситуація, з якою команди української електронної комерції стикаються під час інвентаризації активів з другої половини 2025 року — це не поодинокий випадок.

Реальний сценарій, з яким ми стикалися (телеком, дані знеособлені): Під час внутрішнього тренінгу в одному з регіональних підрозділів «Київстар» менеджер маркетингового центру зізнався, що вони вже зібрали за допомогою Bolt «інструмент швидкого перегляду профілю клієнта», який за номером телефону витягує історію змін тарифів за 90 днів, історію скарг і таблицю рекомендованих пропозицій — технічний відділ про це навіть не знав. Це пряме порушення статей 6, 7 та 11 Закону України «Про захист персональних даних» щодо мети обробки, згоди та обмеження доступу.

Спочатку подивіться на схему, щоб зрозуміти, як виглядає ця прогалина.

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

1. Спочатку розставимо ці п’ять інструментів по своїх місцях

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

Перша група — «ті, хто вміє писати код». Їм потрібен швидший редактор коду: інструмент, який розуміє контекст вашої кодової бази, вносить зміни між файлами, автоматично запускає тести та пояснює помилки. Типові представники — Cursor, Trae від ByteDance, Tongyi Lingma від Alibaba, GitHub Copilot. Їхня логіка проста: ви вже інженер, а інструмент бере на себе рутинну роботу. Цю категорію ми детально розглядали в четвертій частині серії, тож тут не повторюватимемось. Важливо: такі IDE — це точки дотику з резидентними та нерезидентними серверами розробників, тож для українських банків і операторів вони перетинаються з вимогами статті 29 Закону України «Про захист персональних даних» (транскордонна передача) та статті 9 Закону «Про основні засади забезпечення кібербезпеки України».

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

Ми розглянемо чотири такі генератори застосунків, а з AI-IDE окремо виокремимо Trae — бо він зачіпає критично важливий для високорегульованих галузей момент.

Bolt.new (від StackBlitz). У жовтні 2024 року з’явився твіт без зайвого галасу — і продукт став другим за швидкістю зростання в історії (поступаючись лише ChatGPT), за даними Sacra та Growth Unhinged. Перший мільйон ARR — за тиждень, чотири мільйони — за місяць, двадцять мільйонів — приблизно за два місяці, сорок мільйонів — за п’ять. Близько п’яти мільйонів зареєстрованих користувачів (за офіційними даними CEO StackBlitz). У його основі — технологія WebContainers, яка запускає повноцінне середовище Node.js прямо в браузері. Тож AI може безпосередньо працювати з файлами, встановлювати пакети та піднімати сервіси — без жодного налаштування локального середовища. На момент завершення 2026 фінансового року Bolt.new використовували три чверті компаній зі списку Fortune 500, а корпоративний ARR зріс у 10 разів рік до року (офіційний пост Еріка Саймонса в LinkedIn). У січні 2025-го StackBlitz залучив $105,5 млн у раунді B за оцінки близько $700 млн (за даними Business Insider та інших видань). Типовий сценарій використання — невеликий застосунок або лендінг, який одразу можна відкрити й подивитися, як він працює.

Lovable (Стокгольм, Швеція; засновник — Anton Osika; проєкт виріс із відкритого GPT Engineer). Їхній підхід — «від одного речення до повноцінного застосунку, готового до деплою», тобто вони позиціонуються ближче до повноцінних бізнес-застосунків, ніж Bolt. У листопаді 2025-го закрили раунд A на $200M з оцінкою $1.8B, а вже наприкінці грудня 2025-го — раунд B на $330M з оцінкою $6.6B: за пів року вартість зросла майже вчетверо. У червні 2026-го ARR перевищив $500M (про це повідомили Forbes 2026-06-05 та TechCrunch того ж дня). Тоді ж Forbes, посилаючись на чотирьох обізнаних співрозмовників, написав, що компанія веде новий раунд за оцінки близько $12B (тобто майже подвоєння; Forbes / Rashi Shrivastava). Серед корпоративних клієнтів Lovable — Workday, Asana, NVIDIA (зведені дані ARR.club, 2026).

Vercel v0. Випущений у жовтні 2023 року, 3 лютого 2026-го офіційно змінив назву з v0.dev на v0.app — еволюціонував із генератора UI-компонентів у повноцінний генератор full-stack застосунків (sandbox runtime + інтеграція з GitHub + підключення до Snowflake/AWS баз даних). Станом на березень 2026 року Vercel заявляє про понад 6 мільйонів розробників і близько 80 тисяч активних команд щомісяця (аналітики конкурентів оцінюють ARR приблизно в $42M, зведені дані Taskade, березень 2026).

Replit Agent 4. Випущений 13 березня 2026 року — найважливіше оновлення в історії Replit. Змінилися одразу три речі: ① Design Mode еволюціонував у Infinite Design Canvas — тепер можна проєктувати інтерфейс і одразу ж редагувати код; ② колаборація перейшла з моделі fork-and-merge на «спільний проєкт із багатопотоковими завданнями» — кілька sub-agent виконують роботу паралельно, а фінальне об’єднання автоматично виконує окремий агент із вирішення конфліктів. Офіційні дані: Agent 4 автоматично розв’язує 90% конфліктів злиття (звіт AlphaSignal 2026, підтверджено офіційним changelog Replit за березень 2026). ③ Планування та виконання більше не послідовні — можна планувати й виконувати одночасно. Тоді ж Replit залучив раунд D, оцінивши компанію майже в $9 млрд (звіт Atal Upadhyay 2026; підтверджено TechCrunch/Bloomberg). Replit починав як онлайн-середовище для програмування, тому колаборація та хостинг у нього «в крові». Agent 4 стиснув процес «кілька людей разом будують продукт» до швидкості, майже як у індивідуальної роботи.

Спільне для всіх чотирьох: вартість створення застосунку падає з «команда × місяці» до «одна людина × години».

Trae заслуговує окремого розгляду, оскільки для корпоративних клієнтів у телекомі, фінансах та електронній комерції він становить конкретний постачальницький ризик. Формально Trae — це IDE (редактор коду), але по суті це середовище розробки, жорстко прив’язане до серверів ByteDance. Для підприємств його не можна розглядати як «звичайний IDE» — до нього слід застосовувати процедуру допуску як до інструменту передачі даних за межі країни. ByteDance запустив Trae у січні 2025 року як прямого конкурента Cursor, обравши стратегію безкоштовного доступу до преміальних моделей на кшталт Claude та GPT-4o. За 12 місяців продукт залучив 6 мільйонів зареєстрованих користувачів, 1,6 мільйона активних користувачів на місяць і сумарно згенерував близько 100 мільярдів рядків коду (зведені дані OpenAI Tools Hub, травень 2026). Однак у липні 2025 року дослідник із безпеки під псевдонімом segmentationf4u1t опублікував проєкт telemetry_research, який довів: навіть якщо вимкнути телеметрію в налаштуваннях, Trae продовжує у фоновому режимі передавати дані на сервери ByteDance, зокрема mon-va.byteoversea.com — апаратну інформацію, версію операційної системи, постійні ідентифікатори пристрою та машини, а також дані про активність у проєктах. Один пакет телеметрії може сягати 53 606 байт; приблизно за 7 хвилин звичайного використання фіксується понад 500 викликів і близько 26 МБ переданих даних (первинні дані з GitHub segmentationf4u1t/trae_telemetry_research; висвітлено The Register та Cybernews 28 липня 2025 року).

Відповідь ByteDance на подальші запитання варта уваги. У оновленні від 2026-08-01 Cybernews пише: офіційна заява ByteDance визнає, що перемикач телеметрії в налаштуваннях IDE контролює лише телеметрію VS Code-фреймворку, а збір даних інших інструментів Trae цей перемикач не регулює — якщо простою мовою: ви думаєте, що вимкнули, а насправді — ні. Після прямого звернення дослідників до команди Trae підтвердили, що окремий Privacy Mode заплановано до випуску приблизно на серпень 2026 року. Водночас запроваджена в лютому 2026 року “token-based paywall” у Trae порушила обіцянку “forever free”, змусивши багатьох розробників, які використовували цей інструмент у продакшені, переглянути свої рішення (зведені дані дослідження OpenAI Tools Hub, травень 2026).

Для індивідуальних розробників безкоштовний Claude — це справді приємний бонус. Але для вас як для особи, що ухвалює рішення, це класична проблема транскордонної передачі даних: ваші інженери завантажують код компанії, а можливо, і конфігурації, та інтерфейси, в інструмент, який передає дані на сервери ByteDance. В Україні такі дії перевіряються за статтею 29 Закону «Про захист персональних даних» (підстави транскордонної передачі, включаючи угоду про обмін даними з гарантіями належного захисту) та за статтею 9 Закону «Про основні засади забезпечення кібербезпеки України» (обов’язки операторів критичної інфраструктури). У «ПриватБанку» чи «Київстарі» такий крок сам по собі вже може стати підставою для аудиту НБУ чи Держспецзв’язку. Детальніше це питання розглядається в четвертому розділі.

2. Розробку переписано: від «написання коду» до «ревʼю, оркестрації та контролю»

Генератори застосунків найчастіше сприймають неправильно — мовляв, «тепер інженери більше не потрібні». Це хибний напрямок.

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

Ці три речі є дефіцитнішими й дорожчими, ніж «написання коду». Людей, які можуть написати React-компонент, — повно. А от тих, хто здатен оцінити, чи можна випускати в прод згенерований ШІ промо-застосунок, який працює з даними замовлень, чи не є його автентифікація бутафорською, чи не надсилає він логи на закордонні сервіси, — значно менше.

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

Ця схема передає лише одну думку: горизонтальна вісь показує, наскільки складною є логіка застосунку, вертикальна — чи працює він із грошима та персональними даними. Клітинка в нижньому правому куті (висока складність плюс висока чутливість) — туди App-генератор не допускається, хоч би яким розумним він був. Лендінг для промо-акції можна довірити Lovable — без питань. А от ваш платіжний шлюз — це лише питання часу, коли станеться інцидент.

Закарбуйте цю червону лінію — і тоді подивіться на те, що відбувається в електронній комерції.

3. Справжній біль електронної комерції: тіньові застосунки дісталися до даних замовлень

Відійдемо трохи назад і подивимось на цифру, яку Gartner оприлюднив у другій половині 2025 року: до кінця 2026 року 40% корпоративних застосунків матимуть вбудовані спеціалізовані AI-агенти, тоді як у 2025 році цей показник не сягав і 5% (офіційний прогноз Gartner, також опублікований Process Excellence Network 2025-08-27). Поруч із цим — ще промовистіші цифри: Gartner повідомляє, що з Q1 2024 по Q2 2025 кількість запитів від підприємств щодо мультиагентних систем зросла на 1445% — це найшвидше зростаюча тема в консалтинговому напрямку Gartner AI advisory, без жодних застережень (за даними RAPIDCLAW, Hendricks.ai та Arion Research).

Перекладу ці два ряди чисел мовою електронної комерції: у 40% корпоративних застосунків працюватимуть AI-агенти, і в парі з ними — ще один показник: кількість консультацій щодо корпоративних мультиагентних систем зросла на +1445% (це динаміка зростання консалтингових звернень до Gartner AI advisory, а не показник впровадження, але сигнал напрямку вже чіткий): AI-агенти перейшли від «допомоги в написанні коду» до «кількох агентів, які співпрацюють і виконують цілий бізнес-процес». Коли AI-агенти починають працювати в корпоративних застосунках — торкаються даних, виконують процеси, пишуть логи, — генератори застосунків перестають бути просто «інструментом» і стають «системою».

Дослідницька компанія UpGuard у своєму звіті за 2025 рік («State of Shadow AI», про який писало Cybersecurity Dive) наводить дві цифри, які вражають більше, ніж гартнерівські 40%: понад 80% працівників використовують на роботі несанкціоновані AI-інструменти, і навіть серед самих фахівців з безпеки таких майже 90%. І ще один показник: близько половини співробітників зізнаються, що вставляли конфіденційні корпоративні дані прямо в ці несанкціоновані інструменти. Mimecast дає цифру 51%, Teramind — 49%, тобто оцінки збігаються. Gartner, своєю чергою, повідомляє: 69% організацій підозрюють або підтверджують, що працівники користуються забороненими AI-інструментами, і лише 37% мають формальні правила використання AI (за даними The Hacker News).

Тепер перекладімо ці цифри мовою електронної комерції: ваші операційники, маркетологи та фахівці з акцій уже самотужки збирають застосунки за допомогою інструментів на кшталт Bolt, Lovable чи v0. Конфігуратор правил акцій, дашборд для відбору товарів у амбасадорів, мінізастосунок для перевірки залишків на складі, інструмент для обробки звернень у підтримці. Вони швидкі, зручні й вирішують реальні проблеми. І вони майже повністю обходять IT-відділ та політики керування даними.

Реальний сценарій із нашої практики (електронна комерція, дані знеособлено): починаючи з другої половини 2025 року, під час аудиту «тіньових» ІТ-систем у 4 українських e-commerce компаніях (платформи 50–200 осіб, зокрема ритейлери побутової техніки, одягу та товарів для дому — типовий представник — Rozetka або Allo) ми не знайшли жодної, де все було б чисто. Найпоказовіший випадок — український ритейлер товарів для дому: за два місяці команда, яка вела блогерів, самостійно створила 7 внутрішніх інструментів на Lovable, 4 з яких працювали з широкими таблицями замовлень (з номерами телефонів і адресами доставки), а 2 експортували дані в особисті хмарні сховища Google Drive. У день аудиту керівник із безпеки сказав: «Ми тоді мало не зупинили перевірку — боялися, що знайдене ніхто не зможе “перетравити” на рівні керівництва». Якби про це стало відомо Держспецзв’язку або Уповноваженому з прав людини, наслідки були б значно серйознішими за внутрішній дискомфорт.

Таку ситуацію можна назвати «тіньовими ІТ у сфері даних». Останні десять років нас турбували тіньові ІТ у вигляді SaaS, які бізнес-підрозділи купували самі (відділ продажів брав CRM, маркетинг — інструмент для розсилок). Теперішні тіньові ІТ — це застосунки, які бізнес-підрозділи створюють самі. Вони використовують несанкціонований інструмент — і, що гірше, створюють нову систему, яка працює з чутливими даними і при цьому не внесена до ІТ-реєстру активів.

Різниця — у масштабі: купити SaaS означає підключити зовнішню систему; створювати застосунки за допомогою генератора — це коли всередині вашої компанії з нічого виростає купа нових систем, кожна з власним API і кожна потенційно доступна з інтернету. За рік e-commerce-компанія може обрости сотнею таких застосунків, і жоден із них не буде в ІТ-реєстрі.

Це не зупинити. Ті 80% від UpGuard уже показують: забороною цього не вирішити. Люди знайдуть найзручніший інструмент, щоб зробити роботу, — це людська природа, це KPI. Тож питання не в тому, «як не дати бізнес-підрозділам користуватися генераторами», а в тому, «як зробити це користування безпечним». У розділі 4 — про регуляторні бар’єри, у розділі 5 — про те, як прокласти безпечний шлях.

4. Регуляторні бар’єри: це не тест

Це найважливіший розділ цієї статті — і найлегше написати його неправильно.

Багато хто з досвідом роботи в інтернет-компаніях, коли чує «контроль якості», одразу уявляє автоматизоване тестування в CI/CD: юніт-тести, інтеграційні, регресійні — зелені галки, і можна випускати. Для техкоманд, які роблять великі розпродажі в електронній комерції, це звична справа.

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

Розглянемо кожен етап окремо.

Оцінка передачі даних за кордон.[^1] Якщо ваш застосунок використовує закордонні AI-сервіси (багато генераторів працюють на бекенді OpenAI, Anthropic), або ваші інженери користуються IDE на кшталт Trae, які передають дані за межі країни, — щойно в даних з’являється персональна інформація, спрацьовують вимоги щодо транскордонної передачі згідно зі статтею 29 Закону України «Про захист персональних даних» (підстави транскордонної передачі, включаючи угоду з країною-імпортером, де гарантовано належний захист, або письмову згоду суб’єкта). Для операторів критичної інфраструктури додатково працює стаття 9 Закону «Про основні засади забезпечення кібербезпеки України». Повноцінна процедура оцінки безпеки передачі даних за кордон займає від одного-двох місяців у найкращому випадку до пів року і більше. Випадок із Trae, коли телеметрія передавалася навіть після її вимкнення, означає: навіть якщо вам здається, що передачі немає, вона відбувається. У «ПриватБанку» чи «Київстарі» з їх регулярною звітністю до НБУ як головного регулятора, таким інструментам взагалі не місце в розробницькому середовищі.

Атестація за рівнем захисту.[^2] В Україні роль КСЗІ (Комплексна система захисту інформації) виконує атестація за стандартами Держспецзв’язку (Державна служба спеціального зв’язку та захисту інформації). Публічний застосунок, що обробляє персональні дані, з високою ймовірністю потрапить під другий чи третій рівень захисту. Визначення рівня, реєстрація, усунення недоліків, атестація — повний цикл зазвичай триває від трьох до шести місяців. Це законодавча вимога, а не опція. Той факт, що застосунок створено за допомогою AI, не звільняє вас від атестації.

Реєстрація алгоритму.[^3] Якщо ваш застосунок орієнтований на широку аудиторію та використовує генеративний AI (наприклад, автоматичне створення описів товарів, автоматичні відповіді в підтримці, персоналізовані рекомендації з AI-контентом), в Україні це регулюється через повідомлення/реєстрацію в Держспецзв’язку та програмні вимоги до ШІ-систем. Станом на 2026 рік Верховна Рада перебуває на етапі ухвалення профільного закону про штучний інтелект (за європейським AI Act як зразком), але наявні вимоги до автоматизованого прийняття рішень за статтею 11 Закону «Про захист персональних даних» уже зараз забороняють рішення, що істотно впливають на суб’єкта, лише на основі автоматизованої обробки без його згоди. Для банків додатково діють вимоги НБУ щодо пояснюваності моделей у кредитному скорингу та антифроді. Запуск без урахування цих вимог — порушення комплаєнсу.

Затвердження змін (CAB) і план відкату.[^4] У фінансовому та телеком-секторі виведення в прод однієї критичної системи проходить через погодження в Change Advisory Board: оцінка впливу, план відкату, підтвердження вікна змін. В українських банках цей процес обов’язковий за вимогами НБУ до управління ІТ-змінами (Положення про інформаційні технології в банках, постанова № 95 від 2018 року); в операторів мобільного зв’язку на кшталт «Київстар» — за внутрішніми політиками, узгодженими з Держспецзв’язку. Цей етап з’їдає календарний час, а не машинний — не встигли у вікно, чекаєте наступного тижня.

Звірка та аудит.[^5] Після запуску e-commerce розпродажів або фінансових розрахунків обов’язкова звірка з платіжними системами та контрагентами, а також аудиторські логи для відстеження кожної транзакції. В Україні для банків діють вимоги НБУ щодо зберігання фінансових документів та журналів аудиту (зазвичай ≥ 5 років для платіжних операцій); для публічних сервісів — типово ≥ 6 місяців мережевих журналів за стандартами Держспецзв’язку. Саме тут AI-генеровані застосунки часто «голі»: вони працюють, але не мають вбудованої звірки — і за будь-якої розбіжності в обліку слідів не знайти.

Зібравши це докупи, бачимо контрінтуїтивний висновок: генератори застосунків прискорюють шлях від «ідеї» до «робочого прототипу» на порядок, але від «робочого прототипу» до «комплаєнс-релізу» час не скорочують взагалі. Скільки займали ці етапи раніше — стільки ж займають і зараз.

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

5. Дайте бізнесу легальний шлях для комплаєнсу, а не змушуйте діяти в обхід

Якщо заблокувати не виходить — дайте канал. Це один із небагатьох робочих підходів до впорядкування shadow IT.

Як саме збудувати цей канал — чотири кроки.

Крок перший: компанія сама надає генератор, що пройшов оцінку безпеки. Замість того щоб дозволяти операційним командам користуватися будь-яким зовнішнім інструментом на кшталт Lovable, компанія купує або створює власну версію, яка відповідає вимогам КСЗІ Держспецзв’язку (аналог китайського MLPS 2.0 / 等保 — стандарт багаторівневого захисту інформаційних систем) і гарантує, що дані не залишають периметр. Для банків додатково — вимоги НБУ до внутрішнього контролю та операційної стійкості. Для цього створюється внутрішній вхід. Якщо бізнес-підрозділам зручно працювати з цим інструментом, вони не шукатимуть альтернативи назовні — це стратегія «спрямування» замість простої «заборони». Реальні зразки вже є: «ПриватБанк» і monobank розгорнули власні внутрішні LLM-асистенти з обов’язковим підключенням до корпоративного ID, аудиту й моніторингу. Менш відомий приклад — національна інфраструктура взаємодії «Дія», де держава сама керує інтерфейсом та рівнем допустимих даних для кожного типу послуг.

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

Крок третій: маршрутизація за рівнем чутливості даних. Використовуйте матрицю з другого розділу. Застосунки, що працюють лише зі знеособленими або тестовими даними, проходять автоматично. Щойно з’являється запит на доступ до реальних замовлень чи персональних даних — автоматично запускається процедура попередньої оцінки транскордонної передачі даних та оцінки відповідності вимогам захисту інформації (в Україні — КСЗІ Держспецзв’язку, у Китаї — атестація MLPS / 等保). Процес має залежати від чутливості даних, а не застосовувати один шаблон до всіх застосунків.

Крок четвертий: автоматичне сканування безпеки. У застосунках, згенерованих ШІ, рівень вразливостей значно вищий, ніж у коді, написаному людиною. У звіті CodeRabbit за 2026 рік цю цифру оновлено: кількість проблем (включно з логічними помилками та багами коректності) у коді, створеному за допомогою ШІ, у 1,7 раза вища, ніж у традиційному коді, написаному вручну (методологія CodeRabbit, враховує комерційну позицію; узгоджується з вебінаром DORA 2026-02 та горизонтальним порівнянням Kunal Ganglani 2026). Звіт Veracode 2025 про безпеку GenAI-коду ще прямолінійніший: у протестованій вибірці близько 45% згенерованого ШІ-коду містило вразливості рівня OWASP Top 10 (для Java-коду рівень невдач перевищує 70%; методологія Veracode, враховує комерційну позицію). Академічне масштабне емпіричне дослідження публічних репозиторіїв GitHub (arXiv:2510.26103) підтверджує той самий напрямок. Тож для ШІ-згенерованих застосунків цей крок — обов’язковий, а не опційний. Інтегруйте SAST, сканування залежностей і перевірку секретів у пайплайн випуску генератора: тільки якщо всі перевірки зелені — дозволяйте реліз. У червні 2026 року було публічно підтверджено, що CodeRabbit — найбільш встановлюваний інструмент AI-рев’ю коду на GitHub/GitLab: понад 15 000 платних клієнтів, перевірено 6 мільйонів репозиторіїв, а генеральний директор NVIDIA Дженсен Хуанг публічно заявив: «Вся NVIDIA користується CodeRabbit». Тож цілком розумно розглядати його як базовий орієнтир для корпоративного контролю якості ШІ-коду.

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

Тут варто окремо прояснити одну цифру, яку часто перекручують. У попередніх версіях тексту з’являлося «45% рівень впровадження shadow AI» — це помилкове приписування. 45% — це частка дефектів у коді, згенерованому ШІ, за звітом Veracode, а не рівень впровадження інструментів. Для shadow AI показник впровадження — це 80%+ з даних UpGuard. Це два різні показники, які описують зовсім різні речі. Не плутайте.

6. Коли не варто використовувати генератори застосунків

Це не срібна куля. Є чотири типові сценарії неправильного використання, і кожен із них ми бачили в наших клієнтів.

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

Код, згенерований ШІ, за замовчуванням вважається безпечним. Відповідь на це вже дали показники CodeRabbit (1.7×) та Veracode (45%). Між тим, що застосунок, згенерований ШІ, «виглядає так, ніби працює», і тим, що він «працює безпечно», лежить цілий інженерний пласт із забезпечення безпеки. Ставитися до ШІ-генерованих застосунків інакше, ніж до написаних людиною, і занижувати для них стандарти безпеки — означає пришвидшеними темпами плодити дедалі більше вразливостей.

Використання закордонних генераторів для обробки персональних даних без оцінки транскордонної передачі. Це особливо непомітно в електронній комерції: для маркетингової кампанії роблять сторінку для користувачів, на бекенді викликають OpenAI для генерації тексту, і номер телефону, який залишив користувач, попутно опиняється на закордонному сервісі. Так перетинають червону лінію статті 29 Закону України «Про захист персональних даних» (транскордонна передача) — і паралельно Закону КНР «Про захист персональної інформації» (PIPL). Якщо щось піде не так — це вже інцидент із даними, а не технічний баг.

Встановлення всім інженерам компанії IDE з передачею даних за кордон, як-от Trae, за замовчуванням. Спокуса безкоштовних потужних моделей велика, тож інженери встановлюватимуть їх самі. Щойно ваш основний код, конфігурації чи інтерфейси опиняться на серверах ByteDance (або будь-якого іншого закордонного суб’єкта), виправляти щось буде запізно. Такі інструменти мають проходити оцінку допуску разом із відділами безпеки та юридичним, а не бути одноосібним рішенням технічної команди.

7. Погляд крізь призму чотирьох галузей: що можна довірити ШІ, а що — категорично ні

Цей розділ зосереджений на 4 галузях, де ми супроводжували компанії крізь реальні проблеми (електронна комерція / фінанси / телеком / виробництво). Сценарії з жорстким регулюванням, як-от державний сектор чи охорона здоров’я, розглянемо окремо в іншій статті.

Перемкнімо фокус на чотири галузі — для кожної наведемо реальний сценарій, який ми спостерігали на практиці.

Електронна комерція. Найчастіше “вибухають” такі інструменти, як “конфігуратор акційних правил”, “дашборд для відбору товарів амбасадорами” та “мінізастосунок для перевірки залишків” — вони виглядають як звичайні утиліти, але насправді читають широкі таблиці замовлень із номерами телефонів та адресами. В Україні це торкається статті 11 Закону «Про захист персональних даних» (обмеження доступу) і статті 6 (згода). Такі застосунки обов’язково мають проходити реєстрацію через санкціонований канал із п’ятого розділу, а доступ до реальних даних автоматично запускає процедуру оцінки КСЗІ (аналог китайської атестації MLPS / 等保) та оцінку трансферу даних за кордон. Типовий український приклад — Rozetka, Allo, Prom.ua, де внутрішні інструменти маркетингу та блогерських програм регулярно працюють із замовленнями. Ми на власні очі бачили, як операційна команда одного українського e-commerce гравця за два місяці створила сім внутрішніх інструментів, і чотири з них читали таблиці замовлень — це не поодинокий випадок.

Фінанси. Червона лінія — це “торговельні системи / платежі / кліринг і розрахунки / ризик-менеджмент / антифрод / регуляторна звітність”. Генеративні інструменти доречно використовувати для робочого місця клієнтського менеджера, конфігуратора маркетингових кампаній та фронтенду звірки рахунків. Категорично не можна застосовувати їх для побудови ризик-движка чи антифрод-правил — той самий коефіцієнт логічних багів CodeRabbit (1,7× за власною методологією CodeRabbit, з урахуванням комерційної позиції) у фінансовому контексті означає зростання ризику для грошових потоків. Компанію в кейсі знеособлено: один український банк з числа системно важливих (на кшталт «ПриватБанку» чи «Укрексімбанку» — типовий представник) наприкінці 2025 року почав використовувати AI-програмування для допоміжної генерації регуляторної звітності, і в скриптах для подання до НБУ виявили три розбіжності в маппінгу полів — банк викликали на розмову. Одна з кореневих причин — AI-згенерований код, який “виглядає правильним”, ніхто не перевірив.

Телеком / оператори. У «Київстар» (найбільший український мобільний оператор, типовий представник), з яким ми консультувалися, маркетинговий відділ регіональної філії самотужки зібрав на Bolt «швидкий пошук за профілем клієнта»: вводиш номер телефону — і отримуєш історію тарифів, скарг і рекомендацій за останні 90 днів. Це пряме порушення меж доступу до даних, визначених статтею 11 Закону України «Про захист персональних даних» (обмеження доступу третіх осіб) та статтею 6 (згода та мета обробки). У телеком-сценаріях генеративні інструменти можна використовувати для «робочого місця менеджера з клієнтів», «фронт-енду бази знань для підтримки» чи «конфігуратора маркетингових акцій» — але не для білінгу, формування рахунків або перегляду деталізації дзвінків. Це критичні системи оператора: одна помилка — і це не тільки новини, а й розслідування НКРЗІ (Національна комісія, що здійснює державне регулювання у сферах електронних комунікацій).

Виробництво. MES/ERP-інтеграція, контроль якості та подання звітності — це ядро системи, і генератори коду можуть працювати лише на периферії: цехові дашборди, довідники технологічних маршрутів, демо-версії OEE-аналітики обладнання. Категорично не можна чіпати: алгоритми виробничого планування, правила ухвалення рішень щодо якості, інтерфейси звірки з ERP вищого рівня. Приклад анонімізовано: один постачальник автокомпонентів (у відкритих джерелах можна знайти кілька схожих випадків відкликання продукції; деталі кейсу зібрано з публічних повідомлень про відкликання та проєктів, у яких брав участь автор, — щоб проілюструвати логіку рішень, а не вказати на конкретну компанію) доручив IT-відділу зібрати на Bolt «дашборд для AI-контролю якості». Задум був простий: показувати фото зразків і результати класифікації. Але під час рендерингу на фронтенді порогове значення впевненості моделі зашили прямо в клієнтський код. Хтось із операторів випадково змінив 0.85 на 0.6 — і за три дні понад 200 деталей, які мали піти у брак, позначили як придатні й відправили на наступну ділянку. Усе закінчилося відкликанням трьох партій. Типова помилка середнього виробничого підприємства — віддавати генератору навіть «фронтенд для AI-контролю якості». Бо наслідок помилки тут — відкликання продукції. І це вже не просто технічний баг, а публічний репутаційний ризик.

8. Що це означає для керівників

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

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

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

Урок четвертий: змініть метрику, інакше весь бюджет піде на інструменти, а вузьке місце так і не зникне. Це порада для перших осіб. Зараз багато рад директорів оцінюють успішність AI-трансформації за кількістю придбаних ліцензій на AI-інструменти або відсотком прискорення розробки. Наслідок такої системи оцінки простий: бюджет іде на закупівлю інструментів, а ті ланки, які реально стримують постачання (відділ оцінки транскордонної передачі даних, відділ відповідності вимогам безпеки, інженери з безпеки, звірка та аудит), залишаються без фінансування і без людей. У результаті — купа інструментів, а швидкість постачання не зростає. Щоб вилікувати хворобу «знаю, але не можу зрушити з місця», треба змінювати метрику нагорі. Додайте такі показники: «яка частка застосунків покрита відповідністю вимогам», «кількість тіньових застосунків знизилася з N до M», «цикл від прототипу до відповідного запуску для ключових застосунків». Змініть метрику — і бюджет потече туди, де реально стоїть проблема.

Зворотна самоперевірка (не прикрашайте відповіді): Скільки застосунків, створених бізнес-підрозділами самостійно за допомогою AI, зараз працює у вашій компанії — ви можете назвати точну цифру? Скільки з цих застосунків торкаються замовлень, номерів телефонів, адрес? Куди передає дані той AI-IDE, який ви за замовчуванням встановили інженерам, — ви перевіряли? Ті кілька показників, якими ви міряєте ефективність AI, — вони заохочують «купівлю інструментів» чи «прискорення постачання»? Якщо хоча б на одне з чотирьох питань ви відповіли невпевнено — то ризики, про які йдеться в цій статті, вже сталися у вашій компанії.

Наступний крок

Це п’ята стаття з серії з 18 матеріалів про трансформацію інженерії програмного забезпечення в епоху ШІ. Ми вже побачили, як генератори застосунків та AI-IDE знижують поріг входу для створення застосунку, і чому поріг для роботи з даними не знижується так само.

У наступній статті (№6) розглянемо протилежний напрямок, який стає галузевим консенсусом: Spec-Driven Development (розробка, керована специфікаціями). Чому GitHub Spec Kit, Claude Code, AWS Kiro та AGENTS.md від OpenAI незалежно один від одного прийшли до підходу «спочатку зафіксуй вимоги в документації, потім дай AI діяти». У попередньому розділі ми говорили, що рівень вразливостей у коді, згенерованому AI, вищий, ніж у коді, написаному людиною; специфікації — один зі способів лікування цієї проблеми: перетворюючи розмиті усні вимоги на перевірювані специфікації, ми даємо AI можливість бути контрольованим.

---

Про серію: Ця серія відстежує останні зміни в AI-інструментах для програмування, організаційних структурах і парадигмах програмної інженерії. Підписуйтеся, щоб отримувати оновлені інсайти.

---

Хочете застосувати ці висновки у вашій компанії?

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

Наразі ми пропонуємо три формати співпраці:

• Корпоративне навчання: на основі реальних проєктів вашої компанії — вибір генератора застосунків, визначення меж використання, комплаєнс-процедури та проєктування механізмів governance.
• Цільові консультації: зосереджені на конкретному рішенні, наприклад, «чи надавати бізнес-підрозділам доступ до санкціонованого генератора застосунків» або визначення пріоритетів виправлення після інвентаризації тіньових застосунків.
• Виступи для керівництва та галузеві доповіді: на теми AI-інструментів програмування, управління тіньовими застосунками, AI-трансформації підприємств та організаційного governance.

Стаття пропонує універсальну рамку. Конкретне впровадження все одно потребує перепроєктування з урахуванням меж даних підприємства, регуляторних вимог, інженерної зрілості та наявних процесів доставки. Співпраця — через coach@iaiuse.com.

Рекомендоване читання: «Методологія “Вивіска” v1.0» (повільне навчання AI 187) — системний огляд 7-крокової рамки AI-трансформації підприємства.

---

Про цю серію

«Трансформація інженерії програмного забезпечення в епоху AI» — це дослідницька серія для CIO, CDO, CTO та керівників цифрової трансформації в телекомунікаціях, фінансах, виробництві та електронній комерції. Серія налічує 18 статей і зосереджена на тому, як AI-інструменти програмування, генератори застосунків та управління тіньовими застосунками впливають на процеси доставки програмного забезпечення, організаційну структуру, механізми governance та управлінські метрики.

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

Я маю майже 8 років досвіду в консалтингу для великих підприємств і бізнес-аналітиці. Працював в IBM, брав участь у проєктах для телекомунікаційної, фінансової, страхової та виробничої галузей. Згодом перейшов у продуктову розробку — спершу в операторські продукти, потім в інтернет-продукти, а тепер у розробку AI-застосунків, де займаюся аналізом вимог, продуктовим дизайном і впровадженням рішень між командами.

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

За цим блогом стоїть невелика команда — я та 1–2 колеги, з якими ми давно працюємо разом. Ми розподілили між собою дослідження AI-інструментів для програмування, аналіз кейсів організаційного врядування та коучингові діалоги. Більшість проєктів, де «ми супроводжували компанії», — це спільна робота нашої команди. Ми й надалі не називаємо клієнтів і не розкриваємо деталей, що стосуються комплаєнс-меж, — анонімність зберігає простір для майбутньої співпраці з колегами.

---

Джерела (усі перевірені, із зазначенням рівня доказовості та позиції)

• StackBlitz CEO Ерік Саймонс (LinkedIn, підсумки 2026 фінансового року). Bolt.new використовують три чверті компаній зі списку Fortune 500, а корпоративний ARR зріс у 10 разів порівняно з минулим роком. Пряма заява від самої компанії (позиція вендора). https://www.linkedin.com/posts/eric-simons-a464a664-a_growth-update-as-we-close-out-our-fiscal-activity-7425263313049026560-5tdV

• Sacra / Growth Unhinged (2025). Відстеження зростання ARR для Bolt.new (приблизно 5 місяців до $40 млн ARR, близько 5 млн користувачів, друге за швидкістю зростання в історії після ChatGPT). Первинне дослідження / моніторинг. https://sacra.com/c/bolt-new/ , https://www.growthunhinged.com/p/boltnew-growth-journey

• Taskade (2026-03) / Business Insider. StackBlitz у січні 2025-го залучив $105,5 млн у раунді серії B за оцінки близько $700 млн; Bolt V2 вийшов із Bolt Cloud. Зведення галузевих звітів.

• Forbes / Rashi Shrivastava (2026-06-05). Lovable веде переговори про новий раунд фінансування за оцінки $12 млрд; ARR перевищив $500 млн (підтверджено TechCrunch 2026-06-09). Першоджерело галузевої інформації. https://www.forbes.com/sites/rashishrivastava/2026/06/05/ai-coding-startup-lovable-in-talks-to-raise-funding-at-a-12-billion-valuation

• CNBC / Bloomberg (2025-12) / TechCrunch (2025-11). Lovable: серія B — $330 млн за оцінки $6,6 млрд, серія A — $200 млн за оцінки $1,8 млрд. Галузеві звіти.

• ARR.club (2026-07). Крива зростання ARR у Lovable: $17M (2025-02) → $100M (2025-07) → $200M (2025-11) → $400M (2026-02) → $500M (2026-06); серед корпоративних клієнтів — Workday, Asana, NVIDIA. Галузевий моніторинг.

• Vercel (2026-02-03, офіційний блог “Introducing the new v0”). v0 перейменовано з v0.dev на v0.app — продукт еволюціонував із генератора UI-компонентів у повноцінний генератор full-stack застосунків (пісочниця runtime + GitHub + інтеграції з Snowflake/AWS). Офіційна позиція вендора. https://vercel.com/blog/introducing-the-new-v0

• Taskade (2026-03) / Vercel. Станом на березень 2026 року v0 має понад 6 млн користувачів, близько 80 тис. активних команд щомісяця, оціночний ARR — приблизно $42M. Комплексна галузева оцінка.

• Replit (2026-03-13 офіційний журнал змін + офіційний блог “What’s changed from Agent 3 to Agent 4”). Agent 4 випущено 2026-03-11; Infinite Design Canvas; співпрацю через fork-and-merge замінено на багатопотокові завдання в межах одного проєкту з автоматичним вирішенням конфліктів (90% вирішуються автоматично). Першоджерело від виробника. https://docs.replit.com/updates/2026/03/13/changelog

• AlphaSignal (2026). Детальний репортаж про те, як Replit Agent 4 автоматично вирішує 90% конфліктів злиття в командній роботі. Галузеве видання. https://alphasignal.ai/news/replit-s-agent-4-resolves-90-of-team-merge-conflicts-automatically

Atal Upadhyay (2026-03-19). Replit того ж тижня оголосив про раунд D на $400 млн з оцінкою $9 млрд (утричі більше за пів року). Зведення галузевих звітів. https://atalupadhyay.wordpress.com/2026/03/19/replit-agent-4-replit-just-changed-everything

• Cybernews (оновлено 01.08.2026) / The Register (28.07.2025) / segmentationf4u1t (першоджерело, GitHub). Trae навіть із вимкненою телеметрією продовжує передавати на сервери ByteDance дані про апаратне забезпечення, ідентифікатори пристроїв та активність у проєктах; обсяг одного пакета даних може сягати 53 606 байт; за 7 хвилин зафіксовано понад 500 викликів — приблизно 26 МБ даних. Представники ByteDance офіційно підтвердили, що перемикач у налаштуваннях контролює лише частину функціоналу, пов’язану з фреймворком VS Code. Режим Privacy Mode заплановано до випуску приблизно на серпень 2026 року. У лютому 2026 року Trae скасував умову «forever free» і перейшов на платну модель на основі токенів. Першокласне безпекове дослідження + галузеві звіти + офіційна заява виробника. https://cybernews.com/security/bytedance-ai-coding-tool-trae-data-collection 、https://www.theregister.com/software/2025/07/28/bytedance-ai-ide-trae-telemetry-continues-even-after-opt-out/ 、https://github.com/segmentationf4u1t/trae_telemetry_research

• OpenAI Tools Hub / Jim Liu (2026-05-18). Trae за 12 місяців зареєстрував 6 млн користувачів, 1,6 млн активних щомісяця, сумарно згенерував 100 млрд рядків коду; у лютому paywall на токени поклав край обіцянці «forever free». Комплексне дослідження (аналітична позиція).

• Gartner (цитується за Process Excellence Network, 2025-08-27 / DevOpsDigest / UC Today). До кінця 2026 року 40% корпоративних застосунків міститимуть вузькоспеціалізовані AI-агенти (у 2025-му — менш ніж 5%); до 2035 року agentic AI займатиме близько 30% ринку корпоративного ПЗ ($450 млрд). Офіційний прогнозний документ. https://www.processexcellencenetwork.com/ai/news/gartner-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026

• Gartner (цитовано за RapidClaw / Hendricks.ai / Arion Research, 2025–2026). З Q1 2024 по Q2 2025 кількість запитів від підприємств щодо мультиагентних систем зросла на 1445% — це найшвидше зростаюча тема в AI-консалтингу Gartner. Первинне дослідження / вторинне цитування.

• Microsoft (оглядовий пост за підсумками FY26, 2026-07-28). EY розгорнула Copilot для 150 000 співробітників, отримавши 15% приріст продуктивності, і масштабує рішення на 400 000 працівників по всьому світу; Atos впровадила Copilot для 56 000 співробітників у 54 країнах і керує 19 000 AI-агентами через єдину панель управління. Першоджерело від вендора + підтвердження клієнтів (позиція вендора та інтегратора). https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

• Atos Group (2026-06-09, офіційний прес-реліз). Atos розширює співпрацю з Microsoft, розгортаючи Copilot E7 (Frontier Suite) для 56 000 співробітників, уніфікуючи панель керування Entra/Defender/Intune/Purview/Agent 365 та експлуатуючи 19 000 агентів. Першоджерело — заява компанії. https://www.atosgroup.com/en/press/atos-group-and-microsoft-expand-strategic-collaboration-scale-secure-agentic-ai-across-atos

• UpGuard / Cybersecurity Dive (2025). Понад 80% працівників і майже 90% керівників з безпеки використовують несанкціоновані AI-інструменти; близько половини співробітників вставляли конфіденційні дані в ці інструменти (аналогічні звіти Mimecast і Teramind дають схожі цифри, що підтверджує висновки). Первинне дослідження + галузеві репортажі. https://www.cybersecuritydive.com/news/shadow-ai-employee-trust-upguard/805280/

• Gartner (цитовано The Hacker News, травень 2026). 69% організацій підозрюють або підтверджують, що працівники використовують заборонені AI-інструменти; лише 37% мають політику використання AI. Переказ галузевого звіту.

• CodeRabbit (спільний вебінар із DORA, лютий 2026 + горизонтальне оцінювання від Kunal Ganglani, червень 2026). Кількість проблем у коді, згенерованому за допомогою ШІ (включно з логічними помилками та багами коректності), приблизно в 1,7 раза вища, ніж у коді, написаному людиною традиційним способом. CodeRabbit — це найпоширеніший інструмент AI-ревʼю коду на GitHub/GitLab, який має понад 15 000 платних клієнтів і перевірив 6 мільйонів репозиторіїв. Його публічно підтримав генеральний директор NVIDIA Дженсен Хуанг. Первинне дослідження / дані від виробника / індустріальне оцінювання. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report

• Veracode (звіт про безпеку GenAI-коду, 2025). Близько 45% зразків AI-згенерованого коду містять уразливості з OWASP Top 10 (рівень невдач для Java-коду перевищує 70%). Первинне дослідження. https://www.veracode.com/blog/genai-code-security-report/ (примітка: у попередній версії ці «45%» помилково інтерпретували як рівень впровадження «тіньового ШІ» — це було неправильно; 45% — це частка дефектів у згенерованому ШІ коді, а не рівень впровадження інструментів; показник впровадження «тіньового ШІ» див. у звіті UpGuard — понад 80%).

• arXiv:2510.26103. Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories. (Емпіричне дослідження вразливостей безпеки в AI-згенерованому коді на основі великого масиву публічних GitHub-репозиторіїв.)

Примітка щодо даних: Усі кількісні показники в цьому матеріалі мають зазначені джерела. Окремі цифри, які вендори не оприлюднювали в первинній формі або які не були незалежно підтверджені (наприклад, $12 млрд нового раунду фінансування Lovable, що ще на стадії переговорів, або точний час інвентаризації 19 000 агентів Atos), були подані з обережністю. Клієнтські кейси деідентифіковані (операційна група українського e-commerce, маркетинговий відділ регіонального підрозділу оператора тощо); джерело — фактичні сценарії, які я спостерігав під час супроводу впроваджень, без прив’язки до конкретних компаній. Регуляторні вимоги (транскордонна передача даних, захист інформаційних систем, реєстрація алгоритмів) наведені згідно з чинним законодавством України та КНР; конкретне застосування залежить від бізнес-моделі та типів даних. Перед упровадженням обов’язково отримайте висновок юридичного/комплаєнс-відділу та, за потреби, консультацію з Держспецзв’язку чи НБУ.

[^1]: В Україні транскордонна передача персональних даних регулюється статтею 29 Закону «Про захист персональних даних» (умови передачі, зокрема: країна-імпортер забезпечує належний захист; укладено договір з гарантіями; суб’єкт дав згоду; необхідно для виконання договору). Для операторів критичної інфраструктури додатково застосовується стаття 9 Закону «Про основні засади забезпечення кібербезпеки України» та підзаконні акти Держспецзв’язку. Контекст КНР: стаття 31 Закону «Про безпеку даних» (оцінка безпеки передачі важливих даних за кордон); статті 38–43 Закону «Про захист персональної інформації» (умови передачі, типові контракти, шляхи сертифікації, інформування та згода). Супутні нормативні акти КНР: «Заходи з оцінки безпеки передачі даних за кордон» (чинні з 01.09.2022, наказ Державної інтернет-адміністрації КНР № 11), «Заходи щодо типових контрактів на передачу персональних даних за кордон» (чинні з 01.06.2023).
[^2]: В Україні функції атестації рівня захисту виконує Держспецзв’язку (Державна служба спеціального зв’язку та захисту інформації), яка затверджує нормативні документи з технічного захисту інформації (НД ТЗІ), зокрема НД ТЗІ 2.5-010-03 (вимоги до КСЗІ). Базою є Закон «Про захист інформації в інформаційно-телекомунікаційних системах» (1994, чинна редакція) та наказ Адміністрації Держспецзв’язку № 96 від 28.12.2017. Контекст КНР: стаття 21 Закону «Про кібербезпеку» (система багаторівневого захисту), національний стандарт GB/T 22239-2019 «Інформаційні технології безпеки — Базові вимоги до багаторівневого захисту кібербезпеки» (відомий як MLPS 2.0 / 等保 2.0); «Адміністративні заходи щодо управління багаторівневим захистом інформаційної безпеки» (спільний наказ Міністерства громадської безпеки та інших відомств № 43, 2007 р.) передбачають, що системи третього рівня проходять щорічну атестацію рівня захисту, а системи другого рівня — зазвичай раз на два роки.

[^3]: В Україні спеціального реєстру AI-алгоритмів поки немає, але працюють загальні вимоги: стаття 11 Закону «Про захист персональних даних» (заборона рішень, що істотно впливають на суб’єкта, лише на основі автоматизованої обробки без його згоди), стаття 7 Конвенції 108+ (Рекомендація Ради Європи щодо захисту осіб у зв’язку з автоматизованою обробкою персональних даних, ратифікована Україною), для банків — вимоги НБУ до пояснюваності моделей у кредитному скорингу та антифроді. Контекст КНР (для порівняння): ① Стаття 24 «Правил регулювання рекомендаційних алгоритмів у послугах інтернет-інформації» (чинні з 2022-03-01) — реєстрація рекомендаційних алгоритмів; ② Стаття 17 «Правил регулювання послуг глибокого синтезу в інтернет-інформації» (чинні з 2023-01-10) — реєстрація глибокого синтезу; ③ Стаття 17 «Тимчасових заходів щодо регулювання послуг генеративного штучного інтелекту» (чинні з 2023-08-15) — оцінка безпеки для публічних генеративних AI-сервісів, що формують громадську думку — це саме оцінка, а не реєстрація. Код, згенерований за допомогою App-генератора, сам по собі не обов’язково підпадає під ці три категорії, але якщо створений застосунок надає генеративні AI-послуги назовні або містить функції рекомендаційних алгоритмів чи глибокого синтезу, він обробляється згідно з відповідними положеннями.
[^4]: Загальну структуру управління змінами див. у ITIL 4 Change Enablement; в Україні для банків актуальним орієнтиром є «Положення про інформаційні технології в банках» (постанова Правління НБУ № 95 від 18.09.2018, зі змінами), вимоги до управління ІТ-змінами та операційною стійкістю за стандартами Базельського комітету, адаптованими НБУ; для операторів мобільного зв’язку — внутрішні політики, узгоджені з Держспецзв’язку. Контекст КНР: «Положення про нагляд за аутсорсингом ІТ-послуг у банківських і страхових установах» (Yin Bao Jian Fa 2021 № 46) та відповідні повідомлення Державного управління фінансового нагляду за 2024 рік; для страхової галузі додатково діють «Методичні вказівки з інформатизації страхових установ» (Bao Jian Fa 2009 № 17, редакція 2024 року).

[^5]: В Україні для банків — це вимоги НБУ до зберігання фінансових документів та журналів аудиту (зазвичай ≥ 5 років для платіжних операцій, згідно з «Положенням про інформаційні технології в банках»); для публічних сервісів — типово ≥ 6 місяців мережевих журналів за стандартами Держспецзв’язку (НД ТЗІ 2.5-010-03 та аналогічні). Контекст КНР: збереження записів про транзакції — стаття 31 Закону «Про електронну комерцію» (платформи зобов’язані фіксувати та зберігати інформацію про транзакції щонайменше 3 роки) + стаття 26 «Правил нагляду та управління онлайн-транзакціями» (уточнює період у 3 роки). Журнали аудиту: для систем третього рівня захисту згідно зі стандартом MLPS 2.0 (китайський стандарт багаторівневого захисту інформаційної безпеки) вимагається зберігання мережевих журналів не менше 6 місяців (відповідно до статті 21 Закону КНР «Про кібербезпеку»), однак для критичних систем фінансового сектору згідно зі статтею 19 «Керівних принципів управління даними банківських фінансових установ» та «Керівних принципів внутрішнього контролю комерційних банків» зазвичай вимагається не менше 5 років — 6 місяців це лише мінімальна межа, а не рекомендоване значення.