Это подтверждают данные. В отчёте Veracode GenAI Code Security Report 2026 AI-модели писали код, который почти всегда компилировался, но в среднем проходил лишь 56 % тестов безопасности — практически столько же, сколько годом ранее. А в опросе разработчиков Stack Overflow 2025 66 % назвали главной проблемой «AI-решения, которые почти правильные, но не совсем».

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

Что нужно подготовить перед стартом?

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

  • описание в один абзац: кто пользователи и какую работу приложение для них делает;
  • три-пять критериев приёмки для каждого ключевого сценария («клиент отправляет бронирование и получает письмо-подтверждение в течение минуты»);
  • список того, что не входит в первую версию;
  • систему контроля версий (Git) и место для тестовой копии (staging);
  • владельца, который утверждает релизы и разбирает инциденты;
  • если речь о персональных данных — понимание, где они хранятся и кто их обрабатывает.

Чек-лист AI-приложения по этапам

Проходите этапы по порядку. Пункты намеренно короткие: отметьте выполненный или запишите, почему он к вам не относится.

1. Рамки и продукт

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

2. Процесс разработки

Эти пункты следуют духу Secure Software Development Framework от NIST: защищайте код, проверяйте его и знайте, что попадает в сборку.

  • Весь код — в системе контроля версий, небольшими проверяемыми коммитами.
  • Человек читает каждое изменение, написанное AI, до слияния — особенно авторизацию, платежи и доступ к данным.
  • Секреты (API-ключи, пароли к базам данных) никогда не попадают в репозиторий и в код, который уходит в браузер.
  • Проект запускается с чистого клона по документированным шагам; ничего не держится на «у меня на ноутбуке работает».
  • Версии зависимостей зафиксированы и проверены на известные уязвимости; пакеты, предложенные AI, проверены — существуют ли они и поддерживаются ли.

3. Данные и права доступа

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

4. AI-функции внутри приложения (пропустите, если приложение не обращается к модели)

  • API-ключи моделей хранятся только на сервере.
  • Ответ модели считается недоверенным: перед изменением данных или запуском действий он проверяется по схеме.
  • Поиск по документам учитывает права пользователя — модель видит только то, что можно видеть ему.
  • Заданы тайм-ауты, лимиты частоты запросов и месячный потолок расходов.
  • Важные действия (отправка, оплата, удаление) требуют подтверждения человеком.
  • Есть запасной вариант на случай, если модель медленная, ошибается или недоступна.
  • Пользователи знают, когда общаются с AI, а сгенерированный контент при необходимости помечен.

5. Безопасность

  • Приложение проверено по стандарту OWASP Application Security Verification Standard на уровне, соответствующем риску.
  • Риски, специфичные для LLM, проверены по OWASP Top 10 для LLM-приложений, особенно промпт-инъекции и избыточные полномочия.
  • Аутентификация построена на проверенной библиотеке или сервисе, а не на коде, написанном AI с нуля.
  • Настроены заголовки безопасности, HTTPS, защита от CSRF и ограничение попыток входа.
  • Автоматическая проверка безопасности запускается на каждый pull request.

6. Тестирование

  • Тесты написаны по критериям приёмки, а не сгенерированы по той же реализации, которую должны проверять.
  • Они покрывают обычное использование, некорректный ввод, истёкшие сессии, повторные отправки и отказы в доступе.
  • Для AI-функций небольшой набор реальных примеров оценивает человек — до запуска и после каждой смены промпта или модели.
  • Доступность проверена по WCAG 2.2: подписи полей, работа с клавиатуры, фокус, контраст.
  • Вёрстка проверена на мобильных и десктопе, включая состояния загрузки, пустого списка и ошибки.

7. Приватность и соответствие требованиям

  • Политика конфиденциальности описывает то, что приложение делает на самом деле, включая AI-провайдеров, которые обрабатывают данные.
  • С хостингом и AI-провайдерами подписаны договоры об обработке данных (DPA).
  • Баннер cookies отражает реально используемые трекеры.
  • Проверено, не подпадает ли какая-либо AI-функция под более строгие правила EU AI Act (например, решения о найме или кредитах).

