Для крупной федеральной компании из телеком-сектора команда разработчиков создала закрытую семейную платформу, объединяющую родительские и детские профили с тематическими районами, викторинами, мини-играми и творческими заданиями. Одной из ключевых активностей стала виртуальная роспись городского здания: пользователь выбирал фотографию фасада, загружал собственный рисунок, а система трансформировала его в изображение на стенах, сохраняя узнаваемость архитектуры. Задача требовала не просто генерации по тексту, а именно редактирования изображений с двумя исходниками, что исключало использование text-to-image подходов. На момент реализации ни GigaChat, ни Yandex не предоставляли подходящего API для такого сценария, поэтому выбор пал на OpenAI Image Edits, несмотря на ограничения доступа из России. Этот выбор был обусловлен не стремлением к единственной «лучшей нейросети», а конкретной механикой: нужно было передать два изображения — фасад и рисунок пользователя, — чтобы модель сохранила геометрию здания и детали авторского рисунка, что не гарантируется при генерации по текстовому описанию.

Прямой вызов OpenAI API с российского сервера был невозможен, а использование обычного сетевого proxy, по мнению команды, создавало слишком много неуправляемых рисков в production. Промежуточный узел мог логировать данные, менять ограничения или выходить из строя без возможности диагностики. Вместо этого разработчики подняли собственный application-level proxy на зарубежном VPS, который принимает только один контракт: два изображения и несколько разрешённых параметров. Этот сервис проверяет подпись и файлы, вызывает конкретный endpoint OpenAI, нормализует ошибки и возвращает предсказуемый JSON. Ключ OpenAI хранится исключительно на этом VPS, а российский backend знает только секрет для server-to-server подписи, что минимизирует риски утечки. Такой подход оказался надёжнее готовых сетевых туннелей благодаря полному контролю: известный код, собственный мониторинг, отсутствие общего публичного relay и возможность проверить весь маршрут от очереди до ответа OpenAI.

Полный поток запроса состоит из трёх независимых частей. React отвечает за пользовательский интерфейс: показывает доступные фотографии-основы, отправляет выбранный идентификатор и рисунок, затем опрашивает endpoint статуса. Laravel владеет пользователями, заданиями, состоянием генерации, временными исходниками и итоговыми файлами. При получении запроса backend проверяет токен, принадлежность детского профиля родителю, доступность задания по расписанию и допустимость выбранной основы. Пользовательский файл ограничен 10 МБ и форматами PNG, JPEG и WebP, причём Laravel читает MIME-тип и убеждается, что содержимое действительно декодируется как изображение. Перед постановкой в очередь рисунок уменьшается до 1920×1920 с сохранением пропорций и сохраняется во временное приватное хранилище как WebP с качеством 90, что снижает объём передачи и делает обработку предсказуемее. Саму фотографию клиент не загружает — он передаёт только ID из списка, определённого backend, что не позволяет пользователю подменить основу на произвольное изображение.

После валидации создаётся запись генерации с UUID, и в очередь отправляется задание ComposeImagesJob. Синхронный API на этом завершает работу и возвращает пользователю идентификатор задания для опроса статуса. Внутри очереди Laravel происходит последовательная обработка: загрузка исходников из приватного хранилища, подписанный запрос к proxy-сервису, ожидание ответа от OpenAI, сохранение результата и обновление статуса. Такой подход позволяет изолировать длительные операции от пользовательского интерфейса и гарантировать, что даже при сетевых ошибках или отказах модерации система остаётся предсказуемой. Proxy-сервис, в свою очередь, не знает о сущностях платформы и обрабатывает только подписанные запросы. Это архитектурное разделение ответственности — ключевое отличие от простого туннелирования: каждый компонент выполняет строго свою функцию, а точки отказа изолированы и диагностируемы.

Контекстно, этот кейс демонстрирует типичные вызовы для российских разработчиков, работающих с зарубежными AI-сервисами. Отсутствие прямого доступа к OpenAI API из российской инфраструктуры вынуждает искать обходные пути, но команда подчеркивает, что собственный proxy оказался надёжнее готовых сетевых туннелей благодаря контролю, мониторингу и возможности проверить весь маршрут от очереди до ответа OpenAI. В других проектах они применяли API GigaChat и Yandex, но для конкретной задачи с двумя изображениями подходящего решения не нашлось. Это подчёркивает фрагментацию рынка AI-инструментов, где каждый провайдер предлагает разные возможности, и выбор зависит от конкретной механики, а не от поиска одной лучшей нейросети. Примечательно, что в то время как на глобальном рынке появляются новые модели, например, китайская Kimi K3, ставящая под вопрос лидерство США в области ИИ, российские команды вынуждены адаптировать доступные решения под локальные ограничения, что создаёт дополнительный слой сложности.

Для российского рынка данная реализация показательна как пример адаптации зарубежных технологий под локальные ограничения. Несмотря на санкционные риски и блокировки, компании продолжают интегрировать AI-функции, строя сложные архитектурные решения. В то же время, конкуренты, такие как GigaChat и Yandex, постепенно расширяют свои возможности, и в будущем они могут покрыть подобные сценарии, что снизит зависимость от внешних провайдеров. Пока же разработчикам приходится балансировать между функциональностью, безопасностью и производительностью, как в описанном случае, где каждый этап — от валидации файлов до хранения ключей — был тщательно продуман. Этот кейс также иллюстрирует, что даже в условиях ограниченного доступа можно построить production-ready решение, если тщательно проработать архитектуру и не полагаться на «чёрные ящики» вроде публичных proxy.

Перспективы этого подхода связаны с дальнейшей оптимизацией и масштабированием. Команда рассматривает возможность кэширования результатов для повторяющихся запросов, а также интеграцию альтернативных AI-провайдеров по мере появления у них аналогичных API. Открытым остаётся вопрос стоимости: использование собственного VPS и оплата OpenAI API могут быть значительными при высоких нагрузках. Однако для production-продукта, где важна стабильность, такие затраты оправданы. В целом, этот кейс служит практическим руководством для других российских команд, сталкивающихся с необходимостью подключения зарубежных AI-сервисов в условиях ограниченного доступа. Он также поднимает более широкий вопрос о том, как долго сохранится необходимость в таких обходных путях, учитывая появление новых игроков на рынке ИИ, таких как китайские модели, и возможное ослабление санкционных барьеров.