ИИ-проект застрял на старой системе? Сначала обновление, потом автоматизация

У большинства компаний, которые хотят ИИ, уже есть рабочая система: магазин, 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