Вы создали это в Lovable — кто отвечает, если произойдёт утечка данных?

Менеджеру продукта нужна внутренняя панель управления. Вместо того чтобы оформлять заявку и ждать квартал, пока за неё возьмётся отдел разработки, он открывает Lovable, описывает желаемое обычным языком, подключает это к корпоративному Google Workspace компании и уже к вечеру того же дня получает работающее приложение. Оно читает данные из Drive, извлекает несколько таблиц и еженедельно отправляет по почте сводку. Всё работает. Все довольны.

Никто не задаёт вопрос, который станет важным спустя полгода, когда его задаст специалист по проверке безопасности или регулятор: кто несёт ответственность за то, как это приложение обращается с данными, к которым оно имеет доступ?

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

Что на самом деле означает «приложение, созданное ИИ»

Новая категория инструментов — Lovable, Base44, Bolt.new, Cursor и растущий список других — позволяет людям создавать и развёртывать полноценные веб-приложения на основе запросов на естественном языке. Их часто называют платформами «вайб-кодинга» (vibe coding). Привлекательность очевидна: человек без опыта разработки может создать то, что раньше требовало команды специалистов, — и сделать это за считаные часы.

Эти приложения — не игрушки. Они развёртываются для реальных пользователей и регулярно подключаются к реальным корпоративным системам — Google Workspace, Salesforce, внутренним базам данных — через обычные OAuth-разрешения. С точки зрения данных приложение, созданное за вечер по одному запросу, и приложение, разрабатываемое месяцами инженерной командой, выглядят идентично: оба обладают токеном доступа, и оба могут читать всё, что этот токен позволяет.

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

Создание с помощью ИИ не означает безопасность

Здесь стоит быть точным и справедливым: приложение, созданное в Lovable или Base44, не является небезопасным по своей сути. Эти платформы способны создавать вполне добротные приложения, и многие так и делают. Риск не в том, что ИИ пишет плохой код. Риск — в управлении (governance), и он проявляется тремя предсказуемыми способами.

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

Доступ широк и невидим. ИИ-конструкторы запрашивают те области доступа (scopes), которые нужны, чтобы демонстрация работала, а «заставить работать» часто означает широкий доступ на чтение. Внутренняя панель, которой требовалось читать только одну папку, может получить доступ на чтение ко всему Drive. Поскольку разрешение было выдано через обычный экран согласия OAuth, оно никогда не появлялось на радаре службы безопасности — по определению, это теневой ИТ.

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

Почему ответственность несёт компания, а не платформа

Вот часть, которая удивляет многих. Когда приложение, созданное ИИ, неправильно обращается с данными, юридическая и регуляторная ответственность ложится на организацию, которая его развернула, а не на ИИ-платформу, которая его сгенерировала.

Это тот же сдвиг ответственности, который сейчас в целом переформатирует законодательство об ИИ. Согласно Общему регламенту ЕС по защите данных (GDPR), сторона, определяющая цели и способы обработки персональных данных, является контролёром данных, и именно на контролёра возлагаются обязательства — законное основание обработки, минимизация данных, ограничение сроков хранения и обязанность всё это подтверждать. Когда ваша компания развёртывает приложение, обрабатывающее данные клиентов, контролёром является именно ваша компания. Платформа-конструктор — в лучшем случае инструмент, который вы использовали.

Более широкий правовой ландшафт 2026 года указывает в том же направлении. Суды начали рассматривать компанию, использующую систему ИИ, как ответственную за её поведение — судебный процесс *Mobley v. Workday* в США основывался на теории агентских отношений и впоследствии получил условную сертификацию как общенациональный коллективный иск. В Германии Верховный земельный суд Хамма (OLG Hamm) рассмотрел вопрос ответственности за то, что система ИИ сообщает клиентам, и дал понять, что общая оговорка «без гарантий» сама по себе не защищает развернувшую систему компанию. Закон ЕС об ИИ (EU AI Act) добавляет к этому обязательства, специфичные для развёртывающей стороны, с существенными штрафами за высокорисковое использование. Подробнее об этом сдвиге — в нашем обзоре о том, кто несёт ответственность при утечке данных ИИ-агентом.

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

Слепая зона на конкретном примере

Соберите всё воедино — и вырисовывается конкретный, распространённый сценарий сбоя:

• Нетехнический сотрудник создаёт приложение с помощью ИИ-конструктора.
• Приложение подключается к Google Workspace через OAuth и получает широкие права доступа.
• Оно получает доступ к персональным данным клиентов или сотрудников — контактам, содержимому писем, файлам.
• Никто не проверил обработку данных, и политика хранения данных нигде не зафиксирована.
• У службы безопасности нет записи об этом приложении в инвентаре, потому что оно никогда не проходило проверку.

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

Как закрыть этот разрыв

Решение — не запрет ИИ-конструкторов: эту гонку уже проиграли, а рост производительности реален. Решение — видимость и доказательства: знать, какие приложения, созданные ИИ, подключены, знать, к чему каждое из них имеет доступ, и уметь показать, что вы ими управляете.

Именно это и делает 8200.dev. Сервис обнаруживает OAuth-приложения, подключённые к вашему Google Workspace, и помечает те, что происходят из ИИ-конструкторов — Lovable, Base44, Bolt.new, Cursor и подобных — по сигнатурам имени приложения и хоста перенаправления, а также по характерному признаку: неподтверждённое, недавно созданное приложение, уже обладающее широкими правами доступа. По каждому такому приложению вы видите платформу-конструктор, точные предоставленные права доступа, того, кто их авторизовал, и оценку риска — всё это отображается в отдельном разделе AI-Built Apps наряду с остальными вашими ИИ-агентами и OAuth-приложениями.

Когда приложение, созданное ИИ, может получить доступ к персональным данным клиентов (PII) или обладает широким доступом без документированной политики хранения, система формирует конкретное замечание — так разрыв превращается в задачу с назначенным ответственным, а не в неожиданность на аудите. И любое приложение, созданное ИИ, может быть зафиксировано в Реестре ИИ-агентов, так что даже те приложения, до которых не дотягивается ни один коннектор, отражаются в едином полном инвентаре. Полный список возможностей можно посмотреть здесь.

Цель — не в том, чтобы замедлить работу ваших команд. Цель в том, чтобы, когда возникнет вопрос — от регулятора, аудитора или в рамках проверки безопасности со стороны клиента, — вы могли на него ответить. Не «мы создали это с помощью ИИ, значит, это проблема платформы» (что не является защитой), а «вот приложение, вот точно то, к чему оно имеет доступ, и вот доказательства того, что мы его проверили». Более подробный взгляд на то, чего теперь ожидают проверяющие, — в статье что аудиторы требуют от управления ИИ в 2026 году.

Создавать с помощью ИИ — быстро. Нести ответственность за созданное — не опционально. Эти две вещи примиряет одно: знание того, к чему на самом деле могут получить доступ ваши ИИ-созданные приложения.

Начните с того, чтобы увидеть, что уже подключено к вашему Workspace. Вы можете составить карту ваших ИИ-созданных приложений, оценить их доступ и получить первое доказательство на бесплатном тарифе — смотрите тарифы и начните бесплатно.

*Эта статья содержит общую информацию, а не юридическую консультацию. За рекомендациями, специфичными для вашей организации, обращайтесь к квалифицированным юристам.*