Lovable расписал правила безопасности для финсектора: аудит-логи на 13 недель и EU inference

Lovable, сервис для сборки рабочих приложений через промпты, выпустил руководство для маркетинговых директоров в финансовом секторе. Идея простая: прототип кампании теперь можно собрать за часы, а вот согласование с комплаенсом и безопасностью занимает недели. Документ описывает, где проходит граница ответственности между платформой и клиентом, какие данные в Lovable загружать нельзя и как проверять приложение перед публикацией. Это вендорский текст, но в нём достаточно конкретики, чтобы использовать его как основу для внутреннего чек-листа.

Платформа и приложение: два уровня защиты

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

Перед сборкой компания предлагает ответить на пять вопросов: какие данные (публичные, внутренние, персональные, конфиденциальные инвестиционные), кто аудитория, что приложение делает (показывает, меняет записи, рассылает, даёт рекомендации), какова цена ошибки и кто владеет приложением и может его отключить. Низкий риск — внутренний планировщик кампаний на синтетических данных, прототип страницы мероприятия. Высокий — инвесторский портал, персонализированный фондовый маркетинг, интеграция с CRM, инструменты с неопубликованными оценками. Отдельно подчёркнуто: «внутреннее» не равно «безопасное», если внутри лежит существенная непубличная информация (MNPI).

Ключевое ограничение — раздел 3.8 соглашения об обработке данных (DPA) для Business и Enterprise. Он запрещает передавать чувствительные данные: номера финансовых счетов, государственные идентификаторы, биометрию, защищённую медицинскую информацию. Контроль доступа и EU inference этот запрет не отменяют.

Коннекторы, данные и география обработки

Самая тонкая часть — коннекторы. Их четыре типа, и от выбора зависит, кто увидит данные:

• Chat connector: личный контекст на этапе сборки (например, бриф из Google Drive), в опубликованное приложение не попадает, но данные в общем проекте могут увидеть коллеги.
• App + chat connector: один общий аккаунт для сборки и работы приложения, пользователи видят данные в рамках его прав.
• App user connector: каждый работает под своей учётной записью, например менеджер видит только свои счета.
• Custom connectors и MCP: поведение зависит от того, какой тип подключения выбран.

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

По обучению моделей: контент клиентов Business и Enterprise (промпты, файлы, код, результаты) исключён из тренировки по умолчанию. На Free и Pro данные могут использоваться, пока пользователь не откажется. EU inference доступен на Enterprise и направляет запросы к моделям на европейские точки; если подходящей нет, запрос завершается ошибкой, а не уходит в другой регион. Оговорки важные: границы провайдеров различаются, часть функций недоступна, некоторые агентские инструменты всё равно обрабатывают данные в США, а место хранения данных приложения настройка не меняет. Регион бэкенда Lovable Cloud выбирается отдельно.

Логи, тарифы и чек-лист перед публикацией

Аудит-логи Enterprise фиксируют изменения участников, ролей, настроек, подключений и публикаций: кто, когда, что и над каким ресурсом. Хранятся они 13 недель, примерно 90 дней, дальше нужен экспорт. Действия внутри самого приложения, скажем скачивание документа инвестором или утверждение рассылки, в эти логи не попадают, такие события разработчик должен заложить сам.

По тарифам: Pro даёт кастомные домены и дизайн-системы, Business добавляет SSO, ролевой доступ, шаблоны дизайна и отсутствие обучения на данных по умолчанию, Enterprise — аудит-логи, SCIM, плановые сканирования безопасности. Расход кредитов стоит закладывать и на сборку, и на эксплуатацию: бэкенд, ИИ и часть коннекторов тоже их тратят.

Практический порядок действий для команды выглядит так. Сначала классифицируйте проект по пяти вопросам и сверьте данные с DPA. Собирайте на синтетике. Для приложения на пять человек выберите кастомную аудиторию на Business и Enterprise или Invite only на Free и Pro. Проверьте оба края: посторонний не открывает дашборд, а приглашённый видит только свои записи. Для действий с последствиями добавьте шаг подтверждения. Секреты держите только в хранилище Secrets, а не во фронтенде. Закройте найденные сканером уязвимости, протестируйте под разными аккаунтами и назначьте владельца, который может отключить приложение. Платформа даёт инструменты, но ответственность за данные и права остаётся за вами.