Соответствие требованиям РФ: 152-ФЗ, DPA¶

Эта страница отвечает на типовые вопросы юридических и ИБ-служб российских заказчиков:

где физически обрабатываются промпты и метаданные;
применяется ли 152-ФЗ о персональных данных и не нарушается ли трансграничная передача;
какие документы (DPA) сопровождают развёртывание;
каков статус в реестре отечественного ПО.

Ключевой принцип: выбор сценария за заказчиком¶

Glarus AI — модельно-агностичная платформа (см. "Поддерживаемые LLM-провайдеры"). Именно заказчик решает, какую LLM использовать, и именно выбор провайдера модели определяет юрисдикцию данных и применимость 152-ФЗ.

Три сценария и их последствия по 152-ФЗ:

Сценарий	Юрисдикция данных	Трансграничная передача ПД	Режим работы по 152-ФЗ
A. Локальная LLM (Ollama / совместимый сервер в контуре заказчика)	периметр заказчика	нет	соответствие 152-ФЗ обеспечивается так же, как и для любой on-premise-системы заказчика
B. Российский облачный провайдер (MWS GPT)	РФ (дата-центр провайдера)	нет	152-ФЗ выполняется; провайдер сам является оператором ПД и имеет УЗ-1. Заказчик подписывает DPA с провайдером LLM
C. Иностранный облачный провайдер через прокси (Claude / OpenAI / Gemini)	США / ЕС	да	требуется согласие субъекта ПД в явной форме (ст. 12 152-ФЗ), а также DPA от зарубежного провайдера и уведомление Роскомнадзора

Glarus Digital как поставщик платформы не навязывает сценарий. Для клиентов, работающих с массовыми ПД (госсектор, финансы, медицина, страхование), рекомендуются сценарии A или B. Сценарий C допустим только для данных без ПД (обезличенная агрегация, технические показатели).

Что уходит в LLM при запросе¶

Важно различать три типа данных, которые могут передаваться модели:

Промпт пользователя — текст вопроса. Может содержать ПД, если пользователь их туда включил.
Метаданные схемы — имена таблиц, колонок, типы данных, описания моделей. Обычно ПД не являются, но имена колонок вида passport_number, client_fio раскрывают структуру хранимых ПД.
Фрагменты данных (результаты промежуточных SQL-запросов агента) — могут содержать ПД, если агент вытащил их из таблицы.

В Glarus AI действуют следующие средства контроля:

RLS / CLS наследуются из прав пользователя Glarus BI — агент не видит столбцов и строк больше, чем видит сам пользователь.
Маскирование полей на уровне семантической модели (Admin → Data Model → Field → Mask). Колонки с ПД (ФИО, паспорт, телефон) можно пометить как маскируемые — вместо значения в LLM уходит ***.

Архитектурная схема обработки данных¶

Схема обработки данных

Вся оркестрация, логирование и доступ к источникам данных происходят внутри периметра заказчика. За его пределы уходят только HTTP-запросы к выбранной модели — и только в сценариях B и C. В сценарии A наружу не уходит ничего.

Основные элементы:

Периметр заказчика (on-prem / private cloud): браузер аналитика → Glarus BI (с RLS/CLS и маскированием) → Glarus AI Orchestrator + MCP-клиент → источники данных (ClickHouse, Postgres, …) и MCP-серверы (1С, внутренние API, документация) и MongoDB (журнал сессий и tool calls).
Исходящие вызовы только к выбранной LLM:
сценарий A — LLM развёрнут внутри периметра (Ollama / совместимый сервер), исходящий трафик отсутствует;
сценарий B — HTTPS-запрос к MWS GPT (РФ, УЗ-1);
сценарий C — HTTPS-запрос через российский прокси к иностранному провайдеру (предупреждение: трансграничная передача ПД).

Что логируется и где хранится¶

Glarus AI ведёт подробный журнал сессий в MongoDB, развёрнутой в контуре заказчика:

текст промпта пользователя;
цепочка вызовов MCP-инструментов (какие SQL выполнены, какие таблицы/колонки запрошены);
ответ модели;
временные метки, идентификатор пользователя.

Настройки retention:

По умолчанию: 90 дней, после чего запись удаляется cron-задачей.
«Только метаданные»: в Admin → AI → Privacy включается опция, при которой тексты промптов и ответов не сохраняются — остаются только метаданные (пользователь, время, использованные инструменты). Рекомендуется для обработки массовых ПД.
Режим zero-logging: полное отключение логов ответа модели — используется при работе с коммерческой и банковской тайной.

Независимо от настроек ретеншна, MongoDB Glarus AI развёрнут в контуре заказчика, никакие данные в Glarus Digital (вендора) не отправляются.

DPA провайдера LLM¶

Для сценария B пример DPA и аттестата — у MWS GPT: инфраструктура развёрнута в аттестованном сегменте 152-ФЗ, УЗ-1 — см. mws.ru/services/iaas-152-fz/.

Для других российских провайдеров DPA и условия обработки данных запрашиваются у выбранного провайдера в составе условий предоставления услуги.

Для сценария C DPA запрашивается у провайдера-оригинала (Anthropic / OpenAI / Google) — это отдельный документ от DPA с поставщиком прокси и от DPA с Glarus Digital.

Реестр отечественного ПО¶

Glarus AI — штатный компонент Glarus BI и покрывается единой реестровой записью Glarus BI в реестре российских программ для ЭВМ. Дополнительная реестровая запись на AI-модуль не требуется.

Внешний LLM-провайдер — отдельный элемент архитектуры; если требуется «российский LLM по реестру», подходит MWS GPT — входит в реестр Минцифры.

Реестровый номер Glarus BI — см. главную страницу glarus-bi.ru.

Чек-лист для внедрения с ПД¶

Определите, содержат ли ваши аналитические данные ПД (фамилии, паспорта, телефоны, e-mail, адреса).
Если да — выберите сценарий A (локальная LLM) или B (российский провайдер).
Подпишите DPA с провайдером LLM.
Проведите внутренний аудит маскирования: выполните 10–20 типовых запросов и убедитесь, что в логах MCP-сервера в полях промптов нет ПД.