8. Запуск и эксплуатация

  • Тестовая среда, похожая на продакшен и с неконфиденциальными данными, проверена от начала до конца.
  • Восстановление из резервной копии хотя бы раз отрепетировано; откат описан.
  • Мониторинг охватывает ошибки, время ответа и расходы на AI, а тревоги доходят до человека.
  • Есть описанный способ быстро отключить AI-функции или отозвать интеграцию.
  • Ответственный за релиз подписывает его по чек-листу, списку известных проблем и плану восстановления.
  • Сначала запуск на ограниченную группу, затем сравнение реального поведения с критериями приёмки.

Ключевые пункты в одной таблице

Если времени мало, проверьте эти двенадцать.

Пункт

Почему это важно

Готово, когда…

Письменные рамки и список «вне рамок»

AI-ассистенты охотно строят то, о чём никто не просил

Есть бриф на одну страницу, изменения идут через него

Проверка AI-кода человеком

В исследовании Veracode 2026 года около 44 % тестов безопасности провалены

У каждого слияния есть названный проверяющий

Секреты вне репозитория и браузера

Утекший ключ — самый быстрый путь к взлому и большому счёту

Сканер секретов ничего не находит; ключи — в серверной конфигурации

Проверка прав на сервере

Скрытая кнопка не останавливает прямой вызов API

Тесты показывают, что доступ к чужим данным невозможен

Экранирование вывода и проверка ввода

В исследовании Veracode 2025 года модели не защитили код от XSS в 86 % случаев

Скан безопасности пройден; вредоносный ввод отклоняется

Проверка ответа модели перед использованием

LLM может вернуть неверный или подозрительный контент

Ответ проверяется по схеме до изменения данных

Лимиты расходов, запросов и времени

Цикл или злоупотребление может сжечь месячный бюджет за ночь

Потолки заданы, при 80 % срабатывает тревога

Тесты по критериям приёмки

Сгенерированные тесты часто подтверждают ту самую ошибку

Для каждого критерия есть хотя бы один проходящий тест

Базовая доступность

Отсекает пользователей и создаёт юридические риски

Проверки только с клавиатуры и со скринридером пройдены

Политика конфиденциальности и DPA

Персональные данные уходят новым обработчикам

Политика обновлена, договоры подписаны

Отрепетированные бэкап и откат

Непроверенные резервные копии часто подводят в нужный момент

Восстановление выполнено и замерено по времени

Мониторинг с назначенным владельцем

Без тревог проблемы остаются незамеченными

Тревоги доходят до человека, который может действовать

Какие ошибки совершают новички, создавая приложения с AI?

Новички чаще ошибаются в процессе, а не в технике: доверяют работающему демо, пропускают проверку и откладывают «скучное» на неделю запуска. Вот десять ошибок, которые мы видим чаще всего, и что делать вместо этого.

  • Выпустить демо. Прототип, который работает в идеальном сценарии, — ещё не продукт. Вместо этого: перечислите сценарии ошибок и сделайте их до новых функций.
  • Принимать код, который не читали. Компилируется — значит, всё в порядке. Вместо этого: проверяйте каждое изменение в авторизации, платежах и доступе к данным и запускайте сканер безопасности.
  • Проверять права только в интерфейсе. Спрятать кнопку — не значит ограничить доступ. Вместо этого: применяйте правила в API и тестируйте их.
  • Класть API-ключи во фронтенд. Любой откроет инструменты разработчика в браузере и скопирует их. Вместо этого: обращайтесь к моделям через свой сервер.
  • Поручать AI писать тесты к собственному коду. Тесты повторяют ошибку. Вместо этого: пишите тесты по критериям приёмки, лучше до кода.
  • Не ограничивать расходы на AI. Один цикл повторных запросов может выставить большой счёт. Вместо этого: с первого дня задайте лимиты, потолок расходов и тревоги.
  • Слепо доверять ответу модели. Модель возвращает текст, который выглядит правильным, но им не является. Вместо этого: проверяйте структуру и добавьте проверку человеком для важных шагов.
  • Устанавливать пакеты, предложенные AI, без проверки. Некоторых не существует или их никто не поддерживает — известный риск цепочки поставок. Вместо этого: проверяйте каждую новую зависимость.
  • Ходить по кругу с промптами. Час просить ассистента «исправь», вместо того чтобы разобраться в проблеме. Вместо этого: прочитайте ошибку, сузьте случай и задайте точный вопрос.
  • Не назначить владельца после запуска. Никто не следит за ошибками, не обновляет зависимости и не отвечает пользователям. Вместо этого: до запуска назначьте владельца и ежемесячное время на поддержку.

