ШІ-проєкт застряг на старій системі? Спочатку оновлення, потім автоматизація

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

КОРОТКО

Чому ШІ-проєкти застрягають на старих системах

ШІ-проєкту потрібні від системи три речі: актуальні версії ПЗ, дані, доступні через API, і спосіб виконувати довгі завдання у фоні. У системи, написаної п’ять чи десять років тому, зазвичай немає жодної з трьох, тому пілот працює на демо і не доходить до бізнесу.

У квітні 2026 року Gartner повідомив, що 59% ШІ-ініціатив так і не потрапляють у продакшн, а 71% IT-директорів не можуть обрати ШІ-завдання з вимірюваним результатом для бізнесу. Аналітики, яких цитують поруч із цими цифрами, раз у раз називають одну перешкоду: застарілі технології. IT-директори почали говорити про модернізацію не як про підтримку, а як про інвестицію, без якої ШІ неможливий у принципі.

Ми бачимо те саме у своїй роботі. За останні місяці ми оновили з Laravel 7 до 13 один із наших проєктів, який не був у пріоритеті, сайт Інституту трихології та його інтернет-магазин до останнього OpenCart 3, сайти міжнародних медичних федерацій та інтернет-магазини, які зовні працювали добре, поки під ними накопичувався технічний борг. На оновлених системах ШІ-функції та інтеграції з CRM стали на місце і просто запрацювали. А для однієї великої системи на PHP 5.3 ми відмовили клієнта від оновлення і підписали договір на повну переробку.

ШІ не лагодить стару систему. Він показує, де вона закінчується.

ВЕРСІЇ

Інструменти не встановлюються на старий код

Найконкретніша перешкода для власника бізнесу і водночас найменш помітна. Пакети, через які розробники підключають сайт до ШІ-моделей, мають мінімальні вимоги, і вони зростають щороку.

Ось що вимагали основні пакети для PHP і Laravel у жовтні 2026 року, за даними Packagist:

Сайт на Laravel 7, 8, 9 або 10 не може встановити жоден пакет для Laravel із цієї таблиці. Сайт на PHP 7.4 не може встановити взагалі жоден. Команда може написати підключення до моделі вручну, але тоді підтримує цей код сама, без оновлень, виправлень безпеки і нових можливостей офіційних пакетів.

Календар підтримки додає тиску. Підтримка безпеки PHP 8.1 закінчилася 31 грудня 2025 року. PHP 8.2 втрачає підтримку безпеки 31 грудня 2026 року, через два місяці після виходу цієї статті. Laravel 11 перестав отримувати виправлення безпеки в березні 2026 року, Laravel 12 перестане в лютому 2027-го. Система на будь-якій із цих версій уже працює без патчів або скоро працюватиме, і це стає ще важливішим, коли ШІ-агент отримує доступ до її даних.

Якщо ШІ-пакет не встановлюється, ШІ-проєкт ще не почався.

ДАНІ

Модель бачить лише те, до чого може дотягнутися

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

Сучасна система віддає дані через API, і ШІ-функція запитує рівно те, що їй потрібно, і нічого зайвого. У старої API часто немає зовсім. Дані ходять між системами через вивантаження, нічні скрипти і ручне копіювання, а логіка бізнесу сидить в умовах, які ніхто не пам’ятає, як писав. Звідки береться така логіка, ми розповіли у статті Код пам’ятає всі версії бізнесу, а про таблицю, яка тихо керує компанією, у статті Кожна корпоративна система починалася з чиєїсь таблиці.

Підключити до цього ШІ можна, але кожне підключення стає ще однією милицею. Тоді ШІ відповідає за даними добової давності, неповними чи хибними, і ніхто цього не помічає, доки не помітить клієнт.

БЕЗПЕКА

Агент із доступом до системи без патчів

Чат-бот, який відповів невлад, це незручність. Агент, який може читати замовлення, змінювати записи чи надсилати листи в системі без патчів, це ризик. Старі версії PHP і фреймворків більше не отримують виправлень безпеки, і відомі вразливості в них лишаються відкритими назавжди.

Дати ШІ-агенту доступ до такої системи означає додати нового учасника з реальними правами на фундамент, який уже неможливо захистити. Який контроль потрібен агенту, від прав доступу до моніторингу, ми розібрали у статті Відповідність для агентного ШІ. Майже все звідти передбачає підтримуваний, актуальний стек.

ГОТОВНІСТЬ

Актуальний стек ще не означає готовність до ШІ

Оновлений стек знімає частину технічних обмежень, але сам по собі не робить систему готовою до безпечної роботи з ШІ. Перед запуском треба вирішити чотири речі:

