Перейти к содержимому

Что происходит с моими данными в AI-билдере: разбор

Под словом «данные» скрываются три разные вещи, и путать их дорого. Есть то, что вы вводите в билдер: описания и промпты. Есть результат: исходный код проекта. И есть самое важное, данные людей, которые пользуются вашим сайтом. Третья группа в Zugo не хранится: она живёт в ваших аккаунтах Supabase и Stripe.

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

Какие данные вообще участвуют?

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

Что за данные Где живёт Кто управляет
Ваши промпты и история сборки Рабочее пространство в Zugo Zugo, доступ у вас
Исходный код проекта Сборка в Zugo и ваш репозиторий после экспорта Вы после экспорта
Пользователи вашего сайта, их вход и профили Ваш проект Supabase Вы
Файлы, которые загружают посетители Ваш проект Supabase Вы
Платежи, карты, покупатели Ваш аккаунт Stripe Вы и Stripe
Письма и адреса получателей Ваш аккаунт Resend Вы
Статистика посещений Ваш аккаунт Google Analytics Вы и Google

Читать таблицу стоит по колонке «где живёт». Самое чувствительное, то есть персональные данные ваших клиентов и их платежи, физически не попадает в билдер: оно идёт напрямую в сервисы, которые вы подключили под своим именем.

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

Где хранятся данные людей, которые пользуются моим сайтом?

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

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

Обратная сторона честная: ответственность тоже ваша. Правила доступа к таблицам, резервные копии и то, кому вы раздали ключи, находятся в вашей зоне. Как устроено подключение и что именно оказывается в базе, разобрано в статье приложение с Supabase.

Что происходит с промптами и сгенерированным кодом?

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

Код проекта существует в двух местах, как только вы сделаете экспорт. Первое это сборка внутри Zugo, второе это репозиторий на GitHub под вашим аккаунтом. После экспорта проект принадлежит вам целиком, и это самая практичная форма страховки от любых вопросов о доступе.

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

Кто отвечает за платежи и данные покупателей?

Stripe, и это правильный ответ, а не попытка отойти в сторону. Реквизиты карт не проходят через сборку и не хранятся в проекте: оплата уходит на сторону Stripe, а ваш сайт получает обратно факт успешной операции.

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

Разумный порядок: сначала подключить оплату и проверить весь путь на маленькой сумме, потом звать покупателей. Как это устроено в сборке, разобрано в статье оплата через Stripe в AI-приложении.

Как забрать всё и уйти?

Тремя действиями, и ни одно из них не требует разрешения. Экспортируйте код в свой репозиторий на GitHub. Данные пользователей уже в вашем Supabase, оттуда делается выгрузка штатными средствами. Платежи и клиенты уже в вашем Stripe.

Останется одно: адрес. Опубликованный проект живёт на имя-проекта.zugo.run, и если вы подключали свой домен, то переезд означает направить домен в другое место. Проект при этом продолжает работать там, куда вы его развернёте, например в вашем аккаунте Vercel.

Такой сценарий стоит прорепетировать заранее, а не в тот день, когда он понадобился. Полчаса на репетицию дают точное знание вместо предположения. Про снимки состояния и запасные копии есть отдельная статья: как делать резервные копии.

Чего нельзя обещать честно?

Четыре вещи, и их отсутствие в других текстах должно вас настораживать сильнее, чем их присутствие здесь.

  • Никакой инструмент не делает ваш проект защищённым сам по себе. Сгенерированный код это рабочая отправная точка, а не результат аудита безопасности. Настройки доступа к вашим таблицам проверяете вы или приглашённый специалист.
  • Проверка перед выдачей узкая. Каждая сборка запускается в песочнице, и та, что не открылась, помечается как неудачная вместо того, чтобы уехать к вам. Это снижает риск получить пустой экран и ничего не говорит об уязвимостях.
  • Ответственность по закону остаётся на вас. Вы собираете персональные данные своих клиентов, значит вы сторона, которая объясняет им, зачем, и выполняет их просьбы.
  • Специфичные требования разработчик закроет лучше. Если у вас медицинские, финансовые или иные регулируемые данные, Zugo не заменяет команду разработки и юриста. Он даёт быструю первую версию, а не соответствие требованиям.

Признавать это выгоднее, чем обещать спокойствие. Человек, который знает границу, ставит правильные вопросы до запуска, а не после инцидента.

Что проверить до того, как пускать людей?

Короткий список, который занимает вечер и снимает большую часть типовых проблем.

Первое: посмотрите, какие поля вы вообще собираете. Каждое лишнее поле в форме это данные, которые вы обязались хранить и защищать. Убрать ненужное поле стоит одну правку, то есть 3 кредита, и это самая дешёвая мера безопасности из существующих.

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

Третье: подключите оплату и вход только тогда, когда они действительно нужны. Лишняя интеграция это лишний аккаунт, лишний счёт и лишняя поверхность для ошибки. Соберите минимальную версию на zugo.dev, проверьте её на себе и добавляйте сервисы по мере появления настоящей потребности.

← Все статьи