За большинством этих ошибок стоит одна закономерность: AI сделал ровно то, что его попросили, а правильных вопросов никто не задал. В наших проектах этап Validate существует именно для того, чтобы намеренно проверять странные случаи — истёкшие сессии, двойные клики, клиента, который вставляет в поле формы целый роман.

Сколько времени занимает AI-приложение и от чего зависит стоимость?

Сроки зависят гораздо больше от рамок, данных и интеграций, чем от скорости, с которой AI пишет код. Генерация ускоряет этап разработки, но не ускоряет решения, проверки, тестирование и согласования. Вот факторы, которые сильнее всего влияют на сроки:

Фактор

Меньше работы

Больше работы

Пользователи и роли

Один тип пользователя

Несколько ролей с разными правами

Данные

Новая простая модель данных

Миграция из существующих систем, персональные или финансовые данные

Интеграции

Нет или один хорошо документированный API

CRM, платежи, ERP, устаревшие системы

AI внутри продукта

Нет или простая генерация текста

Поиск по документам компании, агенты, выполняющие действия

Требования регуляторов

Внутренний инструмент без персональных данных

Клиентский сервис, регулируемая отрасль, AI высокого риска

Поддержка после запуска

Поддерживает ваша команда

Нужны постоянный мониторинг, оценка качества и поддержка

Как ValidVibe может помочь

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

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

Можно ли создать рабочее веб-приложение только с помощью AI?

Создать рабочее веб-приложение с помощью AI можно, но не одним только AI. Инструменты быстро пишут работающий код, однако в исследовании Veracode 2026 года сгенерированный код проваливал около 44 % тестов безопасности. Продакшен-приложению по-прежнему нужны проверка человеком, контроль доступа на сервере, настоящие тесты, мониторинг и владелец, который отвечает за него после запуска.

Безопасен ли код, написанный AI?

Код, написанный AI, по умолчанию небезопасен: в отчёте Veracode GenAI Code Security Report 2026 модели в среднем проходили лишь около 56 % тестов безопасности — почти как в 2025 году. Относитесь к такому коду как к коду неизвестного автора: проверяйте его, сканируйте автоматически и сами тестируйте критичные для безопасности участки.

Какая самая частая ошибка при создании приложения с AI?

Самая частая ошибка при создании приложения с AI — выпустить прототип под видом продукта. В демо, которое работает в идеальном сценарии, обычно нет проверки прав на сервере, обработки ошибок, тестов и лимитов расходов. Определите сценарии ошибок и критерии приёмки заранее и не запускайтесь, пока они не закрыты.

Нужно ли сообщать пользователям, что приложение использует AI?

Сообщать пользователям, что они взаимодействуют с AI-системой, например чат-ботом, как правило, нужно, а некоторый сгенерированный контент — помечать: правила прозрачности EU AI Act применяются с августа 2026 года. В политике конфиденциальности также стоит назвать AI-провайдеров, которые обрабатывают персональные данные. Детали для вашего случая уточните у юриста.

Как держать под контролем расходы на AI API в веб-приложении?

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

Источники

Об авторе

Команда ValidVibe — стратеги, дизайнеры и инженеры по AI-автоматизации. Мы создаём AI-агентов, автоматизацию процессов и AI-приложения для малого и среднего бизнеса в Европе и Великобритании. Более 80 реализованных проектов.