• які дані й дії доступні моделі;
• які операції потребують підтвердження людини;
• як записуються запити і зміни;
• що відбувається, якщо модель помилилася або недоступна.

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

Крім версій PHP і фреймворку, для готовності до ШІ потрібні доступні дані, безпека, керовані інтеграції та контроль над тим, що ШІ може зробити.

ФОНОВІ ЗАВДАННЯ

ШІ думає секунди, стара система чекає

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

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

ПЕРЕВІРКА

Як перевірити свою систему за годину

Для першої відповіді аудит не потрібен. Поставте розробнику або тому, хто підтримує систему, шість запитань:

• Яка версія PHP працює на продакшні? Усе, що старше за 8.2, вже без підтримки безпеки або втратить її цього року.
• Який фреймворк і яка версія? Для Laravel усе, що старше за 12, не може використовувати власний ШІ-пакет Laravel.
• Коли востаннє оновлювалося ядро? Не плагін і не сторінка, а сам фреймворк.
• Чи має система API? Чи може інша система прочитати замовлення, клієнтів або товари без файлу вивантаження?
• Чи є черга для фонових завдань? Листи, імпорти і звіти, які виконуються, не змушуючи відвідувача чекати.
• Хто знає код? Якщо відповідь «одна людина» або «підрядник, який пішов», це перший ризик, і розбиратися з ним треба раніше за будь-який ШІ.

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

ОНОВИТИ ЧИ ПЕРЕПИСАТИ

Як ми вирішуємо

Більшості систем переписування не потрібне. Питання в тому, чи підходить структура бізнесу досі, чи застаріли лише версії.

Перед ШІ є і третій варіант: поки нічого не чіпати. Система не обов’язково має бути оновлена чи переписана, щоб почати з ШІ. Усе залежить від стану коду, доступу до даних, вимог безпеки і того, що компанія хоче отримати.

• Запускати ШІ-пілот зараз, якщо система працює на підтримуваному ПЗ, потрібні дані доступні через надійні інтерфейси, а завдання можна безпечно перевірити.
• Спершу модернізувати, якщо застарілі залежності, непідтримувані версії, відсутність API чи фонових завдань не дають зробити рішення надійним.
• Переписувати, якщо модель даних, інтеграції чи сама бізнес-логіка більше не відповідають тому, як працює компанія.

Модернізувати все до ШІ не обов’язково. Досить прибрати конкретні обмеження, які заважають першому ШІ-завданню дати вимірюваний результат.

Оновлення. Один із наших проєктів, який не був у пріоритеті, працював на Laravel 7 і PHP 7.4, і працював нормально. Ми перевели його на Laravel 13 і PHP 8.4 за три дні, версія за версією, і описали це у статті Шість версій Laravel за три дні. На сайті Інституту трихології в Харкові ми підняли стару збірку OpenCart до 3.0.5.1, останнього релізу у своїй лінійці, а PHP до 8.3. Магазин інституту Trichocosmetics багато років тому був зроблений на PHP 5.6 і так і не запустився. Ми перевели його на OpenCart 3.0.5.1 і PHP 8.4 та оновили модулі й інтеграції замість того, щоб робити заново. Обидва сайти стали помітно швидшими й відчуваються легшими, а магазин зараз запускається. Той самий підхід спрацював для сайтів міжнародних медичних федерацій та для інтернет-магазинів, які зовні працювали добре, а всередині накопичували технічний борг. Увесь метод, з вартістю та інструментами, у статті Оновлення старого сайту на Laravel чи PHP у 2026 році.

Переробка. В одного з наших клієнтів велика самописна система на PHP 5.3 з великою базою, що постійно змінюється. Підтримка безпеки PHP 5.3 закінчилася у 2014 році. Система працює, але багато її зв’язків тримаються на милицях, які додавалися по одній багато років. Оновлення перенесло б кожну з них у нову версію. Натомість ми підписали договір на повну переробку. Проєкт тільки почався, зараз ми розбираємо документацію разом з архітектором клієнта, щоб бізнес-процеси від самого початку були вибудувані правильно, а ШІ та інтеграціям, які компанії потрібні далі, було на що спертися.

Переробка потрібна не лише старому коду. Нинішній сайт IFHRS, Міжнародної федерації товариств з дослідження волосся, працює на WordPress і справляється з роллю набору сторінок. Федерації з товариствами-членами, керівництвом, комітетами, конгресами і десятиліттями історії потрібен контент, пов’язаний з іншим контентом, а її членам потрібен власний доступ. Тому нова платформа будується на Laravel, з особистим кабінетом і глибшим функціоналом, і ми розповідаємо про неї в кейсі IFHRS.

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

