Как довести AI-прототип до продакшена: что ломается и как это починить

Коротко. AI-инструмент соберёт вам рабочий прототип за выходные, но «работает в демо» и «безопасно запускать в продакшене» — это две разные вещи. В почти каждом приложении, собранном AI, всплывают одни и те же три проблемы: дыры в безопасности (открытые ключи, отсутствие авторизации, инъекции), неконтролируемые расходы на API (перерасход в 5–20 раз из-за вызовов без кеша, без батчинга и без лимитов) и утечки данных (чувствительная информация в логах, избыточные ответы API, экспозиция в сторонние сервисы). Прототип не выбрасывают — его проверяют аудитом, чинят эти три категории и выпускают. Этот пост — план действий: что ломается, почему и пошаговый путь от прототипа до продакшена. А если хотите передать это нам — именно этим и занимается аудит AI-кода.

Если нужен только процесс — переходите к тому, как это выпустить.

Прототип, который работает в демо и ломается в продакшене

Вы сделали что-то настоящее. Cursor, Bolt, Lovable или долгая сессия с ChatGPT превратили идею в работающее приложение за дни, а не месяцы. Выглядит отлично. Работает на вашей машине. Вы показываете его ранним пользователям или инвесторам — и обратная связь хорошая. Поэтому вы направляете его на домен, переключаете в продакшен и начинаете присылать туда реальных людей.

Вот тут и начинаются проблемы — и не потому, что вы сделали что-то не так. AI-агенты невероятно хороши в производстве кода, который работает. Они плохи в производстве кода, готового к продакшену, потому что это разные цели. «Работает» означает, что отрабатывает счастливый путь. «Готов к продакшену» означает, что код переживает атакующего, всплеск трафика, кривой ввод и биллинговый цикл — ни одно из этого не появляется в демо.

Это не маргинальная проблема. Veracode протестировала 100+ LLM и обнаружила, что 45% сгенерированного кода не проходит проверки безопасности. Анализ Apiiro за 2025 год показал, что разработчики с AI раскрывают учётные данные почти вдвое чаще. Исследователи из Стэнфорда выяснили, что разработчики с AI-ассистентами пишут менее безопасный код, будучи при этом более уверенными в его безопасности. Именно этот разрыв в уверенности и опасен: демо выглядит законченным, поэтому те 20%, что не закончены, остаются невидимыми, пока не обойдутся вам дорого.

Хорошая новость в том, что разрыв предсказуем. После аудита десятков сгенерированных AI кодовых баз сбои собираются в три корзины — те самые три, которые у прототипа не было причины обрабатывать.

Три вещи, которые ломаются

1. Дыры в безопасности

AI-инструменты оптимизируют кратчайший путь к работающей функции, а кратчайший путь почти никогда не бывает безопасным.

• Открытые ключи и секреты. API-ключи, учётные данные баз и токены сервисов зашиваются в исходники, попадают в клиентские бандлы или коммитятся в .env-файлы. Один утёкший сторонний ключ может нагенерировать тысячи долларов несанкционированного использования за часы — или отдать атакующему ваше хранилище данных.
• Аутентификация без авторизации. Экран логина есть, поэтому кажется, что безопасно. Но бэкенд часто не проверяет, кому что вообще разрешено. Эндпоинты принимают любой запрос; поменяйте ID в URL — и вы читаете чужие записи. Это — сломанная авторизация на уровне объектов — самый частый дефект, который мы находим, и он не зря стоит первым в списке OWASP API Security.
• Инъекции. SQL-инъекции, XSS и prompt injection в AI-коде повсюду, потому что модели охотно склеивают пользовательский ввод прямо в запросы, HTML или промпты LLM. Один неочищенный эндпоинт может раскрыть всю базу или позволить атакующему управлять вашим AI.
• Небезопасное хранение. Персональные данные в открытом виде, токены сессий в localStorage, пароли, хешированные MD5 или вовсе нет. AI выбирает простейшую реализацию, которая редко бывает безопасной. (Мы написали полный разбор того, как данные должны на самом деле шифроваться при хранении и передаче — это та статья, на которую мы ссылаем клиентов.)

2. Неконтролируемые расходы на API

Эта проблема тихо разоряет запуск, а не взламывает его.

• Избыточные вызовы. Приложения, собранные AI, дёргают один и тот же платный эндпоинт — геокодинг, курсы валют, LLM, API верификации — снова и снова ради данных, которые у них уже есть. Ни кеша, ни мемоизации. Мы регулярно находим приложения, где 60–80% трат на API — чистые потери.
• Нет бюджетов и лимитов. Ни лимита на пользователя, ни дневного потолка, ни предохранителя. Один увлечённый пользователь, скрейпер или бот может сжечь весь месячный бюджет за полдня. У AI нет понятия о ваших тарифах или runway, поэтому он никогда не ставит ограничители.
• Нет батчинга. Отдельные запросы в цикле вместо батч-эндпоинта, который предлагает провайдер. На масштабе демо это незаметно; на масштабе продакшена — пятизначный счёт в месяц.