ВАРТІСТЬ

Скільки коштує підготувати систему до ШІ

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

Точну вартість не можна назвати за однією версією PHP чи Laravel. На неї впливають стан коду, кількість інтеграцій, документація, тести, вимоги до безпеки і допустимий ризик для бізнесу, що працює. Тому спершу ми оцінюємо систему і конкретне ШІ-завдання, а потім обсяг робіт. Наші орієнтири щодо аудиту і розробки зібрані на сторінці цін.

Починати варто з найменшого технічного кроку, після якого можливий вимірюваний результат.

Умовний приклад. Інтернет-магазин отримує 200 заявок на місяць, і первинна обробка кожної забирає у працівника 15 хвилин. Це 50 робочих годин на місяць, за умовної вартості години $30 близько $1 500. Якщо автоматизація справді скоротить цей час удвічі, економія становитиме близько $750 на місяць, або $9 000 на рік. Це ілюстрація, а не прогноз: у реальному розрахунку треба врахувати час на перевірку відповідей ШІ, вартість впровадження і підтримки, помилки та заявки, які однаково потребують людини.

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

ПОРЯДОК РОБІТ

Спершу фундамент, потім перше ШІ-завдання

Порядок важливіший за швидкість. Ось послідовність, за якою ми працюємо:

1. Аудит. Версії, дані, зв’язки, хто що знає.
2. Копія для тестів. Тимчасова копія системи, закрита від зовнішнього світу, зі знеособленими даними і без реальних клієнтських записів. Уся робота з оновлення йде там.
3. Оновлення ядра. PHP і фреймворк, по одній версії за раз, з перевіркою сайту після кожного кроку.
4. Дані та API. Дані, які знадобляться першому ШІ-завданню, доступні через API, а не через вивантаження.
5. Викатка. Після перевірок на копії оновлення йде на живий сайт, а копія видаляється.
6. Перше ШІ-завдання. Один процес, один вимірюваний результат: менше ручних відповідей, швидші комерційні пропозиції, менше помилок у замовленнях. Лише потім наступне.

Кроки з першого по п’ятий більшість ШІ-бюджетів пропускають. Саме через них шостий крок доходить до продакшну.

ЩО ЛАМАЛОСЯ

Що насправді йшло не так

Менше, ніж зазвичай очікують. Під час наших оновлень найчастіше проблеми були в CSS: стилі, прив’язані до старих версій бібліотек, з’їжджали після оновлення. Усі вони спливали і виправлялися на тестовій копії. Коли оновлені системи виїжджали на живий сайт, вони просто працювали.

Справжні сюрпризи були в іншому: код, про який ніхто не пам’ятав, налаштування, що жили лише на старому сервері, завдання за розкладом, яке запускалося із забутої папки. Тому аудит іде першим, а тестова копія обов’язкова.

РЕЗУЛЬТАТ

Що змінюється після оновлення

Після оновлень підключення ШІ-функцій та інтеграцій з CRM до цих систем стало звичайною розробкою, а не дослідницьким проєктом. Офіційні пакети встановлюються, оновлення безпеки знову надходять, у фонових завдань є черга, а дані читаються через API.

Оновлений фундамент до того ж здешевлює роботу над дизайном. На сайті Інституту трихології ми паралельно з оновленням підтягуємо дизайн і почали з футера: усі відділення і послуги на одній спокійній сітці замість короткого списку посилань. Той самий контент на тій самій платформі тепер виглядає як інший сайт. У магазину Trichocosmetics оновлення дизайну наступне.

Це і є справжній результат модернізації: не новий номер версії, а система, до якої наступне можна додати без милиці. Якщо компанія планує ШІ на наступний рік, найдешевший момент перевірити фундамент зараз, поки PHP 8.2 ще має два місяці підтримки.

НАСТУПНИЙ КРОК

Почніть з одного завдання

1. Оберіть одне бізнес-завдання, яке хочете автоматизувати.
2. Визначте дані та системи, без яких його не розв’язати.
3. Перевірте платформу: версії, API, фонові завдання і права доступу.
4. Знайдіть мінімальний обсяг модернізації, потрібний для безпечного пілота.
5. Домовтеся про критерій успіху до початку розробки: час обробки, частка помилок або кількість ручних операцій.

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

FAQ

Джерела

• CIO.com: The biggest issues IT faces today (звіт Gartner для CIO, квітень 2026)
• Packagist: laravel/ai
• Packagist: laravel/mcp
• Packagist: prism-php/prism
• Packagist: openai-php/laravel
• Packagist: anthropic-ai/sdk
• PHP: Supported versions
• PHP: Unsupported branches
• Laravel: Release notes and support policy