Стоимость разработки приложения — это одно, а стоимость эксплуатации неоптимизированного — тот сюрприз, который застаёт основателей врасплох.

3. Утечки данных

Категория, превращающая тихий успех в инцидент с комплаенсом.

• Логирование чувствительных данных. AI обожает многословное логирование. Email, пароли, платёжные данные и персональная информация оседают в логах приложения и трекерах ошибок, часто хранятся бессрочно и доступны любому, у кого есть доступ к дашборду.
• Избыточные ответы API. Эндпоинты возвращают весь объект пользователя — хешированные пароли, внутренние ID, метаданные — когда фронтенду нужно было только отображаемое имя. GraphQL-эндпоинты без ограничения глубины, позволяющие атакующему обойти всю вашу модель данных.
• Экспозиция в сторонние сервисы. Аналитика, мониторинг и трекеры ошибок подключаются без мысли о том, что в них утекает. Поведение пользователей и персональные данные покидают вашу систему без согласия — ровно то, под что писались штрафы GDPR.

Как довести AI-прототип до продакшена

Вы не переписываете заново — это выбрасывает те 80%, что AI сделал правильно. Вы проверяете прототип аудитом, чините три категории выше в порядке приоритета и выпускаете. Вот путь, по которому мы работаем.

Шаг 1 — Заморозить и определить объём

Первый порыв после удачного демо — добавить ещё функций. Сдержитесь. Добавление кода к непроверенной базе лишь умножает поверхность, которую придётся чинить. Зафиксируйте объём, выдайте доступ на чтение и решите, что покрывает обзор — полный проход или сфокусированный на том столпе, что пугает больше всего. В продакшене пока ничего не меняется.

Шаг 2 — Автоматическое сканирование

Статический анализ, сканирование зависимостей и секретов, профилирование расходов быстро ловят очевидные проблемы: закоммиченный API-ключ, пакет с известным CVE, эндпоинт, который дёргают 300 раз в минуту. Это дешёвый высокообъёмный слой.

Шаг 3 — Ручной экспертный обзор

Дорогие проблемы прячутся там, где инструменты не видят: эндпоинт, возвращающий правильные данные, но никогда не проверяющий, кто спрашивает; биллинговый цикл, корректный, но без кеша; сторонняя интеграция, тихо отправляющая PII наружу. Человек читает архитектуру, потоки авторизации и пути данных. Именно этот шаг отличает аудит AI-кода от линтера.

Шаг 4 — Приоритизированные исправления

Находки сортируются по критичности и чинятся по порядку. Сначала критические дыры в безопасности — утёкший ключ или обход авторизации это ЧП. Затем контроль расходов, потому что каждый день при перерасходе в 5–20 раз — это реальные деньги. Затем приватность и комплаенс. Вы просматриваете и одобряете каждое изменение перед слиянием; с вашим кодом ничего не происходит без вашего согласия.

Шаг 5 — Выпуск с уверенностью

Перепроверьте по каждой находке, убедитесь, что патчи держатся, и разверните. Тот же продукт, тот же собранный AI фундамент — теперь укреплённый. В этом и весь смысл: вы сохраняете скорость, которую дал AI, и добавляете надёжность, которую он не смог.

Мы прогоняли ровно это на реальных проектах. Arcana, клиент стримингового AI-чата, прошла путь от прототипа до выпущенного, продакшен-уровня приложения — неблагодарная работа по укреплению стриминга, авторизации и работы с данными и превратила демо в то, на что люди действительно могут положиться.

Сколько это стоит и сколько занимает

Сфокусированный проход по безопасности небольшого одно-сервисного приложения занимает 1–2 недели; полный аудит готовности к продакшену — безопасность, расходы, данные, производительность, инфраструктура — для типичного многосервисного приложения это 2–4 недели. Это на порядок быстрее и дешевле, чем 3–6 месяцев на переписывание с нуля, потому что вы сохраняете всё, что AI сделал правильно, и чините только то, что он сделал не так.

Полезная ментальная модель: AI проводит вас на 80% пути за 5% времени. Последние 20% — безопасность, контроль расходов, приватность данных, обработка ошибок — это и есть вся разница между демо и продуктом. Аудит покупает эти 20%, не выбрасывая фундамент. Полные тарифы и цены — на странице аудита AI-кода.

Частые вопросы

Выпустите то, что уже построили

Вы сделали трудную часть — нашли то, что стоит строить, и заставили это работать. Не позволяйте невидимым 20% превратить настоящий успех во взлом, неожиданный счёт или проблему с комплаенсом. Прогоните прототип через аудит AI-кода, почините три вещи, которые ломаются, и выводите его к реальным пользователям с уверенностью.

Если у вас есть собранное AI приложение, которое страшно разворачивать, запишитесь на бесплатную оценку. Мы скажем, какой из трёх столпов — ваш главный риск, что потребуется для исправления, и дадим фиксированную оценку объёма — а не догадку.